1. An ID/locator split architecture for future networks Ved P. Kafle, Hideki Otsuki, and Masugi Inoue, National Institute of Information and Communications Technology 1 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 addresses the 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. 2

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. 3 [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. 4

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. 5 [7] E. Nordmark and M. Bagnulo, “Shim6: Level 3 Multi-homing Shim Protocol for IPv6,” RFC 5533, June 2009. from http://www.shim6.org/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. 6 [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. 7 [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 8 [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/s lides/RRG-7.pdf http://www.ietf.org/proceedings/70/s lides/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. 9

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 10 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 11 wireless sensor network, ad hoc network, vehicular network, or moving network a) Translate network layer protocols or locators b) Obtain MH’s [ID, LOC] c) update the [ID, LOC] mappings of IDRs a) Translate network layer protocols or locators b) 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 domain b) Relay CH’s query to MH a) Accept the registration from the hosts in the domain b) Relay CH’s query to MH [hostname, ID, LOC, secur. key] of all hosts

12. 12 backbone networks of Internet service providers (ISPs)

13. 13 DNRs, IDRs, AAA svr, policy control, network configuration, QoS control etc. Similar to DNS a) Accept HNR’s registration b) Answer CH’s HNR-query Similar to DNS a) Accept HNR’s registration b) Answer CH’s HNR-query [hostname, ID, LOC] of HNRs a) Accept updates for [ID, LOC] of hosts from gateways b) help the network to adapt to changes in network conditions and mobility c) Fault tolerant for gateways a) Accept updates for [ID, LOC] of hosts from gateways b) help the network to adapt to changes in network conditions and mobility c) 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. 14

15. Communication Process 15 GW translation (Lightweight) GW translation

16. Mobility Support Proactive mode 16 1 Request to transfer MH’s info (MH, CH, GWs) to GW_FN 2 a) movement detected b) buffer pkt destined to MH 1

17. Proactive mode (cont.) 17 a) obtains a new LOC b) informs the GW_FN 2 Updates MH’s new LOC and GW_FN 3

18. Proactive mode (cont.) 18 flush buffer 4 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. 19

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. 20

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 21

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

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. 23

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 24

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 25