DMM H. Chan, Ed. Internet-Draft Huawei Technologies Intended status: Informational K. Pentikousis, Ed. Expires: January 4, 2015 EICT July 3, 2014 Enhanced mobility anchoring draft-chan-dmm-enhanced-mobility-anchoring-00 Abstract This document initiates the discussion on enhanced mobility anchoring solutions in the context of a distributed mobility management deployment. Such solutions consider the problem of assigning a mobility anchor and a gateway at the initiation of a session. In addition, the mid-session switching of the mobility anchor in a distributed mobility management environment is considered. 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 January 4, 2015. Copyright Notice Copyright (c) 2014 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 document must include Simplified BSD License text as described in Section 4.e of Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 1] Internet-Draft mobility anchor switching July 2014 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 . . . . . . . . . . . . . . . . . . 3 3. Enhanced anchor switching . . . . . . . . . . . . . . . . . . . 4 3.1. Anchor switching between subnets . . . . . . . . . . . . . 4 3.2. Anchor switching between networks . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 2] Internet-Draft mobility anchor switching July 2014 1. Introduction A key requirement in distributed mobility management [I-D.ietf-dmm-requirements] is to enable traffic to avoid traversing single mobility anchor far from the optimal route. Recent developments in research and standardization with respect to future deployment models call for far more flexibility in network function operation and management. For example, the work on service function chaining at the IETF (SFC WG) has already identified a number of use cases for data centers. Although the work in SFC is not primarily concerned with mobile networks, the impact on IP-based mobile networks is not hard to see as by now most hosts connected to the Internet do so over a wireless medium. For instance, as a result of a dynamic re-organization of service chain a non-optimal route between mobile nodes may arise if pme relies solely on centralized mobility management. As discussed earlier in the distributed mobility management working group (DMM WG) this may also occur when the mobile node has moved such that both the mobile node and the correspondent node are far from the mobility anchor via which the traffic is routed. Motivated by the above-mentioned developments as well as [I-D.ietf-dmm-requirements] we aim with this draft to initiate the discussion on enhanced mobility anchoring. Recall that distributed mobility management solutions do not make use of centrally deployed mobility anchor. As such, an application session SHOULD be able to have its traffic passing from one mobility anchor to another as the mobile node moves, or when changing operation and management (OAM) requirements call for mobility anchor switching, thus avoiding non- optimal routes. 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]. All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275] and in the Proxy Mobile IPv6 specification [RFC5213]. This includes terms such as mobile node (MN), correspondent node (CN), home agent (HA), home address (HoA), care- of-address (CoA), local mobility anchor (LMA), and mobile access gateway (MAG). In addition, this document uses the following term: Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 3] Internet-Draft mobility anchor switching July 2014 Home network of an application session (or of an HoA) is the network that has allocated the IP address (HoA) used for the session identifier by the application running in an MN. An MN may be running multiple application sessions, and each of these sessions can have a different home network. 3. Enhanced anchor switching In this section we consider mid-session mobility anchor switching for two cases. First we discuss the case where the mobile node moves from one subnet to another, and then we discuss the case where the node moves to a different network. Note that although the cases are described with traditional (read: physical) node mobility in mind, the proposed mechanism can be triggered for other operational reasons, such as the redefinition of a service chain graph, due to mechanisms which indicate that by relocating the mobility anchor for certain sessions energy and other operation expenditure can be reduced, or due to emergency situations, such as physical catastrophes. 3.1. Anchor switching between subnets First we consider the situation illustrated in Fig. 1: The mobile node (M) moves from Subnet 1 to Subnet 2. Each of the Network A Subnets (1, 2, and so on) owns a block of IP addresses. In each subnet, the corresponding access router (AR1, AR2, ...) advertises the routes for the block of addresses of that subnet. Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 4] Internet-Draft mobility anchor switching July 2014 +----------+ | Network A| |Controller| +----------+ +---+ +---+ +---+ |AR1| |AR2| |AR3| +--------+ +--------+ +--------+ |Subnet 1| |Subnet 2| |Subnet 3| .... +--------+ +--------+ +--------+ +----+ +----+ | M | =====> | M | |with| |with| |IP1 | |IP2 | | | |IP1 | +----+ +----+ Figure 1. Movement of M from Subnet 1 to Subnet 2. Before moving, M is allocated an IP address IP1 from Subnet 1, and it may run network applications using this IP address. As M moves to Subnet 2, it obtains a new IP address IP2 from Subnet 2. The applications that can handle a change of IP address will use the address IP2 [I-D.seite-dmm-dma]. Other ongoing applications that cannot survive an IP address change will need to continue using IP11 to maintain session continuity. A mobility management protocol may be used to enable M to use the address IP1 belonging to Subnet 1. The AR1 access router in Subnet 1 may delegate the IP address (IP1) to the access router AR2 in Subnet 2. AR2 will then advertise IP1 so that the routing tables in Network A will be updated and packets destined to IP1 will be routed to Subnet 2. Relying on earlier routing table update mechanisms with a distributed routing protocol may not be fast enough to meet the requirement for a short handover delay. In the case where a control and data plane separation model is followed, a logically centralized mechanism can perform the forwarding table update faster. For example, we can consider the use of I2RS mechanisms or the possibility to employ NETCONF [RFC6241] for reconfiguring AR2. Alternatively, a tunneling mobility management protocol such as MIPv6 [RFC6275] or PMIPv6 [RFC5213] may be used initially [Paper- Distributed.Mobility.PMIP] to enable M to use the IP address IP1 while IP1 still belongs to Subnet 1. The route may not be optimized initially, but this is a good tradeoff so that anchor switching can Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 5] Internet-Draft mobility anchor switching July 2014 take place. After anchor switching and its subsequent forwarding table update have been completed, packets destined to IP1 will be routed directly towards M. The address delegation of IP1 from Subnet 1 to Subnet 2 may timeout unless there is request to renew it before it expires. When all applications using IP1 in M have been terminated, there will be no longer need for using IP1 in Subnet 2. If there are still such applications running when the address delegation is about to timeout, the mobile node may signal with AR1 to request renewal of address delegation. 3.2. Anchor switching between networks Fig. 2 illustrates the movement of a mobile node (M) from Subnet a1 of Network A to Subnet b2 of Network B. In this case, each Network (A, B, and so on) owns the aggregate of IP addresses blocks for its subnets. The corresponding gateway routers (GWa, GWb, ...) may run an IBGP among them, and each advertises the aggregate of IP addresses for its subnets. +---+ +---+ +---+ |GWa| |GWb| |GWc| +----------+ +----------+ +----------+ |Network A | |Network B | |Network C | .... |Controller| |Controller| |Controller| +----------+ +----------+ +----------+ +----+ +----+ |ARa1| |ARb2| +---------+ +---------+ |Subnet a1| |Subnet b2| .... +---------+ +---------+ +-----+ +-----+ | M | =====> | M | | with| | with| |IPa11| |IPb21| | | |IPa11| +-----+ +-----+ Figure 1. Movement of M from Subnet a1 of Network A to Subnet b2 of Network B. Before moving, M is allocated the IP address IPa11 from Subnet a1 of Network A, and it may run network applications using this IP address. Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 6] Internet-Draft mobility anchor switching July 2014 As M moves to Subnet b2, it obtains a new IP address IPb21 from Subnet b2 of Network B. The applications that can handle a change of IP address will use this new address IPb21. Other applications with ongoing sessions that cannot survive an IP address change will need to continue using IPa11 to maintain session continuity. A mobility management protocol may be used to enable M to use the address IPa11 belonging to Subnet a1 in Network A. As the access router ARa1 in Subnet a1 may delegate the address IPa11 to the access router ARb2 in Subnet b2, the gateways GWa, GWb, ... also need to update the routing information so that GWb will then advertise IPa11 so that the routing tables in GWa, GWb, ... will update and packets destined to IPa11 will be routed to Network B. The routing table update between the gateways MAY be accomplished using IS-IS. In scenarios where the control plane and the data plane for these gateways are separate, and there is a controller for these gateways, a centralized routing protocol can also perform the forwarding table update for these gateways. Optionally, a tunneling mobility management protocol such as MIPv6 [RFC6275] or PMIPv6 [RFC5213] may be used to initially enable M to use the address IPa11 while IPa11 still belongs to Subnet a1 of Network A. Although such a route may not be optimized initially, it enables anchor switching to take place. After anchor switching and its subsequent forwarding table update have been completed, the packets destined to IPa11 will be routed directly towards M. The address delegation of IPa11 from Subnet a1 to Subnet b2 may timeout unless there is request to renew it before it expires. When the applications uisng IPa11 in M have all been terminated, there will be no longer need for using IPa11 in Subnet b2. If there are still such applications running when the address delegation is about to timeout, the mobile node may signal with ARa1 to request renewal of address delegation. 4. Security Considerations TBD 5. IANA Considerations This document presents no IANA considerations. 6. References Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 7] Internet-Draft mobility anchor switching July 2014 6.1. Normative References [I-D.ietf-dmm-requirements] Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", draft-ietf-dmm-requirements-17 (work in progress), June 2014. [I-D.seite-dmm-dma] Seite, P., Bertin, P., and J. Lee, "Distributed Mobility Anchoring", draft-seite-dmm-dma-07 (work in progress), February 2014. [I-D.yokota-dmm-scenario] Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case scenarios for Distributed Mobility Management", draft-yokota-dmm-scenario-00 (work in progress), October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 6.2. Informative References [Paper-Distributed.Mobility.PMIP] Chan, H., "Proxy Mobile IP with Distributed Mobility Anchors", Proceedings of GlobeCom Workshop on Seamless Wireless Mobility, December 2010. [Paper-Distributed.Mobility.Review] Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues", February 2011. Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 8] Internet-Draft mobility anchor switching July 2014 Authors' Addresses H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024 USA Email: h.a.chan@ieee.org Kostas Pentikousis EICT EUREF-Campus Haus 13 Torgauer Strasse 12-15 10829 Berlin Germany Email: k.pentikousis@eict.de Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 9]