[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-05.txt>                               R. Koodli
Expires: May 25, 2004                                  October 25, 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
   authorized context transfers.  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 May 25, 2004                  [Page 1]

Internet-Draft                                          October 25, 2003


   Table of Contents

      1.  Introduction
      1.1 The Problem
      1.2 Conventions Used in This Document
      1.3 Abbreviations Used in the Document
      2.  Protocol Overview
      2.1 Context Transfer Scenarios
      2.2 Context Transfer Packet Formats
      2.3 Context Types
      2.4 Context Data Block
      2.5 Messages
      3.  Transport, Reliability and Retransmission of Feature Data
      4.  Error Codes
      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
      6.1 Threats
      6.2 Security Details
      6.3 IPsec Considerations
      7.  IANA Considerations
      7.1  Context Profile Types Registry
      7.2 UDP Port
      8.  Acknowledgements
      9.  References
      9.1 Normative References
      9.2 Non-Normative References
      Appendix A. Timing and Trigger Considerations
      Appendix B. Multicast Listener Context Transfer
      Author's Addresses



















Loughney et al.           expires May 25, 2004                  [Page 2]

Internet-Draft                                          October 25, 2003


1. Introduction

   This document describes the Context Transfer Protocol overview, 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.  The protocol
   supports both IPv4 and IPv6, though support for IPv4 private
   addresses is for future study.

The Problem

   "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 included in Appendix C.

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


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



Loughney et al.           expires May 25, 2004                  [Page 3]

Internet-Draft                                          October 25, 2003


   FPT             Feature Profile Types

   PCTD            Predictive Context Transfer Data

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 typically 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 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



Loughney et al.           expires May 25, 2004                  [Page 4]

Internet-Draft                                          October 25, 2003


   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
   context data also contain an appropriate token to authorize the
   context transfer.

   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 Scenarios

   The Previous Access Router transfers feature contexts under two
   general scenarios.

2.1.1 Scenario 1

   The pAR 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.5, 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.5, contains the MN's



Loughney et al.           expires May 25, 2004                  [Page 5]

Internet-Draft                                          October 25, 2003


   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.

   When context transfer takes place without the nAR requesting it, 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.
   Token verification takes place at the router possessing the contexts.

2.1.2 Scenario 2

   In the second scenario, pAR receives a Context Transfer Request (CT
   Request), described in Section 2.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 to report the status of processing the
   received contexts.

   When contexts are transferred reactively, the pAR verifies
   authorization token before transmitting the contexts, and hence the
   key the key is not needed in the CTD message.

2.2 Context Transfer Packet Format

   The packet consists of a message specific header and one or more data
   packets.  Data packets may be bundled together in order to 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.

2.3 Context Types

   Contexts are identified by context type of Feature Profile Type
   (FPT), which is a 15-bit number. 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



Loughney et al.           expires May 25, 2004                  [Page 6]

Internet-Draft                                          October 25, 2003


   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:

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

       - 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.4 Context Data Block

   The Context Data Block is used both for request and response
   operation. When a particular feature request is constructed, only the
   first 4 bytes are typically necessary (See CTAR below). When used for
   the actual feature context itself, the context data is present, and
   sometimes the presence vector is present.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Cxt-Type    |    Length     |P| Feature Profile Type (FTP)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Presence Vector (if P = 1)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                               data                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Loughney et al.           expires May 25, 2004                  [Page 7]

Internet-Draft                                          October 25, 2003


            Cxt-Type             Single octet, defined by IANA

            Length               message length in octets

            'P' bit              0 = No presence vector
                                 1 = Presence vector present.

            FPT                  16 bit integer, listing the feature profile
                                 type contained in the data field.

            data                 Context type-dependent data, whose length is
                                 is defined by the Length Field.  If the data
                                 is not 64-bit aligned, the data field is padded
                                 with zeros.

   The Cxt-Type indicates the type of the feature context message itself
   (such as QoS Context Request, QoS Context Transfer etc.), and Feature
   Profile Type (FPT) identifies the way the particular feature context
   is organized. The 'P' bit specifies whether or not the "presence
   vector" is used. When the presence vector is in use, the Presence
   Vector is interpreted to indicate whether particular data fields are
   present (and 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.

   The Length field indicates the size of the CDB in 8 octets including
   the first 4 bytes starting from Cxt-Type.

      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 'P' bit is set, minus the
      accumulated size of all the context data that is implicitly given
      as a default value.

2.5 Messages

   In this section, a list of the available context transfer message
   types is given, along with a brief description of their functions. In
   addition, the CTAR message also contains either the Previous Router's
   IP address or the New Router's IP address.

   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.



Loughney et al.           expires May 25, 2004                  [Page 8]

Internet-Draft                                          October 25, 2003


   The 'V' flag indicates whether the MN's previous address is IPv4
   only, IPv6 only or both addresses are present. See below.

2.5.1 Context Transfer Activate Request (CTAR) Message

   This message is always sent by MN to nAR to request context transfer
   activation. Even when the MN does not know whether or not contexts
   are present, the MN sends CTAR message to gain access with nAR. If an
   acknowledgement for this message is needed, the MN sets the A flag to
   1, otherwise 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 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) rather than previous IP address and pAR's IP
   address.  If the new IP address is not known, then its previous IP
   address is used.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=CTAR   |     Length    | V |A|        Reserved         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous (New) IP Address           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Previous (New) Router IP Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Replay                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Requested Context Data Block (if present)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Next Requested Context Data Block (if present)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type                 CTAR = 1

            Length               message length in octets

            MN's IP Address      Field contains either:
                                 IPv4 Address as defined in [RFC 791].
                                 IPv6 Address as defined in [RFC 2373].

            nAR / pAR IP Address Field contains either:



Loughney et al.           expires May 25, 2004                  [Page 9]

Internet-Draft                                          October 25, 2003


                                 IPv4 Address as defined in [RFC 791].
                                 IPv6 Address as defined in [RFC 2373].

            Reserved             Reserved for future use.  Must be set to zero
                                 by the MN.

            'V' flag             When set to '00', indicate presence of IPv6
                                 Previous (New) address only.
                                 When set to '01' indicate presence of IPv4
                                 Previous (New) Address only.
                                 When set to '10' indicate presence of both
                                 IPv6 and IPv4 Previous (New) addresses.

            'A' bit              The MN requests an acknowledgement.

            Replay               A value used to make sure that each use of the
                                 CTAR message is uniquely identifiable.

            Authorization Token  An unforgeable value calculated as discussed
                                 below.  This authorizes the receiver of CTAR
                                 to perform context transfer.

            Context Block        Variable length field defined in section 2.4.

   If no context types are specified, then all contexts for the mobile
   node are requested. When 'V' is 10, the IPv4 address MUST precede the
   IPv6 address both for the MN and the access router. Since Context
   Types clearly define the context including the IP version, context
   enumeration need not be in any strict order, although it might be
   natural to outline all the IPv4 contexts followed by IPv6 contexts.

   The Authorization Token is calculated as:

      First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context
      Types)))

   where Key is the shared secret between the MN and pAR, and Context
   Types includes all the desired contexts for which the transfer is
   desired. In the default scenario, the MN implicitly (i.e., even
   without the knowledge of contexts being present) or explicitly
   requests transfer of all contexts.

