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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
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",
"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 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
areas
- 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
context.
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
micro-flow(s).
- 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
involved.
- 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
discussions
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
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, Kenward Expires September, 2001 [Page 8]
draft-hamid-seamoby-ct-framewk-reqs-00.txt March, 2001