netext Working Group Jaehwoon Lee Internet-Draft Dongguk University Intended status: Informational Yoonyoung An Expires: January 2, 2011 Byungjun Ahn ETRI July 3, 2010 Flow-based mobility support in Proxy Mobile IPv6 draft-jaehwoon-netext-flowmob-00.txt Abstract IN Proxy Mobile IPv6 (PMIPv6), a multi-homed MN can connect to the PMIPv6 by using only one interface even though it has multiple interfaces. It would be efficient when such a multi-homed MN can connect to the PMIPv6 by using all of its interfaces. If such a multi-homed MN can utilize all of its interfaces, flow mobility can be provided that the MN handovers one or more flows from one interface to another without re-establishing sessions. This document specifies the layer-3 based flow mobility mechanism by considering the intention of the MN. Here, a MN chooses the interface for sending the service traffic and transmits the traffic by using the chosen interface. The PMIPv6 domain can know the intention of the MN when a MAG receives a service flow via a specific network. 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. Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 1] Internet-Draft Flow-based mobility support July 3, 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 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 BSD License. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. Protocol operation............................................4 4. Security Considerations.......................................6 5. IANA Considerations...........................................6 References.......................................................6 Author's Addresses...............................................7 Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 2] Internet-Draft Flow-based mobility support July 3, 2010 1. Introduction The Proxy Mobile IPv6 (PMIPv6) is considered as the network-based mobility management mechanism that the access network within the PMIPv6 domain support the mobility of the mobile node (MN) on behalf of the MN itself [1]. In PMIPv6, the Mobile Access Gateway (MAG) is defined to support the mobility of an MN. The MAG acts as the default gateway of the access link to which an MN is connected. Also, the Localized Mobility Anchor (LMA) is defined as the Home Agent within the PMIPv6 domain. IN PMIPv6, a multi-homed MN can connect to the PMIPv6 by using only one interface even though it has multiple interfaces. It would be efficient when such a multi-homed MN can connect to the PMIPv6 by using all of its interfaces. If such a multi-homed MN can utilize all of its interfaces, flow mobility can be provided that the MN handovers one or more flows from one interface to another without re-establishing sessions. However, as described before, the PMIPv6 is the network-based mobility management protocol, and PMIPv6 domain cannot know the intention of the MN. Therefore, it does not reflect the intention of the MN for the PMIPv6 domain to statically assign the interface for a specific flow. For example, assume that a MN connects both to 3GPP network via an interface and Wireless LAN via another interface and exchange the VoIP traffic with the host resided in the Internet. Then some users prefer to utilize the 3GPP network that satisfies the QoS requirement of the VoIP traffic. On the other hand, other users prefer to utilize the Wireless LAN due to its high speed and low cost. This document specifies the layer-3 based flow mobility mechanism by considering the intention of the MN. In this document, the service flow is defined by using the 5-tuple composed of source IP address, destination IP address, protocol ID of the transport layer protocol, source port number and destination port number. Here, a MN chooses the interface for sending the service traffic and transmits the traffic by using the chosen interface. The PMIPv6 domain can know the intention of the MN when a MAG receives a service flow via a specific network. Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 3] Internet-Draft Flow-based mobility support July 3, 2010 2. Terminology Flow Mapping Table Entry (FMTE) The entry that support the flow handover. The 5-tuple information identifying the service flow is included in the entry. The tunnel end-point address for the service flow is also included. Service Flow (SF) The flow that is exchanged between two end hosts. The SF is identified by using the 5-tuple information including source IP address, destination IP address, protocol ID of the transport layer protocol, source port number and destination port number. 3. Protocol Operation MN-IF1 MN-IF2 MAG1 MAG2 LMA (Internet) CN | | | | | | |----------------->| | | | | L2 attachment |---------- PBU ------------>| | | | |<------ PBAck(HNP1) --------| | |<--- RA(HNP1) ----| | | | | | | | (Configure HoA1 to IF1) | | | | |<~~~~~~~~~~~~~~~~>|<~~~~~~~~~ Flow ~~~~~~~~~~~>|<~~~~~~~~~~~>| | |----------------->| | | | | L2 Attachment |------ PBU ------>| | | | | |<-----------------| | | |<-----------------| PBAck(HNP2,HNP1) | | | | RA(HNP2,HNP1) | | | | (Configure HoA2 to IF2) | | | | | |<---------------------------| | |<-----------------| PBAck(HNP1,HNP2) | | | RA(HNP1,HNP2) | | | | (Flow mobility from IF1 to IF2) | | | | |~~~~~~ SF1 ~~~~~~>| | | | | (create FMTE) | | | | | |~~~~~~ SF1 ~~~~~~>| | | | | | (create FMTE) | | | | | |~~~ SF1 ~~~>| | | | | |<~~ SF1 ~~~>| | | | |<~~~~ SF1 ~~~~> | | | |<~~~~ SF1 ~~~~> | | | Figure 1: Message exchange scenario Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 4] Internet-Draft Flow-based mobility support July 3, 2010 In this document, MN is assumed to follow the weak host model [2]. Figure 1 shows the message exchange scenario considered in this document. it is assument that a MN is equipped with 2 interfaces and can simultaneouly connect to 2 access network each having different access technology within the PMIPv6 domain. In reality, the MN can be equipped with N interfaces. When a MN enters a PMIPv6 domain and connect to a MAG (say, MAG1) with one of its interfaces (say, IF1), MAG1 transmits the Proxy Binding Update (PBU) message having the MN-ID to LMA as described in the PMIPv6 protocol. LMA assignes a network prefix (say, HNP1) for the MN and creates the binding cache entry for the MN. The HNP1 and Proxy-CoA1 information is include in the binding cache entry, where the Proxy-CoA1 is the IP address of the MAG1. And then, the LMA sends the Proxy Binding Acknowledgement (PBAck) message having HNP1 to MAG1. MAG1 having received the PBAck message announces the Router Advertisement (RA) message to the MN. The HNP1 information is included in the RA message. MN assigns one IPv6 address (say, MN-HoA1) that belongs to the HNP1. Form now on, MN can communicate with a host resided in the Internet. Assume that the MN establishes a VoIP session with a correspondent node (CN) in the Internet by using the IF1 and exchanges the service flow (say SF1). The SF1 can be classified with 5-tuple information having MN-HoA1, the IP address of CN, protocol IP of the transport layer protocol, source port number and destination port number. While exchanging SF1 by using IF1, if the MN connects to another MAG (say, MAG2) within the same PMIPv6 domain by using another interface (say, IF2), MAG2 sends the PBU message having the MN-ID to the LMA. The LMA checks if there exists the binding cache entry for the MN. If it exists, the LMA checks the access technology type (ATT) that is included in the PBU message. If the value of the ATT is different, the LMA considers that the MN wants to connect to the PMIPv6 domain by using both two interfaces (that is, two different networks). The LMA assigns another network prefix (say, HNP2) for the MN and adds HNP2 and Proxy-CoA2 information in the binding cache entry for the MN where Proxy-CoA2 is the IP address of the MAG2. And then, the LMA sends the PBAck message having HNP2 and HNP1 to MAG2. The LMA also sends the PBAck message having HNP1 and HNP2 to MAG1. MAG2 having received the PBAck message can know that the MN wants to connect to the PMIPv6 domain via multiple access networks by using the number of network prefixes within the message. MAG2 transmits the RA message having HNP2 and HNP1 to the MN. MN having received the RA message via IF2 configures one of the IPv6 address (say, MN-HoA2) belonging to HNP2 to IF2. MAG1 having received the PBAck message also can know that the MN wants to connect to the PMIPv6 domain via multiple access networks by using the number of network prefixes Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 5] Internet-Draft Flow-based mobility support July 3, 2010 within the message. MAG1 transmits the RA message having HNP1 and HNP2 to the MN. The MN finds that the IP address already configured to the IF1 is the subset of the HNP1 that is the first network prefix included in the RA message. From now, the MN knows that a multi-homed connection is established between it and the PMIPv6 domain. The MN can exchange traffic via any one of two interfaces. After the IP address is configured in the IF2, if the MN decides to handover the VoIP traffic exchanged with the CN from IF1 to IF2, it transmits the service flow (that is, SF1) via IF2. How the MN decides to handover is out of scope of this document. The MAG2 having received the SF1 identifies that the source address of SF1 belongs to HNP1 (not HNP2) and considers that the MN wants the flow handover. MAG2 creates the flow mapping table entry (FMTE) for the MN. The 5-tuple information for the SF1 is included in the FMTE for the MN. And then, the MAG2 sends the SF1 to LMA via the tunnel established between the LMA and the MAG2. The LMA havind received the SF1 identifies that the MN wants the flow handover for the flow. The LMA creates the FMTE for the MN that includes 5-tuple information for SF1 and the IP address of the MAG2 (that is, Proxy-CoA2). And then the LMA transmits the SF1 to the CN. When the LMA receives the SF1 transmitted by the CN, it checks the FMTE. If the LMA finds the entry matching the same 5-tuple information with the SF1, it transmits the SF1 to the MAG2 via the tunnel. Here, the IP address of the MAG2 is also included in the SMTE. MAG2 also sends the SF1 to the MN after having checked its FMTE for the MN. 4. Security Consideration TBD. 5. IANA Considerations TBD. References [1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", RFC 5213, Aug. 2008. [2] R. Braden, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, Oct. 1989. Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 6] Internet-Draft Flow-based mobility support July 3, 2010 Author's Addresses Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul 100-715, KOREA Email: jaehwoon@dongguk.edu Yoon-Young An Network Research Division, ETRI Jeonmin-Dong, Yusung-Gu Daejeon, Chungnam, Korea Email: yyahn@etri.re.kr Byung-Jun Ahn Network Research Division, ETRI Jeonmin-Dong, Yusung-Gu Daejeon, Chungnam, Korea Email: bjahn@etri.re.kr Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 7]