Flow tracking procedure for PMIPv6
draft-trung-netext-flow-tracking-01

Abstract

A mobile node (MN) can connect to the network by using multiple interfaces simultaneously or sequentially. The quality of each connection can be changed due to many reasons such as the movement of the MN and the interference from the network. To guarantee the quality of service, some flows can be moved from a bad connection to another better one. In this draft we discuss about how to extend the Proxy Mobile IPv6 (PMIPv6) to support such kind of flow mobility.

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 January 13, 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.  Design assumptions for supporting flow mobility
    2.1.  Logical Interface at the mobile node
3.  Flow mobility triggers
4.  Flow mobility scenarios
    4.1.  Scenario 1: Flow mobility between an existing attachment to a new attachment
    4.2.  Scenario 2: Flow mobility among existing attachments
        4.2.1.  The MN moves flows
        4.2.2.  The LMA moves flows
5.  LMA extensions
    5.1.  Flow identifier management
    5.2.  Binding Cache Entry extension
    5.3.  Prefix model for the logical interface
    5.4.  Signaling considerations
        5.4.1.  Processing Proxy Binding Updates messages
        5.4.2.  Sending Proxy Binding Acknowledgement messages
6.  MAG extensions
    6.1.  Flow identifier management
    6.2.  Binding Update List Entry extension
    6.3.  Signaling consideration
        6.3.1.  Sending Proxy Binding Update messages
        6.3.2.  Processing Flow Binding Acknowledgement
7.  Message format extensions
    7.1.  Proxy Binding Update messages
    7.2.  Proxy Binding Acknowledgement
8.  Security Considerations
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.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 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.[3] (Sarikaya, B. and F. Xia, “PMIPv6 Multihoming Support for Flow Mobility, draft-sarikaya-netext-fb-support-extensions-00 (work in progress),” February 2010.)
• Since a home network prefix (HNP) can be shared by multiple flows, when only some of these flows is 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.
• After moving flows to a new interface, if these flows share the same HNP then the MAG and LMA should be able to forward flows basing not only on HNP but also flow identification. That routing capability is not supported by the current PMIPv6 standard.

To enable PMIPv6 to support flow mobility, we first utilize the advantage of the logical interface at MN to hide the changing at physical interfaces from the IP layer and then extend the operations of PMIPv6 to perform flow-based routing functions.

Several documents also introduce solutions for flow mobility. The authors in [4] (Koodli, Rajeev. and Kuntal. Chowdhury , “Flow Handover for Proxy Mobile IPv6, draft-koodli-netext-flow-handover-01 (work in progress),” October 2009.) specify a network-controlled protocol to handover application flows from one interface to another. The I-D [5] (Xia, F., “Flow Binding in Proxy Mobile IPv6,draft-xia-netext-flow-binding-02 (work in progress),” June 2010.) introduces extensions to Proxy Mobile IPv6 that allows networks dynamically binding IP flows to different interfaces of a mobile node. The author in [6] (Bernardos, CJ., Jeyatharan, M., R. Koodli, R., Melia, T., and F. Xia, “Proxy Mobile IPv6 Extensions to Support Flow Mobility , draft-bernardos-netext-pmipv6-flowmob-00,” July 2010.) describe a mechanism to support flow mobility on a logical interface over multiple physical interfaces.

Our document is different from all of others in the way that we first discuss about the flow mobility triggers and then according to each kind of trigger we discuss about the necessary extensions of PMIPv6 to support flow mobility. We introduce two flow mobility scenarios. The first scenario discuss about flow mobility between an existing attachment and a new attachment. The second scenario discuss about flow mobility between existing attachments. Our solutions do not require much changes of the PMIPv6. All necessary changes are slightly extending the original operation and data structure of the PMIPv6. It is very easy to implement from the original standard of PMIPv6

2.  Design assumptions for supporting flow mobility

2.1.  Logical Interface at the mobile node

To support flow mobility, we assume that the MN use link layer implementation to hide the actually used physical interfaces from the IP stack [7] (Melia, T. and S. Gundavelli, “Logical Interface Support for multi-mode IP Hosts, draft-melia-netext-logical-interface-support-01 (work in progress),” July 2010.). It provides a logical interface at the IP layer and enables packet transmission and reception over different physical interface. The following are necessary requirements of the virtual interface to support flow mobility:

• The logical interface can simultaneously and/or sequentially attach to multiple MAGs
• The logical interface can be configured with a single or multiple HNP
• The logical interface can accept all the packets that have valid HNP and received from any physical interface that is abstracted by the logical interface
• The logical interface should send and receive a flow via the same interface
• The logical interface can map a flow to a physical interface dynamically basing on the network condition. This operation can be performed by the connection manager. The detail discussion about this operation is out of scope of this draft [8] (Hong, Y. and J. Youn, “Virtual network interface model for multiple network interfaces in a host, draft-hong-mif-virtual-interface-00 (work in progress),” March 2009.)

3.  Flow mobility triggers

There are three triggers that can activate the flow mobility procedures as listed as follows:

• Trigger 1: The MN performs an attachment over a new interface. The MAG is aware of that event and sends PBU message with the handoff indicator of 1 (HI=1) to update the LMA about the current position of the MN.
• Trigger 2: MN recognizes the change of network condition and decides to move a flow from a physical interface to another. Since the MN uses logical interface, the movement of a flow between physical interfaces is transparent to the IP layer. The MAG can be aware of this event by analyzing the packets received from the MN, this procedure will be discussed in the next section. After figuring out that it is a new flow sending from the MN, the MAG sends PBU message with an indicator to inform that the MAG receives a new flow from the MN. To do that we need to extend the PBU message formats, which will be discussed more detail in the next section.
• Trigger 3: The LMA determines the flow mobility due to some reasons. For example, the LMA can recognize the change of policy profile which contains the mapping of a flow to an access network technology. Or, the LMA can recognize the change of network condition for wired links as well as wireless links.

According to each kind of the trigger, the MAG and LMA perform a specific flow mobility procedure. These procedures can be added as extensions of the MAG and LMA signaling considerations, which will be discussed more detail in the next section.

4.  Flow mobility scenarios

We consider two flow mobility scenarios. Each of them has different flow mobility triggers and signaling call flow between LMA and MAG.

4.1.  Scenario 1: Flow mobility between an existing attachment to a new attachment

This scenario occurs when the trigger 1 is activated. The LMA is informed about the new attachment of the MN and it realizes that some existing flow are should better moved to the new attachment.

    +-----+          +-----+          +-----+          +-----+
    | MN  |          |p-MAG|          |n-MAG|          | LMA |
    +-----+          +-----+          +-----+          +-----+
       |                |                |                |
      PI1<--- Flow 1 -->|<------------ Flow 1 ----------->|
       |                |                |                |
(1)MN attached          |                |                |
   over PI2             |                |                |
       |                |                |                |
      PI2 ---------- Rtr Sol ----------->|                |
       |                |                |                |
       |                |             (2)|-- PBU (HI=1)-->|
       |                |                |                |
       |                |                |      (3) Setup tunnel,
       |                |                |           update BCE
       |                |                |          (bind flow 1
       |                |                |         to new tunnel)
       |                |                |                |
       |                |                |<--- Reg PBA ---| (4)
       |                |                |    (S=1,F=1)   |
       |                |                |                |
       |                | (5) Accept PBA, setup Tunnel,   |
       |                |      Add Flow 1 to the BULE,    |
       |                |     Setup routing for Flow 1    |
       |                |                |                |
       |                |<----- De-Reg PBA (S=1,F=0) -----| (6)
       |                |                |                |
       |   (7)   Remove the binding      |                |
       |       and routing for Flow 1    |                |
       |                |                |                |
  (8) IF2 <--------- Flow 1 ------------>|<--- Flow 1 --->|
       |                |                |                |

The Figure 1 (Flow mobility between an existing attachment to a new attachment) shows the signaling call flow of the scenario 1. In this figure, the MN is equipped with 2 physical interfaces, PI1 and PI2. First, the flow 1 is served by the PI1, which is the only PI attaching to the p-MAG. Next, the MN attaches to the n-MAG over the PI2. On recognizing the new attachment from the MN, the n-MAG informs the LMA by sending a PBU message with the HI=1. The LMA, on receiving the PBU message, setups a new tunnel and lookups for all of the flows that is serving for the MN. For each of flow, the LMA will check the MN profile and the operator policy to figure out the flows that need to be moved to the new attachment. In this figure the LMA decides to move flow 1 from the attachment of PI1 to that of PI2. It updates the extended BCE to bind the flow 1 to the Proxy-CoA of the n-MAG and then sends an extended Reg-PBA message, which has the indicator 'S'=1 and 'F'=1, to inform the n-MAG to update BULE and setup routing for the flow 1. The LMA also send an extended De-Reg-PBA message, which has the indicator 'S'=1 and 'F'=0, to inform the p-MAG to remove the flow 1 from BULE and routing table. After completing these processes, the flow 1 will be exchange via the attachment of the PI2 to n-MAG.

4.2.  Scenario 2: Flow mobility among existing attachments

This scenario occurs when the trigger 2 or 3 is activated

4.2.1.  The MN moves flows

The Figure 2 (The signaling call flow of the scenario 1 with the trigger 2) shows the signaling call flow of the scenario 2 with the trigger 2. In this example, the MN is equipped with 2 physical interfaces PI1 and PI2. Both PI1 and PI2 attach to the network via p-MAG and n-MAG. At the first time, the flow 1 is served by the PI1. As time goes by, the MN detects that the condition of the attachment via PI2 is better for serving the flow 1 and it decides to switch the flow 1 from PI1 to PI2. Since we assume that the MN uses logical interface, the switching process is performed at link-layer and transparent to the IP layer. When the n-MAG receives the first packet of the flow 1, it analyzes the flow information from the packet header and lookups for the same flow in the extended BULE. If it cannot find any the same flow, an extended PBU message will be sent to the LMA. The LMA then lookups for the similar flow in the extended BCE to check if it is a flow moved from an existing attachment. If it is yes, then the LMA update BCE to bind the flow 1 to the Proxy-CoA of the n-MAG and then sends an extended Reg-PBA message, which has the indicator 'S'=1 and 'F'=1, to inform the n-MAG to update BULE and setup routing for the flow 1. The LMA also send an extended De-Reg-PBA message, which has the indicator 'S'=1 and 'F'=0, to inform the p-MAG to remove the flow 1 from BULE and routing table. After completing these processes, the flow 1 will be exchange via the attachment of the PI2 to n-MAG.

    +-----+          +-----+          +-----+          +-----+
    | MN  |          |p-MAG|          |n-MAG|          | LMA |
    +-----+          +-----+          +-----+          +-----+
       |                |                |                |
       |                |                |                |
      PI1<--- Flow 1 -->|<------------ Flow 1 ----------->|
       |                |                |                |
(1) LGI switches Flow 1  |                |                |
 From IF1 to IF2        |                |                |
       |                |                |                |
      PI2 <---------- Flow 1 ----------->|                |
       |                |                |                |
       |                |    (2) Detects a new flow       |
       |                |                |                |
       |                |           (3)  |----- PBU ----->|
       |                |                |     (N=1)      |
       |                |                |                |
       |                |                | (4)  Updates BCE and setups
       |                |                |       routing for Flow 1
       |                |                |                |
       |                |                |<--- Reg PBA ---|  (5)
       |                |                |    (S=1,F=1)   |
       |                |                |                |
       |                |   (6)      Accept PBA,          |
       |                |      Add Flow 1 to the BULE,    |
       |                |     Setup routing for Flow 1    |
       |                |                |                |
       |                |<----- De-Reg PBA (S=1,F=0) -----|  (7)
       |                |                |                |
       |   (8)   Remove the binding      |                |
       |       and routing for Flow 1    |                |
       |                |                |                |
      IF2 <--------- Flow 1 ------------>|<--- Flow 1 --->|
       |                |                |                |

4.2.2.  The LMA moves flows

The Figure 3 (The signaling call flow of the scenario 2 with the trigger 3) shows the signaling call flow of the scenario 2 with the trigger 3. First, the LMA realize that the operator policy changes or the service profile of the MN changes and decide to move some flows from an existing attachment to another. The other steps 2-6 are the same as the steps 4-8 in the Figure 2 (The signaling call flow of the scenario 1 with the trigger 2)

    +-----+          +-----+          +-----+          +-----+
    | MN  |          |p-MAG|          |n-MAG|          | LMA |
    +-----+          +-----+          +-----+          +-----+
       |                |                |                |
       |                |                |                |
      PI1<--- Flow 1 -->|<------------ Flow 1 ----------->|
       |                |                |                |
       |                |                | (1)   The network policy
       |                |                |     is changed, or the MN
       |                |                |  service profile is changed
       |                |                |                |
       |                |                |  (2) Updates BCE and setups
       |                |                |       routing for Flow 1
       |                |                |                |
       |                |                |<--- Reg PBA ---|  (3)
       |                |                |    (S=1,F=1)   |
       |                |                |                |
       |                |    (4)     Accept PBA,          |
       |                |      Add Flow 1 to the BULE,    |
       |                |     Setup routing for Flow 1    |
       |                |                |                |
       |                |<----- De-Reg PBA (S=1,F=0) -----| (5)
       |                |                |                |
       |   (6)   Remove the binding      |                |
       |       and routing for Flow 1    |                |
       |                |                |                |
      IF2 <--------- Flow 1 ------------>|<--- Flow 1 --->|
       |                |                |                |

5.  LMA extensions

5.1.  Flow identifier management

The LMA should be extended to manage the flow information. The description of a flow is the n-tuple information including [Source Address, Destination Address, Source Port, Destination Port, and Protocol] and the other information such as flow-label, traffic-class, etc.. The LMA generates a unique ID for each flow. This ID will be used as an extension filed of the BCE to identify the flow. The LMA maintains a table mapping between Flow-ID and Flow description. After a specific time, if the LMA do not receive any packet that has the same header information as any of the flow description in this table, the corresponding record in the table will be removed.

5.2.  Binding Cache Entry extension

To support the flow mobility, the BCE should be extended for containing the flow information. Each BCE should contain the information of all flows generated from the MN.

A BCE should be able to include multiple HNPs, each of which maps to multiple flows. Each flow is bound to a specific Proxy-CoA. With this extension, the flow can be moved from one path to another path by simply updating new Proxy-CoA. The LMA should be able to look up BCE based on not only the HNP but also the Flow-ID.

5.3.  Prefix model for the logical interface

Since the logical interface hides multiple physical interfaces from the IP stack, the HNPs are assigned to the logical interface only. It means that the LMA can send/receive packets of an HNP to/from the MN via any physical interfaces that is abstracted by the logical interface.

                                    LMA's binding state
                         +----+     -------------------
                         |LMA |     MN_ID, HNP1, Voice -> MAG1
                         +----+     MN_ID, HNP1, Video -> MAG2
                          //\\
               +---------//--\\-----------+
               (        //    \\          )
               (       //      \\         )
               +------//--------\\--------+
                     //          \\
             PCoA1  //            \\  PCoA2
                 +----+         +----+
          (3GPP) |MAG1|         |MAG2| (WiFi)
                 +----+         +----+
                    \             /
        Voice (HNP1) \           / Video (HNP1)
                      \ (HNP1)  /
                   +--PI1-----PI2--+
                   |    \     /    |
                   |---------------|
                   |      LGI      | HNP1::LGI_MAC/128
                   |---------------|
                   |      MN       |
                   +---------------+

The figure1 shows an example. The MN attaches to the network using two physical interfaces with 3GPP and WiFi access technologies. These two physical interfaces (PIs) are abstracted by a logical interface (LGI). The LGI is assigned Home Network Prefix 1 (HNP1) and it has a global address, HNP1::LGI_MAC/128, where LGI_MAC is the link-layer address of the LGI. The mobile node sends voice traffic via the PI1, and video traffic via the PI2. Both of two flows use the same HNP1. This example is based on the shared-prefix model where an HNP can be shared across multiple interfaces.

5.4.  Signaling considerations

5.4.1.  Processing Proxy Binding Updates messages

In this section we introduce the additional processing rules to support flow mobility. First, the LMA analyzes the PBU message to check if the flow mobility trigger is activated. If yes, then the LMA will perform flow mobility procedure.

• If the LMA detects a new attachment from the MN, the LMA will look up all of the flows that the LMA is serving for the MN. Then it checks the operator’s policy and the application profile of each flow to decide which flow will be moved to the new attachment. The BCE entry will be updated with the new Proxy-CoA bound to this flow. There are different ways that the LMA can detect the new attachment from the MN. The following are three common cases that can be consider as the trigger of the new attachment case.
  • The HI of 1 (New attachment).
  • The HI is 4 and the ATT of PBU is different with the ATT stored in the corresponding BCE (New attachment with different access technology).
  • The HI is 4 and the ATT of PBU is the same with the ATT stored in the corresponding BCE but the source address of PUB message is different from the Proxy-CoA stored in the BCE (New attachment with the same access technology).
• If the PBU message contains the information about new flows, the LMA will compare the information of these flows with the existing ones stored in the corresponding BCE. If it is the same as one of the existing flow, the LMA will conclude that the mobile moved that flow to another link. The LMA then updates the BCE to bind that flow to the Proxy-CoA of the MAG that sends the PBU message.

5.4.2.  Sending Proxy Binding Acknowledgement messages

After the LMA updating the BCE to bind the flow to new Proxy-CoA, the LMA sends PBA message containing a flow mobility indicator that the LMA agrees to redirect flow via new MAG. The PBA message is sent to both new and old MAG with the flow mobility flag value of 1 and 2 respectively. On receiving PBA message, the MAG will check the flow mobility flag to perform flow binding registration or de-registration as discussed in the next section.

6.  MAG extensions

6.1.  Flow identifier management

Like the LMA, the MAG should be also extended to manage the flow information. The description of a flow is the n-tuple information including [Source Address, Destination Address, Source Port, Destination Port, and Protocol] and the other information such as flow-label, traffic-class, etc. The MAG generates a unique ID for each flow using the same algorithm as the LMA uses. This ID will be included in BULE to represent the flow. The MAG also maintains a table mapping between a Flow-ID and a Flow description. After a specific time, if the MAG do not receive any packet that has the same header information as any of the flow description in this table, the corresponding record in the table will be removed.

6.2.  Binding Update List Entry extension

Similar as BCE, the binding update list entry should be extended to include the flow information (e.g., Flow ID). A BULE includes multiple HNPs, each of which map to multiple flows. Each flow is bound to a specific tunnel-if-id.

6.3.  Signaling consideration

6.3.1.  Sending Proxy Binding Update messages

The MAG sends the extended PBU message with a flow mobility flag N. This flag is set to 1 if the MAG figures out that a new flow is sent from the MN. Otherwise it is set to 0. If the flag is 1 then the PBU will include the identification of the new flow.

6.3.2.  Processing Flow Binding Acknowledgement

When the MAG receives PBA messages, it will check the flow indicator flag value to perform flow binding registration or de-registration as follows:

• If it is 0 then the MAG adds the flow information to the BULE and binds it to the tunnel-if-id that has an end point similar with the address of the LMA that sends PBA message as well as created routing state for tunneling that flow.
• If the flag value is 1 then the MAG removes the flow information from the BULE and removes the created routing state for tunneling that flow.

7.  Message format extensions

To support flow mobility, the signaling messages between LMA and MAG should be extend to contain the extra information of flows. In this section we discuss about the necessary extensions of PBU and PBA messages.

7.1.  Proxy Binding Update messages

      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|N|  Reserved       |            Lifetime         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Mobility options                       .
      .                                                               .

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

A new flag 'N' is included in the PBU message. This flag is set to 1 if the MAG receives new flow from the MN. A new mobility option is also added to contain the identification of the new flow.

7.2.  Proxy Binding Acknowledgement

         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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |   Status      |K|R|P|S|F| Res.|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Sequence #            |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Mobility options                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Two new flags are included in the PBA message.

• The fist flag 'S' is used to indicate that the LMA processed flow mobility update and it wants to inform the old MAG and new MAG of that.
• The second flag 'F' is considered only when the 'S' flag is set to 1. The flag is set to '0' in case that the LMA wants to send a PBA message to the old MAG to de-register the flows that are moved to the new MAG. It is set to '1' if the LMA wants to send a PBA message to the new MAG to register new flows. A new mobility option is also added to contain the identification of the flows that are move to the new MAG.

8.  Security Considerations

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

9.  IANA Considerations

This document has no actions for IANA.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses