Seamoby WG
   Internet Draft                                         J. Loughney (editor)
   Document: draft-ietf-seamoby-ctp-00.txt                        Nokia
Internet Draft                                              M. Nakhjiri
                                                               Motorola
Category: Standards Track                                    C. Perkins
                                                                  Nokia
<draft-ietf-seamoby-ctp-01.txt>                               R. Koodli
Expires: October 2002                                   October 2002 September 2003                                      March 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 [1].

   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
   authorized context transfers.  Context transfers allows better
   support for node based mobility so that the applications running on
   mobile nodes can operate with minimal disruption.  Key objectives are
   to reducing latency, packet losses and avoid re-initiation of
   signaling to and from the mobile node.

   Table of Contents

      1. Introduction...................................................3 Introduction
      1.1 Conventions Used in This Document..........................4 Document
      1.2 Abbreviation Used in the Document..........................4 Document
      2. Protocol Overview..............................................4 Overview
      2.1 Context Transfer Packet Format.............................4 Format
      2.2 Messages...................................................5 Context Types
      2.3 Message Types..............................................5
      2.4 Context Data Format................................................6 Block
      2.4 Messages
      3. Timing and Trigger Considerations..............................6 Transport Considerations
      3.1 Starting Event.............................................7
   4. Congestion Control
      3.2 Transport Considerations.......................................7 Protocols
      4. Open Issues
      4.1 Congestion Control.........................................8 Reliability
      4.2 ICMP.......................................................8 Transport
      4.3 UDP........................................................9 Failure Handling
      4.4 TCP........................................................9
      4.5 SCTP.......................................................9 Zone of Operation
      5. Open Issues....................................................9 Examples and Signaling Flows
      5.1 Reliability................................................9 Network controlled, Initiated by pAR
      5.2 Transport.................................................10 Network controlled, Initiated by nAR
      5.3 Failure Handling..........................................10 Mobile controlled, Predictive New L2 up/old L2 down
      5.4 Zone of Operation.........................................10 Mobile controlled, Reactive CT New L2 up/old L2 down
      6. Examples and Signaling Flows..................................10
   7. Security Considerations.......................................10
   8. Considerations
      7. IANA Considerations...........................................11 Considerations
      8. Acknowledgements
      9. Acknowledgements..............................................12
   10. References...................................................12
      10.1 References
      9.1 Normative References.....................................12
      10.2 References
      9.2 Non-Normative References.................................12 References
      Appendix A. Simplified Example Context Type Specification
      Appendix B. Timing and Trigger Considerations
      Author's Addresses...............................................13 Addresses

1. Introduction

   "Problem Description: Reasons For Performing Context Transfers
   between Nodes in an IP Access Network" [3374] 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.
  2) An additional motivation is to provide an interoperable solution
     that works for any Layer 2 radio access technology.

   Access Routers typically establish state in order to effect certain
   forwarding treatments to packet streams belonging to nodes sharing
   the access router.  For instance, an access router may establish an
   AAA session state and a QoS state for a node's packet streams.  When
   the link connecting a mobile node and the access router is bandwidth-
   constrained,
   bandwidth-constrained, the access router may maintain header
   compression state on behalf of the mobile node.  When such a node
   moves to a different access router, this state or context relocation
   during handover provides many important benefits, including:

     .

      * Seamless operation of application streams.  The handover node
        (i.e., the Mobile Node) does not need to re-establish its
        contexts at the new access router

     .
      * Performance benefits.  When contexts need to be reestablished,
        performance of transport protocols would suffer until the
        contexts are in place.  For instance, when the required QoS
        state is not present, a stream's packets would not receive the
        desired per-hop behavior treatment, subjecting them to higher
        likelihood of unacceptable delays and packet losses.

     .
      * Bandwidth savings.  Re-establishing multiple contexts over an
        expensive, low-speed link can be avoided by relocating contexts
        over a potentially higher-speed wire.

     .
      * Reduced susceptibility to errors, since much more of the
        protocol operates over reliable networks, replacing
        renegotiations over a potentially error-prone link.

   In [3374], a detailed description of motivation, the need and
   benefits of context transfer are outlined.  In this document, we
   describe 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 [2119].

