Flow mobility support in PMIPv6
draft-trung-netext-flow-mobility-support-01

Abstract

To support flow mobility in PMIPv6, the Mobile Node's Home Network Prefix should be able to be shared across its attachments and the network should support flow-based routing. This document specifies how to extend PMIPv6 to meet these requirements.

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 April 28, 2011.

Copyright Notice

Copyright (c) 2010 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
2.  PMIPv6 Extensions
    2.1.  Shared-Prefix Model Support
        2.1.1.  Proactive Signaling
        2.1.2.  Re-active Signaling
    2.2.  Flow-Based Routing Support
        2.2.1.  Multiple Care-of Address Registration
        2.2.2.  Flow Binding Cache Entry List
3.  Protocol Operations
    3.1.  Local Mobility Anchor Operation
        3.1.1.  Sending Home Network Prefix Update Request Message
        3.1.2.  Receiving Home Network Prefix Update Acknowledgement Message
        3.1.3.  Moving a Flow
    3.2.  Mobile Access Gateway Operation
        3.2.1.  Receiving Home Network Prefix Update Request Message
        3.2.2.  Sending Home Network Prefix Update Acknowledgement Message
    3.3.  Mobile Node Operation
4.  Messages format
    4.1.  Home Network Prefix Update Request (HUR)
    4.2.  Home Network Prefix Update Acknowledgement Message (HUA)
    4.3.  Proxy Binding Update extensions
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Proxy Mobile IPv6 (PMIPv6) [1] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) allows mobile nodes to connect to the network through multiple interfaces for simultaneous access. The Mobile Node (MN) can send simultaneously packets to the PMIPv6 domain over multiple interfaces. However it cannot performs flow mobility due to some limitations as follows:

• The PMIPv6 can only support IP mobility: In PMIPv6, when the mobile node performs handover from a network to another, all of the IP flows are moved to the new network. However, the flow mobility requires to support moving just some of the selected flows to the new network, while the other flows are kept transmitting on the old one.
• The PMIPv6 can only support Per-MN-Prefix model: Basically, a home network prefix (HNP) can only be assigned to a single interface at one time. However in a real system, multiple flows can be associated with a HNP. When the flow mobility occurs, some of these flows are moved to a new interface, while the other flows are kept transmitting via the old interface. To keep the sessions continuing the HNP should be preserved during the movement of the flows. It means that the HNP should be able to be assigned simultaneously to multiple interfaces.
• The PMIPv6 does not support flow-based routing: Normally, the network can only route a packet at IP-based level. However to route packet at flow-based level, it should be able to classify the packets at flow level and then apply the same policy to the packets that has the same flow information.

To support flow mobility in PMIPv6, we first utilize the advantage of the logical interface at the MN to hide the changing at physical interfaces from the IP layer and then extend the operations of PMIPv6 to allow the HNP to be able to be shared across interfaces as well as to support flow-based routing functions.

2.  PMIPv6 Extensions

This section introduces the necessary extensions of the PMIPv6 to support flow mobility.

2.1.  Shared-Prefix Model Support

The first requirement for supporting flow mobility is that the PMIPv6 should be extended to support shared-prefix model. Since multiple flows can share the same HNP and each flow can be forwarded to different attachment, the HNP should be shared across attachments. This specification recommends the implementations to extend PMIPv6 in two ways, proactive and reactive signaling approach.

2.1.1.  Proactive Signaling

With the proactive signaling approach, an HNP is shared across attachments immediately when it is assigned to the MN.

When the Local Mobility Anchor (LMA) assigns a new HNP to the MN, it will immediately signal this HNP to all of the Mobile Access Gateways (MAG) that the MN attaches to. By doing this, the HNPs assigned to the MN are always shared across its attachments in advance. Therefore the LMA can move flows from an attachment to another in a free manner without any extra signaling messages.

    +--+              +----+              +----+              +---+
    |MN|              |MAG1|              |MAG2|              |LMA|
    +--+              +----+              +----+              +---+
     |                   |                  |                   |
    IF1<--Rtr Adv(HNP1)--|                  |                   |
     |                   |                  |                   |
IF1(HNP1)<--- Flow 1 --->|<-------------- Flow 1 -------------->|
     |                   |                  |                   |
MN Attached              |                  |                   |
   Via IF2               |                  |                   |
     |                   |                  |                   |
     |--- Rtr Sol ------------------------->|                   |
     |                   |                  |                   |
     |                   |                  |---- PBU (H=1) --->|
     |                   |                  |                   |
     |                   |                  |<--PBA(HNP1,HNP2)--|
     |                   |                  |                   |
     |                   |                  |== Bi-Dir Tunnel ==|
     |                   |                  |                   |
     IF2 <--------Rtr Adv (HNP1,HNP2)-------|
     |                   |                  |                   |
     |                   |<----------- HUR (HNP2) --------------|
     |                   |                  |                   |
     |              Accept HUR              |                   |
     |       Set Up Tunnel and Routing      |                   |
     |                   |                  |                   |
     |                   |------- HUA ------------------------->|
     |                   |                  |                   |
     |                   |                  |               Accept HUA
     |                   |                  |            Update BCE and
     |                   |                  |             Setup Tunnel
     |                   |                  |                   |
     |                   |=========== Bi-Dir Tunnel ============|
     |                   |                  |                   |
    IF1<-Rtr Adv(HNP1,2)-|                  |            Decide to Move
     |                   |                  |            flow 1 to MAG2
     |                   |                  |                   |
     |                   |                  |              Update Flow
     |                   |                  |             binding table
     |                   |                  |                   |
   IF2<-------------- Flow 1 -------------->|<----- Flow 1 ---->|
(HNP1,HNP2)              |                  |                   |
     |                   |                  |                   |

Figure 1 (Call flow for proactive signaling approach) shows signaling call flow the of proactive signaling approach. First, the MN attaches to the MAG1 using the physical interface IF1. The network assigns HNP1 to the IF1. Next, the MN performs new attachment via the physical interface IF2. The MAG sends a Proxy Binding Update (PBU) message with HI=1 to inform the LMA. If the LMA recognizes that the MN can support flow mobility, it will assign both new HNP2 and the old HNP1 to the new attachment. Upon accepting this PBU message, the LMA sends a Proxy Binding Acknowledgement (PBA) message including both of the HNP1 and HNP2 to the MAG2. It also signals MAG1 to update with the new HNP2 by sending an Home Network Prefix Update Request (HUR) to the MAG1. On receiving the HUR message, the MAG1 setups tunnel and routing path for the HNP2 and sends back an Home Network Prefix Update Acknowledgement Message (HUA) to inform the LMA that it is ready for forwarding the packets of the HNP2.

After the above steps, both MAG1 and MAG2 can forward the packets of both HNP1 and HNP2. Therefore the LMA can move flows between two attachments freely without any extra signaling messages. For example the LMA can move the flow 1, which uses HNP1, from MAG1 to MAG2 immediately because the MAG2 is already enabled for forwarding the packets of the HNP1.

With this approach, the implementations need to do two extensions:

• Extend the PBA message to include both the new HNP assigned to new attachment and the HNPs that are already assigned to the existing MN's attachments.
• Extend the MAG and LMA to enable them to exchange HUR and HUA.

2.1.2.  Re-active Signaling

With the re-active signaling approach, an HNP is shared with another attachment only when a flow is moved to an attachment which the HNP associated to that flow is not valid.

When the LMA decides to move a flow and realizes that the HNP used by that flow is not valid on the destination MAG, it will signal the HNP to that MAG. By doing this, an HNP will be shared on the destination MAG only when the flow associating with it is moved to a destination MAG that it is not valid.

    +--+              +----+              +----+              +---+
    |MN|              |MAG1|              |MAG2|              |LMA|
    +--+              +----+              +----+              +---+
     |                   |                  |                   |
    IF1<--Rtr Adv(HNP1)--|                  |                   |
     |                   |                  |                   |
IF1(HNP1)<--- Flow 1 --->|<-------------- Flow 1 -------------->|
     |                   |                  |                   |
MN Attached              |                  |                   |
   Via IF2               |                  |                   |
     |                   |                  |                   |
     |--- Rtr Sol ------------------------->|                   |
     |                   |                  |                   |
     |                   |                  |---- PBU (H=1) --->|
     |                   |                  |                   |
     |                   |                  |<----PBA(HNP2)-----|
     |                   |                  |                   |
     |                   |                  |== Bi-Dir Tunnel ==|
     |                   |                  |                   |
    IF2 <------------Rtr Adv (HNP2)---------|                   |
     |                   |                  |                   |
     |                   |                  |                   |
     |                   |                  |            Decide to Move
     |                   |                  |            flow 1 to MAG2
     |                   |                  |                   |
     |                   |                  |                   |
     |                   |                  |<--- HUR (HNP1) ---|
     |                   |                  |                   |
     |                   |              Accept HUR              |
     |                   |        Set Up Tunnel and Routing     |
     |                   |                  |                   |
     |                   |                  |---- HUA --------->|
     |                   |                  |                   |
     |                   |                  |               Accept HUA
     |                   |                  |            Update BCE and
     |                   |                  |             Setup Tunnel
     |                   |                  |                   |
     |                   |                  |== Bi-Dir Tunnel ==|
    IF2 <--------Rtr Adv (HNP1,HNP2)--------|                   |
     |                   |                  |              Update Flow
     |                   |                  |             binding table
     |                   |                  |                   |
    IF2<------------- Flow 1 -------------->|<----- Flow 1 ---->|
(HNP1,HNP2)              |                  |                   |
     |                   |                  |                   |

Figure 2 (Call flow for proactive signaling approach) shows the signaling call flow of re-active signaling approach. First, the MN attaches to the network using 2 interfaces, IF1 and IF2. The network assigns HNP1 to the IF1 and HNP2 to the HNP2. The flow 1 is forwarded by the MAG1 and uses HNP1. When the LMA decides to move flow 1 to the MAG2, it signals MAG2 to update with the HNP1 by sending a HUR message. On receiving the HUR message, the MAG2 setups routing path for the HNP1 and sends back a HUA message to inform the LMA that it is ready for forwarding the packets of HNP1. After receiving HUA from the MAG2, the LMA can update flow binding table to move the flow 2 from MAG1 to MAG2.

The key difference between proactive and reactive approach is that in the case of the re-active approach, the HNPs assigned to the MN is not shared across attachments in advance. Each attachment will be assigned with a unique HNP as described in the PMIPv6 standard [1]. The HNP1 is shared on the MAG2 only when the flow 1, which is associated with the HNP1, is moved to the MAG2.

With the re-active approach, the implementations need only to extend the MAG and LMA to enable them to exchange HUR and HUA when the flow mobility occurs.

2.2.  Flow-Based Routing Support

The second requirement for supporting flow mobility is that the PMIPv6 should be able to bind a particular flow to a Proxy-CoA without affecting other flow using the same HNP. This specification allows the LMA to bind a HNP to multiple Proxy-CoAs (MAGs) and then allows it to bind a particular flow to a Proxy-CoA. When the LMA wants to move a flow, it just changes the binding of the flow to another Proxy-CoA (MAG) as showed in the table Table 5 (The Flow Binding Cache Entry list before the LMA receiving the HUA) and Table 6 (The Flow Binding Cache Entry list after the LMA receiving the HUA). To do that the PMIPv6 need to be extended as following:

2.2.1.  Multiple Care-of Address Registration

The LMA is extended to allow a mobile node to register multiple proxy care of address (Proxy-CoA), which is the same situation as described in the [2] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.). The LMA maintains multiple binding cache entries for a MN. The number of binding cache entries of a MN is equal to the number of the MN’s interfaces attaching to the MAG.

Table 1 (The Binding Cache Entry list) shows two Binding Cache Entries of the MN1 when it attaches to the network using two different access technologies. Both of the two attachments share HNP1 and are bounded to two different Proxy-CoAs.

2.2.2.  Flow Binding Cache Entry List

Each LMA must maintain a flow binding table as shown in Table 1 (The Binding Cache Entry list). This table contains entry for each flow sent from the MN. A flow binding entry includes the following fields:

• Flow Identifier - Priority (FID-PRI)
• Flow Identifier (FID)
• Traffic Selector (TS)
• Binding Identifier (BID)
• Action
• Active/Idle

The BIDs field contains the identifier of the binding cache entry that all of the packets matching the flow information described in the TS field will be forwarded to. When the flow mobility occurs, the BIDs will be updated with new binding cache entry identifier.

Similar to flow binding described in [3] (Tsirtsis, G., Soliman , H., Montavont , N., Giaretta , G., and K. Kuladinithi , “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” August 2010.), each flow binding entry points to a specific binding cache entry identifier (BID). When the LMA decides to move a flow, it simply updates the pointer of the flow binding entry with the BID of the interface to which the flow will be moved. The traffic selector (TS) in flow binding table is defined as in [3] (Tsirtsis, G., Soliman , H., Montavont , N., Giaretta , G., and K. Kuladinithi , “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” August 2010.). TS is used to classify the packets of flows basing on specific parameters such as service type, source and destination address … The packets matching with the same TS will be applied with the same forwarding policy.

3.  Protocol Operations

3.1.  Local Mobility Anchor Operation

3.1.1.  Sending Home Network Prefix Update Request Message

When a HNP is needed to be shared on a MAG, the LMA will send an HUR message including the HNP to that MAG to request it to setup a tunnel and update the routing path for the HNP. Depending on the way of implementation, proactive or reactive signaling approach, the trigger for sending an HUR message is different. With proactive signaling approach, the HUR will be initiated whenever a new HNP is assigned to the MN. In contrast, with the reactive signaling approach, the HUR will be initiated only when the LMA decides to move a flow and the HNP used by that flow is not valid on the destination MAG.

3.1.2.  Receiving Home Network Prefix Update Acknowledgement Message

After sending HUR, the LMA waits for the HUA sent back from MAG. On receiving the HUA, the LMA update binding cache to bind the HNP to an extra Proxy-CoA.

Table 3 (The Binding Cache Entry list before the LMA receiving HUA) and Table 4 (The Binding Cache Entry list after the LMA receiving HUA) show the Binding Cache Entries of the MN1 before and after the LMA receive HUA message from the MAG2.

In the Table 3 (The Binding Cache Entry list before the LMA receiving HUA) the HNP1 is bounded to the IP1 of MAG1 only. After the LMA sends HUR to request the MAG2 update with the HNP1. Then the HNP1 is now also bounded IP2 of the MAG2 as showed in the Table 4 (The Binding Cache Entry list after the LMA receiving HUA)

3.1.3.  Moving a Flow

When the LMA decides to move a flow, it first checks whether the HNP used by that flow is valid on the destination MAG or not by checking the existing binding cache entries of the MN. If it is valid, the LMA just updates the flow binding cache entry list with new BID. If it is not valid the LMA sends HUR message to request the destination MAG to update with the HNP used by the flow. After that, if the MAG sends an HUA message to the LMA, the LMA will update the binding cache entry to bind the HNP to new Proxy-CoA and then update the flow binding entry list with the destination BID.

Table 5 (The Flow Binding Cache Entry list before the LMA receiving the HUA) and Table 6 (The Flow Binding Cache Entry list after the LMA receiving the HUA) show the flow binding list entry before and after it is updated. In the Table 5 (The Flow Binding Cache Entry list before the LMA receiving the HUA), the flow 1 is associated with the binding cache entry 1. It means that the flow 1 is forwarded via the Proxy-CoA of the MAG1. After that the LMA updates the flow binding list entry with new binding cache entry 2. The flow 1 is now associated with the Proxy-CoA 2 of the MAG2 as shown in the Table 6 (The Flow Binding Cache Entry list after the LMA receiving the HUA). Thus the flow 1 is successfully moved from MAG1 to MAG2.

3.2.  Mobile Access Gateway Operation

3.2.1.  Receiving Home Network Prefix Update Request Message

On receiving the HUR message, the MAG sets up its endpoint of the bi-directional tunnel to the LMA and also sets up the routing path for the traffic using HNP included in the HUR.

3.2.2.  Sending Home Network Prefix Update Acknowledgement Message

After setting up the tunnel and routing path for new HNP successfully, the MAG sends HUA including the HNP to inform the LMA that the flows using HNP can be forwarded via the MAG.

3.3.  Mobile Node Operation

For simplicity, we assume that the MN uses a single logical interface to hide all of its available physical interfaces. The detail discussion about LGI is provided in [4] (Melia, T. and S. Gundavelli, “Logical Interface Support for multi-mode IP Hosts, draft-ietf-netext-logical-interface-support-00,” August 2010.).

On receiving a downlink traffic flow, the MN always selects the same path for sending the uplink traffic flow. For example, if the mobile node attaches to the network using two physical interfaces, IF1 and IF2. If the downlink traffic of the flow 1 is received from the IF1 then the uplink traffic of the flow 1 will also be sent via the IF1. When the flow 1 is moved to attachment of the IF2, then the path for sending uplink traffic of the flow 1 is also changed to the IF2.

4.  Messages format

4.1.  Home Network Prefix Update Request (HUR)

The data structure of the HUR is described as following [Figure 3 (The data structure of the HUR)]:

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |          Sequence #           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|T|          Reserved         |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Acknowledge (A): The A bit is set by the LMA to request an HNP update acknowledgement to be returned upon receipt of the HUR
• Message type (T): The T bit is set by LMA to indicate that it is a HNP update request message.
• The mobility options: The mobility option field is a variable-length field. It contains all new HNPs that are assigned to the new attachment of the MN.

4.2.  Home Network Prefix Update Acknowledgement Message (HUA)

The data structure of the HUA is described as following [Figure 4 (The data structure of the HUA)]:

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |    Status     |T|  Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Sequence #          |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

•  Message type (T): The T bit is set by MAG to indicate that it is a HUA.
• The mobility options: The mobility option field is a variable-length field. It contains the HNP that is needed to be shared.

4.3.  Proxy Binding Update extensions

The data structure of the extended PBU message is described as following [Figure 5 (The data structure of the PBU)]:

	   0               1               2               3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |            Sequence #         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|K|M|R|P|F|    Reserved   |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Mobility options                       .
      .                                                               .

      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A new flag (F) is included in the Binding Update Massage to indicate to the LMA that the MN can support flow mobility. This field is necessary only when the LMA cannot acquire information about flow mobility capacity of the MN from the MN policy profile. In that case, the MN will signal the MAG about its flow mobility capacity by using layer 2.5 signaling message. The MAG then set the value of F flag to inform the LMA about the flow mobility capacity of the MN. The flag MUST be set to 1 if the MN can support flow mobility and MUST be set to 0 if the MN cannot support flow mobility.

5.  Security Considerations

This document doesn't intend to provide the NETEXT security analysis but one will be required.

6.  IANA Considerations

This document has no actions for IANA.

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses