draft-ietf-seamoby-ct-reqs-03.txt   draft-ietf-seamoby-ct-reqs-04.txt 
Internet Engineering Task Force Hamid Syed Internet Engineering Task Force Gary Kenward, editor
Internet Draft Gary Kenward Internet Draft
draft-ietf-seamoby-ct-reqs-03.txt Pat Calhoun draft-ietf-seamoby-ct-reqs-04.txt
Expires: July 2002 Madjid Nakhjiri Expires: March 2003
Rajeev Koodli
Kulwinder Atwal
Mark Smith
Govind Krishnamurthi
January, 2002 September, 2002
General Requirements for Context Transfer General Requirements for Context Transfer
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 36 skipping to change at line 32
time It is inappropriate to use Internet-Drafts as reference material time It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
The success of time sensitive services like VoIP telephony, video, The success of time sensitive services like VoIP telephony, video,
etc., in a mobile environment depends heavily on the ability to etc., in a mobile environment depends heavily on the ability to
minimize the impact of the traffic redirection during a change of minimize the impact of the traffic redirection during a change of
packet forwarding path. In the process of establishing the new packet forwarding path. In the process of establishing the new
forwarding path, the nodes along the new path must be prepared to forwarding path, the nodes along the new path must be prepared to
provide similar forwarding treatment to the IP packets. The transfer provide similar forwarding treatment to the IP packets. The transfer
of context information may be advantageous in minimizing the impact of context information may be advantageous in minimizing the impact
of host mobility on IP services. This document captures the set of of host mobility on IP services. This document captures the set of
requirements for a context transfer solution and the requirements requirements for a context transfer solution and the requirements
for a generic context transfer protocol to carry the context between for a generic context transfer protocol to carry the context between
the context transfer peers. the context transfer peers.
Table of Contents
1 Introduction
2 Conventions used in this document
3 Terminology
4 General Requirements
5. Protocol Requirements
6 Standardization of Feature Contexts
7 References
8 Acknowledgements
9 Author's Addresses
10 Full Copyright Statement
11 Funding Acknowledgement
1 Introduction 1 Introduction
There are a large number of IP access networks that support mobile There are a large number of IP access networks that support mobile
hosts. For example, wireless Personal Area Networks (PANs), wireless hosts. For example, wireless Personal Area Networks (PANs), wireless
LANs, satellite WANs and cellular WANs. The nature of this mobility LANs, satellite WANs and cellular WANs. The nature of this mobility
is such that the communication path to the host may change frequently is such that the communication path to the host may change frequently
and rapidly. and rapidly.
In networks where the hosts are mobile, the forwarding path through In networks where the hosts are mobile, the forwarding path through
the access network must often be redirected in order to deliver the the access network must often be redirected in order to deliver the
skipping to change at line 100 skipping to change at line 110
Most of the terms used in this document are defined in [2]. Most of the terms used in this document are defined in [2].
Access Router (AR) Access Router (AR)
An IP router residing in an Access Network and connected to one or An IP router residing in an Access Network and connected to one or
more points of access. An AR offers connectivity to MNs. more points of access. An AR offers connectivity to MNs.
4 General Requirements 4 General Requirements
This section addresses the facilities and services required in the access This section addresses the facilities and services required in the access
network to properly support context transfer. The context transfer network to properly support context transfer. The context transfer
solution will have to assume certain characteristics of the access network solution will have to assume certain characteristics of the access
and the mobility solution, and the availability of certain triggering events, network
and the mobility solution, and the availability of certain triggering
events,
transport options, and so forth. These support capabilities are not transport options, and so forth. These support capabilities are not
necessarily part of context transfer, per se, but are needed for context necessarily part of context transfer, per se, but are needed for context
transfer to operate as defined and effect the expected enhancements to MN transfer to operate as defined and effect the expected enhancements to MN
traffic handover. For convenience, this collection of support capabilities
traffic handover. For convenience, this collection of support
capabilities
are referred to as the "context transfer solution". are referred to as the "context transfer solution".
4.1 The context transfer solution MUST define the characteristics of the IP 4.1 The context transfer solution MUST define the characteristics of the IP
level trigger mechanisms that initiate the transfer of context. level trigger mechanisms that initiate the transfer of context.
4.2 The IP level context transfer triggers MAY be initiated by a link level 4.2 The IP level context transfer triggers MAY be initiated by a link level
(layer two) event. (layer two) event.
4.3 The IP level trigger mechanisms for context transfer MUST hide the 4.3 The IP level trigger mechanisms for context transfer MUST hide the
specifics of any layer 2 trigger mechanisms. specifics of any layer 2 trigger mechanisms.
skipping to change at line 174 skipping to change at line 189
4.7 The context transfer solution MUST support context transfer before, 4.7 The context transfer solution MUST support context transfer before,
during and after handover. during and after handover.
4.8 The context transfer solution MUST support a distributed approach in 4.8 The context transfer solution MUST support a distributed approach in
which the Access Routers act as peers during the context transfer. which the Access Routers act as peers during the context transfer.
One main distinction between the various alternative approaches to One main distinction between the various alternative approaches to
context transfer is the choice of the functional entity or entities that context transfer is the choice of the functional entity or entities that
orchestrate the transfer. A context transfer solution that relies upon orchestrate the transfer. A context transfer solution that relies upon
the ARs to effect a context transfer should be the most efficient approach, the ARs to effect a context transfer should be the most efficient
as it involves the fewest possible entities. At the very least, the number approach,
of protocol exchanges should be less when there are fewer entities involved. 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 support a process for mutual 4.9 The entities transferring context MUST support a process for mutual
authentication prior to initiating the transfer. authentication prior to initiating the transfer.
It is believed that if a formal authentication exchange (e.g. exchanging It is believed that if a formal authentication exchange (e.g. exchanging
credentials) were done during the context transfer, the computation credentials) were done during the context transfer, the computation
overhead for both the sender and the receiver would cause additional and overhead for both the sender and the receiver would cause additional and
unnecessary latency to the handoff process. Therefore, the CT peers MUST unnecessary latency to the handoff process. Therefore, the CT peers MUST
exchange credentials prior to any context transfer. exchange credentials prior to any context transfer.
4.10 The context transfer solution SHOULD provide mechanisms to selectively 4.10 The context transfer solution SHOULD provide mechanisms to selectively
enable or disable context transfer for particular IP microflows or groups enable or disable context transfer for particular IP microflows or
groups
of IP microflows. of IP microflows.
The context associated with an MN's microflows is normally to be The context associated with an MN's microflows is normally to be
transferred whenever it is required to support forwarding. However, transferred whenever it is required to support forwarding. However,
there may be conditions where it is desirable to selectively disable there may be conditions where it is desirable to selectively disable
context transfer for specific microflows. context transfer for specific microflows.
For example, it may be desirable to provide an MN with the capability 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 to disallow the transfer of the context associated with one or more
of its microflows when handover occurs between networks administered of its microflows when handover occurs between networks administered
skipping to change at line 254 skipping to change at line 273
5.1.2 The context transfer protocol design MUST define a standard 5.1.2 The context transfer protocol design MUST define a standard
representation for encapsulating context information in the IP packet representation for encapsulating context information in the IP packet
payload that will be interpreted uniformly and perspicuously by payload that will be interpreted uniformly and perspicuously by
different implementations. different implementations.
5.1.3 The context transfer protocol MUST operate autonomously from the 5.1.3 The context transfer protocol MUST operate autonomously from the
content of the context information being transferred. content of the context information being transferred.
5.1.4 The context transfer protocol design MUST define a standard method 5.1.4 The context transfer protocol design MUST define a standard method
for labeling each feature context being transferred. for labelling each feature context being transferred.
Various protocols participate in setting up the service support for Various protocols participate in setting up the service support for
any given microflow, and many of these protocols require feature any given microflow, and many of these protocols require feature
specific state to be maintained for the life of the IP session. The specific state to be maintained for the life of the IP session. The
context transfer protocol should provide a generic mechanism to carry context transfer protocol should provide a generic mechanism to carry
context information to an AR, irrespective of the context type. context information to an AR, irrespective of the context type.
Given that the desired context transfer protocol is a single, generic Given that the desired context transfer protocol is a single, generic
protocol for transferring all feature context, the collection of protocol for transferring all feature context, the collection of
information representing the context for a given feature must be information representing the context for a given feature must be
encapsulated into a standard representation and labeled. encapsulated into a standard representation and labelled.
Encapsulation is necessary to keep the context for different features Encapsulation is necessary to keep the context for different features
separated. The receiving AR will use the label on an encapsulated separated. The receiving AR will use the label on an encapsulated
context to associate it with the appropriate service feature and context to associate it with the appropriate service feature and
process the content appropriately. process the content appropriately.
The context transfer protocol does not need to know the contents of The context transfer protocol does not need to know the contents of
these nuggets of encapsulated information. Indeed, for the protocol these nuggets of encapsulated information. Indeed, for the protocol
to be independent from the type of context being transferred, it must to be independent from the type of context being transferred, it must
be oblivious the actual context. be oblivious the actual context.
5.1.5 The context transfer protocol design MUST provide for the future 5.1.5 The context transfer protocol design MUST provide for the future
definition of new feature contexts. definition of new feature contexts.
The context transfer solution must not attempt to define all possible The context transfer solution must not attempt to define all possible
feature contexts to be transferred. Instead, it must provide for the feature contexts to be transferred. Instead, it must provide for the
definition of new contexts in support of future service features, or definition of new contexts in support of future service features, or
feature evolution. Guidance should be provided to future users of context feature evolution. Guidance should be provided to future users of context
transfer on the best approach to defining feature context. transfer on the best approach to defining feature context.
5.2 Transport Reliability 5.2 Transport Requirements
This section is intentionally left blank as the working group is This section contains requirements on the context transfer transport.
waiting for a questionnaire from the transport directorate. The result
of the questionnaire will create requirements that will be added in this 5.2.1 The context transfer protocol MUST be specified so that it is
section in a later revision of this specification. independent of the underlying transport.
Recognizing that the transport characteristics for context transfer
will depend on the particular application, it should be possible to
transfer context directly on top of reliable transports, such as
TCP or SCTP, unreliable transports, such as UDP, or as an option or
extension on another protocol, such as handover signalling.
5.3 Security 5.3 Security
5.3.1 The protocol MUST provide for "security provisioning". 5.3.1 The protocol MUST provide for "security provisioning".
The security of the context information being exchanged between ARs The security of the context information being exchanged between ARs
must be ensured. Security provisioning includes protecting the must be ensured. Security provisioning includes protecting the
integrity, confidentiality, and authenticity of the transfer, as well integrity, confidentiality, and authenticity of the transfer, as well
as protecting the ARs against replay attacks. as protecting the ARs against replay attacks.
skipping to change at line 319 skipping to change at line 344
preferred to minimize the context transfer protocol overhead. preferred to minimize the context transfer protocol overhead.
5.4 Timing Requirements 5.4 Timing Requirements
5.4.1 A context transfer MUST complete with a minimum number of protocol 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. exchanges between the source AR and the rest of the ARs.
The number of protocol exchanges required to perform a peer to peer The number of protocol exchanges required to perform a peer to peer
interaction is directly related to the unreliability, resource interaction is directly related to the unreliability, resource
consumption, and completion time of that interaction. A context consumption, and completion time of that interaction. A context
transfer will require signaling and data exchanges, but, as a general transfer will require signalling and data exchanges, but, as a general
rule, by keeping the number of these exchanges to a minimum, the rule, by keeping the number of these exchanges to a minimum, the
reliability, resource utilization and completion delay of the reliability, resource utilization and completion delay of the
transfer should improve. transfer should improve.
5.4.2 The context transfer protocol design MUST minimize the amount of 5.4.2 The context transfer protocol design MUST minimize the amount of
processing required at the sending and receiving Access Routers. processing required at the sending and receiving Access Routers.
If the context transfer protocol requires the context information to If the context transfer protocol requires the context information to
be transferred in a form that requires significant additional be transferred in a form that requires significant additional
processing at each AR, delays may be incurred that impact the processing at each AR, delays may be incurred that impact the
skipping to change at line 370 skipping to change at line 395
overhead that might be incurred by separately transferring each overhead that might be incurred by separately transferring each
context, the sending AR may choose to aggregate the contexts and context, the sending AR may choose to aggregate the contexts and
execute one transfer operation. execute one transfer operation.
Note that if contexts are aggregated, the labelling method required Note that if contexts are aggregated, the labelling method required
by 5.1.4 must include an identifier that allows the contexts to be by 5.1.4 must include an identifier that allows the contexts to be
separated at the receiving AR. separated at the receiving AR.
5.5 Context Update and Synchronization 5.5 Context Update and Synchronization
5.5.1 The context transfer protocol MUST be capable of updating 5.5.1 The base context transfer protocol SHOULD NOT provide direct
context information when it changes. support for synchronization with outside events, since
synchronization is not a requirement for all or even most feature
contexts.
5.5.2 A context update MUST preserve the integrity, and thus the 5.5.2 The base context transfer protocol MUST allow individual feature
meaning, of the context at each receiving AR. context specifications to define their own synchronization with
external events.
The context at the AR actually supporting an MN's traffic will 5.5.3 The base context transfer protocol SHOULD NOT provide support for
change with time. For example, the MN may initiate new microflow(s), updating context after it is transferred, since individual feature
or discontinue existing microflows. Any change of context at the contexts will differ in their need for update.
supporting AR must be replicated at those ARs that have already
received context for that MN. 5.5.4 The base context transfer protocol MUST allow individual feature
context specifications to define their own update procedures if
required.
Most feature contexts will not require synchronization, however
there are a few that may. Header compression, for example, may require
that the header compressor on the old access router cease and the
compressor on the new router start in synchrony with hand over of
routing to the new router; otherwise, the compressor on the new
router will not be properly synchronized. Since most contexts don't
need synchronization support, the general CT solution need not support
it, but it should not provide a hindrance to those feature contexts
that do.
Feature contexts will differ in whether or not they require update.
A feature context such as QoS parameters for the service level
agreement with a user may not involve dynamically changing information,
but it may change during or after context transfer. Such feature
contexts may benefit from allowing the context to change after the
transfer is completed. Other feature contexts, such as header
compression, may be tightly synchronized with external events and
changes on the old router need to be discarded since the new router's
state may already have been modified.
5.6 Interworking with handover mechanisms 5.6 Interworking with handover mechanisms
5.6.1 The context transfer protocol MAY provide input to the 5.6.1 The context transfer protocol MAY provide input to the
handover process. handover process.
5.6.2 The context transfer protocol MUST include methods for exchanging 5.6.2 The context transfer protocol MUST include methods for exchanging
information with the handover process. information with the handover process.
Both context transfer and handover require information on the Both context transfer and handover require information on the
skipping to change at line 411 skipping to change at line 461
In a situation where no single AR is capable of receiving a handover 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 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. allow different IP microflows to be handed over to different ARs.
The information transferred to each AR must be limited to only the The information transferred to each AR must be limited to only the
context required to support the microflows that are actually handed context required to support the microflows that are actually handed
over. Thus, the context transfer protocol would need a mechanism for over. Thus, the context transfer protocol would need a mechanism for
partitioning the context and transferring each portion to the partitioning the context and transferring each portion to the
appropriate AR. appropriate AR.
6 References 6 Standardization of Feature Contexts
[1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement The context transfer protocol provides a basic framework in which
feature contexts of varying types can be transferred. Recognizing
that the particular feature contexts may have very different needs
with regard to update, synchronization, and transport, the base
context transfer protocol requirements are designed to not constrain
how the context transfer protocol is used for particular feature
contexts with respect to these points. In addition, some feature
contexts may require additional processing on the target access router
before they can be of use. Individual feature contexts will be
standardized by the method of IETF standards action. The
standardization of a feature context should describe how a feature
context utilizes the base context transfer protocol; if update,
synchronization, and additional processing are required, and, if so,
how they are achieved; and the transport used for the feature context.
7 References
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997. Levels", RFC2119 (BCP), IETF, March 1997.
[2] Levkowetz et al., "Problem Description: Reasons For Performing [2] Kempf, J., editor, "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network ", Context Transfers Between Nodes in an IP Access Network ",
draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001. draft-ietf-seamoby-context-transfer-problem-stat-04.txt, May 2002.
[3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984. [3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
7 Acknowledgements 8 Acknowledgements
Thank you to all who participated in the Seamoby working group context Thank you to all who participated in the Seamoby working group context
transfer design team. transfer design team.
8 Author's Addresses 9 Author's Addresses
Hamid Syed Hamid Syed
Nortel Networks
100 Constellation Crescent 100 Constellation Crescent
Ottawa, Ontario. K2G 6J8 Phone: 1 613 763 6553 Ottawa, Ontario. K2G 6J8 Phone: +1 613 763 6553
Canada Email: hmsyed@nortelnetworks.com Canada Email: hmsyed@nortelnetworks.com
Gary Kenward Gary Kenward
Nortel Networks
100 Constellation Crescent 100 Constellation Crescent
Ottawa, Ontario. K2G 6J8 Phone: 1 613 765 1437 Ottawa, Ontario. K2G 6J8 Phone: +1 613 765 1437
Canada Email: gkenward@nortelnetworks.com Canada Email: gkenward@nortelnetworks.com
Pat R. Calhoun Pat R. Calhoun
Black Storm Networks Black Storm Networks
250 Cambridge Avenue, Suite 200 250 Cambridge Avenue, Suite 200
Palo Alto, CA 94306 Phone: +1 650 617 2932 Palo Alto, CA 94306 Phone: +1 650 617 2932
USA Email: pcalhoun@bstormnetworks.com USA Email: pcalhoun@bstormnetworks.com
Madjid Nakhjiri Madjid Nakhjiri
Motorola Motorola
skipping to change at line 474 skipping to change at line 543
3450 Broad Street, Suite 107 3450 Broad Street, Suite 107
San Luis Obispo, CA 93401 Phone: +1 805 544 1089 San Luis Obispo, CA 93401 Phone: +1 805 544 1089
USA Email: mark.smith@comdev.cc USA Email: mark.smith@comdev.cc
Govind Krishnamurthi Govind Krishnamurthi
Communications Systems Laboratory, Nokia Research Center Communications Systems Laboratory, Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington MA 01803 Phone: +1 781 993 3627 Burlington MA 01803 Phone: +1 781 993 3627
USA EMail: govind.krishnamurthi@nokia.com USA EMail: govind.krishnamurthi@nokia.com
9 Full Copyright Statement James Kempf
DoCoMo Communication Laboratories USA
180 Metro Drive, Suite 300
San Jose, CA 95110 Phone: +1 408 451 4711
USA EMail: kempf@docomolabs-usa.com
"Copyright (C) The Internet Society (2001). All Rights Reserved. 10 Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
skipping to change at line 500 skipping to change at line 575
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11 Funding Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/