Network Working Group P. Kim Internet-Draft Korea Polytechnic University Expires: December 14, 2006 June 15, 2006 Fast Handover for Mobile IPv6 Based IEEE802.16e Wireless Networks draft-pskim-fho16e-arid-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 December 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft proposes a new fast handover mechanism for Mobile IPv6 based IEEE 802.16e wireless networks. To implement the proposed mechanism, the IEEE 802.16e neighbor advertisement message, named MOB_NBR-ADV, sent periodically by a serving base station (BS) is assumed to be defined newly by adding a specific subfield to the available reserved field. In addition, Router Information Request/Reply messages used in the network layer are defined newly. The proposed mechanism provides the faster acquisition of new access router's network information than the existing one, which might be advantageous for the low handover latency. In addition, the proposed mechanism might reduce amount of traffic in comparison with the existing one, which might be remarkable when there are many mobile nodes that are now connecting to the current access router (AR). Moreover, in the proposed mechanism, a mobile node can know whether it changes AR or BS, which can remove redundant traffic of the existing one. Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 1] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Configuration and Router . . . . . . . . . . . . . . . 4 4. New Fast handover mechanism . . . . . . . . . . . . . . . . . 4 4.1 New IEEE 802.16e Neighbor Advertisement Message . . . . . . 5 4.2 Router Information Request/Reply Message Formats . . . . . . 5 5. Operation Procedure of Proposed mechanism . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 2] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 1. Introduction In future Mobile IPv6 based IEEE 802.16e wireless networks, the need to communicate efficiently on the move and to minimize to packet loss caused by a handover is becoming increasingly important because a handover latency would be unacceptable for real-time Internet services. Thus, in recent, a fast handover mechanism [1]-[3] has been proposed for Mobile IPv6 as a way to reduce a L3 handover latency. In the curren draft, a new fast handover mechanism is proposed to reduce the L3 handover latency for Mobile IPv6 based IEEE 802.16e wireless networks where there are several access routers (ARs) connected by base stations (BSs). To implement the proposed mechanism, the IEEE 802.16e neighbor advertisement message, named MOB_NBR-ADV, sent periodically by a serving BS is assumed to be defined newly by adding a specific subfield to the available reserved field. Using this message, a mobile node (MN) can know whether it changes AR or BS. In addition, Router Information Request/Reply messages used in L3 are defined newly. Using these messages, the MN can acquire network information about all ARs, such as ARs' IP addresses, prefix lengths, and identifiers, which is performed once only at the booting time and isn't performed in real-time communication. In real-time communication, this network information allows the MN to formulate a new care-of address and to be able to communicate immediately when the MN changes its point of attachment from the current AR (CAR) to the new AR (NAR). That is, the proposed mechanism can omit a Router Solicitation for a Proxy (RtSolPr) message and a Proxy Router Advertisement (PrRtAdv) message used in the existing one [1]-[3], in real-time communication. This means that the proposed mechanism provides the faster acquisition of NAR's network information than the existing one, which might be remarkable for low L3 handover latency. In addition, the omission of above two messages might reduce amount of traffic when there are many MNs that are now connecting to the CAR. Moreover, in the proposed mechanism, the MN can know whether it changes AR or BS while the existing one cannot. Thus, when the MN changes BS, the proposed mechanism can remove redundant traffic of the existing one. 2. Requirements 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]. Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 3] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 3. Network Configuration This draft considers an IEEE 802.16e wireless network where there are serveral ARs connected by several BSs as shown in Figure 1. This network configuration is feasible because several access routers in the IEEE 802.16e wireless network can cover quite wide area where the MN can moves. These ARs can share each other's network information, such as ARs' IP addresses, prefix lengths, and identifiers, and thus may have information table that will be called the Router Information Table (RIT). Note that the BS can know its AR identifier (ARID) by a system administrator's presetting. Note that a change of BS on same subnet does not require a change of AR because the handover between two BSs (i.e., between BS5 and BS7) within same subnet can be carried out using link layer mobility without IP mobility. The handover between two BSs is outside the scope of L3 handover mechanisms. However, a change of BS between different subnets (i.e., between BS7 and BS8) require a change of AR using IP mobility, because the MN would be attaching to a different subnet. In this case, a L3 handover mechanism would need to be invoked in order to provide low handover latency between the two ARs. Therefore, it should be required to know whether the MN changes BS or AR. Note that this draft borrows all of the terminology from the existing mechanism [1]-[3] and the IEEE 802.16e specification [4]. BS1 BS2 BS3 BS4 \ | | / \ \ / / \ \ / / /-----------\ | AR1 | \-----------/ | /-------------------------------------\ | IP Backbone | \-------------------------------------/ | | /-----------\ /-----------\ | AR2 | | AR3 | \-----------/ \-----------/ / | \ / / | \ \ / | \ / / | \ \ / | \ / | | | \ BS5 BS6 BS7 BS8 BS9 BS10 BS11 BS12 Figure 1. The 802.16e Wireless Network 4. New Fast Handover Mechanism In this section, a new fast handover mechanism is proposed for the Mobile IPv6 based IEEE 802.16e wireless network with serveral access routers. Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 4] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 4.1 New IEEE 802.16e Neighbor Advertisement Message (MOB_NBR-ADV) In order to implement the proposed mechanism, the IEEE 802.16e neighbor advertisement message[4], named MOB_NBR-ADV, sent periodically by a serving BS is assumed to be defined newly by adding a specific subfield "ARID" to the available reserved field. Since this field uses the available reserved field, other fields are not affected. Using this new message, the MN can know whether it changes AR or BS, which will be explained later. 4.2 Router Information Request/Reply Message Formats In order to implement the proposed mechanism, Router Information Request/Reply messages used in L3 are defined newly. These messages are made from the Internet Control Message Protocol for IPv6 (ICMPv6) in [5]. Then, using these messages, the MN performs the Router Information Request/Reply at its booting time. Fig. 1 shows the Router Information Request message. This message is used by the MN to request network information about all ARs from one of them. The description of each fields are as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig.1 Router Information Request Message Formats o Type : 160 (or any available value) o Code : 0 o Identifier : MUST be set by the sender so that replies can be matched to this request. o Reserved : MUST be set to zero by the sender and ignored by the receiver. In the IP header of this message, the source address is an IP address assigned to the sending interface and the destination address is the address of the all routers multicast address. Fig. 2 shows the Router Information Reply message that is used to acknowledge receipt of a Router Information Request. Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 5] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Number of ARs | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARID | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + AR's IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARID | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + AR's IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig.2 Router Information Reply Message Formats o Type : 161 (or any available value) o Code : 0 o Checksum : The ICMP checksum. o Identifier : Copied from Router Information Request. o Number of ARs : The number of ARs' addresses. o ARID : ARs' identity. o Prefix Length : The prefix length of AR's address. o AR's IP Address : IPv6 Address of AR In the IP header of this message, the source address is an IP address assigned to the sending interface and the destination address is the Source Address of an invoking Router Information Request. Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 6] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 5. Operation Procedure of Proposed Mechanism The operation procedure of the proposed mechanism is described and the comparison with the existing one [1]-[3] is shown. When the MN is booting, it sends a Router Information Request message using all routers multicast address to current subnet in order to acquire network information about all ARs, ARs' IP addresses, prefix lengths, and identifiers. In response to Router Information Request message, the current AR (CAR) on the current subnet sends a Router Information Reply message using the RIT. Then, the MN receives this reply message and caches the RIT in this reply message. Note that this Router Information Reqeust/Reply is performed once only at the booting time and thus isn't performed in real-time communication. Assume that the MN communicates with the corresponding node (CN). In real-time communication, when the MN moves, the "trigger" may arrive from specific L2 events that might determine the need for handover. In this draft, this trigger itself is not specified in detail. Since this trigger is based on MOB_NBR-ADV given by BS, the MN can know the ARID of its BS from the trigger. Then, the MN checks this ARID using the RIT cached previously, in order to determine whether the MN changes BS or AR. If the MN changes BS, it continues real-time communication via the CAR. Otherwise, the MN finds the new AR (NAR) corresponding to ARID from the RIT, and formulates a new care-of address (NCoA) using the prefix of the NAR's address. On the other hand, in the existing mechanism [1]-[3], once a new BS is detected through the reception of MOB_NBR-ADV containing the BS identifier (BSID), the MN tries to learn the associated AR information. Thus, the MN sends a Router Solicitation for a Proxy (RtSolPr) message to the CAR in order to acquire network information of the NAR in real-time communication. To response to RtSolPr message, the CAR finds the network information about the NAR corresponding to BSID from the RIT, and sends a Proxy Router Advertisement (PrRtAdv) message with the network information about the NAR to the MN. Note that these RtSolPr and PrRtAdv are performed even if the MN changes BS without change of AR. Then, the MN receives this reply message and determines whether the MN changes BS or AR. If the MN changes BS, it continues real-time communication via the CAR. Otherwise, the MN formulates a NCoA using the prefix of the NAR's address. After then, in both the proposed mechanism and the existing one, the MN associates its current CoA (CCoA) with NAR's IP address for forwarding purposes using a Fast Binding Update (FBU). Then, the CAR sends a Fast Binding Acknowledgment (FBACK) message to the MN and the NAR. The FBACK message confirms whether NCoA could be used, only after which the MN must use NCoA on the new subnet. At this time, the CAR sends a Handover Initiate (HI) message to NAR, after looking up the IP address corresponding to ARID supplied by the MN using its RIT. This FBU/FBACK and HI/HACK allows that packets arriving at the Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 7] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 CAR can be tunneled to the NAR. When the MN has confirmed its NCoA and then completes the Binding Update procedure with its CN, the MN continues real-time communication with the CN using NCoA as its source IP address via the NAR. 6. Advantages over Existing Mechanism The proposed mechanism provides several advantages over the existing one in [1]-[3]. As mentioned in Section 5, the proposed mechanism can omit RtSolPr/PrRtAdv messages used in the existing one, in real-time communication. The proposed mechanism provides the faster acquisition of NAR's network information than the existing one, which might be advantageous for the low L3 handover latency. In addition, the omission of above two messages might reduce amount of traffic in comparison with the existing one, which might be remarkable when there are many mobile nodes that are now connecting to the CAR. Moreover, in the proposed mechanism, the MN can know whether it changes AR or BS, while the existing one cannot. Thus, when the MN changes BS, the proposed mechanism can remove redundant traffic of the existing one. However, when there are many ARs on the IEEE 802.16e wireless network, the size of the RIT may increase. Then, the more memory is required for the MN to cache the RIT, which may be a weak point of the proposed mechanism. 7. References [1] Shim, M., Wood, J., Fu, G. "A Fast Handover Mechanism For IPv6 Based WiBro System" In: ICA0T2006, 2003. [2] Jang, H. "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", IETF Draft:draft-jang-mipshop-fh80216e-02.txt, Feb 2006. [3] Koodli, R. "Fast Handovers for Mobile IPv6", IETF RFC 4068, Jul 2005. [4] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 802.16e/D12, October 2005. [5] Conta, A., Deering, S. "Internet Control message Protocol (ICMP) for the Internet Protocol Version 6 (IPv6) Specification", IETF RFC 2463, December 1998 Authors' Addresses Pyungsoo Kim Department of Electronics Engineering, Korea Polytechnic University, 2121 Jungwang-Dong, Shiheung City, Gyeonggi-Do 429-793 KOREA Phone: +82 31 496 8413 EMail: pskim@kpu.ac.kr Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 8] Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 9]