| DMM | H. Chan |
| Internet-Draft | Huawei Technologies |
| Intended status: Informational | J. Lee |
| Expires: January 4, 2016 | Sangmyung University |
| S. Jeon | |
| Instituto de Telecomunicacoes | |
| July 3, 2015 |
Distributed Mobility Anchoring
draft-chan-dmm-distributed-mobility-anchoring-04
This document defines the mobility management protocol 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 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 January 4, 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. 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 one relies solely on centralized mobility management. 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.
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 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 address at 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 starts a new flow. Packets to the MN in this flow are simply forwarded according to the forwarding table.
In this example, the flow may have terminated before the MN moves to a new network. Otherwise, the flow may close and then restart using a new IP address configured in the new network.
Net1 Net2
+--------------+ +--------------+
|FM-DP: | |FM-DP: |
|AR1 | |AR2 |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1): | or |MN(IP2): |
|flow(IP1,...) | |flow(IP2,...) |
+--------------+ +--------------+
Figure 1. IP 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.
With the MN in the example in Section 3 it may be desirable to change to a flow using the new IP address configured in the new network. The packets of this flow may then follow the forwarding table without requiring IP layer mobility support. 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.
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.
Net1 Net2 +--------------+ +--------------+ |FM-DP: | |FM-DP: | |AR1 | |AR2 | |RA(IP1) | |RA(IP2) | +--------------+ +--------------+ +..............+ +--------------+ .MN(IP1): . move |MN(IP2): | .flow(IP1,...) . =======> |flow(IP2,...) | +..............+ +--------------+
Figure 2. Changing to the new IP address. MN running a flow using IP1 in Net1 changes to running a flow using IP2 in Net2.
The IP address anchor may move without changing the IP address of the flow.
Net1 Net2 +..............+ +--------------+ .FM-DP: . |FM-DP: | .AR1 . move |AR2 | .RA(IP1) . =======> |RA(IP2,IP1) | +..............+ +--------------+ +..............+ +--------------+ .MN(IP1): . move |MN(IP2,IP1): | .flow(IP1,...) . =======> |flow(IP1,...) | +..............+ +--------------+
Figure 3. Moving the IP 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 address 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]. Another example 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. Then the IP anchor node which was advertising the prefix in the original network will need to move to the new network. As the anchor node 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.
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 allow to use the original IP address for the previous flow in the new network.
The IP address at MN's side of a flow may be anchored not at the access router to which the MN is attached.
An example when an MN moves to a new network is as follows. The MN has an ongoing session which was initialized in a prior network (Net1) of attachment using an IP address belonging to the network where it was initialized as described in Section 3. When the flow is unable to change its IP address it may continue to use its original IP address so that the IP address is anchored not in the current network of attachment but in the network where the original IP address belongs. Mobility support is needed to enable the flow to use this original IP address.
Net1 Net2
+--------------+ +--------------+
|FM-DP: | |FM-DP: |
|AR1 | |AR2 |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+--------------+
|MN(IP2): |
|flow(IP1,...) |
+--------------+
Figure 4. IP address anchored not in network of attachment. MN attached to AR2 in Net2 has a flow(IP1,...) using IP1, which belongs to Net1.
After the MN moves with an ongoing session to the new network (Net2), it obtains a new IP address or prefix from the new network. However, the ongoing session which was initialized in a prior network of attachment is using an IP address belonging to the network where it was initialized as described in Section 3.1. IP mobility is needed to use the original IP address for session continuity.
Net1 Net2 +--------------+ +--------------+ |FM-DP: | |FM-DP: | |AR1 |<------------------------------------>|AR2 | |RA(IP1) | |RA(IP2) | +--------------+ +--------------+ +..............+ +--------------+ .MN(IP1): . move |MN(IP1,IP2): | .flow(IP1,...) . =======> |flow(IP1,...) | +..............+ +--------------+
Figure 5. Keeping the IP address from a prior network. MN with ongoing flow using IP1 in Net1 has moved to Net2 and the flow needs to continue using IP1 to preserve session continuity.
The use of IP address belonging to the network of attachment whenever a new flow is initiated as described in Section 3 and to keep the IP address as the MN moves to a new network are described in [I-D.seite-dmm-dma].
As an MN with an ongoing session moves to a new network, the flow may use the original IP address for session continuity by using indirection. Here the location management information may be kept as a binding of the original IP address to a new forwarding address, whereas the Forwarding management function may then use this binding to forward the flow.
In Figure 6, the location management information kept in the original network is the binding of the original IP address to an IP address in the new network.
Net3
+--------------+
|AR3 |
|RA(IPcn) |
/+--------------+
Net1 / +--------------+ Net2
+--------------+ / |CN(IPcn): flow| +--------------+
|FM-CP: | / |(IPcn,IP1,...)| |FM-CP: |
|flow(IP1,...)-| / +--------------+ |flow(IP1,...)-|
|AR1<-->AR2 | / |AR1<-->AR2 |
| | / | |
|LM:IP1<->IPar2| / |LM:IP1<->IPar2|
|--------------| / |--------------|
|FM-DP: |<- |FM-DP: |
|AR1 | ------------------------------------>|AR2(IPar2) |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+..............+ +--------------+
Figure 6. Employing indirection of a flow. After MN has moved from Net1 to Net2, Location Information function in Net1 keeps a binding of IP1 to IP of AR2, and Routing Management function in Net1 forwards the packets of the flow(IP1,...) to Net2.
The packets of the flow(IP1, IPcn, ...) from the CN to the MN will first be forwarded to AR1 in the original network. Here, using the binding of IP1 to an IP address in the new network, the forwarding management function may forward these packets to the new network such as by encapsulating them with a header destined to the new network.
In a host-based mobility management solution such as [I-D.bernardos-dmm-cmip] and [Paper-Distributed.Mobility], the address in the new network may be the MN itself.
In a network-based mobility management solution such as [I-D.bernardos-dmm-pmip], [I-D.sarikaya-dmm-for-wifi], [Paper-Distributed.Mobility] and [Paper-Distributed.Mobility.PMIP], the address in the new network may be an access router to which the MN is attached in the new network. The access router may then forward the packet to the MN at L2, which may use Software-Defined Networking as described in [I-D.sarikaya-dmm-for-wifi].
In general, indirection is invoked only when needed. The flow can use the IP address belonging to the network of attachment where the flow is initialized as described in [I-D.seite-dmm-dma].
In distributed mobility management, the FM-DP may be distributed. The LM and FM-CP may each be distributed and collocate with FM-DP. The may also be centralized. Examples [I-D.yhkim-dmm-enhanced-anchoring] include: (1) Distribute LM and FM-CP, and collocate them with FM-DP, where the IP prefix allocation may be distributed or centralized; (2) As in (1) but with LM centralized; (3) As in (2) but with the IP prefix allocation function centralized.
The security management function in the IP anchor node must ensure that the forwarding management function establishes secure forwarding with a relevant IP anchor node (e.g., forwarding between AR1 and AR2). The security management function in the current IP anchor node (e.g., AR2) must allow the mobile node to receive or send data packets with an IP address configured at a prior network of attachment of the mobile node. Note that nowadays access networks deploy ingress filtering so that the mobile node may not receive or send data packets with the previously configured IP address without the security management function's interaction with ingress filtering.
The security management function in the mobile node must allow to use the previous IP address for the associated flow in the new network.
The security management functions in the end communication nodes (i.e., mobile node and correspondent node) may be used to ensure a secure data plane between them.
For establishments of secure forwarding between IP anchor nodes and secure data plane between the mobile node and correspondent node, existing security protocols such as IKE, IPsec, TLS may be invoked by the security management function.
Forwarding the packets of an ongoing session from CN's network via the original network to MN's new network is not necessarily optimal. The route can be more direct by forwarding these packets directly from CN's network to MN's new network.
Here, the location information in the original network may be copied to CN's network. The packets of the flow(IP1, IPcn, ...) from the CN to the MN are first intercepted at the access router of CN. Then using the binding of IP1 to an IP address in the new network, the forwarding management function in CN's network may forward these packets directly to the new network ([Paper-Distributed.Mobility.PMIP]) such as by encapsulating them with a header destined to the new network.
To change the indirection of a flow, the relevant context with regard to MN should be delivered from AR1 in Net1 to AR3 (CN's anchor) in Net3 (CN's network), while AR2 should be notified of the change of indirection to receive packets directly forwarded by AR3. Existing IP mobility signaling messages such as Proxy Binding Update (PBU) and Proxy Binding Acknowledgment (PBA) can be used for the both communications with as little option extensions as possible. When a packet from the CN has reached AR3, AR3 encapsulates the packet with a tunnel header specified with IP address of CN's anchor as outer source IP and AR2's IP address as outer destination IP. For transparent packet delivery operation in the perspective od AR2, CN's anchor needs to forward packets encapsulated with a tunnel header specified with AR1's IP address as outer source IP and AR2's IP address as outer destination IP.
The security management function in the IP anchor node must ensure that the forwarding management function establishes secure forwarding with a relevant IP anchor node (e.g., forwarding between AR2 and AR3) during mis-session. The security management function in the current IP anchor node (e.g., AR2) must allow the mobile node to receive or send data packets with an IP address configured at a prior network of attachment of the mobile node.
The security management function in the mobile node must allow to use the previous IP address for the associated flow in the new network.
The security management functions in the end communication nodes (i.e., mobile node and correspondent node) may be used to ensure a secure data plane between them during mis-session.
For establishments of secure forwarding between IP anchor nodes and secure data plane between the mobile node and correspondent node, existing security protocols such as IKE, IPsec, TLS may be invoked by the security management function.
Net3
+--------------+
|FM-CP: |
|flow(IP1,...)-|
|AR3<-->AR2 |
y..>| |
p. |LM:IP1<->IPar2|
o. |--------------|
c. |FM-DP: |
. |AR3 |
. |RA(IPcn) |
. +--------------+\
Net1 . +--------------+ \ Net2
+--------------+. |CN(IPcn): flow| \ +--------------+
|FM-CP: | |(IPcn,IP1,...)| \ |FM-CP: |
|flow(IP1,...)-| +--------------+ \ |flow(IP1,...)-|
|AR1<-->AR2 | \ |AR3<-->AR2 |
| | \ | |
|LM:IP1<->IPar2| \ |LM:IP1<->IPar2|
|--------------| \ |--------------|
|FM-DP: | ->|FM-DP: |
|AR1 | |AR2(IPar2) |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+..............+ +--------------+
Figure 7. Changing the indirection path of a flow. Location Information function and Routing Management function in Net2 are copied to Net3, so that the Location Information function in Net3 keeps a binding of IP1 to IP of AR2, and the Routing Management function in Net3 forwards the packets of the flow(IP1,...) to Net2.
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.
| [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. |