1

An ID/locator split architecture for future networks

Ved P. Kafle, Hideki Otsuki, and

Masugi Inoue, National Institute of Information and Communications Technology

IEEE Communications Magazine, vol. 48, no. 2, pp. 138-144, 2010.

2

Introduction

• Current packet-based networks, both the Internet and next-

generation network, are based on domain names DNS IP addressesthe existence of multiple cached copies in the global system of DNS servers– not suitable for the fast update and retrieval of hosts’ dynamic

information

The dual use of IP addresses as IDs and locators– makes it difficult to design efficient solutions for mobility,

multihoming, renumbering, and security • which require the capability of changing locators without changing IDs.

3

Introduction (cont.)

• An ID/locator split architecture [6-10] allows the network layer to change locators without requiring the upper layers to change IDs – ensure that the communication sessions associated with the IDs

are not interrupted.

• ITU-T Study Group 13 has been discussing the ID/locator split concept and has recently approved Recommendation (ITU-T Y.2015) for the NGN functional architecture.

[6] New Generation Network Architecture, “AKARI Conceptual Design (v. 1.1),” NICT, Oct. 2008; http://akari-pro-ject.nict.go.jp

4

contributions of this paper

• develop a new naming system, Host Name and Identifier System (HNIS), for configuring hostnames and IDs.

• use the HNIS in a new network architecture that is based on the ID/locator split concept.– the hostnames and IDs are used in the communication process – the architecture supports network-based mobility and

multihoming in heterogeneous networks (e.g., IPv4 and IPv6)

– makes the routing scalable.

5

Related Work

• the IETF Site Multihoming by IPv6 Intermediation (Shim6) WG has developed the Shim6 protocol [7]– to solve the multihoming problem,– a host uses one of the available IP addresses as the upper layer

ID (ULID) and changes the IP addresses (i.e., locators) used in the network layer when interfaces are switched.

[7] E. Nordmark and M. Bagnulo, “Shim6: Level 3 Multi-homing Shim Protocol for IPv6,” RFC 5533, June 2009.

from http://www.shim6.org/

6

• Six/One routers [8] extend the Shim6 concept– allow hosts as well as edge network operators to choose a

provider’s network • by ensuring that the edge routers have address translation capability.

[8] C. Vogt, “Six/One Routers: A Scalable and Backward Compatible Solution for Provider-Independent Addressing,” Proc. ACM MobiArch, Aug. 2008, pp. 13–17.

[8]

7

Related Work (cont.)

• the IETF Host Identity Protocol (HIP) WG has developed HIP [9] – for improving the security of the Internet– uses public keys (and their hash values) and IP addresses as IDs

and locators, respectively.

[9] R. Moskowitz and P. Nikander, “Host Identity Protocol (HIP) Architecture,” RFC 4423, May 2006.

8

Related Work (cont.)

• the Locator/ID Separation Protocol (LISP) [10] has been considered by the IETF LISP WG. – LISP uses prefix-aggregatable end-point identifiers (EIDs), which can be

mapped to routing locators (RLOCs) in ingress tunnel routers by consulting a mapping system.

– make routing scalable

[10] D. Farinacci et al., “Locator/ID Separation Protocol (LISP),” Internet draft, Sept. 2009; draft-ietf-lisp-05.txt

Figure from http://www.ietf.org/proceedings/70/slides/RRG-7.pdf

9

Related Work (cont.)

• LISP does not consider hostnames.– Although it assumes hierarchical EIDs, it does not contain information

on how such EIDs are generated and mapped to hostnames.

• HIP assumes that DNS servers store and provide information for mapping hostnames to IDs (and locators). – DNS may not be able to accommodate mapping information for a

huge number of hosts • sensors and mobile devices

• HIP also assumes that every host has a public key as its ID. – this assumption helps secure communications, – it may not be applicable in a general case where many small hosts

support only lightweight communications.

10

Hostname and Identifier System

• Hostname: variable-length character sets that can be read and remembered by humans

• host IDs: fixed-length bit strings that cannot be memorized by humans

SHA1 or MD5 etc.Used to aggregate host IDs that refer to a specific context and simplify their resolution.

Whether this ID is private, public, local, or global.

11

Proposed Network Architecture

