Mobility Support through Locator/ID Split Architecture

1. Mobility Support through Locator/ID Split Architecture Joon-Suk KANG Graduate School/Faculty of Information Science and Electrical Engineering, Kyushu University jskang@ale.csce.kyushu-u.ac.jp Koji OKAMURA Research Institute for Information Technology Kyushu University oka@ec.kyushu-u.ac.jp

2. 1. Motivation & Introduction • GOAL : Design of a new locator/ID split network architecture that is capable of supporting the mobility and solving the routing scalability problem. • We suggested an address model based on ‘8+8’ concept capable of storing Identifier and Locator information simultaneously and changing locators easily, and achieved efficient management of addresses in the edge network due to separation of the edge network from global IP transit network and increase of routing scalability in global IP transit network.Particularly, we introduced a concept of a location server in order to manage the fast-growing number of mobile host(MH)s and their dynamic movement.

3. 2. Proposed Network Architecture Locator Managing System (LMS) : LNP-to-GNP mapping Addressing Architecture for Mobility Support (AAMS) This architecture separates the naming and routing in edge networks from the global IP transit network. - Provider independent addresses are used in each edge network. - Every local IP address used in an edge network is locally routable only in the edge network. - End hosts in an edge network communicate with end hosts in different edge network through the global IP transit network. In this case, the local IP address must be translated into a global IP address in the global IP transit network. e HLT (EHID-to-LNP mapping) Policy Manager (PM) Edge Router (ER) ER MH Cache(LNP-to-GNP) Global IP Transit Network (Backbone Network) Cache(LNP-to-GNP) MH Edge Network Edge Network Expanded DNS: EHID-to-LocatorServer LocatorServer(LS): EHID-to-LNP d LoCation Managing System (LCMS) : EHID-to-LNP mapping

4. Address Model Reusing the conventional IPv6 address architecture to support backward-compatibility. • Addressing Method • Sending and receiving procedure in end hosts. Sending Receiving - The AAMS prefix value is a constant value. - Each end host has the Prefix- EHID mapping cache which keeps the mapping between an EHID and a network prefix value. - Upon the movement of the mobile host(MH) though a network prefix value is changed, the transport layer and the application keep the same address. AAMS Prefix EHID AAMS Prefix EHID Transport Layer AAMS Prefix EHID AAMS Prefix EHID Prefix-EHIDmapping AAMS Prefix EHID Network Prefix EHID Prefix-EHIDmapping Network Prefix EHID Network Prefix EHID Network Layer Date Link Layer - We call the address consisting of EHID and AAMS prefix the “AAMS-HID”, where EHID is managed by converting EHID to AAMS-HID type in the AAMS network.

5. 3. Communication Procedures HLT • 2. host-location registration request(to register the MH's domain name and position to the LCMS. A MH can specify a specific LS). • 3. After choosing proper location server, the ER forwards the received request to the server. The requested server stores the AAMS-HID of the MH and the allocated LNP. • 6. ER adds the AAMS-HID of the MH and the allocated LNP to the HLT. LSEHID-to-LNP 6 • Address Registration 3 DNSEHID-to-LS ER 4. DNS registration 2. HL registrationrequest 1. LNP 5. LS’s address MH • Address Query and Communication • 1. DNS resolution request • 2. DNS lookup(MH1’s AAMS-HID and the LS's IP) • 3. Quering about the LNPs of MH1, • 4. MH1's local IP address • 5. Acquiring the GNP(using the LNP list of MH 1) • 7. Data packets(the local IP address of MH1) • 8. Address translation • 10. Address translation

6. Cache • Mobility Support LMS Edge Network A (6) • 5. Once ER C receives MH1’s previous LNP(ER A), ER C informs ER A that the location of MH1 is changed • 6. ER A erases information of MH1 from the HLT of the edge network A(ER A keeps MH1’s information and ER C’s information as a cache.) • 7. Packets destined to MH1 • 8. ER A forwards the packet into the ER C • 9. INFO_GNP_MODIFIED message(to inform ER B that the location of MH1 was changed) HLT ER B (7) Packets(for MH1) (6) (11) (9) INFO_GNP_MODIFIED (MH1’EHID, MH1’LNP, | EN C’s GNP) (10) ER A (8) MH2 (5) ER C Edge Network B (1) (4) LNP_Update_request (3) LNP_update_request (LS’s IP) (2)LNP LocatorServer: EHID-to-LNP MH1 Edge Network C • 10. ER B that receives the message updates its cache server with new information • 11. INFO_LC_CHANGED to MH2(to inform MH2 that MH1’s locator was changed)

7. 4. Performance Evaluations • Simulator • A simulator was implemented using Perl language. • We construct the network topology of the edge network and global IP transit network by using the link attributes and the topology information based on the network snap shot offered by iPlane project. • LMS data base is implemented by adjusting some of LISP-ALT protocol. • We referred the coreSim simulator and the LISP-ALT module to implement the network topology using the data offered by iPlane project. • Simulation Results • Initial Latency • The average LMS lookup delay is 430ms. • The average Signaling delay is 291ms • The average total initial latency is 721ms. Total initial latency LMS lookup delay Signalling delay

8. Handover Latency • The average LMS lookup delay is 398ms. • The average Signaling delay is 275ms • The average total handover latency is 673ms. 5. Conclusions Total handover latency LMS lookup delay Signalling delay • We proposed a new naming system to split an address into separate Identifier and Locator and a network architecture. • The proposed architecture suggests a separate location server as a method for managing location of the MH through separation from DNS, so it allows it to detect and apply the location in real time, even though the state of MHs is rapidly and dynamically changed. Moreover, a series of operations for management of handover are managed by ERs, thus it reduces loads of a MH. • It is possible to prevent increase of BGP routing table in the backbone network, because the routing of edge networks is separated from that of global IP transit network and the routing table stores only GNP prefix set. • It is possible to avoid address renumbering overhead due to ISP changes.