Framework for Mobility Management Protocol
draft-chan-dmm-framework-00

Abstract

This document introduces a framework for mobility management protocols in terms of their key abstracted logical functions. The framework is capable of presenting a unified view, reducing the clutter that obscures a casual reader from understanding the commonalities between different approaches in mobility management. A first order application of this framework allows us to examine previously standardized mobility management protocols, such as MIPv6 and PMIPv6 (as well as several of their extensions), and describe their core functionality in terms of different configurations of the logical functions defined by the framework.

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 August 5, 2013.

Copyright Notice

Copyright (c) 2013 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.

Table of Contents

• 1. Introduction
• 1.1. Overview
• 2. Conventions and Terminology
• 2.1. Conventions used in this document
• 2.2. Terminology
• 3. Mobility Management Logical Functions
• 4. Functional Representation of Existing Mobility Protocols
• 4.1. Mobile IPv6
• 4.2. MIPv6 versus PMIPv6
• 4.3. Hierarchical Mobile IPv6
• 4.4. Distributing mobility anchors
• 4.5. Migrating Home Agents
• 5. DMM Functional Scenarios
• 5.1. Flat Network Scenario
• 5.1.1. Network-based Mobility Management
• 5.1.2. Client-based Mobility Management
• 5.2. Fully distributed scenario with separation of control and data planes
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

While there is ongoing research on new protocols for distributed mobility management (DMM), it has also been proposed, e.g., in [Paper-Distributed.Mobility.PMIP] and in other publications, that a distributed mobility management architecture can be designed using primarily existing mobility management protocols with some extensions. This is reflected in the requirement presented in [ID-dmm-requirements]: distributed mobility management is to first use existing protocols and their extensions before considering new protocol designs.

Mobile IPv6 [RFC6275], which is a logically centralized mobility management approach addressing primarily hierarchical mobile networks, has numerous variants and extensions including, just to name a few, PMIPv6 [RFC5213], Hierarchical MIPv6 (HMIPv6) [RFC5380], Fast MIPv6 (FMIPv6) [RFC4068] [RFC4988], Proxy-based FMIPv6 (PFMIPv6) [RFC5949]. These variants or extensions of MIPv6 have been developed over the years owing to the different needs that have been arising ever since the first specification of MIP came into life.

This document argues that we can gain much more insights into this design space by abstracting functions of existing mobility management protocols in terms of logical functions. Different variants of existing mobility management protocols can then be expressed as different design variations of how these logical functions are put together. The result is a rich framework that can express sophisticated functionalities in a more straightforward manner and can be used to perform gap analysis of existing protocols. What is more, this document shows how to reconfigure these logical functions towards various distributed mobility management designs.

The following subsection presents an overview of this document.

1.1. Overview

Section 3 proposes to abstract existing mobility management protocol functions into three logical functions, namely, home address allocation, mobility routing and location management. Such functional decomposition will enable us to clearly separate data plane and the control plane functionality, and gives us the flexibility in an implementation to position said logical functions at their most appropriate places in the system design.

Section 4 shows that these logical functions can indeed perform the same functions as the major existing mobility protocols. These functions therefore become the foundation for a unified framework upon which different designs of distributed mobility management may be built upon.

2. Conventions and Terminology

2.1. Conventions used in this document

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].

2.2. Terminology

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]. These terms include mobile node (MN), correspondent node (CN), home agent (HA), local mobility anchor (LMA), and mobile access gateway (MAG).

In addition, this document uses the following terms:

Mobility routing (MR)

is the logical function that intercepts packets to/from the HoA of a mobile node and forwards them, based on internetwork location information, either directly towards their destination or to some other network element that knows how to forward the packets to their ultimate destination.

Home address allocation

is the logical function that allocates the home network prefix or home address to a mobile node.

Location management (LM)

is the logical function that manages and keeps track of the internetwork location information of a mobile node, which includes the mapping of the MN HoA to the MN routing address or another network element that knows where to forward packets destined for the MN.

Home network of an application session (or an HoA IP address)

is the network that has allocated the IP address used as the session identifier (HoA) by the application being run in an MN. The MN may be attached to more than one home networks.

3. Mobility Management Logical Functions

The existing mobility management functions of MIPv6, PMIPv6, and HMIPv6 ca be abstracted into the following logical functions:

