Network Working Group H. Yokota Internet-Draft KDDI Lab Intended status: Informational G. Dommety Expires: May 17, 2008 Cisco Systems, Inc. November 14, 2007 Mobile IPv6 Fast Handovers for 3G CDMA Networks draft-ietf-mipshop-3gfh-04.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 May 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Yokota & Dommety Expires May 17, 2008 [Page 1] Internet-Draft 3G CDMA Fast Handover November 2007 Abstract Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new care-of address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Network reference model for Mobile IPv6 over 3G CDMA networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Fast handover procedures . . . . . . . . . . . . . . . . . . . 8 5.1. Predictive fast handover . . . . . . . . . . . . . . . . . 8 5.2. Reactive fast handover . . . . . . . . . . . . . . . . . . 13 5.3. Network-controlled fast handover . . . . . . . . . . . . . 15 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Handover Assist Information Option . . . . . . . . . . . . 18 6.2. New flag extension to FBU message . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Yokota & Dommety Expires May 17, 2008 [Page 2] Internet-Draft 3G CDMA Fast Handover November 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 [1]. Yokota & Dommety Expires May 17, 2008 [Page 3] Internet-Draft 3G CDMA Fast Handover November 2007 2. Introduction Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP connectivity while the MN moves around in the IPv6 network. It is adopted in 3G CDMA networks for handling host based mobility management [7]. During handover, however, the mobile node (MN) needs to switch the radio link, to obtain a new Care-of Address (CoA) and to re-register with the home agent (HA), which may cause a communication disruption. This is not desirable for real-time applications such as VoIP and video telephony. To reduce this disruption time or latency, a fast handover protocol for Mobile IPv6 [3] is proposed. RFC4260 [4] further describes how this Mobile IPv6 Fast Handover could be implemented on link layers conforming to the IEEE802.11 suite of specifications. However, 3G CDMA and IEEE802.11 networks are substantially different in the radio access, the representations of the network nodes or parameters and the network attachment procedures; for example, the beacon scanning or NAR discovery based on [AP-ID, AR-info] tuples specified in RFC4260 can not be directly applied to 3G CDMA networks. This document therefore specifies how Mobile IPv6 fast handovers can be applied in the 3G CDMA networks. In addition to the predictive and reactive fast handovers defined in RFC4068, if the lower layer can provide necessary information for handover, network-controlled fast handover can also be applied and hence defined in this document. Yokota & Dommety Expires May 17, 2008 [Page 4] Internet-Draft 3G CDMA Fast Handover November 2007 3. Terminology This document refers to [3] and [10] for Mobile IPv6 fast handover terminology. Terms that first appear in this document are defined below: Forward Pilot Channel: A portion of the Forward Channel that carries the pilot. The Forward Channel is a portion of the physical layer channels transmitted from the 3G CDMA access network to the MN. Further, several sets of pilots (e.g. the active set or neighbor set) are defined to determine when and where to handover. Sector: A typical cell divides its coverage area into several sectors. In 3G CDMA systems, each sector uses a different PN (Pseudo Noise) code offset. Home Link Prefix (HLP): The prefix address assigned to the home link where the MN should send the binding update message. This is also called as Home Network Prefix (HNP) and one of the bootstrap parameters for the MN. Packet Data Serving Node (PDSN): An entity that routes MN originated or MN terminated packet data traffic. A PDSN establishes, maintains and terminates link- layer sessions to MNs. A PDSN is the access router in the visited access provider network. Access Network Identifier (ANID) An identifier that is used by the PDSN to determine whether the MN is being handed off from the access network that was not previously using this PDSN. Anytime the MN crosses into a new region, which is defined by the ANID, it must re-register with that Access Network. The ANID is further composed of the System ID (SID), Network ID (NID) and Packet Zone ID (PZID) and these values are administrated by the operator. Yokota & Dommety Expires May 17, 2008 [Page 5] Internet-Draft 3G CDMA Fast Handover November 2007 4. Network reference model for Mobile IPv6 over 3G CDMA networks Figure 1 shows a simplified reference model of the Mobile IP enabled 3G CDMA networks. The home agent (HA) and AAA server (AAA) of the mobile node (MN) reside in the home IP network and the MN roams within or between the access provider network(s). Usually, the home IP network is not populated by the MNs, which are instead connected only to the access provider networks. Prior to the Mobile IPv6 registration, the MN establishes a 3G CDMA access technology specific link-layer connection with the access router (AR). When the MN moves from one AR to another, the link-layer connection is re-established and a Mobile IPv6 handover is performed. Those ARs reside in either the same or different access provider network(s). The figure shows the situation, where the MN moves from the previous access router (PAR) to the new access router (NAR) via the radio access network (RAN). Home IP Network +........................+ . +--------+ +--------+ . . | HA |--| AAA | . . +--------+ +--------+ . +../......\..............+ / \ Access Provider Network(s) +.............+ +.............+ . +---------+ . . +---------+ . . | PAR | . . | NAR | . . +---------+ . . +---------+ . . |: . . :| . . |:L2link L2link:| . . |: . . :| . . +----+:---+ . . +---:+----+ . . | RAN | . . | RAN | . . +----+:---+ . . +---:+----+ . . |: . . :| . . +----+ . . +----+ . . | MN | ---------> | MN | . . +----+ . . +----+ . +.............+ +.............+ Figure 1: Reference Model for Mobile IP In 3G CDMA networks, pilot channels transmitted by base stations allow the MN to obtain a rapid and accurate C/I (carrier to interference) estimate. This estimate is based on measuring the strength of the Forward Pilot Channel or the pilot, which is associated with a sector of a base station (BS). The MN searches for Yokota & Dommety Expires May 17, 2008 [Page 6] Internet-Draft 3G CDMA Fast Handover November 2007 the pilots and maintains those with sufficient signal strength in the pilot sets. The MN sends measurement results, which include the offsets of the PN code in use and the C/Is in the pilot sets, to provide the radio access network (RAN) with the estimate of sectors in its neighborhood. There are several triggers for the MN to send those estimates, e.g. when the strength of a pilot in the pilot sets is higher enough than that of the current pilot, the MN sends the estimates to the access network. If the serving access network finds that the sector associated with the highest pilot strength belongs to a different AR, it attempts to close the connection with the MN. The MN then attempts to get a new traffic channel assigned in the new access network, which is followed by establishing a new connection with the new AR. The MN can continually search for pilots without disrupting the data communication and a timely handover is assisted by the network. If the air interface information can be used as a trigger for the handover between access routers, fast and smooth handover of Mobile IPv6 can be realized in 3G CDMA networks. To assist the handover of the MN to the new AR, various types of information can be considered: the pilot sets, which include the candidates of the target sectors or BSs, the cell information where the MN resides, the serving nodes in the radio access network and the location of the MN if available. To identify the access network that the MN moves to or from, the Access Network Identifiers (ANID) or the subnet information can be used [5][6]. In this document, a collection of such information is called "handover assist information". In 3G CDMA networks, the link-layer address of the new access point defined in [3] may not be available. If this is the case, the handover assist information SHOULD be used instead. Yokota & Dommety Expires May 17, 2008 [Page 7] Internet-Draft 3G CDMA Fast Handover November 2007 5. Fast handover procedures There are two modes defined in [3] according to the time of sending the FBU (Fast Binding Update); one is called "predictive mode," where the MN sends the FBU and receives the FBAck (Fast Binding Ack) on the PAR (Previous Access Router)'s link and the other is called "reactive mode," where the MN sends the FBU from the NAR (New Access Router)'s link. In the predictive mode, the time and place the MN hands off must be indicated sufficiently before the time it actually happens. In cellular systems, since handovers are controlled by the network, the predictive mode is well applied. However, if the network is not configured to be able to identify the new AR, to which the MN is moving next, in a timely manner, the reactive mode is better applied. 5.1. Predictive fast handover Figure 2 shows the predictive mode of MIPv6 fast handover operation. When the MN finds a sector or a BS whose pilot signal is sufficiently strong, it initiates handover according to the following sequence: (a) A router solicitation for proxy router advertisement is sent to the PAR. Handover assist information for the target 3G CDMA network (e.g. pilot sets as described in Section 4) is attached to this message. (b) Based on the received handover assist information, the NAR is determined and a proxy router advertisement containing the prefix in the NAR is sent back to the MN. (c) The MN creates an NCoA (new CoA) and sends the Fast Binding Update (FBU) with the NCoA to the PAR, which in turn sends the Handover Initiate (HI) to the NAR. (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR, which in turn sends the FBU acknowledgment (FBAck) to the MN. (e) The PAR starts forwarding packets toward the NCoA and the NAR captures and buffers them. (f) The link-layer connection associated with the PAR is closed and a new traffic channel is assigned in the new access network. (g) The MN attaches to the new access network. The attachment procedure is access technology specific and that for 3G CDMA network including the PPP transactions is described later. (h) The MN sends the Unsolicited Neighbor Advertisement (UNA). Yokota & Dommety Expires May 17, 2008 [Page 8] Internet-Draft 3G CDMA Fast Handover November 2007 (i) The NAR starts delivering packets to the MN. (j) The MN sends the BU to the HA to update the BCE with the NCoA and the HA sends back the BA to the MN. MN PAR NAR HA AAA | RtSolPr | | | | (a) |------------->| | | | | PrRtAdv | | | | (b) |<-------------| | | | | FBU | Hl | | | (c) |------------->|-------------->| | | | FBack | HAck | | | (d) |<-------------|<--------------| | | | |forward packets| | | (e) | |==============>|(buffering) | | | | | | | (f) handover | | | | | | | | | +--------------------------------------------------------------+ (g) | Attachment procedure | +--------------------------------------------------------------+ | UNA | | | (h) |----------------------------->| | | | deliver packets | | | (i) |<=============================| | | | | BU/BA | | | (j) |<------------------------------------------->| | | | | | | Figure 2: MIPv6 Fast handover operation (predictive mode) It is assumed that the NAR can be identified by the PAR leveraging the handover assist information from the MN. To perform the predictive mode, the MN MUST send the FBU before the connection with the current access network is closed. If the MN fails to send the FBU before handover, it SHOULD fall back to the reactive mode. Even if the MN successfully sends the FBU, its reception by the PAR may be delayed for various reasons such as congestion. If the NAR receives the HI triggered by the delayed FBU after the reception of the UNA ((c) comes after (h)), then the NAR SHOULD send the HAck with handover not accepted and behave as the reactive mode. In (a), it is mandated that RtSolPr includes the New Access Point and the MN Link-Layer Address (LLA) options (Option Code=1 and 2, respectively) according to [3]. As for the MN-LLA option , the only available identifier is the interface ID, so it SHOULD be used for Yokota & Dommety Expires May 17, 2008 [Page 9] Internet-Draft 3G CDMA Fast Handover November 2007 the MN-LLA. As for the New AP-LLA option, however, the handover assist information MAY replace it in 3G CDMA networks. Since the LLA is assumed to be an IEEE identifier, even if the length field of the LLA option is in units of 8 octets, the actual length can be obtained by knowing that the length of an IEEE identifier is 6 octets. If the interface ID of the MN is generated in the EUI-64-based format, the MN-LLA can be constructed from it. However, if the type of the MN- LLA is not known, the length of the LLA becomes ambiguous. If this is the case, it is necessary to use a new option defined in Section 6.1 and the corresponding length in it. In (b), PrRtAdv MUST include options for the IP address of the NAR, which may be the link-local address, and the prefix for the MN. The PAR SHOULD be able to identify the NAR from the handover assist information provided by the MN. Figure 3 shows the call flow for the initial attachment in the 3G CDMA network [7]. After the traffic channel is assigned, the MN first establishes a link-layer connection between itself and the access router. As the link-layer protocol, PPP can be considered and in this figure, a PPP handshake is depicted as an example. Then the MN registers with the HA by sending a Binding Update message. There are several parameters for using Mobile IPv6 such as the home address (HoA), the care-of address (CoA), the home agent address (HA) and the home link prefix (HLP). In [7], obtaining these values is called bootstrapping and the bootstrapping information can be obtained during the link-layer establishment phase and/or the mobility binding phase [11]. Yokota & Dommety Expires May 17, 2008 [Page 10] Internet-Draft 3G CDMA Fast Handover November 2007 MN PAR NAR HA AAA / | (serving PDSN) (target PDSN) | | | | LCP | | | | | (1) |<----------------------->| | | | | CHAP/PAP | Access-Request/Accept | | (2) |<----------------------->|<-------------|------->| |. | | +------+ | | | |.(3)* | | | HA |<---------+ | |. | | +------+ | | |+........................................+ | | |. | | . | | |. | IPv6CP(IF-ID) | . | | |.(4)* |<---------|------------->| . | | (g)< . +---------+ | | | . | | |.(5)*| LL-addr |<-+ | | . | | |. +---------+ | | . | | |. | | . | | |. | RA(prefix) | . | | |.(6)* |<---------|--------------| . | | |. +-----+ | | | . | | |.(7)*| CoA |<-----+ | | . | | |. +-----+ | | . | | |+........................................+ | | | | DHCPv6(HA) | | | | (8) |<---------------+------->| | | | +-----+ | | | | | | (9) | HA |<-----------+ | | | | +-----+ | | | | | | | | | | \ | | | | | Figure 3: Attachment procedure in 3G CDMA network The procedure for the initial attachment is as follows: (g) The link-layer connection establishment and the bootstrapping phase (g-1) The LCP (Link Control Protocol) configure-request/response messages are exchanged. (g-2) User authentication (e.g. CHAP or PAP) is conducted. (g-3) The static bootstrapping information is conveyed from the AAA and stored in the NAR (target PDSN). The HoA and HLP can be dynamically assigned by the HA in the mobility binding phase. This step can be skipped in the handover case. Yokota & Dommety Expires May 17, 2008 [Page 11] Internet-Draft 3G CDMA Fast Handover November 2007 (g-4) Unique interface IDs are negotiated in IPv6CP. (g-5) The MN configures its link-local address based on the obtained interface ID. (g-6) A router advertisement containing the prefix is received by the MN. (g-7) The MN configures its CoA based on the obtained prefix. (g-8) DHCPv6 is used to obtain the static bootstrap information (e.g. the HA address). This step is performed in the initial attachment and can be skipped once the MN obtains those parameters. (g-9) The MN installs the bootstrap information for further procedures (e.g. the mobility binding). As is shown in Figure 3, it takes a considerable amount of time to establish a link-layer connection and almost all of the above sequences run every time the MN attaches to a new access network. It is therefore beneficial if packets in transit to the MN are saved not only during the time period where the MN switches to the new radio channel but also during the time period where the MN establishes the link-layer connection. There are several ways to configure a unique IP address for the MN. If a globally unique prefix is assigned per link as introduced in [7], the MN can use any interface ID except that of the other peer (the AR to which the MN is attached) to create a unique IP address. If this is the case, however, the PAR cannot provide the MN with a correct prefix for the new network in the PrRtAdv since such a prefix is selected by the NAR and provided in the router advertisement. The MN therefore configures a temporary NCoA with the prefix provided by the PAR and the correct NCoA MUST be assigned by the NAR. Therefore, in 3G CDMA network, the PAR MUST send the HI with the S flag set when it receives the FBU from the MN at step (c) in Figure 2. In [10], the UNA MUST include the LLA of the MN, but the point-to- point link-layer connection makes it unnecessary. The only required information is the NCoA to check if there is a corresponding buffer. Thus, in (h) function of the UNA can be realized in several ways including the case where the MN does not support the UNA. o Since the establishment of the link-layer connection in (g) indicates readiness of data communication on the MN side, the NAR immediately checks if there is a buffer that has packets destined for the NCoA, which was configured at steps (c) - (d), and starts Yokota & Dommety Expires May 17, 2008 [Page 12] Internet-Draft 3G CDMA Fast Handover November 2007 delivering if any. (elimination of UNA) o The UNA equivalent information can be conveyed in the phase of the link-layer connection, e.g. by conveying the NCoA in a PPP IPCP with vendor specific extension as defined in [8]. Only when this message is received by the NAR, it checks if there is a buffer for the NCoA. (L2 implementation of UNA) o The MN sends the UNA as defined in [3] with the LLA of the MN, which may be derived from the EUI-64 based interface ID. (standard implementation of UNA) If PPP IPCP option can be and is used as the means for the L2 implementation of UNA, it SHOULD be confirmed that the NAR supports this option, otherwise it may cause a longer delay by the Configure- Reject message. The primary benefit of this mode is that the packets destined for the MN can be buffered at the NAR, and packet loss due to handover will be much lower than that of the normal MIPv6 operation. Regarding the bootstrapping, the following benefit can be obtained, too: o Since the NCoA can be configured via the fast handover procedures, a router advertisement is not required. Therefore, the procedures (g-4) to (g-7) can be skipped from the standard MIPv6 operation in Figure 3. Also, if the security policy permits and the PPP state can be transferred from the PAR to the NAR, the PPP link setup (g-1) and the authentication in (g-2) may be omitted. 5.2. Reactive fast handover When the MN cannot receive the FBAck on the PAR's link or the PAR in the 3G CDMA network cannot accurately resolve the address of the NAR, the reactive fast handover can be applied. To minimize packet loss in this situation, the PAR instead of the NAR can buffer packets for the MN until the MN regains connectivity with the NAR. The NAR obtains the information of the PAR from the MN on the NAR's link and receives packets buffered at the PAR. In this case, the PAR does not need to know the IP address of the NAR or the NCoA and just waits for the NAR to contact the PAR. However, since the PAR needs to know when to buffer packets for the MN, the PAR obtains the timing of buffering from the MN via the FBU or the lower layer signaling, e.g. an indication of the release of the connection with the MN. Details of the procedure are as follows: Yokota & Dommety Expires May 17, 2008 [Page 13] Internet-Draft 3G CDMA Fast Handover November 2007 (a) A router solicitation for proxy router advertisement MAY be sent to the PAR. (b) The proxy router advertisement MAY be sent to the MN, but the prefix of the NAR MAY not be included. (c) The MN sends the FBU or the access network indicates the close of the connection with the MN by the lower layer signaling. The PAR MAY start buffering packets destined for the PCoA. (d) The link-layer connection associated with the PAR is closed and a new traffic channel is assigned in the new access network. (e) The MN attaches to the new access network. This part is the same as described in Section 5.1 and illustrated in Figure 3. (f) The MN sends the Fast Binding Update (FBU) to the NAR. The FBU does not need to be encapsulated by the Unsolicited Neighbor Advertisement (UNA) since the uniqueness of the NCoA is guaranteed at step (e). (g) The NAR sends the FBU to the PAR. (h) The PAR sends the Handover Initiate (HI) to the NAR with the Code set to 1. (i) The NAR sends the Handover Acknowledge (HAck) back to the PAR. (j) The PAR sends the FBAck to the NAR. (k) If the PAR is buffering packets destined for the PCoA, it starts forwarding them as well as newly arriving ones to the NAR. (l) The NAR delivers the packets to the MN. (m) The MN sends the BU to the HA to update the BCE with the NCoA and the HA sends back the BA to the MN. Yokota & Dommety Expires May 17, 2008 [Page 14] Internet-Draft 3G CDMA Fast Handover November 2007 MN PAR NAR HA AAA | RtSolPr | | | | (a) |------------->| | | | | PrRtAdv | | | | (b) |<-------------| | | | | FBU | | | | (c) |- - - - - - ->|(buffering) | | | | | | | | (d) handover | | | | | | | | | +--------------------------------------------------------------+ (e) | Attachment procedure | +--------------------------------------------------------------+ | FBU | | | (f) |----------------------------->| | | | | FBU | | | (g) | |<--------------| | | | | HI | | | (h) | |-------------->| | | | | HAck | | | (i) | |<--------------| | | | | FBack | | | (j) | |-------------->| | | | |forward packets| | | (k) | |==============>| | | | deliver packets | | | (l) |<=============================| | | | | BU/BA | | | (m) |<------------------------------------------->| | | | | | | Figure 4: MIPv6 Fast handover operation (reactive mode) To indicate the PAR to buffer packets destined for the PCoA, in step (c), a new flag 'B' is defined in the FBU. When the PAR receives the FBU with this flag set, it SHOULD buffer packets for the MN. The PAR also start buffering packets for the MN based on lower layer signal during handover. 5.3. Network-controlled fast handover If the lower layer can provide necessary information for handover and support handover triggering, the fast handover can also be provided to MNs that do not support FMIPv6. RtSolPr, FBU and UNA, which are initiated by the MN, may be replaced by such lower layer protocols and the fast handover can be performed without explicit involvement of the MN. This type of fast handover has been proposed, for example, in [9] and called the network-controlled fast handover in Yokota & Dommety Expires May 17, 2008 [Page 15] Internet-Draft 3G CDMA Fast Handover November 2007 this document. The detailed call flow is shown in Figure 5. (a) The MN initiates the handover procedure with the currently connected network, which may interact with the new network. The handover initiation procedure is 3G CDMA specific. (b) The PAR (typically) sends the HI to the NAR; however, the NAR may instead send the HI to the PAR based on the lower-layer trigger from the radio access network. (c) The AR that received the HI sends back the HAck to the peer AR and MAY request access technology specific information. (d) The AR that received the HAck MAY return the HAck to the peer AR to confirm the reception of the HAck and MAY send access technology specific information. (e) The PAR starts forwarding packets to the NAR and the NAR MAY buffer them. (f) The link-layer connection associated with the PAR is closed and a new traffic channel is assigned in the new access network. (g) The MN attaches to the new access network. This part is the same as described in Section 5.1 and illustrated in Figure 3. (h) The NAR starts delivering packets to the MN. (i) The MN sends the BU with the CoA being the NCoA to the HA and the HA sends back the BA to the MN after successful authentication of the BU. From this time on, the HA starts sending packets directly to the MN via the NAR. Yokota & Dommety Expires May 17, 2008 [Page 16] Internet-Draft 3G CDMA Fast Handover November 2007 MN PAR NAR HA AAA | | | | | +--------------------------------+ | | (a) | Lower-layer HO initiation | | | +--------------------------------+ | | | | HI | | | (b) | |-------------->| | | | | HAck | | | (c) | |<--------------| | | | | (HAck) | | | (d) | |- - - - - - - >| | | | |forward packets| | | (e) | |==============>|(buffering) | | | | | | | (f) handover | | | | | | | | | +--------------------------------------------------------------+ (g) | Attachment procedure | +--------------------------------------------------------------+ | deliver packets | | | (h) |<=============================| | | | | BU/BA | | | (i) |<------------------------------------------->| | | | | | | Figure 5: Network-controlled fast handover operation This above call flows is based on the predictive fast handover, but it can be applied to the reactive fast handover as well. Even after the MN has moved to the new network, the PAR continues to send the packets to the MN by forwarding them to the NAR. The NAR is responsible for delivering packets whose destination address is the PCoA to the MN in the new network. As far as the PAR is involved, however, the path from the HA to the MN is not optimal. In order to optimize the path towards the MN, the binding cache in the HA needs to be updated. At an appropriate point after the NCoA has been assigned to the MN, the MN sends the BU to the HA to update the binding cache in the HA to the NCoA. Yokota & Dommety Expires May 17, 2008 [Page 17] Internet-Draft 3G CDMA Fast Handover November 2007 6. Message Format 6.1. Handover Assist Information Option If the lower layer information of the new point of attachment is not represented as the Link-Layer Address, the following option SHOULD be used. The primary purpose of this option is to convey the handover assist information described in Section 4. 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 | Length | Option-Code | AS-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS-Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type T.B.D. Length The size of this option in 8 octets including the Type, Length, Option-Code and AS-Length fields. Option-Code Indicates the particular type of handover assist information. This value is administrated by the vendor or organization that uses this option (typically 3GPP2). AS-Length The size of the AS-Value field in octets. AS-Value Zero or more octets of handover assist information data. Handover assist information (e.g. pilot set or cell information) described in Section 4SHOULD use this option. This option MUST be understood by the sender (typically the MN) and the receiver (typically the AR). If nodes in between do not support this option, they SHOULD treat this option as opaque and MUST not drop it. Depending on the size of the AS-Value field, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets. The AS-Length is used to disambiguate the size of the AS- Value. Yokota & Dommety Expires May 17, 2008 [Page 18] Internet-Draft 3G CDMA Fast Handover November 2007 6.2. New flag extension to FBU message The MN MUST send the FBU to the PAR with the following new (B) flag set in the previous network to indicate the PAR to buffer packets destined for the PCoA. The rest of the Binding Update message format remains the same as defined in [2] and with the additional (M), (R) and (P) flags as specified in [12], [13] and [14], respectively. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B flag: If the 'B' flag is set, the PAR SHOULD start buffering the packets destined for the MN as specified in Section 5.2. Yokota & Dommety Expires May 17, 2008 [Page 19] Internet-Draft 3G CDMA Fast Handover November 2007 7. Security Considerations The security considerations for Mobile IPv6 fast handover are described in [3]. When a 3G network is considered, the PAR and the NAR have a trusting relationship and the links between them and those between the ARs and the MN are usually secured. Yokota & Dommety Expires May 17, 2008 [Page 20] Internet-Draft 3G CDMA Fast Handover November 2007 8. IANA Considerations This document defines one new Neighbor Discovery [15] option called the handover assist information option, which is described in Section 6.1. Yokota & Dommety Expires May 17, 2008 [Page 21] Internet-Draft 3G CDMA Fast Handover November 2007 9. Conclusions The handover performance of the standard Mobile IPv6 is not sufficient for real-time communications that are not resilient to packet loss. The Mobile IPv6 fast handover methods are effective for these applications. This document described how these methods can be applied to 3G CDMA networks by specifying the three approaches: the predictive, reactive and network-controlled fast handovers. Yokota & Dommety Expires May 17, 2008 [Page 22] Internet-Draft 3G CDMA Fast Handover November 2007 10. Acknowledgements The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved Kafle and Vijay Devarapalli for providing feedback and support for this work. Yokota & Dommety Expires May 17, 2008 [Page 23] Internet-Draft 3G CDMA Fast Handover November 2007 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068, July 2005. 11.2. Informative References [4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005. [5] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability Specification", A.S0001-A v.2.0, June 2001. [6] 3GPP2 TSG-A, "Interoperability Specification for High Rate Packet 1 2 Data (HRPD) Access Network Interfaces - Rev A.", A.S0007-A v.2.0, May 2003. [7] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP services", X.S0011-002-D v.1.0, February 2006. [8] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997. [9] 3GPP2 TSG-X, "Fast Handoff for HRPD", X.P0043 v.0.3, 2006. [10] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt, October 2007. [11] Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury, "Mobile IPv6 Bootstrapping for the Authentication Option Protocol", draft-devarapalli-mip6-authprotocol-bootstrap-03.txt, September 2007. [12] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [13] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Yokota & Dommety Expires May 17, 2008 [Page 24] Internet-Draft 3G CDMA Fast Handover November 2007 [14] Gundavell, S., Ed., Keung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07.txt, September 2007. [15] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Yokota & Dommety Expires May 17, 2008 [Page 25] Internet-Draft 3G CDMA Fast Handover November 2007 Authors' Addresses Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP Phone: +81 49 278 7894 Fax: +81 49 278 7510 Email: yokota@kddilabs.jp Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US Phone: +1 408 525 1404 Email: gdommety@cisco.com Yokota & Dommety Expires May 17, 2008 [Page 26] Internet-Draft 3G CDMA Fast Handover November 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). Yokota & Dommety Expires May 17, 2008 [Page 27]