1 / 25

An ID/locator split architecture for future networks

IEEE Communications Magazine, vol. 48, no. 2, pp. 138-144, 2010. An ID/locator split architecture for future networks. Ved P. Kafle , Hideki Otsuki , and Masugi Inoue, National Institute of Information and Communications Technology. Introduction .

yvonne
Télécharger la présentation

An ID/locator split architecture for future networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE Communications Magazine, vol. 48, no. 2, pp. 138-144, 2010. An ID/locator split architecture for future networks Ved P. Kafle, Hideki Otsuki, and Masugi Inoue, National Institute of Information and Communications Technology

  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.

  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. from http://www.shim6.org/ [7] E. Nordmark and M. Bagnulo, “Shim6: Level 3 Multi-homing Shim Protocol for IPv6,” RFC 5533, June 2009.

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

  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 Figure from http://www.ietf.org/proceedings/70/slides/RRG-7.pdf [10] D. Farinacci et al., “Locator/ID Separation Protocol (LISP),” Internet draft, Sept. 2009; draft-ietf-lisp-05.txt

  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 Used to aggregate host IDs that refer to a specific context and simplify their resolution. SHA1 or MD5 etc. Whether this ID is private, public, local, or global.

  11. Proposed Network Architecture [hostname, ID, LOC, secur. key] of all hosts [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) Translate network layer protocols or locatorsb) Obtain MH’s [ID, LOC] c) update the [ID, LOC] mappings of IDRs wireless sensor network, ad hoc network, vehicular network, or moving network

  12. backbone networks of Internet service providers (ISPs)

  13. DNRs, IDRs, AAA svr, policy control, network configuration, QoS control etc. Similar to DNS a) Accept HNR’s registrationb) Answer CH’s HNR-query 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 [hostname, ID, LOC] of HNRs *[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 2 Request to transfer MH’s info (MH, CH, GWs) to GW_FN 1 a) movement detected b) buffer pkt destined to MH 1

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

  18. Proactive mode (cont.) 5 Updates MH’s new LOC. May be by the MH itself 4 flush buffer

  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

More Related