Mobileip Working Group H. Jung Internet Draft J. Min Document:draft-jung-mobileip-bet-enhance-00.txt ETRI/KOREA September 2002 An enhancement for limiting the length of tunnel in the fast handover method using bi-directional edge tunnel (BET) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Convention used in this draft 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 RFC 2119. Abstract To support real-time services such as VoIP in Mobile IPv4/v6, several fast handover methods have been proposed. The fast handover method using BET is one of them and was chosen as an alternate protocol to FMIPv6 version 4. BET has advantage in reducing the handover latency because it does not perform the layer 3 registration. However, the long BET in certain situation could be not acceptable. In that case, a mechanism is needed to limit the tunnel length of BET. In this draft, we propose to group the ARs by predefined value to limit the tunnel length of BET. An anchor router is changed whenever a MN changes its associated group. 1. Introduction To support real-time service such as VoIP in Mobile IPv4/v6, several fast handover methods have been proposed. The fast handover method using BET is one of them and was chosen as an alternate protocol to H. Jung, et al. draft-jung-mobileip-bet-enhance-00.txt [Page 1] INTERNET-DRAFT Expires: March 2003 September 2002 FMIPv6 version 4. BET has advantage in reducing the handover latency because it needs relatively simple procedure and does not perform the layer 3 registration. However, the long BET in certain situation could not be acceptable. In this case, a mechanism is needed to limit the tunnel length of BET. In the conventional BET, the length of BET is not limited regardless of its duration time, the number of routers on the path over BET and so on. It may bring unnecessary traffic into the backbone network. Also, a failure probability is increased because the number of router on the path is increased. In that case, a mechanism is needed to limit the length of BET. In this draft, we propose to group the ARs by predefined value to limit the length of BET. An anchor router is changed whenever MN moves into the other group. 2. Protocol behavior In our proposed protocol, ARs are classified into one or more groups and each group has an anchor AR. A group is not defined physically but configured logically. That is, groups can be configured by the number of AR change, hop count of BET and so on. The architecture of the protocol is shown in figure 1. +-------+ | CN/HA | +--+----+ | | +--|--------------++-------------------+ +-------------------+ |+-+---++-----+ ||+-----++-------+ | | +-------++-----+| ||AR(1)||AR(2)|...|||AR(p)||AR(p+1)|...|...|...|AR(k-1)||AR(k)|| |+-----++-----+ ||+-----++-------+ | | +-------++-----+| | aAR(1) || aAR(2) | |aAR(m) | +-----------------++-------------------+ +-------------------+ Group 1 Group 2 Group m Figure 1: The architecture of the protocol In the figure 1, ARs are configured with m groups which have p-1 ARs respectively. m groups have a anchor AR. There is no the change of anchor AR within same group. However, if the group of AR serving MN is changed according to MN's movement, the exchange of anchor AR is forced to limit the length of BET. H. Jung, et al. draft-jung-mobileip-bet-enhance-00.txt [Page 2] INTERNET-DRAFT Expires: March 2003 September 2002 For example, if MN moved from AR(p-1) to AR(p), then group ID will be changed. It means that the group serving MN is changed from group 1 to group 2. Therefore, an anchor AR should be also changed from aAR(1) to aAR(2). After that, aAR(2) plays a role of anchor AR for MN until the MN leaves the group 2. 2.2 Operation for exchanging anchor AR The figure 2 shows the operation of the exchange of anchor AR. We only consider in this draft the case that groups are defined simply by the number of AR change is considered in this draft. The case of using hop count of BET is for further study. Also only the source trigger. +-------+ | aAR |<---------+ +-------+ | | |2) HI(t)/HACK(b) | V +---------+ 1) HTT/HACK +---+----+ | AR(p-1) | <-------------> | AR(p) | +---------+ +--------+ (a) Message exchange when MN moves from AR(p-1) to AP(p) +-------+ | aAR |<-----------+ +-------+ | | |2b) HI(t)/HACK(t) | V +---------+ 2a)HTT(b)/HACK +--+------+ 1)ST ----> | AR(p) | <---------------> | AR(p+1) | +---------+ +---------+ (b) Message exchange when MN moves from AR(p) to AP(p+1) Figure 2. The exchange of a role as anchor AR An aAR counts the number of nAR changes. If the number becomes p-1 and aAR receives HI(t) , then aAR replies with HACK(b), which is a new message but can be made from existing HACK message simply, so as to request nAR(p) to do a role of anchor AR, which is the pth AR as H. Jung, et al. draft-jung-mobileip-bet-enhance-00.txt [Page 3] INTERNET-DRAFT Expires: March 2003 September 2002 shown in figure 2(a). After that, when an MN is going to move from AR(p) to AR(p+1) and pre-handover trigger (source or target trigger) is received, AR(p) sends HTT(b) message to AP(p+1) which includes the information for requesting the exchange of anchor AR as well as for aAR as shown figure 2(b). HTT(b) message also can be derived from HTT message easily. The AR receiving HTT(b) establish BET with AR(p) as well as aAR. Then AR(p) sends binding update message toward CN/HA. These two BETs are maintained even though the AR serving MN is changed until BU is succeeded and forwarded packets destined to MN arriving at current AR serving MN through AR(p). It is done for supporting the real-time property even during changing anchor AR. Current AR receiving forwarded packets destined to MN though AR(p) removes the BET to aAR. Now the anchor AR in BET is changed from aAR to nAR(p). The procedure is repeated whenever AR is p-th changed again. The figure 3 show the timing diagram of the operation described above. aAR AR(p+1) AR(p) CN/HA | | HI(t) | | |<-----------------------------------o | | | HACK(b) | | o----------------------------------->| | | | |<~~ ST | | HI(t) | HTT(b) | | |<----------------o<-----------------o | | HACK(t) | HACK | | o---------------->o----------------->| BU | | | o----------------->| | | | Forwarding data | | | Forwarding data |<-----------------o | |<-----------------o | | HI(r) | | | |<----------------o | | | HACK(r) | | | o---------------->| | | | | | | Figure 3: Timing diagram of the exchange of anchor AR H. Jung, et al. draft-jung-mobileip-bet-enhance-00.txt [Page 4] INTERNET-DRAFT Expires: March 2003 September 2002 3. Packet Formats There is no new message except a message to request of exchange of anchor role to AR(p) and AR(p+1). Even these messages can be made easily with existing HACK and HTT message in the existing BET protocol. We have named this message as HACK(b) and HTT(b). The format of HACK(b) is shown in figure 4 and HTT(b) is obtained from HI and HACK. Only one difference with existing HACK message is the B bit which was a bit in reserved field in case of existing message. If a AR receives HACK(b) message in which B bit is set to 1, the AR have to take a role of anchor AR including sending BU to CN/HA, as described in section 2. 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 |H|T|R|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 4: The message format of HACK(b) 4. References [1] G. Dommety et. al., "Fast Handovers for Mobile IPv6," IETF Internet Draft draft-ietf-mobileip-fast-mipv6-04.txt, March 2002 [2] Karim El Malki et. al., "Low Latency Handoffs in Mobile IPv4," IETF Internet Draft draft-ietf-mobileip-lowlatency-handoffs-v4- 04.txt, June 2002 [3] James Kempf et. al., " Bidirectional Edge Tunnel Handover for IPv6," IETF Individual Draft draft-kempf-beth-ipv6-02.txt, Sep 2001 [4] James Kempf et. al., "Post-handover Mobile Initiated Tunneling for Fast Mobile IPv4 Handover," IETF Individual Draft draft-kempf- mobileip-postmit-handover-00.txt, Dec 2001 H. Jung, et al. draft-jung-mobileip-bet-enhance-00.txt [Page 5] INTERNET-DRAFT Expires: March 2003 September 2002 7. Authors' Addresses HeeYoung Jung Protocol Engineering Center Electronics and Telecommunication Research Institute 161 Kajung-Dong, Yusong-Gu, Taejon, Korea Phone: +82 42 860-4928 EMail: hyjung@etri.re.kr Fax: +82 42 861-5404 Jae Hing Min Protocol Engineering Center Electronics and Telecommunication Research Institute 161 Kajung-Dong, Yusong-Gu, Taejon, Korea Phone: +82 42 860-5805 EMail: jhmin@etri.re.kr Fax: +82 42 861-5404 Full Copyright Statement "Copyright(C) The Internet Society(2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." H. Jung, et al. draft-jung-mobileip-bet-enhance-00.txt [Page 6]