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