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

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

   Seamoby WG
   Internet Draft                                  J. Loughney (editor)
   Document: draft-ietf-seamoby-ctp-00.txt                        Nokia
                                                            M. Nakhjiri
                                                               Motorola
                                                             C. Perkins
                                                                  Nokia
   Expires: October 2002                                   October 2002


                         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.




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.








Loughney                 Expires û April 2003                 [Page 1]

                      Context Transfer Protocol          October 2002


Table of Contents

   1. Introduction...................................................3
      1.1 Conventions Used in This Document..........................4
      1.2 Abbreviation Used in the Document..........................4
   2. Protocol Overview..............................................4
      2.1 Context Transfer Packet Format.............................4
      2.2 Messages...................................................5
      2.3 Message Types..............................................5
      2.4 Data Format................................................6
   3. Timing and Trigger Considerations..............................6
      3.1 Starting Event.............................................7
   4. Transport Considerations.......................................7
      4.1 Congestion Control.........................................8
      4.2 ICMP.......................................................8
      4.3 UDP........................................................9
      4.4 TCP........................................................9
      4.5 SCTP.......................................................9
   5. Open Issues....................................................9
      5.1 Reliability................................................9
      5.2 Transport.................................................10
      5.3 Failure Handling..........................................10
      5.4 Zone of Operation.........................................10
   6. Examples and Signaling Flows..................................10
   7. Security Considerations.......................................10
   8. IANA Considerations...........................................11
   9. Acknowledgements..............................................12
   10. References...................................................12
      10.1 Normative References.....................................12
      10.2 Non-Normative References.................................12
   Author's Addresses...............................................13




















Loughney                 Expires - April 2003                 [Page 2]

                      Context Transfer Protocol          October 2002



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



Loughney                 Expires - April 2003                 [Page 3]

                      Context Transfer Protocol          October 2002


     .  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 common header, message specific header and
   one or more data packets.  Data packets may be bundled together in
   order ensure a more efficient transfer.  The total packet size,


Loughney                 Expires - April 2003                 [Page 4]

                      Context Transfer Protocol          October 2002


   including transport protocol and IP protocol headers SHOULD be less
   than the path MTU, in order to avoid packet fragmentation.

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


2.2 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 or nAR to pAR 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 if the CTSR message is sent by the MN, 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.

   Context Transfer Initiate Ack (CTIN-Ack) Message





Loughney                 Expires - April 2003                 [Page 5]

                      Context Transfer Protocol          October 2002


     Sent by nAR to pAR, showing nAR's readiness to accept MN's context.
     This message is used when reliability is required. In other words,
     if the reliability flag is set, this message must be sent.

   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 included in this message indicates whether a reply
     is required by nAR.

   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.

   Context Transfer Cancel (CTA) Message

     Sent by nAR to pAR 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 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 many 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 minimally to the disruption of services in
   conjunction 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 protocols become more stable.



Loughney                 Expires - April 2003                 [Page 6]

                      Context Transfer Protocol          October 2002


   In addition whenever possible, the context transfer procedure MUST
   take measures to minimize the service disruption (packet loss) caused
   by the context transfer procedure itself. This will be elaborated
   further in the future updates of this draft.

3.1 Starting Event

   CT can be either started by a request from the MN or at the
   initiative of new AR or pAR.

     . MN can send the CT start request to old or new AR. The former is
        preferred since the MN is expected to have more satisfactory
        trust relationship with pAR than with nAR. Also 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 new AR or old AR may request or start (respectively)
        context transfer based on internal or network triggers.

   Here we prefer the following approach:

   The MN will send a context transfer request to the old AR (including
   proper authentication material). After checking authentication and if
   the pAR has a trust relationship with nAR, the old AR starts the
   context transfer procedure.

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

   A general note, however, on congestion control. ICMP and UDP do not
   provide congestion control, while TCP/SCTP do provide congestion
   control.  Congestion control may delay the transfer of context, but
   do protect the network.  This trade off needs to be further studied
   in terms of applicability of context transfer.  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 make
   efficient use of multiplexing functionality of context transfer
   protocol, the UDP checksum MUST be de-activated. This will decrease
   the likelihood that the entire context data packet is dropped due to
   individual feature data corruptions.




Loughney                 Expires - April 2003                 [Page 7]

                      Context Transfer Protocol          October 2002


4.1 Congestion Control

   Context transfer is essentially an optimization to enable smooth
   handovers and to prevent 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 approximately 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 will be fine. Additionally, physically
   adjacent access routers should be with in 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.

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


Loughney                 Expires - April 2003                 [Page 8]

                      Context Transfer Protocol          October 2002


     . ICMP messages have low priority in case of congestion

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

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 in reliability
     . Message-oriented
     . Multiple streams prevent head-of-line blocking for multiple
        users.

   Cons
     . 4-way handshake (though 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



Loughney                 Expires - April 2003                 [Page 9]

                      Context Transfer Protocol          October 2002


   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?  How to handle multiple contexts to be transferred
   with differing reliability needs.

5.2 Transport

   Currently, 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 the
   network or to the user session.  Failure reporting to the mobile node
   may be needed. It is for further study how to handle failures of
   context transfer.

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

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



Loughney                 Expires - April 2003                [Page 10]

                      Context Transfer Protocol          October 2002


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


Loughney                 Expires - April 2003                [Page 11]

                      Context Transfer Protocol          October 2002



9. 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 and Charles Perkins.  The Working Group
   chairs, Pat Calhoun and James Kempf monitored the design team.

10. References

10.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 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 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 Non-Normative References

     [3374] J. Kempf et al., "Problem Description: Reasons For
               Performing Context Transfers Between Nodes in an IP


Loughney                 Expires - April 2003                [Page 12]

                      Context Transfer Protocol          October 2002


               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.






Author's Addresses

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

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

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















Loughney                 Expires - April 2003                [Page 13]


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