netext Working Group Jaehwoon Lee Internet-Draft Dongguk University Intended status: Informational Yoonyoung An Expires: August 27, 2011 Byungjun Ahn ETRI Febraury 28, 2011 Flow-based mobility support in Proxy Mobile IPv6 draft-jaehwoon-netext-flowmob-01.txt Abstract IN Proxy Mobile IPv6 (PMIPv6), a multi-homed MN can connect to the PMIPv6 domain by using only one interface even though it has multiple interfaces. It would be efficient when such a multi-homed MN connect to the PMIPv6 domain by using all of its interfaces. If such a multi-homed MN utilizes 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 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 August 27, 2011. Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 1] Internet-Draft Flow-based mobility support Feb. 28, 2011 Copyright Notice Copyright (c) 2011 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.......................................................7 Author's Addresses...............................................7 Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 2] Internet-Draft Flow-based mobility support Feb. 28, 2011 1. Introduction The Proxy Mobile IPv6 (PMIPv6) is considered as the network-based mobility management mechanism that the access network within the PMIPv6 domain supports 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 domain 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 domain 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 session. 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 Aug. 27, 2011 [Page 3] Internet-Draft Flow-based mobility support Feb. 28, 2011 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) | | | | |<~~~~~~~~~~~~~~~~>|<~~~~~~~~~~ SF ~~~~~~~~~~~~>|<~~~~~~~~~~~>| | |----------------->| | | | | L2 Attachment |------ PBU ------>| | | | | |<-----------------| | | |<-----------------| PBAck(HNP2,HNP1) | | | | RA(HNP2,HNP1) | | | | (Configure HoA2 to IF2) | | | | | |<---------------------------| | |<-----------------| PBAck(HNP1,HNP2) | | | RA(HNP1,HNP2) | | | | (To activate logical interface | | | and assign VLL-ID and IP| | | | address(MN-HoA1) to logical | | | interface) | | | | | |----------------->| | | | |NA(MN-HoA1,VLL-ID)| | | | |--------------------------->| | | | NA(MN-HoA1,VLL-ID) | | | (Flow mobility from IF1 to IF2) | | | | |~~~~~~ SF ~~~~~~~>| | | | | | |~~~~~~ SF ~~~~~~~>| | | | | | (create FMTE) | | | | | |~~~~ SF ~~~~>| | |<~~~~~ SF ~~~~~~~>|<~~~~~ SF ~~~~~~~>|<~~~ SF ~~~~>| Figure 1: Message exchange scenario Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 4] Internet-Draft Flow-based mobility support Feb. 28, 2011 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 assumed that a MN is equipped with two interfaces and can simultaneouly connect to two access networks 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 connects 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 assigns a network prefix (say, HNP1) for the MN and creates the binding cache entry for the MN. The HNP1 and Proxy-CoA1 information is included 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. From 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 (SF). The SF can be classified with 5-tuple information having MN-HoA1, the IP address of CN, protocol ID of the transport layer protocol, source port number and destination port number. While exchanging SF 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 (by using 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. MAG1 having received the PBAck message can also konw that the MN wants to connect to the PMIPv6 domain via multiple access networks by using the number of network prefixes within the message. MAG1 transmits the RA message having HNP1 and HNP2 to the MN. Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 5] Internet-Draft Flow-based mobility support Feb. 28, 2011 The MN having received RA messages having the identical network prefixes from two different network interfaces knows that a multi-homed connection is established between itself and the PMIPv6 domain. The MN activates the logical interface and configures one of the IPv6 address belonging to HNP1 or HNP2 to the logical interface. Here, how the MN decides which network prefix to choose among HNP1 and HNP2 is out of scope of this document. One method is to use the IP address assigned to the first interface that the MN connects to the PMIPv6 domain. In this document, MN-HoA1 is assumed to be configured to the logical interface. Moreover, the MN configures the virtual link-layer identifier (VLL-ID) to the logical interface as the layer two address. How VLL-ID is configured for the logical interface is out of scope of this document. See [3] for logical interface link layer configuration. Once the MN configures the MN-HoA1 and VLL-ID to the logical interface, it broadcasts the unsolicited Neighbor Advertisement (NA) message having MN-HoA1 and VLL-ID via both IF1 and IF2. MAG1 and MAG2 having received the NA message store the MN-HoA1 and VLL-ID information in each of their binding update list entries associated to the MN. From now on, the MN can exchange traffic via any of two interfaces. After having configured the IP address to the logical interface, if the MN decides to handover the VoIP traffic exchanged with the CN from IF1 to IF2, it transmits the traffic (that is, SF) via IF2. How the MN decides to handover is out of scope of this document. The MAG2 having received the SF sends the SF to LMA via the tunnel established between the LMA and the MAG2. The LMA having received the SF 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 SF and the IP address of the MAG2 (that is, Proxy-CoA2). And then the LMA transmits the SF to the CN. When the LMA receives the SF transmitted by the CN, it checks the FMTE. If the LMA finds the entry matching the same 5-tuple information with the SF, it transmits the SF to the MAG2 via the tunnel. MAG2 also sends the SF to the MN. 4. Security Consideration TBD. 5. IANA Considerations TBD. Jaehwoon Lee, et al. Expires Aug. 27, 2011 [Page 6] Internet-Draft Flow-based mobility support Feb. 28, 2011 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. [3] T. Melia and S. Gundavelli, "Logical Interface Support for multi-mode IP hosts", draft-ietf-netext-interface-support-01 (work in progress), Oct. 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 Aug. 27, 2011 [Page 7]