Internet Draft Madjid Nakhjiri Ajoy Singh draft-nakhjiri-seamoby-text-ct-00.txt Motorola Inc. Category: Internet draft Nov 2001 Expires: May 2002 Time Efficient conteXt Transfer (TEXT) 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. Abstract This document presents a context transfer proposal, greatly in line with the current fast handover framework within Mobile IP WG [3]. Namely, this proposal allows flow of MNÆs real time traffic through a tunnel, while completing context transfer outside timing critical path for handover. The context transfer procedure is initiated at an instance of MNÆs choice in regard to layer 2 and 3 handover and MNÆs traffic. To add flexibility, the context data is transferred outside the tunnel. Although this document concentrates on a protocol proposal, the framework on which this proposal is based, provides great amount of flexibility in detailed design of context transfer. A minimum reliability mechanism for ensuring quality of transferred context is added. Specifically, the context update mechanism suggested here can not be achieved by any transport protocol. Since this proposal is written at a time, when transport requirements for context transfer procedure are not specified, the reliability mechanisms included should be treated as preliminary. Table of Contents Status of this Memo................................................1 Nakhjiri Internet Draft - Expires May 2002 1 Internet Draft Time Efficient CT October 2001 Abstract...........................................................1 Table of Contents..................................................1 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. Terminology....................................................4 4. Protocol overview..............................................5 4.1. Call flow....................................................7 4.2. Advantages...................................................7 5. Context transfer protocol considerations.......................8 5.1. context transfer start.......................................8 5.1.1. Context transfer starting trigger....................8 5.1.2. Context transfer starting element....................9 5.2. Robustness considerations....................................9 5.3. Reliability considerations..................................10 5.3.1. CT Header Checksum (optional).......................11 5.3.2. Feature data checksum: fdc (optional)...............11 5.3.3. Update flag (U-flag) (optional).....................12 5.3.4. Context transfer NACKs (optional)...................12 5.3.5. NACK timers (optional)..............................12 5.4. Security considerations:....................................12 6. Protocol messaging............................................13 6.1. IPsec ESP header............................................13 6.2. Context transfer header.....................................14 6.3. Context profile types.......................................15 7. Message formats...............................................15 7.1. CT Request message (MN to aAR)..............................15 7.2. CT data message (aAR to newAR)..............................15 7.3. Context transfer NACK message (from nAR to aAR) (optional)..17 7.4. CT abort message (nAR to aAR)...............................18 8. Compliance with requirements for context transfer.............18 8.1. Compliance with general requirements (section 4 of [5]).....18 8.2. Compliance with protocol requirements (section 5 of [5])....19 9. IANA considerations...........................................20 10. Security Considerations.....................................20 11. Acknowledgments.............................................21 12. References..................................................21 13. Contact Information.........................................22 1. Introduction The amount of signaling required during handovers in IP networks [1] together with scarcity of bandwidth in most radio networks to support this signaling traffic have created one of the major obstacles in integrating IP based solutions into the most of todayÆs wireless environments. To be specific, the combination of the two mentioned factors would potentially result in prohibitively large disruption in the flow of traffic for real time applications. Various methods have been proposed to reduce or eliminate the length of such disruption. Most of the work within Mobile IP WG has been focused on minimizing the delay associated with registration and change of routing information by allowing Nakhjiri Internet Draft - Expires May 2002 2 Internet Draft Time Efficient CT October 2001 layer 3 handover signaling continue in concurrence with other handover related events [2]. However, applications running at MN would also have to provide continuous support for various features such as security, QoS, etc, even after handovers. The instantiation of the context information at the new AR without re-negotiation by the MN is called context transfer [4]. Since the early stages of the context transfer requirement specification [5], it was clear that in order to reduce the amount of perceived latency in handovers, the context transfer procedure should also be optimized from a latency point of view. Low bandwidth in 3G cellular environments generally imposes a limit on the amount of signaling that can be done over the air during critical path. Recently a solution for Mobile IP handover has been proposed [3], which allows the MN to keep its real time traffic without any disruption until the MN chooses to engage in L3 handover (acquisition of new CoA from new AR). The MN's traffic is simply tunneled by the anchor AR to the new AR, which in turn forwards the traffic to MN. The registration is postponed to MN's earliest convenience. This solution removes L3 handover signaling out of timing critical path and thereby reducing service disruption due to layer 3 registration process. The context transfer solution proposed in this draft, adopts the above handover solution [3] and seeks to eliminate the context transfer signaling out of timing critical path of network layer handover. This proposal simply suggests that after a link layer handover, the context still resides at anchor AR, rather than at the new AR, until MN starts engaging in layer 3 handover and adopts the new AR as the AR in charge of forwarding MNÆs traffic. During that time, the old AR (anchor AR) is in charge of processing MNÆs feature. Context transfer can be started and completed along with delivery of data traffic and independent of exact timing of handover completion. Once the context transfer is completed reliably, the new AR simply takes over processing of MNÆs service features. This way, this proposal ensures not only continuous traffic forwarding and feature support, but also ensures context reliability by preventing context mis- synchronization. The context transfer needs not to happen through the tunnel. However, the tunnel for the data traffic MUST stay in place until completion of context transfer. Once the context transfer is complete, the traffic tunnel can be torn down. Section 2 of this document defines terminology used in this document. Section 3 provides an overview of the proposed protocol and its benefits. Section 4 covers some considerations, that need to be taken into account during more detailed protocol design stages, e.g. it explains reliability and timing issues. Section 5 contains general context transfer messaging issues, while Section 6 contains the details of the messages. Section 7 discusses IANA considerations. Section 8 provides verifications for the Nakhjiri Internet Draft - Expires May 2002 3 Internet Draft Time Efficient CT October 2001 compliance of the proposed solution with context transfer requirements. 2. Conventions used in this document 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 RFC-2119 [5]. 3. Terminology The next subsections define various terms used throughout this document. Most of the terminology in this draft is in accordance with Mobile IP and Seamoby WG drafts ([1]-[5]). Hence, new terms or slight additions to the existing explanations are given here to help understanding the concepts of this draft. aAR anchor AR The access router, which handles routing of mobile node's traffic and ensures support of features associated to MN's applications and holds MN's contexts. This is also the AR, from which MN has acquired its current CoA. NAR new AR The AR, with which, the MN establishes link connections (maybe via an access point) after the handover. CaAR context anchor AR The AR that holds MN's context. Anchor AR is in general also context anchor AR, This term is added to ease the understanding of the concept: context transfer does not happen until MN acquires a newCoA and changes anchor AR. aCoA anchor CoA The care of address, CoA, that MN has acquired from its anchor AR and uses for its IP traffic. nCoA new CoA The CoA, that MN acquires from its new AR. Note that nCoA is not aCoA until the newAR receives MN's context and starts act as MN's anchor AR. In other word, it is possible that for a short period of time MN holds an aCoA and nCoA. feature CTTL feature context time to live Nakhjiri Internet Draft - Expires May 2002 4 Internet Draft Time Efficient CT October 2001 The time interval during which a feature context is relevant. The length of this time interval (time to live: TTL) can be different for different features, and different applications, e.g. TTL for header compression context for voice traffic can be as small as voice packet inter-arrival time, while TTL for IPsec context can be as long as the MN stays within the same AR domain and TTL for QoS somewhere in between. Feature context retransmissions In case transmission a context packet has failed, depending on the TTL of the included feature context data, the lost data needs to be retransmitted or updated. The short-lived feature contexts need updates, while the longer-lived feature contexts need re- transmissions. This also makes the bundling of feature context data into one or several packets an important design consideration: the relation of various feature contexts, path MTU and link RTT are among important factors in context data fragmentation. Feature Context update transfer In case a feature TTL expires prior to completion of context transfer and redirection of traffic, an update of that feature context is necessary. Note: Unlike context retransmissions, feature context update transfer cannot be accomplished through a transport layer protocol. 4. Protocol overview The motivation for this proposal is to eliminate the context transfer delay from the critical path of network layer handover. It is developed based on the mobility framework, in which, the MNÆs traffic is forwarded through a tunnel between old AR and new AR during handover. In other words, after the MN has completed an L2 handover to the new AR, the traffic for the MN is simply tunneled from the old AR to its new AR, until the MN decides to have the new AR to route MN's traffic (MN changes its CoA). During that time, the new AR continues to forward the traffic between MN and old AR without looking into the details of the features associated with the MN. During this time, the old AR (anchor AR) is in charge of processing MNÆs feature. Hence, old AR acts as an anchor AR can also hold mobile nodeÆs context information. Hence the MN's context information is not transferred from old AR to nAR until MN acquires its nCoA and decides to use the nAR as new forwarding agent. Context transfer can be started and completed along with delivery of data traffic and independent of exact timing of handover completion. Once the context transfer is completed reliably, the new AR simply takes over processing of MNÆs service features. This Nakhjiri Internet Draft - Expires May 2002 5 Internet Draft Time Efficient CT October 2001 way, this proposal ensures not only continuous traffic forwarding and feature support, but also ensures context reliability by preventing context mis-synchronization. The context transfer needs not to happen through the tunnel. However, the tunnel for the data traffic MUST stay in place until completion of context transfer. Once the context transfer is complete, the traffic tunnel can be torn down. This provides the natural mechanism for application continuity as well as synchronization of time sensitive context information such as header compression states. Note: Keeping the context at anchor AR until a change of CoA by MN also provides sufficient protection against unnecessary context transfers in ping-ponging or handover to the third AR scenarios. The following steps describe the proposed context transfer procedure: -The bi-directional tunnel between old AR (anchor AR) and new AR is used to the exchange traffic between MN and aAR via new AR until the MN acquires its nCoA. -During this period the MN's context resides at anchor AR. The new AR continues to forward the traffic between MN and aAR, without looking into the details of the features associated with the new users. -Once the MN has acquired its nCoA and is ready to changes its anchor AR from oldAR to newAR, the two ARs can engage in context transfer. -The command to start context transfer is issued by MN through an authenticated context transfer request message sent by MN to aAR through nAR (not tunneled). MN sends this message after one of the event triggers described in 5.1. As a trigger, we choose registration request or binding update depending on Mobile IP version. Also, note that it is possible to have the MN send the context transfer request to the new AR, in case, it is desired that the new AR starts context transfer signaling. -After receiving the context transfer request with proper authentication, the anchor AR starts the context transfer procedure through context transfer data message. The context information can be sent as next header information associated with a data flow or in separate packets. We prefer the latter approach, at this point. -In case reliability in context delivery is required and a non- reliable transport protocol is chosen in the future, we have proposed optional reliability mechanisms with details explained in sections 5 and 7. Nakhjiri Internet Draft - Expires May 2002 6 Internet Draft Time Efficient CT October 2001 -As soon as the context transfer is complete, either the bi- directional tunnel is torn down (nAR or aAR sends a HRqst to aAR with lifetime=0 ) or the aAR stops handling the MNÆs feature processing (more in 5.4 and 5.5). -Once the tunnel is torn down and MN is ready to use its nCoA, the new AR will handle routing and feature support for MN's traffic. 4.1. Message flow The following shows the message flow for the protocol. Note that the reliability related messages in the protocol, are not included in the protocol overview above and figure below. This is to retain the flexibility of the protocol towards the currently uncertain reliability requirements for context transfer. The detail formats of these message are described in 4.5 and 5. MN's traffic forwarded through aAR-nAR tunnel | MN decides to change nCoA t MN -CT Request->aAR i aAR ---CT data-------> nAR m aAR ----HReq (lt=0)-->nAR e | V figure 1: context transfer messaging (without inbuilt reliability) 4.2. Advantages The benefits of this proposal can be listed as following: 1-The Context transfer is eliminated from timing critical path. Since the tunnel stays in place, until nCoA for the MN is operative, a great amount of flexibility in choosing the timing for context transfer trigger is provided. Context transfer can be done regardless of exact timing of handover messages. Also, it provides great amount of flexibility in choice the network element, starting context transfer signaling. A list of viable triggers is provided in 5.1. 2-It reduces network traffic load due to context transfer, in cases MN moves too quickly between several ARs, ping-pongs between same pair of ARs. Only when MN is ready to acquire nCoA, and the new AR is known, context transfer is done. In case MN moves to a third AR before changing its CoA, the aAR simply tears the wireless end of tunnel to oAR (AR2) down and set it up at nAR. The traffic can be still tunneled from the aAR and the context can still stay at aAR until the MN decides to change its CoA. Nakhjiri Internet Draft - Expires May 2002 7 Internet Draft Time Efficient CT October 2001 3-The MN determines based on its traffic load, when to change context anchor AR. Also by allowing MN to request context transfer initiation, and hence provides more design flexibility to accommodate various access technologies. 4-Since context transfer is done after the handover target is determined, the need for proactive multi-target context transfers is eliminated. 5-Context is delivered just in time, the chances for context mis-synchronization and stale contexts are greatly reduced, since the tunnel is torn down after transfer of dynamic feature context such as header compression states (details in 5.2 and 5.3). 5. Context transfer protocol considerations 5.1. context transfer start 5.1.1. Context transfer starting trigger Once the MN has acquired a new CoA from newAR, the newAR needs to install the MN's context, in order to be able to start handling MN's traffic. Hence, context transfer from anchor AR to new AR needs to be complete before the bi-directional tunnel between old AR and new AR is torn down. Although, this imposes a hard deadline for context transfer completion, this proposal provides a great deal of flexibility in choosing the timing of context transfer trigger. We can safely say, the context transfer trigger can created at any time between the following two events (as long as the tunnel life- time allows for complete transfer of context data, otherwise tunnel life-time must be extended) 1) MN starts signaling for new CoA acquisition. 2) New AR is ready to handle routing of MN's traffic (tunnel must be torn down) Below is a list several that events can be chosen as CT triggers: -L2 indication to new AR about L2 connection between MN and nAR. -MN initiates new CoA acquisition (address auto-configuration or registration message to HA). -MN informs its aAR about its new CoA through a BU (BU in Mobile IP is seen as an indication for old AR to start forwarding MN's packets to new CoA through new AR. -MN informs new AR about its new CoA by sending a neighbor advertisement (NA). Despite the flexibility in choosing triggers and messages. CT request messaging can be piggybacked along with any of these Nakhjiri Internet Draft - Expires May 2002 8 Internet Draft Time Efficient CT October 2001 messages or sent as a stand alone packet (our choice is the latter). We choose a source AR initiated approach based on MN's request as described below: Once the MN has acquired a new CoA, it will send a registration request (v4) or a binding update, BU, to CN (v6). MN can use this event, as a trigger for sending context transfer request message to aAR. 5.1.2. Context transfer starting element Any of following approaches can be chosen to start context transfer -A source initiated context transfer (source trigger to old AR, such as BU) -A target initiated context transfer (target trigger to new AR, such as NA) -Simply have the MN to request a context transfer from new AR or old AR. We see that this framework provides a great amount of flexibility in choosing the starting event and element. As mentioned earlier, we choose to have MN send a context transfer request to old AR. 5.2. Robustness considerations In order to provide a robust transfer of context, a number of factors should be taken into account. -In case the network is capable of handling different QoS profiles, the context transfer packets should be treated as better than best effort traffic to add robustness to context transfer procedure. -Fragmentation of context data into multiple packets might be necessary. Reasons for fragmentation might be: 1-Large amount of context data in relation to path MTU and maximum segment size (MSS). 2-Different feature context data may have significantly different life-times and the aAR-nAR round trip times (RTT) may be prohibitively long. In this case, these feature contexts might have to be sent in different packets to avoid inconsistency of protocol states at protocol peers. 3-In case multiphase context transfer is deemed necessary for some reason. Note that, our context proposal does not require multiphase context transfer. In case fragmentation is required, consecutive context data packets are marked with ascending context data sequence numbers. -In case, context transfer is performed at the same time as real time traffic, prevailing flow of real time traffic will Nakhjiri Internet Draft - Expires May 2002 9 Internet Draft Time Efficient CT October 2001 render the already transmitted header compression states invalid. Hence, once the header compression states are transmitted, either the tunnel should be torn down, or the anchor AR must stop transmitting compressed packets to the MN through the tunnel, i.e. the remainder of the traffic should be transmitted in uncompressed format. -Tunnel tear down message: As mentioned above, if possible, once the header compression states are transferred, the tunnel should be torn down to avoid state inconsistency. However, as mentioned above, we suggest that after completion of context transfer, aAR simply send uncompressed packets to nAR. -CT abort message: In case the MN moves to a third AR, while the context transfer signaling is in progress, the context transfer should be aborted immediately of two reasons: 1-the context would no longer be needed at the second AR. 2-To avoid the confusion on what AR is the MN's current context anchor AR. The. details of this message are explained in section 6. 5.3. Reliability considerations This proposal is written at a time, when transport requirements for context transfer procedure are not specified [5], and hence the reliability mechanisms suggested here needs to be viewed bearing that fact in mind. In case, the context transfer mechanism has a need for reliability mechanisms, it is possible that an existing transport protocol with some reliability provisioning mechanisms such as retransmissions and ACKs is chosen for this purpose. Of this reason, we avoid adding extensive inbuilt reliability mechanisms in our CT protocol design. However, regardless of the choice of transport and reliability mechanism, it is important to note the following: NOTE: The reliability mechanisms provided by transport layer can provide retransmission of data. In case of context transfer, certain feature contexts, such as header compression states are highly dynamic. In case the transmission of such contexts fails, it might be possible that retransmission of the same feature context would lead to inconsistency. In such cases, an update rather than a retransmission is necessary. The underlying transport mechanisms would only be able to handle retransmissions and not updates. It is not clear at this point, whether reliability is a necessity for context transfer protocol. Hence, in this section, we provide the following context transfer message flow with optional minimum reliability mechanism. For instance, we do not provide mechanisms that inform the new AR of a lost context transfer data message from old AR. We predict and expect, that this portion of the Nakhjiri Internet Draft - Expires May 2002 10 Internet Draft Time Efficient CT October 2001 protocol will undergo a redesign, once reliability requirements for context transfer are specified. Caveat: The minimum reliability mechanism proposed here assumes that the receivers of context transfer related messages are able to intercept context transfer messages as such (without damaged headers) and only provide reliability for transferred feature context. The checksum mechanisms only protect the context transfer peer ARs from minor corruptions of CT header and payload. (The message details provided in 6.): MN's traffic forwarded through aAR-nAR tunnel | MN decides to change nCoA | MN -CT Request->aAR | aAR ---CT data-------> nAR t aAR NACK time out? NO i aAR <----CT NACK(U)--- nAR m e aAR -----CT update --->nAR | V . . aAR NACK time out? yes aAR ----HReq (lt=0)-->nAR figure 2: context transfer messaging with inbuilt reliability 5.3.1. UDP Checksum activation Of the existing transport mechanisms, both TCP and SCTP provide checksums. Only UDP provides an optional checksum. Hence, instead of adding a context transfer header checksum, we propose that the UDP checksum MUST be activated, in case context transfer messages are carried over UDP. Note: This mechanism would not provide protection against individual feature context corruptions. 5.3.2. CT Header sequence number (optional) In case, context transfer data is transmitted in multiple packets or phases, this sequence number can be used to aid new AR in ordering the packets and detecting lost packets (through observing a gap in sequence numbers). Retransmissions or updates of context data should use the same sequence number. Note: in case, context transfer data consists of a single packet, the new AR will not be able to detect the loss of that packet, Nakhjiri Internet Draft - Expires May 2002 11 Internet Draft Time Efficient CT October 2001 unless MN informs new AR of the imminent context transfer (at the same time as requesting context transfer from aAR). So one should bear in mind, that we are only providing minimum reliability mechanisms due to lack of reliability requirements at this point. 5.3.3. Update flag (U-flag) (optional) The decision of retransmission or update of context data is based on the value of this flag. This flag is transmitted along with the context data packet and context transfer NACK message. If the flag is set, it means prior to consequent transmissions of this context data, the protocol unit for this feature must be consulted to acquire updated context data. If the flag is cleared, the anchor AR can simply retransmit this feature context from its buffers. 5.3.4. Context transfer NACKs (optional) In case the new AR, i.e. the CT peer, receiving context data has determined that it has received an invalid packet or failed to receive an expected packet (based observed gaps in sequence number gaps), it will send a context transfer NACK to the anchor AR, i.e the transmitting end. In case, the NACK is for an entire lost or corrupted packet, only the CT header with type 5 (for CT NACK) is sent without any payload, including the expected sequence number. When the aAR receives this CT NACK message (header only), based on the sequence number, it needs to reconstruct the entire context data it had sent earlier. This means some feature contexts needs to updated consulting the feature unit. In case the new AR needs an update for a specific feature context, a CT NACK payload is constructed as shown in figure 7 along with CT header. The value of Update flag is simply copied from the context data packet to indicate whether a retransmission or an update is required. 5.3.5. NACK timers (optional) Implementing a NACK timer at the anchor AR has the same effect as implementing ACK messages sent by newAR to anchor AR, but a NACK timer saves network bandwidth otherwise wasted on acknowledgements. NACK timer is generic for entire context data, not specific features. The length of NACK timers will depend on RTT, ability of context transfer peers in processing the information and possibly capability of protocol units related to the feature context. Although updates will be sent with different sequence numbers, the ability of the underlying transport protocol to detect duplications in case of retransmissions is also another important factor in choosing the NACK timer value. Hence considerations in choosing length of NACK timer are TBD at this time. 5.4. Security considerations: The security considerations for this protocol are covered in detail in 10. Nakhjiri Internet Draft - Expires May 2002 12 Internet Draft Time Efficient CT October 2001 6. Protocol messaging In a tunneling approach for handover, the compressed traffic is carried through the aAR-nAR bi-directional tunnel, using GRE. The details of this procedure are being worked out in Mobile IP WG [3], and since our main objective is to transfer context data, we avoid going into the details of that procedure. It is possible to piggyback context transfer data and signaling over other traffic related to the MN. That means the context transfer messages would also be sent through the bi-directional tunnel. However, for simplicity, at this point, we suggest using "un-tunneled" standalone packets for context transfer purpose. In case the network is capable of handling different QoS profiles, the context transfer packets should be treated as better than best effort traffic to add robustness to context transfer procedure. Figure 3 shows the proposed the format for context transfer messages. These messages are sent using "regular IP" packet format. Since the reliability and transport layer mechanism for context transfer is not specified yet, we suffice adding a "transport header" in the message format below. The IP header and transport header is then followed by a context transfer header. The context transfer header needs to have a next header type number to be identified by the transport layer. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPsec ESP header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ transport header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT message payload ( only for CT data message) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication field (for ESP) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ figure 3: generic format for context transfer packets. 6.1. IPsec ESP header ESP header (and tail authentication field) is added to provide security protection, as explained in security consideration section (10). Nakhjiri Internet Draft - Expires May 2002 13 Internet Draft Time Efficient CT October 2001 6.2. Context transfer header The context transfer header consists of the common information for all the messages in context transfer protocol, i.e. both data and signaling transfer messages and is as follows (exact field sizes are TBD) 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 |R|P| Length | sequence number (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MN's ID (L2 addresss) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ figure 4: context transfer header Type: Is the context transfer message type and is defined as follows. 0 CT request message 1-2 reserved 3 CT data message 4 reserved 5 CT NACK message (optional) 6 CT abort message 7 --- Flags: R: reserved P: Payload present. Some messages, such as cT request message might not require CT payload, and only a CT header is sufficient, while CT data message will include payload. Length: length of CT message payload. Sequence Number (optional) In case, context transfer data is transmitted in multiple packets or phases, this sequence number can be used to aid new AR in ordering the packets and detecting lost packets (through observing a gap in sequence numbers). Retransmissions or updates of context data should use the same sequence number. Note: in case, context transfer data consists of a single packet, the new AR will not be able to detect the loss of that packet. MN's L2 address: This field identifies the MN to the context transfer peers, i.e. aAR and nAR. Although, aAR is able to recognize the MN based on MN's old CoA or home IP address, newAR might only Nakhjiri Internet Draft - Expires May 2002 14 Internet Draft Time Efficient CT October 2001 be able to recognize MN's L2 address. Hence, We choose MN's L2 address as a mean to identify the MN. 6.3. Context profile types As proposed in [6], we also recognize the need for a simple representation that provides a generic structure, while allowing each feature to define its own context parameters. We define a Feature context Profile Type (FPT) to uniquely identify the type of a feature context, such as a QoS Profile Type (QPT) for Diffserv, or a Compression Profile Type (CPT). 7. Message formats 7.1. CT Request message (MN to aAR) When MN desires a change of anchor AR, MN sends a context transfer request message to aAR using the link to nAR. This message is sent after new CoA acquisition, i.e. when MN is ready to send registration or binding update messages. This message is sent in uncompressed IP packet format with MN's IP address as source address and aAR IP address as the destination address. The MN's IP address is MN's home address in v4 without route optimization and MN's aCoA in v6). Since this source and destination address combination is unique, the IP header in this message cannot be compressed. Note, the context transfer request message is not a sent through the tunnel. The message is constructed using context transfer header with the header type 0 for CT request. No CT payload is necessary for this message. This message is authenticated based on the authentication provided in the ESP header. 7.2. CT data message (aAR to newAR) This message contains actual context data. This message is transmitted in an standalone packet, which is constructed using context transfer header with the header type 3 for CT data message, and the CT payload shown in the following figure. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ context data option 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ context data option 2 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: context transfer data message payload Nakhjiri Internet Draft - Expires May 2002 15 Internet Draft Time Efficient CT October 2001 Each of the context data options are constructed as shown below. Note, the figure only provides the schematic format and not the actual field sizes. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT |N|U| FD length | FCD sq. number (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ microflow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ context data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: context data option (feature context data) Fields: FPT Feature context profile type: Describes the type of feature context, being transferred in the context data option, such as Header compression profile type. The type numbers are TBD. N flag: If set, there would be a next feature context data option present, indicating more context data to follow. If cleared, this is the last feature context data option. U-flag: Retransmit or update flag (optional) Depending on the reliability needs of the context transfer procedure and the reliability needs of the specific feature being transferred the context data option, a U flag is set, or cleared, to show, whether consequent transmissions of this feature context should be updates or retransmissions. This U flag is set/cleared for each context profile type based on the determination of the protocol unit. If the flag is set, it means prior to consequent transmissions of this context data, the protocol unit for this feature must be consulted to acquire updated context data. If the flag is cleared, the anchor AR can simply retransmit this feature context from its buffers. The update messages would be marked with the same feature context sequence numbers. feature data length: The length of feature context data for the specified feature. Feature context data sequence number In case one feature context data is transmitted over several datagrams. This sequence number is initiated at zero between AR and nAR at the start of context transfer procedure. Nakhjiri Internet Draft - Expires May 2002 16 Internet Draft Time Efficient CT October 2001 Depending on the reliability mechanisms, this sequence number can be used in NACKs and retransmissions. For instance, in case the new AR needs an update for a specific feature context, a CT NACK payload is constructed as shown in figure 7 along with CT header. The value of Update flag is simply copied from the context data packet to indicate whether a retransmission or an update is required. Microflow identifier: The definition of micro-flow for context transfer framework is borrowed from RFC 2475, as explained in the context transfer problem statement [4]. Hence the micro-flow is identified by source and destination address, source and destination port and protocol id. Context data: The actual feature protocol states 7.3. Context transfer NACK message (from nAR to aAR) (optional) The reliability and underlying transport protocol requirement for CT are not specified at this point [5]. Hence, the combination of CT NACK messages and U flag is provided as a minimum reliability mechanisms built into the context transfer protocol. As mentioned earlier, the context updates can not be provided by transport protocols, so in case reliability for the transport of a specific feature is needed in forms of updates, the U-flag is set in the context data option for that feature. In case the new AR, i.e. the CT peer, receiving context data has determined that it has received an invalid packet or failed to receive an expected packet (based observed gaps in sequence number gaps), it will send a context transfer NACK to the anchor AR, i.e the transmitting end. In case, the NACK is for an entire lost or corrupted packet, only the CT header with type 5 (for CT NACK) is sent without any payload, including the expected sequence number. When the aAR receives this CT NACK message (header only), based on the sequence number, it needs to reconstruct the entire context data it had sent earlier. This means some feature contexts needs to updated consulting the feature unit. In case the new AR needs an update for a specific feature context, a CT NACK payload is constructed as shown in figure 7 along with CT header. The value of Update flag is simply copied from the context data packet to indicate whether a retransmission or an update is required. The value of micro-flow identifier is simply copied from the context data packet. The message is constructed using context transfer header with the header type 5 for CT NACK message and a payload as shown below: Nakhjiri Internet Draft - Expires May 2002 17 Internet Draft Time Efficient CT October 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT |U| FPT offset | CD sq. number ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ micro-flow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: CT NACK message payload. Note, as mentioned earlier, in case CT data consists of a single packet and that packet is lost, the new AR has no way of knowing about the context transfer in process. This is a trade off based on minimum signaling requirement and uncertain transport mechanisms at the time of this writing. 7.4. CT abort message (nAR to aAR) In case the MN moves to a third AR, while the context transfer signaling (or context data transfer) is in progress, the context transfer should be aborted immediately of two reasons: 1-the context would no longer be needed at the second AR. 2-To avoid the confusion on what AR is the MN's current context anchor AR. Hence, the context would still stay at anchor AR without a need for context transfer, until a newCoA and AR for MN's traffic is identified. CT abort message can be send from nAR to aAR based on the L2 indication on deteriorating MN-nAR link conditions. This is more preferable than having MN send a CT abort message to aAR. The message is constructed using context transfer header with the header type 6 for CT abort and no payload. 8. Compliance with requirements for context transfer In this section we will verify the compliance of the context transfer solution proposed in this document with the requirements for context transfer in [5]. The sections in the requirement document [5] to which, we are verifying compliances are mentioned in parantheses. 8.1. Compliance with general requirements (section 4 of [5]) Trigger Requirements (4.1-4): The MN sends a Context transfer request to aAR in form of a standalone IP message. This message can be seen as an explicit form of layer 3 trigger for context transfer procedure. Nakhjiri Internet Draft - Expires May 2002 18 Internet Draft Time Efficient CT October 2001 Separation of context transfer signaling and data (4.5): According to our proposal, aAR starts the transfer of context data to nAR, after a separate request by MN. This is a natural separation of context transfer signaling and context data transfer. Optional support of one-to-many context transfer (4.6): We propose starting context transfer after L2 handover completion. This removes the inter-dependency of context transfer on next AR discovery procedure. Timing of context transfer relative to handover (4.7): Our proposal removes the context transfer out of the timing critical path for handover and at the same time provides great amount of flexibility in timing of the context transfer operation. Distributed context transfer approach (4.8): Our proposal is based on AR-AR context transfer. Mutual authentication (4.9): Mutual authentication between aAR and nAR is accomplished using IPsec ESP. IP micro-flow as a unit (4.10): using context data options, feature profile types and micro flow identifiers plus the fact that context transfer is started by anchor AR, provide the means to selectively able and disable context transfer for a particle micro-flow. Context availability at ARs (4.12): Having the oldAR to act as anchor AR and context holding AR for MN, complies with this requirement. This is also re-enforced by MN sends the context request to the aAR. Reliability of context (4.13): The details of a minimal reliability procedure are provided in 5.3. This includes a clear distinction between retransmissions and updates, which would not be covered by a transport layer protocol. Inter-working with IETF mobility solutions (4.14): The proposal is highly aligned with the work being done in Mobile IP working group [4]. 8.2. Compliance with protocol requirements (section 5 of [5]) Support for all feature types (5.1.1-5): This proposal supports the usage of feature context profile type (also suggested in [6]), which facilitates the move of various kinds of context and identifying the type of these context data. Having the tunnel open for traffic during context transfer also reduces the chances of incomplete context transfer, before all the context is transferred. Transport requirements (5.2): Checksum fields and NACK messages are provided as optional procedures to provide flexibility in Nakhjiri Internet Draft - Expires May 2002 19 Internet Draft Time Efficient CT October 2001 choice of transport layer protocol and reliability mechanism even before the transport requirements for context transfer are identified Security requirements (5.3.1-3): The security considerations are explained in details in 5.4. Removing the ESP from the context transfer simply achieve the goal of disabling security. Minimum protocol exchanges (5.4.1): The protocol proposed is very lightweight; after a request by the MN at a convenient time to aAR, which holds the context, context is transferred to nAR. After this request, aAR starts transferring the context data. Without reliability procedures, the protocol only involves two messages. Minimum processing at ARs (5.4.2): By holding the context at aAR until the MN changes the new AR, the processing can continue at aAR, which minimizes the need for processing at new AR. It also minimizes the effects of ping-ponging and fast moves to third ARs. Timing constraints for feature types (5.4.3): Using the tunnel to forward MNÆs traffic and giving the MN the flexibility in choosing the timing of context transfer, as well as the update flag, and sending dynamic context data (such as header compression) at the end, provides means of meeting time constraints for various feature types. Context aggregation (5.4.4-5): Using context data options, feature profile types and micro flow identifiers facilitate the aggregation of multiple context data in a natural way. Context synchronization (5.5): By provisioning means for sending updates for specific contexts, as well as sending uncompressed packets after completion of header compression context, the synchronization requirements are met. Inter-working with handover mechanisms (5.6): This proposal is closely tied to the handover mechanisms currently being proposed in Mobile IP WG [3], the context transfer request message is chosen based on the handover events. A list of other possible context transfer trigger (all based on Mobile IP handover mechanisms) is provided in 5.1. 9. IANA considerations Since, CT header follows a known transport header, a next header type for the context transfer header needs to be identified by IANA. This number would be inserted in "next header" field of the transport layer. 10. Security Considerations Our proposal assumes that prior to tunnel establishment between the peer ARs (for traffic forwarding), these ARs are authenticated Nakhjiri Internet Draft - Expires May 2002 20 Internet Draft Time Efficient CT October 2001 to each other. It would be straight forward to say that the context transfer protocol simply uses the same authentication procedures and SAs in order to authenticate the context transfer data message (and CT NACK and CT updates, if applied) between old AR and new AR. This is aligned with [5] that the context transfer peer ARs Must be mutually authenticated to each other, and share appropriate security associations. However, context transfer data might include keying material that needs to be encrypted. For this reason, we suggest that IPsec ESP should be used for protecting context transfer data message (as shown in 4.3). ESP should be used in transport mode, since aAR and nAR context transfer can be considered as an end to end communications, even when aAR and nAR each are acting as security gateways for their own networks (traffic destined to a SG can be protected in transport mode [7]). ESP can also be used for authentication of the CT data message. ESP related SA s must exist between aAR and nAR prior to context transfer signaling. These SA s can either exist permanently or can be established while the tunnel between the peer ARs is being setup to not add extra signaling delay). Our recommendation is that these SA s should be of coarse type, i.e. on per host pair basis, rather than on context transfer session, or MN basis and should exist permanently between the two AR s. In case encryption needs to be disabled, ESP can be used in NULL encryption mode, while authentication is still on. If neither authentication nor encryption is desired, the ESP header needs to be removed completely (or alternatively, one can have a "bypass" grade for the corresponding SA in security policy database, SPD). The CT request message sent by MN to aAR, can be authenticated using the already existing security association between MN and aAR. It is not our intention to discussion the procedure of authentication of MN to nAR, since it is out of the scope of context transfer security provisioning. We will rely on the existing MN's L2 authentication mechanisms to new AP/ AR, until MN is ready for L3 registration and authentication. 11. Acknowledgments We are grateful to numerous colleagues for discussions on the topics covered in this paper, in particular (with apologies to anybody we've missed): Mike Needham, Narayanan Venkitaraman, Lily Chen and Alexandru Petrescu. 12. References Nakhjiri Internet Draft - Expires May 2002 21 Internet Draft Time Efficient CT October 2001 [1] D. Johnson, C. Perkins, Mobility Support in IPv6 Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip- ipv6-13.txt [2] G. Dommety et al, "Fast Handovers for Mobile IPv6", Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip- fast-mipv6-02.txt, July 2001 [3] James Kempf et al., "Bi-directional Edge Tunnel Handover for IPv6", Internet Draft, Internet Engineering Task Force, draft-kempf-beth-ipv6-00.txt, June 2001 [4]H. Levkowetz et al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network ", Internet Draft, Internet Engineering Task Force, draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001. [5] H. Syed et al., "General Requirements for Context Transfer", Internet Draft, Internet Engineering Task Force, draft-ietf- seamoby-ct-reqs-00.txt, September 2001 [6] R Koodli, C.E. Perkins, A Context Transfer Framework for Seamless Mobility, Internet Draft, Internet Engineering Task Force, draft-koodli-seamoby-ctv6-01.txt, July 2001. [7] S. Kent et al., ææSecurity Architecture for the Internet ProtocolÆÆ RFC-2401, November 1998. 13. Contact Information Madjid Nakhjiri Motorola Inc. 1421 West Shure Drive, Mail Drop IL27, 2D5 Arlington Heights, IL 60004 Phone: 847-632-5030 Email: Madjid.Nakhjiri@motorola.com Ajoy Singh Motorola Inc. 1421 West Shure Drive, Arlington Heights, IL 60004 Phone: 847-632-6941 Email: asingh1@email.mot.com Nakhjiri Internet Draft - Expires May 2002 22