Internet Draft Madjid Nakhjiri draft-nakhjiri-seamoby-text-ct-02.txt Motorola Inc. Category: Internet draft March 2003 Expires: September 2003 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 that allows completion of context transfer outside timing critical message sequence for handover. The context transfer process is initiated at a moment of MNÆs choice (in regard to layer 2 and 3 handover and MNÆs traffic) and is completed without a disruption in the flow of MNÆs real time traffic. This proposal is in line with the current fast handover framework within Mobile IP WG [3]. A selective reliability mechanism (using UDP transport) for ensuring quality of transferred context depending on the type of context being transferred is provided. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................1 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. Terminology....................................................4 4. Protocol overview..............................................4 4.1. Message flow.................................................5 4.2. Advantages...................................................6 Nakhjiri draft-nakhjiri-seamoby-text-ct-02.txt 1 Internet Draft Time Efficient CT March 2003 5. Protocol messaging format......................................7 5.1. IP header....................................................8 5.2. Transport header.............................................8 5.3. IPsec ESP header (optional)..................................8 5.4. Context transfer header......................................8 6. Message formats................................................9 6.1. CT Start Request message (MN to aAR).........................9 6.2. CT data message (aAR to newAR)...............................9 6.3. Context Transfer header option..............................10 6.4. CT PNACK message (from nAR to aAR) (optional)...............12 6.5. CT FNACK message (from nAR to aAR) (optional)...............13 6.6. CT abort message (nAR to aAR)...............................13 6.7. CT Feature abort message (nAR to aAR) (optional)............14 7. Transport and Reliability considerations......................14 7.1. Overview of reliability mechanism...........................15 7.2. Message flow for reliable TEXT..............................15 8. Robustness considerations.....................................16 9. Security Considerations.......................................16 10. Compliance with requirements for context transfer...........17 10.1. Compliance with general requirements (section 4 of [5])...17 10.2. Compliance with protocol requirements (section 5 of [5])..18 11. IANA considerations.........................................19 12. Acknowledgments.............................................20 13. References..................................................20 14. Contact Information.........................................20 Appendix A- Context transfer start................................21 Appendix B- Robustness considerations.............................22 1. Introduction Low bandwidth in many access networks generally imposes a limit on the amount of signaling that can be done over the air during a handover. Large amounts of signaling over a low bandwidth link translate to a long delay associated with completion of handover signaling. If the flow of mobileÆs traffic must be disrupted during the signaling period, packet loss and ultimately service disruption or failure may result. The basic Mobile IP solutions (such as [1]) introduce a disruption in traffic flow, since layer 3 handover signaling is in the timing critical path and must be completed before MN can have service at the new location. Furthermore, applications running at MN may also require continuous support for various features such as security, QoS, etc, after (and maybe during) handovers. Re-establishment of the states for these features is a necessary process for continued service after handover. This is however time consuming and can add to latency perceived by user. Context transfer is a process by which the old AR will transmit the feature context related to the MN to the new AR to reduce the need for over the air signaling in conjunction with feature re-establishment [4]. If done properly, the delay associated with feature re-establishment may not affect the length of service disruption period [5]. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 2 Internet Draft Time Efficient CT March 2003 A great deal of effort within Mobile IP WG has been focused on minimizing the delay associated with registration and change of routing information. This is done by allowing layer 3 handover signaling to continue in concurrence with other handover related events [2], [8]. Recently a solution for Mobile IP handover, named Bi-directional Edge Tunnel Handover (BETH) has been proposed (in [3] and later in fast Mobile IP post-registration process [8]), which allows the MN to continue its real time traffic through a tunnel from the old AR to new AR, until the MN chooses to engage in L3 handover (acquisition of new CoA from new AR). The new AR forwards the traffic to MN without having intimate knowledge about MNÆs service and routing information. MNÆs registration with newAR is postponed to MN's earliest convenience. However, this solution only removes the latency involved in establishing L3 routing out of the handover critical path; any delay associated with feature re-establishments may still introduce service disruption. The context transfer solution proposed here (TEXT) builds on top of BETH [3] and seeks to also 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 context anchor AR, caAR, 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 (context anchor AR) is in charge of processing MNÆs features. 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 and acts as context anchor AR. 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 does not need to happen through the tunnel. However, the tunnel for the data traffic MUST stay in place until completion of critical context transfer. The proposal also provisions for context transfer failures. 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 the transport issues and describes an overview of the checksums used for reliability purposes. Section 8 describes the robustness consideration. Section 9 goes through security consideration. Section 10 provides verifications for the compliance of the proposed solution with context transfer requirements. Section 11 discusses IANA considerations. Finally several Appendixes provide additional alternatives for context transfer initiation, Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 3 Internet Draft Time Efficient CT March 2003 considerations in the design as well as an extension to the TEXT for reliable context transfer. 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, which holds MN's context. Anchor AR is in most of cases 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 to 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. 4. Protocol overview Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 4 Internet Draft Time Efficient CT March 2003 The motivation for this proposal is to eliminate the context transfer delay from the timing critical path of network layer handover. It is developed based on the same philosophy as that in fast Mobile IP post-registration process [8](or BETH [3] to be specific), namely: to continue forwarding MNÆs traffic through a bi-directional tunnel between old AR and new AR as soon as the MN establishes an L2 connection with the newAR. The tunnel stays in place until the MN can use newAR as its default router to forward MNÆs traffic. In the same manner, we propose to start and complete transfer of critical context while MN is receiving its data traffic through the tunnel via newAR. During that time, the new AR simply tunnels MNÆs traffic without having looked into the details of the features associated with the MN. The old AR handles MNÆs feature processing and their associated context, i.e. acts as a context anchor (CaAR) for as long as the tunnel between newAR and oldAR is in place. This way, the MN not only can receive its data, but also has its feature services processed at the oldAR without disruption. Once the context transfer for each feature is considered complete (transfer reliability needs may vary), the new AR simply takes over processing of that service feature for the MN. The context transfer needs not to happen through the tunnel. However, for the following reasons the bi-directional tunnel for the data traffic MUST stay in place until completion of a transfer of MNÆs critical context (this is elaborated on in Appendix B). This provides the natural mechanism for application continuity as well as synchronization of time sensitive context information such as header compression states. 4.1. Message flow The following steps describe the proposed context transfer procedure: 1-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 proper trigger for context transfer arrives. -During this period the MN's context resides at anchor AR, which is also context anchor AR. The new AR continues to forward the traffic between MN and aAR (also CaAR), without looking into the details of the features associated with the new users. 2-The context transfer trigger arrives at context transfer initiating element. We provide a list of viable options for context transfer triggers and starting elements in the appendix A. For now, we choose the moment when MN is ready to send a BU to aAR (through BETH) as a trigger for context transfer, since Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 5 Internet Draft Time Efficient CT March 2003 we assume the tunnel would be up long enough for the context transfer to complete. Some other trigger alternatives are presented in appendix A (such as MN acquisition of nCoA, or start signaling for nCoA acquisition) 3-We prefer the context transfer to be initiated by MN. I.e. after receiving the context transfer trigger, the MN will send an authenticated context transfer start request to aAR showing that is ready to change its anchor AR from oldAR to newAR. 4-Upon receiving and authenticating context transfer start request, the context anchor AR starts the context transfer procedure through standalone (not tunneled) context transfer data packets. 5-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 7. 6-The time critical context (scenario dependent: context necessary for newAR to start acting as MNÆs access node) should be transmitted while bi-directional tunnel is still up. As soon as transfer of a feature context is complete, the aAR stops processing of that feature for MN, i.e. stops acting as context anchor AR for that feature. Note, at this stage if the traffic is still going through the tunnel, the oldAR still acts as aAR (for routing) and CaAR for context that is not transferred yet, while the newAR acts as CaAR for context that is already transmitted. 7-Once the newAR has installed MNÆs critical context, the new AR will handle feature support for MN's traffic. Note that if necessary, the transfer of static non-critical context (such as accounting context) can be done at later stage (not show in the figure). 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 transferring userÆs data stays in place while context transfer is in process, the context transfer does not impose any service disruptions. Furthermore, this provides a great amount of flexibility in the timing of trigger as well as phasing of context transfer for various contexts. 2-By keeping a context anchor AR until after a change of default router (change of CoA) by MN, the method is less sensitive to fast moving mobiles and ping-ponging between pairs of ARs. For the same reason, it reduces network traffic load due to premature context transfers. In case MN moves to a third Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 6 Internet Draft Time Efficient CT March 2003 AR before changing its CoA, the aAR simply tears the wireless end of tunnel to oAR (AR2) down and sets 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. 3-The MN determines based on its traffic load, when to change context anchor AR. Also by allowing different elements to request context transfer initiation, it accommodates 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, and after that the newAR takes over as context anchor. This way, the chances for context mis-synchronization and stale contexts are greatly reduced. 6-Failure scenarios for context transfer are considered through the use of CT abort and CT feature abort messages. 5. Protocol messaging format In a tunneling approach for handover, the compressed traffic is carried through the aAR-nAR bi-directional tunnel, using GRE (Generic routing encapsulation). 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 also possible to piggyback context transfer data and signaling over other IP 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 standalone packets for context transfer. Figure 3 shows the proposed the format for context transfer messages. 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 (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT header option (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 7 Internet Draft Time Efficient CT March 2003 ~ CT message payload (only for CT data message) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication field (for ESP) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: generic format for context transfer packets. 5.1. IP header Context data is sent using "regular IP" packet format (uncompressed). In case the traffic in the network is marked in the IP header based on QoS profiles, the IP packets carrying context packets should be marked with better than best effort marking to add robustness to context transfer procedure. 5.2. Transport header In order to be independent of transport layer protocol for context transfer, we suffice adding a "transport header" in the message format below. The transport header needs to include a next header type that corresponds to context transfer header that follows (see IANA considerations). 5.3. IPSec ESP header (optional) In case encryption and/or payload authentication is required for context transfer, an ESP header (and tail authentication field) is added to provide security protection, as explained in security consideration section. 5.4. 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| | Length ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MN's ID (L2 address) (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: context transfer header (CT header) Type: Is the context transfer message type and is defined as follows. 0 CT start request message 1-2 reserved 3 CT data message 4 reserved 5 CT PNACK message (optional) 6 CT FNACK message (optional) Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 8 Internet Draft Time Efficient CT March 2003 7 CT abort message 8 CT Feature abort message (optional) 9- reserved Flags: R: Reliability-Required Flag In case a context transfer message (data or NACK) includes feature(s) that require reliability mechanisms, this flag is set. Length: Length of CT message payload (0 if none present). MN's L2 address (optional): If the MN may have not completed new CoA acquisition, it can only be recognized through its old CoA, home IP address, or layer 2 address. This field is an optional field, which may be of limited use to aAR (in case the aAR and nAR use different layer 2 technologies). 6. Message formats 6.1. CT Start Request message (MN to aAR) In order to start context transfer MN sends a context transfer start request message to aAR using the link to nAR. This message is sent after receiving a CT trigger. This message is sent in uncompressed IP (since the message is going to aAR as opposed to CN, the headers are unique and shouldnÆt be compressed). Note: the context transfer start request message needs to be reverse tunneled (as specified in BETH), to avoid ingress filtering and to provide L3 authentication with aAR. Other packet fields as follows: IP Source address: MN's home IP address (v4, No route optimization) MN's aCoA (v6) IP destination address: aAR IP address CT header: type 0 for CT request. CT payload: None ESP header: Only Authentication (if required). 6.2. CT data message (aAR to newAR) The header for this message is the context transfer header as described earlier with the header type 3 for CT data message. This message also contains a CT header option (in case reliable CT is required) as described in 6.3. The payload contains context data in form of context data options (one per feature) as shown below. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 9 Internet Draft Time Efficient CT March 2003 An overview of how the checksums are used to provide reliability is provided in 7.1. 6.3. Context Transfer header option The header option is only used for CT data message before the payloads (as explained shortly). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTDSN | CL (optional) | Checksum (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT1 | FPT2 | . . . | FPTn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT data option 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT data option N ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: context transfer data message payload CTDSN (CT data sequence number) 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 CT data packets should use the same sequence number as the original. CL: Checksum length Checksum length. Shows the total number of bytes from the beginning of CT header over which the checksum (explained below) will be calculated. In case reliability is not deployed, this field will be null. Checksum In case a reliable context transfer is in process, i.e. the CT data message is carrying features that require reliability (R flags is set in the header), a checksum will be calculated over the CT header and CT header option (as explained in the appendix in details). This field will be null in case unreliable CT is in process. FPTi The feature profile type corresponding to i-th CT data option carried the payload of CT data message. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 10 Internet Draft Time Efficient CT March 2003 Each of the context data options is constructed as shown below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ micro flow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FPT |R|N|U| FSN | FDL ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FDGN (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Feature Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... | FDC ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: CT data option (feature context data). Note: the figure only provides the schematic format and not the actual field sizes. Fields: Micro flow 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. FPT Feature context profile type: Describes the type of feature context, being transferred in the context data option, such as Header compression profile type, or QoS profile type. The type numbers are TBD (possibly defined by IANA in the future). R-flag: Reliability-required flag (optional) If set, the specific feature contained in the option, requires reliability and cleared otherwise. N flag: Next feature 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: Update flag (optional) This flag is only processed if R-flag in CT header is set. A set U-flag for the context data option means updates and not retransmissions need to be transmitted, in case aAR receives a NACK. For updates, the aAR must consult the feature unit to acquire updated context data. For retransmission (cleared U-flag), the anchor AR simply retransmits the feature context from its buffers. The update messages would be marked with the same feature context sequence numbers. FDL: Feature data length The length of context data for the specified feature. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 11 Internet Draft Time Efficient CT March 2003 FSN: Feature data sequence number Used 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 for each feature. Both feature context updates and retransmissions use the same sequence number as the original data packet. Feature Data Generation Number (optional) In case the feature requires reliability (R-flag in CT header is set) and creates dynamic context, which means updates as opposed to retransmissions are required in case of transmission failure (U-flag is set), it is important that the newAR uses the latest version of the data. The use of time stamps is discouraged due possible clock mismatch between ARs. Hence, if the U-flag for update is set, every time the transmitter sends a new updates regarding a feature, the generation number included in the feature data option is increased by one (starting with zero in the first transmission). Feature Data: The actual feature context (protocol states) FDC: Feature Data Checksum (optional) In case the reliability is supported and the feature, which the CT data option pertains to, requires reliability, this checksum should be calculated by the feature-processing unit and sent as part of context data option transmitted by oldAR. This however assumes that the checksum within the CT header option has been successfully verified, so the receiver knows what options have been corrupted. 6.4. CT PNACK message (from nAR to aAR) (optional) The message indicates one or more missing CT data packets. It is sent by the new AR, when newAR recognizes, based on gap in CT header sequence numbers that some CT data packets are missing. The newAR then sends a CT PNACK (packet NACK) message (type 5 for CT PNACK). The CT header in this includes the Seq. No of the first expected (but missed) CT packet. The payload for the CT NACK message in this case is as follows +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ micro flow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Seq. No+1 |Seq. No.+2 | ... |Seq. No+M-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: CT PNACK message payload. The payload shows an example where M packets are missing. Loss of single-packet CT data or loss of last CT data packet cannot be detected, unless dummy packets are sent after the last Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 12 Internet Draft Time Efficient CT March 2003 CT data packet (The dummy packet could simply include the CT header of the last CT data packet). PNACK timers (optional) Implementing a PNACK timer at the anchor AR has the same effect as implementing ACK messages sent by newAR to anchor AR, but a PNACK timer saves network bandwidth otherwise wasted on acknowledgements. For simplicity, PNACK timer is generic for entire context data, not specific features. The length of PNACK timers will depend on RTT, and ability of context transfer peers and protocol units in processing the information. Adding time stamps to updates will make CT invulnerable to UDPÆs inability to detect duplicate packets. Transport independency Note that, in case TCP is to be used with TEXT, the PNACKs can simply be removed (loss of entire packets will be captured by TCP). However, FNACKs should still be performed, especially if some features require updates. 6.5. CT FNACK message (from nAR to aAR) (optional) The message indicates a received CT data packet with missing feature context (CT data options). When the newAR has received a CT data packet, but based on the included FDC (feature data checksum) in the CT data option, recognizes that some of feature contexts (CT data options) are missing, a CT FNACK (feature NACK) is sent. CT FNACK payload is constructed with one payload Blob per missing feature as shown in figure 7. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ micro flow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FPT | | |U| FSN | NULL ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: CT FNACK message payload Blob (For field descriptions see CT data options). 6.6. CT abort message (nAR to aAR) The context transfer should be aborted immediately in two cases: -In case the MN moves to a third AR, while the context transfer signaling is in progress. -Un-necessary context: In case the newAR determines it no longer needs the context residing at aAR (e.g. because MN started negotiating the context with newAR directly). In either case, the newAR would send a CT abort message to the oldAR and 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 Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 13 Internet Draft Time Efficient CT March 2003 preferable than having MN send a CT abort message to aAR. The message is constructed using context transfer header with the header type 7 for CT abort. No payload is sent in the first case above. A payload indicating the unnecessary context is added for the second case. 6.7. CT Feature abort message (nAR to aAR) (optional) This message is used in case the transfer of a feature is considered to be failing, or the new AR has started negotiating the feature with the MN directly. In case the newAR determines that several requests for retransmissions have failed or the MN started negotiating the feature context with newAR directly, newAR can abort the transfer of the context for that feature. In this case the newAR would send a CT feature abort message with a CT abort payload to the CaAR. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ micro flow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT reserved ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: CT feature abort message payload. 7. Transport and Reliability considerations Complicated transport mechanisms such as congestion control or flow control provided by TCP and SCTP are less important for context transfer, due to its transient nature. Other mechanisms such as duplicate detection or ordering of packets can also be easily handled by the context transfer peers. However, in case the context transfer must be performed reliably, lost packets need to be detected. It is widely accepted that, the transfer of different feature contexts and within different scenarios may require different degrees of reliability. It is decided that the context transfer protocol design needs to be defined independent of the underlying transport mechanism and that the reliability is not a mandatory requirement. Hence this section explains an overview of the selective reliability mechanism that provides the flexibility to send context data with different reliability requirement within the same message. TCP and SCTP use Acknowledgements to detect transmission losses, while UDP does not provides ACKs at all. Regardless of whether the ACKs are provided by the transport layer (such as in TCP) or not (UDP), it is important to note the following: NOTE: A transport protocol can only provide retransmission of data. Some features have dynamic contexts, i.e. states will change due to transmission or lapsed time. In case the transmission of such contexts fails, simply retransmitting Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 14 Internet Draft Time Efficient CT March 2003 the previously transmitted feature context may lead to context mis-synchronization. In such cases, the feature unit must do a context update transmission rather than a retransmission. The underlying transport mechanisms would only be able to handle retransmissions and not updates. This means, the ability to send context updates must be embedded in the context transfer protocol and its interface with transport protocol. Hence, in this section, we provide a reliability mechanism adapted to work with UDP. This reliability mechanism can easily be turned off by clearing the reliability-required flag (R flag) in the CT header. It is quasi-reliable since it only provides minimum reliability, since it is NACK based (Since CT is transported over UDP and the reliability is NACK based, in case a packet with indistinguishable UDP header arrives, no retransmissions are triggered). In case additional reliability is needed, the NACK method can easily be converted to an ACK method. 7.1. Overview of reliability mechanism First of all, we have to assume that both CaAR and nAR support reliability mechanisms. Second, the CaAR based on the reliability needs of the context data it is transmitting needs to set or clear the R (Reliability-Required) Flag in CT header. Third, UDP provides an optional checksum. In order to use the selective reliability mechanism provided by CT header option and the feature checksums, the UDP checksum MUST be de- activated. This way, errors in parts of the CT payload of a CT data message would not lead the message being dropped. This is especially useful, if the payload in error did not even require reliability. Forth, when some feature data must be handled reliably, in the CT header option, a checksum in calculated over the CT header as well as a list of FPTs that are to be included in the CT data payload. This way, the nAR will know what FPTs it should expect in the CT data payload. In case it has not received any those FPT or the included individual feature data checksum (FDC) fails, it would act according to the reliability mechanism for that feature, ask for retransmission, update (Update flag set) or simply discard (R-flag with the data option). 7.2. Message flow for reliable TEXT In the following we will explain various elements of a reliable TEXT over UDP. All the message details are provided in 6 | MN nAR CaAR T | | ==== MNÆs data=========. | I CT trigger | | Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 15 Internet Draft Time Efficient CT March 2003 M | -CT Start Req-----.| =======================. | E | | | | | | <-----CT Data----------- | V | | PNACK time out? | | NO | | ----CT NACK(U=1/0)----. | | | .---CT Data(Update/Retx) | | | PNACK time out? | | Yes | | | Figure 5: context transfer messaging with minimum reliability 8. Robustness considerations A robust transfer of context needs to -avoid mis-synchronization of context at old and new AR by coordinating context transfer with other handover events. -Accommodate eventual large context packets. -Accommodate transfer of different contexts at different times, such as sending critical context first and non-critical context later. -Provision for context transfer failures. More discussion is provided in Appendix B of this document. 9. Security Considerations Our proposal assumes that prior to tunnel establishment between the peer ARs (for traffic forwarding), these ARs are authenticated to each other. It would be straightforward to say that the context transfer protocol simply uses the same authentication procedures and security associations (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 on MN basis, and should exist permanently between the two ARs. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 16 Internet Draft Time Efficient CT March 2003 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). It is advised that security related context is transmitted in encrypted form, while other context may not require encryption. In case IPSec is used for encryption, different transport port numbers may need to be defined for the security policy to be able to handle outbound packets properly 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 discuss 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. When authentication, authorization or other security actions are required at the newAR prior to establishing the newAR as default router for the MN, and context transfer for such actions is planned, the oldAR must remain as feature anchor until the context is transferred to the newAR. 10. 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 parentheses. 10.1. Compliance with general requirements (section 4 of [5]) Trigger and start Requirements (4.1-5): The MN sends a Context transfer start request to aAR in form of a standalone IP message. This message is sent based on layer 3 triggers that are explicitly defined (binding update or registration requests from MN). This message is clearly separated from the transfer of context itself. 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, which makes one-to-many context transfer unnecessary. Since the start request is made to the aAR, if one to many CT is still required, it can be easily accommodated. Timing of context transfer relative to handover (4.7): Our proposal removes the context transfer out of the timing critical signal sequence for handover and at the same time provides great Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 17 Internet Draft Time Efficient CT March 2003 amount of flexibility in timing of the context transfer operation. Many suggestions for triggers are provided in Appendix A. 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 particular micro-flow. Multiphase context transfer (4.11) is supported through definition of context data options. 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 sending the context request to the aAR. Inter-working with IETF mobility solutions (4.13): The proposal is highly aligned with the work being done in Mobile IP working group [4]. Inter-working with non-IETF mobility solutions (4.14): The variety of alternatives triggers and start procedure proposed in Appendix, as well as the ability of tunneling data traffic in many network standards makes this proposal suited for many mobility protocols. 10.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 the identifying of the type of these context data. Having the tunnel open for traffic during context transfer also reduces the chances of incomplete context transfer, before the entire context is transferred. Transport independence (5.2): The optional reliability mechanisms that can be turned off/on based on flags provide independence of transport. 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 Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 18 Internet Draft Time Efficient CT March 2003 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. Also it provides CT abort mechanisms, in case CT is deemed to be unnecessary. 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, provisioning of dynamic context handling (such as header compression), optional updates, as well as CT abort and CT feature abort 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 facilitates the aggregation of multiple context data in a natural way. Feature Context synchronization (5.5.2, 5.5.4): CT data options that include reliability related flags and checksums are defined for each feature. CT FNACK message is able to NACK individual features. CT feature abort provides means of stopping retransmission of individual features. All these mechanisms are designed to meet this requirement. Additionally means to specify update versus retransmission requests by the receiver are embedded. Feature context update (5.5.3): Introducing the concept of context anchor AR and moving the anchor after completion of transfer, the need for updates after context transfer is moot. Other mechanisms such as sending uncompressed packets after completion of header compression context also support this requirement. 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 triggers (all based on Mobile IP handover mechanisms) is provided in 5.1. Interaction with handover (5.6.2): The triggers and transfer mechanisms are closely aligned with low latency Mobile IP mechanisms. 11. IANA considerations Since, CT header follows a known transport header, a next header type for the context transfer header needs to be identified by Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 19 Internet Draft Time Efficient CT March 2003 IANA. This number would be inserted in "next header" field of the transport layer. It is advised that security related context is transmitted in encrypted form, while other context may not require encryption. In case IPSec is used for encryption, different transport port numbers may need to be defined for the security policy to be able to handle outbound packets properly 12. 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): Ajoy Singh, Mike Needham, Narayanan Venkitaraman, Lily Chen, Christophe Janneteau and Alexandru Petrescu. 13. References [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] J. kempfs et al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network ", RFC 3374, Internet Engineering Task Force, rfc3374.txt, May 2001. [5] G. Kenward et al., "General Requirements for Context Transfer", Internet Draft, Internet Engineering Task Force, draft- ietf-seamoby-ct-reqs-04.txt, September 2002. [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. [8] K. El Malki et. Al, ææLow Latency Handoffs in Mobile IPv4ÆÆ, Internet Draft, Internet Engineering Task Force, draft-oetf- mobileip-lowlatency-handoffs-v4-04.txt, June 2002. 14. Contact Information Madjid Nakhjiri Motorola Inc. 1301 E. Algonquin Rd. Room 2246 Schaumburg, IL 60196 Phone: 847-632-5030 Email: Madjid.Nakhjiri@motorola.com Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 20 Internet Draft Time Efficient CT March 2003 Appendix A- Context transfer start Context transfer start triggers As explained earlier, for the newAR to become MNÆs default router and process MNÆs feature, the MN must have acquired a new CoA from newAR and the newAR needs to install the MN's critical context 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 start trigger. Below is a list several that events can be chosen as CT triggers: -L2 link Up to new AR (AP) -Establishment of BETH. -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). Context transfer starting element The framework in this paper provides a great amount of flexibility in choosing the starting event and element. Depending on the unit receiving the context transfer trigger (explained earlier), or depending on desired type of control for context transfer, there are several options for context transfer start: 1-Network Initiated context transfer: the context transfer starts by a start request from either oldAR or newAR (depending on which unit receives the context transfer trigger). The advantage of this approach is its security, i.e. as long as the two ARs trust each other and can uniquely identify the mobile, this process can start. 1a) Old AR initiated context transfer (source initiated based on a source trigger to old AR, such as BU): In case the oldAR starts the transfer, it could simply push the context packets towards the newAR without emitting a separate start message. This however, means that the newAR must be ready to accept the context data at any time. Alternatively the oldAR can send a ææcontext transfer start notificationÆÆ message and wait for a ææcontext transfer start respondÆÆ before starting the transfer. Note that the latter two messages are not defined in this document. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 21 Internet Draft Time Efficient CT March 2003 1b) NewAR initiated context transfer (target initiated): In case the newAR receives the context transfer trigger such as an NA (neighbor advertisement), it needs to send a context transfer start request message to the oldAR, which in turns responds by starting the context transfer. Note: this alternative may render one-to-many context transfer difficult, if not impossible. 2) Mobile initiated context transfer: The command to start context transfer (context transfer start request) can be issued by MN. The command can either be sent to the newAR or to the oldAR. In case the MN sends the request to newAR, the assumption is that the MN has established L2 security (authentication and possibly encryption) with the newAR. This assumption also might restrict the timing of the context transfer trigger (in case the trigger is transmitted by the MN to newAR). After the newAR receives the request may relay this message to aAR, or regenerate a context transfer start request as described in 1b) above and send it to aAR. In case the MN sends the context transfer start request to oldAR, (in case nAR conducts ingress filtering, the MN-aAR needs to go through a reverse tunnel aAR), it bears only authentication credentials for aAR, without authenticating to nAR. The requirements for L2 security between MN and nAR can be looser for this case. MN sends this message after one of the event triggers described earlier. Appendix B- 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. -Context data in multiple packets might be necessary in case the amount of context data packets is larger than that accommodated by path MTU and maximum segment size. -Different feature context data may have significantly different lifetimes 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. - Tunnel tear down: The context transfer needs not to happen through the tunnel. However, for some feature with highly dynamic context (such as header compression and packet count), care must be taken so that the flow of real time traffic will Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 22 Internet Draft Time Efficient CT March 2003 not render the already transmitted states invalid. Hence, to avoid state inconsistency, once such highly dynamic states are transmitted, the newAR Must immediately start acting as CaAR. For instance in case of header compression, the old AR (routing anchor prior to tunnel tear down) may stop transmitting compressed packets to the MN through the tunnel, i.e. transmit the remainder of the traffic in uncompressed format. -Handover to the third AR, CT abort: In case the MN moves to a third AR, while the context transfer signaling is in progress, the context transfer should be aborted (using CT abort message) immediately to avoid the confusion on what AR is the MN's current context anchor AR. -Unnecessary CT: In case the newAR determines it no longer needs the context residing at aAR, MN started negotiating the context with newAR directly. In this case the newAR would send a CT Feature abort message to the oldAR. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 23