| DMM | H. Chan |
| Internet-Draft | X. Wei |
| Intended status: Informational | Huawei Technologies |
| Expires: April 17, 2016 | J. Lee |
| Sangmyung University | |
| S. Jeon | |
| Instituto de Telecomunicacoes | |
| F. Templin | |
| Boeing Research and Technology | |
| October 15, 2015 |
Distributed Mobility Anchoring
draft-chan-dmm-distributed-mobility-anchoring-05
This document defines the mobility management solutions in the context of a distributed mobility management deployment. It consider the problem of assigning a mobility anchor at the initiation of a flow. In addition, the mid-session switching of the mobility anchor in a distributed mobility management environment is considered.
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 April 17, 2016.
Copyright (c) 2015 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
A key requirement in distributed mobility management [RFC7333] is to enable traffic to avoid traversing single mobility anchor far from the optimal route. Recall that distributed mobility management solutions do not make use of centrally deployed mobility anchor [Paper-Distributed.Mobility]. As such, a flow SHOULD be able to have its traffic changing from traversing one mobility anchor to traversing another mobility anchor as the mobile node moves, or when changing operation and management (OAM) requirements call for mobility anchor switching, thus avoiding non-optimal routes. This draft proposes distributed mobility anchoring solutions.
The needs of IP-layer mobility support are diverse so that the use of distributed anchoring may differ according to the needs.
A mobile node (MN) may be running a flow with its correspondent node (CN) for which the source IP address of this flow belongs to MN's network. That is, it is anchored to an access router (anchor) belonging to MN's network. When there are multiple anchors, the flow may need to select the anchor when it is initiated (Section 3). Using an anchor in MN's network has the advantage that the packets can simply be forwarded according to the forwarding table. The anchor may be in the MN's network when the flow was initiated. As the MN moves from one network to another, IP address no longer belongs to the new network. To order that the IP address of the flow is in the new network different methods can be used dependent on the needs of the flow. If the ongoing IP flow can cope with an IP prefix/address change, the flow can be reiniated with a new IP address anchored in the new network (Section 3.1). On the other hand, if the ongoing IP flow cannot cope with such change, the IP address anchoring can be moved from the original network to the new network (Section 3.2).
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], the Proxy Mobile IPv6 specification [RFC5213], and the DMM current practices and gap analysis [RFC7429]. 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:
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 MN attaches to a network (Net1) or moves to a new network (Net2), it is allocated an IP prefix from that network. It configures from this prefix an IP address which is typically a dynamic IP address. It then uses this IP address when it a flow is initiated. Packets to the MN in this flow are simply forwarded according to the forwarding table.
Net1 Net2 +---------------+ +---------------+ |AR1 anchors IP1| |AR2 anchors IP2| +---------------+ +---------------+ +---------------+ +---------------+ |MN(IP1): | |MN(IP2): | |flow(IP2,...) | or |flow(IP2,...) | +---------------+ +---------------+
Figure 1. IP prefix/address anchored in network of attachment. MN is attached to AR1 in Net1 where it has initiated a flow using IP1 or has moved to AR2 in Net2 where it initiates a new flow using IP2.
There may be multiple IP prefixes/addresses to choose from. 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.dmm-ondemand-mobility-api]. A flow will need to choose the appropriate one according to whether it needs IP mobility support.
With on-demand mobility, IP mobility support is provided only when needed instead of being provided by default.
A straightforward choice of mobility anchoring is for a flow to use the IP prefix of the network to which the MN is attached when the flow is initiated [I-D.seite-dmm-dma]. This is shown in Figure 2.
Net1 Net2 +---------------+ +---------------+ |AR1 anchors IP1| |AR2 anchors IP2| +---------------+ +---------------+ +...............+ move +---------------+ .MN(IP1): . =======> |MN(IP2): | .flow(IP1,...) . |flow(IP2,...) | +...............+ +---------------+
Figure 2. Changing to the new IP prefix/address. MN running a flow using IP1 in Net1 changes to running a flow using IP2 in Net2.
When IP mobility is not provided to a specific flow, the flow may use a new IP address acquired from a new network as the MN moves to the new network.
Regardless of whether IP mobility is needed, if the flow has terminated before the MN moves to a new network, the flow may subsequently restart using the new IP address allocated from the new network.
When session continuity is needed, even if a flow is ongoing as the MN moves, it may still be desirable for the flow to change to using the new IP prefix configured in the new network. The flow may then close and then restart using a new IP address configured in the new network. Yet such a change in flow may be using a higher layer mobility support which is not in the scope of this document to change the IP address of the flow.
In Figure 2, a flow initiated while the MN was in Net1 has terminated before the MN moves to a new network Net2. After moving to Net2, the MN uses the new IP prefix anchored in Net2 to start a new flow. The packets may then be forwarded without requiring IP layer mobility support.
The call flow is outlined in Figure 3.
MN p-AR n-AR CN |MN attaches to p-AR: | | | |acquire MN-ID and profile | | |--RS---------------->| | | | | | | |<----------RA(HNP1)--| | | | | | | Allocated prefix P1 IP1 address configuration | | | | |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| | | | | |MN detach from p-AR | | | |MN attach to n-AR | | | | | | | |--RS------------------------------>| | | | | | |<--------------RA(HNP2)------------| | | | | | Allocated prefix P2 IP2 address configuration | | | | |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| | | | |
Figure 3. A flow uses the IP allocated from the network at which the MN is attached when the flow is initiated.
The security management function in the anchor node at a new network must allow to assign a valid IP prefix/address to a mobile node.
When IP mobility is needed for a flow, the mobility support may be provided by moving the IP address anchoring to the new network to be described in Section 3.2 or by using other mobility management methods ([Paper-Distributed.Mobility.PMIP] and [Paper-Distributed.Mobility.Review]) Then the flow may continue to use the IP prefix from the prior network. Yet some time later, the flow of a certain user application may be closed. If the spplication is started again, the new flow may not need to use the prior network address to avoid having to invoke IP mobility support. This is the case when the use of a permanent IP prefix/address is not needed. The flow may then use the new IP prefix in the network where the flow is initiated. Routing is again kept simpler without employing IP mobility and will remain so as long as the MN has not moved away from that network.
The call flow in this case is outlined in Figure 4.
MN p-AR n-AR CN |MN attaches to p-AR: | | | |acquire MN-ID and profile | | |--RS---------------->| | | | | | | |<----------RA(HNP1)--| | | | | | | Allocated prefix P1 IP1 address configuration | | | | |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| | | | | |MN detach from p-AR | | | |MN attach to n-AR | | | | | | | |--RS------------------------------>| | Moving IP2 anchoring to n-AR to be described in next sub-section |<--------------RA(HNP2,P1)---------| | | | | | |<-Flow(IP1,IPcn,...)---------------+------------------------------->| | | | | Allocated prefix P2 IP2 address configuration | | | | Flow(IP1,IPcn) teminates | | | | |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| | | | |
Figure 4. A flow uses the IP allocated from the network at which the MN is attached when the flow is initiated.
The IP prefix/address anchor may move without changing the IP prefix/address of the flow.
Net1 Net2 +---------------+ +---------------+ |LM:IP1<-->IPar2| |LM:IP1<-->IPar2| |FM:DHCPv6-PD | | | |---------------| move |---------------| |AR1 anchors IP1| =======> |AR2 anc IP1,IP2| +---------------+ +---------------+ +...............+ +---------------+ .MN(IP1): . move |MN(IP1,IP2): | .flow(IP1,...) . =======> |flow(IP1,...) | +...............+ +---------------+
Figure 5. Moving the IP prefix/address anchor to the new network. MN with flow using IP1 in Net1 continues to run the flow using IP1 as it moves to Net2.
As an MN with an ongoing session moves to a new network, the flow may preserve session continuity by moving the original IP prefix/address of the flow to the new network. An example is in the use of BGP UPDATE messages to change the forwarding table entries as described in [I-D.mccann-dmm-flatarch] and also for 3GPP Evolved Packet Core (EPC) network in [I-D.matsushima-stateless-uplane-vepc].
The security management function in the anchor node at a new network must allow to assign the original IP prefix/address used by the mobile node at the previous (original) network. As the assigned original IP prefix/address is to be used in the new network, the security management function in the anchor node must allow to advertise the prefix of the original IP address and also allow the mobile node to send and receive data packets with the original IP address.
The security management function in the mobile node must allow to configure the original IP prefix/address used at the previous (original) network when the original IP prefix/address is assigned by the anchor node in the new network. The security management function in the mobile node also allows to use the original IP address for the previous flow in the new network.
An example of moving the IP prefix is in the case where Net1 and Net2 both belong to the same operator network with separation of control and data planes ([I-D.liu-dmm-deployment-scenario] and [I-D.matsushima-stateless-uplane-vepc]), where the controller may send to the switches/routers the updated information of the forwarding tables with the IP addressing anchoring of the original IP prefix/address at AR1 moved to AR2 in the new network. That is, the IP address anchoring in the original network which was advertising the prefix will need to move to the new network. As the anchoring in the new network advertises the prefix of the original IP address in the new network, the forwarding tables will be updated so that packets of the flow will be forwarded according to the updated forwarding tables. Figure 6 shows such a case where the functions LM, FM-CP are centralized whereas the FM-DP's are distributed.
Net1 Net2 +----------------------------------------------------------------------+ | LM:IP1<-->IPar2 | | FM-CP | +----------------------------------------------------------------------+ +---------------+ +---------------+ |FM-DP:DHCPv6-PD| |FM-DP | |---------------| move |---------------| |AR1 anchors IP1| =======> |AR2 anc IP1,IP2| +---------------+ +---------------+ +...............+ +---------------+ .MN(IP1): . move |MN(IP1,IP2): | .flow(IP1,...) . =======> |flow(IP1,...) | +...............+ +---------------+
Figure 6. Moving the IP prefix/address anchor to the new network and with LM and FM-CP in a centralized control plane whereas the FM-DP's are distributed.
The call flow in Figure 7 shows that MN is allocated HNP1 when it attaches to the p-AR. A flow running in MN may or may not need IP mobility. If it does, it may continue to use the previous IP prefix. If it does not, it may use a new IP prefix allocated from the new network.
MN p-AR n-AR DHCP Servers CN |MN attaches to p-AR: | | | | |acquire MN-ID and profile | | | |--RS---------------->| | | | |<----------RA(HNP1)--| | | | | | | Allocate MN-HNP1 | IP addr config | | | | | | | | | |<-Flow(IP1,IPcn,...)-+--------------------------------------------->| | | | | | |MN detach from p-AR | | | | |MN attach to n-AR | | | | | | | | | |--RS(HNP1)------------------------>| | | | | | | | | |------DHCPv6 release-------------->| | | | | | | | | |--DHCPv6 PD request->| | | | |<-DHCPv6 PD reply--->| | | | | | | | BGP route updates | | | | | | | |<--------------RA(HNP2,HNP1)-------| | | | | | Allocate MN-HNP2 | IP addr config | | | | | | | | | |<-Flow(IP1,IPcn,...)---------------+------------------------------->| | | | | | | Flow(IP1,IPcn,...) terminates | | | | | | | | | | DHCPv6-PD timeout | | | | | | | | BGP route updates | | | | | | | | | | | | |<-new Flow(IP2,IPcn,...)-----------+------------------------------->| | | | | |
Figure 7. DMM solution. MN with flow using IP1 in Net1 continues to run the flow using IP1 as it moves to Net2.
As the MN moves from p-AR to n-AR, the p-AR as a DHCP client may send a DHCP release message to release the HNP1. It is now necessary for n-AR to learn the IP prefix of the MN from the previous network so that it will be possible for Net2 to allocate both the previous network prefix and the new network prefix. MN may provide its previous network prefix information by including it to the RS message [I-D.jhlee-dmm-dnpp].
Knowing that MN is using HNP1, the n-AR sends to a DHCP server a DHCPv6-PD request to move the HNP1 to n-AR. The server sends to n-AR a DHCPv6-PD reply to move the HNP1. Then BGP route updates will take place here.
In addition, the MN also needs a new HNP in the new network. The n-AR may now send RA to n-AR, with prefix information that includes HNP1 and HNP2. The MN may then continue to use IP1. In addition, the MN is allocated the prefix HNP2 with which it may configure its IP addresses. Now for flows using IP1, packets destined to IP1 will be forwarded to the MN via n-AR.
As such flows have terminated and DHCP-PD has timed out, HNP1 goes back to Net1. MN will then be left with HNP2 only, which it will use when it now starts a new flow.
A hierarchy may also exist as shown the Figure 8. Here the IP prefix allocated to the MN is anchored at an edge router (ER) supporting multiple access routers to which the MN may be attached. Mobility of the MN involving change of AR but not of ER may be accomplished using tunneling between the ER and the AR or using some other L2 mobility mechanism.
Net1 Net2
+----------------------------------------------------------------------+
| LM:IP1<-->IPar2 |
| FM-CP |
+----------------------------------------------------------------------+
+---------------+
|FM-DP |
|---------------|
|ER1 anchors IP1|
+---------------+
+---------------+ +---------------+
|FM-DP | |FM-DP |
|---------------| move |---------------|
|AR1 | =======> |AR2 |
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1): . move |MN(IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
Figure 8. Mobility without involving change of IP anchoring in a network with hierarchy in which the IP prefix allocated to the MN is anchored at an Edge Router supporting multiple access routers to which the MN may connect to.
The mobility event shown in Figure 9 involves a change of the IP prefix anchoring. ER1 acting as a DHCP-PD client may exchange message with the DHCP server to release the prefix IP1. Meanwhile, ER2 acting as a DHCP-PD client may exchange message with the DHCP server to delegate the prefix IP1 to ER2.
Net1 Net2
+----------------------------------------------------------------------+
| LM:IP1<-->IPar2 |
| FM-CP |
+----------------------------------------------------------------------+
+---------------+
|FM-DP |
|---------------|
|GW |
+---------------+
+---------------+ +---------------+
|FM-DP:DHCPv6-PD| |FM-DP |
|---------------| move |---------------|
|ER1 anchors IP1| =======> |ER2 anc IP1,IP2|
+---------------+ +---------------+
+---------------+ +---------------+
|FM-DP | |FM-DP |
|---------------| |---------------|
|AR1 | |AR2 |
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
Figure 9. Mobility involving change of IP anchoring in a network with hierarchy in which the IP prefix allocated to the MN is anchored at an Edge Router supporting multiple access routers. to which the MN may connect to.
TBD
This document presents no IANA considerations.
This document is an attempt to harmonize the different distributed mobility solutions in a number of other drafts. These drafts cited in this document are the work of their many authors/co-authors. While some of them have taken the work to jointly write this document, others have contributed at least indirectly by writing these drafts. The latter include Carlos J. Bernardos, Philippe Bertin, Hui Deng, Fabio Giust, Dapeng Liu, Satoru Matushima, Peter McCann, Antonio de la Oliva, Behcet Sarikaya, Pierrick Seite, Li Xue, Ryuji Wakikawa, and Younghan Kim.
Valuable comments have also been received from John Kaippallimil and ChunShan Xiong.
| [I-D.dmm-ondemand-mobility-api] | Yegin, A., Kweon, K., Lee, J., Park, J. and D. Moses, "On Demand Mobility API", Internet-Draft draft-dmm-ondemand-mobility-api-00, May 2015. |
| [I-D.jhlee-dmm-dnpp] | Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", Internet-Draft draft-jhlee-dmm-dnpp-00, October 2015. |
| [I-D.liu-dmm-deployment-scenario] | Liu, V., Liu, D., Chan, A. and D. Lingli, "Distributed mobility management deployment scenario and architecture", Internet-Draft draft-liu-dmm-deployment-scenario-04, July 2015. |
| [I-D.matsushima-stateless-uplane-vepc] | Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", Internet-Draft draft-matsushima-stateless-uplane-vepc-05, September 2015. |
| [I-D.mccann-dmm-flatarch] | McCann, P., "Authentication and Mobility Management in a Flat Architecture", Internet-Draft draft-mccann-dmm-flatarch-00, March 2012. |
| [I-D.mccann-dmm-prefixcost] | McCann, P. and J. Kaippallimalil, "Communicating Prefix Cost to Mobile Nodes", Internet-Draft draft-mccann-dmm-prefixcost-02, October 2015. |
| [I-D.seite-dmm-dma] | Seite, P., Bertin, P. and J. Lee, "Distributed Mobility Anchoring", Internet-Draft draft-seite-dmm-dma-07, February 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5213] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008. |
| [RFC6275] | Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011. |
| [RFC7333] | Chan, H., Liu, D., Seite, P., Yokota, H. and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014. |
| [RFC7429] | Liu, D., Zuniga, JC., Seite, P., Chan, H. and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015. |
| [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 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. |