Internet Engineering Task Force                               Hamid Syed
Internet Draft                                              Gary Kenward
draft-ietf-seamoby-ct-reqs-01.txt                        Nortel Networks
Expires: March 2001                                          Pat Calhoun
                                                    Black Storm Networks
                                                         Madjid Nakhjiri
                                                                Motorola
                                                           Rajeev Koodli
                                                                   Nokia
                                                         Kulwinder Atwal
                                                        Zucotto Wireless
                                                              Mark Smith
                                                        COM DEV Wireless
                                                    Govind Krishnamurthi
                                                                   Nokia

                                                         September, 2001

           General Requirements for Context Transfer


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Copyright Notice

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


Abstract

   The success of time sensitive services like VoIP telephony, video,
   etc., in a mobile environment depends heavily on the ability to
   minimize the impact of the traffic redirection during a change of
   packet forwarding path. In the process of establishing the new
   forwarding path, the nodes along the new path must be prepared to
   provide similar forwarding treatment to the IP packets. The transfer
   of context information may be advantageous in minimizing the impact
   of host mobility on IP services. This document captures the set of
   requirements for a context transfer solution and the requirements
   for a generic context transfer protocol to carry the context between
   the context transfer peers.


  Introduction

   There are a large number of IP access networks that support mobile
   hosts. For example, wireless Personal Area Networks (PANs), wireless
   LANs, satellite WANs and cellular WANs. The nature of this mobility
   is such that the communication path to the host may change frequently
   and rapidly.

   In networks where the hosts are mobile, the forwarding path through
   the access network must often be redirected in order to deliver the
   host's IP traffic to the new point of access. The success of time
   sensitive services like VoIP telephony, video, etc., in a mobile
   environment depends heavily upon the ability to minimize the impact
   of this traffic redirection. In the process of establishing the new
   forwarding path, the nodes along the new path must be prepared to
   provide similar forwarding treatment to the IP packets.

   The information required to support a specific forwarding treatment
   provided to an IP flow is part of the context for that flow. To
   minimize the impact of a path change on an IP flow, the context must
   be replicated from the forwarding nodes along the existing path to
   the forwarding nodes along the new path. The transfer of context
   information may be advantageous in minimizing the impact of host
   mobility on, for example, AAA, header compression, QoS, Policy, and
   possibly sub-IP protocols and services such as PPP.

   An analysis of the context transfer problem is captured in [2]. This
   document captures the requirements for a context transfer solution
   and the requirements for a generic context transfer protocol to
   carry the context between the context transfer peers.


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


  Terminology

   Most of the terms used in this document are defined in [2].

   Access Router (AR)
      An IP router residing in an Access Network and connected to one or
      more points of access. An AR offers connectivity to MNs.


  General Requirements

   This section addresses the facilities and services required in the access
   network to properly support context transfer.  The context transfer
   solution will have to assume certain characteristics of the access network
   and the mobility solution, and the availability of certain triggering events,
   transport options, and so forth. These support capabilities are not
   necessarily part of context transfer, per se, but are needed for context
   transfer to operate as defined and effect the expected enhancements to MN
   traffic handover. For convenience, this collection of support capabilities
   are referred to as the "context transfer solution".

4.1 The context transfer solution MUST define the characteristics of the IP
    level trigger mechanisms that initiate the transfer of context.

4.2 The IP level context transfer triggers MAY be initiated by a link level
    (layer two) event.

4.3 The IP level trigger mechanisms for context transfer MUST hide the
    specifics of any layer 2 trigger mechanisms.

   Handover at the IP level is a consequence of a change in the physical
   path used to communicate between the MN and the access network. The
   mechanisms utilized to change the communications path at layer 2 are
   specific to the physical characteristics of the medium, and often
   specific to the layer 2 transmission technology being used (e.g. TIA
   IS 2000, ETSI UMTS R4, IEEE 802.11).

   In order for any action to be taken at the IP level to maintain IP
   sessions during a layer 2 path change, some indication of the path
   change must be made available to the IP level. One example of an
   indicator would be the trigger event that initiates context transfer.

   Since it is expected that IP handover, and thus context transfer will
   work irrespective of the layer 2 technology, the IP level solutions
   must not utilize specific layer 2 information. The conditions and
   events that caused the generation of an IP level trigger must be
   opaque to the IP level. This implies that there are general
   characteristics of an IP level trigger that need to be defined so
   that the triggers generated by different layer 2 solutions will have
   identical semantics at the IP level.

