draft-ietf-seamoby-ct-reqs-00.txt   draft-ietf-seamoby-ct-reqs-01.txt 
Internet Engineering Task Force Hamid Syed Internet Engineering Task Force Hamid Syed
Internet Draft Gary Kenward Internet Draft Gary Kenward
draft-ietf-seamoby-ct-reqs-00.txt Nortel Networks draft-ietf-seamoby-ct-reqs-01.txt Nortel Networks
Expires: November 2001 Pat Calhoun Expires: March 2001 Pat Calhoun
SUN Microsystems, Inc Black Storm Networks
Madjid Nakhjiri Madjid Nakhjiri
Motorola Motorola
Rajeev Koodli Rajeev Koodli
Nokia Nokia
Kulwinder Atwal Kulwinder Atwal
Zucotto Wireless Zucotto Wireless
Mark Smith Mark Smith
COM DEV Wireless COM DEV Wireless
Govind Krishnamurthi Govind Krishnamurthi
Nokia Nokia
May, 2001 September, 2001
General Requirements for a Context Transfer Framework 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 55 skipping to change at line 55
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 framework 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.
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.
skipping to change at line 86 skipping to change at line 86
The information required to support a specific forwarding treatment The information required to support a specific forwarding treatment
provided to an IP flow is part of the context for that flow. To 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 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 be replicated from the forwarding nodes along the existing path to
the forwarding nodes along the new path. The transfer of context the forwarding nodes along the new path. The transfer of context
information may be advantageous in minimizing the impact of host information may be advantageous in minimizing the impact of host
mobility on, for example, AAA, header compression, QoS, Policy, and mobility on, for example, AAA, header compression, QoS, Policy, and
possibly sub-IP protocols and services such as PPP. possibly sub-IP protocols and services such as PPP.
An analysis of the context transfer problem is captured in [2]. This An analysis of the context transfer problem is captured in [2]. This
document captures the requirements for a context transfer framework document captures the requirements for a context transfer solution
and the requirements for a generic context transfer protocol to and the requirements for a generic context transfer protocol to
carry the context between the context transfer peers. carry the context between the context transfer peers.
2 Conventions used in this document 2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
3 Terminology 3 Terminology
skipping to change at line 114 skipping to change at line 114
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 network
and the mobility solution, and the availability of certain triggering events, 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 framework". are referred to as the "context transfer solution".
4.1 The context transfer framework 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 trigger mechanisms for context transfer MUST hide the 4.2 The IP level context transfer triggers MAY be initiated by a link level
specifics of the layer 2 trigger mechanisms. (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 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 path used to communicate between the MN and the access network. The
mechanisms utilized to change the communications path at layer 2 are mechanisms utilized to change the communications path at layer 2 are
specific to the physical characteristics of the medium, and often specific to the physical characteristics of the medium, and often
specific to the layer 2 transmission technology being used (e.g. TIA specific to the layer 2 transmission technology being used (e.g. TIA
IS 2000, ETSI UMTS R4, IEEE 802.11). IS 2000, ETSI UMTS R4, IEEE 802.11).
In order for any action to be taken at the IP level to maintain IP 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 sessions during a layer 2 path change, some indication of the path
skipping to change at line 143 skipping to change at line 146
Since it is expected that IP handover, and thus context transfer will Since it is expected that IP handover, and thus context transfer will
work irrespective of the layer 2 technology, the IP level solutions work irrespective of the layer 2 technology, the IP level solutions
must not utilize specific layer 2 information. The conditions and must not utilize specific layer 2 information. The conditions and
events that caused the generation of an IP level trigger must be events that caused the generation of an IP level trigger must be
opaque to the IP level. This implies that there are general opaque to the IP level. This implies that there are general
characteristics of an IP level trigger that need to be defined so characteristics of an IP level trigger that need to be defined so
that the triggers generated by different layer 2 solutions will have that the triggers generated by different layer 2 solutions will have
identical semantics at the IP level. identical semantics at the IP level.
4.3 The context transfer framework SHOULD support one-to-many context 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. transfer.
An MN may have connectivity to the access network through more than An MN may have connectivity to the access network through more than
one physical path at any given time, depending upon the one physical path at any given time, depending upon the
characteristics of the physical medium, and the layer 1 and 2 characteristics of the physical medium, and the layer 1 and 2
protocols and services. protocols and services.
The different physical paths may connect into the network via The different physical paths may connect into the network via
different ARs. In this scenario, two or more ARs may be candidates different ARs. In this scenario, two or more ARs may be candidates
for handover of the MN's traffic and each will require the for handover of the MN's traffic and each will require the
appropriate IP context when forwarding commences. Exactly which AR appropriate IP context when forwarding commences. Exactly which AR
will be the target of the handover is often not known until the will be the target of the handover is often not known until the
handover is initiated, and providing the necessary context to all the handover is initiated, and providing the necessary context to all the
candidate ARs can only accelerate the handover process. candidate ARs can only accelerate the handover process.
A one-to-many context transfer may be achieved using either a series A one-to-many context transfer may be achieved using either a series
of point-to-point transfers, or a point-to-multipoint (multicast) of point-to-point transfers, or a point-to-multipoint (multicast)
transfer. transfer.
4.4 The context transfer framework MUST support proactive context transfer. 4.7 The context transfer solution MUST support context transfer before,
during and after handover.
4.5 The context transfer framework MUST support reactive context transfer
It is useful to consider two modes of operation for context transfer:
proactive and reactive.
With proactive context transfer, the context is made available
to an AR before it is needed. This means that the context is
available at the AR before it is required to forward the first
packet arrival in the MN's traffic. Proactive context transfer is
coupled to mobile handover only by the requirement that the context
be in place before the handover of the MN's traffic is complete.
With reactive context transfer, the context is made available to
an AR when the need is imminent. The implication here is that the
initiation of a handover, or some event soon after initiation,
triggers a reactive context transfer. Depending upon the network
configuration, the MN's velocity and the behavior of the mobility
solution, a reactive context transfer may or may not complete quickly
enough for the new forwarding AR to provide a consistent service to
the first packets of the re-directed traffic.
The proactive mode of context transfer is an attempt to further
reduce any disruption of the service provided to the MN's traffic by
making the context available to an AR prior to it being needed for
forwarding. This implies that some network event will occur at the IP
level to indicate the potential for a handover, prior to the handover
being initiated (c.f. requirements 4.1 and 4.2). This event would
trigger a proactive context transfer. There can be no guarantee that
this event will occur, and thus, a reactive context transfer is
always required as a contingency.
In many situations there is no forewarning available of a handover
and context transfer must be initiated simply because the
re-direction of the MN's traffic is in progress and the AR needs the
forwarding context immediately. Because of the real world physics of
MN movement and wireless coverage patterns, these situations can
never be completely avoided. Thus, if context transfer is to be
performed at all, the fundamental mode of operation must be reactive.
This also means that a context transfer that begins in proactive mode
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete in reactive mode. In this scenario,
proactive and reactive context transfer are really two possible phases of
a single attempted context transfer.
As the proactive mode of context transfer is an enhancement, there may be
situations where the reactive mode is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
mode, its use is optional.
4.6 The context transfer framework 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 context One main distinction between the various alternative approaches to
transfer is the choice of the functional entity or entities that orchestrate context transfer is the choice of the functional entity or entities that
the transfer. A context transfer solution that relies upon the ARs to effect orchestrate the transfer. A context transfer solution that relies upon
a context transfer should be the most efficient approach, as it involves the the ARs to effect a context transfer should be the most efficient approach,
fewest possible entities. At the very least, the number of protocol exchanges as it involves the fewest possible entities. At the very least, the number
should be less when there are fewer entities involved. of protocol exchanges should be less when there are fewer entities involved.
4.7 The entities transferring context MUST have completed a mutual 4.9 The entities transferring context MUST have completed a mutual
authentication process prior to initiating the transfer. authentication process prior to initiating the transfer.
4.8 The context transfer framework SHOULD provide mechanisms to It is believed that if a formal authentication exchange (e.g. exchanging
selectively enable or disable context transfer for particular credentials) were done during the context transfer, the computation
IP microflows or groups of IP microflows. 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 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
by different operators. by different operators.
skipping to change at line 252 skipping to change at line 218
Local mechanisms for allowing context transfer to be disabled on a per Local mechanisms for allowing context transfer to be disabled on a per
microflow basis have to be provided for in the context transfer solution. 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 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 possibly, as part of a PIB, if policy based management is considered
desirable. desirable.
There are other mechanisms and protocols required to manage or control There are other mechanisms and protocols required to manage or control
the per microflow disabling of context transfer. These are clearly the per microflow disabling of context transfer. These are clearly
out of the scope of the context transfer work. out of the scope of the context transfer work.
4.9 All context information to be transferred MUST be available at the 4.11 Context information MAY be transferred in phases.
AR performing the transfer, prior to the initiation of the context
transfer.
The total context associated with the MN's traffic is composed of Providing for phased transfers allows the context acquisition
various types of feature context. To effect a rapid transfer, the and transfer to be prioritized.
context information has to be readily available when the AR begins
the transfer.
4.10 The context information provided for transfer MUST be reliable. 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 The context to be transferred must not only be readily available for
transfer, but the sending AR must ensure that the information is sound. transfer, but the sending AR must ensure that the information is sound.
The context transfer solution may provide mechanisms to support reliable The context transfer solution may provide mechanisms to support reliable
transfer of context, but the effectiveness of context transfer in enhancing transfer of context, but the effectiveness of context transfer in enhancing
handover between ARs would very likely be compromised by attempts to handover between ARs would very likely be compromised by attempts to
transfer malformed context. transfer malformed context.
4.11 The context transfer framework MUST include methods for interworking 4.14 The context transfer solution MUST include methods for interworking
with any IETF IP mobility solutions. with any IETF IP mobility solutions.
4.12 The context transfer framework MAY include methods for interworking 4.15 The context transfer solution MAY include methods for interworking
with non-IETF mobility solutions. with non-IETF mobility solutions.
5. Protocol Requirements 5. Protocol Requirements
This section captures the general requirements for the context This section captures the general requirements for the context
transfer protocol. transfer protocol.
5.1 General Protocol Requirements 5.1 General Protocol Requirements
5.1.1 The context transfer protocol MUST be capable of transferring all 5.1.1 The context transfer protocol MUST be capable of transferring all
skipping to change at line 356 skipping to change at line 328
5.3.3 The protocol MUST provide for the security provisioning to be 5.3.3 The protocol MUST provide for the security provisioning to be
disabled. disabled.
In some environments, the security provisioning provided for by the In some environments, the security provisioning provided for by the
context transfer protocol may not be necessary, or it may be context transfer protocol may not be necessary, or it may be
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 Proactive context transfer MUST be completed before the handover 5.4.1 A context transfer MUST complete with a minimum number of protocol
of the Mobile Node's traffic to the receiving AR completes.
When an MN's traffic is handed over to a new AR, that AR will
usually require the associated context in order to provide service
contiguous with the service provide by the old AR. For there to be
no disruption in service, the associated context needs to be
installed at the new AR in time for the forwarding of the first packet
of the MN's traffic.
5.4.2 The context transfer protocol SHOULD NOT introduce additional
delay into the handover completion.
The purpose of context transfer is to enhance the performance of traffic
handover between ARs. While incurring additional delay may be acceptable
in some situations, as a general solution, it is preferable that the context
transfer protocol be capable of operating without impacting handover
completion.
For proactive context transfer, meeting requirement 5.4.2 will ensure that
requirement 5.4.1 is not achieved by explicitly delaying the handover
completion.
For reactive context transfer, the requirement has to be less stringent.
By definition, reactive context transfer is invoked when a handover to the
receiving AR is either in progress or impending. Completing a reactive
context transfer within any time constraint will depend heavily on the
handover solution being used, and situational factors such as the topology
of the network, or networks, local to the handover. Regardless, it is still
useful to require that reactive context transfer not delay handover, if at
all possible. If additional delay is unavoidable, then the reactive context
transfer solution must be designed to minimize the incremental delay that is
introduced.
5.4.3 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 signaling 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.4 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
reliability of the context. In other words, the context may become reliability of the context. In other words, the context may become
obsolete before it can be reconstructed at the receiving AR. obsolete before it can be reconstructed at the receiving AR.
Also, AR processing delay contributes to the overall context transfer Also, AR processing delay contributes to the overall context transfer
delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult. 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 An example of a protocol design that would increase the processing
delay at the receiver is where the context information is segmented, delay at the receiver is where the context information is segmented,
and the ordering of the segments is not preserved during transfer; and the ordering of the segments is not preserved during transfer;
segmenting at the sender, and more likely, re-ordering of the segmenting at the sender, and more likely, re-ordering of the
segments at the receiver could introduce significant additional segments at the receiver could introduce significant additional
AR processing delays. AR processing delays.
5.4.5 The Context Transfer protocol MUST meet the timing constraints 5.4.3 The Context Transfer protocol MUST meet the timing constraints
required by all the feature contexts. required by all the feature contexts.
A given feature context may have timing constraints imposed by the A given feature context may have timing constraints imposed by the
nature of the service being support. The delivered context must nature of the service being support. The delivered context must
always comply with the requirements of the service if it is to be always comply with the requirements of the service if it is to be
useable. useable.
5.4.6 The context transfer protocol MUST support the aggregation of 5.4.4 The context transfer solution MUST provide for the aggregation of
multiple contexts. 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 There may be instances where there are multiple context transfers
pending. To reduce the overall transfer time, as well as transport pending. To reduce the overall transfer time, as well as transport
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 labeling 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 context transfer protocol MUST be capable of updating
context information when it changes. context information when it changes.
5.5.2 A context update MUST preserve the integrity, and thus the 5.5.2 A context update MUST preserve the integrity, and thus the
meaning, of the context at each receiving AR. meaning, of the context at each receiving AR.
skipping to change at line 493 skipping to change at line 435
6 References 6 References
[1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement [1] S. Bradner, "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] Levkowetz et al., "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-01.txt, May 2001.
[3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984.
7 Acknowledgements 7 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 8 Author's Addresses
Hamid Syed Hamid Syed
100 Constellation Crescent 100 Constellation Crescent
Nepean, Ontario. K2G 6J8 Phone: 1 613 763 6553 Nepean, Ontario. K2G 6J8 Phone: 1 613 763 6553
Canada Email: hmsyed@nortelnetworks.com Canada Email: hmsyed@nortelnetworks.com
Gary Kenward Gary Kenward
100 Constellation Crescent 100 Constellation Crescent
Nepean, Ontario. K2G 6J8 Phone: 1 613 765 1437 Nepean, Ontario. K2G 6J8 Phone: 1 613 765 1437
Canada Email: gkenward@nortelnetworks.com Canada Email: gkenward@nortelnetworks.com
Pat R. Calhoun Pat R. Calhoun
Network and Security Research Center, Sun Labs Black Storm Networks
15 Network Circle 250 Cambridge Avenue, Suite 200
Menlo Park CA 94025 Phone: +1 650 786 7733 Palo Alto, CA 94306 Phone: +1 650 617 2932
USA Email: pcalhoun@eng.sun.com USA Email: pcalhoun@bstormnetworks.com
Madjid Nakhjiri Madjid Nakhjiri
Motorola Motorola
1501 West Shure Drive 1501 West Shure Drive
Arlington Heights IL 60004 Phone: +1 847 632 5030 Arlington Heights IL 60004 Phone: +1 847 632 5030
USA Email: madjid.nakhjiri@motorola.com USA Email: madjid.nakhjiri@motorola.com
Rajeev Koodli Rajeev Koodli
Communications Systems Laboratory, Nokia Research Center Communications Systems Laboratory, Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
 End of changes. 

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