Internet Draft Madjid Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt Motorola Inc. Category: Internet draft September 2002 Expires: April 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]. Although this document provides a specific recommendation, the framework proposed here, along with multiple alternatives that are mentioned, provides a great amount of flexibility in detailed design of context transfer. A minimum reliability mechanism for ensuring quality of transferred context is added to provide context updates that cannot be achieved by any transport protocol. 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 Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 1 Internet Draft Time Efficient CT September 2002 4. Protocol overview............................................4 4.1. Message flow................................................5 4.2. Advantages..................................................6 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).......................10 6.2. CT data message (aAR to newAR).............................10 6.3. CT PNACK message (from nAR to aAR) (optional)..............12 6.4. CT FNACK message (from nAR to aAR) (optional)..............12 6.5. CT abort message (nAR to aAR)..............................12 6.6. CT Feature abort message (nAR to aAR) (optional)...........13 7. Compliance with requirements for context transfer...........13 7.1. Compliance with general requirements (section 4 of [5])... 13 7.2. Compliance with protocol requirements (section 5 of [5]).. 14 8. IANA considerations.........................................15 9. Robustness and Reliability considerations:..................15 10. Security Considerations.....................................16 11. Acknowledgments.............................................17 12. References..................................................17 13. Contact Information.........................................17 Appendix A- Context transfer start...............................18 Appendix B- Quasi-Reliable TEXT (optional).......................19 Appendix C- Robustness considerations............................23 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 translates 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 September 2002 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 IANA considerations. Section 8 provides verifications for the compliance of the proposed solution with context transfer requirements. Finally several Appendixes provide additional alternatives for context transfer initiation, considerations in the design as well as an extension to the TEXT for reliable context transfer. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 3 Internet Draft Time Efficient CT September 2002 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 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 Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 4 Internet Draft Time Efficient CT September 2002 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 an 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 C). 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 (the trigger could be when MN has acquired a nCoA, or knows a change of nCoA is imminent (the choice of triggers is discussed in detail later). -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 we assume the tunnel would be up long enough for the context Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 5 Internet Draft Time Efficient CT September 2002 transfer to complete. Some other trigger alternatives are presented in appendix A. We also choose the context transfer to be initiated by MN. 3-Once the context transfer trigger has arrived at MN (MN is ready to send a binding update or a registration request to aAR), 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 Appendix B. 6-The 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 (more in 5.4 and 5.5). 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 stays in place, until context transfer is complete, the context transfer itself does not impose any service disruptions. Hence, context transfer can be done regardless of exact timing of handover messages. This provides a great amount of flexibility in choosing the timing (trigger) and control of context transfer (a number of trigger alternatives is provided in appendix A). 2-By keeping a context anchor AR until after a change of default router (change of CoA) by MN, the method is less Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 6 Internet Draft Time Efficient CT September 2002 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 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. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 7 Internet Draft Time Efficient CT September 2002 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 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 (10). 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 |S|R|N| Seq. No | Length ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MN's ID (L2 address) (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: context transfer header (CT header) Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 8 Internet Draft Time Efficient CT September 2002 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) 7 CT abort message 8 CT Feature abort message (optional) 9- reserved Flags: S: Reliability-Supported Flag: In case the reliability mechanisms are supported by oldAR or new AR, this flag is set by that AR, otherwise it is cleared. If this flag is cleared, none of R- and N- flags in the CT header and none of reliability related flags in the context transfer data options are processed. R: Reliability-Required Flag In case a context transfer message (data or NACK) includes feature(s) that require reliability mechanisms, and S-flag in CT header is set, this flag is set. N: New or retransmitted The On-set of this flag indicates that a message is being sent for the first time. Clearing the flag means the message includes one or more feature context retransmissions or updates. Also if the entire message is being retransmitted, the flag is cleared. Seq. No: 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). The sequence number for the first CT data packet is zero. Retransmissions or updates of context data should use the same sequence number. Length: Length of CT message payload. 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 Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 9 Internet Draft Time Efficient CT September 2002 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. The payload contains context data in form of context data options (one per feature) as shown below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT data option 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CT data option N ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: context transfer data message payload Each of the context data options is constructed as shown below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ microflow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FPT |R|N|U| FSN | FDL ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FCD timestamp(optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Feature Context data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... | FDC ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: CT data option (feature context data). Note: the figure only provides the schematic format and not the actual field sizes. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 10 Internet Draft Time Efficient CT September 2002 Fields: 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. 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. Note, this flag is only processed by the ARs, if the AR supports reliability mechanisms (S-flag in the CT header). 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. 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 context data time stamp (optional) This is added only in case reliability is supported (R-flag in CT header is set). As opposed to retransmissions, in case of updates, sequence numbering of feature context is not enough. For updates it is important that the newAR uses the Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 11 Internet Draft Time Efficient CT September 2002 latest sent update over the original packet or previous updates that may arrive later. Hence, if the U-flag for update is set, a time stamp must be added to the feature context data payload. Feature Context data: The actual feature 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. 6.3. CT PNACK message (from nAR to aAR) (optional) The message indicates one or more missing CT data packets. This message is only sent or processed in case the reliability mechanism is supported, i.e. S-flag in CT header is set. The details are specified in the appendix B. 6.4. CT FNACK message (from nAR to aAR) (optional) The message indicates a received CT data packet with missing feature context (CT data options). This message is only sent or processed in case the reliability mechanism is supported, i.e. S- flag in CT header is set. The details are specified in the appendix B. 6.5. 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 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. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 12 Internet Draft Time Efficient CT September 2002 6.6. 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. This message is a reliability related message and only supported if reliability mechanisms are supported (S-flag in CT header and R-flag in CT data option). See Appendix B for more details. 7. 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. 7.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 amount of flexibility in timing of the context transfer operation. Many suggestion 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. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 13 Internet Draft Time Efficient CT September 2002 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. 7.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 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. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 14 Internet Draft Time Efficient CT September 2002 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. 8. 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. 9. Robustness and Reliability 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. Most of these issues are resolved either in protocol overview or message detail section and are not covered here for brevity. However, more discussion is provided in Appendix C of this document. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 15 Internet Draft Time Efficient CT September 2002 As this version of the proposal is being written, the transport and reliability requirements for context transfer procedure are being specified [5]. 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. Appendix B of this draft provides optional reliability enhancements that can easily be turned on/ off. Since this proposal is written at a time when transport requirements for context transfer procedures are not specified, the reliability mechanisms included should be treated as preliminary. 10. 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. 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. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 16 Internet Draft Time Efficient CT September 2002 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. 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): Ajoy Singh, Mike Needham, Narayanan Venkitaraman, Lily Chen, Christophe Janneteau and Alexandru Petrescu. 12. 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. 13. 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 17 Internet Draft Time Efficient CT September 2002 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 18 Internet Draft Time Efficient CT September 2002 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- Quasi-Reliable TEXT (optional) 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 provides optional reliability enhancements that can easily be turned on/ off. Since this proposal is written at a time when transport requirements for specific feature context transfer are not specified, the reliability mechanisms included should be treated as preliminary. 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. TCP and SCTP use Acknowledgements to detect transmission losses, while UDP does not provides ACKs at all. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 19 Internet Draft Time Efficient CT September 2002 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 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 an optional quasi-reliable enhancement to TEXT message sequence adapted to work with UDP. The enhancement is optional in the sense that, reliability mechanism can easily be turned off by clearing the reliability_supported flag (S flag) in the CT header. It is quasi-reliable since it only provides minimum reliability, since it is NACK based. In case additional reliability is needed, the NACK method can easily be converted to an ACK method. In the following we will explain various elements of a quasi- reliable TEXT over UDP. To provide a minimum reliability that provides context updates, a combination of CT NACK messages and U flag is used. (The message details provided in 6.): | MN nAR CaAR T | | ==== MNÆs data=========. | I CT trigger | | 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 UDP Checksum activation Of the existing transport mechanisms, both TCP and SCTP provide checksums. UDP provides only 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. Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 20 Internet Draft Time Efficient CT September 2002 CT Header 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 message. S: Reliability-Supported Flag in CT header This flag indicates whether the reliability mechanisms are supported or not (explained in 5.4) R: Reliability-Required Flag in CT header This flag indicates whether the message regards a feature(s) that requires reliability mechanisms (explained in 5.4) N: New or retransmitted in CT header The On-set of this flag indicates that a message is being sent for the first time or includes retransmissions or updates of some features (explained in 5.4). CT data option sequence number Retransmissions or updates of feature context (CT data options should) use the same sequence number as the original transmission. However, in case of updates a combination of sequence numbers and time stamps is needed, as explained in the following. R-flag: Reliability-required flag in CT data option This flag indicates whether the feature specified in the option requires reliability or not (details in 6.2). U-flag: Update flag in CT data option (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 CaAR receives a NACK. For updates, the CaAR must consult the feature unit to acquire updated context data. For retransmission (cleared U- flag), the CaAR simply retransmits the feature context from its buffers. The update messages would be marked with the same feature context sequence numbers. 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. Context transfer NACK messages (from nAR to CaAR) Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 21 Internet Draft Time Efficient CT September 2002 For bandwidth efficiency, the mechanism is NACK based, i.e. not every packet is ACKed. This means packets with indistinguishable UDP headers do not trigger retransmissions. The NACK messages are only sent or processed in case the reliability mechanism is supported by newAR (S-flag in CT header set) and reliability for one or more feature has been required (R-flag in CT data option). Two types of CT NACK messages are proposed: CT PNACK message (from nAR to CaAR) Used when the newAR recognizes that one or more entire CT data packets are missing based on gap in CT header sequence numbers of the received CT data packets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ microflow 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 CT data packet (The dummy packet could simply include the CT header of the last CT data packet). CT FNACK message (from nAR to aAR) 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. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ microflow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ FPT | | |U| FSN | NULL ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: CT FNACK message payload Blob (For field descriptions see CT data options). 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 Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 22 Internet Draft Time Efficient CT September 2002 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 updates are required by some features. CT Feature abort (CT Failure mechanism) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ microflow identifier ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT | reserved ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: CT feature abort message payload. Appendix C- 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), Nakhjiri draft-nakhjiri-seamoby-text-ct-01.txt 23 Internet Draft Time Efficient CT September 2002 care must be taken so that the flow of real time traffic will 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 24