1. Anchoring: allocation of home network prefix or HoA to an MN that registers with the network;
   
   
2. Mobility Routing (MR) function: packets interception and forwarding to/from the HoA of the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination;
   
   
3. Internetwork Location Management (LM) function: managing and keeping track of the internetwork location of an MN, which includes a mapping of the HoA to the mobility anchoring point that the MN is anchored to;
   
   
4. Location Update (LU): provisioning of MN location information to the LM function;
   
   
5. Routing Control (RC): this logical function configures the forwarding state of the mobility routing function.
   
   

4. Functional Representation of Existing Mobility Protocols

This section shows that existing mobility management protocols can be expressed as different configurations of the logical functions introduced in Section 3 above.

Using these generic logical functions, we will build up the existing mobility protocols one step at a time in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA. Functions are added and modified as needed in each step.

4.1. Mobile IPv6

Figure 1 shows Mobile IPv6 [RFC6275] in a functional representation. The combination of the logical functions MR, LM and HoA allocation in network1 is the home agent or the mobility anchor. The mobile node MN11 was originally attached to Network1 and was allocated the IP prefix for its home address HoA11. After some time, MN11 moved to Network3, from which it is allocated a new prefix to configure the IP address IP32. LM1 maintains the binding HoA11:IP32 so that packets from CN21 in Network2 destined to HoA11 will be intercepted by MR1, which will then tunnel them to IP32. MN11 must perform mobility signaling using the LU function.

 Network1     Network3     Network2
 +-----+ 
 | LM1 | 
 +-----+ 
location=IP32
HoA1 alc      IP3 alc      IP2 alc
    |     
    |     
 +-----+  
 | MR1 |  
 +-----+  
    .     
    .      +----+ +----+    +----+
    .      |MN31| |MN11|    |CN21|
    .      |    | |+LU |    |    |
    .      +----+ +----+    +----+
  HoA11     IP31   IP32,  
                   HoA11 
      	

Figure 1. Functional decomposition of Mobile IPv6.

4.2. MIPv6 versus PMIPv6

MIPv6 and PMIPv6 both employ the same concept of separating the session identifier from the routing address into the HoA and CoA, respectively. Figure 2 contrasts (a) MIPv6 and (b) PMIPv6 by showing the destination IP address in the network-layer header as a packet traverses from a CN to an MN.

(a) MIPv6:
+---+     +---+---+     +---+
|HoA| --> |HoA|HoA|     |HoA|
|   |     |   |---|     |---|
|   |     |   |CoA| ==> |CoA|
+---+     +---+---+     +---+
 CN          MR         MN+LU

(b) PMIPv6:
+---+     +---+---+     +---+---+     +---+
|HoA| --> |HoA|HoA|     |HoA|HoA| --> |HoA|
|   |     |   |---|     |---|   |     |   |
|   |     |   |CoA| ==> |CoA|   |     |   |
+---+     +---+---+     +---+---+     +---+
 CN          MR           AR+LU         MN
      	

Figure 2. Network layer in the protocol stack of packets sent from the CN and tunneled (a) to the MN+LU in MIPv6; and (b) to the AR+LU in PMIPv6 showing the destination IP address as the packet traverses from the CN to the MN.

Figure 2 shows that, as far as data-plane traffic is concerned, routing from CN to MN+LU in MIPv6 is similar to the route from CN to AR+LU in PMIPv6. The difference is in that the MN with the LU function is substituted by the combination of the AR with the LU function and the MN. While additional signaling is needed to enable the combination of AR+LU and MN to behave like MN+LU, such signaling can be confined between the AR+LU and MN only. It can therefore be seen under this unified formulation, that a host-based mobility management protocol can be translated using this substitution into a network-based mobility management protocol and vice versa.

MIPv6 and PMIPv6 bundle all three mobility management logical functions: LM1, IP1 prefix allocation, and MR1 into the home agent (HA) and Local Mobility Anchor (LMA) respectively.

The functional representation of Proxy Mobile IPv6 [RFC5213] is shown in Figure 3. In PMIPv6, the combination of LM, MR, and HoA allocation is the Local Mobility Anchor (LMA), whereas the AR+LU combination together with additional signaling with MN comprises the Mobile Access Gateway (MAG). Here MN11 is attached to the access router AR31 which has the IP address IP31 in Network3. LM1 maintains the binding HoA11:IP31. The access router AR31 also behaves like a home link to MN11 so that MN11 can use its original IP address HoA11.

 Network1     Network3     Network2
 +-----+ 
 | LM1 | 
 +-----+ 
