DMM Working Group M. Liebsch Internet-Draft NEC Intended status: Standards Track March 13, 2012 Expires: September 14, 2012 Per-Host Locators for Distributed Mobility Management draft-liebsch-mext-dmm-nat-phl-01.txt Abstract Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. In scope of a solution for Distributed Mobility Management is the maintenance of IP sessions and IP address continuity when mobile nodes get a new mobility anchor assigned during handover. This document proposes the use of identifier-locator split concepts to achieve optimal routing of data packets to a mobile node's current mobility anchor. The use of per-host locator IP addresses allows translation of addresses within the mobile operator network to route packets to the mobile node's current mobility anchor, while address translation is kept transparent to the communication endpoints. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 14, 2012. Copyright Notice Copyright (c) 2012 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 Liebsch Expires September 14, 2012 [Page 1] Internet-Draft DMM per-host locator March 2012 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Routing Plane Considerations of DMM . . . . . . . . . . . . . 5 4. Use of NATs and per-host locators . . . . . . . . . . . . . . 8 5. Ascertaining of an MN's current anchor . . . . . . . . . . . . 10 5.1. Resolving an MN's Locator State at a Router . . . . . . . 10 5.2. Maintenance of an MN's Locator State at a Router . . . . . 12 6. Function of the DMM Ingress Router . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Liebsch Expires September 14, 2012 [Page 2] Internet-Draft DMM per-host locator March 2012 1. Introduction The concept of Distributed Mobility Management (DMM) in based on the distribution of mobility anchors towards the access networks to provide mobile nodes with local anchors and enable optimal routing of traffic above anchor level to any kind of serving point, e.g. distributed content caches. The closer mobility anchors are located to mobile nodes, the more a mobile node's handover may necessitate the assignment of a new mobility anchor. Continuity of a mobile node's IP address or IP address prefix enables IP session continuity, but creates the problem of routing downlink packets to the mobile node's current mobility anchor. Different solutions and associated extensions to IP mobility management protocols are being considered to maintain a mobile node's IP session after mobility anchor relocation. The solution for DMM as described in this document adopts the concept of an identifier-locator split to solve the routing above anchor level and enable optimal routes to the mobile node's current mobility anchor. Whereas the mobile node's Home Network Prefix (HNP) or Home Address is treated solely as identifier after mobility anchor relocation, the mobile node's current mobility anchor represents the locator. The proposed solution assumes distributed DMM Ingress Routers (IR) which resolve the MN's identifier into a locator address in case they have to forward data traffic to a mobile node. The mobile node's current mobility anchor serves as Egress Router (ER). Between the IR and ER, the existing routing or switching plane in the mobile operator network is in use. Instead of using encapsulation to tunnel packets between an IR and the ER, per-host locator addresses are used to network address translate (NAT) downlink packets at the IR(s) and route packets to the mobile node's anchor. Locator addresses are overloaded to carry identifier information, which allows the ER to reverse address translate the packet's destination address into the mobile node's identifier (HNP or Home Address) as assigned by the initial mobility anchor. The proposed approach to solve DMM in the routing plane above mobility anchor level implies no dependency on the IP mobility protocol below anchors and requires no changes to the routing infrastructure, as standard routing and associated table entries can be used. The introduced Ingress Router is represented by a regular router with the capability of performing pre-routing NAT to make use of a routable host address and to achieve that the data packet arrives at the mobile node's current mobility anchor using the most suitable route. Liebsch Expires September 14, 2012 [Page 3] Internet-Draft DMM per-host locator March 2012 2. Conventions and Terminology 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 [RFC2119]. Liebsch Expires September 14, 2012 [Page 4] Internet-Draft DMM per-host locator March 2012 3. Routing Plane Considerations of DMM The problem of routing downlink packets to the mobile node's current mobility anchor after anchor relocation is depicted in Figure 1. The MN initially attaches to a Mobility Anchor (MA) and gets assigned an HNP from this MA's prefix pool in case Proxy Mobile IPv6 is used as mobility management protocol below MAs. In case Mobile IPv6 is used, the initial MA assigns a Home Address to the MN. In the following description, PMIPv6 is assumed, whereas the proposed solution for DMM is independent of the mobility management protocol. The MN's initial anchor is denoted as previous MA (pMA), whereas the new anchor is denoted as new MA (nMA) The following symbolic notation of IP addresses is used: [Prefix]:: [Suffix]. +--+ |CN| +--+ : :data, dest. address A:1::1 : V ?? Mobile Operator Routing Plane PFX A:x:: PFX B:x:: +----+ +----+ |pMA | |nMA | +----+ +----+ |pAR/| |nAR/| |pMAG| |nMAG| +----+ +----+ . / . +--+ / . |MN|/ +--+ A:1::1 Figure 1: Issue of routing downlink packets after mobility anchor relocation The initial anchor pMA assigns the prefix A:1:: to the MN as a result of the MN's registration. Routers in the mobile operator's core network forward all packets with prefix (PFX) A:x:: towards pMA. As a result of handover, the MN gets a new mobility anchor (nMA) assigned. In case nMA continues anchoring the MN's initially Liebsch Expires September 14, 2012 [Page 5] Internet-Draft DMM per-host locator March 2012 assigned IP address prefix, the DMM solution must enable forwarding of downlink packets to the nMA instead of following the default routing states, which forward all A:x:: prefixes to the pMA. Forwarding of packets from the pMA to the nMA may imply suboptimal routes from the CN. Figure 2 depicts the generic concept of using DMM Ingress Routers (IR) to resolve the MN's HNP into the associated locator address, which is represented by the MN's current MA (nMA). Section 5 comprises exemplary operations of IRs with a mapping system. However, detailed descriptions and recommendations of technology to resolve the locator is not covered in this version of the document. As the nMA serves as locator and ER, the IR can set up a forwarding tunnel to the ER. The inner packet carries the MN's identifier, which allows forwarding of the packet after decapsulation of the tunnel at the ER according to the mobility management protocol supported by the nMA. Liebsch Expires September 14, 2012 [Page 6] Internet-Draft DMM per-host locator March 2012 +--+ |CN| +--+ : :data, dest. address A:1::1 : V +--+ |IR| +--+ A:1::1 is identifier, B:254::254 is locator || ===================|| host route between IR and ER || || VV +----+ +------+ A:254::254|pMA | |nMA/ER| B:254::254 +----+ ++----++ |pAR/| |nAR/| |pMAG| |nMAG| +----+ +----+ . / . +--+ / . |MN|/ +--+ A:1::1 Figure 2: Identifier-Locator split to solve DMM on the routing plane to enable IP address continuity after anchor relocation Since the IR can be topologically far away from the nMA, the solution described in this document is based on address translation instead of using encapsulation between the IR and the ER to save encapsulation overhead. Liebsch Expires September 14, 2012 [Page 7] Internet-Draft DMM per-host locator March 2012 4. Use of NATs and per-host locators Translation of the MN's IP address into the locator address (pMA) implies loosing identifier information, which results in an issue at the ER to reverse address translate the MN's downlink packets into the associated identifier address (HNP, Home Address). Hence, the proposed solution is based on per-host locators instead of referring to the nMA's IP address as locator. Building the per-host locator is intrinsically supported by MAs for IP mobility management and are represented by the HNP or the Home Address respectively. At the nMA, the initially assigned address serves as identifier (HNP_id), whereas the nMA assigns a new HNP to the MN after registration, which is treated as per-host locator (HNP_loc). The HNP_loc is not advertised to the MN for address configuration, but provided to a mapping system, which enables IRs to resolve the HNP_id into an HNP_loc. The reference to a suitable mapping system is out of scope of the current version of this document. A generic view of the operation between IRs and a mapping system is depicted in Section 5. Figure 3 illustrates NATing the downlink packet's destination address at the IR into the HNP_loc. According to local binding information, the nMA can reverse address translate the packet into the original IP address of the MN, which carries the HNP_id prefix. Further forwarding from the nMA is performed according to the used mobility management protocol. Liebsch Expires September 14, 2012 [Page 8] Internet-Draft DMM per-host locator March 2012 +--+ |CN| +--+ : :data, dest. address A:1::1 : V +--+---+ |IR|NAT|--------------+ +--+---+ |data, dest. address B:1::1 | | | V +----+ MN's BCE@pMA: |NAT | MN's BCE@nMA: HNP A:1:: +----+ ++----++ HNP_id A:1:: |pMA | |nMA/ER| HNP_loc B:1:: +----+ ++----++ |pAR/| |nAR/| |pMAG| |nMAG| +----+ /+----+ . / . +--+ / . |MN|/ +--+ A:1::1 Figure 3: Using per-host locators to enable reverse NAT on the MN's current mobility anchor (nMA) Liebsch Expires September 14, 2012 [Page 9] Internet-Draft DMM per-host locator March 2012 5. Ascertaining of an MN's current anchor The routers, which function as DMM Ingress Router for an MN's data traffic, are able to perform pre-routing destination NAT on the traffic downlink path. In case the router has no per-host state for the MN's IP address yet, the router can either forward the data packet according to a longest prefix match and update the route after the MN's IP address has been resolved into the currently valid locator, or the router holds the packet until a per-host state has been established after a query to a mapping system. The proposed approach for DMM assumes the availability of a suitable mapping system, maintaining mappings between MNs' HNP_id and the HNP_loc, which is topologically anchored at the MN's current mobility anchor. Mapping entries are set up and maintained by registration with a mapping system. Routers can query a mapping from the mapping system. Furthermore, the mapping system may maintain a list of routers, who queried a mapping for a particular MN. This enables the mapping system to update these routers, which have a (soft) state for the MN to optimize routing of the MN's packets according to the HNP_loc, after the MN's HNP_id resolves into a new HNP_loc, e.g. after the MN has been assigned a new mobility anchor. Since pushing unsolicited mapping updates to some routers exceeds the function of a mapping database, the following description denotes such mapping system as Mapping Control (MC) function. 5.1. Resolving an MN's Locator State at a Router Figure 4 depicts an exemplary procedure of the registration of the MN's mapping between its HNP_id (A:1::) and the HNP_loc (B:1::) after anchor relocation. The MN's previous mobility anchor (pMA) serves as initial anchor to the MN and has assigned the MN a prefix A:1:: from its available prefix pool (A:x::) (1). After the MN has been changed to a new mobility anchor (nMA), the nMA assigns a per-host prefix to the MN (B:1::) from its available prefix pool (B:x::) (2), which is used as HNP_loc and registered with the mapping control (MC) (3). As soon as a router (Rt1) has to forward packets towards the MN, it can query the MC about an HNP_loc while treating the destination IP address in the packet being sent by the traffic source (S) as HNP_id (4). According to the response, the router (Rt) can perform destination NAT of the packet's HNP_id based destination IP address (A:1::1) to the HNP_loc based address (B:1::1) and forward the packet according to the translated address (6). The MN's current mobility anchor performs reverse address translation of the HNP_loc based IP address to the original HNP_id based IP address (A:1::1). Liebsch Expires September 14, 2012 [Page 10] Internet-Draft DMM per-host locator March 2012 (S) -> Traffic Source (e.g. local cache server) or local IXP A:x:: B:x:: +--+ +---+ +---+ +---+ +---+ +--+ |MN||pMA| |nMA| |Rt1| |Rt2| |MC| +--+ +---+ +---+ +---+ +---+ +--+ | | | | | | +--1)binding---+A:1::1 | | | | anchor | | | | | relocation | | | | | +--2)binding-------------+A:1::1 | | | | |B:1::1 3)Register(A:1::1,B:1::1) | | | |--------------------------------------->| | | | | | | | data to A:1::1<--(S) 4)Resolve(A:1::1)| | | |------------------------->| | | | 5) Response(B:1:.1)| | 7) A:1::1 | 6) B:1::1 |<-------------------------| |<---------------------[NAT]<--------[NAT] | | | | | | | | | | | | Figure 4: Exemplary per-host locator registration and mapping As an alternative, the router (Rt1) can forward the downlink packet towards the MN's initial mobility anchor according to its local routing table using a longest prefix match, as depicted in Figure 4. In parallel, the router (Rt1) can query the HNP_loc for the MN from the MC (4). Such approach avoids holding the MN's downlink packet in a buffer while the MC is contacted. However, the MN's initial anchor (pMA) must ensure that the data packet will be forwarded to the MN's current anchor, for example by holding a state about the MN's mapping (4). The pMA can utilize the same NAT rules as the router (Rt1) and forward the packet to the MN's current anchor according to the address translated HNP_loc based IP address (5). After a completed mapping query (6)(7), the router (Rt1) can perform address translation and route the packet according to its HNP_loc based IP address (8). For any packet, which arrives at the current anchor (nMA) using the HNP_loc address, the nMA translates the packet's destination address back to the original HNP_id based IP address (9). Liebsch Expires September 14, 2012 [Page 11] Internet-Draft DMM per-host locator March 2012 (S) -> Traffic Source (e.g. local cache server) or local IXP A:x:: B:x:: +--+ +---+ +---+ +---+ +---+ +--+ |MN||pMA| |nMA| |Rt1| |Rt2| |MC| +--+ +---+ +---+ +---+ +---+ +--+ | | | | | | +--1)binding---+A:1::1 | | | | anchor | | | | | relocation | | | | | +--2)binding-------------+A:1::1 | | | | |B:1::1 3)Register(A:1::1,B:1::1) | | | |--------------------------------------->| | | 4)Notify(A:1::1,B:1::1) | | |<-------------------------------------------------| | | | | | | | 5) | data to A:1::1<--(S) | | |<----------------------| 6)Resolve(A:1::1) | | [NAT]------>| |------------------------->| |<---------------------[NAT] | 7)Response(B:1::1)| | | | |<-------------------------| | | | | | | 9) A:1::1 | 8) B:1::1 |<---(S) | |<---------------------[NAT]<--------[NAT] | | | | | | | | | Figure 5: Exemplary per-host locator registration and mapping with fast forward 5.2. Maintenance of an MN's Locator State at a Router After anchor relocation, the MN's current mobility anchor binds the MN's HNP_id based prefix (A:1::) as well the HNP_loc based prefix (B:1::) to the MN's registration (1), as depicted in Figure 6. The MN has two active IP sessions from different sources (S), whose downlink packets are directed to the MN's current mobility anchor by different routers (Rt1)(Rt2), which function as DMM Ingress Routers. After the MN has been assigned a new mobility anchor (nMA), the MN receives an updated HNP_loc from the nMA's prefix pool (C:1::), which is then registered with the MC (3). The MC updates the routers, which maintain a mapping (soft) state for the MN (4). This results in a translation of the packets' downlink address into a locator, which is based on the HNP_loc assigned by the nMA (5). Liebsch Expires September 14, 2012 [Page 12] Internet-Draft DMM per-host locator March 2012 (S) -> Traffic Source (e.g. local cache server) or local IXP B:x:: C:x:: +--+ +---+ +---+ +---+ +---+ +--+ |MN||pMA| |nMA| |Rt1| |Rt2| |MC| +--+ +---+ +---+ +---+ +---+ +--+ | 1) | | | | | +--------------+A:1::1, | | | | | |B:1::1 | 2) | | | |<-----------[NAT]<----------------[NAT]<--(S) | | |<-----------[NAT]<--------------------------[NAT]<---(S) | | | | | | | anchor | | | | | relocation | | | | | +----binding-------------+A:1::1 | | | | |C:1::1 3) Register(A:1::1,C:1::1) | | | |-------------------------------------->| | | | |<--------------------------| | | | | 4)Notify(A:1::1,C:1::1) | | | | 5) | |<----------------| |<---------------------[NAT]<------[NAT]<--(S) | | |<---------------------[NAT]<----------------[NAT]---(S) | | | | | | | | | | | | | Figure 6: Exemplary per-host locator update Liebsch Expires September 14, 2012 [Page 13] Internet-Draft DMM per-host locator March 2012 6. Function of the DMM Ingress Router The DMM Ingress Router (IR) is a regular IP router in the mobile operator's network, which can apply host rules to forward traffic to a MN's current mobility anchor. The router must be able to receive and enforce mapping policies. According to these mapping policies, the router can use the locator information to either tunnel the packet to the MN's current mobility anchor, or use destination NAT to allow routing the plain data packet to the MN's current mobility anchor while saving encapsulation overhead. Figure 7 depicts the key functional architecture of such a router, which is able to use network address translation before routing the MN's packet to the currently used mobility anchor by means of an HNP_loc based IP address. : :data V +-----------------[I/F]-----+ | : | |+-----------+ : | ||pre-routing|<--(Policy) | || NAT |----->: | |+-----------+ : | | V | | +-------+ | | |Routing| | | +-------+ | | : : | | V V | +--------------[I/F]-[I/F]--+ : : : : V V Figure 7: Pre-routing destination NAT at a router, which supports the use of per-host locators according to the specified DMM approach Liebsch Expires September 14, 2012 [Page 14] Internet-Draft DMM per-host locator March 2012 7. Security Considerations Secure inter-working between with the mapping system must be established to avoid entering addresses of a malicious node as HNP_loc. Liebsch Expires September 14, 2012 [Page 15] Internet-Draft DMM per-host locator March 2012 8. IANA Considerations So far no need for IANA actions has been identified. Liebsch Expires September 14, 2012 [Page 16] Internet-Draft DMM per-host locator March 2012 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Liebsch Expires September 14, 2012 [Page 17] Internet-Draft DMM per-host locator March 2012 Author's Address Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@neclab.eu Liebsch Expires September 14, 2012 [Page 18]