Network Working Group Hongke Zhang Internet Draft Feng Qiu Expires: March 2013 Huachun Zhou Xiaoqian Li Fei Song September 4, 2012 A Distributed Mobility Management Solution in LISP networks draft-zhang-dmm-lisp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 4, 2013. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this Zhang et al. Expires March 4, 2013 [Page 1] Internet-Draft dmm-lisp September 2012 document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract In traditional Internet architectures, current centralized mobility management solutions face scalability issues due to the creation of network bottlenecks and a single mobility agent of failures. To address these issues, we propose a Distributed Mobility Management solution in Locator/ID Separation Protocol (DMMLISP). We divide the network into many domains according to the area of Autonomous Systems (ASs). Each domain consists of a Mapping Server and several Tunnel Routers (xTRs). The Mapping Server stores global mappings between EID (Endpoint Identifier) prefixes and AS Numbers (ASNs) to lookup the mobile nodes'(MNs') home domain. Meanwhile, the Mapping Server also contains ASN-to-xTR mappings so that it can forward Map- Register and Map-Request messages to any xTR of the MN's home domain, thus enhancing reliability. In addition, the xTRs in each domain constitute one-hop DHT (Distributed Hash Table). Moreover, any xTR in the MN's home domain may be the home agent of MNs, and the MNs' EID-to-RLOC (Routing Locator) mapping is stored in two xTRs using two hash functions. In this way, it not only supports quick lookup but also improves scalability and survivability. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 0. Table of Contents 1. Introduction ................................................ 3 2. Definition of items ......................................... 4 3. A distributed mobility management in LISP networks ...........6 3.1. The architecture of DMMLISP .............................6 3.2. Host mobility .......................................... 8 3.3. Call delivery procedure................................. 9 4. Properties of DMMLISP .......................................10 4.1. Optimize path ......................................... 10 4.2. Split the signaling and the data .......................10 4.3. Improve survivability.................................. 10 4.4. Hide location information of MNs .......................11 4.5. Network-based mobility management ......................11 4.6. Support routing scalability ............................11 Zhang et al. Expires March 4, 2013 [Page 2] Internet-Draft dmm-lisp September 2012 5. Security Considerations..................................... 11 6. IANA Considerations ........................................ 11 7. Acknowledgments ............................................ 11 8. References ................................................. 12 Author's Addresses ............................................ 12 Acknowledgment ................................................ 13 1. Introduction The conventional Internet does not natively support mobility because IP addresses are used as both host identifiers and locators. Many solutions based on the current Internet have been specified to support mobility. Mobile IPv6 (MIPv6) [MIPv6] as a host-based mobility protocol requires that an MN uses a Home Address (HoA) to indicate its identifier and a Care of Address (CoA) to represent its location information. A home agent (HA) as a location manager maintains HoA-to-CoA mappings and takes charge of forwarding data traffic for MNs. Proxy Mobile IPv6 (PMIPv6) [PMIPv6] is a network- based mobility protocol in which a Local Mobility Anchor (LMA) provides a prefix for an MN as its identifier. The IP address of a Mobile Access Gateway (MAG) is used as the location of an MN, and the LMA keeps the mapping between the MN's prefix and the serving MAG address. In this way, whenever mobility events occur, the HoA or the MN's prefix is unchanged, so it can keep transport connections alive. However, a HA and a LMA can be viewed as centralized mobility agents. All traffic to MNs associated with the HA or the LMA is routed through their agent. Such a centralized mobility solution has some issues [Problem-dmm]. First, when a single mobility agent generally serves a large number of MNs, it becomes a potential bottleneck because all the traffic from and towards an MN has to go through the centralized mobility agent. Second, a centralized mobility agent often results in a non-optimal path. An MN and a correspondent node (CN) may be close to each other but be both far from the mobility agent. Packets destined to the MN need to be forwarded via the mobility agent, which is not the shortest path. If the CoA of an MN is given to the CN in MIPv6 Route Optimization (RO) mode, the location privacy of the MN will be not protected. And we can not expect RO capabilities to exist at each CN. Third, malicious MNs can attack HAs or LMAs directly (e.g. MNs send a large mount of data traffic), so it can bring insecure factors and a single point of failures is more vulnerable. Finally, the current Internet faces serious scaling problems. MIPv6 and PMIPv6 which develop based on the traditional TCP/IP are not suitable for an increasing demand for future Internet scalability. Zhang et al. Expires March 4, 2013 [Page 3] Internet-Draft dmm-lisp September 2012 To address the above issues, we propose a Distributed Mobility Management in Locator/ID Separation Protocol (DMMLISP), which can improve scalability and survivability of the network. When an MN crosses different subnets, it only changes its RLOC but its EID used by the transport layer's connection is invariable, so it can offer services connectivity and support global roaming [MILSA]. A Tunnel Router (xTR) receives packets from sites on one side [LISP] and encapsulates them with RLOCs toward the Internet on the other side, so routers in the core networks only need to maintain RLOCs, which addresses routing scalability problems [Report-RoutingAddressing]. Meanwhile, we separate the signaling and data planes by introducing the mapping system as an overlay architecture to deliver signaling messages, which avoids evil MNs attacking map servers (MSs) [LISP-MS] directly. In addition, we divide the Internet into different domains according to the coverage area of Autonomous Systems (ASs). Each domain is managed by an MS who takes charge of forwarding Map- Request and Map-Register messages for xTRs by storing the global EID-prefix-to-ASN (AS number) and ASN-to-xTR mappings. In this way, even if one MS break down, other MSs can substitute it. In addition, xTRs are distributed in different sites so that packets may be routed via a nearby router. In this way, all the data between two xTRs near to hosts can be transited on the shortest path. Hence, it can help reduce the delay and overhead. Meanwhile, the xTRs in each domain constitute one-hop DHT (Distributed Hash Table). We store the MN's EID-to-RLOC mappings in two xTRs, avoiding a single point of failures. 2. Definition of items Autonomous System (AS): Within the Internet, an autonomous system is a collection of connected IP routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. See [LISP] for details. Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs Zhang et al. Expires March 4, 2013 [Page 4] Internet-Draft dmm-lisp September 2012 are numbered based on the connectivity of provider networks. See [LISP] for details. EID-prefix: An EID-prefix is a power-of-two block of EIDs which are allocated to a site by an address allocation authority. EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID-prefix. EID-to-RLOC mapping: a binding between an EID or EID-prefix and a RLOC set which can be used to reach the EID. The xTRs can encapsulate packets with the RLOC in the EID-to-RLOC mapping to reach the destination EID. A RLOC set may contain multiple RLOCs to perform multihoming or traffic engineering. Ingress Tunnel Router (ITR): An ITR accepts an IP packet and prepends an "outer" header with RLOCs. It sends a Map-request to the mapping system when it does not have the EID-to-RLOC mapping for the destination EID. Egress Tunnel Router (ETR): An ETR accepts packets with the RLOCs as the destination addresses. It strips the outer header and forwards packets based on EIDs. xTR: A xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Mapping Server (MS): A Mapping Server is a component, which stores the EID-prefix-to-ASN and ASN-to-xTR mappings. The MS forwards Map- Register or Map-Request messages to xTRs. Mapping Domain (MD): This document defines the area that a Mapping Server covers as a Mapping Domain. EID-prefix-to-ASN mapping: It indicates which AS EID-prefix belongs to. ASN-to-xTR mapping: A binding between ASN and the xTR, which is one- to-many relationship. Zhang et al. Expires March 4, 2013 [Page 5] Internet-Draft dmm-lisp September 2012 3. A distributed mobility management in LISP networks 3.1. The architecture of DMMLISP +-------------------------------------------------+ | Mapping +----+ +----+ | | System | MS |------------ | MS | | | +----+ +----+ | | | | | | | | | | +----+ +----+ | | | MS |------------ | MS | | | +----+ +----+ | | / \ | | ----------/----------------------\------------- | | MD1 / | MD2 \ | | +----+ +----+ | +---+ +---+ | | -|HxTR|----|DxTR|-- | --|xTR|----|xTR|-- | | |+----+ +----+ | | | +---+ +---+ | | | | | | | | | |+----+ +---+ | +---+ +---+ | ||HxTR| |xTR| | |xTR| |xTR| | |+----+ +---+ | +---+ +---+ | | | | | | | | | | +---+ +----+ | | |+----+ +----+ | | | --|xTR|---|xTR1|-- | -|xTR2|---|CxTR|-- | | +---+ +----+ | +----+ +----+ | | | | | | | +----+ | +----+ | | | MN | | | CN | | | +----+ | +----+ | | | | +-------------------------------------------------+ Figure 1 :Architecture of DMMLISP Figure 1 shows the architecture of DMMLISP, which is divided into different domains according to the coverage area of the AS. Each domain is managed by an MS who stores EID-prefix-to-ASN and ASN-to- xTR mappings. All the xTRs in the same AS constitute one-hop DHT and maintain EID-to-RLOC mappings. Each xTR collects local EID-prefixes and notifies these prefixes to the associated MS. MSs advertise their EID-prefix-to-ASN mappings each other through BGP (Border Gateway Protocol) extension, so each MS can know global EID-prefixes. In this way, it is possible to aggregate local prefixes efficiently in an AS so that it can alleviate the stored overload in the MS. Moreover, the change of the Zhang et al. Expires March 4, 2013 [Page 6] Internet-Draft dmm-lisp September 2012 topology within an AS does not impact on the mappings between EID- prefix-to-ASN mappings in other MSs. Thus, the mapping system is more scalability and stable. In addition, the MS also maintains the ASN-to-xTR mappings, which is one-to-many relationship. When the MS receives Map-Register or Map- Request messages, it randomly selects one of xTRs as the destination xTR (DxTR) and forwards these messages to the DxTR. Even if the DxTR fails, any other xTRs in the destination AS can replace it by reselecting other DxTRs. Hence, it enhances the survivability of DMMLISP. There are two ways to replace a broken MS. One way is that MSs use BGP (Border Gateway Protocol), which entablishes on TCP. If one MS breaks down, the peer MS can detect that the TCP connection is broken and replaces the broken MS. Because each MS maintains ASN-to- xTR mappings, the peer MS can notify all the xTRs in the AS of the broken MS. In this way, the MS can replace the broken MS. Another way is we replicate an MS in each AS. One MS is primary and the other is for backup. We deploy one-hop DHT ring in each AS. Any xTRs in the DHT ring may be the agent of MNs, which inherits the advantages on scalability and robustness of the DHT-based infrastructure. We store the MN's EID-to-RLOC mapping in two xTRs. The DxTR uses different hash functions to map the MN's EID to two home xTRs (HxTR) in order to avoid a single point of failures. Hence, it can enhance the survivability of the mobile network. The operations in detail are described in the following sections. Zhang et al. Expires March 4, 2013 [Page 7] Internet-Draft dmm-lisp September 2012 3.2. Host mobility +--+ +----+ +----+ +--+ +----+ +----+ +----+ |MN| |xTR1| |xTR2| |MS| |DxTR| |HxTR| |CxTR| +--+ +----+ +----+ +--+ +----+ +----+ +----+ | |-handover->| | | | | |<--1-Attachment---->| | | | | | | | 2 Map- | | | | | | |Register->| | | | | | | |3 Map- | | | | | | |Register->| | | | | | | |4 Map- | | | | | | |Register->| | | | 5 Map- | | | | | | | <-Update- | | | | | | | | | | | | | |-------------------6 Map--Update-------------------->| | | | | | | | Figure 2 : Host Mobility Scenario Fig. 2 illustrates the message flows for host mobility. When an MN moves from the coverage area of the xTR1 to the xTR2, it connects to the xTR2 (Message 1). Then, the xTR2 checks whether the EID belongs to its local AS or not. If yes, it indicates that this AS is the home domain of the MN. The xTR2 hashes the EID to find its HxTR and updates the MN's EID-to-RLOC mapping in the HxTR. If not, it indicates that the MN has left its home domain, the xTR2 sends a Map-Register message to its local MS (Message 2). Each MS stores two tables: an EID-prefix-to-ASN table and an ASN-to- xTR table. When receiving a Map-Register message, the MS lookups the EID-prefix-to-ASN table to obtain the MN's home AS number. Then, it lookups the ASN-to-xTR table and randomly chooses one xTR as the DxTR. After that, the MS forwards the Map-Register message to the DxTR (Message 3). Once receiving the Map-Register message, the DxTR uses the MN's EID as a key and hashes it in order to obtain the MN's HxTR. The HxTR stores the mapping between the EID and the RLOC. To improve the survivability of the system, we use two Hash functions and store the EID-to-RLOC mapping in two HxTRs (Message 4). Even if one HxTR breaks down, the other can replace it and respond to the Map-Request message. In addition, the xTR2 sends a location update message to the xTR1 (message 5) including the new MN's EID-to-RLOC mapping. Then, xTR1 sends a message to the correspondent's xTRs (CxTR) in order to Zhang et al. Expires March 4, 2013 [Page 8] Internet-Draft dmm-lisp September 2012 update the new MN's mapping information in the CxTR's mapping table (message 6). Once the CxTR obtains the new mapping, packets destined to the MN are directly forwarded to the xTR2, so that it is not necessary to pass through the old xTR1. Thus, the scheme can achieve route optimization. 3.3. Call delivery procedure Fig. 3 illustrates the message flows for the call delivery procedure. When a CN wants to communicate with an MN, it sends packets to the CxTR using its EID and the MN's EID as the packets's source address and destination address (Message 1). The CxTR checks whether the EID belongs to the local AS. If the MN's home domain and the CxTR are different, the CxTR sends a Map-Request message to the associated MS (Message 2). The MS lookups the EID-prefix-to-ASN table and obtains the home AS of the MN. Then, the MS lookups the ASN-to-xTR table in order to find one of its home domain's DxTRs, and forwards the Map- Request message to the DxTR (Message 3). If the MS does not receive the response message of the DxTR, it will choose another DxTR and send the Map-Request message to the DxTR. As long as one DxTR of the MN's home domain is active, the signalling can be forwarded to the DxTR. In this way, the survivability of the system is enhanced. The DxTR randomly selects one of two hash functions to find the MN's HxTR and then forwards the Map-Request message to it (Message 4). The HxTR responds to a Map-Reply Message including the EID-to-RLOC mapping to the CxTR (Message 5). Then, the CxTR encapsulates packets with RLOCs and sends them to the xTR which the MN attaches to. When receiving packets, the xTR of the MN strips the encapsulated header and forwards them to the MN (Message 6). Zhang et al. Expires March 4, 2013 [Page 9] Internet-Draft dmm-lisp September 2012 +--+ +----+ +---+ +----+ +--+ +----+ +----+ |MN| |xTR2| |HTR| |DxTR| |MS| |CxTR| | CN | +--+ +----+ +---+ +----+ +--+ +----+ +----+ | | | | | | | | | | | | |1<=Packets=| | | | | | | | | | | | | 2 Map- | | | | | | |<-Request| | | | | | 3 Map- | | | | | | |<-Request| | | | | | 4 Map- | | | | | | |<-Request | | | | | | |---------5 Map--Reply-------->| | | | | | | | | |6 <=====|<===============Packets===================| | Figure 3 : Call delivery procedure 4. Properties of DMMLISP 4.1. Optimize path In PMIPv6 and MIPv6, the LMA or the HA is required to deliver data packets and they as location managers need to encapsulate packets. In DMMLISP, xTRs are distributed in different access networks so that data packets may be routed via a nearby xTR without passing through MSs. In this way, compared to PMIPv6 and MIPv6, there is not an extra encapsulated overhead on location managers. Moreover, the data transmission delay can be reduced. 4.2. Split the signaling and the data The mapping system as an overlay architecture on the top of the Internet is used to deliver signaling messages. The mapping system consists of many MSs who manage mobility-related signaling. Meanwhile, the locator/ID separation avoids evil MNs sending a great many data to MSs. Thus, it can offer better controllability, manageability and security. 4.3. Improve survivability Each MS stores the global EID-prefix-to-ASN mappings. In this way, even if one MS breaks down, other MSs can replace its function to Zhang et al. Expires March 4, 2013 [Page 10] Internet-Draft dmm-lisp September 2012 forward Map-Request and Map-Register messages. In addition, we store the MN's EID-to-RLOC mapping in two HxTRs via two hash functions, so the HxTR is also alternative. Thus, our scheme can enhance the survivability of DMMLISP. 4.4. Hide location information of MNs In LISP networks, a CN only knows the MN's identifier but location information of the MN is hidden to the CN, which avoids malicious CNs attacking MNs directly. 4.5. Network-based mobility management The MN is not required to participate in any mobility-related signaling, so the proposed scheme avoids a part of signaling overhead in wireless links and makes use of wireless resources efficiently. Moreover, our network-based mobility management solution does not require any modification on the MNs. 4.6. Support routing scalability One of aims for the Locator/ID separation solution is to support routing scalability by removing hosts' EIDs from core routers in the current routing system. After packets which are sent by a host arrive at an xTR, they are encapsulated with RLOCs and then are forwarded to its destination xTR. We design a distributed mobility management solution based on LISP which does not damage the architecture and can solve both global routing scalability problems and mobility support. 5. Security Considerations TBD 6. IANA Considerations This document makes no request of the IANA. 7. Acknowledgments Zhang et al. Expires March 4, 2013 [Page 11] Internet-Draft dmm-lisp September 2012 8. References [MIPv6] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, RFC 3775, 2004. [PMIPv6] Sri G, Kent L, Vijay D, Kuntal C, Basavaraj P. Proxy Mobile IPv6, RFC 5213, 2008. [LISP] Dino F, Vince F, Dave M, Darrel L, Locator/ID Separation Protocol (LISP), Internet draft, draft-ietf-lisp-22, February 2012. [Problem-dmm] H Anthony C. Requirements of Distributed Mobility Management, IETF Internet draft-chan-dmm-requirements-00, 2012. [MILSA] Jianli P, Raj J, Subharthi P, Chakchai S. MILSA: A New Evolutionary Architecture for Scalability, Mobility, and Multihoming in the Future Internet, IEEE Journal on Selected Areas in Communications, 2010;28(8):1344-1361. [Report-RoutingAddressing] David M, Lixia Z, Kevin F. Report from the IAB Workshop on Routing and Addressing, IETF RFC 4984, 2007. [LISP-MS] Vince F, Dino F. LISP Map Server Interface, IETF Internet draft-ietf-lisp-ms-16, 2012. Author's Addresses Hongke Zhang, Feng Qiu, Huachun Zhou, Xiaoqian Li, Fei Song National Engineering Laboratory for Next Generation Internet Interconnection Devices School of Electronics and Information Engineering Beijing Jiaotong University of China Phone: +86 01051685677 hkzhang@bjtu.edu.cn 07111019@bjtu.edu.cn hczhou@bjtu.edu.cn Zhang et al. Expires March 4, 2013 [Page 12] Internet-Draft dmm-lisp September 2012 xiaoqianli@bjtu.edu.cn fsong@bjtu.edu.cn Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang et al. Expires March 4, 2013 [Page 13]