Network Working Group T. Tran Internet-Draft Y. Hong Intended status: Informational ETRI Expires: September 2, 2010 March 1, 2010 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 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Tran & Hong Expires September 2, 2010 [Page 1] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The MAG operation . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Classifying flows by using flow-label . . . . . . . . . . . 4 2.2. Extension of the Binding Update List Entry (BULE) Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Flow tracking procedure . . . . . . . . . . . . . . . . . . 4 3. The LMA operation . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Extension of the Binding Cache Entry Data (BCE) Structure . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Flow tracking procedure . . . . . . . . . . . . . . . . . . 5 4. An example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Tran & Hong Expires September 2, 2010 [Page 2] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 1. Introduction The Proxy Mobile IPv6 (PMIPv6) [1] 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: o 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] o 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], 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], while the others initiate the flow binding update from the MAG such as in [6]. 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]. 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. Tran & Hong Expires September 2, 2010 [Page 3] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 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]. 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] 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. Tran & Hong Expires September 2, 2010 [Page 4] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 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. o 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. o 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].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. Tran & Hong Expires September 2, 2010 [Page 5] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 +-----+ +-----+ +-----+ +-----+ | 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 ->| | | | | | Figure 1: Flow tracking procedure 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. Tran & Hong Expires September 2, 2010 [Page 6] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 +-----+ +-----+ +-----+ +-----+ | 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 -------->| | | | | Figure 2: Flow mobility support 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 [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Tran & Hong Expires September 2, 2010 [Page 7] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 [2] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. 8.2. Informative References [3] Sarikaya, B. and F. Xia, "PMIPv6 Multihoming Support for Flow Mobility, draft-sarikaya-netext-fb-support-extensions-00 (work in progress)", February 2010. [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. [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. [6] Xia, F., "Flow Binding in Proxy Mobile IPv6,draft-xia-netext-flow-binding-00 (work in progress)", February 2009. [7] 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. Authors' Addresses Tran Minh Trung ETRI 161 Gajeong-Dong Yuseung-Gu Daejeon, 305-700 Korea Phone: +82 42 860 1132 Email: trungtm2909@gmail.com Tran & Hong Expires September 2, 2010 [Page 8] Internet-Draft Flow tracking procedure for PMIPv6 March 2010 Yong-Geun Hong ETRI 161 Gajeong-Dong Yuseung-Gu Daejeon, 305-700 Korea Phone: +82 42 860 6557 Email: yonggeun.hong@gmail.com Tran & Hong Expires September 2, 2010 [Page 9]