4.4 The IP level context transfer triggers MAY be initiated by IP level
    (layer three) signalling.

4.5 Any IP level signalling for Context Transfer MUST be separated from
    the actual transfer of context.

4.6 The context transfer solution SHOULD support one-to-many context
    transfer.

   An MN may have connectivity to the access network through more than
   one physical path at any given time, depending upon the
   characteristics of the physical medium, and the layer 1 and 2
   protocols and services.

   The different physical paths may connect into the network via
   different ARs. In this scenario, two or more ARs may be candidates
   for handover of the MN's traffic and each will require the
   appropriate IP context when forwarding commences. Exactly which AR
   will be the target of the handover is often not known until the
   handover is initiated, and providing the necessary context to all the
   candidate ARs can only accelerate the handover process.

   A one-to-many context transfer may be achieved using either a series
   of point-to-point transfers, or a point-to-multipoint (multicast)
   transfer.

4.7 The context transfer solution MUST support context transfer before,
    during and after handover.


4.8 The context transfer solution MUST support a distributed approach in
    which the Access Routers act as peers during the context transfer.

   One main distinction between the various alternative approaches to
   context transfer is the choice of the functional entity or entities that
   orchestrate the transfer. A context transfer solution that relies upon
   the ARs to effect a context transfer should be the most efficient approach,
   as it involves the fewest possible entities. At the very least, the number
   of protocol exchanges should be less when there are fewer entities involved.

4.9 The entities transferring context MUST have completed a mutual
    authentication process prior to initiating the transfer.

   It is believed that if a formal authentication exchange (e.g. exchanging
   credentials) were done during the context transfer, the computation
   overhead for both the sender and the receiver would cause additional and
   unnecessary latency to the handoff process. Therefore, the CT peers MUST
   exchange credentials prior to any context transfer.



4.10 The context transfer solution SHOULD provide mechanisms to selectively
     enable or disable context transfer for particular IP microflows or groups
     of IP microflows.

   The context associated with an MN's microflows is normally to be
   transferred whenever it is required to support forwarding. However,
   there may be conditions where it is desirable to selectively disable
   context transfer for specific microflows.

   For example, it may be desirable to provide an MN with the capability
   to disallow the transfer of the context associated with one or more
   of its microflows when handover occurs between networks administered
   by different operators.

   Local mechanisms for allowing context transfer to be disabled on a per
   microflow basis have to be provided for in the context transfer solution.
   These mechanisms will most likely be captured as part of the CT MIB, and
   possibly, as part of a PIB, if policy based management is considered
   desirable.

   There are other mechanisms and protocols required to manage or control
   the per microflow disabling of context transfer. These are clearly
   out of the scope of the context transfer work.

4.11 Context information MAY be transferred in phases.


   Providing for phased transfers allows the context acquisition
   and transfer to be prioritized.



4.12 The context information to be transferred MUST be available at the
     AR performing the transfer, prior to the initiation of a given phase
     of the context transfer.

   To effect a rapid transfer, the context information has to be readily
   available when the AR begins a phase of the transfer.

   If the context transfer is comprised of a single phase, then all of the
   context must be available prior to the transfer initiation.

4.13 The context information provided for transfer MUST be reliable.

   The context to be transferred must not only be readily available for
   transfer, but the sending AR must ensure that the information is sound.

   The context transfer solution may provide mechanisms to support reliable
   transfer of context, but the effectiveness of context transfer in enhancing
   handover between ARs would very likely be compromised by attempts to
   transfer malformed context.

4.14 The context transfer solution MUST include methods for interworking
     with any IETF IP mobility solutions.

4.15 The context transfer solution MAY include methods for interworking
     with non-IETF mobility solutions.


. Protocol Requirements

   This section captures the general requirements for the context
   transfer protocol.


5.1 General Protocol Requirements

5.1.1 The context transfer protocol MUST be capable of transferring all
      of the different types of feature context necessary to support the
      MN's traffic at a receiving AR.

5.1.2 The context transfer protocol design MUST define a standard
      representation for conveying context information that will be
      interpreted uniformly and perspicuously by different
      implementations.

5.1.3 The context transfer protocol MUST operate autonomously from the
      content of the context information being transferred.

5.1.4 The context transfer protocol design MUST define a standard method
      for labeling each feature context being transferred.

   Various protocols participate in setting up the service support for
   any given microflow, and many of these protocols require feature
   specific state to be maintained for the life of the IP session. The
   context transfer protocol should provide a generic mechanism to carry
   context information to an AR, irrespective of the context type.

   Given that the desired context transfer protocol is a single, generic
   protocol for transferring all feature context, the collection of
   information representing the context for a given feature must be
   encapsulated into a standard representation and labeled.
   Encapsulation is necessary to keep the context for different features
   separated. The receiving AR will use the label on an encapsulated
   context to associate it with the appropriate service feature and
   process the content appropriately.

   The context transfer protocol does not need to know the contents of
   these nuggets of encapsulated information. Indeed, for the protocol
   to be independent from the type of context being transferred, it must
   be oblivious the actual context.

5.1.5 The context transfer protocol design MUST provide for the future
      definition of new feature contexts.

   The context transfer solution must not attempt to define all possible
   feature contexts to be transferred. Instead, it must provide for the
   definition of new contexts in support of future service features, or
   feature evolution. Guidance should be provided to future users of context
   transfer on the best approach to defining feature context.


5.2 Transport Reliability

   This section is intentionally left blank as the working group is
   waiting for a questionnaire from the transport directorate. The result
   of the questionnaire will create requirements that will be added in this
   section in a later revision of this specification.


5.3 Security

5.3.1 The protocol MUST provide for "security provisioning".

   The security of the context information being exchanged between ARs
   must be ensured. Security provisioning includes protecting the
   integrity, confidentiality, and authenticity of the transfer, as well
   as protecting the ARs against replay attacks.

5.3.2 The security provisioning for context transfer MUST NOT
      require the creation of application layer security.

5.3.3 The protocol MUST provide for the security provisioning to be
      disabled.

   In some environments, the security provisioning provided for by the
   context transfer protocol may not be necessary, or it may be
   preferred to minimize the context transfer protocol overhead.


5.4 Timing Requirements

5.4.1 A context transfer MUST complete with a minimum number of protocol
      exchanges between the source AR and the rest of the ARs.

   The number of protocol exchanges required to perform a peer to peer
   interaction is directly related to the unreliability, resource
   consumption, and completion time of that interaction.  A context
   transfer will require signaling and data exchanges, but, as a general
   rule, by keeping the number of these exchanges to a minimum, the
   reliability, resource utilization and completion delay of the
   transfer should improve.

5.4.2 The context transfer protocol design MUST minimize the amount of
      processing required at the sending and receiving Access Routers.

   If the context transfer protocol requires the context information to
   be transferred in a form that requires significant additional
   processing at each AR, delays may be incurred that impact the
   reliability of the context. In other words, the context may become
   obsolete before it can be reconstructed at the receiving AR.

   Also, AR processing delay contributes to the overall context transfer
   delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult.

   An example of a protocol design that would increase the processing
   delay at the receiver is where the context information is segmented,
   and the ordering of the segments is not preserved during transfer;
   segmenting at the sender, and more likely, re-ordering of the
   segments at the receiver could introduce significant additional
   AR processing delays.

5.4.3 The Context Transfer protocol MUST meet the timing constraints
      required by all the feature contexts.

   A given feature context may have timing constraints imposed by the
   nature of the service being support. The delivered context must
   always comply with the requirements of the service if it is to be
   useable.