HoA1 alc      IP3 alc      IP2 alc
    |     
    |     
 +-----+  
 | MR1 |  
 +-----+  
    .     
    .      +----+           +----+
    .      |AR31|           |CN21|
    .      |+LU |           |    |
    .      +----+           +----+
  HoA11     IP31         
              |   
              |   
           +----+ 
           |MN11| 
           +----+ 
            HoA11 
      	

Figure 3. Functional representation of PMIPv6.

4.3. Hierarchical Mobile IPv6

The functional representation of Hierarchical Mobile IPv6 [RFC5380] is shown in Figure 4.

 Network1     Network3     Network2
 +-----+ 
 | LM1 | 
 +-----+ 
HoA1 alc      IP3 alc      IP2 alc
    |    
    |    
 +-----+      +-----+  
 | MR1 |      | MR3 |  
 |     |      |+ LM |
 |     |      |proxy|
 +-----+      +-----+  
    .           / \
    .          /   \
    .         /     \
    .      +----+ +----+    +----+
    .      |AR31| |MN11|    |CN21|
    .      |+LU | |+LU |    |    |
    .      +----+ +----+    +----+
  HoA11     IP31   IP32, 
              |    HoA11
              |   
           +----+ 
           |MN31| 
           +----+ 
      	

Figure 4. Functional representation of Hierarchical Mobile IPv6.

Besides the logical functions: LM1, MR1, and HoA1 prefix allocation in Network1 as MIPv6 in Figure 2 and PMIPv6 in Figure 3, there is an MR function (MR3) in the visited network (Network3). MR3 is also a proxy between LM1 and MN11 in the hierarchical LM function LM1--MR3--MN11. That is, LM1 maintains the LM binding HoA11:MR3 while MR3 keeps the LM binding HoA11:IP32. The combined function of MR and the LM proxy function is the Mobility Anchor Point (MAP).

In Figure 4, if MN11 takes the place of MN31 which is attached to AR31, the resulting mobility management becomes network-based.

4.4. Distributing mobility anchors

It is possible to repeat the mobility anchoring function for any of MIPv6, PMIPv6, or HMIPv6, in multiple networks as shown in Figure 5 which shows such an example with three networks.

 Network1     Network3     Network2
 +-----+      +-----+      +-----+
 | LM1 |      | LM3 |      | LM2 |
 +-----+      +-----+      +-----+
HoA1 alc     HoA3 alc     HoA2 alc
    |            |            |
    |            |            |
 +-----+      +-----+      +-----+
 | MR1 |      | MR3 |      | MR2 |
 +-----+      +-----+      +-----+
    .           / \
    .          /   \
    .         /     \
    .      +----+ +----+    +----+
    .      |AR31| |MN11|    |CN21|
    .      |+LU | |+LU |    |    |
    .      +----+ +----+    +----+
  HoA11     IP31   IP32, 
              |    HoA11
              |   
           +----+ 
           |MN31| 
           +----+ 
      	

Figure 5. Functional representation of distributing mobility anchors.

4.5. Migrating Home Agents

When all these logical functions are bundled into one single entity e.g., a home agent in MIPv6 or a local mobility anchor in PMIPv6, in a single network, the result is triangular routing when the MN and the CN are in networks close to each other but are far from the anchor point.

A method to solve the triangle routing problem is to duplicate the anchor points in many networks in different geographic locations as in [Paper-Migrating.Home.Agents]. A functional representation of Migrating Home Agents is shown in Figure 6.

 Network1     Network3     Network2
 +-----+      +-----+      +-----+
 | LM0 |------| LM0 |------| LM0 |
 +-----+      +-----+      +-----+
HoA1 alc     HoA3 alc     HoA2 alc
    |            |            |
    |            |            |
 +-----+      +-----+      +-----+
 | MR1 |      | MR3 |      | MR2 |
 +-----+      +-----+      +-----+
    .           / \
    .          /   \
    .         /     \
    .      +----+ +----+    +----+
    .      |AR31| |MN11|    |CN21|
    .      +----+ +----+    +----+
  HoA11     IP31   IP32, 
              |    HoA11
              |   
           +----+ 
           |MN31| 
           +----+ 
      	

Figure 6. Functional representation of Migrating Home Agents.

Here, the MR function is available in each of the three networks Network1, Network2, and Network3. The LM function in each network (LM0) contains the LM information for all networks. Each MR in each network advertises the HoA IP prefixes of all these networks using anycast. Traffic from CN21 in Network2 destined to HoA11 will therefore be intercepted by the MR nearest to CN, which is MR2. Using the LM information in LM0, MR2 will use the binding HoA11:IP32 to tunnel the packets to MN11.

