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

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 March 17, 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.  Extensions to Binding Cache Entry
        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 extension
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.) can support multihoming. The Mobile Node (MN) can send simultaneously packets to the PMIPv6 domain over multiple interfaces. However it cannot support flow mobility due to the following limitations:

• When a flow moves from an interface to a new interface, the HNP used by that flow will be assigned to the new interface. This action can discontinue the ongoing sessions on both interfaces.
• Since a home network prefix (HNP) can be shared by multiple flows, when only some of these flows are moved to a new interface, the old interface and the new interface should be able to share the same HNP. That is not supported by the current PMIPv6 standard since it supports only Per-MN-Prefix model.
• To move a flow to a new interface, the network should be able to perform flow-based routing function which is not supported by the current PMIPv6 standard.

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 way, the HNPs assigned to the MN are always shared across its attachments in advanced. Therefore the LMA can move flows from an attachment to another freely and 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 the 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 of the MAG1 and the MAG2 can forward the packets of the HNP1 as well as the 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 the HNP1, from the MAG1 to the 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 new HNPs assigned to the new attachment and the old HNPs assigned to the current MN's attachments.
• Extend the MAG and the LMA to enable them to exchange the HUR and the HUA message.

2.1.2.  Re-active Signaling

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

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

    +--+              +----+              +----+              +---+
    |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 IF2. The flow 1 is forwarded by the MAG1 and uses HNP1. When the LMA decides to move flow 1 to the MAG2, it sends a HUR message including the HNP1 to the MAG2. 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 1 from MAG1 to MAG2.

The key different 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 advanced. Each attachment will be assigned a unique HNP(s) as described in the standard RFC5213. In this example, the HNP1 is shared on the MAG2 only when the flow1, which uses HNP1, is moved to the MAG2.

With this approach, the implementations need only to extend the MAG and LMA to enable them to exchange HUR and HUA when necessary.

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 want to move a flow, it just changes the binding of the flow to another Proxy-CoA (MAG).

2.2.1.  Extensions to Binding Cache Entry

When the MN attaches to the network by using multiple interfaces simultaneously, the LMA should bind the MN to multiple care-of addresses. As provided in [2] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), the MN is allowed to register multiple care-of address for a home address. A new binding identification number is created by the LMA for each binding the MN wants to register.

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

The detail usage of each field and the description of the example in table 2 are provided in [3] (Tsirtsis, G., Soliman , H., Montavont , N., Giaretta , G., and K. Kuladinithi , “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” August 2010.)

3.  Protocol Operations

3.1.  Local Mobility Anchor Operation

3.1.1.  Sending Home Network Prefix Update Request Message

When a HNP 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 tunnel and update the routing path for the HNP. Depending on the way that implementation selects, 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 receives 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, first it checks whether the HNP used by the flow is valid on the destination MAG or not by checking the existing binding cache entries of the MN. If it is valid then the LMA just updates the flow binding cache entry list. If it is not valid then 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 updates the flow binding entry list to forward the flow to the new updated binding cache entry.

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

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 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:

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

• Acknowledge (A): The Acknowledge (A) bit is set by the LMA to request an HNP update Acknowledgement be returned upon receipt of the Binding Update.
• Message type (T): The Message type (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:

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

• The Message type (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 extension

The data structure of the extended PBU message is described as following:

	   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's policy profile. In this 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 F 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