Internet DRAFT - draft-hamid-seamoby-ct-fwk

draft-hamid-seamoby-ct-fwk





SeaMoby Working Group                                    Hamid Syed
Internet Draft                                         Gary Kenward
Document: draft-hamid-seamoby-ct-fwk-00.txt         Nortel Networks

                                                       June 4, 2001
                      

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

   The distribution of this memo is unlimited. This memo is filed as
   <draft-hamid-seamoby-ct-fwk-00.txt>, and expires November 2001.
   Please send comments to the authors.

Copyright Notice

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


Abstract

   This document proposes a framework for context transfer between the
   access routers. The framework identifies the various functional
   elements that participate in the process of context transfer and the
   protocols required to exchange information between the functional
   entities. Included are a few samples of context transfer scenarios
   to assist in explaining the interactions of the entities in the
   framework.


1  Introduction

   In networks where hosts are mobile, the success of real-time
   sensitive services like VoIP telephony, video, etc. depends heavily
   on the ability of the network to support handover of the MN's
   traffic from one access router to the other as the MN moves with
   minimum or no service disruption. The ability of a new access router
   to support the same service quality after handoff is determined by
   the router's built-in capabilities, by the availability of the


Syed                     Expires November 2001                  [Page 1]
Internet Draft                                Context transfer Framework


   necessary router resources, by the availability of unused bandwidth
   on the links that the traffic must traverse to and from the router,
   and, by the timely available of the service support context at the
   router. The support context referred to here is comprised of the
   information necessary to support the all the committed service
   features, such as AAA, header compression, Differentiated Services,
   Integrated Services, policy enforcement, etc. Each context is
   initially established when the corresponding service is set-up
   between the mobile node and the network, and changes over time as
   the components supporting the service features change state. In
   order for this context to be available at a new access router after
   handoff, it must be replicated from the access router currently
   supporting the MN's traffic. The replicated context must represent
   the most recent support state. The general requirements for a
   framework for context transfer are captured in [3].
   This document proposes a framework for context transfer between the
   access routers. The framework identifies the various functional
   elements that participate in the process of context transfer and the
   protocols required to exchange information between the functional
   entities.


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