wireless sensor network, ad hoc network, vehicular network, or moving network

a) Translate network layer protocols or locatorsb) Obtain MH’s [ID, LOC]c) update the [ID, LOC] mappings of IDRs

[ID, LOC] of MH, CH, GW_CN

a) Accept the registration from the hosts in the domainb) Relay CH’s query to MH

[hostname, ID, LOC, secur. key]

of all hosts

12

backbone networks of Internet service providers (ISPs)

13

DNRs, IDRs, AAA svr, policy control, network configuration, QoS control etc.

Similar to DNSa) Accept HNR’s registrationb) Answer CH’s HNR-query

[hostname, ID, LOC] of HNRs

a) Accept updates for [ID, LOC] of hosts from gatewaysb) help the network to adapt to changes in network conditions and mobilityc) Fault tolerant for gateways

*[ID, LOC] of active hosts; *[ID, LOC] of the MH, CH,

GW_HN, GW_CN of a session

14

Identity Sublayer in Protocol Stack• Use a identity sublayer to map host IDs locators

– between the transport and network layers• similar to that of the HIP identity layer

– separates the transport and upper layers, from the network layer• host IDs are used for host or session identification• locators are used for finding host location and forwarding packets through the

network.

• Attach an identity header to both data and control packets– HIP attaches the HIP header only to control packets and the IPsec header

to data packets.

• Use IPsec or cryptographic security mechanisms only when the applications require them.– IPsec is mandatory for HIP implementation.

15

Communication Process

GW translation

(Lightweight)GW translation

16

Mobility Support

• Proactive mode

1

Request to transfer MH’s info (MH, CH, GWs) to GW_FN

2

a) movement detectedb) buffer pkt destined to MH

1

17

• Proactive mode (cont.)

a) obtains a new LOCb) informs the GW_FN

2

Updates MH’s new LOC and GW_FN

3

18

• Proactive mode (cont.)

flush buffer4

Updates MH’s new LOC. May be by the MH itself

5

19

Multihoming Support

• host multihoming – a host has two or more interfaces connected to the same or

different edge networks– hosts exchange lists of their available locators

• the preferred locator is that used for default communication.

– Whenever the host wants to change its preferred locator, • it sends a locator update request to the peer host. • Upon receiving the message, the CH or gateway replies a locator update

response and uses the new default locator as the destination locator.

20

• site multihoming – an edge network is connected to multiple ISPs through one or

more gateways– The gateways exchange their available locators via the IDR

network• assign different destination locators to outgoing packets for forwarding

the packets through different ISP networks• can also change the source locator of outgoing packets in order to

receive the response packets through a preferred link.

21

Scalable Routing

• allowing the use of different locator spaces in the edge networks and the global transit network

• the growth of the global routing table can be controlled – fewer global locators need to be stored in the routing table

22

Implementation

• Basic components are implemented on Linux.• New application program interfaces (API) – identify sockets by using IDs, instead of IP addresses

23

• IDR functions and gateway functions are implemented in the same physical node

• the hostname resolution took approximately 280 ms• The RTT for data communication between host 1 and host 3 was 2.8 ms.

– The change in the RTT was insignificant (<0.001 ms) when the gateways translated only locators and when they translated the network layer protocols.

• the network layer handover delay was around 12 ms– the mobility of host 1 from edge network 1 to 2, – around 8 ms to prepare and transmit an ID/locator binding update request and – around 4 ms for the request to reach host 3 via the IDRs.

24

Conclusion

• a new naming system is proposed – facilitates efficient hostname resolution in future networks.

• Demonstrate the use of the naming system in the ID/locator split architecture – for supporting mobility, multihoming, and scalable routing.

• In a future study we intend to focus on how the architecture scales. – to evaluate the scalability of the mapping functions at gateways

as well as the scalability of the logical control network • for the secure distribution of the ID/locator mapping information

25

comments

• Separating ID and locator value sets is important for mobility, multihoming, renumbering, and security.

• Proxy Mobile IPv6 is another simple/effective/efficient way to achieve– Can use MSISDN to be the ID– with the reusing of current DNS system (hostname<->HoA

mapping)– No modification on current end hosts

• No new API needs to be developed

– Suitable for Lightweight devices