2.5.2 Context Transfer Activate Acknowledge (CTAA) Message

   This is an informative message sent by the receiver of CTAR to the MN
   to acknowledge a CTAR message. Acknowledgement is optional, depending
   on whether the MN requested it. This message may include a list of
   FPT (feature profile types) that were not transferred successfully.



Loughney et al.           expires May 25, 2004                 [Page 10]

Internet-Draft                                          October 25, 2003


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type=CTAA    |     Length    |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous IP address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         FPT (if present)      | Status code   |  Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type                 CTAR = 2

            Length               message length in octets

            Reserved             Reserved for future use.  Must be set to zero
                                 by the MN.

            MN's Prev IP Address Field contains either:
                                 IPv4 Address as defined in [RFC 791].
                                 IPv6 Address as defined in [RFC 2373].

            FPT                  16 bit integer, listing the FTP that was not
                                 Successfully transferred.

            Status Code          An octet, containing failure reason.

2.5.3 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type=(P)CTD  |     Length    | V |A|   Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Elapsed Time (in milliseconds)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Mobile Node's New Care-of Address, when Type=PCTD      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
      |             Algorithm           |          Key Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD



Loughney et al.           expires May 25, 2004                 [Page 11]

Internet-Draft                                          October 25, 2003


      |                            Key                                | only
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
      |                   First Context Data Block                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Next Context Data Block                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type                 CTD = 3 (Context Transfer Data)
                                 PCTD = 4 (Predictive Context Transfer Data)

            'V' flag             When set to '00', indicate presence of IPv6
                                 Previous (New) address only.
                                 When set to '01' indicate presence of IPv4
                                 Previous (New) Address only.
                                 When set to '10' indicate presence of both
                                 IPv6 and IPv4 Previous (New) addresses.

            'A' bit              The MN requests an acknowledgement.

            Length               message length in octets

            Reserved             Reserved for future use.  Must be set to zero
                                 by the MN.

            MN's Prev CoA        Address Field contains either:
                                 IPv4 Address as defined in [RFC 791],
                                 IPv6 Address as defined in [RFC 2373].

            MN's New CoA         Address Field contains either:
                                 IPv4 Address as defined in [RFC 791],
                                 IPv6 Address as defined in [RFC 2373].
                                 This is only applicable for the PCTD message.

            Algorithm            Algorithm for carrying out the computation
                                 of the MN Authorization Token.  Currently
                                 only 1 algorithm is defined, HMAC_SHA1 = 1.

            Key Length           length of key, in octets.

   When CTD is sent predictively, the supplied parameters including the
   algorithm, key length and the key itself, allow nAR to compute a
   token locally and verify against the token present in the CTAR
   message.  This message MUST be protected by IPsec ESP.

   As described previously, the algorithm for carrying out the
   computation of the MN Authorization Token is HMAC_SHA1. The input



