[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4067

Seamoby WG                                         J. Loughney (editor)
Internet Draft                                              M. Nakhjiri
Category: Experimental                                       C. Perkins
<draft-ietf-seamoby-ctp-03.txt>                               R. Koodli
Expires: December 2003                                        June 2003





                       Context Transfer Protocol



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [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.

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 2003.  All Rights Reserved.

Abstract

   This document presents a context transfer protocol that enables
   mobile nodes to authorize context transfers between access routers.
   Context transfers allow better support for node based mobility so
   that the applications running on mobile nodes can operate with
   minimal disruption.  Key objectives are to reduce latency, packet
   losses and avoiding re-initiation of signaling to and from the mobile
   node.



Loughney et al.          expires December 2003                  [Page 1]

Internet-Draft                                                 June 2003


   Table of Contents

      1. Introduction
      1.1 Conventions Used in This Document
      1.2 Abbreviations Used in the Document
      2. Protocol Overview
      2.1 Context Transfer Packet Formats
      2.2 Context Types
      2.3 Context Data Block
      2.4 Messages
      3. Transport, Reliability and Retransmission of Feature Data
      4. Open Issues
      4.1 Failure Handling ti -5 5. Examples and Signaling Flows
      5.1 Network controlled, Initiated by pAR
      5.2 Network controlled, Initiated by nAR
      5.3 Mobile controlled, Predictive New L2 up/old L2 down
      6. Security Considerations
      7. IANA Considerations
      8. Acknowledgements
      9. References
      9.1 Normative References
      9.2 Non-Normative References
      Appendix A. Timing and Trigger Considerations
      Appendix B. Congestion Control
      Author's Addresses


























Loughney et al.          expires December 2003                  [Page 2]

Internet-Draft                                                 June 2003


1. Introduction

   "Problem Description: Reasons For Performing Context Transfers
   between Nodes in an IP Access Network" [RFC3374] defines the
   following main reasons why Context Transfer procedures may be useful
   in IP networks.

  1) The primary motivation, as mentioned in the introduction, is the
     need to quickly re-establish context transfer-candidate services
     without requiring the mobile host to explicitly perform all
     protocol flows for those services from scratch. An example of a
     service is Context Relocation for Seamless Header Compression in IP
     Networks [CTHC].

  2) An additional motivation is to provide an interoperable solution
     that supports various Layer 2 radio access technologies.

   This document describes a generic context transfer protocol, which
   provides:

      * Representation for feature contexts.
      * Messages to initiate and authorize context transfer, and notify
        a mobile node of the status of the transfer.
      * Messages for transferring contexts prior to, during and after
        handovers.

   The proposed protocol is designed to work in conjunction with other
   protocols in order to provide seamless mobility.


1.1 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 [RFC2119].

1.2 Abbreviations Used in the Document

   Mobility Related Terminology [TERM] defines basic mobility
   terminology.  In addition to the material in that document, we use
   the following terms and abbreviation in this document.

   CTP             Context Transfer Protocol

   DoS             Denial-of-Service

   FPT             Feature Profile Types




Loughney et al.          expires December 2003                  [Page 3]

Internet-Draft                                                 June 2003


2. Protocol Overview

   This section provides a protocol overview. A context transfer can be
   either started by a request from the mobile node ("mobile
   controlled") or at the initiative of either the new or the previous
   access router ("network controlled").

    * The mobile node sends the CT Activate Request to old AR whenever
      possible to initiate predictive context transfer. In any case, the
      MN always sends the CTAR message to new AR. If the contexts are
      already present, nAR would verify the authorization token present
      in CTAR with its own computation (using the parameters supplied by
      pAR), and subsequently activate those contexts. If the contexts
      are not present, nAR requests pAR to supply them using the Context
      Transfer Request message, in which it supplies the authorization
      token present in CTAR.
    * Either nAR or pAR may request or start (respectively) context
      transfer based on internal or network triggers (see Appendix B).

   The Context Transfer protocol typical           lly operates between
   a source node and a target node. In the future, there may be multiple
   target nodes involved; the protocol described here would work with
   multiple target nodes. For simplicity, we describe the protocol
   assuming a single receiver or target node.

   Typically, the source node is a MN's Previous Access Router (pAR) and
   the target node is MN's New Access Router (nAR). Context Transfer
   takes place when an event, such as a handover, takes place. We call
   such an event as a Context Transfer Trigger. In response to such a
   trigger, the pAR may transfer the contexts; the nAR may request
   contexts; and the MN may send a message to the routers to transfer
   contexts. Such a trigger must be capable of providing the necessary
   information, such as the MN's IP address with which the contexts are
   associated, the IP addresses of the access routers, and authorization
   to transfer context.

   Context transfer protocol messages use Feature Profile Types that
   identify the way that data is organized for the particular feature
   contexts. The Feature Profile Types (FPTs) are registered in a number
   space (with IANA Type Numbers) that allows a node to unambiguously
   determine the type of context and the context parameters present in
   the protocol messages.  Contexts are transferred by laying out the
   appropriate feature data within Context Data Blocks according to the
   format in section 2.3, as well as any IP addresses necessary to
   associate the contexts to a particular MN. The context transfer
   initiation messages contain parameters that identify the source and
   target nodes, the desired list of feature contexts and IP addresses
   to identify the contexts. The messages that request transfer of



Loughney et al.          expires December 2003                  [Page 4]

Internet-Draft                                                 June 2003


   context data also contain an appropriate token to authorize the
   context transfer.

   The Previous Access Router transfers feature contexts under two
   general scenarios.  First, it may receive a Context Transfer Activate
   Request (CTAR) message from the MN whose feature contexts are to be
   transferred, or it receives an internally generated trigger (e.g., a
   link-layer trigger on the interface to which the MN is connected).
   The CTAR message, described in Section 2.4.1, provides the IP address
   of nAR, the IP address of MN on pAR, the list of feature contexts to
   be transferred (by default requesting all contexts to be
   transferred), and a token authorizing the transfer. It also includes
   the MN's new IP address (valid on nAR) whenever it is known. In
   response to a CT-Activate Request message or to the CT trigger, pAR
   predictively transmits a Context Transfer Data (CTD) message that
   contains feature contexts.  This message, described in Section 2.4.2,
   contains the MN's previous IP address and its new IP address (if
   known). It also contains parameters for nAR to compute an
   authorization token to verify the MN's token present in CTAR message.
   Recall that the MN always sends CTAR message to nAR regardless of
   whether it sent the CTAR message to pAR. The reason for this is that
   there is no means for the MN to ascertain that context transfer
   reliably took place. By always sending the CTAR message to nAR, the
   Context Transfer Request (see below) can be sent to pAR whenever
   necessary.

   In the second scenario, pAR receives a Context Transfer Request (CT
   Request) described in Section 2.4.5, message from nAR.  The nAR
   itself generates the CT Request message either as a result of
   receiving the CTAR message or as a response to an internal trigger
   (that indicates the MN's attachment). In the CT-Req message, nAR
   supplies the MN's previous IP address, the feature contexts to be
   transferred, and a token (generated by the MN) authorizing context
   transfer. In response to CT Request message, pAR transmits a Context
   Transfer Data (CTD) message that includes the MN's previous IP
   address and feature contexts.  When it receives a corresponding CTD
   message, nAR may generate a CTD Reply message (See Section 2.4.3) to
   report the status of processing the received contexts.

   [1].* contexts, pAR verifies authorization token before transmitting
   the [2].* in the CTD message.

   When context transfer takes place without the nAR requesting it
   (scenario one above), nAR requires MN to present its authorization
   token. Doing this locally at nAR when the MN attaches to it improves
   performance and increases security, since the contexts are highly
   likely to be present already. When context transfer happens with an
   explicit request from nAR (scenario two above), pAR performs such



Loughney et al.          expires December 2003                  [Page 5]

Internet-Draft                                                 June 2003


   verification since the contexts are still present at pAR. In either
   case, token verification takes place at the router possessing the
   contexts.

   Performing context transfer in advance of the MN attaching to nAR can
   increase handover performance.  For this to take place, certain
   conditions must be met.  For example, pAR must have sufficient time
   and knowledge about the impending handover. This is feasible, for
   instance, in Mobile IP fast handovers. Additionally, many cellular
   networks have mechanisms to detect handovers in advance. However,
   when the advance knowledge of impending handover is not available, or
   if a mechanism such as fast handover fails, retrieving feature
   contexts after the MN attaches to nAR is the only available means for
   context transfer. Performing context transfer after handover might
   still be better than having to re-establish all the contexts from
   scratch. Finally, some contexts may simply need to be transferred
   during handover signaling. For instance, any context that gets
   updated on a per-packet basis must clearly be transferred only after
   packet forwarding to the MN on its previous link is terminated.

   The messages (CTD and CTDR) that perform the context transfer between
   the access routers need to be authenticated, so that the access
   routers can be certain that the data has not been tampered with
   during delivery.

2.1 Context Transfer Packet Format

   The packet consists of a common header, message specific header and
   one or more data packets.  Data packets may be bundled together in
   order ensure a more efficient transfer.  The total packet size,
   including transport protocol and IP protocol headers SHOULD be less
   than the path MTU, in order to avoid packet fragmentation.


           +----------------------+
           |      CTP Header      |
           +----------------------+
           |    Message Header    |
           +----------------------+
           |     CTP Data 1       |
           +----------------------+
           |     CTP Data 2       |
           +----------------------+
           |         ...          |

2.2 Context Types

   Contexts are identified by context type, which is a 32-bit number.



Loughney et al.          expires December 2003                  [Page 6]

Internet-Draft                                                 June 2003


   The meaning of each context type is determined by a specification
   document and the context type numbers are to be tabulated in a
   registry maintained by IANA, and handled according to the message
   specifications in this document.  The instantiation of each context
   by nAR is determined by the messages in this document along with the
   specification associated with the particular context type. Each such
   context type specification contains the following details:

       - Number, size (in bits), and ordering of data fields in the
         state variable vector which embodies the context.
       - Default values (if any) for each individual datum of the
         context state vector.
       - Procedures and requirements for creating a context at a new
         access router, given the data transferred from a previous
         access router, and formatted according to the ordering rules
         and date field sizes presented in the specification.
       - If possible, status codes for success or failure related to the
         context transfer.  For instance, a QoS context transfer might
         have different status codes depending on which elements of the
         context data failed to be instantiated at nAR.

2.3 Context Data Block

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V|                       Context Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Presence Vector (if V = 1)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                   context type-dependent data                 /
                                                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'V' bit specifies whether or not the "presence vector" is used.
   When the presence vector is in use, the next 32 bits are interpreted
   to indicate whether particular data fields are present (and, thus,
   containing non-default values).  The ordering of the bits in the
   presence vector is the same as the ordering of the data fields
   according to the context type specification, one bit per data field
   regardless of the size of the data field.   Notice that the length of
   the context data block is defined by the sum of lengths of each data
   field specified by the context type specification, plus 4 bytes if
   the 'V' bit is set, minus the accumulated size of all the context
   data that is implicitly given as a default value.

2.4 Messages

   In this section, a list of the available context transfer message



Loughney et al.          expires December 2003                  [Page 7]

Internet-Draft                                                 June 2003


   types is given, along with a brief description of their functions.
   Generally, messages use the following generic message header format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |reserve|       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous IP address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                         message data                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Mobile Node, for which context transfer protocol operations are
   undertaken, is always identified by its previous IP access address.
   At any one time, only one context transfer operation per MN may be in
   progress so that the CTDR message unambiguously identifies which CTD
   message is acknowledged simply by including the mobile node's
   identifying previous IP address.

2.4.1 Context Transfer Activate Request (CTAR) Message

   This message is always sent by MN to nAR to request context transfer
   activation. It is for further to study to see if when the CTAR
   message is sent by the MN to the nAR.  If an acknowledgement is
   needed, the MN sets the A flag to 1, other wise the MN does not
   expect an acknowledgement. This message may include a list of FPT
   (feature profile types) that require transfer. It may include flags
   to request secure and/or reliable transfer.

   The MN may also send this message to pAR while still connected to
   pAR. In such a case, the MN includes the nAR's IP address and its new
   IP address (if known).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |A| rsv |       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous IP Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Previous Router IP Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Type=Auth-Token| Type Len      |        Replay                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Requested Context Type (if present)              |



Loughney et al.          expires December 2003                  [Page 8]

Internet-Draft                                                 June 2003


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Next Requested Context Type (if present)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The message data for CTAR is the Mobile Node's Previous IP Address,
   Previous Router's IP address, MN Authorization Token, followed by a
   list of context types.  If no context types are specified, then all
   contexts for the mobile node are requested.


2.4.2 Context Transfer Activate Acknowledge (CTAA) Message

   This is an informative message sent nAR to the MN to acknowledge a
   CTAR message. Acknowledgement is optional, since the MN may have
   already moved and may not receive the reply. This message may include
   a list of FPT (feature profile types) that were not transferred
   successfully.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |reserve|       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous IP Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Previous Router IP Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Type=Auth-Token| Type Len      |        Replay                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Failed Context Type (if present)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Next Failed Context Type (if present)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The message data for CTAR is the Mobile Node's Previous IP Address,
   Previous Router's IP address, MN Authorization Token, followed by a
   list of context types that were not successfully transferred.  If no
   context types are specified, then all contexts for the mobile node
   are considered successfully transferred.

2.4.3 Context Transfer Data (CTD) Message




Loughney et al.          expires December 2003                  [Page 9]

Internet-Draft                                                 June 2003


   Sent by pAR to nAR, and includes feature data (CTP data). This
   message should handle predictive as well as normal CT.  A reliability
   flag, R, included in this message indicates whether a reply is
   required by nAR.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |C|R|rsv|       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Elapsed Time (in milliseconds)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Mobile Node's New Care-of Address, if C=1          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type=Auth    |  Type Length  |   Algorithm   |  Key Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Key...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      First Context Block                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Next Context Block                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Authorization token type field is present in the predictive
   scenario only. The supplied parameters, algorithm, key length and the
   key itself, allow nAR to compute a token locally depending on the
   contents of the CTAR message.

   The algorithm for carrying out the computation of the MN
   Authorization Token is HMAC_SHA1. The input data for computing the
   token are: the MN's Previous IP address, the FPT objects and the
   Replay field. When support for transferring all contexts is
   requested, a default FPT is used. The Authorization Token is obtained
   by truncating the results of the HMAC_SHA1 computation to retain only
   the leading 32 bits.


2.4.4  Context Transfer Data Reply (CTDR) Message

   This message is sent by nAR to pAR depending on the value of the
   reliability flag in CTD. Indicates success or failure.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1



Loughney et al.          expires December 2003                 [Page 10]

Internet-Draft                                                 June 2003


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |C| rsv |       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OverallStatus | Ctx-1 Status  | Ctx-2 Status  |     ......    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The OverallStatus is used for reporting overall success or failure,
   which could be based on verification of the MN authorization token
   for instance.  For certain values of the overall status, it may be
   that some contexts were successfully transferred and some failed to
   be transferred.  In this case, then for each context another status
   code MUST be provided to indicate to pAR those contexts that have
   failed and those that have succeeded, along with the reason.

2.4.5  Context Transfer Cancel (CTC) Message

   If transferring a context cannot be completed in a timely fashion,
   then nAR may send CTC to pAR to cancel an ongoing CT process.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |  rsv  |      Length  = 4      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.4.6 Context Transfer Request (CT Request) Message

   Sent by nAR to pAR request start of context transfer. This message is
   sent as a response to CTAR message by the MN.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |reserve|       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Type=Auth-Token| Type Len      |        Replay                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Requested Context Type (if present)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Next Requested Context Type (if present)          |



Loughney et al.          expires December 2003                 [Page 11]

Internet-Draft                                                 June 2003


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The message data for CT Request is the Mobile Node's Previous Care-of
   Address, MN Authorization Token, followed by a list of context types.
   If no context types are specified, then all contexts for the mobile
   node are requested.  The fields including and following the
   Authorization Token Type are inserted from the CTAR message.

   The algorithm for carrying out the computation is HMAC_SHA1. The
   Authorization token is obtained by truncating the results of the
   HMAC_SHA1 computation to retain only the leading 32 bits. The input
   data for computing the token are: the MN's Previous IP address, the
   FPT objects and the Replay field. When support for transferring all
   contexts is requested, a default FPT is used.

3. Transport, Reliability and Retransmission of Feature Data

   CTP runs over UDP using port number <TBD>. Some feature contexts may
   specify a reliability factor, MAX_RETRY_INTERVAL, which is the length
   of time that the pAR is allowed to perform retransmissions before
   giving up on the context transfer for that feature context.  The
   longer the allowed retry interval, the more retransmissions will be
   possible for that feature context.

   For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD
   retransmit an unacknowledged CTD message after waiting for
   RETRANSMISSION_DELAY milliseconds.  This time value is configurable
   based on the type of network interface; slower network media
   naturally will be configured with longer values for the
   RETRANSMISSION_DELAY.  Except for the value of the elapsed time
   field, the payload of each retransmitted CTD packet is identical to
   the payload of the initially transmitted CTD packet, in order to
   maintain the ability of the mobile device to present a correctly
   calculated authentication token.  The number of retransmissions, each
   delayed by RETRANSMISSION_DELAY, depends on the maximum value for
   MAX_RETRY_INTERVAL as specified by any of the contexts.   The value
   of the Elapsed Time field is the number of milliseconds since the
   transmission of the first CTD message

   UDP provides an optional checksum, which SHOULD be checked. If the
   checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with
   the status value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in
   the CTD.

4. Error Codes




Loughney et al.          expires December 2003                 [Page 12]

Internet-Draft                                                 June 2003


   This section lists error codes used by UDP

      BAD_UDP_CHECKSUM                        0x01

5. Examples and Signaling Flows

5.1 Network controlled, Initiated by pAR

              MN                    nAR                     pAR
              |                      |                       |
         T    |                      |                  CT trigger
         I    |                      |                       |
         M    |                      |<------- CTD ----------|
         E    |--------CTAR--------->|                       |
         :    |                      |                       |
         |    |                      |-------- CTDR -------->|
         V    |                      |                       |
              |                      |                       |

5.2 Network controlled, initiated by nAR

in 6
        MN                    nAR                     pAR
        |                      |                       |
   T    |                 CT trigger                   |
   I    |                      |                       |
   M    |                      |----- CT Request ----->|
   E    |                      |                       |
   :    |                      |<------- CTD ----------|
   |    |                      |                       |
   V    |--------CTAR--------->|                       |
        |                      |----- CTDR (opt) ----->|
        |                      |                       |



5.3 Mobile controlled, Predictive New L2 up/old L2 down

   CTAR request to nAR

              MN                    nAR                     pAR
              |                      |                       |
        new L2 link up               |                       |
              |                      |                       |
         CT trigger                  |                       |
              |                      |                       |
         T    |--------CTAR  ------->|                       |
         I    |                      |---- CT Request ------>|



Loughney et al.          expires December 2003                 [Page 13]

Internet-Draft                                                 June 2003


         M    |                      |                       |
         E    |                      |<-------- CTD ---------|
         :    |                      |                       |
         |    |                      |                       |
         V    |                      |                       |
              |                      |                       |

   In case CT cannot be supported, a CTAR reject (TBD) may be sent to
   the MN by nAR.

6. Security Considerations

6.1. Threats.

   The Context Transfer Protocol transfers state between access routers.
   If the mobile nodes are not authenticated and authorized before
   moving on the network, there is a potential for DoS attacks to shift
   state between ARs, causing network disruptions.

   Additionally, DoS attacks can be launched from mobile nodes towards
   the access routers by requesting multiple context transfers and then
   disappearing.  Additionally, a rogue access router could flood mobile
   nodes with packets, attempting DoS attacks.

  6.2. Security Details

   CTP relies on IETF standardized security mechanisms for protecting
   traffic between access routers, as opposed to creating application
   security mechanisms. IPsec MUST be supported between access routers.

   In order to avoid the introduction of additional latency to context
   transfer due to the need for establishment of secure channel between
   the context transfer peers (ARs), the two ARs SHOULD establish such
   secure channel in advance. If IPSec is used, for example, the two
   access routers need to engage in a key exchange mechanisms such as
   IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and
   IPSec protocols (such as ESP) in anticipation for any upcoming
   context transfer. This will save time during handovers that require
   secure transfer of mobile node's context(s). Such SAs can be
   maintained and used for all upcoming context transfers between the
   two ARs.  Security should be negotiated prior to the sending of
   context.

   Furthermore, either one or both of the pAR and nAR need to be able
   authenticate the mobile and authorize mobile's credential before
   authorizing the context transfer and release of context to the
   mobile. In case the context transfer is request by the MN, a
   mechanism MUST be provided so that requests are authenticated



Loughney et al.          expires December 2003                 [Page 14]

Internet-Draft                                                 June 2003


   (regardless of the security of context transfer itself) to prevent
   the possibility of rogue MNs launching DoS attacks by sending large
   number of CT requests as well as cause large number of context
   transfers between ARs. Another important consideration is that the
   mobile node should claim it's own context, and not some other
   masquerader. One method to achieve this is to provide an
   authentication cookie to be included with the context transfer
   message sent from the pAR to the nAR and confirmed by the mobile node
   at the nAR.

6.3. IPsec Considerations

   Access Routers MUST implement IPsec ESP [ESP] in transport mode with
   non-null encryption and authentication algorithms to provide per-
   packet authentication, integrity protection and confidentiality, and
   MUST implement the replay protection mechanisms of IPsec. In those
   scenarios where IP layer protection is needed, ESP in tunnel mode
   SHOULD be used. Non-null encryption should be used when using IPSec
   ESP.

7. IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   context transfer protocol, in accordance with BCP 26 [RFC2434].

7.1  Context Profile Types Registry

This document authorized IANA to create a registry for Context Profile
Types, introduced in this document.  For future Context Profile Types,
it is recommended that allocations be done on the basis of Designated
Expert.

The Context Profile Type introduced in this document requires IANA Type
Numbers for each set of feature contexts that make use of Profile Types.

For registration requests where a Designated Expert should be consulted,
the responsible IESG area director should appoint the Designated Expert.

7.2 UDP Port

   CTP requires a UDP port assignment.

8. Acknowledgements

   This document is the result of a design team formed by the Working
   Group chairs of the SeaMoby working group. The team included John
   Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. The



Loughney et al.          expires December 2003                 [Page 15]

Internet-Draft                                                 June 2003


   working group chairs are Pat Calhoun and James Kempf, whose comments
   have been very helpful during the creation of this specification.

9. References

9.1 Normative References


   [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
             BCP 9, RFC 2026, October 1996.


   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
             ment Levels", BCP 14, RFC 2119, March 1997.


   [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402,
             November 1998


   [CT-REQ]  G. Kenward et al., "General Requirements for Context
             Transfer", Internet Draft, Internet Engineering Task Force,
             Work in Progress.


   [CTF]     R. Koodli, C.E. Perkins, "Context Transfer Framework for
             Seamless Mobility", Internet Draft, Internet Engineering
             Task Force, Work in Progress.


   [FMIPv6]  R. Koodli (Ed),  "Fast Handovers for Mobile IPv6", Internet
             Engineering Task Force. Work in Progress.

             IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.


   [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
             RFC 2409, November 1998.


   [LLMIP]   K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
             Internet Engineering Task Force. Work in Progress.


   [ESP]     Kent, S. and R. Atkinson, "IP Encapsulating Security Pay-
             load (ESP)", RFC 2406, November 1998.



Loughney et al.          expires December 2003                 [Page 16]

Internet-Draft                                                 June 2003


9.2 Non-Normative References


[CTHC]    R. Koodli et al., "Context Relocation for Seamless Header
          Compression in IP Networks", Internet Draft, Internet
          Engineering Task Force, Work in Progress.


[RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing
          Context Transfers Between Nodes in an IP Access Network", RFC
          3374, Internet Engineering Task Force, RFC 3374, May 2001.


[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
          Protocol", RFC 2401, November 1998.


[TERM]    J. Manner, M. Kojo, "Mobility Related Terminology", Internet
          Engineering Task Force, Work in Progress.


[RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
          January 1999.

          Appendix A. Timing and Trigger Considerations

   Basic Mobile IP handover signaling can introduce disruptions to the
   services running on top of Mobile IP, which may introduce unwanted
   latencies that practically prohibit its use for certain types of ser-
   vices. Mobile IP latency and packet loss is being optimized through
   several alternative procedures, such as Fast Mobile IP [FMIPv6] and
   Low Latency Mobile IP [LLMIP].

   Feature re-establishment through context transfer should contribute
   zero (optimally) or minimal extra disruption of services in conjunc-
   tion to handovers. This means that the timing of context transfer
   SHOULD be carefully aligned with basic Mobile IP handover events, and
   with optimized Mobile IP handover signaling mechanisms, as those pro-
   tocols become available.

   Furthermore, some of those optimized mobile IP handover mechanisms
   (such as BETH) may provide more flexibility is choosing the timing
   and order for transfer of various context information.

Appendix B. Congestion Control

   Context transfer enables smooth handovers and prevents the need of
   re-initializing signaling to and from a mobile node after handover.



Loughney et al.          expires December 2003                 [Page 17]

Internet-Draft                                                 June 2003


   Context transfer takes place between access routers.

   The goal of congestion control is to prevent congestion by noting
   packet loss at the transport layer and reducing the congestion con-
   trol window when packet loss occurs, thus effectively restricting the
   available in-flight window for packet sending.  Additionally, TCP &
   SCTP deploy slow-start mechanisms at start-up, in order to prevent
   congestion problems at the start of a new TCP/SCTP session.

   As some context is time-critical, delays due to congestion control
   may reduce the performance of mobile nodes; additionally, signaling
   from the mobile node may be increased if the context transfer of time
   critical data fails.

   Therefore, some analysis is needed on the role of congestion control
   and context transfer.  Important considerations should be network-
   provisioning, intra-domain vs. inter-domain signaling as well as
   other considerations. A quick analysis follows.

   It is assumed that intra-domain time-critical context transfer should
   take no more than one kilobyte, based on existing implementation of
   some context transfer solutions.   Contexts that are significantly
   larger are assumed not so time critical. For a larger number of
   users, say one thousand users requesting a smooth handover all in the
   same second, the total bandwidth needed is still a small fraction of
   a typical Ethernet or frame relay or ATM link between access routers.
   So even bursty traffic is unlikely to introduce local congestion.
   Furthermore, physically adjacent access routers should be within one
   or two IP hops of each other, so the effects of context transfer
   should be localized.  If transferring real-time contexts triggers
   congestive errors, the access network may be seriously under-
   provisioned.

   In order to handle multiple contexts to be transferred with differing
   reliability needs, each context has to be considered separately by
   the sending access router nAR.  If a CTD message is retransmitted
   because the CTDR message was not received in time, then those con-
   texts that are "too late" are included anyway as part of the
   retransmitted CTD data, in order to ease the ability to verify the
   Mobile Authorization Token.

Authors' Addresses

   Rajeev Koodli
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, California 94043
   USA



Loughney et al.          expires December 2003                 [Page 18]

Internet-Draft                                                 June 2003


   Rajeev.koodli@nokia.com

   John Loughney
   Nokia
   It„merenkatu 11-13
   00180 Espoo
   Finland
   john.loughney@nokia.com

   Madjid F. Nakhjiri
   Motorola Labs
   1031 East Algonquin Rd., Room 2240
   Schaumburg, IL, 60196
   USA
   madjid.nakhjiri@motorola.com

   Charles E. Perkins
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, California 94043
   USA
   charliep@iprg.nokia.com

Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to per-
   tain to the implementation or use of the technology described in this
   document or the extent to which any license under such rights might
   or might not be available; neither does it represent that it has made
   any effort to identify any such rights.  Information on the IETF's
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP-11.  Copies of claims of
   rights made available for publication and any assurances of licenses
   to be made available, or the result of an attempt made to obtain a
   general license or permission for the use of such proprietary rights
   by implementers or users of this specification can be obtained from
   the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.







Loughney et al.          expires December 2003                 [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/