1.2 Abbreviation Used in the Document

   AR              Access Router

   CT              Context Transfer

   CTP             Context Transfer Protocol

   DoS             Denial-of-Service

   FPT             Feature Profile Types

   MIP             Mobile IP

   MN              Mobile Node

   nAR             New Access Router

   pAR             Previous Access Router

   SA              Security Association

2. Protocol Overview

   This section provides a protocol overview.

2.1 Context Transfer Packet Format

   The packet consists of A context transfer can be
   either started by a common header, message specific header and
   one request from the mobile node ("mobile
   controlled") or more data packets.  Data packets at the initiative of either the new or the previous
   access router ("network controlled").

    * The mobile node can send the CT start request to old or new AR.
      The former is preferred whenever possible.  Sending the request to
      nAR would add extra latency since the new AR, itself, after
      processing the MN's request will need to request context
      transmission from pAR.
    * Either nAR or pAR may be bundled together in
   order ensure request or start (respectively) context
      transfer based on internal or network triggers (see Appendix B).

   The MN will send a more efficient transfer. context transfer request to the pAR (including
   proper authentication material). After checking authentication, pAR
   starts the context transfer procedure.

   The total packet size,
   including transport Context Transfer protocol typically operates between a source
   node and IP protocol headers SHOULD a target node. In the future, there may be less
   than multiple target
   nodes involved; the path MTU, in order to avoid packet fragmentation.

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

2.2 Messages

   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           |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Authorization Token                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3 Message Types

   Context Transfer Start Request (CTSR) Message

     Sent by MN 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). We assume that pAR
   and nAR share an appropriate security association, set up
   independently and prior to pAR request start of context transfer.  It is
     for further to study Any appropriate
   mechanism may be used in setting up this security association; it
   enables the CT peers to see if utilize a secure channel for transferring
   contexts, providing authentication, integrity, and (if needed)
   confidentiality.

   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 CTSR message is sent by pAR may transfer the contexts; the
   NAR may request contexts and the MN may send a message to the nAR, it should also be relayed PAR to pAR). Acknowledgement
     is optional, since if
   transfer contexts. Such a trigger must be capable of providing the CTSR message is sent by
   necessary information, such as the MN, MN's IP address with which the MN
     may have already moved and may not receive
   contexts are associated, the reply. This message
     may include a list IP addresses of FPT (feature profile types) that require
     transfer. It may include flags to request secure and/or reliable
     transfer.

   Context Transfer Initiate Ack (CTIN-Ack) Message
     Sent by nAR to pAR, showing nAR's readiness the access routers, and
   authorization to accept MN's transfer context.
     This message is used when reliability is required. In other words,
     if

   Context transfer protocol messages use Context Types that identify
   the reliability flag way that data is set, this message must be sent. organized for the particular feature contexts.
   The Context Transfer Data (CTD) Message

     Sent by pAR Types (CPTs) are registered in a number space (with IANA
   Type Numbers) that allows a node to nAR, unambiguously determine the type
   of context and includes the context parameters present in the protocol
   messages.  Contexts are transferred by laying out the appropriate
   feature data (CTP data). This
     message should handle predictive within Context Data Blocks according to the format in
   section 2.3, as well as normal CT. A
     reliability flag included in this message indicates whether 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 actually transfer 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 reply
     is required by nAR. Context Transfer Data Reply (CTDR) Message

     This Start
   Request (CTSR) message is sent by nAR from the MN whose feature contexts are to pAR depending be
   transferred, or it receives an internally generated trigger (e.g., a
   link-layer trigger on the value of interface to which the
     reliability flag MN is connected).

   The CTSR message, described in CTD. Indicates success or failure.

   Context Transfer Cancel (CTA) Message

     Sent by nAR Section 2.4.1, provides the IP address
   of NAR, the IP address of MN on PAR, the list of feature contexts to pAR
   be transferred (by default requesting all contexts to cancel an ongoing CT process, for example
     mobile node has moved, or nAR has waited too long for
     retransmissions.

2.4 Data 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Data Type           |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     context feature data                      /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Timing be
   transferred), and Trigger Considerations

   Basic Mobile IP handover signaling can introduce disruptions to a token authorizing the
   services running on top of Mobile IP, which may introduce unwanted
   latencies that practically prohibit its use for many types of
   services. Mobile transfer. It also includes
   the MN's new IP latency and packet loss address (valid on NAR) whenever it 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) known. In
   response to a CT-Start Request message or minimally to the disruption of services in
   conjunction to handovers. This means 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 timing of context
   transfer SHOULD be carefully aligned with basic Mobile MN's previous IP handover
   events, address and with optimized Mobile its new IP handover signaling mechanisms,
   as those protocols become more stable.

   In addition whenever possible, address
   (whenever known). It also includes a key, and an indication to use a
   particular algorithm to assist NAR in computing a token that it could
   use to check authorization prior to making the context transfer procedure MUST
   take measures contexts available to minimize
   the service disruption (packet loss) caused
   by MN.

   In the context transfer procedure itself. This will be elaborated
   further second scenario, pAR receives a Context Transfer Request (CT
   Request) described in Section 2.4.5, message from nAR.  The nAR
   itself generates the future updates of this draft.

