From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5271.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc5271.txt (limited to 'doc/rfc/rfc5271.txt') diff --git a/doc/rfc/rfc5271.txt b/doc/rfc/rfc5271.txt new file mode 100644 index 0000000..1a8fe3d --- /dev/null +++ b/doc/rfc/rfc5271.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group H. Yokota +Request for Comments: 5271 KDDI Lab +Category: Informational G. Dommety + Cisco Systems, Inc. + June 2008 + + + Mobile IPv6 Fast Handovers for 3G CDMA Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +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 (MN) 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 a 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. + + + + + + + + + + + + + + + + + + + + + + +Yokota & Dommety Informational [Page 1] + +RFC 5271 3G CDMA Fast Handover June 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Notation ...........................................3 + 3. Terminology .....................................................3 + 4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks ...4 + 5. Fast Handover Procedures ........................................6 + 5.1. Predictive Fast Handover ...................................7 + 5.2. Reactive Fast Handover ....................................12 + 5.3. Considerations on the Link Indications ....................15 + 6. Message Format .................................................15 + 6.1. Handover Assist Information Option ........................15 + 6.2. Mobile Node Identifier Option .............................16 + 6.3. New Flag Extension to FBU Message .........................17 + 6.4. New Flag Extension to PrRtAdv Message .....................17 + 7. Security Considerations ........................................18 + 8. IANA Considerations ............................................18 + 9. Acknowledgements ...............................................19 + 10. References ....................................................19 + 10.1. Normative References .....................................19 + 10.2. Informative References ...................................19 + +1. 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 [12]. 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. RFC 4260 [7] further describes how this Mobile IPv6 + Fast Handover could be implemented on link layers conforming to the + IEEE 802.11 suite of specifications. However, 3G CDMA and IEEE + 802.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 New Access + Router (NAR) discovery based on [Access Point Identifier, Access + Router-info (AP-ID, AR-info)] tuples specified in RFC 4260 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. + + + + + + + +Yokota & Dommety Informational [Page 2] + +RFC 5271 3G CDMA Fast Handover June 2008 + + +2. 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]. + +3. Terminology + + This document refers to [3] for Mobile IPv6 fast handover + terminology. Terms that first appear in this document are defined + below: + + Access Network Identifier (ANID): An identifier that is used by the + Packet Data Serving Node (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 + administered by the operator. The lengths of the SID, NID, and + PZID are 2 octets, 2 octets, and 1 octet, respectively. Thus, + that of the ANID occupies 5 octets [11]. + + 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. + + 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 Home Network Prefix (HNP) and one of the bootstrap + parameters for the MN. + + International Mobile Subscriber Identity (IMSI): The IMSI is a + string of decimal digits, up to a maximum of 15 digits, that + identifies a unique mobile terminal or mobile subscriber + internationally. The IMSI consists of three fields: the Mobile + Country Code (MCC), the Mobile Network Code (MNC), and the Mobile + Subscriber Identification Number (MSIN). An example of the IMSI + is "440701234567890", where "440" is the MCC, "70" is the MNC, and + "1234567890" is the MSIN. The IMSI conforms to the ITU-T E.212 + numbering standard [6]. In this specification, IMSI is an ASCII + string that consists of not more than 15 decimal digits (ASCII + values between 30 and 39 hexadecimal), one character per IMSI + digit. The above example would therefore be encoded as "34 34 30 + 37 30 31 32 33 34 35 36 37 38 39 30" in hexadecimal notation. + + + + +Yokota & Dommety Informational [Page 3] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + Mobile Identity (MN ID): An identifier of the Mobile Node that is + used by the access network. The value (e.g., IMSI) is unique + within the operator's network. + + 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. + + Sector Address Identifier (SectorID): A typical cell divides its + coverage area into several sectors. In 3G CDMA systems, each + sector uses a different PN (Pseudo Noise) code offset and is + associated with SectorID. The SectorID is 128 bits long and can + be represented in the IPv6 address format [8]. + +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 Authentication, + Authorization, and Accounting (AAA) server 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). + + + + + + + + + + + + + + + + + + + + +Yokota & Dommety Informational [Page 4] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + 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 + 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 + exceeds that of the current pilot, the MN sends the estimates to the + access network. As long as the sector to which the MN is going to + move belongs to the same access network, the mobility within that + access network is handled by the access-specific interfaces [10] and + the link-layer connection between the MN and AR can be maintained + without a re-establishment. The MN can continually search for pilots + without disrupting the data communication and a timely handover is + assisted by the network. If, however, 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 + + + +Yokota & Dommety Informational [Page 5] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + in the new access network, which is followed by establishing a new + connection with the new AR. This could cause a noticeable + communication disruption and lead to a serious degradation of the + user experience. In order to minimize the service degradation, + during the handover between ARs, an IP-level fast handover approach + as defined in RFC 5268 needs to be involved. 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. The MN can continually search for pilots without + disrupting the data communication and a timely handover is assisted + by the network. + + 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 [9][10]. 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 (AP) defined in [3] may not be available. If this is + the case, the Handover Assist Information option defined in this + document SHOULD be used instead. + +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 + Acknowledgment) on the PAR's (Previous Access Router's) link and the + other is called "reactive mode", where the MN sends the FBU from the + NAR's (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. + + Section 2 of RFC 4907 [20] suggests architectural principles on the + link indication and the effectiveness of the optimization. The link + indication of this document relies on 3G CDMA networks and the + effectiveness of the optimization is attributed to RFC 5268. The + above principles are thus considered by the related specifications + referenced in this document. + + + + + +Yokota & Dommety Informational [Page 6] + +RFC 5271 3G CDMA Fast Handover June 2008 + + +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 is attached to this message. + + (b) Based on the received handover assist information, the NAR is + determined and a proxy router advertisement (PrRtAdv) containing + the prefix of the NAR is sent back to the MN. The MN also + checks that the R flag is not set in the PrRtAdv message, which + indicates the network supports the predictive fast handover mode + (defined later). + + (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). + + (i) The NAR starts delivering packets to the MN. + + (j) The MN sends the Binding Update (BU) to the HA to update the + Binding Cache Entry (BCE) with the NCoA, and the HA sends back + the Binding Acknowledgment (BA) to the MN. + + + + + + + + + + +Yokota & Dommety Informational [Page 7] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + 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), Router Solicitation for Proxy Advertisement (RtSolPr) is + supposed to include the New Access Point and the MN Link-Layer + Address (LLA) options (Option Code=1 and 2, respectively) according + to [3]. The New AP-LLA option MAY be replaced by the handover assist + information option in 3G CDMA networks. As for the MN-LLA option, if + the LLA for the MN is not available, 3G specific IDs such as IMSI[11] + MAY be used. If this is the case, the MN ID option defined in + Section 6.2, which can support other types of IDs and a length that + is not necessarily multiples of 8 octets, SHOULD be used instead of + the MN-LLA option. + + + +Yokota & Dommety Informational [Page 8] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + 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 [12]. After the traffic channel is assigned, the MN + first establishes a link-layer connection between itself and the + access router. As a link-layer protocol, PPP is considered in this + figure, and a PPP handshake is depicted as an example. After a + link-layer connection is established, 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 [12], 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 [13]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yokota & Dommety Informational [Page 9] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + 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., Challenge Handshake Authentication + Protocol (CHAP) or Password Authentication Protocol (PAP)) is + conducted. + + + + + + + +Yokota & Dommety Informational [Page 10] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + (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. + + (g-4) Unique interface IDs are negotiated in IPv6 Control Protocol + (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 when the MN switches to the new radio + channel but also during the time period when 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 + [12], 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. + + + + + + + + +Yokota & Dommety Informational [Page 11] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + The UNA is supposed to include the MN-LLA [3], but the point-to-point + link-layer connection may be able to uniquely identify the MN. The + most required information by the UNA is the NCoA to check if there is + a corresponding buffer. Therefore, in (h), the function of the UNA + can be realized in several ways: + + 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 + delivering, if any (substitution of UNA). + + o The MN sends the UNA as defined in [3]. Instead of the MN-LLA in + the LLA option, the MN ID MAY be included in the MN ID option + (standard implementation of UNA). + + The primary benefit of the predictive fast handover 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. + +5.2. Reactive Fast Handover + + When the network does not support the predictive fast handover mode, + the reactive fast handover is applied. In this document, a new flag + is defined in PrRtAdv to inform the MN about the capability of the + network (see Section 6.4). 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: + + (a) A router solicitation for proxy router advertisement MAY be sent + to the PAR. + + + + +Yokota & Dommety Informational [Page 12] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + (b) The proxy router advertisement MAY be sent to the MN. If the + information on the NAR is not available by the PAR, "0::0" MUST + be used for the options related to the NAR (e.g., IP address of + the NAR). + + (c) The MN sends the FBU or the access network indicates the close + of the connection with the MN by the lower-layer signaling. If + the MN cannot formulate the NCoA, "0::0", MUST be used for the + NCoA in the FBU. If the B flag is set in the FBU, the PAR + SHOULD 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 UNA to the NAR. + + (g) The MN sends the Fast Binding Update (FBU) to the PAR via the + NAR. + + (h) The NAR forwards the FBU from the MN to the PAR. + + (i) The PAR sends the Handover Initiate (HI) to the NAR with the + Code set to 1. + + (j) The NAR sends the Handover Acknowledge (HAck) back to the PAR. + + (k) The PAR sends the FBAck to the NAR. + + (l) If the PAR is buffering packets destined for the PCoA, it starts + forwarding them as well as newly arriving ones to the NAR. + + (m) The NAR delivers the packets to the MN. + + (n) 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 Informational [Page 13] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + MN PAR NAR HA AAA + | RtSolPr | | | | + (a) |------------->| | | | + | PrRtAdv | | | | + (b) |<-------------| | | | + | FBU | | | | + (c) |- - - - - - ->|(buffering) | | | + | | | | | + (d) handover | | | | + | | | | | + +--------------------------------------------------------------+ + (e) | Attachment procedure | + +--------------------------------------------------------------+ + | UNA | | | + (f) |----------------------------->| | | + | FBU | | | + (g) |----------------------------->| | | + | | FBU | | | + (h) | |<--------------| | | + | | HI | | | + (i) | |-------------->| | | + | | HAck | | | + (j) | |<--------------| | | + | | FBack | | | + (k) | |-------------->| | | + | |forward packets| | | + (l) | |==============>| | | + | deliver packets | | | + (m) |<=============================| | | + | | BU/BA | | | + (n) |<------------------------------------------->| | + | | | | | + + 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 + MAY also start buffering packets for the MN based on lower layer + signal during handover. Since the packets are buffered at the PAR in + this scenario, the UNA, which is received and processed by the NAR, + can not be used to trigger to forward the buffered packets at the + PAR. In Figure 4, the HAck from the NAR is used as the trigger for + the forwarding of any buffered packets. + + The handover indication from the lower layer of 3G CDMA system is + reasonably reliable by the periodical reports from the MN; however, + there are several situations where the target link is not available + + + +Yokota & Dommety Informational [Page 14] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + after the handover (step (d)) and the MN comes back to the PAR, or + the MN is not able to move to the target link for some reason after + the connection was closed. If this is the case, the attachment + procedure is performed on the previous link. The packets buffered at + the PAR SHOULD be delivered to the MN after the connection is + re-established. + +5.3. Considerations on the Link Indications + + This section discusses if the link indications assumed in this + document meet the principles defined in Section 2 of RFC 4907[20], + which suggests 11 architectural principles on the link indication and + the effectiveness of the optimization. This document relies on the + 3G CDMA network regarding the link indication, which is precisely + specified by 3GPP2. Therefore, principles (1) to (5), (7), (8), and + (11), that is, "Model Validation", "Clear Definition", "Robustness", + "Recovery from Invalid Indications", "Congestion Control", + "Interoperability", "Race Condition", and "Transport of Link + Indications" are considered by those specs. Principle (6) + "Effectiveness" mentions the effectiveness of the optimization. This + document bases its effectiveness on RFC 5268. Therefore, this + principle is dealt by that RFC. Principle (9) "Metric Consistency" + mentions inconsistencies between link and routing layer metrics. The + spec of this document does not change the routing metrics and + multi-homing is not considered. Finally, principle (10) "Layer + Compression", mentions an overhead reduction scheme and + interoperability. This document does not deal with overhead + reduction and therefore this principle does not apply. + +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 | HAI-Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HAI-Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Yokota & Dommety Informational [Page 15] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + Type 29 + + Length The size of this option in 8 octets including the + Type, Length, Option-Code, and HAI-Length (Handover + Assist Information-Length) fields. + + Option-Code + 1: Access Network Identifier (AN ID) + 2: Sector ID + + HAI-Length The size of the HAI-Value field in octets. + + HAI-Value The value specified by the Option-Code. + + If those that received this message do not support this option, they + SHOULD treat this option as opaque and MUST NOT drop it. + + Option-Code indicates the particular type of handover assist + information. Currently, two types of information are defined to + assist the discovery of the NAR (see Section 3). + + Depending on the size of the HAI-Value field, appropriate padding + MUST be used to ensure that the entire option size is a multiple of 8 + octets. The HAI-Length is used to disambiguate the size of the + HAI-Value. + + The handover assist information MAY replace the New Access Point + Link-Layer Address in 3G CDMA networks. + +6.2. Mobile Node Identifier Option + + This option is used to transfer the Identifier of the MN, which is + not its link-layer address. + + 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 | MN ID-Length | + +---------------------------------------------------------------+ + | MN ID ... + +----------------------------- + + Type 30 + + Length The size of this option is in 8 octets including the + Type, Length, and Option-Code. + + + + + +Yokota & Dommety Informational [Page 16] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + Option-Code + 1: NAI [4] + 2: IMSI (See Section 3) + + MN ID-Length The length of the MN ID in octets. + + MN ID MN ID value + + The MN ID MAY replace the MN Link-Layer Address in 3G CDMA networks. + +6.3. 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 [14], [15], and [16], 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. + +6.4. New Flag Extension to PrRtAdv Message + + A new flag 'R' is defined in the PrRtAdv to inform the MN about the + fast handover mode that the network supports. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Subtype |R| Reserved | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+-+-+-+-+-+-+-+- + + + +Yokota & Dommety Informational [Page 17] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + R flag: If the 'R' flag is set, the network supports only the + reactive handover mode. Otherwise, the network + supports both the predictive and reactive fast + handover mode. + +7. Security Considerations + + The security considerations for Mobile IPv6 fast handover are + described in [3]. When a 3G CDMA network is considered, it can be + assumed that the PAR and the NAR have a trust relationship and the + links between them and those between the ARs and the MN are secured. + The MN is authenticated every time it attaches to the new link; + therefore, the AR can securely identify the MN. Depending on the + operator's policy, however, SEcure Neighbor Discovery (SEND) [18] and + the shared handover key defined in [17] can also be applied. + +8. IANA Considerations + + This document defines two new IPv6 Neighbor Discovery options that + have been assigned from the same space as the IPv6 Neighbor Discovery + Options defined in [19]. + + 29: Handover Assist Information Option (Section 6.1) + + 30: Mobile Node Identifier Option (Section 6.2) + + This document creates two new registries for the Option-Code field in + the Handover Assist Information Option and that in the Mobile Node + Identifier Option. The values for the Option-Code must be within the + range 0-255. New values for both registries can be allocated by + Standards Action or IESG approval [5]. + + The Option-Code values that have been assigned by IANA are as + follows: + + Option-Code for Handover Assist Information Option + Value Description Reference + ----- ---------------------------- ---------- + 0 Reserved + 1 ANID Section 6.1 + 2 Sector ID Section 6.1 + + + + + + + + + + +Yokota & Dommety Informational [Page 18] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + Option-Code for Mobile Node Identifier Option + Value Description Reference + ----- ---------------------------- ---------- + 0 Reserved + 1 NAI Section 6.2 + 2 IMSI Section 6.2 + +9. Acknowledgements + + The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved + Kafle, and Vijay Devarapalli for providing feedback and support for + this work. The authors would also thank Sebastian Thalanany for + 3GPP2 expert review. + +10. References + +10.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., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June + 2008. + + [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network + Access Identifier", RFC 4282, December 2005. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. + + [6] ITU-T Recommendation, "The international identification plan + for mobile terminals and mobile users", ITU-T E.212, May 2004. + +10.2. Informative References + + [7] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", + RFC 4260, November 2005. + + [8] 3GPP2 TSG-C, "cdma2000 High Rate Packet Data Air Interface + Specification", C.S0024-A v.2.0, July 2005. + + [9] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability + Specification", A.S0001-A v.2.0, June 2001. + + + + + +Yokota & Dommety Informational [Page 19] + +RFC 5271 3G CDMA Fast Handover June 2008 + + + [10] 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. + + [11] 3GPP2 TSG-A, "Interoperability Specification (IOS) for High + Rate Packet Data (HRPD) Access Network Interfaces", 3GPP2 + A.S0008-0 v3.0, May 2003. + + [12] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP + and Mobile IP services", X.S0011-002-D v.1.0, February 2006. + + [13] Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury, + "Mobile IPv6 Bootstrapping for the Authentication Option + Protocol", Work in Progress, September 2007. + + [14] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, + "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC + 4140, August 2005. + + [15] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, + "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, + January 2005. + + [16] Gundavell, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., + and B. Patil, "Proxy Mobile IPv6", Work in Progress, February + 2008. + + [17] Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6 + Handover Key using SEND", RFC 5269, June 2008. + + [18] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [19] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [20] Aboba, B., Ed., "Architectural Implications of Link + Indications", RFC 4907, June 2007. + + + + + + + + + + + + +Yokota & Dommety Informational [Page 20] + +RFC 5271 3G CDMA Fast Handover June 2008 + + +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 Informational [Page 21] + +RFC 5271 3G CDMA Fast Handover June 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + + + + + + + + + + + +Yokota & Dommety Informational [Page 22] + -- cgit v1.2.3