Internet Engineering Task Force Hamid Syed
Internet Draft Gary Kenward
draft-ietf-seamoby-ct-reqs-01.txt Nortel Networks
Expires: March 2001 Pat Calhoun
Black Storm Networks
Madjid Nakhjiri
Motorola
Rajeev Koodli
Nokia
Kulwinder Atwal
Zucotto Wireless
Mark Smith
COM DEV Wireless
Govind Krishnamurthi
Nokia
September, 2001
General Requirements for Context Transfer
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The success of time sensitive services like VoIP telephony, video,
etc., in a mobile environment depends heavily on the ability to
minimize the impact of the traffic redirection during a change of
packet forwarding path. In the process of establishing the new
forwarding path, the nodes along the new path must be prepared to
provide similar forwarding treatment to the IP packets. The transfer
of context information may be advantageous in minimizing the impact
of host mobility on IP services. This document captures the set of
requirements for a context transfer solution and the requirements
for a generic context transfer protocol to carry the context between
the context transfer peers.
1 Introduction
There are a large number of IP access networks that support mobile
hosts. For example, wireless Personal Area Networks (PANs), wireless
LANs, satellite WANs and cellular WANs. The nature of this mobility
is such that the communication path to the host may change frequently
and rapidly.
In networks where the hosts are mobile, the forwarding path through
the access network must often be redirected in order to deliver the
host's IP traffic to the new point of access. The success of time
sensitive services like VoIP telephony, video, etc., in a mobile
environment depends heavily upon the ability to minimize the impact
of this traffic redirection. In the process of establishing the new
forwarding path, the nodes along the new path must be prepared to
provide similar forwarding treatment to the IP packets.
The information required to support a specific forwarding treatment
provided to an IP flow is part of the context for that flow. To
minimize the impact of a path change on an IP flow, the context must
be replicated from the forwarding nodes along the existing path to
the forwarding nodes along the new path. The transfer of context
information may be advantageous in minimizing the impact of host
mobility on, for example, AAA, header compression, QoS, Policy, and
possibly sub-IP protocols and services such as PPP.
An analysis of the context transfer problem is captured in [2]. This
document captures the requirements for a context transfer solution
and the requirements for a generic context transfer protocol to
carry the context between the context transfer peers.
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
Most of the terms used in this document are defined in [2].
Access Router (AR)
An IP router residing in an Access Network and connected to one or
more points of access. An AR offers connectivity to MNs.
4 General Requirements
This section addresses the facilities and services required in the access
network to properly support context transfer. The context transfer
solution will have to assume certain characteristics of the access network
and the mobility solution, and the availability of certain triggering events,
transport options, and so forth. These support capabilities are not
necessarily part of context transfer, per se, but are needed for context
transfer to operate as defined and effect the expected enhancements to MN
traffic handover. For convenience, this collection of support capabilities
are referred to as the "context transfer solution".
4.1 The context transfer solution MUST define the characteristics of the IP
level trigger mechanisms that initiate the transfer of context.
4.2 The IP level context transfer triggers MAY be initiated by a link level
(layer two) event.
4.3 The IP level trigger mechanisms for context transfer MUST hide the
specifics of any layer 2 trigger mechanisms.
Handover at the IP level is a consequence of a change in the physical
path used to communicate between the MN and the access network. The
mechanisms utilized to change the communications path at layer 2 are
specific to the physical characteristics of the medium, and often
specific to the layer 2 transmission technology being used (e.g. TIA
IS 2000, ETSI UMTS R4, IEEE 802.11).
In order for any action to be taken at the IP level to maintain IP
sessions during a layer 2 path change, some indication of the path
change must be made available to the IP level. One example of an
indicator would be the trigger event that initiates context transfer.
Since it is expected that IP handover, and thus context transfer will
work irrespective of the layer 2 technology, the IP level solutions
must not utilize specific layer 2 information. The conditions and
events that caused the generation of an IP level trigger must be
opaque to the IP level. This implies that there are general
characteristics of an IP level trigger that need to be defined so
that the triggers generated by different layer 2 solutions will have
identical semantics at the IP level.
4.4 The IP level context transfer triggers MAY be initiated by IP level
(layer three) signalling.
4.5 Any IP level signalling for Context Transfer MUST be separated from
the actual transfer of context.
4.6 The context transfer solution SHOULD support one-to-many context
transfer.
An MN may have connectivity to the access network through more than
one physical path at any given time, depending upon the
characteristics of the physical medium, and the layer 1 and 2
protocols and services.
The different physical paths may connect into the network via
different ARs. In this scenario, two or more ARs may be candidates
for handover of the MN's traffic and each will require the
appropriate IP context when forwarding commences. Exactly which AR
will be the target of the handover is often not known until the
handover is initiated, and providing the necessary context to all the
candidate ARs can only accelerate the handover process.
A one-to-many context transfer may be achieved using either a series
of point-to-point transfers, or a point-to-multipoint (multicast)
transfer.
4.7 The context transfer solution MUST support context transfer before,
during and after handover.
4.8 The context transfer solution MUST support a distributed approach in
which the Access Routers act as peers during the context transfer.
One main distinction between the various alternative approaches to
context transfer is the choice of the functional entity or entities that
orchestrate the transfer. A context transfer solution that relies upon
the ARs to effect a context transfer should be the most efficient approach,
as it involves the fewest possible entities. At the very least, the number
of protocol exchanges should be less when there are fewer entities involved.
4.9 The entities transferring context MUST have completed a mutual
authentication process prior to initiating the transfer.
It is believed that if a formal authentication exchange (e.g. exchanging
credentials) were done during the context transfer, the computation
overhead for both the sender and the receiver would cause additional and
unnecessary latency to the handoff process. Therefore, the CT peers MUST
exchange credentials prior to any context transfer.
4.10 The context transfer solution SHOULD provide mechanisms to selectively
enable or disable context transfer for particular IP microflows or groups
of IP microflows.
The context associated with an MN's microflows is normally to be
transferred whenever it is required to support forwarding. However,
there may be conditions where it is desirable to selectively disable
context transfer for specific microflows.
For example, it may be desirable to provide an MN with the capability
to disallow the transfer of the context associated with one or more
of its microflows when handover occurs between networks administered
by different operators.
Local mechanisms for allowing context transfer to be disabled on a per
microflow basis have to be provided for in the context transfer solution.
These mechanisms will most likely be captured as part of the CT MIB, and
possibly, as part of a PIB, if policy based management is considered
desirable.
There are other mechanisms and protocols required to manage or control
the per microflow disabling of context transfer. These are clearly
out of the scope of the context transfer work.
4.11 Context information MAY be transferred in phases.
Providing for phased transfers allows the context acquisition
and transfer to be prioritized.
4.12 The context information to be transferred MUST be available at the
AR performing the transfer, prior to the initiation of a given phase
of the context transfer.
To effect a rapid transfer, the context information has to be readily
available when the AR begins a phase of the transfer.
If the context transfer is comprised of a single phase, then all of the
context must be available prior to the transfer initiation.
4.13 The context information provided for transfer MUST be reliable.
The context to be transferred must not only be readily available for
transfer, but the sending AR must ensure that the information is sound.
The context transfer solution may provide mechanisms to support reliable
transfer of context, but the effectiveness of context transfer in enhancing
handover between ARs would very likely be compromised by attempts to
transfer malformed context.
4.14 The context transfer solution MUST include methods for interworking
with any IETF IP mobility solutions.
4.15 The context transfer solution MAY include methods for interworking
with non-IETF mobility solutions.
5. Protocol Requirements
This section captures the general requirements for the context
transfer protocol.
5.1 General Protocol Requirements
5.1.1 The context transfer protocol MUST be capable of transferring all
of the different types of feature context necessary to support the
MN's traffic at a receiving AR.
5.1.2 The context transfer protocol design MUST define a standard
representation for conveying context information that will be
interpreted uniformly and perspicuously by different
implementations.
5.1.3 The context transfer protocol MUST operate autonomously from the
content of the context information being transferred.
5.1.4 The context transfer protocol design MUST define a standard method
for labeling each feature context being transferred.
Various protocols participate in setting up the service support for
any given microflow, and many of these protocols require feature
specific state to be maintained for the life of the IP session. The
context transfer protocol should provide a generic mechanism to carry
context information to an AR, irrespective of the context type.
Given that the desired context transfer protocol is a single, generic
protocol for transferring all feature context, the collection of
information representing the context for a given feature must be
encapsulated into a standard representation and labeled.
Encapsulation is necessary to keep the context for different features
separated. The receiving AR will use the label on an encapsulated
context to associate it with the appropriate service feature and
process the content appropriately.
The context transfer protocol does not need to know the contents of
these nuggets of encapsulated information. Indeed, for the protocol
to be independent from the type of context being transferred, it must
be oblivious the actual context.
5.1.5 The context transfer protocol design MUST provide for the future
definition of new feature contexts.
The context transfer solution must not attempt to define all possible
feature contexts to be transferred. Instead, it must provide for the
definition of new contexts in support of future service features, or
feature evolution. Guidance should be provided to future users of context
transfer on the best approach to defining feature context.
5.2 Transport Reliability
This section is intentionally left blank as the working group is
waiting for a questionnaire from the transport directorate. The result
of the questionnaire will create requirements that will be added in this
section in a later revision of this specification.
5.3 Security
5.3.1 The protocol MUST provide for "security provisioning".
The security of the context information being exchanged between ARs
must be ensured. Security provisioning includes protecting the
integrity, confidentiality, and authenticity of the transfer, as well
as protecting the ARs against replay attacks.
5.3.2 The security provisioning for context transfer MUST NOT
require the creation of application layer security.
5.3.3 The protocol MUST provide for the security provisioning to be
disabled.
In some environments, the security provisioning provided for by the
context transfer protocol may not be necessary, or it may be
preferred to minimize the context transfer protocol overhead.
5.4 Timing Requirements
5.4.1 A context transfer MUST complete with a minimum number of protocol
exchanges between the source AR and the rest of the ARs.
The number of protocol exchanges required to perform a peer to peer
interaction is directly related to the unreliability, resource
consumption, and completion time of that interaction. A context
transfer will require signaling and data exchanges, but, as a general
rule, by keeping the number of these exchanges to a minimum, the
reliability, resource utilization and completion delay of the
transfer should improve.
5.4.2 The context transfer protocol design MUST minimize the amount of
processing required at the sending and receiving Access Routers.
If the context transfer protocol requires the context information to
be transferred in a form that requires significant additional
processing at each AR, delays may be incurred that impact the
reliability of the context. In other words, the context may become
obsolete before it can be reconstructed at the receiving AR.
Also, AR processing delay contributes to the overall context transfer
delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult.
An example of a protocol design that would increase the processing
delay at the receiver is where the context information is segmented,
and the ordering of the segments is not preserved during transfer;
segmenting at the sender, and more likely, re-ordering of the
segments at the receiver could introduce significant additional
AR processing delays.
5.4.3 The Context Transfer protocol MUST meet the timing constraints
required by all the feature contexts.
A given feature context may have timing constraints imposed by the
nature of the service being support. The delivered context must
always comply with the requirements of the service if it is to be
useable.
5.4.4 The context transfer solution MUST provide for the aggregation of
multiple contexts.
5.4.5 If context aggregation is not support by the transport protocol
(via the Nagle algorithm [3]) then the context transfer protocol
MUST provide it.
There may be instances where there are multiple context transfers
pending. To reduce the overall transfer time, as well as transport
overhead that might be incurred by separately transferring each
context, the sending AR may choose to aggregate the contexts and
execute one transfer operation.
Note that if contexts are aggregated, the labelling method required
by 5.1.4 must include an identifier that allows the contexts to be
separated at the receiving AR.
5.5 Context Update and Synchronization
5.5.1 The context transfer protocol MUST be capable of updating
context information when it changes.
5.5.2 A context update MUST preserve the integrity, and thus the
meaning, of the context at each receiving AR.
The context at the AR actually supporting an MN's traffic will
change with time. For example, the MN may initiate new microflow(s),
or discontinue existing microflows. Any change of context at the
supporting AR must be replicated at those ARs that have already
received context for that MN.
5.6 Interworking with handover mechanisms
5.6.1 The context transfer protocol MAY provide input to the
handover process.
5.6.2 The context transfer protocol MUST include methods for exchanging
information with the handover process.
Both context transfer and handover require information on the
AR candidates for handover. The context transfer entities may, in the
process of establishing and supporting context transfer, acquire
information that would be useful to the handover process in
determining the new forwarding path: for example, the outcome of an
admission control decision at a receiving AR.
5.7 Partial Handover
5.7.1 The context transfer protocol MAY provide a mechanism for
supporting partial handovers.
In a situation where no single AR is capable of receiving a handover
of all of an MN's traffic, a mechanism could be provided that would
allow different IP microflows to be handed over to different ARs.
The information transferred to each AR must be limited to only the
context required to support the microflows that are actually handed
over. Thus, the context transfer protocol would need a mechanism for
partitioning the context and transferring each portion to the
appropriate AR.
6 References
[1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997.
[2] Levkowetz et al., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network ",
draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001.
[3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
7 Acknowledgements
Thank you to all who participated in the Seamoby working group context
transfer design team.
8 Author's Addresses
Hamid Syed
100 Constellation Crescent
Nepean, Ontario. K2G 6J8 Phone: 1 613 763 6553
Canada Email: hmsyed@nortelnetworks.com
Gary Kenward
100 Constellation Crescent
Nepean, Ontario. K2G 6J8 Phone: 1 613 765 1437
Canada Email: gkenward@nortelnetworks.com
Pat R. Calhoun
Black Storm Networks
250 Cambridge Avenue, Suite 200
Palo Alto, CA 94306 Phone: +1 650 617 2932
USA Email: pcalhoun@bstormnetworks.com
Madjid Nakhjiri
Motorola
1501 West Shure Drive
Arlington Heights IL 60004 Phone: +1 847 632 5030
USA Email: madjid.nakhjiri@motorola.com
Rajeev Koodli
Communications Systems Laboratory, Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043 Phone: +1 650 625 2359
USA Email: rajeev.koodli@nokia.com
Kulwinder S. Atwal
Zucotto Wireless Inc.
Ottawa Ontario K1P 6E2 Phone: +1 613 789 0090
CANADA EMail: kulwinder.atwal@zucotto.com
Mark Smith
COM DEV Wireless
3450 Broad Street, Suite 107
San Luis Obispo, CA 93401 Phone: +1 805 544 1089
USA Email: mark.smith@comdev.cc
Govind Krishnamurthi
Communications Systems Laboratory, Nokia Research Center
5 Wayside Road
Burlington MA 01803 Phone: +1 781 993 3627
USA EMail: govind.krishnamurthi@nokia.com
9 Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.