--- 1/draft-ietf-dmm-distributed-mobility-anchoring-09.txt 2018-07-02 15:13:16.555032358 -0700 +++ 2/draft-ietf-dmm-distributed-mobility-anchoring-10.txt 2018-07-02 15:13:16.595033334 -0700 @@ -4,21 +4,21 @@ Intended status: Informational Huawei Technologies Expires: January 3, 2019 J. Lee Sangmyung University S. Jeon Sungkyunkwan University CJ. Bernardos, Ed. UC3M July 2, 2018 Distributed Mobility Anchoring - draft-ietf-dmm-distributed-mobility-anchoring-09 + draft-ietf-dmm-distributed-mobility-anchoring-10 Abstract This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support according to the needs of mobility support. In the distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start @@ -64,32 +64,31 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 5 3.1. Configurations for Different Networks . . . . . . . . . . 5 3.1.1. Network-based DMM . . . . . . . . . . . . . . . . . . 5 3.1.2. Client-based DMM . . . . . . . . . . . . . . . . . . 6 4. IP Mobility Handling in Distributed Anchoring Environments - Mobility Support Only When Needed . . . . . . . . . . . . . . 7 - 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 8 - 4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 9 - 5. IP Mobility Handling in Distributed Mobility Anchoring - Environments - Anchor Switching to the New Network . . . . . 11 - 5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 9.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.1. Nomadic case (no need of IP mobility): Changing to new IP + prefix/address . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Mobility case, traffic redirection . . . . . . . . . . . 10 + 4.3. Mobility case, anchor relocation . . . . . . . . . . . . 12 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction A key requirement in distributed mobility management [RFC7333] is to enable traffic to avoid traversing a single mobility anchor far from an optimal route. This document defines different configurations, functional operations and parameters for distributed mobility anchoring and explains how to use them to make the route changes to avoid unnecessarily long routes. @@ -218,32 +218,32 @@ consider architectures in which the control and data planes are separated, as described in [I-D.ietf-dmm-deployment-models]. 3.1.1. Network-based DMM Figure 1 shows a general scenario for network-based distributed mobility management. The main characteristics of a network-based DMM solution are: - There are multiple data plane anchors (i.e., DPA instances), each + o There are multiple data plane anchors (i.e., DPA instances), each with an FM-DP function. - The control plane may either be distributed (not shown in the + o The control plane may either be distributed (not shown in the figure) or centralized (as shown in the figure). - The control plane and the data plane (Control Plane Anchor -- CPA + o The control plane and the data plane (Control Plane Anchor -- CPA -- and Data Plane Anchor -- DPA) may be co-located or not. If the CPA is co-located with the distributed DPAs, then there are multiple co-located CPA-DPA instances (not shown in the figure). - An IP prefix/address IP1 (anchored to the DPA with IP address + o An IP prefix/address IP1 (anchored to the DPA with IP address IPa1) is assigned for use by an MN. The MN uses this IP1 address to communicate with CNs (not shown in the figure). - The location management (LM) function may be co-located or split + o The location management (LM) function may be co-located or split (as shown in the figure) into a separate server (LMs) and a client (LMc). In this case, the LMs may be centralized whereas the LMc may be distributed or centralized. ____________ Network ___/ \___________ / +-----+ \___ ( |LMs | Control \ / +-.---+ plane \ / +--------.---+ functions \ @@ -300,21 +300,36 @@ |flow(IP1,..)|using IP1 |FM, LMc |anchored to +------------+DPA(IPa1) Figure 2: Client-based DMM configuration 4. IP Mobility Handling in Distributed Anchoring Environments - Mobility Support Only When Needed IP mobility support may be provided only when needed instead of being - provided by default. + provided by default. Three cases can be considered: + + o Nomadic case: no address continuity is required. The IP address + used by the MN changes after movement and traffic using old + address is disrupted. If session continuity is required, then it + needs to be provided by a solution running at L4 or above. + o Mobility case, traffic redirection: address continuity is + required. When the MN moves, the previous anchor still anchors + traffic using the old IP address, and forwards it to the new MN's + location. The MN obtains a new IP address anchored at the new + location, and preferably uses it for new communications, + established while connected at the new location. + o Mobility case, anchor relocation: address continuity is required. + In this case the route followed by the traffic is optimized, by + using some means for traffic indirection to deviate from default + routes. A straightforward choice of mobility anchoring is the following: the MN's choses as source IP address of packets belonging to an IP flow, an address allocated by the network the MN is attached to when the flow was initiated. As such, traffic belonging to this flow traverses the MN's mobility anchor [I-D.seite-dmm-dma] [I-D.bernardos-dmm-pmipv6-dlif]. The IP prefix/address at the MN's side of a flow may be anchored at the access router to which the MN is attached. For example, when an @@ -329,21 +344,22 @@ There may be multiple IP prefixes/addresses that an MN can select when initiating a flow. They may be from the same access network or different access networks. The network may advertise these prefixes with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node may choose the one with the least cost. In addition, these IP prefixes/addresses may be of different types regarding whether mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow will need to choose the appropriate one according to whether it needs IP mobility support. -4.1. No Need of IP Mobility: Changing to New IP Prefix/Address +4.1. Nomadic case (no need of IP mobility): Changing to new IP prefix/ + address When IP mobility support is not needed for a flow, the LM and FM functions are not utilized so that the configurations in Section 3.1 are simplified as shown in Figure 3. Net1 Net2 +---------------+ +---------------+ |AR1 | AR is changed |AR2 | +---------------+ -------> +---------------+ @@ -406,52 +421,73 @@ |<--------------RA(IP2)-------------| | | | | | Assigned prefix IP2 | | | IP2 address configuration | | | | | | |<-new Flow(IP2,IPcn,...)-----------+---------------------------->| | | | | Figure 4: Re-starting a flow with new IP prefix/address -4.2. Need of IP Mobility +4.2. Mobility case, traffic redirection When IP mobility is needed for a flow, the LM and FM functions in Section 3.1 are utilized. There are two possible cases: (i) the initial anchor remains the anchor and forwards traffic to a new locator in the new network, and (ii) the mobility anchor (data plane function) is changed but binds the MN's transferred IP address/ - prefix. The latter enable optimized routes but requires some data - plane node that enforces rules for traffic indirection. + prefix. The latter enables optimized routes but requires some data + plane node that enforces rules for traffic indirection. Next, we + focus on the first case. - The first case identified above (mobility support provided by IP - prefix anchor switching to the new network) can be performed as - described in Section 5 or by using other mobility management methods - ([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and - [Paper-Distributed.Mobility.Review]). Then the flow may continue to - use the IP prefix from the prior network of attachment. Yet some - time later, the user application for the flow may be closed. If the - application is started again, the new flow may not need to use the - prior network's IP address to avoid having to invoke IP mobility - support. This may be the case where a dynamic IP prefix/address - rather than a permanent one is used. The flow may then use the new - IP prefix in the network where the flow is being initiated. Routing - is again kept simpler without employing IP mobility and will remain - so as long as the MN which is now in the new network has not moved - again and left to another new network. + Mobility support can be provided by using mobility management methods + such as ([Paper-Distributed.Mobility], + [Paper-Distributed.Mobility.PMIP] and + [Paper-Distributed.Mobility.Review]). After moving, a certain MN's + traffic flow may continue using the IP prefix from the prior network + of attachment. Yet some time later, the user application for the + flow may be closed. If the application is started again, the new + flow may not need to use the prior network's IP address to avoid + having to invoke IP mobility support. This may be the case where a + dynamic IP prefix/address rather than a permanent one is used. The + flow may then use the new IP prefix in the network where the flow is + being initiated. Routing is again kept simpler without employing IP + mobility and will remain so as long as the MN which is now in the new + network has not moved again and left to another new network. - An example call flow in this case is outlined in Figure 5. In this + An example call flow in this case is outlined in Figure 6. In this example, the AR1 plays the role of FM-DP entity and redirects the traffic (e.g., using an IP tunnel) to AR2. Another solution could be to place an FM-DP entity closer to the CN network to perform traffic steering to deviate from default routes (which will bring the packet - to AR1 per default routing). + to AR1 per default routing). The LM and FM functions are implemented + as shown in Figure 5. + + Net1 Net2 + + +---------------+ +---------------+ + |AR1 | |AR2 | + +---------------+ +---------------+ + |CPA: | |CPA: | + | | |LM:IP1 at IPa1 | + |---------------| IP1 (anchored at Net1) |---------------| + |DPA(IPa1): | is redirected to Net2 |DPA(IPa2): | + |anchors IP1 | =======> |anchors IP2 | + +---------------+ +---------------+ + + +...............+ +---------------+ + .MN(IP1) . MN moves |MN(IP2,IP1) | + .flow(IP1,...) . =======> |flow(IP1,...) | + . . |flow(IP2,...) | + +...............+ +---------------+ + + Figure 5: Anchor redirection MN AR1 AR2 CN |MN attaches to AR1: | | | |acquire MN-ID and profile | | |--RS---------------->| | | | | | | |<----------RA(IP1)---| | | | | | | Assigned prefix IP1 | | | IP1 address configuration | | @@ -470,55 +506,59 @@ |<-Flow(IP1,IPcn,...)-------------->+ | | | | | Assigned prefix IP2 | | | IP2 address configuration | | | | | | Flow(IP1,IPcn) terminates | | | | | | |<-new Flow(IP2,IPcn,...)-----------+---------------------------->| | | | | - Figure 5: A flow continues to use the IP prefix from its home network + Figure 6: A flow continues to use the IP prefix from its home network after MN has moved to a new network Multiple instances of DPAs (at access routers), which are providing IP prefix to the MNs, are needed to provide distributed mobility anchoring in an appropriate configuration such as those described in Figure 1 (Section 3.1.1) for network-based distributed mobility or in Figure 2 (Section 3.1.2) for client-based distributed mobility. -5. IP Mobility Handling in Distributed Mobility Anchoring Environments - - Anchor Switching to the New Network +4.3. Mobility case, anchor relocation + + We focus next on the case where the mobility anchor (data plane + function) is changed but binds the MN's transferred IP address/ + prefix. This enables optimized routes but requires some data plane + node that enforces rules for traffic indirection. IP mobility is invoked to enable IP session continuity for an ongoing flow as the MN moves to a new network. Here the anchoring of the IP address of the flow is in the home network of the flow, which is not in the current network of attachment. A centralized mobility management mechanism may employ indirection from the anchor in the home network to the current network of attachment. Yet it may be difficult to avoid unnecessarily long route when the route between the MN and the CN via the anchor in the home network is significantly longer than the direct route between them. An alternative is to switch the IP prefix/address anchoring to the new network. -5.1. IP Prefix/Address Anchor Switching for Flat Network - The IP prefix/address anchoring may move without changing the IP prefix/address of the flow. Here the LM and FM functions in Figure 1 - in Section 3.1 are implemented as shown in Figure 6. + in Section 3.1 are implemented as shown in Figure 7. Net1 Net2 +---------------+ +---------------+ |AR1 | |AR2 | +---------------+ +---------------+ + |CPA: | |CPA: | + |LM:IP1 at IPa1 | |LM:IP1 at IPa2 | | changes to | | | | IP1 at IPa2 | | | |---------------| |---------------| |DPA(IPa1): | IP1 anchoring is effectively moved|DPA(IPa2): | |anchored IP1 | =======> |anchors IP2,IP1| +---------------+ +---------------+ +...............+ +---------------+ .MN(IP1) . MN moves |MN(IP2,IP1) | @@ -518,46 +558,46 @@ |---------------| |---------------| |DPA(IPa1): | IP1 anchoring is effectively moved|DPA(IPa2): | |anchored IP1 | =======> |anchors IP2,IP1| +---------------+ +---------------+ +...............+ +---------------+ .MN(IP1) . MN moves |MN(IP2,IP1) | .flow(IP1,...) . =======> |flow(IP1,...) | +...............+ +---------------+ - Figure 6: Anchor mobility + Figure 7: Anchor mobility As an MN with an ongoing session moves to a new network, the flow may preserve IP session continuity by moving the anchoring of the original IP prefix/address of the flow to the new network. One way to accomplish such move is to use a centralized routing protocol, but note that this solution presents some scalability concerns and its applicability is typically limited to small networks. -6. Security Considerations +5. Security Considerations Security protocols and mechanisms are employed to secure the network and to make continuous security improvements, and a DMM solution is required to support them [RFC7333]. In a DMM deployment [I-D.ietf-dmm-deployment-models] various attacks such as impersonation, denial of service, man-in-the-middle attacks need to be prevented. -7. IANA Considerations +6. IANA Considerations This document presents no IANA considerations. -8. Contributors +7. Contributors Alexandre Petrescu and Fred L. Templin had contributed to earlier versions of this document regarding distributed anchoring for hierarchical network and for network mobility, although these extensions were removed to keep the document within reasonable length. This document has benefited from other work on mobility support in SDN network, on providing mobility support only when needed, and on mobility support in enterprise network. These works have been @@ -566,23 +606,23 @@ indirectly by writing these drafts. The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli. Valuable comments have been received from John Kaippallimalil, ChunShan Xiong, and Dapeng Liu. Dirk von Hugo, Byju Pularikkal, Pierrick Seite have generously provided careful review with helpful corrections and suggestions. Marco Liebsch also performed a very detailed and helpful review of this document. -9. References +8. References -9.1. Normative References +8.1. Normative References [I-D.bernardos-dmm-pmipv6-dlif] Bernardos, C., Oliva, A., Giust, F., Zuniga, J., and A. Mourad, "Proxy Mobile IPv6 extensions for Distributed Mobility Management", draft-bernardos-dmm-pmipv6-dlif-01 (work in progress), March 2018. [I-D.ietf-dmm-deployment-models] Gundavelli, S. and S. Jeon, "DMM Deployment Models and Architectural Considerations", draft-ietf-dmm-deployment- @@ -648,21 +688,21 @@ Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, . -9.2. Informative References +8.2. Informative References [Paper-Distributed.Mobility] Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed IP Mobility Management from the Perspective of the IETF: Motivations, Requirements, Approaches, Comparison, and Challenges", IEEE Wireless Communications, October 2013. [Paper-Distributed.Mobility.PMIP] Chan, H., "Proxy Mobile IP with Distributed Mobility Anchors", Proceedings of GlobeCom Workshop on Seamless