Loughney et al.           expires May 25, 2004                 [Page 12]

Internet-Draft                                          October 25, 2003


   data for computing the token are:

      - the MN's Previous IP address,
      - the FPT objects,
      - 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.5.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type=CTDR    |     Length    | V |S|       Reserved          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous IP Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        FPT (if present)       | Status code   |  Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | .......                                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type                 CTDR = 5 (Context Transfer Data)

            Length               message length in octets

            'V' flag             When set to '00', indicate presence of IPv6
                                 Previous address only.
                                 When set to '01' indicate presence of IPv4
                                 Previous Address only.
                                 When set to '10' indicate presence of both
                                 IPv6 and IPv4 Previous addresses.

            'S' bit              When set to one, this bit indicates that all
                                 the feature contexts sent in CTD or PCTD were
                                 received successfully.

            Reserved             Reserved for future use.  Must be set to zero
                                 by the MN.

            MN's Prev IP         Contains either:
            Address Field          IPv4 Address as defined in [RFC 791].



Loughney et al.           expires May 25, 2004                 [Page 13]

Internet-Draft                                          October 25, 2003


                                   IPv6 Address as defined in [RFC 2373].

            Status Code          A context-specific return value, present
                                 when 'S'     is not set to one.

            FPT                  16 bit integer, listing the FPT that is being
                                 acknowledged.

            Status Code          0 = not successfully transfered
                                 1 = successfully transfered


2.5.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type=CTC     | Length        |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type           CTC = 6 (Context Transfer Data)

            Length         message length in octets

            Reserved       Reserved for future use.  Must be set to zero
                           by the MN.

