draft-ietf-seamoby-ct-reqs-04.txt   draft-ietf-seamoby-ct-reqs-05.txt 
Internet Engineering Task Force Gary Kenward, editor Internet Engineering Task Force Gary Kenward, editor
Internet Draft Internet Draft
draft-ietf-seamoby-ct-reqs-04.txt draft-ietf-seamoby-ct-reqs-05.txt
Expires: March 2003 Expires: April 2003
September, 2002 October, 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 110 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 solution will have to assume certain characteristics of the access network
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 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 160 skipping to change at line 155
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.4 The IP level context transfer triggers MAY be initiated by IP level 4.4 The IP level context transfer triggers MAY be initiated by IP level
(layer three) signalling. (layer three) signalling.
4.5 Any IP level signalling for Context Transfer MUST be separated from 4.5 Any IP level signalling for Context Transfer MUST be separated from
the actual transfer of context. the actual transfer of context.
4.6 The context transfer solution SHOULD support one-to-many context 4.6 The context transfer solution MAY 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
skipping to change at line 189 skipping to change at line 184
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 the ARs to effect a context transfer should be the most efficient approach,
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 of protocol exchanges should be less when there are fewer entities involved.
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 enable or disable context transfer for particular IP microflows or groups
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
 End of changes. 

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