3 Terminology

   The terminology and the definitions used in the document are for the
   most part taken from [3]. This section defines few additional terms
   that are used in this document to explain the context transfer
   framework.

   - Context Group (CG): A logical grouping of access routers. The
     context group is comprised of the AR currently supporting a given
     MN's microflows, and those ARs maintaining an updated replica of
     the context associated with the MN's active microflows. These 
     latter members may never be required to forward the MN's microflows.

   - Context Transfer Source (CTS): is an AR that is actively
     supporting one or more active microflows of a MN. It transfers
     the context of the microflows it is supporting to one or more
     context group candidates.

   - Context Group Candidate (CGC): is an AR that receives a
     notification of a MN arriving in its communication area. The AR
     thus becomes a candidate for transfer of the context associated
     with the MN's active microflows.

   - Configuration Context: represents the part of the over all
     context information (for each of the sub-context associated with
     the MN's active sessions) that remains unchanged throughout the
     life of the session. Examples of such information could be the
     bandwidth requirements for each session between the MN and the
     Access Network, the QoS parameters such as the DSCP and user
     authentication information that is determined for the MN at the
     time of its attachment to the network.


Syed                     Expires November 2001                  [Page 2]
Internet Draft                                Context transfer Framework


   - State Context: represents the part of the over all context (for
     each active microflow) that is updated on each packet arrival.
     Examples of such information include the metering and header
     compression states.


4 Requirements for context Transfer framework

   The proposed framework covers three functional areas:
       - context group management mechanism
       - distributed context transfer approach
       - context transfer protocol

   The requirements that lead to a distributed approach to context
   transfer and the context transfer protocol are captured in [3]. The
   following sub-section presents a discussion of the requirements for
   the context group management mechanism.


4.1 Additional Requirements for Context Group Management

   Performing context transfer proactively provides for the preparation
   of the ARs in anticipation of a context transfer. The notion of a
   context group is introduced in support of the proactive context
   transfer. Each member of the context group maintains an updated
   replica of the context associated with the MN's traffic. In a
   reactive context transfer mode, the source of the context changes
   and this information needs to be propagated to the group members.
   Moreover, forming of a context group, the addition of ARs that
   become candidates for a possible handoff, and the removal of ARs
   that are no longer candidates require a management mechanism.
   Context group management is a dynamic process, with some
   requirements, as described below.

4.1.1 The context group management mechanism MUST define the events for
      inclusion and removal of the ARs from the context group.

4.1.2 The context group management mechanism MUST support collection
      and distribution of the AR's group membership information.

4.1.3 The context group management mechanism MUST define how to
      Identify the context source AR for the newly joined AR.


5  Framework Discussion

   This section provides the details of a framework to replicate the
   context associated with a MN's traffic flows to one or more
   receiving ARs. The proposed framework identifies the functional
   entities participating in the context transfer and describes the
   role of each functional entity. The context transfer framework
   includes definition of one key network event and two protocols.

5.1 Functional Elements of the Framework

   The major functional elements of the context transfer framework are
   the context transfer agent (CTA), and the membership collection and
   distribution function (MCDF). Figure 1 shows a simple configuration
   involving these two functional elements and the protocols required.


Syed                     Expires November 2001                  [Page 3]
Internet Draft                                Context transfer Framework


                                 +--------+
                                 |        |
                 +-------------->|  MCDF  |<------------+
                 |               |        |             |
                 |               +--------+             |
                 |                                      |
                 |MDP                             MDP   |
                 |                                      |
                 |                                      |
                 |                                      |
                 |                                      |
            +----|----+                            +----|----+
            |    v    |                            |    v    |
            |  +----+ |            CTP             | +----+  |
            |  |CTA |<------------------------------>| CTA|  |
            |  +----+ |                            | +----+  |
            |         |                            |         |
            |  AR     |                            |  AR     |
            +---------+                            +---------+

           Figure 1: The CT framework entities and the protocols


5.1.1 Context Transfer Agent (CTA)

   The context transfer agent (CTA) is the functional entity that
   actively participates in the process of context transfer. Residing
   at the peers of the context transfer, the CTA is responsible for
   collection of all of the information required to support the active
   microflow associated with the MN to create the overall context that
   needs to be transferred. The CTA stores this context information in
   a form required by the context transfer protocol to carry between
   the peers of the context transfer.

   The CTA also communicates with the membership collection and
   distribution function (MCDF) assisting MCDF in context group
   management. The CTA exchanges the membership information with MCDF
   through a standardized membership distribution protocol (MDP).
   The CTA residing at the receiver of the context information
   distributes the received information to the relevant entities for
   processing. The first operation to be invoked at the receiver on
   reception of context is the admission control. The CTA may help in
   intelligent handover decision making by relaying the outcome of the
   admission control decision to the handover decision point (c.f
   section 6).

5.1.2 Membership Collection and Distribution Function (MCDF)

   The membership collection and distribution function (MCDF) is a
   functional entity that administers the formation of context groups.
   It creates and maintains one context group per active MN. The MCDF
   also collects the identification of the ARs that are supporting the
   active microflows of the MN and stores them as potential sources of
   the context for the MN. When an AR receives the notification of the
   MN's arrival in its communication area (thus becomes a context group
   candidate), it communicates with the MCDF (through MDP) to get the
   information of the source of the context (CTS) for the MN.

Syed                     Expires November 2001                  [Page 4]
Internet Draft                                Context transfer Framework


   The MCDF function MAY be mapped to a single physical entity in the
   network or may be distributed throughout the network. If the MCDF is
   distributed, a standardized protocol MUST be defined to support the
   distribution and coordination of the membership information.
   Definition of this protocol is outside the scope of this document.


5.2 Protocols/Events

   The context transfer framework includes the definition of one key
   network event and two protocols.