5.4.4 The context transfer solution MUST provide for the aggregation of
      multiple contexts.

5.4.5 If context aggregation is not support by the transport protocol
      (via the Nagle algorithm [3]) then the context transfer protocol
      MUST provide it.

   There may be instances where there are multiple context transfers
   pending. To reduce the overall transfer time, as well as transport
   overhead that might be incurred by separately transferring each
   context, the sending AR may choose to aggregate the contexts and
   execute one transfer operation.

   Note that if contexts are aggregated, the labelling method required
   by 5.1.4 must include an identifier that allows the contexts to be
   separated at the receiving AR.


5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

5.6 Interworking with handover mechanisms

5.6.1 The context transfer protocol MAY provide input to the
      handover process.

5.6.2 The context transfer protocol MUST include methods for exchanging
      information with the handover process.

   Both context transfer and handover require information on the
   AR candidates for handover. The context transfer entities may, in the
   process of establishing and supporting context transfer, acquire
   information that would be useful to the handover process in
   determining the new forwarding path: for example, the outcome of an
   admission control decision at a receiving AR.


5.7 Partial Handover

5.7.1 The context transfer protocol MAY provide a mechanism for
      supporting partial handovers.

   In a situation where no single AR is capable of receiving a handover
   of all of an MN's traffic, a mechanism could be provided that would
   allow different IP microflows to be handed over to different ARs.
   The information transferred to each AR must be limited to only the
   context required to support the microflows that are actually handed
   over. Thus, the context transfer protocol would need a mechanism for
   partitioning the context and transferring each portion to the
   appropriate AR.


  References

   [] S. Bradner, "Keywords for use in RFCs to Indicate Requirement
       Levels", RFC2119 (BCP), IETF, March 1997.

   [] Levkowetz et al., "Problem Description: Reasons For Performing
       Context Transfers Between Nodes in an IP Access Network ",
       draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001.

   [] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.


 Acknowledgements

  Thank you to all who participated in the Seamoby working group context
  transfer design team.


  Author's Addresses

   Hamid Syed
   100 Constellation Crescent
   Nepean, Ontario. K2G 6J8         Phone:  1 613 763 6553
   Canada                           Email:  hmsyed@nortelnetworks.com

   Gary Kenward
   100 Constellation Crescent
   Nepean, Ontario. K2G 6J8         Phone:  1 613 765 1437
   Canada                           Email:  gkenward@nortelnetworks.com

   Pat R. Calhoun
   Black Storm Networks
   250 Cambridge Avenue, Suite 200
   Palo Alto, CA 94306              Phone: +1 650 617 2932
   USA                              Email: pcalhoun@bstormnetworks.com

   Madjid Nakhjiri
   Motorola
   1501 West Shure Drive
   Arlington Heights  IL 60004      Phone: +1 847 632 5030
   USA                              Email: madjid.nakhjiri@motorola.com

   Rajeev Koodli
   Communications Systems Laboratory, Nokia Research Center
   313 Fairchild Drive
   Mountain View  CA 94043          Phone: +1 650 625 2359
   USA                              Email: rajeev.koodli@nokia.com

   Kulwinder S. Atwal
   Zucotto Wireless Inc.
   Ottawa  Ontario K1P 6E2          Phone: +1 613 789 0090
   CANADA                           EMail: kulwinder.atwal@zucotto.com

   Mark Smith
   COM DEV Wireless
   3450 Broad Street, Suite 107
   San Luis Obispo, CA 93401        Phone: +1 805 544 1089
   USA                              Email: mark.smith@comdev.cc

   Govind Krishnamurthi
   Communications Systems Laboratory, Nokia Research Center
   5 Wayside Road
   Burlington  MA 01803             Phone: +1 781 993 3627
   USA                              EMail: govind.krishnamurthi@nokia.com


  Full Copyright Statement

   "Copyright (C) The Internet Society (2001). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.