Network Working Group H. Yokota Internet-Draft KDDI R&D Laboratories, Inc. Expires: January 11, 2006 G. Dommety Cisco Systems, Inc. July 10, 2005 Mobile IPv6 Fast Handovers for 3G CDMA Networks draft-yokota-mipshop-3gfh-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 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 provider networks. However, this handover procedure requires not only movement detection, but also the acqusition of a new care-of address and the sending of a binding update message to the home agent before the traffic begins to direct to the new location. During this Yokota & Dommety Expires January 11, 2006 [Page 1] Internet-Draft 3G CDMA Fast Handover July 2005 period, packets destined for the mobile node will 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 and selective bi-casting methods in the 3G context 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 networks . . . 6 5. Fast handover procedures . . . . . . . . . . . . . . . . . . . 10 5.1 Predictive fast handover . . . . . . . . . . . . . . . . . 10 5.2 Reactive fast handover . . . . . . . . . . . . . . . . . . 12 5.3 Impact on 3G network entities . . . . . . . . . . . . . . 14 6. Selective bi-casting . . . . . . . . . . . . . . . . . . . . . 15 6.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 17 6.1.1 Simultaneous bindings flag extension to (Fast) Binding update message . . . . . . . . . . . . . . . . 17 6.1.2 New mobility option for bi-casting lifetime . . . . . 17 6.1.3 New status code for simultaneous bindings . . . . . . 17 6.2 MN and AR/HA operations . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Yokota & Dommety Expires January 11, 2006 [Page 2] Internet-Draft 3G CDMA Fast Handover July 2005 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 January 11, 2006 [Page 3] Internet-Draft 3G CDMA Fast Handover July 2005 2. Introduction Mobile IPv6 allows mobile nodes (MNs) to maintain persistent IPv6 addresses while roaming around in IPv6 networks and it is adopted in 3G CDMA networks for handing off between different access provider networks [2]. During handover, however, the mobile node (MN) needs to switch the radio networks, to obtain a new Care-of Address (CoA) and to re-register with the home agent (HA), which causes 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. In this proposal, there are two modes called "predictive" fast handover and "reactive" fast handover. This document first specifies how these fast handover modes can be applied in the 3G context and shows that several Mobile IPv6 bootstrapping procedures can be omitted. If the MN has more than two network interfaces, even smoother handover can be realized by transmitting packets destined for the MN to both networks, where the mobile node resides and will move to. This document defines this mechanism as selective bi-casting and defines a protocol for it. Yokota & Dommety Expires January 11, 2006 [Page 4] Internet-Draft 3G CDMA Fast Handover July 2005 3. Terminology This document refers to [2] for Mobile IPv6 fast handover terminology. Terms that first appear in this document are defined below: Home Link Prefix (HLP): The prefix address assigned to the home link where the MN should send the binding update message. This is 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 [2]. A PDSN can be the access router in the visited access provider network. Yokota & Dommety Expires January 11, 2006 [Page 5] Internet-Draft 3G CDMA Fast Handover July 2005 4. Network reference model for Mobile IPv6 over 3G networks Figure 1 shows a simplified reference model of the Mobile IP enabled 3G networks. The home agent (HA) of the mobile node (MN) resides in the home IP network and the MN roams around the access provider networks. The home network and the access provider networks are managed by either the same or different operator(s). Prior to the Mobile IPv6 registration, the MN establishes a link-layer connection with the access router (AR), which is also called PDSN (Packet Data Serving Node) in 3G networks, of the access provider network to which the MN is attached. When the MN moves from one access provider network to another, a Mobile IPv6 handover is performed. The figure shows the situation, where the MN moves from the PAR (previous access router) to the NAR (new access router) and in the case of 3G networks, the PAR and the NAR are equivalent to the oPSDN (old PDSN) and the nPDSN (new PDSN). Home IP Network +........................+ . +--------+ +--------+ . . | HA |--| AAA | . . +--------+ +--------+ . +../......\..............+ / \ Access Provider Network Access Provider Network +.............+ +.............+ . +---------+ . . +---------+ . . | PAR | . . | NAR | . . | (oPDSN) | . . | (nPDSN) | . . +---------+ . . +---------+ . . | .| . . .| | . . | .|L2link L2link.| | . . | .| . . .| | . . +--+ +.--+ . . +.--+ +--+ . . |BS| |.BS| . . |.BS| |BS| . . +--+ +.--+ . . +.--+ +--+ . . .| . . .| . . +----+ . . +----+ . . | MN |---------> | MN | . . +----+ . . +----+ . +.............+ +.............+ Figure 1: Reference Model for Mobile IP Yokota & Dommety Expires January 11, 2006 [Page 6] Internet-Draft 3G CDMA Fast Handover July 2005 In 3G networks, pilot signals from BSs allow the MN to obtain a rapid and accurate C/I (carrier to interference) estimate. The MN measures the channel C/I from all the measurable pilot channels and requests a connection to the BS with the strongest pilot channel. If this physical layer information such as the channel C/I can be used as a trigger for the handover of access routers when the MN is about to move to a new access provider network, faster and smoother handover of Mobile IPv6 can be realized. Figure 2 shows the protocol sequence from the attachment to the network to th Mobile IPv6 registration. The MN first establishes a link-layer connection between itself and the access router. As the link-layer protocol, PPP or RLP (Radio Link Protocol) 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). These addresses are required prior to sending a Binding Update and obtaining these values is called bootstrapping. One such method is proposed in [5], where the bootstrapping information is obtained during the link-layer establishment phase. Yokota & Dommety Expires January 11, 2006 [Page 7] Internet-Draft 3G CDMA Fast Handover July 2005 MN AR HA AAA +-- | (PDSN) | | | | LCP | | | |(1) |<-------------------->| | | | | CHAP | Access-Request/Accept | |(2) |<-------------------->|<---------|----------------->| | | +------------+ | | | |(3) | | HA,HLP,HoA |<--+ | | | | +------------+ | | | | IPv6CP(IF-ID) | | | |(4) |<--------|----------->| | | (a)< +---------+ | | | | |(5) | LL-addr |<--+ | | | | +---------+ | | | | | RA(prefix) | | | |(6) |<-----|---------------| | | | +-----+ | | | | |(7) | CoA |<--+ | | | | +-----+ | | | | | DHCPv6(HA,HLP,HoA) | | | |(8) |<-----------|-------->| | | | +------------+ | | | | |(9) | HA,HLP,HoA |<--+ | | | | +------------+ | | | *-- | | BU | | (b) |------------------------------------>|Authentication| | | | query/reply | (c) | | |<------------>| | | BA | | (d) |<------------------------------------| | | | | | Figure 2: MIPv6 operation in 3G network The procedure for the initial registration is as follows: (a) The link-layer connection establishment and the bootstrapping phase (a-1) The LCP configure-request/response messages are exchanged. (a-2) CHAP authentication for instance is conducted. (a-3) The bootstrapping parameters are conveyed from the HA and stored in the AR (PDSN). (a-4) Unique interface IDs are negotiated in IPv6CP. Yokota & Dommety Expires January 11, 2006 [Page 8] Internet-Draft 3G CDMA Fast Handover July 2005 (a-5) The MN configures its link-local address based on the obtained interface ID. (a-6) A router advertisement containing the prefix is received by the MN. (a-7) The MN configures its CoA based on the obtained prefix. (a-8) DHCPv6 is used to obtain the bootstrap parameters such as the home agent address, the home link prefix and the home address. (a-9) The MN configures its HoA based on the obtained parameters. (b) A binding update is sent to the HA. (c) The HA asks the AAA to authenticate the MN for the initial registration. (d) The binding acknowledgment is sent back to the MN. As is shown in Figure 2, it takes a considerable amount of time to establish a link-layer connection and all of the above sequences run every time the MN attaches to a new access network. It is therefore beneficial if packets on the fly 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. Yokota & Dommety Expires January 11, 2006 [Page 9] Internet-Draft 3G CDMA Fast Handover July 2005 5. Fast handover procedures There are two modes defined in [3] according to the timing of sending FBU (Fast Binding Update); one is called "predictive mode," where the MN sends FBU and receives FBAck (Fast Binding Ack) on PAR (Previous Access Router)'s link and the other is called "reactive mode," where the MN sends FBU from NAR (New Access Router)'s link. In the predictive mode, the time and place the MN hands off is indicated sufficiently before the time it actually happens. In cellular systems, handovers are controlled by the network and the predictive mode is well applied although the reactive mode is possible as well. On the other hand, in wireless LAN networks, for example, the MN controls its handover and it does not know where it moves to until it starts to scan the channels. In this case, only the reactive mode is applied. 5.1 Predictive fast handover Figure 3 shows the predictive mode of MIPv6 fast handover operation. The MN knows the NAR before movement and has the PAR transfer the packets destined for the MN to the NAR. Details of the sequence are as follows: (a) A router solicitation for proxy router advertisement is sent to the PAR. (b) 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) storing 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 to the NAR and the NAR buffers them. (f) The MN hands over to the NAR. (g) The MN establishes the link layer connection with/without authentication. (h) The MN sends the fast neighbor advertisement. (i) The NAR starts delivering packets to the MN. Yokota & Dommety Expires January 11, 2006 [Page 10] Internet-Draft 3G CDMA Fast Handover July 2005 (j) The MN sends the BU to the HA. (k) The HA sends the BA back to the MS. (l) The HA starts delivering packets to the MS via the NAR. MN PAR NAR HA AAA | RtSolPr | | | | (a) |------------->| | | | | PrRtAdv | | | | (b) |<-------------| | | | | FBU | Hl | | | (c) |------------->|-------------->| | | | FBack | HAck | | | (d) |<-------------|<--------------| | | | |forward packets| | | (e) | |==============>| | | | | +-----------+ | | | | | buffering | | | | | +-----------+ | | (f) handover | | | | | | link layer connection | | (g) |/----------------------------\|/...........................\| |\----------------------------/|\.........................../| | FNA | | | (h) |----------------------------->| | | | deliver packets | | | (i) |<=============================| | | | | BU | | | (j) |-------------------------------------------->| | | | BA | | | (k) |<--------------------------------------------| | | deliver packets | | | (l) |<=============================|<=============| | Figure 3: MIPv6 Fast handover operation (predictive mode) It is assumed that the NAR address can be resolved before handover by the BS-ID, which is obtained from the air link information. The tunnel between the PAR and the NAR will be released after a preconfigured time. 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 the reactive mode. Regarding the bootstrapping, the following benefits can be obtained, too: Yokota & Dommety Expires January 11, 2006 [Page 11] Internet-Draft 3G CDMA Fast Handover July 2005 o Since the HA, HL and HoA are not changed during the fast handover, bootstrapping information is not required. o Since the NCoA can be obtained or configured via the fast handover procedures, a router advertisement is not required. Therefore, as shown in Figure 4, bootstrapping procedures (a-3) and (a-6) to (a-9) can be omitted from the standard MIPv6 operation in Figure 2. Also, if the security policy permits, the NAR can know the MN by the NAI in the PPP link setup and the authentication in (2) may be omitted. Note that another authentication is conducted in the MIPv6 registration phase and presumably the same AAA is referred to. MN oPDSN nPDSN HA AAA +-- | (PAR) (NAR) | | | | LCP | | | | | (1) |<--------------->| | | | | | CHAP | Access-Request/Accept | | (2) |<--------------->|<----------|--|------------------->| |+................................+ | | | | |. | +-----------+ . | | | | |.(3)* | | HA,HL,HoA |<-------+ | | |. | +-----------+ . | | | |+................................+ | | | | | IPv6CP(IF-ID) | | | | | (4) |<----------|---->| | | | (a)< +---------+ | | | | | | (5) | LL-addr |<--+ | | | | | +---------+ | | | | |+................................+ | | | |. | RA(prefix) | . | | | |.(6)* |<------|---------| . | | | |. +-----+ | | . | | | |.(7)*| CoA |<--+ | . | | | |. +-----+ | . | | | |. |DHCPv6(HA,HL,HoA)| . | | | |.(8)* |<------|-------->| . | | | |. +-----+ | | . | | | |.(9)*| HoA |<--+ | . | | | |. +-----+ | . | | | |+................................+ | | | *-- | | | | | Figure 4: Procedures that can be omitted in the link-layer connection 5.2 Reactive fast handover Yokota & Dommety Expires January 11, 2006 [Page 12] Internet-Draft 3G CDMA Fast Handover July 2005 In the reactive mode, packets on the fly destined for the MN are not saved by buffering at the NAR, but those within the period from the time when the MN becomes IP reachable on the new access network to the time when the MN finishes registering the new location with the HA are saved. Details of the procedure are as follows: (a) A router solicitation for proxy router advertisement is sent to the PAR. (b) A proxy router advertisement containing the prefix in the NAR is sent back to the MN. (c) The MN hands over to the NAR. (d) The MN establishes the link layer connection with/without authentication. (e) The MN sends the Fast Neighbor Advertisement (FNA) with the Fast Binding Update (FBU) to the PAN. (f) The NAR extracts the FBU and sends it to the PAR. (g) The PAR sends the FBAck to the NAR. (h) The PAR starts forwarding packets to the NAR. (i) The NAR delivers the packets to the MN. (j) The MN sends the BU to the HA. (k) The HA sends the BA back to the MN. (l) The HA starts delivering packets to the MN via the NAR. Yokota & Dommety Expires January 11, 2006 [Page 13] Internet-Draft 3G CDMA Fast Handover July 2005 MN oPDSN nPDSN HA AAA | (PAR) (NAR) | | | RtSolPr | | | | (a) |------------->| | | | | PrRtAdv | | | | (b) |<-------------| | | | | | | | | (c) handover | | | | | | link layer connection | | (d) |/----------------------------\|/...........................\| |\----------------------------/|\.........................../| | FNA [FBU] | | | (e) |----------------------------->| | | | | FBU | | | (f) | |<--------------| | | | | FBack | | | (g) | |-------------->| | | | |forward packets| | | (h) | |==============>| | | | deliver packets | | | (i) |<=============================| | | | | BU | | | (j) |-------------------------------------------->| | | | BA | | | (k) |<--------------------------------------------| | | deliver packets | | | (l) |<=============================|<=============| | Figure 5: MIPv6 Fast handover operation (reactive mode) An L2-based fast handover is possible as defined in [6] by extending the L2 link from the previous access network to the new access network via the PAR and the NAR. The timing of the fast handover trigger is the same as the reactive fast handover method in this section. In the case of the L2-based fast handover, however, once the L2 link is extended to the new location, it is maintained until the MN becomes inactive (dormant) and the link is released. As long as the L2 link is extended, the path, on which packets are conveyed, is not optimal in length. In the case of Mobile IPv6 fast handover, when the new location is registered with the HA, the packets are directed to the NAR. 5.3 Impact on 3G network entities Amongst existing 3G network entities, the MN and PDSNs are required to support fast handover procedures. The MN is also required to leverage the channel C/I to estimate the timing of handover in the predictive fast handover mode. Yokota & Dommety Expires January 11, 2006 [Page 14] Internet-Draft 3G CDMA Fast Handover July 2005 6. Selective bi-casting If the MN has the capability to receive more than one radio signal, even smoother handover can be realized. This situation happens when, for instance, the MN can receive multiple channels of the same radio system at the same time, or the MN has multiple interfaces of different radio systems such as 3G and WiFi. Especially, when the MN is running a real-time and interactive application, long-time buffering at the NAR is not always beneficial for the MN. If this is the case, it will be helpful to deliver packets destined for the MN via both the old and new points of attachment at the same time during handover. Mobile IPv4 allows simultaneous bindings [7] and bi- casting is realized by retaining the old care-of address in the binding cache and sending packets destined for the MN towards both the old and new care-of addresses. Since bi-casting consumes double the network resources, it must be limited to smooth handover. In this document, bi-casting used for a short period of time for smooth handover is called "selective bi-casting." Figure 6 shows that the simultaneous bindings and bi-casting are performed at the PAR, which copies packets destined for the MN and transmits them not only to the old point of attachment but also to the new point of attachment via the NAR. This type of scenario was originally proposed in [8]. The above operation is more effective when the predictive fast handover is applied because in the case of the reactive fast handover, all the actions are taken after the MN has moved to the new location. By that time, it is not necessary to deliver packets to the old point of attachment. Note that even if this is the case, it may be effective when the MN moves back and forth between the old and new points of attachment, the so-called "ping-pong" situation. The timing when the selective bi-casting is conducted is shown in Figure 3 (e) or Figure 5 (h) without buffering in the proactive or reactive fast handover, respectively. As another scenario, Figure 7 shows that simultaneous bindings are performed at the HA. This scenario is likely to happen when the MN are connected to multiple different networks such as 3G and WiFi at the same time. Also, if the access networks in Figure 1 are operated by different providers, it may be difficult for the ARs in these networks to cooperate with each other. In this case as well, the HA must handle simultaneous bindings and bi-casting. Yokota & Dommety Expires January 11, 2006 [Page 15] Internet-Draft 3G CDMA Fast Handover July 2005 +----------+ | HA | +----------+ / / +------/-+ +--------+ | PAR --|------|-- NAR | +------|-+ +-|------+ | | | | +----|+ +|----+ | BS || || BS | +----|+ +|----+ \ / \ | / > |< +------+ | MN |--> +------+ Figure 6: Selective bi-casting scenario 1 +----------+ | HA | +----------+ / \ / \ +------/-+ +-\------+ | PAR | | | | NAR | +------|-+ +-|------+ | | | | +----|+ +|----+ | BS || || BS | +----|+ +|----+ \ / \ | / > |< +------+ | MN |--> +------+ Figure 7: Selective bi-casting scenario 2 Yokota & Dommety Expires January 11, 2006 [Page 16] Internet-Draft 3G CDMA Fast Handover July 2005 6.1 Message Format 6.1.1 Simultaneous bindings flag extension to (Fast) Binding update message When the MN requests simultaneous bindings to the HA or the PAR, the MN sets the newly defined simultaneous bindings flag in the Binding Update (BU) [9] or FBU, respectively. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S: Simultaneous bindings. If the 'S' bit is set, the mobile node is requesting that the HA or the PAR retain its prior mobility bindings, as described below. 6.1.2 New mobility option for bi-casting lifetime The MN may request how long the HA or the PAR should retain the simultaneous bindings (and therefore bi-casting) by attaching the following mobility option in the binding update message: 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 = T.B.D | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bi-casting Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bi-casting Lifetime: The time period when the PAR or the HA retains the previous CoA (PCoA). 6.1.3 New status code for simultaneous bindings If the AR or the HA receives more (fast) binding update messages with different CoAs for the same HoA than it can support, it should send a Yokota & Dommety Expires January 11, 2006 [Page 17] Internet-Draft 3G CDMA Fast Handover July 2005 binding acknowledgement message with the following status code: Status T.B.D. too many simultaneous mobility bindings 6.2 MN and AR/HA operations In order to enable bi-casting, the MN sends a BU or FBU by setting the 'S' flag to the HA or the PAR, respectively. When the PAR/HA allows bi-casting, a successful (F)Back is returned and bi-casting is started. The MN can request a desirable bi-casting lifetime to the PAR/HA with the bi-casting lifetime option in the (F)BU. If the requested lifetime is acceptable, the PAR/HA sends an (F)Back with the accepted bi-casting lifetime, which is determined by the policies of the PAR/HA. When bi-casting is performed at the HA, the MN is likely to receive duplicate packets from multiple interfaces. In the case of audio or video applications, it may be necessary to synchronize the bi-cast flows coming from different access networks so that the user does not have to experience a communication disruption. This may take longer than just the time for a handover. If this is the case, the MN may request a longer bi-cast lifetime. After the flows are synchronized and successfully switched on the application level, the MN may explicitly de-register the PCoA by sending an (F)BU with the lifetime field being zero. On the side of the PAR/HA, the maximum value of the bi-casting lifetime must be configured and even if the MN does not request a bi-casting lifetime or does not successfully de-register the PCoA, it is deleted after the maximum value of the bi-casting lifetime elapses. Yokota & Dommety Expires January 11, 2006 [Page 18] Internet-Draft 3G CDMA Fast Handover July 2005 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. When the MN is authenticated at the phase of the link-layer connection, the AR can distinguish the authenticated users from the others. This may be not the case, however, if the access networks are operated by different providers. Yokota & Dommety Expires January 11, 2006 [Page 19] Internet-Draft 3G CDMA Fast Handover July 2005 8. 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 specifies how these methods can be applied to 3G networks. By introducing fast handover, not only are more packets saved which otherwise would be dropped, but also some of the bootstrapping parameters can be omitted at the link establishment phase, which can expedite the handover process. For interactive real-time applications, in which excessive buffering is inappropriate, selective bi-casting is also proposed. By retaining the PCoA and the NCoA in the binding cache, packets destined for the MN are transmitted to both the old and new points of attachment at the same time, whereby the applications on the MN can choose which flow to adopt considering the media continuity. 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 3GPP2 TSG-A, "Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 1 Overview", A.S0011-C v.1.0, February 2005. [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-02.txt, July 2004. [4] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Introduction", X.P0011-001-D v.0.5, November 2004. [5] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP services", X.P0011-002-D v.0.5, November 2004. [6] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet Data Mobility and Resource Management", X.P0011-003-D v.0.5, November 2004. [7] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. [8] Malki, K., "Simultaneous Bindings for Mobile IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05.txt, October 2003. [9] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. Yokota & Dommety Expires January 11, 2006 [Page 20] Internet-Draft 3G CDMA Fast Handover July 2005 Authors' Addresses Yokota Hidetoshi KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Kamifukuoka 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 January 11, 2006 [Page 21] Internet-Draft 3G CDMA Fast Handover July 2005 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 (2005). 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. Yokota & Dommety Expires January 11, 2006 [Page 22]