Context and Micro-mobility Routing (seamoby) WG Rajeev Koodli INTERNET DRAFT Charles E. Perkins 21 February 2001 Communication Systems Laboratory Nokia Research Center A Context Transfer Framework for Seamless Mobility draft-koodli-seamoby-ctv6-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This document is an individual submission for the seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the seamoby@cdma_2000.org mailing list. Distribution of this memo is unlimited. Abstract Mobile nodes enhance their connections across wireless media by establishing various kinds of state (context), in order to make practicable, secure, and economical use of the available bandwidth. During handover from one access router to another, a bandwidth-constrained mobile node may need to have state information passed from the previous router to the new one. This document proposes a framework for control structures that enable transfer of the necessary state during handovers. This state transfer allows the applications running on the mobile node to operate with reduced latency, minimal disruption, and reduced packet loss during handovers. Koodli, Perkins Expires 21 August 2001 [Page i] Internet Draft Seamless Handovers 21 February 2001 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Data Structure Representation 3 4. Option Types and Packet Formats 6 4.1. Seamless Handover Initiate (SHIN) Destination Option . . 7 4.2. Seamless Handover Acknowledgment (SHAK) Option . . . . . 9 4.3. ICMP Seamless Handover Request option (SHREQ) . . . . . . 10 4.4. ICMP Seamless Handover Reply (SHREP) option . . . . . . . 11 4.5. Seamless Handover Reply Acknowledgment option . . . . . . 12 5. Using Options with Handover Signaling 13 5.1. Basic Handover Signaling . . . . . . . . . . . . . . . . 13 5.2. Fast Handover Signaling . . . . . . . . . . . . . . . . . 14 6. Configurable Parameters 17 Addresses 19 Koodli, Perkins Expires 21 August 2001 [Page 1] Internet Draft Seamless Handovers 21 February 2001 1. Introduction When a mobile node undergoes handover from an access router to another, context information pertaining to the mobile node's packet streams needs to be transferred in order to maintain seamless operation of applications. This seamless operation ensures that the mobile node does not have to re-establish the contexts associated with various features, such as QoS, header compression, security etc. In many instances (e.g., when the mobile node is attached to its access router through a low-bandwidth wireless link) the seamless operation also provides performance benefits, since context establishment typically involves transmission of a considerable amount of data. In this document, we describe a generic context transfer framework which provides 1. means for data structure representation of context information for inter-operability and efficient operation 2. packet formats for encapsulating the context data structure for transfer purposes, and 3. a description of how context transfers can be achieved with handover signaling with the packet format definitions Together, these components form the basis for context transfers. This document does not describe how the target router is selected for context transfer, nor does it explain context transfer (re)negotiation issues. Mobility management protocols outside the scope of this specification could consider the ability of an access router to support desired features when selecting a target router. For our purposes, we assume that the IP address of the target router is supplied to the context transfer framework. In this document, we make use of concepts outlined earlier in [3, 4, 5]. The protocols specified in those documents do not depend in any essential way on the mobile node's home address, nor on the way that the mobile node's local access IP address can be used as a care-of address for Mobile IPv6. While we make use of the concepts developed in those documents, what we present here is independent of Mobile IPv6. However, we assume IPv6 in the rest of this document. Furthermore, we have made the protocol specification to readily make use of recent fast handover designs using ICMP messages instead of IPv6 Destination Options. Koodli, Perkins Expires 21 August 2001 [Page 2] Internet Draft Seamless Handovers 21 February 2001 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119 [1]. We define the following terms for use in this document. We also use Figure 1 as the basis for our handover discussion. GPT Generic Profile Type: a general way to lay out state variable descriptors for use when describing various feature contexts [7]. ICMP Internet Control Message Protocol New Router The router to which the MN attaches after handover Previous Router The MN's default router prior to handover New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the Previous Router 3. Data Structure Representation There may be multiple features associated with each unidirectional packet stream (also known as a microflow). Examples are QoS, security and header compression. We assume that there is a feature context that is specific for each packet stream. Note that each feature itself may be supported by multiple, co-existing mechanisms. As an example, a particular header compression feature may support both IPv6/UDP/RTP and IPv6/TCP compression mechanisms at the same router. Therefore, a feature context may need to specifically refer to the particular mechanism it realizes. One or more feature contexts may belong to a microflow context and many microflow contexts together form the overall context for a mobile node. This hierarchy, consistent with the nomenclature in [7], is illustrated in Figure 2 (where feature realizations through one or more mechanisms is not shown for clarity). >From this hierarchy, it is clear that a representation is needed to capture the diversity of features and feature realizations. It is also Koodli, Perkins Expires 21 August 2001 [Page 3] Internet Draft Seamless Handovers 21 February 2001 v +------------+ +-+ | Previous | < | | ---------- | Router | ------ > ----\ +-+ | (Prtr) | < \ MN | | \ | +------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +------------+ / +-+ | New | < / | | ---------- | Router | ------ > ----/ +-+ | (Nrtr) | < MN | | +------------+ Figure 1: Reference Scenario for Handover clear from Figure 2, it is also clear that a feature context is the unit of data representation for context transfer purposes. Given the diversity of various features and their associated contexts, we recognize the need for a simple representation that provides a generic structure, while allowing each feature to define its own state variables. We define a Generic Profile Type (GPT) as an object that uniquely identifies the type of a feature context. An instance of a GPT clearly defines the state variables associated with the corresponding feature context. For example, a QoS Profile Type (QPT) for Diffserv has to identify the control variables associated with the QoS feature, and a Compression Profile Type (CPT) for IPv6 has to identify the IPv6 header compression control variables. The purpose of a GPT is as follows. First, for each feature (and the associated mechanism that is standardized), it provides a definition for the feature context that can be used during handovers. This context would have the necessary and sufficient state variables so that the node receiving the context would be able to seamlessly offer the feature subsequent to handover. In other words, the context state captured by each instance of GPT would facilitate feature inter-operability across access routers during handovers. Second, a GPT provides a standard programming object that can be used, e.g., to request context transfer for a feature, or to initialize feature support. In other Koodli, Perkins Expires 21 August 2001 [Page 4] Internet Draft Seamless Handovers 21 February 2001 +--------------+ | | | Context | | | | | +--------------+ | | +-----------------------------------------+ | | | +------------+ +------------+ +------------+ | | | | | | |Microflow-1 | |Microflow-2 | ... |Microflow-n | | context | | context | | context | | | | | | | +------------+ +------------+ +------------+ | | | +----------+ +----------------+ | | | | | Feature | +----------+ +----------+ |context X | | | | | | | | Feature | | Feature | +----------+ |context Y | |context X | | | | | +----------+ +----------+ Figure 2: Context Hierarchy for a Mobile Node words, this object is visible for a mobile node for use in appropriate programming API and signals. Furthermore, some mobility management protocol may use this object to determine whether a target router supports the desired feature. Finally, we note that each instance of the GPT has to formalize the state for context transfer purposes individually. As an example, the Compression Profile Type (CPT) for ``IPv6/UDP/RTP/voice/G.723.1'' has to specify all the necessary and sufficient state variables for seamless operation of header compression across handovers. We expect that standardization effort is likely for the definition of new GPTs. Each feature context itself, then consists of the [GPT, state variables] tuple along with some generally useful parameters (such as a filter that identifies the packet stream and a handle that allows indexing into the correct feature context). Koodli, Perkins Expires 21 August 2001 [Page 5] Internet Draft Seamless Handovers 21 February 2001 4. Option Types and Packet Formats Once the data structure for the context state variables is available, appropriate packet formats are needed for communication and processing. We propose using ICMP options for inter-access router communication, and IPv6 destination options for mobile node - access router communication. The ICMP options can be used with specific signaling messages, e.g., with fast handover signaling messages, to facilitate context transfer. The mobile node uses destination options to effect context transfer using appropriate signals. When a suitable signaling message is not available for the mobile node, we assume that an IPv6 packet containing the context transfer destination option is used for communication. We believe that the delineation between context options and the signals (i.e., ICMP message or other control message) used to carry those options provides maximum flexibility. The proposed options should cover mobile node - access router communication as well as communication between access routers. Other network entities may make use of the options we define here in their signals to the access routers or the mobile node itself, but such uses are outside the scope of this specification. The following ICMP options are defined for handling context transfer requirements between access routers. 1. Seamless Handover Request (SHREQ) 2. Seamless Handover Reply (SHREP), and 3. (optionally) Seamless Handover Reply Acknowledgment (SHREP-Ack) All of these options are of the form shown in Figure 3. 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 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ One or more Feature Context sub options... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Feature Context ICMP Option Format The following IPv6 destination options are defined for the mobile node to request context transfers and process the responses. Koodli, Perkins Expires 21 August 2001 [Page 6] Internet Draft Seamless Handovers 21 February 2001 1. Seamless Handover Initiate (SHIN) 2. Seamless Handover Acknowledgment (SHAK) Each feature context, represented by the appropriate [GPT, State Variables] tuple, is enumerated as a sub option in SHIN, SHREQ and SHREP options. Thus, each SHIN, SHREQ and SHREP option contains one or more sub options corresponding to one or more feature contexts (or requests for feature contexts). These specific sub options, not specified in this document, may appear multiple times in the same option whenever needed for different instances of the same GPT. These ICMP options and IPv6 Destination Options will be described in the following sections. 4.1. Seamless Handover Initiate (SHIN) Destination Option The Seamless Handover Initiate destination option is an envelope for containing suboptions, prefixed by some fields that are generally expected to be useful for all suboptions. The sub options enumerate various context transfer requests and optionally supply additional parameters for those sub options. The mobile node sends SHIN to the New Router after it establishes connectivity. The mobile node could also send this option to the Previous Router when appropriate, e.g., when support for fast handover signaling is available. When the mobile node sends it to the Previous Router, this option is called Proactive SHIN or simply P-SHIN. When it sends this option to the New Router, the MN supplies its previous IP address and Previous Router address, where as when it sends it to the Previous Router, it supplies its new IP address and New Router address. Koodli, Perkins Expires 21 August 2001 [Page 7] Internet Draft Seamless Handovers 21 February 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len |Op-Type=(P)SHIN| Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous (New) IP Access Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous (New) Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Data authenticated by MN ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Feature Data for Nrtr only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Seamless Handover Initiate Destination Option Format Option Type Seamless Handover Initiate (SHIN), Proactive SHIN (P-SHIN). Option Length Variable Reserved Reserved for future use. Must be set to zero by the MN. This is not present in P-SHIN. Replay A value used to make sure that each use of the Seamless Handover Initiate destination option is uniquely identifiable. This is not present in P-SHIN. Authentication Data An unforgeable value calculated as discussed below. This not present in P-SHIN. Suboptions Feature suboptions requesting context transfer included as selected by the mobile node. In order to make sure that context cannot be lost at the previous router in response to an erroneous action or malicious request not initiated by the mobile node, authentication is required for the context Koodli, Perkins Expires 21 August 2001 [Page 8] Internet Draft Seamless Handovers 21 February 2001 transfer request. The Authentication Data (Auth) is calculated as follows: Auth = HMAC (Key, input_data) mod 2^32 where HMAC (Key, Data) is defined (see RFC 2104 [6] for details) roughly as follows: HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data)) and MD5 is defined as given in RFC 1321 [8]. The input_data is defined as follows: input_data = HO_features || Replay || Paddr where HO_features includes all the suboption data from the MN to the Previous Router (Prtr), and Paddr is the mobile node's previous IP access address while attached to the network served by Prtr. If a mobile node uses the same features and Previous_IP_Address more than 255 times, then the mobile node SHOULD establish a new security association with the Previous Router (Prtr) (i.e., the mobile node's default router at the Previous IP Access Address (Paddr)). 4.2. Seamless Handover Acknowledgment (SHAK) Option The Seamless Handover Acknowledgment (SHAK) option, illustrated in Figure 5. This option MAY be sent from the New (Previous) Router to the mobile node to inform the mobile node about the status of its SHIN message. The acknowledgment MAY contain separate status reports for each relevant feature that was requested. However, unless a failure has occurred, or else otherwise required by a specific feature, SHAK is optional. The mobile node MUST be prepared to process a SHAK option even when no error has occurred. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len | Op-Type=SHAck | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options response from Nrtr (Prtr) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Seamless Handover Acknowledgment Option Format Koodli, Perkins Expires 21 August 2001 [Page 9] Internet Draft Seamless Handovers 21 February 2001 The routers use the following messages to request and obtain context state information. 4.3. ICMP Seamless Handover Request option (SHREQ) The Seamless Handover Request (SHREQ) option, illustrated in figure 6, provides means for New Router to request that some feature context associated with the mobile node at the Previous Router be sent to the New Router as part of a seamless handover. The option contains suboptions prefixed by previous and new IP addresses of the mobile node. The New Router MUST copy the suboptions supplied by the MN (in the SHIN message) exclusively for the Previous Router verbatim starting from the suboption type AuthPrtr. 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=SHREQ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit New IP Address (Naddr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous IP Address (Paddr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Context Transfer Options Authenticated by MN ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Prtr only from Nrtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Seamless Handover Request Option Format IPv6 fields: Source address The IP address of the New Router Destination Address The IP address of the Previous Router Option Type Seamless Handover Request (SHREQ) Option Length Variable Koodli, Perkins Expires 21 August 2001 [Page 10] Internet Draft Seamless Handovers 21 February 2001 Reserved Reserved for future use, set to zero by the MN. Replay A value used to make sure that each use of the Seamless Handover Initiate destination option is uniquely identifiable. Authentication Data An unforgeable value calculated as discussed above. Suboptions Feature suboptions included as selected by the mobile node and the New Router, in the order specified. If a router transmits a message with SHREQ option, and does not receive a message with SHREP option (see below) within SHREQ_REXMIT_TIME, the router SHOULD retransmit the SHREQ option. This retransmission should be attempted until SHREQ_RETRIES is exceeded. For this reason, all context suboptions are required to be specified in such a way that the effect is the same whether the Previous Router receives them one time or several times as part of the same seamless handover (idempotent behavior). 4.4. ICMP Seamless Handover Reply (SHREP) option The Seamless Handover Reply (SHREP) option, illustrated in Figure 7, allows the Previous Router to send context state associated with the mobile node to the New Router as a part of seamless handover. 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=(U)SHREP | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit New IP Address (Naddr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous IP Address (Paddr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Context Transfer Options Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Data (for U-SHREP only) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Seamless Handover Reply Option Format Koodli, Perkins Expires 21 August 2001 [Page 11] Internet Draft Seamless Handovers 21 February 2001 Option Type Seamless Handover Reply (SHREP), Unsolicited SHREP (U-SHREP). Option Length Variable ICMP Options Data Feature suboptions data appropriate for each suboption present in the SHREQ option in the order specified. Authentication Data An unforgeable value calculated as discussed above. This data, along with the preceding four bytes of associated sub option, is present only for U-SHREP option (See Section 5.2. Because of retransmissions, the New Router may receive the same SHREP option and suboptions several times as part of the same seamless handover. Therefore, all context suboptions are required to be specified in such a way that the effect is the same whether the New Router receives them one time or several times in a SHREP message as part of the same seamless handover. 4.5. Seamless Handover Reply Acknowledgment option In addition to these two options, the New Router MAY use the SHREP-Ack option shown in Figure 8 to acknowledge individual sub options received in SHREP or U-SHREP. 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=SHREP-Ack | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit New IP Address (Naddr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128-bit Previous IP Address (Paddr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Context Transfer Acknowledgment Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Seamless Handover Reply Ack Option Format Koodli, Perkins Expires 21 August 2001 [Page 12] Internet Draft Seamless Handovers 21 February 2001 Option Type (Unsolicited) Seamless Handover Reply Ack (SHREP-Ack). Option Length Variable ICMP Options Data Feature suboptions acknowledgments appropriate for each suboption present in the SHREP or U-SHREP. 5. Using Options with Handover Signaling This section specifies the use of destination options and ICMP options described in the previous sections with handover signaling. There are two types of signaling for context transfer purposes. Sometimes, the context transfer takes place "gratuitously" from the New Router's viewpoint. In this scenario, the Previous Router, perhaps in response to a request from the mobile node (or some other network entity), sends options containing context information to the New Router without explicit request from the latter. Such a transfer could take place before the mobile node even attaches to the New Router, so that the desired context could be utilized as soon as the mobile node obtains new IP connectivity. The New Router MAY acknowledge this gratuitous context transfer. Other times, the context transfer takes place as a reaction to explicit signaling from the mobile node after it attaches to its New Router. In this case, the New Router explicitly sends a context transfer request to the Previous Router. This scenario can be considered as an extension to the basic handover signaling. This can also be considered as a fallback approach when the fast handover signaling experiences a failure. We explain this scenario first. 5.1. Basic Handover Signaling After the mobile node performs Neighbor Discovery procedures and formulates a new IP access address, it sends a message containing SHIN option shown in Figure 4 to the New Router. We call this message by the name of the option it carries, i.e., SHIN. When the New Router (Nrtr) receives this SHIN message, it identifies the suboptions within the SHIN and constructs a new message for the Previous Router to request context handover. This message, called the Seamless Handover Request (SHREQ) message (i.e., the message containing the SHREQ option), is described in section 4.3 and MUST use IPsec for the appropriate security protection. When the Previous Router (Prtr) receives the SHREQ message, it MUST check to see whether it has a security association with the New Router. If so, the Previous Router MUST check for the presence and validity of Koodli, Perkins Expires 21 August 2001 [Page 13] Internet Draft Seamless Handovers 21 February 2001 an IPv6 Authentication Option [2]. Then the Previous Router MUST check for the presence and validity of the SHREQ Authentication Suboption data supplied by the mobile node to make sure that the handover has been authorized by the mobile node. The Previous Router then constructs a Seamless Handover Reply (SHREP) message that would contain appropriate structures for the context transfer. Indeed, this message would contain enumerated ICMP sub options corresponding to various feature contexts. These operations are illustrated in Figure 9. It is important that context for the mobile node be not destroyed at the Previous Router without authorization. Hence, after sending the requested state to the New Router in the SHREP message, the Previous Router has to keep the context data for the mobile node intact for CONTEXT_SAVE_TIME. This would allow recovery in case a SHREP message is lost and not received by the router sending the SHREQ message. The Previous Router SHOULD not perform garbage collection of context data until CONTEXT_PURGE_TIME. +----------+ 2. SHREQ +----------+ | | <--------- | | | | | | | Prtr |-----------------| Nrtr | | | | | | | ---------> | | +----------+ 3. SHREP +----------+ | ^ | | | | ~~ 1. SHIN| ~~ | V V +-+ +-+ | | movement | | +-+ -------> +-+ Figure 9: Context Transfer with Basic Handover Signaling 5.2. Fast Handover Signaling In the ``gratuitous'' context transfer scenario, the Previous Router uses the SHREP option (with all suboptions inserted just as for the Koodli, Perkins Expires 21 August 2001 [Page 14] Internet Draft Seamless Handovers 21 February 2001 previous ``reactive'' case) along with a suitable signaling message, such as the HI message [9]. The trigger for this gratuitous (or unsolicited) option may come from the Proactive SHIN (P-SHIN) option that the mobile node sends while still being attached to the Previous Router. The trigger for this U-SHREP option could also come from some other network entity. See Figure 10. In this P-SHIN option, the MN supplies its new IP access address as well as the New Router's IP address, and enumerates its sub options for context transfer. It, however, does not compute the authentication sub option shown in Figure 4. The reason for not including this sub option is as follows. The MN already shares a security association with the Previous Router, making the use of IPSec authentication header for the message containing SHIN option sufficient. Furthermore, the MN still sends a normal SHIN message (containing the authentication sub option) subsequent to attaching to the New Router. Thus, including the authentication sub option twice would expose the MN to masquerading attacks. +----------+ +----------+ | | | | | | | | | Prtr |-----------------| Nrtr | | | | | | | ---------> | | +----------+ 2. U-SHREP +----------+ | ^ ^ | | | | | ~~ | 1. P-SHIN | ~~ | 3. SHIN | V V +-+ +-+ | | movement | | +-+ -------> +-+ Figure 10: Context Transfer with Fast Handover Signaling In order for the gratuitous context transfer operation to be secure, the Previous Router MUST have a security association with the New Router, and it MUST include an IPv6 Authentication Header in the message containing gratuitous SHREP option. Furthermore, the Previous Router MUST include the authentication sub option (indicated as optional in Figure 7) in this message based on the sub option requests enumerated in the proactive SHIN option. When the New Router receives a HI message Koodli, Perkins Expires 21 August 2001 [Page 15] Internet Draft Seamless Handovers 21 February 2001 with SHREP option, it MUST check for the presence and validity of an IPv6 Authentication Header using the security association it has with the Previous Router. In order to characterize the option as an unsolicited SHREP, a new type called U-SHREQ is defined for use in the HI message. When the New Router receives a valid U-SHREP option, it MUST buffer the contents in the option for at least GRAT_SHREP_TIME, or until it receives the corresponding SHIN message from the mobile node whichever event occurs first. When the mobile node sends a SHIN to a New Router that has received an unsolicited SHREP from the Previous Router, the New Router can immediately complete all necessary context transfers. Note that the MN still needs to send a normal SHIN to the New Router in order to allow the New Router to activate received contexts. And, such a SHIN message would contain the authentication sub option covering all the sub options that the mobile node is interested in. The New Router MUST compare the authentication data against that is supplied by the Previous Router in the U-SHREP option prior to activating the contexts. The New Router MAY send a SHREP-Ack option, e.g., in a HACK message. Koodli, Perkins Expires 21 August 2001 [Page 16] Internet Draft Seamless Handovers 21 February 2001 6. Configurable Parameters Every access router supporting the mobility extensions defined in this document SHOULD be able to configure each parameter in the following table. Each table entry contains the name of the parameter, the default value, and the section of the document in which the parameter first appears. Parameter Name Default Value Definition ------------------- ---------------------- ------- SHREQ_RETRIES 3 Section 4.3 SHREQ_REXMIT_TIME 1 seconds Section 4.3 CONTEXT_SAVE_TIME 2 * SHREQ_REXMIT_TIME Section 5.1 CONTEXT_PURGE_TIME 5 * SHREQ_REXMIT_TIME Section 5.1 GRAT_SHREP_TIME 3 seconds Section 5.2 References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [3] R. Koodli and C. Perkins. Fast Handovers in Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-fastv6-01.txt, October 2000. [4] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. [5] R Koodli, M. Tiwari, and C.E. Perkins. Header Compression State Relocation in IP Mobile Networks (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-rohc-hc-relocate-01.txt, November 2000. [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [7] O. Levkowetz and et al. Problem Description: Reasons For Doing Context Transfers Between Nodes in an IP Access Network (work in Koodli, Perkins Expires 21 August 2001 [Page 17] Internet Draft Seamless Handovers 21 February 2001 progress). Internet Draft, Internet Engineering Task Force. draft-ietf-seamoby-context-transfer-problem-stat-00.txt, February 2001. [8] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. [9] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in progress). Internet Draft, Internet Engineering Task Force. draft-designteam-fast-mipv6-01.txt, February 2001. Koodli, Perkins Expires 21 August 2001 [Page 18] Internet Draft Seamless Handovers 21 February 2001 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors: Rajeev Koodli Charles E. Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2986 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Perkins Expires 21 August 2001 [Page 19]