Network Working Group J-C. Lee Internet-Draft D. Kaspar Intended status: Standards Track ETRI Expires: January 19, 2008 July 18, 2007 PMIPv6 Fast Handover for PMIPv6 Based on 802.11 Networks (draft-lee-netlmm-fmip-00.txt) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Lee & Kaspar Expires January 19, 2008 [Page 1] Internet-Draft Fast Handover for PMIPv6 July 2007 Abstract The PMIPv6 protocol provides local mobility to a mobile node without requiring any modification of the mobile node. A PMIPv6 domain contains multiple MAGs which the mobile node is attached to, and they advertise the same prefix to the mobile node so that the mobile node feels like it is always on the same link. However, horizontal/ vertical handover still happens while the mobile node moves among MAGs in a PMIPv6 domain, and this handover could give undesirable delay to mobile nodes running real time applications, such as VoIP. To solve this problem, this memo proposes a fast handover for PMIPv6 based on 802.11 networks. This scheme uses IAPP to transfer context information like the mobile node's authentication information and HNP. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. 802.11 Network Architecture . . . . . . . . . . . . . . . 7 5.2. IAPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 9 5.3.1. Architectural Consideration . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Lee & Kaspar Expires January 19, 2008 [Page 2] Internet-Draft Fast Handover for PMIPv6 July 2007 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Lee & Kaspar Expires January 19, 2008 [Page 3] Internet-Draft Fast Handover for PMIPv6 July 2007 2. Introduction The PMIPv6 protocol provides local mobility to mobile nodes without requiring any involvement of a mobile node stack. From the perspective of a mobile node, the entire PMIPv6 domain appears as a single link, the network ensures the mobile node believes it is always on its home link. Therefore, mobile nodes in a PMIPv6 domain may operate as if they were still on the same link, while roaming in the PMIPv6 domain. A MAG is an access router that manages mobility related signaling instead of the mobile node. Hence, if a mobile node roams in the PMIPv6 domain, handover between MAGs always happens. When a mobile node moves from a previous MAG to new MAG, it enters an access authentication process first. After successful access authentication, the new MAG obtains the mobile node's profile from the policy store, and then sends a Router Advertisement message to the mobile node for reconfiguration of the default router. It also sends a Proxy Binding Update message to the LMA for updating the current location of the mobile node. These successive procedures constitute the total handover delay of PMIPv6. (See Figure 1) |<-------------->|<------------------------->|<----->|<------------>| L2 detach/attach access authentication RA PBU/PBA Figure 1: Handover Delay in the PMIPv6 Domain To reduce this handover delay, this memo focuses on reducing the "access authentication/obtaining MN's profile" portion of total handover delay. The scheme described in this memo is based on 802.11 networks, thus the context information (authentication information, MN's Profile) is transferred from a previous MAG to a new MAG via the IAPP [802.11f] protocol. IAPP is a protocol used by an AP to communicate with other APs on a common DS (Distribution System). By transferring context information in advance, handover delay could be reduced significantly. The more detailed procedure is described in Section 5. Lee & Kaspar Expires January 19, 2008 [Page 4] Internet-Draft Fast Handover for PMIPv6 July 2007 3. Terminology Access Point (AP): Any entity that has station functionality and provides access to the distribution services, via the wireless medium (WM) for associated stations. Association: The service used to establish access point/station (AP/STA) mapping and enable STA access to the Distribution System. Basic Service Set (BSS): A set of stations controlled by a single coordination function, where the coordination function may be centralized (e.g., in a single AP) or distributed (e.g., for an ad hoc network). The BSS can be thought of as the coverage area of a single AP. Distribution System (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). Extended Service Set (ESS): A set of one or more interconnected basic service sets (BSSs) and integrated local area networks (LANs) that appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. The ESS can be thought of as the coverage area provided by a collection of APs all interconnected by the Distribution System. It may consist of one or more IP subnets. Station (STA): Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). In this memo a mobile node means a STA. Inter AP Protocol (IAPP): IAPP is a set of functionalities and a protocol used by an AP to communicate with other APs on a common DS. Lee & Kaspar Expires January 19, 2008 [Page 5] Internet-Draft Fast Handover for PMIPv6 July 2007 4. Assumptions Layer 3 AP The IAPP does not deal directly with the delivery of 802.11 data frames to the STA (AP); instead the DS utilizes existing network functionality (like TCP/IP protocol) for data frame delivery, thus all APs mentioned in this memo support IP protocol. AP and MAG APs and MAGs can exist as separate entities or as a merged entity. If the AP and the MAG exist separately it is assumed that both maintain the same context information (authentication information, HNP) for a mobile node, or the AP can get this information from the MAG. AP and DS All APs in a PMIPv6 domain are connected with one another via the same DS. Lee & Kaspar Expires January 19, 2008 [Page 6] Internet-Draft Fast Handover for PMIPv6 July 2007 5. Protocol Details 5.1. 802.11 Network Architecture The basic building block of an 802.11 network is the BSS. Within a BSS, STAs can communicate with each other and access the wired internet via the STA serving as an AP of the BSS. Instead of being standalone, a BSS may also be a component of an extended form of network built with multiple BSSs, as shown in Figure 2. This extended form of network is called an ESS and the architectural component used to interconnect BSSs is the DS. The IAPP uses the DS. +-------------------------- ESS -----------------+ | +---------+ | | | BSS1 | | | +--[AP1]--+ | | | | | +---+----------------+ +----------+ | | | | | | | | | DS |----[AP2] BSS2 | | | +---------+----------+ | | | | | +----------+ | | | | | +---[AP3]------+ | | | | | | | BSS3 | | | +--------------+ | +------------------------------------------------+ Figure 2: 802.11 Network Architecture Figure 3 is a conceptual view for A PMIPv6 domain based on 802.11 networks. In this case, each AP and MAG exists separately, and each {MAG, AP} pair shares context information for a mobile node. There are several 802.11 access network architectures based on the characteristics of the DS, but this memo does not handle more detailed 802.11 access network architectures. For more information, see [RFC4118]. Lee & Kaspar Expires January 19, 2008 [Page 7] Internet-Draft Fast Handover for PMIPv6 July 2007 PMIPv6 Domain +--------------------------[ LMA ]-----------------------+ | / | \ | | / | \ | | | | | | | +-------------+ | +------------+ | | | | | | | | | | | | [MAG1] [MAG2] [MAG3] | | | | | | | | _________________|________________ | | | |/ DS | \| | | +-----[AP1]----+ +-----[AP2]----+ +-----[AP3]----+ | | | \_____|___|______________|__|______/ | | | | | | | | | | | | BSS1 | | BSS2 | | BSS3 | | | +--------------+ +--------------+ +--------------+ | | | +----------------------------------------------------------+ Figure 3: Example Architecture for a PMIPv6 Domain Based on 802.11 Networks 5.2. IAPP IAPP is designed for the enforcement of unique association throughout a ESS and for secure exchange of STA's security context between previous AP and new AP during handover period. The DS utilizes an IAPP that provides the necessary capabilities to achieve multi-vendor AP interoperability within the DS. This IAPP uses TCP or UDP/IP to carry IAPP packets between APs. When a STA moves away from its previous AP, it starts searching for new APs. When the STA found a new AP, it attempts to reassociate itself with this new AP by sending a reassociation message. On receiving this reassociation message the new AP replies to the STA with a reassociation response message. After this response the new AP also sends an IAPP MOVE-notify message to the previous AP via the DS. Then, the previous AP responds to the new AP with a MOVE- response message. With the MOVE-notify and MOVE-response messages, the IAPP is able to provide context transfer between APs. By using the context information carried in these packets, a new AP can expedite the reauthentication of the STA on reassociation, thus reducing link- layer handoff latency [802.11f]. In this proposal the mobile node's HNP and authentication information Lee & Kaspar Expires January 19, 2008 [Page 8] Internet-Draft Fast Handover for PMIPv6 July 2007 are included in the context information. 5.3. Message Flow The following scheme is activated when a mobile node roams among MAGs in a PMIPv6 domain. Figure 4 describes the message flow for this scheme. (1) Sending Disassociation message: a mobile node moves away from the current AP. When the received signal strength reaches a specific threshold value, the mobile node sends a Disassociation message to the current AP (pAP). The Disassociation message includes the mobile node's MAC address. (2) Forwarding the mobile node's ID: on receiving the Disassociation message from the mobile node, the pAP sends the mobile node's ID (MAC) information to the pMAG. (3) Sending FPBU message: on receiving the mobile node's ID, the pMAG sends an FPBU(Fast PBU) message to the LMA. This FPBU message contains the mobile node's NAI option. (4) Buffering: on receiving the FPBU message, the LMA starts buffering packets toward the mobile node. (5) Sending Reassociation message: the mobile node attaches at the new AP (nAP), and sends a Reassociation message. This message contains the mobile node's MAC address and the BSSID of the pAP. (6) Sending MOVE-notify message: on receiving the Reassociation message, the nAP sends a MOVE-notify message via the DS. (7) Sending MOVE-response message: on receiving the MOVE-notify message, the pAP responds to the nAP with a MOVE-response message which carries context information for the mobile node. This context information contains authentication information and HNP for the mobile node. (8) Forwarding context information: on receiving the MOVE-response message, the nAP forwards the mobile node's context information to the nMAG. (9) Reconfigure default router for the mobile node: on receiving the mobile node's context information, the nMAG sends a RA message to reconfigure the default router of the mobile node. Lee & Kaspar Expires January 19, 2008 [Page 9] Internet-Draft Fast Handover for PMIPv6 July 2007 (10) Configure forwarding information: on receiving the mobile node's context information, the nMAG constructs a PBU message by using the context information, and sends it to the LMA. (11) ~ (12) Forwarding buffered packets: on receiving the PBU message, the LMA sets up a route for the mobile node and starts forwarding buffered packets to it. +----+ +-----+ +-----+ +-----+ +-----+ +-----+ | MN | | pAP | | pMAG| | nAP | | nMAG| | LMA | +----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | |====(1)===>| | | | | | |-----(2)--->|----------------(3) FPBU-------------->|[ ] | | | | | |[ ] ~disconnect | | | | |[ ] | | | | |[ ] ~connect | | | | |[4] | | | | | |[B] ==================(5)================>| | |[U] | | | | | |[F] | | | | | |[F] | | | | | |[E] | |<----(6) MOVE-notify-----| | |[R] | | | | | |[I] | | | | | |[N] | | | | | |[G] | |-----(7) MOVE-response-->| | |[ ] | | | |---(8)----->| |[ ] | | | | | |[ ] | | | | | |[ ] |<-----------------(9) Router Advertisement--------|--(10) PBU-->|[ ] | | | | | | | | | | | | | | | | | | |<---------------------(11) forward packets----------------------| | | | | | | | | | | | | | | | | |<--(12)PBAck-| | | | | | | | | | | | | ====>: Layer 2 message ---->: Layer 3 message Figure 4: Protocol Message Flow Lee & Kaspar Expires January 19, 2008 [Page 10] Internet-Draft Fast Handover for PMIPv6 July 2007 This scheme reduces handover delay as follows, Before applying this scheme: |<------------->|<------------------------->|<----->|<------------>| L2 detach/attach access authentication RA PBU/PBA After applying this scheme: |<-------->|<------------->|<------->|<-------------->| L2 detach L2 attach/ RA PBU/PBA context transfer 5.3.1. Architectural Consideration If the AP and MAG are collocated, steps (2) and (8) are not necessary for this scheme. Lee & Kaspar Expires January 19, 2008 [Page 11] Internet-Draft Fast Handover for PMIPv6 July 2007 6. IANA Considerations There is no IANA consideration in this document. Lee & Kaspar Expires January 19, 2008 [Page 12] Internet-Draft Fast Handover for PMIPv6 July 2007 7. Security Considerations [802.11f] has some security considerations. This memo follows section 1.4 of [802.11f]. Lee & Kaspar Expires January 19, 2008 [Page 13] Internet-Draft Fast Handover for PMIPv6 July 2007 8. References 8.1. Normative References [802.11f] "802.11F IEEE Trial-Use Recommended Practice for Multi- Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", July 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [pmipv6] Gundavelli, S., "Proxy Mobile IPv6", March 2007. 8.2. Informative References [802.11] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", June 2003. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005. Lee & Kaspar Expires January 19, 2008 [Page 14] Internet-Draft Fast Handover for PMIPv6 July 2007 Authors' Addresses Joo-Chul Lee ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-700 Korea Fax: +82 42 861 5404 Email: rune@etri.re.kr Dominik Kaspar ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-700 Korea Fax: +82 42 861 5404 Email: dominik@etri.re.kr Lee & Kaspar Expires January 19, 2008 [Page 15] Internet-Draft Fast Handover for PMIPv6 July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee & Kaspar Expires January 19, 2008 [Page 16]