2.5.6 Context Transfer Request (CT Request) Message

   Sent by nAR to pAR to request start of context transfer. This message
   is sent as a response to CTAR message by the MN. The fields following
   the Previous IP address of the MN are included verbatim from the CTAR
   message.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type=CTREQ   |     Length    | V |       Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous IP Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Replay                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Loughney et al.           expires May 25, 2004                 [Page 14]

Internet-Draft                                          October 25, 2003


      |                    MN Authorization Token                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Requested Context Data Block (if present)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Next Requested Context Data Block (if present)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           ........                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Type                CTREQ = 7

            Length              message length in octets

            'V' bits            When set to '00', indicate presence of IPv6
                                Previous (New) address only.
                                When set to '01' indicate presence of IPv4
                                Previous (New) Address only.
                                When set to '10' indicate presence of both
                                IPv6 and IPv4 Previous (New) addresses.

            Reserved            Reserved for future use.  Must be set to zero
                                by the MN.

            Replay              A value used to make sure that each use of the
                                CTAR message is uniquely identifiable.
                                Copied from CTAR.

            Authorization Token An unforgeable value calculated as discussed
                                above.  This authorizes the receiver of CTAR
                                to perform context transfer. Copied from
                                CTAR.



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



Loughney et al.           expires May 25, 2004                 [Page 15]

Internet-Draft                                          October 25, 2003


   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 'A' bit is not set in
   the CTD.

4. Error Codes

   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

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



Loughney et al.           expires May 25, 2004                 [Page 16]

Internet-Draft                                          October 25, 2003


              |                      |                       |


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

   At this time, the threats to IP handover in general and context
   transfer in particular are incompletely understood, particularly on
   the MN to AR link, and mechanisms for countering them are not well
   defined. Part of the experimental task in preparing CTP for eventual
   standards track will be to better characterize threats to context
   transfer and design specific mechanisms to counter them. This section
   provides some general guidelines about security based on discussions
   among the Design Team and Working Group members.

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.  Finally, a rogue access router could flood mobile
   nodes with packets, attempting DoS attacks.




Loughney et al.           expires May 25, 2004                 [Page 17]

Internet-Draft                                          October 25, 2003


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 to
   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
   (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



Loughney et al.           expires May 25, 2004                 [Page 18]

Internet-Draft                                          October 25, 2003


   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 & Contributors

   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.

   Contributors to the Context Transfer Protocol review are Basavaraj
   Patil, Pekka Savola, and Antti Tuominen.

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

   The authors would also like to thank Julien Bournelle, Vijay
   Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf
   Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their
   help and suggestions with this document.

9. References

9.1 Normative References


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





Loughney et al.           expires May 25, 2004                 [Page 19]

Internet-Draft                                          October 25, 2003


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

             IP [RFC2434] T. Narten, H. 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.


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

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.


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


   [LLMIP]   K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
             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.


   [RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast
             Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999.





Loughney et al.           expires May 25, 2004                 [Page 20]

Internet-Draft                                          October 25, 2003


   [RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery
             for IP Version 6 (IPv6)," RFC 2461, December, 1998.


   [RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfigura-
             tion," RFC 2462, December, 1998.


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
   may provide more flexibility is choosing the timing and order for
   transfer of various context information.

Appendix B. Multicast Listener Context Transfer

   As an example of how context transfer can improve the performance of
   IP layer handover, we consider transferring IPv6 MLD state [RFC2710].
   MLD state is a particularly good example because every IPv6 node must
   perform one MLD messaging sequence on the wireless link to establish
   itself as an MLD listener prior to performing router discovery
   [RFC2461] or duplicate address detection [RFC2462] or before
   sending/receiving any application-specific traffic (including Mobile
   IP handover signaling, if any). The node must subscribe to the Soli-
   cited Node Multicast Address as soon as it comes up on the link. Any
   application-specific multicast addresses must be re-established as
   well. Context transfer can significantly speed up re-establishing
   multicast state by allowing the nAR to initialize MLD for a node that
   just completed handover; without any MLD signaling on the new wire-
   less link. The same approach could be used for transferring multicast
   context in IPv4.

   An approximate qualitative estimate for the amount of savings in
   handover time can be obtained as follows. MLD messages are 24 bytes,



Loughney et al.           expires May 25, 2004                 [Page 21]

Internet-Draft                                          October 25, 2003


   to which the headers must be added, because there is no header
   compression on the new link, with the IPv6 header being 40 bytes, and
   a required Router Alert Hop-by-Hop option being 8 bytes including
   padding. The total MLD message size is thus 72 bytes per subscribed
   multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD
   Report messages per address subscription, since the Report message is
   unacknowledged. Assuming 2 MLD messages sent for a subscribed
   address, the mobile node would need to send 144 bytes per address
   subscription, and must send at least 144 bytes on every handover, for
   the link local Solicited Node Multicast address. The amount of time
   required for MLD signaling will, of course, depend on the wireless
   link bandwidth, but some representative numbers can be obtained by
   assuming bandwidths of 20 kbps or 100 kbps. The former is approximate
   for a narrowband 3G cellular link and the latter for a heavily util-
   ized 802.11b WLAN link, both running Voice over IP (VoIP). With these
   two bit rates, the savings from not having to perform the required
   MLD signaling are 57 msec. and 11 msec., respectively. If any
   application-specific multicast addresses are subscribed, the amount
   of time saved could be substantially more. Considering most ATM-based
   3G voice cellular protocols try to keep total voice handover delay
   less than 40-80 msec., MLD signaling could have a substantial impact
   on the performance of inter-subnet VoIP handover.

   The context-specific data field for MLD context transfer included in
   the CTP Context Data Block message for a single IPv6 multicast
   address has the following 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +             Subnet Prefix on nAR Wireless Interface           +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +               Subscribed IPv6 Multicast Address               +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Subnet Prefix on nAR Wireless Interface field contains a subnet
   prefix that identifies the interface on which multicast routing
   should be established. The Subscribed IPv6 Multicast Address field
   contains the multicast address for which multicast routing should be
   established.



Loughney et al.           expires May 25, 2004                 [Page 22]

Internet-Draft                                          October 25, 2003


   The pAR sends one MLD context block per subscribed IPv6 multicast
   address.

   The MLD state machine requires no changes to implement context
   transfer. Upon receipt of a CTP Context Data Block for MLD, the state
   machine takes the following actions:

    - If the router is in the No Listeners present state on the wireless
      interface on which the Subnet Prefix field from the Context Data
      Block is advertised, it transitions into the Listeners Present
      state for the Subscribed IPv6 Multicast Address field in the Con-
      text Data Block. This transition is exactly the same as if the
      router had received a Report message.

    - If the router is in the Listeners present state on that interface,
      it remains in that state but restarts the timer, as if it had
      received a Report message.

   If more than one MLD router is on the link, a router receiving an MLD
   Context Data Block SHOULD send the block to the other routers on the
   link. The router MAY instead send a proxy MLD Report message on the
   wireless interface that advertises the Subnet Prefix field from the
   Context Data Block if wireless bandwidth is not an issue. Since MLD
   routers do not keep track of which nodes are listening to which mul-
   ticast addresses, only whether a particular multicast address is
   being listened to, proxying the subscription should cause no diffi-
   culty.

Authors' Addresses

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

   John Loughney
   Nokia
   Itdmerenkatu 11-13
   00180 Espoo
   Finland
   john.loughney@nokia.com

   Madjid F. Nakhjiri
   Motorola Labs
   1031 East Algonquin Rd., Room 2240
   Schaumburg, IL, 60196



Loughney et al.           expires May 25, 2004                 [Page 23]

Internet-Draft                                          October 25, 2003


   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 May 25, 2004                 [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/