3.1 Starting Event CT can be Request message either started by as a request from result of
   receiving the MN or at the
   initiative of new AR CTSR message or pAR.

     . MN can send the CT start request as a response to old or new AR. The former is
        preferred since an internal trigger
   (that indicates the MN is expected to have more satisfactory
        trust relationship with pAR than with nAR. Also sending MN's attachment). In the
        request to CT-Req message, nAR would add extra latency since the new AR, itself,
        after processing
   supplies the MN's request will need to request context
        transmission from pAR.

     . Either new AR or old AR may request or start (respectively)
        context transfer based on internal or network triggers.

   Here we prefer previous IP address, the following approach:

   The MN will send a context transfer request feature contexts to the old AR (including
   proper authentication material). After checking authentication be
   transferred, and if a token (typically generated by the MN) authorizing
   context transfer. In response to CT Request message, pAR has transmits a trust relationship with nAR, the old AR starts
   Context Transfer Data (CTD) message that includes the
   context transfer procedure.

4. Transport Considerations

   It is not 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 intention status of this work to define a new general-purpose
   transport protocol. processing the received contexts.   In this section we outline the issues
   "reactive" transfer of running
   CTP over well-known protocols.

   A general note, however, on congestion control. ICMP contexts, PAR verifies authorization token
   before transmitting the contexts, and UDP do hence does not
   provide congestion control, while TCP/SCTP do provide congestion
   control.  Congestion control may delay include the transfer of context, but
   do protect key
   and the network.  This trade off needs to be further studied
   in terms of applicability name of algorithm in the CTD message.

   When context transfer.  Some issues affecting transfer takes place without the nAR requesting it
   (scenario one above), nAR should require MN to present its
   authorization token. Doing this will be locally at nAR when the type of signaling - for example, intra-domain vs.
   inter-domain.

   Of the existing transport mechanisms, both TCP and SCTP provide
   checksums. UDP provides only an optional checksum. In order MN attaches
   to make
   efficient use of multiplexing functionality of context transfer
   protocol, it improves performance, since the UDP checksum MUST contexts highly likely to be de-activated. This will decrease
   the likelihood that the entire
   present already. When context data packet is dropped due to
   individual feature data corruptions.

4.1 Congestion Control

   Context transfer is essentially happens with an optimization to enable smooth
   handovers and to prevent the need of re-initializing signaling to and explicit
   request from a mobile node after handover.  Context transfer NAR (scenario two above), pAR performs such verification
   since the contexts are still present at pAR. In either case, token
   verification takes place
   between access routers.

   The goal of congestion control is to prevent congestion by noting
   packet loss at the transport layer and reducing node possessing the congestion
   control window when packet loss occurs, thus effectively restricting contexts.

   Performing context transfer in advance of the available in-flight window MN attaching to NAR
   clearly has potential for packet sending.  Additionally, TCP
   & SCTP deploy slow-start mechanisms at start-up, in order better performance.  For this to prevent
   congestion problems at take
   place, certain conditions must be met.  For example, PAR must have
   sufficient time and knowledge about the start of a new TCP/SCTP session.

   As some context impending handover. This is time-critical, delays due to congestion control
   may reduce
   feasible for instance in Mobile IP fast handovers. However, when the performance
   advance knowledge of mobile nodes; additionally, signaling
   from the mobile node may be increased impending handover is not available, or if a
   mechanism such as fast handover fails, retrieving feature contexts
   after the context transfer of time
   critical data fails.

   Therefore, some analysis MN attaches to NAR is needed on the role of congestion control
   and only available means for 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 Performing context transfer should
   take approximately one kilobyte, based on existing implementation of 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 transfer solutions.   Contexts that are significantly
   larger are assumed not so time critical. For a larger number of
   users, say one thousand users requesting gets updated on a smooth handover all in the
   same second,
   per-packet basis must clearly be transferred only after packet
   forwarding to the total bandwidth needed MN on its previous link is still a small fraction terminated.  Transfer of
   a typical Ethernet or frame relay or ATM link between access routers.
   So even bursty traffic will be fine. Additionally, physically
   adjacent access routers should
   such contexts must be properly synchronized with in appropriate handover
   messages, such as Mobile IP (Fast) Binding Update.

2.1 Context Transfer Packet Format

   The packet consists of a common header, message specific header and
   one or two 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 hops 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.
   The meaning of each
   other, so context type is determined by a specification
   document and the effects of context transfer should type numbers are to be localized If
   transferring real-time contexts triggers congestive errors, the
   access network may be seriously under-provisioned.

4.2 ICMP

   Pros
     . No explicit connection setup needed.
     . Reliability tabulated in a
   registry maintained by IANA, and handled at the upper layer.
     . Co-ordination with mobility solutions easier to implement.

   Cons
     . No transport level signaling
     . No reliability
     . No ability according to fragment data.
     . Upper Size limits on packets.

     . ICMP messages have low priority the message
   specifications in case this document.  The instantiation of congestion

4.3 UDP

   Pros
     . No explicit connection setup needed.
     . Reliability handled at each context
   by nAR is determined by the upper layer.
     . Co-ordination with mobility solutions easier to implement.

   Cons
     . No transport level signaling
     . No reliability
     . No ability to fragment data.

4.4 TCP

   Pros
     . Supports TLS
     . Built in reliability

   Cons
     . 3-way handshake, mitigated if TCP connections are re-used.

   Open issues
     . Single TCP connection or multiple TCP connections?

4.5 SCTP

   Pros
     . Supports TLS
     . Built messages in reliability
     . Message-oriented
     . Multiple streams prevent head-of-line blocking for multiple
        users.

   Cons
     . 4-way handshake (though 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 can be included on 4th), mitigated
        if TCP connections are re-used.

   Open issues
     . Partial Reliability SCTP may have interesting applicability
        here.

5. Open Issues

   This section lists some open issues that need further discussion.

5.1 Reliability
   Should reliability be handled at fields in the transport layer?  Should
         state variable vector which embodies the
   reliability needs context.
       - Default values (if any) for each individual datum of contexts be handled the
         context state vector.
       - Procedures and requirements for creating a context at a new
         access router, given the CTP data level or CTP
   message level?  How to handle multiple contexts to be transferred
   with differing reliability needs.

5.2 Transport

   Currently, from a previous
         access router, and formatted according to the issue of which transport protocol should be supported
   is open.

5.3 Failure Handling

   Failure of Context Transfer should at least cause no harm to ordering rules
         and date field sizes presented in the
   network specification.
       - If possible, status codes for success or failure related to the user session.  Failure reporting to
         context transfer.  For instance, a QoS context transfer might
         have different status codes depending on which elements of the mobile node
   may
         context data failed to be needed. It is instantiated at nAR.

   Appendix A contains an example context type specification for further study how UDP/RDP
   header compression context.

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 handle failures 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 transfer.

5.4 Zone type specification, one bit per data field
   regardless of Operation

   Currently, the authors are restricting discussion size of CTP to intra-
   domain signaling.  Discussion the data field.   Notice that the length of inter-domain signaling left for
   later discussions.

   Inter-domain signaling
   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
   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 Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                         message data                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The Mobile Node, for which context transfer protocol operations are
   undertaken, is always identified by its previous care-of address. At
   any one time, only one context transfer operation may be in progress
   so that the CTDR message unambigously identifies which CTD message is
   acknowledged simply by including the mobile node's identifying
   previous care-of address.

2.4.1 Context Transfer Start Request (CTSR) Message

   Sent by MN to nAR to request start of context transfer.  It is for
   further to study to see if when the CTSR message is sent by the MN to
   the nAR, it should also be relayed to pAR.  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 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           |reserve|       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Previous Router IP Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             MN Authorization Token                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Requested Context Type (if present)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Next Requested Context Type (if present)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The message data for CTSR is the Mobile Node's Previous Care-of
   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 Data (CTD) Message

   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          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Mobile Node's New Care-of Address, if C=1          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      First Context Block                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Next Context Block                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MN Authorization Token is computed over the binary data
   represented in the Context Data BLocks of the CTD message.  The
   binary data is laid out as the fully specified ordered sequence of
   data fields according to the defining context specification, as if
   there were no presence vector and therefore no implicitly supplied
   default values.  Since the mobile node is expected to know the
   precise contents of the context data to be transferred, and the pAR
   is expected to know the security parameters and algorithm used by the
   mobile node to compute the authorization token, the token can be
   supplied by pAR on behalf of the mobile node.

2.4.3  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        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 which contexts have failed
   and which have succeeded, along with the reason.

2.4.4  Context Transfer Cancel (CTC) Message

   If transfering a context requires an ongoing process (i.e., is not
   short-lived), 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.5 Context Transfer Request (CT Request) Message

   Sent by nAR to pAR request start of context transfer. This message is
   sent as a response to CTSR 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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Requested Context Type (if present)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Next Requested Context Type (if present)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 MN Authorization Token is computed by laying
   out all the context data according to the specifications given within
   the Context Type document, without any abbreviation or implicit
   specification as for default values.

3. Transport Considerations

   It is not the intention of this work to define a new general-purpose
   transport protocol.  In this section we outline the issues of running
   CTP over well-known protocols.

   ICMP and UDP do not provide congestion control, while TCP/SCTP do
   provide congestion control.  The connection setup for those
   congestion control transport protocols may introduce delays in start
   of data transfer, but do protect the network from becoming
   overloaded. This trade off needs to be further studied in terms of
   applicability of context transfer.  Since the data to be handled by
   the context transfer protocol is typically transmitted locally only,
   between access routers, the danger for congestion in the network at
   large is substantially reduced or eliminated.  Some issues affecting
   this will be the type of signaling - for example, intra-domain vs.
   inter-domain.

   Of the existing transport mechanisms, both TCP and SCTP provide
   checksums. UDP provides only an optional checksum.  In order to
   enable use of multiplexing functionality of context transfer
   protocol, the UDP checksum MAY be de-activated to provide flexibility
   in inserting checksums within context information as needed. This
   will decrease the likelihood that the entire context data packet is
   dropped due to individual feature data corruptions.

3.1 Congestion Control

   Context transfer enables smooth handovers and prevents the need of
   re-initializing signaling to and from a mobile node after handover.
   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
   control 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
   contexts that are "too late" should not be included as part of the
   retransmitted CTD data.

3.2 Transport Protocols

3.2.1 ICMP

   Pros
    * No explicit connection setup needed.
    * Reliability handled at the upper layer.
    * Co-ordination with mobility solutions easier to implement.

   Cons
    * No transport level signaling
    * No reliability
    * No ability to fragment data.
    * Upper Size limits on packets.
    * ICMP messages have low priority in case of congestion

3.2.2 UDP

   Pros
    * No explicit connection setup needed.
    * Reliability handled at the upper layer.
    * Co-ordination with mobility solutions easier to implement.

   Cons
    * No transport level signaling
    * No reliability
    * No ability to fragment data.

3.2.3 TCP

   Pros
    * Supports TLS
    * Built in reliability

   Cons
    * 3-way handshake, mitigated if TCP connections are re-used.

   Open issues
    * Single TCP connection or multiple TCP connections?  Per transfer
      or per neighbor?

3.3.4 SCTP

   Pros
    * Supports TLS
    * Built in reliability
    * Message-oriented
    * Multiple streams prevent head-of-line blocking for multiple users.

   Cons
    * 3-way handshake, mitigated if STCP connections are re-used.

   Open issues
    * Partial Reliability SCTP may be interesting, as it allows
      selective retransmission.

4. Open Issues

   This section lists some open issues that need further discussion.

4.1 Reliability

   Should reliability be handled at the transport layer?  Should the
   reliability needs of contexts be handled at the CTP data level or CTP
   message level?

4.2 Transport

   Currently, the issue of which transport protocol should be supported
   is open.

4.3 Failure Handling

   Failure of Context Transfer should at least cause no harm to the
   network or to the user session.  Failure reporting to the mobile node
   may be needed.  The details about how failure can be reported for
   some individual contexts but not requiring retransmission of all
   contexts should be straightforward but remain to be worked out.

4.4 Zone of Operation

   Currently, the authors are restricting discussion of CTP to intra-
   domain signaling.  Discussion of inter-domain signaling left for
   later discussions.

   Inter-domain signaling places additional requirements on establishing
   security relationships that may not be relevant for intra-domain.
   Besides, physically adjacent routers may be more than several IP hops
   away.  Additionally, provisioning inter-domain signaling links may be
   much more complicated.

   Restricting CTP to intra-domain signaling simplifies security,
   transport and provision concerns.  Additionally, a restriction to
   intra-domain signaling may help to ensure CT completes in sufficient
   time to meet time sensitive requirements.

5. Examples and Signaling Flows

5.1 Network controlled, Initiated by pAR

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

5.2 Network controlled, initiated by nAR

              MN                    nAR                     pAR
              |                      |                       |
         T    |                 CT trigger                   |
         I    |                      |                       |
         M    |                      |----- CT request ----->|
         E    |                      |                       |
         :    |                      |<------- CTD ----------|
         |    |                      |                       |
         V    |                      |----- CTDR (opt) ----->|
              |                      |                       |
   Is a new message CT request needed?

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

   CTSR request to nAR (nAR must be able to authenticate MN for CT,
   security details later)

              MN                    nAR                     pAR
              |                      |                       |
        new L2 link up               |                       |
              |                      |                       |
         CT trigger                  |                       |
              |                      |                       |
         T    |--------CTSR  ------->|                       |
         I    |                      |---- CT request ------>|
         M    |                      |                       |
         E    |                      |<-------- CTD ---------|
         :    |                      |                       |
         |    |                      |                       |
         V    |                      |                       |
              |                      |                       |

   Is a new message CT request needed?

   In case CT cannot be supported, a CTSR reject may be sent to the MN
   by nAR.

5.4 Mobile controlled, Reactive CT New L2 up/old L2 down

   CTSR request to pAR through nAR (the pAR needs to authenticate the
   CTSR)

              MN                    nAR                     pAR
              |                      |                       |
        new L2 link up               |                       |
              |                      |                       |
         CT trigger                  |                       |
              |                      |                       |
         T    |------- CTSR -------->|===== CTSR relay =====>|
         I    |                      |                       |
         M    |                      |<------- CTD --------- |
         E    |                      |                       |
         :    |                      |                       |
         |    |                      |                       |
         V    |                      |                       |
              |                      |                       |
   The CTSR relay is more complicated.  For example, the
   physically adjacent routers may be more than several IP hops away.
   Additionally, provisioning inter-domain signaling links may be much
   more complicated.

   Restricting CTP CTSR message that is destined to intra-domain signaling simplifies security,
   transport pAR and provision concerns.  Additionally, a restriction to
   intra-domain signaling may help to ensure is
   routed through nAR (routing details later). In case CT completes in sufficient
   time cannot be
   supported, a CTSR reject maybe sent to meet time sensitive requirements. the MN through nAR.

6. Examples and Signaling Flows

   To be added.

7. Security Considerations

   The Context Transfer Protocol essentially 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-style attacks by bad guys trying to shift state between ARs, causing network
   disruptions.

   In general, CTP MUST rely relies on IETF standardized security mechanisms for
   protecting traffic between access routers, as opposed to creating
   application security mechanisms. Both IPsec and TLS [TLS] may be
   reasonable mechanisms for securing the context transfer 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 AR
   need to engage in a key exchange mechanisms such as IKE [IKE],
   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 MSUT be provided so that requests are authenticated
   (regardless of the security of context transfer itself) to prevent
   the possibility of rouge MNs launching DoS attacks by sending large
   number of CT requests as well as cause large number of context
   transfers between ARs.

   Another 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.

8.

7. IANA Considerations

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

   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.

9.

8. Acknowledgements

   The authors would like to thank Rajeev Koodli, whose prior Context
   Transfer Framework was used as the basis for part of this work.

   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 Nakhjiri, Rajeev Koodli and Charles Perkins. The Working Group
   chairs,
   working group chairs are Pat Calhoun and James Kempf monitored Kempf, whose comments
   have been very helpful during the design team.

10. creating of this specification.

9. References

10.1

9.1 Normative References

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

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

   [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.

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

   [IKE]     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.

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

10.2

9.2 Non-Normative References

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

   [2401]    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.

Appendix A.  Simplified Example Context Type Specification

   This diagram illustrates the method for specifying context type data
   to be associated with a particular context type for Header Compres-
   sion.

   TBA

   Context Type: Header Compression

     Data fields:
       IP header fields
          Current IP Source Address        32bits     Change recipe
          Current IP Destination Address   32bits     Change recipe

       UDP header fields

       RTP header fields

Appendix B. 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 services. 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 conjunction to
   handovers. This means that the timing of context transfer SHOULD be carefully
   aligned with basic Mobile IP
               Access Network", RFC 3374, Internet Engineering Task
               Force, RFC 3374, May 2001.

   [2401]    S. Kent, R. Atkinson, "Security Architecture for handover events, and with optimized Mobile IP
   handover signaling mechanisms, as those protocols become available.

   Furthermore, some of those optimized mobile IP handover mechanisms (such as
   BETH) may provide more flexibility is choosing the
            Internet Protocol", RFC 2401, November 1998.

   [TERM]   J. Manner, M. Kojo, "Mobility Related Terminology",
            Internet Engineering Task Force, Work in Progress. timing and order for
   transfer of various context information.

Author's Addresses

   Rajeev Koodli
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, California 94043
   USA
   Rajeev.koodli@nokia.com

   John Loughney
   Nokia
   It„merenkatu
   Itdmerenkatu 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.