| DMM | H. Chan |
| Internet-Draft | Huawei Technologies |
| Intended status: Informational | J. Lee |
| Expires: September 24, 2015 | Sangmyung University |
| S. Jeon | |
| Instituto de Telecomunicacoes | |
| March 23, 2015 |
Distributed Mobility Anchoring
draft-chan-dmm-distributed-mobility-anchoring-01
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 session. 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 September 24, 2015.
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. 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. This draft proposes enhanced mobility anchoring.
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:
When an IP prefix or address is topologically anchored to a node (data plane node), the anchor function will advertise connected route for it. Then an IP packet with this IP address as its destination address will be forwarded along a path that traverses through this IP anchoring node.
When a session or flow is anchored to a node (data plane node), the packets of the flow will traverse at least one such session anchoring node.
A session anchoring node may differ from an IP anchoring node for an IP address of the session.
An IP prefix or address may be anchored to the access router to which the MN is attached.
For example, when an MN attaches to a network or moves to a new network, 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 application session (an IP flow). Packets to the MN in this flow simply follows the forwarding table for as long as the MN stays in that network.
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.
The security management function in the IP anchoring node at a new network must assign a valide IP prefix to a mobile node. In the example, the security management function in the node anchoring address IP2 assigns the valid IP prefix for the mobile node.
Net1 Net2
+--------------+ +--------------+
|node anchoring| |node anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+
|MN(IP2) |
|running |
|session IP2 |
+--------------+
Figure 1. IP anchoring in network of attachment.
An IP prefix or address may be anchored to an access router in a different network to which the MN is attached. The anchor function is then in a network different from the network of attachment.
An example is in using a static IP address which does not belong to the network of attachment.
Another 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 of attachment using an IP address belonging to the network where it was initialized as described in Section 3.1. When the session is unable to change its IP address it may continue to use its original IP address which 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 ongoing session to use this original IP address.
The security management function in the IP anchoring node at a new network must assign a valide IP prefix to a mobile node. The security management function 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.
Net1 Net2
+--------------+ +--------------+
|node anchoring| |node anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+
|MN(IP2) |
|running |
|session IP1 |
+--------------+
Figure 2. IP anchoring not in network of attachment.
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 (Net2). However, the ongoing session which was initialized in a prior network of attachment 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 the ongoing session continuity.
Net1 Net2 +--------------+ +--------------+ |node anchoring| |node anchoring| | address IP1 | | address IP2 | +--------------+ +--------------+ +--------------+ +--------------+ |MN(IP1) with | move |MN(IP1,IP2) | |session over | =======> |with session | |IP1 | |over IP1 | +--------------+ +--------------+
Figure 3. Keeping IP anchoring in mid-session.
With the MN in the example in Section 3.1 it may be desirable that the flow can change to 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 the 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 IP anchoring node at a new network must assign a valide IP prefix to a mobile node.
Net1 Net2 +--------------+ +--------------+ |node anchoring| |node anchoring| | address IP1 | | address IP2 | +--------------+ +--------------+ +--------------+ +--------------+ |MN(IP1) with | move |MN(IP2) with | |session over | =======> |session IP1 | |IP1 | |changed to IP2| +--------------+ +--------------+
Figure 4. Changing IP anchoring.
The IP anchoring may move without changing the IP address of the flow.
Net1 Net2 +--------------+ +--------------+ |node anchoring| move |node anchoring| | address IP1 | =======> | address IP1 | +--------------+ +--------------+ +--------------+ +--------------+ |MN(IP1) | move |MN(IP2) | |running | =======> |running | |session IP1 | |session IP1 | +--------------+ +--------------+
Figure 5. Moving IP anchoring.
As an MN with an ongoing session moves to a new network, the session may preserve session continuity by moving the IP anchoring of its original IP address to the new network. Then the IP anchoring which was advertising the prefix in the original network will need to move to the new network. As the IP anchoring in the new network advertises the prefix of the session in the new network, the forwarding tables will be updated so that packets of the ongoing session will follow the updated forwarding tables.
As an MN with an ongoing session moves to a new network, the session may use the original IP address for session continuity by anchoring the session to some nodes (data plane nodes) and redirecting the packets of this session to traverse through these session anchoring nodes.
Net3
+--------------+
Net1 |node anchoring| Net2
+--------------+ /|address of CN | +--------------+
| anchoring| / +--------------+ | anchoring|
| session | / | session |
| identified | / +--------------+ | identified |
| with IP1 | / | CN | | with IP1 |
| | / +--------------+ | |
|session IP1 | / |session IP1 |
|--> addr AR2 | / |--> MN |
|--------------| / |--------------|
|node anchoring|<- |AR2 anchoring|
| address IP1 | ------------------------------------>| address IP2 |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1) | move |MN(IP2) |
|running | =======> |running |
|session IP1 | |session IP1 |
+--------------+ +--------------+
Figure 6. Session anchoring.
For example, a first node to anchor the session may be at the IP anchoring of the original IP address in the original network. A second node to anchor the session may be in the new network. Then packets of this session traverse the session anchoring in both the original network and the new network. Forwarding management function at these nodes may be used to direct the flow to traverse them.
The session's packets from the CN to the MN will then first be forwarded to the IP anchoring node in the original network where it is intercepted by the first session anchoring node. The session anchoring node may possess forwarding management function to forward the packets to the second session anchoring node in the new network.
In host-based mobility management, the session may be anchored in the new network to the MN itself.
In network-based mobility management, the session may be anchored to 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.
The security management function in the IP anchoring node must ensure that the forwarding management function establishes a secure session anchoring with a relevant node. The security management function in the end communication nodes (i.e., mobile node and correspondent node) may be used to ensure a secure data plane between them.
The route of the packets of an ongoing session traversing the original network and the MN's new network of attachment is not necessarily optimal. It can be unnecessarily long especially when the session anchoring nodes are far from each other even when the MN and CN are close to each other. A shorter route results when the session is anchored in both the CN's network and the MN's network. An example to achieve this is to move the session anchoring from the original network to the CN's network.
For anchor switching of a session in mid-session, the relevant context with regard to MN should be delivered to CN's anchor from the AR in Net 1, while the anchor switching should be notified to AR1 to receive packets directly forwarded by CN's anchor. Existing IP mobility signaling messages such as Proxy Binding Update (PBU) and Proxy Binding Acknowledgment (PBA) can be used for the both communications with smaller option extensions as possible. When CN's anchor receives packets from the CN, it encapsulates the packet with a tunnel header specified with IP address of CN's anchor for outer source IP and AR2's IP address for outer destination IP. For the transparent packet delivery operation in AR2 perspective, CN's anchor needs to forward packets encapsulated with a tunnel header specified with AR1's IP address for outer source IP and AR2's IP address for outer destination IP.
The security management function in the IP anchoring node must ensure that the forwarding management function re-establishes a secure session anchoring with a relevant node during mid-session. The security management function in the end communication nodes may be used to ensure a secure data plane between them during mid-session.
Net3
+--------------+
| anchoring|
| session |
| identified |
| with IP1 |
| |
..>|session IP1 |
. |--> addr AR2 |
. |--------------|
Net1 . |node anchoring| Net2
+--------------+ . |address of CN |\ +--------------+
| anchoring| . +--------------+ \ | anchoring|
| session | . \ | session |
| identified | . +--------------+ \ | identified |
| with IP1 |. | CN | \ | with IP1 |
| | +--------------+ \ | |
|session IP1 | \ |session IP1 |
|--> addr AR2 | \ |--> MN L2 addr|
|--------------| \ |--------------|
|node anchoring| ->|AR2 anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1) | move |MN(IP2) |
|running | =======> |running |
|session IP1 | |session IP1 |
+--------------+ +--------------+
Figure 7. Changing session anchoring in mid-session.
TBD
This document presents no IANA considerations.
| [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. |