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

Versions: 00 01

Internet Engineering Task Force                             Hamid Syed
Internet Draft                                            Gary Kenward
draft-hamid-seamoby-ct-reqs-00.txt                     Nortel Networks
Expires: September 2001                                    March, 2001

            General Requirements for a Context Transfer Framework

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
   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

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


   This document attempts to capture a set of general requirements for
   a context transfer framework to replicate and synchronize the
   context associated with a mobile node's traffic (as it moves) from
   one access router to any potential candidate access router(s).

1  Introduction

   In an IP network that supports mobile nodes, it is preferred that
   the service provided to the user be maintained. This means that the
   user experiences no perceptible degradation in service capability
   or service quality, as the mobile node is moved between points of
   attachment to the network. In order to provide both service
   capability and service quality, the routing/switching elements of
   the IP access network must establish and maintain configuration and
   state information in support of the traffic to and from the mobile.
   This information is referred to as the "context" associated with a

   Syed, Kenward         Expires September, 2001              [Page 1]

   draft-hamid-seamoby-ct-reqs-00.txt                      March, 2001

   mobile's traffic. Context may include features like authentication,
   authorization and accounting state, security state, header
   compression state, quality of service state, multicast group
   membership state, buffer state, etc [2]. The context associated
   with the mobile node's active micro-flows needs to be transferred
   or replicated between the access routers to enable the seamless
   handover of the micro-flows.

   This document attempts to capture a set of general requirements for
   a context transfer framework to replicate and synchronize the
   context associated with a mobile node's traffic (as it moves) from
   one access router to a group of potential candidate access routers.
   The requirement analysis in this document considers the reference
   architecture described in [2] as a baseline.

2  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119 [1].

3  Terminology

   The terminology and the definitions used in the document are mostly
   taken from [2]. The few additional terms used in this document are
   defined as follows;

3.1 Coverage Area (CA)

   The coverage area for an AR can be defined in terms of the access
   points (APs) that the AR may serve due to network topology or
   configuration. An access router may have one or more APs in its
   coverage area.

3.2 Forwarding Path Handover Scenarios

3.2.1 Make-before-break

   This is a term used for handover cases where the new access router
   can see the actual micro-flows from the MN and enough time is made
   available before the MN breaks its attachment from the current
   access router. In such cases, the forwarding path for the packets
   of an IP micro-flow changes gradually and the new access router
   establishes the forwarding support in parallel with the active
   access router. In essence, separate forwarding paths are created
   for the IP micro-flow and subsequent packets are forwarded either
   by the current or the new AR or by both of them. The later
   situation is possible when copies of packet are forwarded to both
   the ARs.

   Syed, Kenward                 Expires September, 2001      [Page 2]

   draft-hamid-seamoby-ct-reqs-00.txt                      March, 2001

3.2.2 Break-before-make

   In this scenario, the MN detaches itself from the current access
   router before it finds a new access router for its flows. In this
   situation, the forwarding path of an IP micro-flow changes
   abruptly: the active access router (current point of attachment
   for mobile node) stops supporting the micro-flow before any new AR
   has established the forwarding support.

3.3 Context Transfer Scenarios

3.3.1 Proactive Context Transfer

   The context information required to completely support an IP micro-
   flow is replicated to the access router(s), that detect the
   presence of MN in its coverage area, in advance of the first packet
   arrival to one or any of the ARs. A proactive context transfer can
   be performed in each of the handover scenarios described above.

3.3.2 Reactive Context Transfer

   The context information required to completely supporting an IP
   micro-flow is replicated to the access router at the instant when a
   packet from that micro-flow arrives at the new access router. The
   reactive context transfer is applicable to make-before-break as
   well as to break-before-make forwarding scenario.

4  General Requirements for a Context Transfer Framework

   In this section, we attempt to capture the general requirements for
   the transfer of context to help seamless handover of MN's traffic.
   The general requirements can be categorized in to two functional
       - Generic architectural approach
       - Context transfer protocol

4.1 Generic Architectural Approach

   A MN may have connectivity through more than one access points (AP)
   at any time. The determination of which APs are communicating with
   the MN is dependent entirely on the link characteristics and the
   layer 2 protocol and services. If the APs that can detect the
   arrival of the MN in the coverage area are connected to the same AR
   for IP connectivity, no context transfer is required. However, if
   the APs in contact with the MN are connected to two or more ARs,
   then the MN may choose to have its bearer connectivity through any
   of the ARs. In this situation, the ARs that detect a new arrival
   of a MN in their coverage area, become candidates for forwarding
   the MNs traffic. To prepare for a seamless handover, all of these
   ARs must be prepared to support the traffic by a replication of the
   context associated with the active micro-flow(s) of the MN.

       - The framework MUST support one-to-many context transfer

   Syed, Kenward          Expires September, 2001              [Page 3]

   draft-hamid-seamoby-ct-reqs-00.txt                       March, 2001

   The access router requires an event when a mobile node is found in
   its coverage area. This event will trigger a notification to layer 3
   of any arrival/departure of a mobile node to/from the coverage area
   of the AR.

         - The framework MUST consider defining the characteristics of
           the mobile arrival or departure notification or event to the
           access router

         - The mobile arrival/departure event MUST be independent of
           the layer 2 mechanism

   A seamless handover of the MN's micro-flows could be supported by
   performing an advance replication of the context associated with
   the MN to one or more access routers before the actual micro-flow(s)
   are re-directed to either of the access routers.

        - The framework MUST support proactive context transfer

   The vagaries of layer 2 handoff mechanism ensure that a proactive
   transfer may not always be possible and there may be cases where
   conditions do not allow to transfer the context before the actual
   traffic starts to flow through the access router

        - The framework SHOULD support reactive context transfer

   There could be various possible alternatives for context transfer in
   terms of the network entities that may participate in the context
   transfer process. Some of the approaches are captured in [2] with the
   pros and cons of each. The main distinction being a single entity
   driving the context transfer (e.g. MN driven, a central repository or
   any functional entity in the network) versus a distributed approach
   where the access routers control and perform the context transfer
   between each other. Any single or central entity approach may face
   severe scalability problems as the number MNs or the number of
   handovers increases. Moreover, the most updated context information
   (specially the operational context information) could only be
   available at the access router(s).

        - The framework MUST support a distributed transfer approach in
          which the access routers perform the actual transfer of

   The actual context associated with a MN's active micro-flow(s)
   reflects the service treatment parameters that were agreed upon
   between the requesting application and the network. Various protocols
   participate in setting up, for example, a QoS session and some or all
   of them may require to maintain a state for that session. A few
   examples of the context types are captured in [2]. Looking at the
   types of the context, it is quite possible that more than one physical
   or functional network entity may be involved maintaining pieces of the
   context due to the interaction of

   Syed, Kenward           Expires September, 2001               [Page 4]

   draft-hamid-seamoby-ct-reqs-00.txt                         March, 2001

   different protocols with different network entities. A real-time
   distributed context transfer approach requires that only one
   functional entity is responsible for collection and transfer of the
   context between the access routers.

         - The framework MAY consider the definition of a mechanism for
           collection of context to a single functional entity residing
           at the access router.

         - The framework MUST define a single mechanism to transfer
           various types of context.

4.2 Context Transfer Protocol

   The context transfer protocol is the mechanism to transport the
   context information from the source of context information to any new
   access router identified as potential candidate for the context. The
   process will end up with a replication of the context information from
   the source access router to the candidate access router. There could
   be a number of requirements for such a protocol:

        - The protocol MUST be reliable. This means a 100% reliable
          transfer of information to the intended destination(s) with
          zero loss, no duplication, no mis-ordering of the information.

        - Considering a scenario of reactive context transfer, the
          protocol MUST be fast enough to transfer the context
          information in a time frame so that the transferred still
          remains meaningful at the candidate access router.

   The context available at the any of the potential candidates at any
   given time may not reflect the real-time changes occurred to the
   conetxt since the last transfer/update. Example of such changes may
   include addition of any new micro-flow(s) or deletion of the existing

        - The protocol MUST provide a synchronization mechanism to keep
          the context updated within the potential candidates of the
          context. The update include any micro-flow(s) added or deleted
          since the last update.

   The context information contains pieces of the information which is
   calculated or updated on a per packet basis. Such an information is
   defined as real-time or operational context in [2]. It is important
   to consider the synchronization of real-time information within the
   access routers. However, there could be certain tradeoffs in
   considering the synchronization of real-time information. For example,
   in a proactive context transfer scenario, the transferred real-time
   information may become irrelevant or obsolete at the new access
   router. This is because the instant of time it was last updated and

   Syed, Kenward                Expires September, 2001          [Page 5]

   draft-hamid-seamoby-ct-reqs-00.txt                         March, 2001

   the time when the access router receives the first packet of the
   actual micro-flow(s) (to which the information belongs) could be large
   enough and the information may not represent the latest update
   occurred for the micro-flow(s). Even for a reactive transfer mode, by
   the time the information is transferred to the new access router, it
   may become obsolete or irrelevant.

        - The update SHOULD include the synchronization of the real-time
          or operational context information (see [2] for definition of
          real-time context)

   The amount of signaling required initiating a context transfer will
   add to the delay in the actual transfer. The protocols like TCP [4]
   and COPS [5] requires initial handshake mechanism between the entities

        - The context transfer protocol SHOULD NOT introduce extra
          signaling overhead to initiate the actual transfer.

   The total time taken to replicate context to the candidates of the
   context depends mainly on the number of protocol exchange to complete
   a context transfer. In a reactive context transfer scenario, this time
   becomes crucial as the context transfer must complete in a minimum
   time to keep service disruption to a minimum.

        - The transfer SHOULD complete with minimum number of protocol
          exchange between the source and the candidate (access routers)
          of the context data.

        - The protocol SHOULD have minimum complexity in terms of
          buffering or re-ordering mechanism

        - The protocol MUST sustain the security of data transfer.

   The intent of the pro-active context transfer is mainly to allow the
   context candidates to process the information against their
   capabilities and determine whether the current set of capabilities can
   afford to "admit" the MN's traffic. If any of the potential candidates
   of the context cannot admit one or more micro-flow(s), the context
   transfer to that access router has obviously failed. In a heterogeneous
   network, it is very likely that one or more of the context receiving
   access routers will not be able to support the whole context associated
   with the MN's traffic due to different set of available capabilities.
   However, a seamless handover of the mobile node's active sessions
   require an intelligent decision to be made at the access router about
   selecting one access router within the potential candidates. A feedback
   of the admission control result from each context candidate to an
   entity responsible for the making a handover decision could support a
   seamless handover process.

   Syed, Kenward                Expires September, 2001           [Page 6]

   draft-hamid-seamoby-ct-reqs-00.txt                          March, 2001

        - The context transfer protocol MUST support a feedback mechanism
          of the admission decision result on each transfer for an
          intelligent handover decision to be made

        - The context transfer protocol MUST define interface with the
          micro-mobility mechanism [3].

   In a situation where a single access router is not available to support
   the whole context associated with a MN's traffic, a mechanism could be
   required to negotiate the handover of the active sessions to more than
   one new access router.

        - The context transfer protocol MAY provide a negotiation
          mechanism to deal with the failed admission

5. References

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

   [2] The seamoby CT design team, "Context transfer: problem statement",
       draft-ietf-seamoby-context-transfer-problem-stat-00.txt, Feb 2001.

   [3] The seamoby MM design team, "Micro-mobility: problem statement",
       draft-ietf-seamoby-mm-problem-00.txt, Feb 2001.

   [4] "Transmission Control Protocol", RFC 793, September 1981.

   [5] D.Durham et. al, "The COPS (Common open Policy Services) protocol",
       RFC2748, January 2000.

6. Acknowledgments

   The contents of this draft are a result of the discussions within
   the Nortel Networks Advanced Wireless Network Technology Lab and
   we would like to thank all the members who contributed in the

7. Author's Address

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

8. Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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

   Syed, Kenward                Expires September, 2001          [Page 7]

   draft-hamid-seamoby-ct-reqs-00.txt                         March, 2001

   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

   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

   Syed, Kenward                Expires September, 2001        [Page 8]

   draft-hamid-seamoby-ct-framewk-reqs-00.txt               March, 2001

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