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/rfc5949.txt | 1795 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1795 insertions(+) create mode 100644 doc/rfc/rfc5949.txt (limited to 'doc/rfc/rfc5949.txt') diff --git a/doc/rfc/rfc5949.txt b/doc/rfc/rfc5949.txt new file mode 100644 index 0000000..a1c4f79 --- /dev/null +++ b/doc/rfc/rfc5949.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Yokota +Request for Comments: 5949 KDDI Lab +Category: Standards Track K. Chowdhury +ISSN: 2070-1721 R. Koodli + Cisco Systems + B. Patil + Nokia + F. Xia + Huawei USA + September 2010 + + + Fast Handovers for Proxy Mobile IPv6 + +Abstract + + Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility + when it performs a handover from one access router to another, and + fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the + handover performance in terms of latency and packet loss. While + MIPv6 (and FMIPv6 as well) requires the participation of the mobile + node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; + RFC 5213) provides IP mobility to nodes that either have or do not + have MIPv6 functionality without such involvement. Nevertheless, the + basic performance of PMIPv6 in terms of handover latency and packet + loss is considered no different from that of MIPv6. + + When the fast handover is considered in such an environment, several + modifications are needed to FMIPv6 to adapt to the network-based + mobility management. This document specifies the usage of fast + handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 + is used as the mobility management protocol. Necessary extensions + are specified for FMIPv6 to support the scenario when the mobile node + does not have IP mobility functionality and hence is not involved + with either MIPv6 or FMIPv6 operations. + + + + + + + + + + + + + + + + +Yokota, et al. Standards Track [Page 1] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5949. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. This document is subject to + BCP 78 and the IETF Trust's Legal Provisions Relating to IETF + Documents (http://trustee.ietf.org/license-info) in effect on the + date of publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + +Yokota, et al. Standards Track [Page 2] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Requirements Notation ...........................................4 + 3. Terminology .....................................................4 + 4. Proxy-Based FMIPv6 Protocol Overview ............................5 + 4.1. Protocol Operation .........................................7 + 4.2. Inter-AR Tunneling Operation ..............................14 + 4.3. IPv4 Support Considerations ...............................16 + 5. PMIPv6-Related Fast Handover Issues ............................16 + 5.1. Manageability Considerations ..............................16 + 5.2. Expedited Packet Transmission .............................17 + 6. Message Formats ................................................18 + 6.1. Mobility Header ...........................................18 + 6.1.1. Handover Initiate (HI) .............................18 + 6.1.2. Handover Acknowledge (HAck) ........................20 + 6.2. Mobility Options ..........................................22 + 6.2.1. Context Request Option .............................22 + 6.2.2. Local Mobility Anchor Address (LMAA) Option ........23 + 6.2.3. Mobile Node Link-Local Address Interface + Identifier (MN LLA-IID) Option .....................24 + 6.2.4. Home Network Prefix Option .........................25 + 6.2.5. Link-Local Address Option ..........................25 + 6.2.6. GRE Key Option .....................................25 + 6.2.7. IPv4 Address Option ................................25 + 6.2.8. Vendor-Specific Mobility Option ....................25 + 7. Security Considerations ........................................26 + 8. IANA Considerations ............................................26 + 9. Acknowledgments ................................................28 + 10. References ....................................................28 + 10.1. Normative References .....................................28 + 10.2. Informative References ...................................29 + Appendix A. Applicable Use Cases ..................................30 + A.1. PMIPv6 Handoff Indication .................................30 + A.2. Local Routing .............................................31 + +1. Introduction + + Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to a mobile + node that does not support Mobile IPv6 (MIPv6) [RFC3775] mobile node + functionality. A proxy agent in the network performs the mobility + management signaling on behalf of the mobile node. This model + transparently provides mobility for nodes within a PMIPv6 domain. + Nevertheless, the basic performance of PMIPv6 in terms of handover + latency and packet loss is considered no different from that of + Mobile IPv6. + + + + + +Yokota, et al. Standards Track [Page 3] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + Fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes the + protocol to reduce the handover latency for Mobile IPv6 by allowing a + mobile node to send packets as soon as it detects a new subnet link + and by delivering packets to the mobile node as soon as its + attachment is detected by the new access router. This document + extends FMIPv6 for Proxy MIPv6 operation to minimize handover delay + and packet loss as well as to transfer network-resident context for a + PMIPv6 handover. [RFC5568] is normative for this document, except + where this document specifies new or revised functions and messages. + +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 [RFC2119]. + +3. Terminology + + This document reuses terminology from [RFC5213], [RFC5568], and + [RFC3775]. The following terms and abbreviations are additionally + used in this document. + + Access Network (AN): + A network composed of link-layer access devices such as access + points or base stations providing access to a Mobile Access + Gateway (MAG) connected to it. + + Previous Access Network (P-AN): + The access network to which the Mobile Node (MN) is attached + before handover. + + New Access Network (N-AN): + The access network to which the Mobile Node (MN) is attached after + handover. + + Previous Mobile Access Gateway (PMAG): + The MAG that manages mobility-related signaling for the mobile + node before handover. In this document, the MAG and the Access + Router are co-located. + + New Mobile Access Gateway (NMAG): + The MAG that manages mobility-related signaling for the mobile + node after handover. In this document, the MAG and the Access + Router (AR) are co-located. + + + + + + + +Yokota, et al. Standards Track [Page 4] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + Local Mobility Anchor (LMA): + The topological anchor point for the mobile node's home network + prefix(es) and the entity that manages the mobile node's binding + state. This specification does not alter any capability or + functionality defined in [RFC5213]. + + Handover indication: + A generic signaling message, sent from the P-AN to the PMAG, that + indicates a mobile node's handover. While this signaling is + dependent on the access technology, it is assumed that Handover + indication can carry the information to identify the mobile node + and to assist the PMAG in resolving the NMAG (and the new access + point or base station) to which the mobile node is moving. The + details of this message are outside the scope of this document. + +4. Proxy-Based FMIPv6 Protocol Overview + + This specification describes fast handover protocols for the network- + based mobility management protocol called Proxy Mobile IPv6 (PMIPv6) + [RFC5213]. The core functional entities defined in PMIPv6 are the + Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The + LMA is the topological anchor point for the mobile node's home + network prefix(es). The MAG acts as an access router (AR) for the + mobile node and performs the mobility management procedures on its + behalf. The MAG is responsible for detecting the mobile node's + movements to and from the access link and for initiating binding + registrations to the mobile node's local mobility anchor. If the + MAGs can be informed of the detachment and/or attachment of the + mobile node in a timely manner via, e.g., lower-layer signaling, it + will become possible to optimize the handover procedure, which + involves establishing a connection on the new link and signaling + between mobility agents, compared to the baseline specification of + PMIPv6. + + In order to further improve the performance during the handover, this + document specifies a bidirectional tunnel between the Previous MAG + (PMAG) and the New MAG (NMAG) to tunnel packets meant for the mobile + node. In order to enable the NMAG to send the Proxy Binding Update + (PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck) + messages in [RFC5568] are extended for context transfer, in which + parameters such as the mobile node's Network Access Identifier (NAI), + Home Network Prefix (HNP), and IPv4 Home Address are transferred from + the PMAG. New flags, 'P' and 'F', are defined for the HI and HAck + messages to distinguish from those in [RFC5568] and to request packet + forwarding, respectively. + + + + + + +Yokota, et al. Standards Track [Page 5] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + In this document, the Previous Access Router (PAR) and New Access + Router (NAR) are interchangeable with the PMAG and NMAG, + respectively. The reference network is illustrated in Figure 1. The + access networks in the figure (i.e., P-AN and N-AN) are composed of + Access Points (APs) defined in [RFC5568], which are often referred to + as base stations in cellular networks. + + Since a mobile node is not directly involved with IP mobility + protocol operations, it follows that the mobile node is not directly + involved with fast handover procedures either. Hence, the messages + involving the mobile node in [RFC5568] are not used when PMIPv6 is in + use. More specifically, the Router Solicitation for Proxy + Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), + Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack), and + the Unsolicited Neighbor Advertisement (UNA) messages are not + applicable in the PMIPv6 context. A MAG that receives a RtSolPr or + FBU message from a mobile node SHOULD behave as if they do not + implement FMIPv6 as defined in [RFC5568] at all -- continuing to + operate according to this specification within the network -- or + alternatively, start serving that particular mobile node as specified + in [RFC5568]. + + +----------+ + | LMA | + | | + +----------+ + / \ + / \ + / \ + +........../..+ +..\..........+ + . +-------+-+ .______. +-+-------+ . + . | PMAG |()_______)| NMAG | . + . | (PAR) | . . | (NAR) | . + . +----+----+ . . +----+----+ . + . | . . | . + . ___|___ . . ___|___ . + . / \ . . / \ . + . ( P-AN ) . . ( N-AN ) . + . \_______/ . . \_______/ . + . | . . | . + . +----+ . . +----+ . + . | MN | ----------> | MN | . + . +----+ . . +----+ . + +.............+ +.............+ + + Figure 1: Reference Network for Fast Handover + + + + + +Yokota, et al. Standards Track [Page 6] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +4.1. Protocol Operation + + There are two modes of operation in FMIPv6 [RFC5568]. In the + predictive mode of fast handover, a bidirectional tunnel between the + PMAG (PAR) and NMAG (NAR) is established prior to the mobile node's + attachment to the NMAG. In the reactive mode, this tunnel + establishment takes place after the mobile node attaches to the NMAG. + In order to alleviate the packet loss during a mobile node's handover + (especially when the mobile node is detached from both links), the + downlink packets for the mobile node need to be buffered either at + the PMAG or NMAG, depending on when the packet forwarding is + performed. It is hence REQUIRED that all MAGs have the capability + and enough resources to buffer packets for the mobile nodes + accommodated by them. The buffer size to be prepared and the rate at + which buffered packets are drained are addressed in Section 5.4 of + [RFC5568]. Note that the protocol operation specified in the + document is transparent to the local mobility anchor (LMA); hence + there is no new functional requirement or change on the LMA. + + Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved + with IP mobility signaling; therefore, in order for the predictive + fast handover to work effectively, it is REQUIRED that the mobile + node is capable of reporting lower-layer information to the AN at a + short enough interval, and that the AN is capable of sending the + Handover indication to the PMAG at an appropriate timing. The + sequence of events for the predictive fast handover is illustrated in + Figure 2. + + + + + + + + + + + + + + + + + + + + + + + + +Yokota, et al. Standards Track [Page 7] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + PMAG NMAG + MN P-AN N-AN (PAR) (NAR) LMA + | | | | | | + (a) |--Report-->| | | | | + | | | | | | + | | Handover | | | + (b) | |------indication------>| | | + | | | | | | + | | | | | | + (c) | | | |----HI---->| | + | | | | | | + | | | | | | + (d) | | | |<---HAck---| | + | | | | | | + | | | | | | + | | | |HI/HAck(optional) | + (e) | | | |<- - - - ->| | + | | | #=|<===================| + (f) | | | #====DL data=>| | + | Handover | Handover | | | + (g) |<-command--|<------command---------| | | + ~~~ | | | | | + ~~~ | | | | | + | MN-AN connection | AN-MAG connection | | + (h) |<---establishment---->|<----establishment----->| | + | | | (substitute for UNA) | | + | | | | | | + (i) |<==================DL data=====================| | + | | | | | | + (j) |===================UL data====================>|=# | + | | | #=|<============# | + | | | #=====================>| + / | | | | | | \ + |(k) | | | | |--PBU-->| | + | | | | | | | | + |(l) | | | | |<--PBA--| | + | |<==================DL data=====================|<=======| | + | | | | | | | | + \ |===================UL data====================>|=======>| / + + UL Uplink + DL Downlink + PBA Proxy Binding Acknowledgment + + Figure 2: Predictive Fast Handover for PMIPv6 (Initiated by PMAG) + + + + + + +Yokota, et al. Standards Track [Page 8] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + The detailed descriptions are as follows: + + (a) The mobile node detects that a handover is imminent and reports + its identifier (MN ID) and the New Access Point Identifier (New + AP ID) [RFC5568] to which the mobile node is most likely to + move. The MN ID could be the NAI, link-layer address, or any + other suitable identifier, but the MAG SHOULD be able to map any + access-specific identifier to the NAI as the MN ID. In some + cases, the previous access network (P-AN) will determine the New + AP ID for the mobile node. This step is access technology + specific, and details are outside the scope of this document. + + (b) The previous access network, to which the mobile node is + currently attached, indicates the handover of the mobile node to + the previous mobile access gateway (PMAG), with the MN ID and + New AP ID. Detailed definition and specification of this + message are outside the scope of this document. + + (c) The previous MAG derives the new mobile access gateway (NMAG) + from the New AP ID, which is a similar process to that of + constructing an [AP ID, AR-Info] tuple in [RFC5568]. The + previous MAG then sends the Handover Initiate (HI) message to + the new MAG. The HI message MUST have the 'P' flag set and + include the MN ID, the HNP(s), and the address of the local + mobility anchor that is currently serving the mobile node. If + there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID), + that information MUST also be included. With some link layers, + the MN Link-local Address Interface Identifier (MN LLA-IID) can + also be included (see Section 6.2.3). + + (d) The new MAG sends the Handover Acknowledge (HAck) message back + to the previous MAG with the 'P' flag set. + + (e) If it is preferred that the timing of buffering or forwarding + should be later than step (c), the new MAG MAY optionally + request that the previous MAG buffer or forward packets at a + later and appropriate time, by setting the 'U' flag [RFC5568] or + the 'F' flag in the HI message, respectively. + + (f) If the 'F' flag is set in the previous step, a bidirectional + tunnel is established between the previous MAG and new MAG, and + packets destined for the mobile node are forwarded from the + previous MAG to the new MAG over this tunnel. After + decapsulation, those packets MAY be buffered at the new MAG. If + the connection between the new access network and new MAG has + already been established, those packets MAY be forwarded towards + + + + + +Yokota, et al. Standards Track [Page 9] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + the new access network, which then becomes responsible for them + (e.g., buffering or delivering, depending on the condition of + the mobile node's attachment); this is access technology + specific. + + (g) When handover is ready on the network side, the mobile node is + triggered to perform handover to the new access network. This + step is access technology specific, and details are outside the + scope of this document. + + (h) The mobile node establishes a physical-layer connection with the + new access network (e.g., radio channel assignment), which in + turn triggers the establishment of a link-layer connection + between the new access network and new MAG if not yet + established. An IP-layer connection setup may be performed at + this time (e.g., PPP IPv6 Control Protocol) or at a later time + (e.g., stateful or stateless address autoconfiguration). This + step can be a substitute for the Unsolicited Neighbor + Advertisement (UNA) in [RFC5568]. If the new MAG acquires a + valid new MN LL-ID via the new access network and a valid old MN + LL-ID from the previous MAG at step (c), these IDs SHOULD be + compared to determine whether the same interface is used before + and after handover. When the connection between the mobile node + and new MAG is PPP and the same interface is used for the + handover, the new MAG SHOULD confirm that the same interface + identifier is used for the mobile node's link-local address + (this is transferred from the previous MAG using the MN LLA-IID + option at step (c), and sent to the mobile node during the + Configure-Request/Ack exchange). + + (i) The new MAG starts to forward packets destined for the mobile + node via the new access network. + + (j) The uplink packets from the mobile node are sent to the new MAG + via the new access network, and the new MAG forwards them to the + previous MAG. The previous MAG then sends the packets to the + local mobility anchor that is currently serving the mobile node. + + (k) The new MAG sends the Proxy Binding Update (PBU) to the local + mobility anchor, whose address is provided in step (c). Steps + (k) and (l) are not part of the fast handover procedure but are + shown for reference. + + (l) The local mobility anchor sends back the Proxy Binding + Acknowledgment (PBA) to the new MAG. From this time on, the + packets to/from the mobile node go through the new MAG instead + of the previous MAG. + + + + +Yokota, et al. Standards Track [Page 10] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + According to Section 4 of [RFC5568], the previous MAG establishes a + binding between the Previous Care-of Address (PCoA) and New Care-of + Address (NCoA) to forward packets for the mobile node to the new MAG, + and the new MAG creates a proxy neighbor cache entry to receive those + packets for the NCoA before the mobile node arrives. In the case of + PMIPv6, however, the only address that is used by the mobile node is + the Mobile Node's Home Address (MN-HoA), so the PMAG forwards the + mobile node's packets to the NMAG instead of the NCoA. The NMAG then + simply decapsulates those packets and delivers them to the mobile + node. FMIPv4 [RFC4988] specifies forwarding when the mobile node + uses the home address as its on-link address rather than the care-of + address. The usage in PMIPv6 is similar to that in FMIPv4, where the + address(es) used by the mobile node is/are based on its HNP(s). + Since the NMAG can obtain the link-layer address (MN LL-ID) and + HNP(s) via the HI message (also the interface identifier of the + mobile node's link-local address (MN LLA-ID), if available), it can + create a neighbor cache entry for the link-local address and the + routes for the whole HNP(s), even before the mobile node performs + Neighbor Discovery. For the uplink packets from the mobile node + after handover in step (j), the NMAG forwards the packets to the PMAG + through the tunnel established in step (f). The PMAG then + decapsulates and sends them to the local mobility anchor. + + The timing of the context transfer and that of packet forwarding may + be different. Thus, a new flag 'F' and Option Code values for it in + the HI and HAck messages are defined to request forwarding. To + request buffering, the 'U' flag has already been defined in + [RFC5568]. If the PMAG receives the HI message with the 'F' flag + set, it starts forwarding packets for the mobile node. The HI + message with the 'U' flag set MAY be sent earlier if the timing of + buffering is different from that of forwarding. If packet forwarding + is completed, the PMAG MAY send the HI message with the 'F' flag set + and the Option Code value set to 2. Via this message, the ARs on + both ends can tear down the forwarding tunnel synchronously. + + The IP addresses in the headers of those user packets are summarized + below: + + In step (f), + + Inner source address: IP address of the correspondent node + + Inner destination address: HNP or Mobile Node's IPv4 Home Address + (IPv4-MN-HoA) + + Outer source address: IP address of the PMAG + + Outer destination address: IP address of the NMAG + + + +Yokota, et al. Standards Track [Page 11] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + In step (i), + + Source address: IP address of the correspondent node + + Destination address: HNP or IPv4-MN-HoA + + In step (j), + + - from the mobile node to the NMAG, + + Source address: HNP or IPv4-MN-HoA + + Destination address: IP address of the correspondent node + + - from the NMAG to the PMAG, + + Inner source address: HNP or IPv4-MN-HoA + + Inner destination address: IP address of the correspondent node + + Outer source address: IP address of the NMAG + + Outer destination address: IP address of the PMAG + + - from the PMAG to the LMA, + + Inner source address: HNP or IPv4-MN-HoA + + Inner destination address: IP address of the correspondent node + + Outer source address: IP address of the PMAG + + Outer destination address: IP address of the LMA + + In the case of the reactive handover for PMIPv6, since the mobile + node does not send either the FBU or UNA, it would be more natural + that the NMAG send the HI message to the PMAG after the mobile node + has moved to the new link. The NMAG then needs to obtain the + information of the PMAG beforehand. Such information could be + provided, for example, by the mobile node sending the AP-ID on the + old link and/or by the lower-layer procedures between the P-AN and + N-AN. The exact method is not specified in this document. Figure 3 + illustrates the reactive fast handover procedures for PMIPv6, where + the bidirectional tunnel establishment is initiated by the NMAG. + + + + + + + +Yokota, et al. Standards Track [Page 12] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + PMAG NMAG + MN P-AN N-AN (PAR) (NAR) LMA + | | | | | | + (a) ~~~ | | | | | + ~~~ | | | | | + | MN-AN connection | AN-MAG connection | | + (b) |<--establishment-->|<-------establishment------>| | + | | |(substitute for UNA and FBU)| | + | | | | | | + | | | | | | + (c) | | | |<-----HI-------| | + | | | | | | + | | | | | | + (d) | | | |-----HAck----->| | + | | | | | | + | | | | | | + (e) | | | #=|<=======================| + | | | #================>|=# | + |<====================DL data======================# | + | | | | | | + (f) |=====================UL data===================>|=# | + | | | #=|<================# | + | | | #=========================>| + | | | | | | + / | | | | | | \ + |(g) | | | | |--PBU-->| | + | | | | | | | | + |(h) | | | | |<--PBA--| | + | |<====================DL data====================|<=======| | + | | | | | | | | + \ |=====================UL data===================>|=======>| / + + Figure 3: Reactive Fast Handover for PMIPv6 (Initiated by NMAG) + + The detailed descriptions are as follows: + + (a) The mobile node undergoes handover from the previous access + network to the new access network. + + (b) The mobile node establishes a connection (e.g., radio channel) + with the new access network, which triggers the establishment of + the connection between the new access network and new MAG. The + MN ID is transferred to the new MAG at this step for the + subsequent procedures. The AP-ID on the old link (Old AP ID), + which will be provided by either the mobile node or the new + access network, is also transferred to the new MAG to help + identify the previous MAG on the new link. This can be regarded + as a substitute for the UNA and FBU. + + + +Yokota, et al. Standards Track [Page 13] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + (c) The new MAG sends the HI message to the previous MAG. The HI + message MUST have the 'P' flag set and include the MN ID. The + Context Request option MAY be included to request additional + context information on the mobile node to the previous MAG. + + (d) The previous MAG sends the HAck message back to the new MAG with + the 'P' flag set. The HAck message MUST include the HNP(s) + and/or IPv4-MN-HoA that corresponds to the MN ID in the HI + message and SHOULD include the MN LL-ID, only if it is valid + (non-zero), and the local mobility anchor address that is + currently serving the mobile node. The context information + requested by the new MAG MUST be included. If the requested + context is not available for some reason, the previous MAG MUST + return the HAck message with the Code value 131. If the 'F' + flag is set in the HI message at step (c) and forwarding is + nevertheless not executable for some reason, the previous MAG + MUST return the HAck message with the Code value 132. + + (e) If the 'F' flag in the HI message is set at step (c), a + bidirectional tunnel is established between the previous MAG and + new MAG, and packets destined for the mobile node are forwarded + from the previous MAG to the new MAG over this tunnel. After + decapsulation, those packets are delivered to the mobile node + via the new access network. + + (f) The uplink packets from the mobile node are sent to the new MAG + via the new access network, and the new MAG forwards them to the + previous MAG. The previous MAG then sends the packets to the + local mobility anchor that is currently serving the mobile node. + + Steps (g)-(h) are the same as steps (k)-(l) in the predictive fast + handover procedures. + + In step (c), the IP address of the PMAG needs to be resolved by the + NMAG to send the HI message to the PMAG. This information may come + from the N-AN or some database that the NMAG can access. + +4.2. Inter-AR Tunneling Operation + + When the PMAG (PAR) or NMAG (NAR), depending on the fast handover + mode, receives the HI message with the 'F' flag set, it prepares to + send/receive the mobile node's packets to/from the other MAG and + returns the HAck message with the same sequence number. Both MAGs + SHOULD support the following encapsulation modes for the user + packets, which are also defined for the tunnel between the local + mobility anchor and MAG: + + + + + +Yokota, et al. Standards Track [Page 14] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + o IPv4-or-IPv6-over-IPv6 [RFC5844] + + o IPv4-or-IPv6-over-IPv4 [RFC5844] + + o IPv4-or-IPv6-over-IPv4-UDP [RFC5844] + + o TLV-header UDP tunneling [RFC5845] + + o Generic Routing Encapsulation (GRE) tunneling with or without GRE + key(s) [RFC5845] + + The PMAG and the NMAG MUST use the same tunneling mechanism for the + data traffic tunneled between them. The encapsulation mode to be + employed SHOULD be configurable. It is RECOMMENDED that: + + 1. As the default behavior, the inter-MAG tunnel uses the same + encapsulation mechanism as that for the PMIPv6 tunnel between the + local mobility anchor and the MAGs. The PMAG and NMAG + automatically start using the same encapsulation mechanism + without a need for a special configuration on the MAGs or a + dynamic tunneling mechanism negotiation between them. + + 2. Configuration on the MAGs can override the default mechanism + specified in scenario #1 above. The PMAG and NMAG MUST be + configured with the same mechanism, and this configuration is + most likely to be uniform throughout the PMIPv6 domain. If the + packets on the PMIPv6 tunnel cannot be uniquely mapped on to the + configured inter-MAG tunnel, this scenario is not applicable, and + scenario #3 below SHOULD directly be applied. + + 3. An implicit or explicit tunnel negotiation mechanism between the + MAGs can override the default mechanism specified in scenario #1 + above. The employed tunnel negotiation mechanism is outside the + scope of this document. + + The necessary information MUST be transferred in the HI/HAck messages + to determine whether a mobile node's packets should be forwarded + immediately or at a later time. Such information includes the HNP(s) + (or IPv4-MN-HoA) and/or GRE key(s). In the case of GRE tunneling + with GRE keys being used, for each mobility session, the NMAG selects + the GRE key for the downlink packets, and the PMAG selects the GRE + key for the uplink packets. These GRE keys are exchanged between the + PMAG and the NMAG using the GRE Key option as described in [RFC5845]; + e.g., in the case of the reactive mode as shown in Figure 3, the DL + GRE key is communicated in the HI message while the UL GRE key is + sent in the HAck message. In the case of downlink packets, the PMAG + redirects the mobile node's packets from the local mobility anchor + towards the NMAG, and if the mobile node is ready to receive those + + + +Yokota, et al. Standards Track [Page 15] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + packets or the N-AN can handle them regardless of the state of the + mobile node, the NMAG SHOULD immediately send them towards the N-AN; + otherwise, it SHOULD buffer them until the mobile node is ready. In + the case of uplink packets, the NMAG SHOULD reverse-tunnel them from + the mobile node towards the PMAG, and the PMAG will then send them to + the local mobility anchor. + + When the PMAG or NMAG receives the HI message with the 'U' flag set, + it prepares to buffer the mobile node's packets and returns the HAck + message with the same sequence number. It MUST be followed by + another HI message with the 'F' flag set at an appropriate time to + forward the buffered packets. + + If the MAG that received the HI message encounters an erroneous + situation (e.g., insufficient buffer space), it SHOULD immediately + send the HAck message with the cause of the error and cancel all + tunneling operations. + +4.3. IPv4 Support Considerations + + The motivation and usage scenarios of IPv4 protocol support by PMIPv6 + are described in [RFC5844]. The scope of IPv4 support covers the + following two features: + + o IPv4 Home Address Mobility Support, and + + o IPv4 Transport Support. + + As for IPv4 Home Address Mobility Support, the mobile node acquires + the IPv4 Home Address (IPv4-MN-HoA), and in the case of handover, the + PMAG needs to transfer IPv4-MN-HoA to the NMAG, which is the inner + destination address of the packets forwarded on the downlink. For + this purpose, the IPv4 Address option described in Section 6.2.7 is + used. In order to provide IPv4 Transport Support, the NMAG needs to + know the IPv4 address of the local mobility anchor (IPv4-LMAA) to + send PMIPv6 signaling messages to the local mobility anchor in the + IPv4 transport network. For this purpose, a new option called the + LMA Address (LMAA) option is defined in Section 6.2.2 so as to convey + IPv4-LMAA from the PMAG to the NMAG. + +5. PMIPv6-Related Fast Handover Issues + +5.1. Manageability Considerations + + This specification does not require any additional IP-level + functionality on the local mobility anchor and the mobile node + running in the PMIPv6 domain. A typical network interface that the + mobile node could be assumed to have is one with the cellular + + + +Yokota, et al. Standards Track [Page 16] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + network, where the network controls the movement of the mobile node. + Different types of interfaces could be involved, such as different + generations (3G and 3.9G) or different radio access systems. This + specification supports a mobile node with the single radio mode, + where only one interface is active at any given time. The assigned + IP address is preserved whether the physical interface changes or + not, and the mobile node can identify which interface should be used + if there are multiple ones. + +5.2. Expedited Packet Transmission + + The protocol specified in this document enables the NMAG to obtain + parameters that would otherwise be available only by communicating + with the local mobility anchor. For instance, the HNP(s) and/or + IPv4-MN-HoA of a mobile node are made available to the NMAG through + context transfer. This allows the NMAG to perform some procedures + that may be beneficial. The NMAG, for example, SHOULD send a Router + Advertisement (RA) with prefix information to the mobile node as soon + as its link attachment is detected (e.g., via receipt of a Router + Solicitation message). Such an RA is recommended, for example, in + scenarios where the mobile node uses a new radio interface while + attaching to the NMAG; since the mobile node does not have + information regarding the new interface, it will not be able to + immediately send packets without first receiving an RA with HNP(s). + Especially in the reactive fast handover, the NMAG gets to know the + HNP(s) assigned to the mobile node on the previous link at step (d) + in Figure 3. In order to reduce the communication disruption time, + the NMAG SHOULD expect the mobile node to keep using the same HNP and + to send uplink packets before that step upon the mobile node's + request. However, if the HAck message from the PMAG returns a + different HNP or the subsequent PMIPv6 binding registration for the + HNP fails for some reason, then the NMAG MUST withdraw the advertised + HNP by sending another RA with zero prefix lifetime for the HNP in + question. This operation is the same as that described in + Section 6.12 of [RFC5213]. + + The protocol specified in this document is applicable regardless of + whether link-layer addresses are used between a mobile node and its + MAG. A mobile node should be able to continue sending packets on the + uplink even when it changes link. When link-layer addresses are + used, the mobile node performs Neighbor Unreachability Detection + (NUD) [RFC4861], after attaching to a new link, probing the + reachability of its default router. The new router should respond to + the NUD probe, providing its link-layer address in the solicited + Neighbor Advertisement, which is common in the PMIPv6 domain. + Implementations should allow the mobile node to continue to send + uplink packets while it is performing NUD. + + + + +Yokota, et al. Standards Track [Page 17] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +6. Message Formats + + This document defines new Mobility Header messages for the extended + HI and HAck, and new mobility options for conveying context + information. + +6.1. Mobility Header + +6.1.1. Handover Initiate (HI) + + This section defines extensions to the HI message in [RFC5568]. The + format of the Message Data field in the Mobility Header is as + follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-------------------------------+ + | Sequence # | + +-+-+-+-+-------+---------------+-------------------------------+ + |S|U|P|F|Resv'd | Code | | + +-+-+-+-+-------+---------------+ | + | | + . . + . Mobility options . + . . + | | + +---------------------------------------------------------------+ + (Note: P=1) + + IP Fields: + + Source Address + + The IP address of the PMAG or NMAG + + Destination Address + + The IP address of the peer MAG + + Message Data: + + Sequence # Same as [RFC5568]. + + 'S' flag Defined in [RFC5568], and MUST be set to zero in this + specification. + + 'U' flag Buffer flag. Same as [RFC5568]. + + + + +Yokota, et al. Standards Track [Page 18] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + 'P' flag Proxy flag. Used to distinguish the message from that + defined in [RFC5568], and MUST be set in all new message + formats defined in this document when using this protocol + extension. + + 'F' flag Forwarding flag. Used to request to forward the packets + for the mobile node. + + Reserved Same as [RFC5568]. + + Code [RFC5568] defines this field and its values, 0 and 1. In + this specification, with the 'P' flag set, this field can + be set to zero by default, or to the following values: + + 2: Indicate the completion of forwarding + + 3: All available context transferred + + Code value 3 is set when the transfer of all necessary + context information is completed with this message. This + Code value is used both in cases where the context + information is fragmented into several pieces and the + last fragment is contained in this message, and where the + whole information is transferred in one piece. + + Mobility options: + + This field contains one or more mobility options, whose encoding and + formats are defined in [RFC3775]. + + Required option + + In order to uniquely identify the target mobile node, the mobile + node identifier MUST be contained in the Mobile Node Identifier + option. + + The transferred context MUST be for one mobile node per message. In + addition, the NMAG can request necessary mobility options via the + Context Request option defined in this document. + + Context Request Option + + This option MAY be present to request context information, + typically by the NMAG to the PMAG in the NMAG-initiated fast + handover. + + + + + + +Yokota, et al. Standards Track [Page 19] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +6.1.2. Handover Acknowledge (HAck) + + This section defines extensions to the HAck message in [RFC5568]. + The format of the Message Data field in the Mobility Header is as + follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-------------------------------+ + | Sequence # | + +-+-+-+---------+---------------+-------------------------------+ + |U|P|F|Reserved | Code | | + +-+-+-+---------+---------------+ | + | | + . . + . Mobility options . + . . + | | + +---------------------------------------------------------------+ + (Note: P=1) + + IP Fields: + + Source Address + + Copied from the destination address of the Handover Initiate + message to which this message is a response. + + Destination Address + + Copied from the source address of the Handover Initiate message to + which this message is a response. + + Message Data: + + The usages of Sequence # and Reserved fields are exactly the same as + those in [RFC5568]. + + 'U' flag Same as defined in Section 6.1.1. + + 'P' flag Same as defined in Section 6.1.1. Used to distinguish + the message from that defined in [RFC5568], and MUST be + set in all new message formats defined in this document + when using this protocol extension. + + 'F' flag Same as defined in Section 6.1.1. + + + + + +Yokota, et al. Standards Track [Page 20] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + Code Code values 0 through 4 and 128 through 130 are defined + in [RFC5568]. When the 'P' flag is set, the meaning of + Code value 0 is as defined in this specification; 128 + through 130 are reused; and 5, 6, 131, and 132 are newly + defined. + + 0: Handover Accepted or Successful + + 5: Context Transfer Accepted or Successful + + 6: All available Context Transferred + + 128: Handover Not Accepted, reason unspecified + + 129: Administratively prohibited + + 130: Insufficient resources + + 131: Requested Context Not Available + + 132: Forwarding Not Available + + Mobility options: + + This field contains one or more mobility options, whose encoding and + formats are defined in [RFC3775]. The mobility option that uniquely + identifies the target mobile node MUST be copied from the + corresponding HI message, and the transferred context MUST be for one + mobile node per message. + + Required option(s) + + All the context information requested by the Context Request + option in the HI message SHOULD be present in the HAck message. + The other cases are described below. + + In the case of the PMAG-initiated fast handover, when the PMAG sends + the HI message to the NMAG with the context information and the NMAG + successfully receives it, the NMAG returns the HAck message with Code + value 5. In the case of the NMAG-initiated fast handover, when the + NMAG sends the HI message to the PMAG with or without the Context + Request option, the PMAG returns the HAck message with the requested + or default context information (if any). If all available context + information is transferred, the PMAG sets the Code value in the HAck + message to 6. If more context information is available, the PMAG + + + + + + +Yokota, et al. Standards Track [Page 21] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + sets the Code value in the HAck message to 5, and the NMAG MAY send + new HI message(s) to retrieve the rest of the available context + information. If none of the requested context information is + available, the PMAG returns the HAck message with Code value 131 + without any context information. + +6.2. Mobility Options + +6.2.1. Context Request Option + + This option is sent in the HI message to request context information + on the mobile node. If a default set of context information is + defined and always sufficient, this option is not used. This option + is more useful to retrieve additional or dynamically selected context + information. + + The Context Request option is typically used for the reactive (NMAG- + initiated) fast handover mode to retrieve the context information + from the PMAG. When this option is included in the HI message, all + the requested context information SHOULD be included in the HAck + message in the corresponding mobility option(s) (e.g., HNP, LMAA, or + MN LL-ID mobility options). + + The default context information to request is the Home Network Prefix + option. If the Mobile Node link layer is available and used, the + Mobile Node Link-layer Identifier option MUST also be requested. + + 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 + +---------------+---------------+---------------+---------------+ + | Option-Type | Option-Length | Reserved | + +---------------+---------------+-------------------------------+ + | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | + +---------------------------------------------------------------+ + | Req-type-3 | Req-length-3 | Req-option-3 | + +---------------------------------------------------------------+ + | ... | + + Option-Type 40 + + Option-Length The length in octets of this option, not including the + Option Type and Option Length fields. + + Reserved This field is unused. It MUST be initialized to zero + by the sender and MUST be ignored by the receiver. + + Req-type-n The type value for the nth requested option. + + + + +Yokota, et al. Standards Track [Page 22] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + Req-length-n The length of the nth requested option, excluding the + Req-type-n and Req-length-n fields. + + Req-option-n The optional data to uniquely identify the requested + context for the nth requested option. + + In the case where there are only Req-type-n and Req-length-n fields, + the value of Req-length-n is set to zero. If additional information + besides Req-type-n is necessary to uniquely specify the requested + context, such information follows after Req-length-n. For example, + when the requested contexts start with the HNP option (type=22), the + MN Link-layer ID option (type=25), and the Vendor-Specific option + (type=19), the required option format looks as follows: + + | ... | + +---------------+---------------+---------------+---------------+ + |Option-Type=CRO| Option-Length | Reserved | + +---------------+---------------+---------------+---------------+ + | Req-type-n=22 | Req-length-n=0| Req-type-n=25 | Req-length-n=0| + +---------------+---------------+-------------------------------+ + | Req-type-n=19 | Req-length-n=5| Vendor-ID | + +-------------------------------+---------------+---------------+ + | Vendor-ID | Sub-Type | | + +-----------------------------------------------+ | + | ... | + + Note: CRO = Context Request Option + + The first two options can uniquely identify the requested contexts + (i.e., the HNP and MN Link-layer ID) by the Req-type, so the + Req-length is set to zero; however, the subsequent Vendor-Specific + option further needs the Vendor-ID and Sub-Type to identify the + requested context, so these parameters follow, and the Req-length is + set to 5. Note that the exact values in the Vendor-ID and Sub-Type + follow [RFC5094]. + +6.2.2. Local Mobility Anchor Address (LMAA) Option + + This option is used to transfer the Local Mobility Anchor IPv6 + Address (LMAA) or its IPv4 Address (IPv4-LMAA) with which the mobile + node is currently registered. The detailed definition of the LMAA is + described in [RFC5213]. + + + + + + + + + +Yokota, et al. Standards Track [Page 23] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option-Type | Option-Length | Option-Code | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Mobility Anchor Address ... | + + Option-Type 41 + + Option-Length 18 or 6 + + Option-Code 0 Reserved + + 1 IPv6 address of the local mobility anchor (LMAA) + + 2 IPv4 address of the local mobility anchor + (IPv4-LMAA) + + Reserved This field is unused. It MUST be initialized to zero + by the sender and MUST be ignored by the receiver. + + Local Mobility Anchor Address + + If the Option-Code is 1, the LMA IPv6 address (LMAA) + is inserted. If the Option-Code is 2, the LMA IPv4 + address (IPv4-LMA) is inserted. + +6.2.3. Mobile Node Link-Local Address Interface Identifier (MN LLA-IID) + Option + + This option is used to transfer the interface identifier of the + mobile node's IPv6 Link-local Address that is used in the P-AN. In + deployments where the interface identifier is assigned by the network + or is known to the network, this option is used to transfer this + identifier from the PMAG to the NMAG. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option-Type | Option-Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Interface Identifier + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Yokota, et al. Standards Track [Page 24] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + Option-Type 42 + + Option-Length 10 + + Reserved This field is unused. It MUST be initialized to zero + by the sender and MUST be ignored by the receiver. + + Interface Identifier + + The Interface Identifier value used for the mobile + node's IPv6 Link-local address in the P-AN. + +6.2.4. Home Network Prefix Option + + This option, as defined in [RFC5213], is used to transfer the home + network prefix that is assigned to the mobile node in the P-AN. + +6.2.5. Link-Local Address Option + + This option, as defined in [RFC5213], is used to transfer the link- + local address of the PMAG. + +6.2.6. GRE Key Option + + This option is used to transfer the GRE Key for the mobile node's + data flow over the bidirectional tunnel between the PMAG and NMAG. + The message format of this option follows that of the GRE Key option + defined in [RFC5845]. The GRE Key value uniquely identifies each + flow, and the sender of this option expects to receive packets of the + flow from the peer AR with this value. + +6.2.7. IPv4 Address Option + + As described in Section 4.3, if the mobile node runs in IPv4-only + mode or dual-stack mode, it requires the IPv4 home address + (IPv4-MN-HoA). This option is used to transfer the IPv4 home address + if assigned on the previous link. The format of this option follows + that of the IPv4 Home Address Request option defined in [RFC5844]. + +6.2.8. Vendor-Specific Mobility Option + + This option is used to transfer any other information defined in this + document. The format and used values of this option follow those of + the Vendor-Specific Mobility option defined in [RFC5094]. + + + + + + + +Yokota, et al. Standards Track [Page 25] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +7. Security Considerations + + Security issues for this document follow those for PMIPv6 [RFC5213] + and FMIPv6 [RFC5568]. In PMIPv6, the MAG and local mobility anchor + are assumed to share security associations. In FMIPv6, the access + routers (i.e., the PMAG and NMAG in this document) are assumed to + share security associations. + + The Handover Initiate (HI) and Handover Acknowledge (HAck) messages + exchanged between the PMAG and NMAG MUST be protected using end-to- + end security association(s) offering integrity and data origin + authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] + for protecting the HI and HAck messages. IPsec Encapsulating + Security Payload (ESP) [RFC4303] in transport mode with mandatory + integrity protection SHOULD be used for protecting the signaling + messages. Confidentiality protection SHOULD be used if sensitive + context related to the mobile node is transferred. + + IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the + mobile node's packets at the time of forwarding if the link between + the PMAG and NMAG exposes the mobile node's packets to more threats + than if they had followed their normal routed path. + +8. IANA Considerations + + This document defines new flags and status codes in the HI and HAck + messages, as well as three new mobility options. The Type values for + these mobility options are assigned from the same numbering space as + that allocated for the other mobility options defined in [RFC3775]. + Those for the flags and status codes are assigned from the + corresponding numbering space defined in [RFC5568], and have been + created as new tables in the IANA registry (marked with asterisks). + New values for these registries can be allocated by Standards Action + or IESG approval [RFC5226]. + + Mobility Options + Value Description Reference + ----- ------------------------------------- ------------- + 40 Context Request Option Section 6.2.1 + 41 Local Mobility Anchor Address Option Section 6.2.2 + 42 Mobile Node Link-local Address + Interface Identifier Option Section 6.2.3 + + + + + + + + + +Yokota, et al. Standards Track [Page 26] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + + Handover Initiate Flags (*) + Registration Procedures: Standards Action or IESG Approval + Flag Value Description Reference + ---- ----- ----------------------------------- ------------- + S 0x80 Assigned Address Configuration flag [RFC5568] + U 0x40 Buffer flag [RFC5568] + P 0x20 Proxy flag Section 6.1.1 + F 0x10 Forwarding flag Section 6.1.1 + + Handover Acknowledge Flags (*) + Registration Procedures: Standards Action or IESG Approval + Flag Value Description Reference + ---- ----- ------------------------------- ------------- + U 0x80 Buffer flag Section 6.1.2 + P 0x40 Proxy flag Section 6.1.2 + F 0x20 Forwarding flag Section 6.1.2 + + Handover Initiate Status Codes (*) + Registration Procedures: Standards Action or IESG Approval + Code Description Reference + ---- -------------------------------------- ------------- + 0 FBU with the PCoA as source IP address [RFC5568] + 1 FBU whose source IP address is not PCoA [RFC5568] + 2 Indicate the completion of forwarding Section 6.1.1 + 3 All available context transferred Section 6.1.1 + 4-255 Unassigned + + Handover Acknowledge Status Codes (*) + Registration Procedures: Standards Action or IESG Approval + Code Description Reference + ---- --------------------------------------- ------------- + 0 Handover Accepted or Successful + (when 'P' flag is set) Section 6.1.2 + Handover Accepted with NCoA valid [RFC5568] + 1 Handover Accepted, NCoA not valid [RFC5568] + 2 Handover Accepted, NCoA assigned [RFC5568] + 3 Handover Accepted, use PCoA [RFC5568] + 4 Message sent unsolicited [RFC5568] + 5 Context Transfer Accepted or Successful Section 6.1.2 + 6 All available Context Transferred Section 6.1.2 + 7-127 Unassigned + 128 Handover Not Accepted, reason unspecified [RFC5568] + 129 Administratively prohibited [RFC5568] + 130 Insufficient resources [RFC5568] + 131 Requested Context Not Available Section 6.1.2 + 132 Forwarding Not Available Section 6.1.2 + 133-255 Unassigned + + + + +Yokota, et al. Standards Track [Page 27] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +9. Acknowledgments + + The authors would like to specially thank Vijay Devarapalli and Sri + Gundavelli for their thorough reviews of this document. + + The authors would also like to thank Charlie Perkins, Desire Oulai, + Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan + Zhao, Julien Laganier, and Pierrick Seite for their passionate + discussions in the MIPSHOP working group mailing list. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support + in IPv6", RFC 3775, June 2004. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 + Vendor Specific Option", RFC 5094, December 2007. + + [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, + K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, + August 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, + July 2009. + + [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy + Mobile IPv6", RFC 5844, May 2010. + + [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, + "Generic Routing Encapsulation (GRE) Key Option for Proxy + Mobile IPv6", RFC 5845, June 2010. + + + + + +Yokota, et al. Standards Track [Page 28] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +10.2. Informative References + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", + RFC 4988, October 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yokota, et al. Standards Track [Page 29] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +Appendix A. Applicable Use Cases + +A.1. PMIPv6 Handoff Indication + + PMIPv6 [RFC5213] defines the Handoff Indicator option and also + describes the type of handoff and values that can be set for this + option. This document proposes one approach to determining the + handoff type by the NMAG when the handoff of the mobile node is + executed. + + According to [RFC5213], the following handoff types are defined: + + 0) Reserved + + 1) Attachment over a new interface + + 2) Handoff between two different interfaces of the mobile node + + 3) Handoff between mobile access gateways for the same interface + + 4) Handoff state unknown + + 5) Handoff state not changed (Re-registration) + + Assuming that there is a valid MN Link-layer Identifier (MN LL-ID), + the following solution can be considered. When the NMAG receives the + MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck + message, the NMAG compares it with the new MN LL-ID that is obtained + from the mobile node in the N-AN. If these two MN LL-IDs are the + same, the handoff type falls into type 3 (defined above) and the + Handoff Indicator value is set to 3. If these two MN LL-IDs are + different, the handoff is likely to be type 2 (defined above) since + the HI/HAck message exchange implies that this is a handoff rather + than a multihoming, and therefore the Handoff Indicator value can be + set to 2. If there is no HI/HAck exchange performed prior to the + network attachment of the mobile node in the N-AN, the NMAG may infer + that this is a multi-homing case and set the Handoff Indicator value + to 1. In the case of re-registration, the MAG, to which the mobile + node is attached, can determine if the handoff state is not changed, + so the MAG can set the HI value to 5 without any additional + information. If no handoff type can be assumed or if there is no + valid MN LL-ID available, the NMAG may set the value to 4. + + + + + + + + + +Yokota, et al. Standards Track [Page 30] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +A.2. Local Routing + + As described in Section 6.10.3 of [RFC5213], if the + EnableMAGLocalRouting flag is set, when two mobile nodes are attached + to one MAG, the traffic between them may be locally routed. If one + mobile node moves from this MAG (PMAG) to another MAG (NMAG) and if + the PMAG does not detect the mobile node's detachment, it will + continue to forward packets locally forever. This situation is more + likely to happen in the reactive fast handover with Wireless Local + Area Network (WLAN) access, which does not have the capability to + detect the detachment of the mobile node in a timely manner. This + specification can be applied to handle this case. When the mobile + node attaches to the NMAG, the NMAG sends the HI message to the PMAG + with the 'F' flag set, which makes the PMAG realize the detachment of + the mobile node and establish the inter-MAG tunnel. The PMAG + immediately stops the local routing and sends the packets for the + mobile node to the NMAG via that tunnel; the packets are then + delivered to the mobile node on the new link. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yokota, et al. Standards Track [Page 31] + +RFC 5949 Proxy-Based Fast Handover September 2010 + + +Authors' Addresses + + Hidetoshi Yokota + KDDI Lab + 2-1-15 Ohara, Fujimino + Saitama 356-8502 + Japan + + EMail: yokota@kddilabs.jp + + + Kuntal Chowdhury + Cisco Systems + 30 International Place + Tewksbury, MA 01876 + USA + + EMail: kchowdhu@cisco.com + + + Rajeev Koodli + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA + + EMail: rkoodli@cisco.com + + + Basavaraj Patil + Nokia + 6000 Connection Drive + Irving, TX 75039 + USA + + EMail: basavaraj.patil@nokia.com + + + Frank Xia + Huawei USA + 1700 Alma Dr. Suite 500 + Plano, TX 75075 + USA + + EMail: xiayangsong@huawei.com + + + + + + +Yokota, et al. Standards Track [Page 32] + -- cgit v1.2.3