5.2.1 Mobile Arrival/Departure Event (MADE)

   The MADE is a notification delivered to an AR when the MN enters or
   leaves its communication area. The requirements for such an event
   definition have been captured in [3]. The arrival or departure event
   enables the AR to join or leave a context group. The AR reacts to
   the arrival event by initiating a communication with the MCDF (as
   the context group candidate) for the identification of the source of
   the context. Similarly, a departure event initiates the removal of
   the AR from the context group associated with the MN.


5.2.2 Membership Distribution Protocol (MDP)

   The membership distribution protocol (MDP) enables the MCDF to
   effectively manage the context groups. It exchanges the context
   group membership with the CTA.

   The MDP carries the following information:

       - identification of the mobile node
       - context group information
       - identification of the AR (or ARs) that is to act as the source
         of the context transfer (CTS)

5.2.3 Context Transfer Protocol (CTP)

   The context transfer protocol (CTP) provides mechanisms to transfer
   context information for a MN's traffic from the source (CTS) to the
   receiver, the CGC. The requirements for such a protocol are captured
   in [3].


6  Interworking with the Mobility Framework

   The goal of reducing the effect of mobility on the service level
   received by the MN through context transfer cannot be achieved
   without providing a close interworking between the context transfer
   process and any mechanism that is responsible for the actual traffic
   re-direction from one AR to the other. For this reason, discussion
   of an interface between the context transfer and the mobility
   framework would help clarifying the interaction between the two
   frameworks. The context transfer framework discusses the roles of
   one functional entity in the mobility framework and an interface
   with the mobility framework. This entity in the mobility framework


Syed                     Expires November 2001                  [Page 5]
Internet Draft                                Context transfer Framework 


   may have different names for different mobility mechanisms. The
   context transfer framework, however, is a generic framework that
   should interwork with any mobility mechanism.

6.1 HandOver Decision Point (HODP)

   The HandOver Decision Point (HODP) represents the functional
   capability that is provided by the mobility framework. For a given
   mobility solution, it will likely have a different name and may be
   effected by a collection of network elements. The HODP is the entity
   that determines which of the ARs would be the best candidates for
   supporting an imminent handoff of a MN's traffic. This determination
   should be based upon the admission control status provided by the
   CTA associated with each AR in the context group.
   Since the HODP is a functional element that deals primarily with the
   Handoff of micro-flows, it is not a part of the context transfer
   framework, per se. However, it is a primary collaborator in context
   transfer, and it is required to describe how the various context
   transfer scenarios would transpire.

6.2 CTA-HODP Interface

   A few transactions between the CTA and the HODP functions are
   necessary to discover a suitable handover candidate for the MN's
   traffic. This requires an interface definition between the two
   entities. The entity HODP can be co-located with the CTA in which
   case the CTA-HODP interface could have different implementations.
   However, if the HODP is an entity that is not located in the same
   physical entity as the CTA then the CTA-HODP interface would require
   the standardized handover candidate discovery protocol.
   Since HODP is an entity outside context transfer (lies within the
   mobility framework), the details of this interface are outside the
   scope of this document.


7  Additional Features Supported by the Framework

7.1 Progressive Context Transfer

   The proactive context transfer allows the transfer of the context
   for the MN to the context group members before an actual handover is
   required. During the time period from when the context is
   transferred proactively and the actual handover of the
   MN's microflows to any of the context group members occurs, the
   context at the context transfer source (CTS) may get changed. These
   changes may include the addition or deletion of one or more
   microflows from the MN. The context information for the MN is
   composed of the configuration and state components (see section 3).
   The intent of the proactive transfer is to prepare the potential
   context group candidates by replicating the information required to
   perform an admission control at each of the candidates. The state
   component, information that is updated on each packet arrival at the
   source, plays no role in the admission decision.

   By separating the context into configuration and state components,
   context transfer can be performed in a progressive way. For a
   proactive context transfer mode, the information required to perform


Syed                     Expires November 2001                  [Page 6]
Internet Draft                                Context transfer Framework


   the admission decision (i.e. the configuration components) should be
   transferred proactively. Moreover, since this information changes
   infrequently, it should be kept synchronized between the CTS and the
   rest of the context group members. The events to trigger an update
   from the CTS to the rest of the context group members are simply the
   addition and deletion of microflows to the overall context
   associated with the MN's traffic at the CTS. The second stage of the
   context transfer, updating the state components, should be coupled
   with the actual handover. The context transfer here carries the
   information that is updated on each packet arrival and is now
   required at the new AR supporting the MN's traffic.  This is
   effectively a one-to-one transfer, as only the new serving AR
   requires this information.

7.2 Demand and Reservation states in the proactive context transfer

   The proactive transfer of configuration context and the outcome of
   the admission control on this context determines the level of
   support for the MN's traffic if the MN's traffic is re-directed to
   the AR. Since the transfer of the context to an AR and actual
   handover of the traffic to the AR may not happen at the same time,
   the resource availability at the AR may not be the same as it was
   reported after the admission control process on transferred context.
   The framework provides concepts by which the mobility mechanism can
   make effective use of the admission control information and the
   reported status of the resource availability. This is accomplished
   by allowing the mobility mechanism to put the AR into one of the two
   states in terms of resources: the demand and the reservation states.
   In the demand state, the AR has essentially acknowledged that it has
   the capability to support the MN's traffic, but no attempt is made
   to reserve resources. Thus, when the handover is finally attempted,
   the necessary resources may not be available and the handover to the
   AR may fail partially or completely. This option minimizes resource
   use, and requires some level of over-provisioning to ensure an
   acceptably low level of failed handovers. This could be used for the
   services that may not require immediate resource availability.
   Examples could be http sessions etc.

   In the reservation state, an AR not only acknowledges that it has
   the capability to support the MN's traffic, it also reserves the
   necessary resources. In this case, when the handover is finally
   attempted, it should succeed. This option minimizes handover
   failures, at the expense of having resources allocated for potential
   handovers that may never occur. This could be useful for services
   that cannot tolerate disruptions like VoIP etc. The reservation mode
   guarantees the availability of resources for such services
   immediately after the handover.


8  Example Scenarios based on the context transfer framework

   This section provides some scenarios to explain the interworking of
   the various functional entities and the corresponding protocols of
   the framework. Some mnemonics are used for the sake of brevity:

    - MN54 is a moving mobile node in the access network. Initially,
      MN54 does not have any active microflows through any of the
      access routers but is within the coverage area of AR1.
    - AR1 is an access router in the network and CTA1 is the context
      transfer agent at the AR1.


Syed                     Expires November 2001                  [Page 7]
Internet Draft                                Context transfer Framework


    - AR7 is another access router in the same access network and CTA7
      is the context transfer agent at AR7. At some point in time, AR7
      receives a MADE notification of the presence of the MN54 in its
      coverage area due to the MN's mobility.
    - MCDF is the membership collection and distribution function.
    - HODP is an entity within the mobility framework that interacts
      with the CTA within context transfer framework.

8.1 Context Group Management Scenarios

   The addition and deletion of ARs to the context group, tracking the
   source(s) of the context group associated with each active MN in the
   network requires a context group management mechanism in place.
   This mechanism also distributes the identity of the context source
   to the CGCs, which helps the CGCs initiating a context transfer to
   send a request directly to the source of the context. The following
   scenarios explain CG management in the context transfer framework.

8.1.1 Joining the CG

     1. AR1 receives a mobile arrival notification (MADE) for MN54. AR1
        now becomes the context group candidate for MN54's context;
     2. CTA1 informs the MCDF that AR1 is the CGC for MN54's context
        group, using MDP;
     3. Assuming that MCDF does not have any existing CG information
        for MN54, it informs CTA1 that no context transfer source is
        available, using MDP;

8.1.2 Context and Context Group Creation

     4. MN54 establishes one or more microflows through AR1;
     5. CTA1 collects and stores the context associated with MN54's
        active  microflows;
     6. CTA1 informs the MCDF that it is supporting the active
        microflows for MN54 (and thus becomes the source of the MN54's
        context),using MDP;
     7. MCDF creates a context group 'CG54' for the MN54's context
        with AR1 as the context transfer source (CTS);

8.1.3 Membership Distribution

     8. AR7 receives a mobile arrival notification (MADE) for MN54. AR7
        now  becomes a context group candidate for MN54's context;
     9. CTA7 informs the MCDF that AR7 is a CGC for MN54's context
        group, using MDP; OR MCDF receives a request from CTA7 for
        joining the CG associated with MN54, using MDP;
     10. The MCDF informs CTA7 with the following information,
        using MDP;

- list of sources (CTS IDs) for the MN's microflows (only CTA1
          in this case)
        - context group information such as context group identification

8.1.4 Updating the MCDF as the source for a CG changes

     11. AR7 receives a change of forwarding path for MN54's traffic 
         from HODP;

 
Syed                     Expires November 2001                  [Page 8]
Internet Draft                                Context transfer Framework 


     12. Being the new source for MN54's context, CTA7 informs the MCDF
         that it is supporting the active microflows for MN54, using MDP;
     13. CTA1 informs the MCDF that it is no longer the source
         of the context for MN54's traffic, using MDP;
         - If CTA1 still supports one or more microflows associated with
           the MN54's traffic, it will continue as one of the sources for
           the context within the CG associated with MN54;

8.1.5 Leaving the context group

     14. AR1 determines that the MN54 is leaving its communication area 
         through a mobile departure event (MADE);
     15. Since AR1 is not the source of the context within the context 
         group but just a context group member (replicating the context), 
         it will only have to inform the source of the context to
         discontinue any updates. No update to the MCDF is required in 
         this case.

    The Figure 2 below combines the context group management (CGM)
    scenarios in a single message flow diagram.

       +------+                 +------+                   +------+
       | CTA1 |                 | CTA7 |                   | MCDF |
       +------+                 +------+                   +------+
          |                        |                          |
          |---+                    |                          |
          |   |(1)                 |                          |
          |<--+                    |      (2)                 |
          |------------------------|------------------------->|
          |       (3)              |                          |
          |<-----------------------|--------------------------|
          |                        |                          |
          |---+                    |                          |
          |   |(4) & (5)           |                          |
          |<--+                    |                          |
          |                        |         (6)              |
          |------------------------|------------------------->|
          |                        |                      +------+
          |                        |                      | (7)  |
          |                        |                      +------+
          |                        |                          |
          |                        |---+                      |
          |                        |   | (8)                  |
          |                        |<--+                (9)   |
          |                        |------------------------->|
          |                        |         (10)             |
          |                        |<-------------------------|
          |                        |                          |
          |                        |---+                      |
          |                        |   | (11)                 |
          |                        |<--+                      |
          |                        |             (12)         |
          |                        |------------------------->|
          |                        |              (13)        |
          |------------------------|------------------------->|


Syed                     Expires November 2001                  [Page 9]
Internet Draft                                Context transfer Framework 


          |                        |                      +------+
          |                        |                      | (14) |
          |                        |                      +------+
          |---+                    |                          |
          |   |(15)                |                          |
          |<--+                    |                          |


             Figure 2: Message Flow Diagram for the CGM Scenarios


8.2 Context Transfer Scenarios

    The context transfer is initiated from the CGC to the CTS when the
    newly joined context group member has already retrieved the CTS
    information through the context group management mechanism.
         - CTA1 is supporting the MN54's microflows and hence is the CTS
           within the CG for MN54.
         - CTA7 is a CGC and has already retrieved the CTS information
           from the MCDF.

8.2.1 Proactive Context Transfer Mode

8.2.1.1 Configuration Context Transfer

     1. CTA7 sends a context transfer request to CTA1 for MN54's
        configuration context, using CTP;
     2. CTA1 transfers the configuration context for MN54, using CTP;

8.2.1.2 Context Processing and Interworking with Mobility Mechanism

     3. CTA7 processes the configuration context and determines the
        available support for MN54's traffic;
     4. CTA7 informs the HODP about the available support for the
        MN54's traffic, using the CTA-HODP interface;
         - if CTA7 is unable to admit MN54's traffic, it may opt to
           remain as a CGC and continue receiving the context updates
           from the source, using CTP;
         - OR CTA7 may choose to leave the context group, using MDP;
           (in this case it will no longer be the CGC and will not 
           receive any context updates for MN54).
     5. The HODP determines demand and reservation states for the
        MN54's microflows. It may choose all the microflows for either
        demand or reservation states OR it may select some microflows
        under demand state and others in reservation state.

8.2.1.2.1 Demand state

     6. In demand mode, the HODP only acknowledges the CTA7's response,
        using the CTA-HODP interface. The CTA7, in this case, makes no
        attempt to reserve the resources for MN54's traffic;

8.2.1.2.2 Reservation State

     7. In reservation mode, HODP requests CTA7 to reserve the resources
        to support MN's microflows, using the CTA-HODP interface;
     8. CTA7 reserves the resources and sends the confirmation to the
        HODP, using the CTA-HODP interface;


Syed                     Expires November 2001                 [Page 10]
Internet Draft                                Context transfer Framework


8.2.1.3 Configuration Context Update

     9. MN54 initiates a new microflow through CTA1 at some time while
        handover of the MN54's traffic has not yet performed to any of 
        the context group members. The new microflow is added to the
        MN's context at the CTA1;
     10. CTA1 sends an update on the configuration context of the new
         microflow to the context group members (only CTA7 in this
         case), using CTP;

8.2.1.4 State Context Transfer

     11. CTA7 receives a handover notification for MN54's traffic from 
         the HODP.
     12. CTA7 initiates a state context transfer request to the CTA1, 
         using CTP;
     13. CTA1 transfers the state context associated with the  MN54's 
         traffic to the CTA7, using CTP;
     14. For demand state microflows, the CTA7 processes the current 
         configuration context and determines the available support
         for MN54's microflows in demand state.
     15. CTA7 informs the HODP about the available support for the 
         MN54's traffic in demand state, using the CTA-HODP interface;
     16. For a complete support available at the CTA7, the HODP
         acknowledges the information, using the CTA-HODP interface
          - For a scenario where partial or no support was available at
            the CTA7 or CGC, the HODP must take necessary actions to 
            redirect the MN54's traffic to a suitable handover candidate.
            Since HODP belongs to mobility mechanism, the discussion of
            partial or complete failure of the admission control is out 
            of the scope of this document.
 
     Figure 3 below shows the message flow between the functional
     entities in a proactive mode context transfer


       +------+                 +------+                   +------+
       | CTA1 |                 | CTA7 |                   | HODP |
       +------+                 +------+                   +------+
          |          (1)           |                          |
          |<-----------------------|                          |
          |                        |                          |
          |          (2)           |                          |
          |----------------------->|                          |
          |                        |                          |
          |---+                    |                          |
          |   |(3)                 |                          |
          |<--+                    |                          |
          |                        |         (4)              |
          |                        |------------------------->|
          |                        |                          |
          |                        |                      +------+
          |                        |                      | (5)  |
          |                        |                      +------+
          |                        |                          |
          |                        |                    (6)   |
          |                        |<-------------------------|


Syed                     Expires November 2001                 [Page 11]
Internet Draft                                Context transfer Framework


          |                        |         (7)              |
          |                        |<-------------------------|
          |                        |                          |
          |                        |             (8)          |
          |                        |------------------------->|
          |---+                    |                          |
          |   |(9)                 |                          |
          |---+                    |                          |
          |                 (10)   |                          |
          |----------------------->|                          |
          |                        |          (11)            |
          |                        |<-------------------------|
          |        (12)            |                          |
          |<-----------------------|                          |
          |                        |                          |
          |----------------------->|                          |
          |            (13)        |---+                      |
          |                        |   |(14)                  |
          |                        |<--+                      |
          |                        |         (15)             |
          |                        |------------------------->|
          |                        |           (16)           |
          |                        |<-------------------------|


            Figure 3: Context Transfer (Proactive Mode)

8.2.2 Reactive Context Transfer Mode

     1. The CTA7 receives a trigger for reactive context transfer. The 
        trigger for reactive context transfer should be different from
        the proactive context.
     2. The CTA7 retrieves the CTS information from the MCDF using the
        context group management mechanism;
     3. The CTA7 initiates a context transfer request to the CTA1,
        using CTP. The context transfer request in a reactive context
        transfer indicates the transfer of both configuration and 
        state context;
     4. CTA1 transfers the complete context associated with the MN54's
        traffic to the CTA7, using CTP;
     5. CTA7 processes the configuration context and determines the
        available support for MN54's traffic;
     6. CTA7 informs the HODP about the available support for the 
        MN54's traffic, using the CTA-HODP interface;
     7. For a complete support available at the CTA7, the HODP
        acknowledges the information, using the CTA-HODP interface
          - For a scenario where partial or no support was available at
            the CTA7 or CGC, the HODP must take necessary actions to 
            redirect the MN54's traffic to a suitable handover candidate.
            Since HODP belongs to mobility mechanism, the discussion of 
            partial or complete failure of the admission control is out
            of the scope of this document.

    The figure 4 below shows the interactions in the reactive context
    transfer mode.


Syed                     Expires November 2001                 [Page 12]
Internet Draft                                Context transfer Framework 


       +------+                 +------+                   +------+
       | CTA1 |                 | CTA7 |                   | HODP |
       +------+                 +------+                   +------+
          |                        |                          |
          |                        |                          |
          |                        |---+                      |
          |                        |   |(1)                   |
          |                        |<--+                      |
          |                        |                          |
          |                        |---+                      |
          |                        |   |(2)                   |
          |                        |<--+                      |
          |          (3)           |                          |
          |<-----------------------|                          |
          |          (4)           |                          |
          |----------------------->|                          |
          |                        |---+                      |
          |                        |   |(5)                   |
          |                        |<--+                      |
          |                        |         (6)              |
          |                        |------------------------->|
          |                        |         (7)              |
          |                        |<-------------------------|


             Figure 4: Context Transfer (Reactive Mode)


9  Recommendations for Future Work

   The general requirements for the context transfer framework are
   captured in [3]. This draft proposes the context transfer framework
   that identifies the major functional entities, their roles, and the
   supporting protocols.

   The next step in this work is the definition of the context transfer
   protocol (CTP) and the Membership Distribution Protocol (MDP). It
   would also be useful to define the characteristics of the Mobile
   Arrival-Departure Event (MADE), the requirements for the HandOver
   Decision Point (HODP) and the CTA-HODP interface (required for the
   handover candidate discovery).


10 Intellectual Property Rights Considerations

   This is to inform you that Nortel Networks has applied for and/or
   has patent(s) that relates to some of the concepts used in this
   document. See http://www.ietf.org/ietf/IPR/NORTEL-GENERAL.

   This submission is being made pursuant to the provisions of IETF IPR
   Policy, RFC 2026, Sections 10.3.1 and 10.3.2.


11 References

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


Syed                     Expires November 2001                 [Page 13]
Internet Draft                                Context transfer Framework



   [2] The seamoby CT design team, "Context transfer: problem
       statement", draft-ietf-seamoby-context-transfer-problem-
       stat-00.txt.
   [3] The seamoby CT design team, " General requirements for a context
       transfer framework", May 2001 (work in progress). draft-ietf-
       seamoby-ct-req.00.txt.


12 Acknowledgments

   We would like to thank the following for their useful input: Bill
   Gage, Louis Hamer.


13 Author's Address

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


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


14 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 organisations, 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.









Syed                     Expires November 2001                 [Page 14]
Internet Draft                                Context transfer Framework