NEMO WG JH. Choi Internet-Draft Hee Jin. Jang Intended status: Informational Samsung AIT Expires: April 19, 2007 Youngdon. Chung Samsung Electronics October 16, 2006 Prefix binding based mobility management in WiMAX network draft-jinchoi-nemo-pbm-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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Choi, et al. Expires April 19, 2007 [Page 1] Internet-Draft pbm October 2006 Abstract This document describes a protocol which provides movbility support for an ordinary IPv6 host in WiMAX network. The protocol allows session continuity for every IPv6 node in WiMAX network as it moves across subnets. The protocol exploits the facts that a single prefix is assigned per an IPv6 host in WiMAX network and prefix binding scheme is defined in NEMO WG. WiMAX access routers perform prefix binding for the hosts' stead and the mobility is transparent to the hosts inside WiMAX network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Home Access Router (HAR) . . . . . . . . . . . . . . . . . 5 2.2. Prefix table for AR . . . . . . . . . . . . . . . . . . . 5 2.3. Prefix table for AAA server . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8 4.1. Home Access Router (HAR) operation . . . . . . . . . . . . 8 4.1.1. Assigning prefix . . . . . . . . . . . . . . . . . . . 8 4.1.2. Receiving Binding Update . . . . . . . . . . . . . . . 8 4.1.3. Forwarding packets . . . . . . . . . . . . . . . . . . 9 4.2. New Access Router (NAR) operation . . . . . . . . . . . . 9 4.2.1. Detecting prefix . . . . . . . . . . . . . . . . . . . 9 4.2.2. Sending Binding Update . . . . . . . . . . . . . . . . 9 4.2.3. Forwarding packets . . . . . . . . . . . . . . . . . . 9 4.3. AAA server operation . . . . . . . . . . . . . . . . . . . 10 4.3.1. Managing prefix . . . . . . . . . . . . . . . . . . . 10 4.3.2. Informing prefix . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Choi, et al. Expires April 19, 2007 [Page 2] Internet-Draft pbm October 2006 1. Introduction This document presents a way to support mobility for an ordinary IPv6 host in WiMAX network. The scheme exploits the fact that, in WiMAX network, a prefix is assigned per an MS (mobile station) and extends the prefix binding defined in NEMO basic protocol [4]. WiMAX network follows the point-to-point link model, i.e. 'per MS prefix model'. RFC 2461 defines link as a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. When an MS moves within a link, it can keep using its IP addresses. In WiMAX, there exists a connection (service flow) between an MS and the AR via a BS, over which packets are transferred. [9] 'per MS prefix model' defines the collection of all service flows (transport connections) to the same MS as a single link. An AR should treat the collection of service flows to each MS as a separate virtual link and manage a virtual interface for each virtual link. Each MS belongs to a different link. A different prefix should be assigned to a different link [2]. An AR assigns a separate 64-bit prefix on a link for each MS. Bear in mind that a prefix is assigned not to an MS but to the link between the MS and the AR. The AR advertises an assigned prefix by sending the prefix in a Router Advertisement (RA) message. To prevent steep routing table increase, the prefixes should be aggregated. An AR may get a 48-bit prefix, allocate 64-bit sub prefixes to MSs and inject only the aggregated prefix uplink. An AR has the pool of prefixes and assigns a prefix for each MS. The AR manages the prefix table to keep track of a prefix per an MS and forward packets properly. The AR advertises an MS its prefix according to the prefix table. If an MS sends an RS, the AR refers the prefix table to find the prefix associated with the soliciting MS and replies an RA to the MS with the prefix. When an MS moves within an AR and makes a new attachment, the AR recognizes its previous attachment and advertises the MS's existing prefix. The MS can keep using its existing IP address. When an MS moves to a different AR, the MS can't use the existing IP address and should perform mobility signaling. However, we may use prefix binding method defined in NEMO [4] to provide mobility support without an MS's involvement. When an MS, which is an ordinary IPv6 node, attaches to a New Access Router (NAR), during the AAA procedure the NAR finds out the MS's existing prefix and the AR to which the prefix is allocated. The NAR sends Choi, et al. Expires April 19, 2007 [Page 3] Internet-Draft pbm October 2006 the AR a prefix Binding Update (BU) for the MS's stead to establish a bi-directional tunnel with the AR. The NAR advertises the existing prefix to the MS which keeps using its IP address. The packets destined for the MS are delivered, through the tunnel, from the AR to the NAR and finally to the MS. Choi, et al. Expires April 19, 2007 [Page 4] Internet-Draft pbm October 2006 2. Terminology 2.1. Home Access Router (HAR) Each AR plays the role of NEMO Home Agent as defined in RFC 3963 [4]. When an MS is attached to an WiMAX AR for the first time, the AR assigns a prefix for the MS and becomes its Home Access Router (HAR). When the MS moves to a New Access Router (NAR), the HAR established the binding for the prefix with the NAR to provide mobility support. 2.2. Prefix table for AR An AR manages the prefix table which, as an entry, has 3-tuple of [MS ID, the prefix assigned for the MS, the virtual interface for the MS]. The prefix table is used to properly forward packets to its destination. (Further work is needed for lifetime management.) 2.3. Prefix table for AAA server An AAA server manages the prefix table which, as an entry, has 3-tuple of [MS ID, the prefix assigned for the MS, the MS's HAR address]. The prefix table is used to inform an NAR an MS's existing prefix and HAR address. (Further work is needed for lifetime management.) Choi, et al. Expires April 19, 2007 [Page 5] Internet-Draft pbm October 2006 3. Protocol Overview A WiMAX Access Router (AR) is an omniscient AR, i.e. it knows all MS attached to itself and all prefixes associated with MSs [9]. The AR manages a prefix table which, as an entry, has 3-tuple [MS ID, the prefix assigned for the MS, the virtual interface for the MS]. The virtual interface may be represented as a GRE key for the ISF. When a packet arrives, the AR compares the destination address's prefix with its prefix table to find an associated interface. The packet is delivered to the interface and forwarded to the destined MS accordingly. Each AR also plays the role of Home Agent for mobile router as of RFC 3963 [4]. When an MS is attached to an WiMAX AR for the first time, the AR becomes the MS's Home Access Router (HAR) and performs AAA procedure as defined in WiMAX specification. After completing access authentication, the HAR establishes an Initial Service Flow (ISF) with the MS. The HAR forms a virtual link with the ISF and manages a virtual interface for the link. The HAR assigns on the link a prefix from its prefix pool and adds a new entry of 3-tuple [MS ID, the newly assigned prefix, the associated virtual interface] to updates its prefix table. The HAR advertises the prefix to the MS by sending an RA with the prefix. The MS receives the RA and starts communication. The HAR also informs the prefix to the AAA server by sending 3-tuple of [MS ID, the prefix assigned for the MS, the HAR address for the MS] [5], [6]. Accordingly the AAA server update its prefix table. When the MS moves to a New Access Router (NAR), it performs AAA procedure. The NAR sends an AAA-Request message [5], [6] to the AAA server with the MS ID. The AAA server compares the MS ID with its prefix table to find a matching entry of [MS ID, the MS's prefix, the MS's HAR address]. When the AAA server sends the NAR an Access- Accept [5], [6] for the MS, it includes the MS's prefix and HAR address. Upon receiving the Access-Accept, the NAR detects the MS's prefix and HAR address. The NAR establishes another ISF. The NAR forms another link and an associated virtual interface. The NAR sends a prefix Binding Update (BU) message to the MS's HAR with the MS ID and the prefix. (Further work is needed for the exact message format.) Upon receiving the BU, if the HAR decides to accept the binding, the HAR establishes a bi-directional tunnel with the NAR. The HAR Choi, et al. Expires April 19, 2007 [Page 6] Internet-Draft pbm October 2006 manages a virtual interface for the tunnel and updates its prefix table accordingly. The HAR sends the NAR a prefix Binding Acknowledgement (BAck) accepting binding and the NAR establishes the bi-directional tunnel with the HAR. The NAR adds a new entry of 3-tuple [MS ID, the prefix, the virtual interface] to its prefix list and advertises the prefix to the MS with the RA message. The MS keeps using its existing IP address. When a corresponding node sends a packet to the MS, the packet is delivered to the HAR because the destination address's prefix is allocated to the HAR. The HAR compares the prefix of the packet's destination address with its prefix table and finds the associated interface, i.e. the tunnel end point. The packet is delivered to the interface and forwarded to the NAR through the bi-directional tunnel. Upon receiving the packet, the NAR also refers its prefix table to find the associated interface. The packet is delivered to the interface, i.e. GRE tunnel, and forwarded to the MS accordingly. Choi, et al. Expires April 19, 2007 [Page 7] Internet-Draft pbm October 2006 4. Protocol Specification 4.1. Home Access Router (HAR) operation 4.1.1. Assigning prefix When an MS attaches to a Home Access Router (HAR) for the first time, it performs access authentication procedure with an AAA server through the HAR. After completing access authentication procedure, the HAR grants network access to the MS and establish an Initial Service Flow (initial service flow) with the MS. With the ISF, the HAR forms a (virtual) link and manages a virtual interface for the link. The HAR assigns the link a 64bit prefix (Take notice that HAR is delegated a bigger prefix and allocate its subprefix for an MS.) and adds a new entry of [MS ID, the new prefix, the new virtual interface] to its prefix table. The HAR registers the newly assigned prefix to the AAA server [5], [6]. The HAR sends the 3-tuple of [MS ID, the prefix, the HAR IP address]. (Further work is needed about the exact AAA message format.) The HAR advertise the prefix to MS in a Router Advertisement (RA) message. Upon receiving the RA, the MS sets its IP configuration and starts communication. 4.1.2. Receiving Binding Update Upon receiving a prefix Binding Update (BU) message from a New Access Router (NAR), the HAR verifies the BU message properly. (Further work is needed about the exact BU format.) The HAR extracts the prefix and the MS ID from the BU and check whether the prefix belongs to its prefix table and the MS left the HAR. If not, it rejects the BU and send back Binding Acknowledgement (BAck) informing such. When the HAR determines that the prefix belongs to its prefix table, the MS left the HAR and decides to grants the binding to provide mobility support, it establishes the bi-directional tunnel with the NAR and forms a new virtual inteface to the tunnel. The HAR updates its prefix table accordingly and set lifetime as the BU lifetime in the BU message. Choi, et al. Expires April 19, 2007 [Page 8] Internet-Draft pbm October 2006 4.1.3. Forwarding packets When a packet destined for the prefix arrives, the HAR refers its prefix table and finds an associated interface. The HAR deliver the packet to the associated interface, i.e. the tunnel end-point and the packet is forwarded to the NAR through the tunnel. 4.2. New Access Router (NAR) operation 4.2.1. Detecting prefix When the MS moves to a New Access Router (NAR), it performs access authentication procedure with an AAA server through the NAR. The NAR sends Access-Request message [5], [6] to the AAA server with the MS ID. The AAA server replies with the Access-Accept message [5], [6] with the MS's prefix and HAR address. Upon receiving the Access-Accept, the NAR finds out the prefix assigned for the MS and the HAR to which the prefix is delegated. 4.2.2. Sending Binding Update The NAR establish a new Initial Service Flow (initial service flow) with the MS and with the ISF, the NAR forms a (virtual) link and manages a virtual interface for the link. The NAR sends a prefix Binding Update (BU) message to the MS's HAR with MS's prefix and MS ID. The NAR manages the Binding Update list accordingly. (Further work is needed for exact message format and Binding Update list management.) When the NAR receives a Binding Acknowledgement (BAck) message accepting binding, it establishes the bi-directional tunnel with the HAR. The NAR assigns the prefix to the (virtual) link for the MS and updates its prefix table accordingly. The NAR advertises the prefix to the MS with an RA message. The MS keeps using its current IP address. When the NAR receives a Binding Acknowledgement (BAck) message rejecting binding, the NAR assigns one of the prefixes assigned to itself to the (virtual) link for the MS and updates its prefix table accordingly. The NAR advertise the prefix to the MS with an RA message. The MS detects movement and changes its IP configuration. 4.2.3. Forwarding packets When a packet destined for the prefix arrives through the tunnel from the HAR, the NAR refers its prefix table and finds the associated Choi, et al. Expires April 19, 2007 [Page 9] Internet-Draft pbm October 2006 interface. The NAR deliver the packet to the interface and the packet is forwarded to the MS. 4.3. AAA server operation 4.3.1. Managing prefix An AAA server manages the prefix table which, as an entry, has 3-tuple of [MS ID, the prefix assigned for the MS, the MS's HAR address]. When an HAR informs a newly assigned prefix with the 3-tuple [MS ID, the prefix assigned for the MS, the MS's HAR address], the AAA server updates its prefix table accordingly. [Further work is needed for exact message format and signaling procedure.] 4.3.2. Informing prefix When the AAA server receives an AAA-Request message [5], [6] with an MS ID from an NAR, it checks its prefix table with the MS ID to find a matching entry, i.e. the MS's prefix and HAR address. If the AAA server grants network access and there is a matching entry, it sends the NAR the MS's prefix and HAR address in Access-Accept message [5], [6]. Choi, et al. Expires April 19, 2007 [Page 10] Internet-Draft pbm October 2006 5. Security Considerations TBD Choi, et al. Expires April 19, 2007 [Page 11] Internet-Draft pbm October 2006 6. References 6.1. Normative References [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [7] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [8] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 2005. [9] WiMAX Forum Network Working Group (NWG), http://www.wimaxforum.org 6.2. Informative References [10] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based Networks", draft-ietf-16ng-ipv6-link-model-analysis-00 (work in progress), October 2006. [11] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [12] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. Choi, et al. Expires April 19, 2007 [Page 12] Internet-Draft pbm October 2006 Authors' Addresses JinHyeock Choi Samsung AIT Networking Lab P.O.Box 111 Suwon 440-600 KOREA Phone: +82 31 280 9233 Email: jinchoe@samsung.com Hee Jin Jang Samsung AIT Networking Lab P.O.Box 111 Suwon 440-600 KOREA Phone: +82 31 280 9233 Email: heejin.jang@samsung.com Youngdon Chung Samsung Electronics Maetan 3 Youngtond Suwon KOREA Phone: +82 31 213 3506 Email: yd.chung@samsung.com Choi, et al. Expires April 19, 2007 [Page 13] Internet-Draft pbm October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Choi, et al. Expires April 19, 2007 [Page 14]