draft-ietf-seamoby-ct-reqs-01.txt   draft-ietf-seamoby-ct-reqs-02.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-01.txt Nortel Networks draft-ietf-seamoby-ct-reqs-02.txt Pat Calhoun
Expires: March 2001 Pat Calhoun Expires: May 2002 Madjid Nakhjiri
Black Storm Networks
Madjid Nakhjiri
Motorola
Rajeev Koodli Rajeev Koodli
Nokia
Kulwinder Atwal Kulwinder Atwal
Zucotto Wireless
Mark Smith Mark Smith
COM DEV Wireless
Govind Krishnamurthi Govind Krishnamurthi
Nokia
September, 2001 November, 2001
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 185 skipping to change at line 178
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 approach,
as it involves the fewest possible entities. At the very least, the number 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. of protocol exchanges should be less when there are fewer entities involved.
4.9 The entities transferring context MUST have completed a mutual 4.9 The entities transferring context MUST support a process for mutual
authentication process 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.
skipping to change at line 233 skipping to change at line 226
4.12 The context information to be transferred MUST be available at the 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 AR performing the transfer, prior to the initiation of a given phase
of the context transfer. of the context transfer.
To effect a rapid transfer, the context information has to be readily To effect a rapid transfer, the context information has to be readily
available when the AR begins a phase of the transfer. available when the AR begins a phase of the transfer.
If the context transfer is comprised of a single phase, then all of the If the context transfer is comprised of a single phase, then all of the
context must be available prior to the transfer initiation. context must be available prior to the transfer initiation.
4.13 The context information provided for transfer MUST be reliable. 4.13 The context transfer solution WILL NOT verify the context information
prior to transfer.
The context to be transferred must not only be readily available for The context transfer solution may provide mechanisms to support the
transfer, but the sending AR must ensure that the information is sound. reliable transfer of context, however, it is not the purpose of the context
transfer solution to verify the context at the source prior to transfer.
The context transfer solution may provide mechanisms to support reliable The effectiveness of context transfer in enhancing handover between ARs
transfer of context, but the effectiveness of context transfer in enhancing would very likely be compromised if the context at the source is malformed.
handover between ARs would very likely be compromised by attempts to Nonetheless, ensuring the integrity of the context at the source requires
transfer malformed context. specific knowledge of the syntax and semantics of the context representation
for each feature and this is outside the scope of the context transfer solution.
4.14 The context transfer solution 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.15 The context transfer solution 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.
4.16 The context transfer solution MUST include methods for interworking
with any IETF IP handover solutions.
4.17 The context transfer solution MUST be scalable.
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
of the different types of feature context necessary to support the of the different types of feature context necessary to support the
MN's traffic at a receiving AR. MN's traffic at a receiving AR.
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 conveying context information that will be representation for encapsulating context information in the IP packet
interpreted uniformly and perspicuously by different payload that will be interpreted uniformly and perspicuously by
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 labeling 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
 End of changes. 

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