Similarly, traffic originating from MN11 will be served by its nearest MR (MR3). Triangular routing is therefore avoided. Yet the synchronization of all home agents becomes a challenge as discussed in [Paper-SMGI]. In addition, the amount of signaling traffic needed in synchronizing the home agents may become excessive when both the number of mobile nodes and the number of home agents increase.

As before, if MN11 in Figure 6 takes the place of MN31 which is attached to AR31, the resulting mobility management becomes network-based.

5. DMM Functional Scenarios

This section covers the functional description of DMM. Basically, the scenario presents a way to distribute the logical mobility functions. Gap analysis will be made on the functional scenarios.

5.1. Flat Network Scenario

In a flat network, the logical functions in the functional representation may all be located at the AR as shown in Figures 7 and 8, respectively. These two figures depict the network- and client-based distributed mobility management scenarios. The AR is expected to support the HoA allocation function. Then, depending on the mobility situation of the MN, the AR can run different functions:

1. the AR can act as a legacy IP router;
   
   
2. the AR can provide the MR function (i.e. act as mobility anchor);
   
   
3. the AR can provide the LU functions;
   
   
4. the AR can provide both MR and LU functions.
   
   

For example, [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed-anchoring] are PMIPv6 based implementation of this scenario.

5.1.1. Network-based Mobility Management

The functional description of network-based mobility management is depicted in Figure 7.

In case (1), MN1 attaches to AR1. AR advertises prefix HoA1 to MN1 and then acts as a legacy IP router. MN1 initiates a communication with CN11.

In case (2), MN1 performs a handover from AR1 to AR3 while maintaining ongoing IP communication with CN11. AR1 becomes the mobility anchor for the MN1-CN11 IP communication: AR1 runs MR and LM functions for MN1. AR3 performs LU up to the LM in AR1: AR3 indicates to AR1 the new location of the MN1. AR3 allocates a new IP prefix (HoA3) for new IP communications. HoA3 is supposed to be used for new IP communication, e.g., if MN1 initiates IP communication with CN21. AR3 shall act as a legacy IP router for MN1-CN21 communication.

In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP communication with CN11 and CN21. AR1 is the mobility anchor for the MN1-CN11 IP communication. AR3 becomes the mobility anchor for the MN1-CN21 IP communication. Both AR1 and AR3 run MR and LM functions for MN1, respectively, anchoring HoA1 and HoA3. AR2 performs location updates up to the LMs in AR1 and AR3 for respectively relocate HoA1 and HoA3.

            Network1                Network1     Network3
+----+     HoA1 alc     +----+     HoA1 alc      HoA3 al        +----+
|CN11|      +-----+     |CN11|      +-----+      +-----+        |CN21|
|    |------|     |     |    |------| MR1 |------|     |------- |    |
+----+      |     |     +----+      | LM1 |------|LU31 |        +----+
            | AR1 |                 | AR1 |      |AR3  |
            |     |                 |     |      |     |
            +-----+                 +-----+      +-----+
               |                                    |
               |                                    |
               |                                    |
             +----+                               +----+
             |MN1 |                               |MN1 |
             |    |                               |    |
             +----+                               +----+
             HoA11                                HoA11,
                                                  HoA31
       (1)                              (2)

                                                      Network2
                              Network1                HoA2 al
                  +----+     HoA1 alc                 +-----+
                  |CN11|      +-----+                 |     |
                  |    |------| MR1 |-----------------|LU21 |-------+
                  +----+      | LM1 |-----------------|AR2  |       |
                              | AR1 |                 |     |       |
                              |     |      Network3   +-----+       |
                              +-----+      HoA3 al     | |        +----+
                                           +-----+     | |        |MN1 |
                               +----+      |MR3  |------ |        |    |
                               |CN21|      |LM3  |--------        +----+
                               |    |------|     |                HoA11,
                               +----+      |AR3  |                HoA31
                                           +-----+       (3) 
      	

Figure 7. Network-based DMM architecture for a flat network.

5.1.2. Client-based Mobility Management

The functional description of client-based mobility management is depicted in Figure 8.

In case (1), MN1 attaches to AR1. AR advertises the prefix HoA1 to MN1 then acts as a legacy IP router. MN1 initiates a communication with CN11.

In case (2), MN1 performs a handover from AR1 to AR3 with ongoing IP communication with CN11. AR1 becomes the mobility anchor for the MN1-CN11 IP communication: AR1 runs MR and LM functions for MN1. The MN performs LU directly up to the LM in AR1 or via AR3; in this case AR3 acts as a proxy locator (pLU) (e.g. as a FA in MIPv4). AR3 allocates a new IP prefix (HoA3) for new IP communications. HoA3 is supposed to be used for new IP communications, e.g., if MN1 initiates IP communication with CN21. AR3 shall act as a legacy IP router for MN1-CN21 communication.

              Network1                Network1     Network3
  +----+     HoA1 alc     +----+     HoA1 alc                     +----+
  |CN11|      +-----+     |CN  |      +-----+      +-----+        |CN21|
  |    |------|     |     |    |------| MR1 |------|     |------- |    |
  +----+      |     |     +----+      | LM1 |------|pLU31|        +----+
              | AR1 |                 | AR1 |      |AR31 |
              |     |                 |     |      |     |
              +-----+                 +-----+      +-----+
                 |                                    |
                 |                                    |
                 |                                    |
               +----+                               +----+
               |MN1 |                               |MN1 |
               |    |                               |LU31|
               +----+                               +----+
               HoA11                                HoA11,
                                                    IP31

        (1)                              (2)      	

Figure 8. Client-based DMM architecture for a flat network.

5.2. Fully distributed scenario with separation of control and data planes

This scenario considers multiple MRs and a distributed LM database.

The different use case scenarios of distributed mobility management are described in [I-D.yokota-dmm-scenario] as well as in [Paper-Distributed.Mobility.Review]. The architecture described in this document is mainly on separating the data plane from the control plane.

Figure 9 shows an example DMM architecture with the same three networks as in Figure 5. As is in Figure 5, each network in Figure 9 has its own IP prefix allocation function. In the data plane, the mobility routing function is distributed to multiple locations at the MRs so that routing can be optimized. In the control plane, the MRs may exchange signaling with each other. In addition to these features in Figure 5, the LM function in Figure 9 is a distributed database, with multiple servers, of the mapping of HoA to CoA.

 Network1     Network3     Network2
 +-----+      +-----+      +-----+
 | LM1 |      | LM3 |      | LM2 |
 +-----+      +-----+      +-----+
HoA1 alc     HoA3 alc     HoA2 alc
    | \ \      / | \      / / |
    |  \  \   /  |  \   /  /  |
    |   \   \/   |   \/   /   |
    |    \  / \  |  / \  /    |
    |     \/    \|/    \/     |
    |     /\    /|\    /\     |
    |    /  \ /  |  \ /  \    |
    |   /   /\   |   /\   \   |
    |  /  /   \  |  /   \  \  |
    | / /      \ | /      \ \ |
 +-----+      +-----+      +-----+
 | MR1 |------| MR3 |------| MR2 |
 +-----+      +-----+      +-----+
    .           / \
    .          /   \
    .         /     \
    .      +----+ +----+    +----+
    .      |AR31| |MN11|    |CN21|
    .      |+LU | |+LU |    |    |
    .      +----+ +----+    +----+
  HoA11     IP31   IP32, 
              |    HoA11
              |   
           +----+ 
           |MN31| 
           +----+ 
      	

Figure 9. A distributed architecture for mobility management.

To perform mobility routing, the MRs need the location information which is maintained at the LMs. The MRs are therefore the clients of the LM servers and may also send location updates to the LM as the MNs perform the handover. The location information may either be pulled from the LM servers by the MR, or pushed to the MR by the LM servers. In addition, the MR may also cache a limited amount of location information.

This figure shows three MRs (MR1, MR2, and MR3) in three networks. MN11 has moved from the first network supported by MR1 and LM1 to the third network supported by MR3 and LM3. It may use an HoA (HoA11) allocated to it when it was in the first network for those application sessions that had already started when MN11 was attached there and that require session continuity after the handover to the third network. When MN11 was in the first network, no location management is needed so that LM1 will not keep an entry of HoA11. After MN11 has performed its handover to the third network, the database server LM1 maintains a mapping of HoA11 to MR3. That is, LM1 points to the third network and it is the third network that will keep track of how to reach MN11. Such a hierarchical mapping can prevent frequent update signaling to LM1 as MN11 performs intra-network handover within the third network. In other words, the concept of hierarchical mobile IP [RFC5380] is applied here but only in location management and not in routing in the data plane.

6. Security Considerations

TBD

7. IANA Considerations

None

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses