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

Abstract

When a mobile node attaches to the proxy mobile IPv6 domain by using multiple interfaces simultaneously, it can dynamically move a flow from an interface to another. A Mobile Access Gateway (MAG) should be aware of this event and inform a Local Mobility Anchor (LMA) to send packets of the flow to appropriate interfaces. This document introduces procedures for the MAGs and a LMA to actively track the movement of the flow basing on the flow-label of the IPv6 packet header.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 3, 2010.

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

Table of Contents

1.  Introduction
2.  The MAG operation
    2.1.  Classifying flows by using flow-label
    2.2.  Extension of the Binding Update List Entry (BULE) Data Structure
    2.3.  Flow tracking procedure
3.  The LMA operation
    3.1.  Extension of the Binding Cache Entry Data (BCE) Structure
    3.2.  Flow tracking procedure
4.  An example
5.  Conclusion
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.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. When the flow is moved from an interface to another interface, there are two technical issues that PMIPv6 has to solve:

• The first one is how to maintain the session of the mobility flow when the source address of the flow is changed from an interface to another. [3] (Sarikaya, B. and F. Xia, “PMIPv6 Multihoming Support for Flow Mobility, draft-sarikaya-netext-fb-support-extensions-00 (work in progress),” February 2010.)
• The second one is how the LMA can route packets of a flow sent from correspondent node to the correct interfaces.

Since the first issue can be solved by using virtual interface [4] (Tran, T. and Y. Hong, “Virtual interface for supporting multihoming and inter technology handover, draft-trung-netext-virtual-interface-01 (work in progress),” October 2009.), in this document we tackle on the second issue. We discuss about how to enable the MAG and the LMA to actively track the movement of flows.

There are several internet drafts introduce solutions for controlling the movement of flows. Some of them initiate the flow binding from the LMA such as in [5] (Sarikaya, B. and F. Xia, “Local Mobility Anchor Initiated Flow Binding for Proxy Mobile IPv6, draft-sarikaya-netext-lma-init-flow-binding-00 (work in progress),” February 2010.), while the others initiate the flow binding update from the MAG such as in [6] (Xia, F., “Flow Binding in Proxy Mobile IPv6,draft-xia-netext-flow-binding-00 (work in progress),” February 2009.). Since the MAG is the direct attached point of the mobile node to the proxy mobile IPv6 domain, it can actively track the packets sent from the mobile node and then inform the movement of the source of packets to the LMA.

2.  The MAG operation

When a mobile node attaches to the proxy mobile IPv6 by using simultaneously multiple interfaces, the router solicitation messages are sent to the MAGs via multiple interfaces. Multiple bi-directional tunnels will be established between the MAGs and the LAM for serving the packets sent to and from the mobile node via the multiple interfaces. The procedure of establishing bi-directional tunnel is discussed detail in the [1] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.).

After establishing bi-directional tunnels successfully, we enable the MAGs to actively start tracking the flows sending from the mobile node. To do that, we modify the operation of the MAG and LMA, as well as extend the Binding Update List Entry (BULE) and the Binding Cache Entry (BCE) data structure. The signaling between MAG and LMA is also added.

2.1.  Classifying flows by using flow-label

A flow is a sequence of packets sent from a particular source to a particular destination. It could consist of all packets in a specific transport connection or a media stream. The MAG can classify the flow basing on the 5-tuple of the source and destination addresses, ports, and the transport protocol type. However, some of these fields may be unavailable due to either fragmentation or encryption. The usage of the 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used as discussed in [2] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.).

Since the flow label identifies all packets belonging to a specific flow, the MAG can identify these packets and handle them in a similar fashion. The flow label information will be stored in the extended field of the binding update list entry. Which will be discussed more detail in the next section.

2.2.  Extension of the Binding Update List Entry (BULE) Data Structure

For supporting the flow-label tracking, each BULE should be extended with a 20-bit flow-label field. This field is used for storing the flow-label of the flow that the mobile node sends to the MAG.

After extending the BULE data structure, each node is represented by multiple sub-BULEs. Each sub-BULE corresponds to a specific flow-label.

2.3.  Flow tracking procedure

Whenever receiving a packet, the MAG extracts the flow-label from IPv6 packet’s header [2] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) and compare it with the flow-label field of all of the sub-BULEs that represents for the mobile node. If is a new label, the MAG will understands that there is a new flow sent from the mobile node. Then it will send a signaling message to the LMA to inform that there is a new flow sent from the mobile node via this MAG.

3.  The LMA operation

3.1.  Extension of the Binding Cache Entry Data (BCE) Structure

For supporting the flow-label tracking, each BCE should be extended with a 20-bit flow-label field. This filed is used for storing the flow-label of the flow that sent to or from the specific MAG.

After extending the BCE data structure, each mobility session now is represented by multiple sub-BCEs. Each sub-BCEs corresponds to a specific flow-label.

3.2.  Flow tracking procedure

Whenever the LMA receives a singling message from MAGs informing about the new flow sent to the MAG, the LMA compare the flow-label of this flow with the flow-label fields of all of the sub-BCEs that represent for the node to decide whether to update the existing sub-BCE or add new sub-BCE for this flow.

• If there is a sub-BCE entry that has the same flow-label field value and different ATT or Proxy-CoA, the LMA will understand that this is a mobility flow and update the sub-BCE for this flow.
• If there are no sub-BCE entries that have the same flow-label field value, the LMA will understand that it is a new flow and add a new sub-BCE entry for it.

4.  An example

The figure 1 shows the flow tracking procedure of an example, in which the mobile node attaches to the proxy mobile IPv6 by using two interfaces, IF 1 and IF 2. There are two bi-directional tunnels are established using the basic procedure of the [1] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.).We assume that the flow 1 is initiated from the interface IF1 and sent to the MAG1. When the MAG1 receives the first packet of the flow 1, it will extract the flow-label and add a new sub-BULE for tracking the flow 1 and binding it to the bi-directional tunnel 1 which is established between the MAG1 and the LMA. The MAG1 then send a signaling message to the LMA to inform that there is a new flow sent from the mobile node to the MAG1 via the interface IF1. The LMA then add a new sub-BCE for tracking the flow 1.

    +-----+          +-----+          +-----+          +-----+
    | MN  |          |MAG 1|          | LMA |          |MAG 2|
    +-----+          +-----+          +-----+          +-----+
       |                |                |                |
Sends RS via IF1 ------>|                |                |
Sends RS via IF2 ---------------------------------------->|
       |                       ....                       |
       |      Registration steps as in RFC5213.Fig. 2.    |
       |                       ....      |                |
       |                |=Bi-Di Tunnel-1=|                |
       |                |                |=Bi-Di Tunnel-2=|
      IF1<-----Rtr Adv--|                |                |
      IF2<--------------------------------------Rts Adv---|
       |                |                |                |
   Flow 1 from IF1----->|                |                |
       |      Binds Flow 1 to Tunnel-1   |                |
       |                |--- Send FBU -->|                |
       |                |      Accept FBU, Update BCE     |
       |                |<--- Send FBA---|                |
       |<-Flow 1 Data ->|<-Flow 1 Data ->|                |
       |                |                |                |

In the figure 2, we assume that the flow 1 is moved from IF1 to the interface IF2. From the point of view of the MAG2, the flow 1 is a new flow so a new sub-BULE is added and a signaling message is sent from MAG2 to LMA to inform that the flow 1 is now sent to LMA via MAG2. Since there an existing sub-BCE of flow 1 with different ATT and different Proxy-CoA, the LMA understands that flow 1 is moved from the MAG1 to the MAG2 then the LMA will update new ATT and Proxy-CoA to the record of the flow 1 sub-BCE. After updated successfully, the new routing path for the flow 1 via MAG2 is established. The packets of the flows 1 are now can be exchanged via the MAG2.

    +-----+          +-----+          +-----+          +-----+
    | MN  |          |MAG 1|          | LMA |          |MAG 2|
    +-----+          +-----+          +-----+          +-----+
       |                |                |                |
 CM switch Flow 1       |                |                |
 From IF1 to IF2        |                |                |
       |                |                |                |
   Flow 1 from IF2--------------------------------------->|
       |                |                |          Binds Flow 1
       |                |                |          to Tunnel-2
       |                |                |<--- Send FBU --|
       |                |            Accept FBU           |
       |                |           Update/Add BCE        |
       |                |                |--- Send FBA--->|
       |<-Flow 1 Data ->|<-----------Flow 1 Data -------->|
       |                |                |                |

5.  Conclusion

In this document we briefly introduce the procedures for the MAG and the LMA to actively track the movement of flows. They do not require any involvements of the mobile node. In the next version of the document, we will discuss more detail about the structure of flow binding messages as well as the extended structure of the binding ache entry at the LMA and the detail procedures.

6.  Security Considerations

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

7.  IANA Considerations

This document has no actions for IANA.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses