Internet DRAFT - draft-koodli-seamoby-ctv6
draft-koodli-seamoby-ctv6
Seamoby Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins
27 February 2002 Communication Systems Laboratory
Nokia Research Center
A Context Transfer Protocol for Seamless Mobility
draft-koodli-seamoby-ctv6-03.txt
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.
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
Abstract
Mobile nodes enhance the performance of their connections
across wireless media by establishing various kinds of state
(context), in order to use the available bandwidth securely and
economically. During handover from one access router to another, a
bandwidth-constrained mobile node may need to have state information
passed from the previous router to the new one. This document
proposes a framework for control structures that enable authorized
context transfers. We demonstrate how the proposed framework could
be applied for use during handovers so that the applications running
on the mobile node could operate with minimal disruption, by reducing
latency and packet losses.
Koodli, Perkins Expires 27 August 2002 [Page i]
Internet Draft Context Transfers 27 February 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 3
2. Terminology 4
3. Background 5
4. Protocol Overview 7
5. Protocol Messages and Message Formats 10
5.1. Context Transfer Initiate (CTIN) Message . . . . . . . . 11
5.2. Context Transfer Initiate Ack (CTIN-Ack) Message . . . . 13
5.3. Context Transfer Request (CT-Req) Message . . . . . . . . 14
5.4. Context Transfer Reply (CT-Rep) Message . . . . . . . . . 16
5.5. Predictive Context Transfer (PCT) Message . . . . . . . . 17
5.6. Context Transfer Reply Acknowledgment (CT-Ack) Message . 19
6. Protocol Behavior with IP Handovers 20
6.1. Basic Handover Signaling . . . . . . . . . . . . . . . . 21
6.2. Fast Handover Signaling . . . . . . . . . . . . . . . . . 21
7. Transport Considerations 23
7.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Configurable Parameters 26
9. Security Considerations 26
10. IANA Considerations 26
11. Comparison with the Requirements 27
11.1. General Requirements . . . . . . . . . . . . . . . . . . 27
11.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 29
11.3. Transport Reliability . . . . . . . . . . . . . . . . . . 30
11.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 30
11.5. Timing Requirements . . . . . . . . . . . . . . . . . . . 31
11.6. Context Update and Synchronization . . . . . . . . . . . 32
11.7. Interworking with handover mechanisms . . . . . . . . . . 32
11.8. Partial Handover . . . . . . . . . . . . . . . . . . . . 33
Koodli, Perkins Expires 27 August 2002 [Page 1]
Internet Draft Context Transfers 27 February 2002
Addresses 35
Koodli, Perkins Expires 27 August 2002 [Page 2]
Internet Draft Context Transfers 27 February 2002
1. Introduction
Access Routers typically establish state in order to effect
certain forwarding treatments to packet streams belonging to nodes
sharing the access router. For instance, an access router may
establish a AAA session state and a QoS state for a node's packet
streams. When the link connecting the node and the access router is
bandwidth-constrained, the access router typically also maintains
header compression state. When such a node moves to a different
access router, this state or context relocation during handover
provides many important benefits, including
- seamless operation of application streams. The handover node
(i.e., the Mobile Node) does not need to re-establish its
contexts at the new access router
- performance benefits. When contexts need to be re-established,
performance of transport protocols would suffer until the
contexts are in place. For instance, when the required QoS state
is not present, a stream's packets would not receive the desired
per-hop behavior treatment, subjecting them to higher likelihood
of unacceptable delays and packet losses.
- bandwidth savings. Re-establishing multiple contexts over an
expensive, low-speed link can be avoided by relocating contexts
over a potentially higher-speed wire.
- Reduced susceptibility to errors, since much more of the protocol
operates over reliable networks, replacing renegotiations over a
potentially error-prone link.
In [6], a detailed description of motivation, the need and
benefits of context transfer are outlined. In this document, we
describe a generic context transfer protocol which provides
- representation for feature contexts
- messages to initiate and authorize context transfer, and notify a
MN of the status of the transfer, and
- messages for transferring contexts prior to, during and after
handovers
The protocol is transport and IP version independent. We show how
it can be carried using ICMP and SCTP. The protocol can carry both
IPv4 and IPv6 contexts.
The proposed protocol is designed to work in conjunction with
other [seamoby] and [mobile-ip] protocols in order to provide
Koodli, Perkins Expires 27 August 2002 [Page 3]
Internet Draft Context Transfers 27 February 2002
``seamless mobility''. For example, the messages defined in this
protocol are closely synchronized with Mobile IP fast handover
protocols [12] to achieve improved handover results. Furthermore,
the proposed protocol would make use of the Candidate Access Router
selection protocol [11] to obtain the IP address of the target
router to which the MN will attach to during handover. The protocol
described here satisfies the requirements set forth in [10] in
Section 11.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [1].
We define the following terms for use in this document. We also
use Figure 1 as the basis for our handover discussion.
CPT Context Profile Type: a general way to lay out context
parameters, which constitute a particular context, for
use when describing various feature contexts.
ICMP Internet Control Message Protocol
IP Access Address
An IP address useful for routing packets to a mobile node
while it is attached to an access network.
Microflow A communication stream of related packets, considered as
a separable and identifiable sequence of packets within
the entire aggregate data communications between two
endpoints.
New Access Router (NAR)
The router to which the MN attaches after handover
Predictive Same as proactive.
Previous Access Router (PAR)
The MN's default router prior to handover
New access address (Naddr) The IP Access address of the Mobile
Node (MN) when attached to the link served by the New
Router
Koodli, Perkins Expires 27 August 2002 [Page 4]
Internet Draft Context Transfers 27 February 2002
Previous access address (Paddr)
The IP Access Address of the Mobile Node (MN) when
attached to the link served by the Previous Router
v +------------+
+-+ | Previous | <
| | ---------- | Router | ------ > ----\
+-+ | (PAR) | < \
MN | | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Router | ------ > ----/
+-+ | (NAR) | <
MN | |
+------------+
Figure 1: Reference Scenario for Handover
3. Background
We begin with a brief discussion of what a feature context is.
There may be multiple features associated with each unidirectional
packet stream (also known as a microflow). Examples are QoS,
security and header compression. We assume that there is a feature
context that is specific for each microflow. Note that each feature
itself may be supported by multiple, co-existing mechanisms, for
various microflows. As an example, a header compression feature may
have separate contexts for IPv6/UDP/RTP and IPv6/TCP compression
mechanisms at the same router. Generally, a feature context
typically needs to identify and refer to the mechanism for which
its state is relevant. One or more feature contexts may belong to
a microflow context, and particular contexts for several features
together form the overall context for a mobile node. This overall
context may also include contexts that are not microflow-specific;
for example, it may include session-specific contexts such as AAA
state. The context hierarchy, consistent with the nomenclature
in [6], is illustrated in Figure 2 (where feature realizations
Koodli, Perkins Expires 27 August 2002 [Page 5]
Internet Draft Context Transfers 27 February 2002
through one or more mechanisms are not shown for clarity). This
hierarchy indicates the need for a representation that organizes
the diversity of features and feature realizations. It is also
clear from Figure 2 that a feature context is the unit of data
representation for context transfer purposes.
+--------------+
| |
| Context |
| |
| |
+--------------+
|
|
+-----------------------------------------+
| | |
+------------+ +------------+ +------------+
| | | | | |
|Microflow-1 | |Microflow-2 | ... |Microflow-n |
| context | | context | | context |
| | | | | |
+------------+ +------------+ +------------+
| | |
+----------+ +----------------+
| | | |
| Feature | +----------+ +----------+
|context X | | | | |
| | | Feature | | Feature |
+----------+ |context Y | |context X |
| | | |
+----------+ +----------+
Figure 2: Context Hierarchy for a Mobile Node
A context transfer protocol operates along with other protocols
to enhance handover experience. One such important protocol is IP
handover protocol which establishes a routing path to the mobile
node's new location, allowing the MN to send and receive IP packets,
including the packets that make up its identified microflows.
As soon as IP connectivity is available, a MN can resume packet
transmission and reception. Each microflow needs to be treated
with appropriate contexts to ensure smooth continuation of the MN's
packet streams. In some networks, an access router may require
authentication from the MN before making connectivity available.
Koodli, Perkins Expires 27 August 2002 [Page 6]
Internet Draft Context Transfers 27 February 2002
In such networks, the MN's new access router needs appropriate
context to avoid reinitiating time-consuming elaborate authentication
protocol operations.
Context transfer with respect to handover is complementary and
very natural; handover establishes IP connectivity (a routing issue),
while context transfer allows uninterrupted connectivity and smooth
operation of packet streams (a transport issue). Since routing
and transport issues are closely related, handover and context
transfer must also interwork closely. If handover fails due to
context transfer protocol, connectivity cannot be established. On
the other hand, if contexts cannot be relocated, they can always
be re-established. This illustrates that handover is a more basic
operation than context transfer.
A context transfer protocol must be capable of carrying all the
feature contexts relevant to a MN. The protocol message data must
accommodate different feature contexts, and be able to aggregate
multiple such contexts. We propose that message data is structured
according to a ``framework'' for carrying individual feature
contexts. Each individual feature context must define its structure
and format for interpreting the context unambiguously. Successful
processing of transferred contexts must produce a result that is
equally useful as establishing the contexts from first principles,
and, from the point of view of the mobile node, just as if it had
stayed at the previous access router.
4. Protocol Overview
Given the diversity of various features and their associated
contexts (See Figure 2), we propose a simple representation that
provides a generic structure, allowing each feature to define its
own context parameters. We define a Context Profile Type (CPT) as
an object that uniquely identifies the type of a feature context.
An instance of a CPT defines the context parameters associated with
the corresponding feature context to facilitate inter-operability.
For example, a QoS Profile Type (QPT) for Diffserv has to identify
the control parameters associated with the QoS feature, and a Header
Compression Profile Type (HPT) for IPv6 has to identify the IPv6
header compression control parameters. Each instance of a CPT can
also be used as a standard object in feature context requests,
feature negotiation etc, which are beyond the scope of this document.
Nevertheless, each feature context itself then consists of the [CPT,
context parameters] tuple along with some generally useful parameters
(such as a filter that identifies the packet stream).
The Context Transfer protocol typically operates between a source
node and a target node. In the future, there may be multiple target
Koodli, Perkins Expires 27 August 2002 [Page 7]
Internet Draft Context Transfers 27 February 2002
nodes involved; the protocol described here would work with multiple
target nodes. For simplicity, we describe the protocol assuming a
single receiver or target node.
Typically, the source node is a MN's Previous Access Router (PAR)
and the target node is MN's New Access Router (NAR). We assume
that PAR and NAR share an appropriate security association, set
up independently and prior to context transfer. Any appropriate
mechanism may be used in setting up this security association; it
enables the CT peers to utilize a secure channel for transferring
contexts, providing authentication, integrity, and (if needed)
confidentiality.
There are two messages associated with initiating the context
transfer, and four messages associated with the actual context
transfer protocol. The context transfer protocol messages use
Context Profile Types that identify the relevant feature contexts.
The Context Profile Types (CPTs) are standard identifiers (with
IANA Type Numbers) that allow a node to unambiguously determine the
type of context and the context parameters present in the protocol
messages. In addition to the CPT, each message contains a list of
feature contexts each in (Type, Length) format, as well as any IP
addresses necessary to associate the contexts to a particular MN. The
context transfer initiation messages contain parameters that identify
the source and target nodes, the desired list of feature contexts and
IP addresses to identify the contexts. Some of the messages contain
an appropriate token to authorize context transfer.
The Previous Access Router transfers feature contexts under two
general scenarios. First, it may receive a Context Transfer Initiate
(CTIN) message from a trusted entity, which could be the MN whose
feature contexts are to be transferred, a network server overseeing
the MN's handover, or an internally generated trigger (e.g., a
link-layer trigger on the interface to which the MN is connected),
etc. The CTIN message, described in Section 5.1, provides the IP
address of NAR, the IP address of MN on PAR, the list of feature
contexts to be transferred (by default requesting all contexts to
be transferred), and a token authorizing the transfer. It also
includes the MN's new IP address (valid on NAR) whenever it is known.
In response to a CTIN message, PAR transmits a Predictive Context
Transfer (PCT) message that contains feature contexts. The PCT
message, described in Section 5.5, contains the MN's previous IP
address and its new IP address (whenever known). It also includes a
key, and an indication to use a particular algorithm to assist NAR in
computing a token that it could use to check authorization prior to
making the contexts available to the MN.
In the second scenario, PAR receives a Context Transfer Request
(``CT-Req'', described in Section 5.3), message from NAR. In the
Koodli, Perkins Expires 27 August 2002 [Page 8]
Internet Draft Context Transfers 27 February 2002
CT-Req message, NAR supplies the MN's previous IP address, the
feature contexts to be transferred, and a token (typically generated
by the MN) authorizing context transfer. In response to CT-Req
message, PAR transmits a Context Transfer Reply (CT-Rep) message that
includes the MN's previous IP address and feature contexts. In this
``reactive'' transfer of contexts, PAR verifies authorization token
before transmitting the contexts, and hence does not include the key
and the name of algorithm in CT-Rep message.
When context transfer takes place without NAR requesting
it (scenario one above), NAR should require MN to present its
authorization token. Doing this locally at NAR when the MN attaches
to it improves performance, since the contexts may already be
present. When context transfer happens with an explicit request from
NAR (scenario two above), PAR performs such a verification since the
contexts are still present at PAR. In either case, token verification
takes place at the node possessing the contexts.
The New Access Router requests feature contexts when it receives
a CTIN message, such as the newly attached MN, a server overseeing
the handover of MN, or a link-layer indication from the interface
to which the MN attaches to. In response to the CTIN message, NAR
generates a CT-Req message to PAR. When it receives a corresponding
CT-Rep message, NAR may generate a CT-Ack message (See Section 5.6)
to report the status of processing the received contexts.
The node that receives a CTIN message may reply back with Context
Transfer Initiate Ack (CTIN-Ack) message. This message is intended
to report the status resulting from processing the CTIN message.
Furthermore, this message is used to notify the MN if there are
changes to certain feature contexts as a result of context transfer.
The CTIN-Ack message is described in Section 5.2.
Performing context transfer in advance of the MN attaching to
NAR clearly has potential for better performance. For this to take
place, certain conditions must be met. For example, PAR must have
sufficient time and knowledge about the impending handover. This is
feasible for instance in Mobile IP fast handovers; we describe how
in Section 6.2. However, when the advance knowledge of impending
handover is not available, or if a mechanism such as fast handover
fails, retrieving feature contexts after the MN attaches to NAR is
the only available means for context transfer. Performing context
transfer after handover is still better than having to re-establish
all the contexts from scratch. We describe this type of context
transfer that can be employed in conjunction with basic Mobile IP
further in Section 6.1. Finally, some contexts may simply need to
be transferred during handover signaling. For instance, any context
that gets updated on a per-packet basis must clearly be transferred
only after packet forwarding to the MN on its previous link is
Koodli, Perkins Expires 27 August 2002 [Page 9]
Internet Draft Context Transfers 27 February 2002
terminated. Transfer of such contexts must be properly synchronized
with appropriate handover messages, such as Mobile IP (Fast) Binding
Update. We describe this in Section 6.2.
The context transfer protocol messages described in this document
provide the basic structure necessary for context transfer to work
with other mechanisms, most notably IP handovers. The messages
can carry either IPv4 contexts or IPv6 contexts or both kinds of
contexts. The messages are transport protocol independent; we show
how they can be formulated with ICMP or SCTP as examples. They work
just as well with IPv4 and IPv6, as long as the relevant address
fields are sized appropriately.
5. Protocol Messages and Message Formats
In this document, we propose the following messages.
1. Context Transfer Request (CT-Req). A node uses this message to
request feature contexts from another node.
2. Context Transfer Reply (CT-Rep). A node uses this message to
respond to Context Transfer Request or CT-Req message.
3. Predictive Context Transfer (PCT). A node uses this message to
transfer feature contexts without having the CT-Req message
received.
4. Context Transfer Acknowledgment (CT-Ack). A node uses this
message to report status after processing either CT-Rep or PCT
messages. This message is not mandatory.
In general, these messages contain parameters that identify a
microflow, one or more feature contexts (or requests for feature
contexts) associated with the microflow and context authorization
data. These messages can be carried over appropriate transport
protocol; we describe ICMP and SCTP as specific examples. See
Sections 7.1 and 7.2. The messages can carry IPv4 or IPv6 or both
types of contexts (for dual stack nodes for example). These messages
are also IP version independent, i.e., they work with IPv4 and IPv6.
Furthermore, these messages are independent of the IP version used in
interconnecting the access routers.
In addition to the above messages, we define the following which
may be used to initiate context transfer.
1. Context Transfer Initiate (CTIN) Message. This message serves
as a general-purpose trigger to initiate context transfer. In
Koodli, Perkins Expires 27 August 2002 [Page 10]
Internet Draft Context Transfers 27 February 2002
response to this message, either CT-Req or PCT messages could be
transmitted.
2. Context Transfer Initiate Ack (CTIN-Ack) Message. This message
is an acknowledgment to CTIN message. This message does not
always have to occur after CTIN. However, when CTIN contains
request for specific feature context transfer, such a request may
require an acknowledgment; in those cases, CTIN-Ack would not be
optional.
We first explain the CTIN and CTIN-Ack messages. Note, however,
that in some systems these messages may not be needed, if other
triggers are available to initiate context transfer.
5.1. Context Transfer Initiate (CTIN) Message
The CTIN message contains feature context transfer requests. Each
feature context request is represented in the ``Type, Length, Value''
(TLV) format as a suboption to the CTIN message. The envelope of
these suboptions is prefixed by some fields that are generally
expected to be useful for all suboptions. Finally, this message
contains a token representing the authorization to effect context
transfers.
The CTIN message can be used either by a MN or by some other
entity to initiate context transfer. The message may be generated in
response to specific events such as a link-layer trigger indicating
handover, discovery of a new default router by MN etc. When CTIN is
delivered to the source of the context transfer, the message contains
the new IP addresses of the MN and its New Access Router. When this
message is delivered to the target of the context transfer, the
message contains the previous IP addresses of the MN and its Previous
Access Router. In either case, the authorization token is intended
for the node that currently possesses the feature contexts. For
instance, when CTIN arrives, NAR could verify the authorization token
if it already possesses the feature contexts. When CTIN arrives,
but NAR does not yet possess feature contexts, then NAR includes the
authorization token in CT-Req message for PAR to perform verification
of the authorization token. We rely on a secured data path between
PAR and NAR to insure integrity of the CT-Rep.
The node receiving the CTIN message MAY respond using CTIN-Ack
message. A MN however, must be able to operate its microflows
without necessarily having to wait for the CTIN-Ack message.
The format of CTIN message is shown in Figure 3.
Koodli, Perkins Expires 27 August 2002 [Page 11]
Internet Draft Context Transfers 27 February 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTIN | Length | V |T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous (New) IP Access Address of MN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous (New) Router Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| CT Data for Target Router...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SOType = Auth | Sub-Option Len| Reserved | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| CT Data for Source Router...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Context Transfer Initiate (CTIN) Message Format
Option Type Context Transfer Initiate (CTIN).
Option Length Variable
Reserved Reserved for future use. Must be set to zero
by the MN.
`V' bits When set to `00', indicate presence of IPv6
Previous (New) address only.
When set to `01' indicate presence of IPv4
Previous (New) Address only.
When set to `10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
`T' bit When set to 1 (one), indicates that suboptions
for the target node of CT are present.
Replay A value used to make sure that each use of the
CTIN message is uniquely identifiable.
Authorization Token
An unforgeable value calculated as discussed
below. This authorizes the receiver of CTIN
to perform context transfer.
Koodli, Perkins Expires 27 August 2002 [Page 12]
Internet Draft Context Transfers 27 February 2002
Suboptions Feature suboptions requesting context transfer
included as selected by the requesting node.
A default suboption could include request
for all contexts present. Each suboption
corresponds to one feature context, and is
assigned a unique integer value. So, for each
IP address listed, a maximum of 255 feature
contexts can be requested for transfer. Each
feature context defines its own parameters in
the data field.
These requests are typically meant for the
node possessing the feature contexts. In
some cases however, the node that would be
receiving the feature contexts may be supplied
with additional information to process
feature contexts. In order to facilitate this
programmability, an option is made available
for suboptions addressed to the target node of
context transfer.
In order to make sure that contexts are not transferred or lost
in response to a malicious request, authorization is required for
the context transfer request. The Authorization Token (Auth) is
calculated as follows:
Auth = HMAC (Key, input_data) mod 2^32
where HMAC (Key, Data) is defined (see RFC 2104 [5] for details)
roughly as follows:
HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data))
and MD5 is defined as given in RFC 1321 [8]. The input_data is
defined as follows:
input_data = CT_features || Replay || Paddr
where CT_features includes all the feature suboption data to the
node possessing MN's feature contexts, and Paddr is the mobile node's
previous IP access address while attached to the network served by
PAR. When all the contexts are already present at the New Access
Router, the New Access Router itself can verify authorization token
if it has the session key (and the knowledge of the algorithm) used
in computing the token.
5.2. Context Transfer Initiate Ack (CTIN-Ack) Message
A CT node receiving the CTIN message MAY respond to the sender
of the CTIN message with CTIN-Ack message. As an example, if NAR
receives CTIN from the MN, it MAY send a CTIN-Ack message to MN
containing status reports for each relevant feature for which context
Koodli, Perkins Expires 27 August 2002 [Page 13]
Internet Draft Context Transfers 27 February 2002
transfer was requested. However, unless a failure has occurred, or
else otherwise required by a specific feature, CTIN-Ack is optional.
On the other hand, the mobile node MUST be prepared to process a
CTIN-Ack even when no error has occurred. The format of CTIN-Ack
message is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTIN | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len|Response from receiver of CTIN..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Context Transfer Initiate Acknowledgment
(CTIN-Ack) Message Format
5.3. Context Transfer Request (CT-Req) Message
A MN's New Access Router (NAR) sends this message to retrieve
feature contexts from the MN's Previous Access Router (PAR). The
message contains the MN's IP address on PAR and optionally a token
from the MN authorizing the transfer of contexts. The authorization
token allows PAR to verify if context transfer was actually
authorized by the MN. The format of CT-Req message is shown in 5.
The IP header contains NAR as the Source Address, and PAR as the
Destination Address. These can be either IPv4 of IPv6 addresses.
Option Type Context Transfer Request (CT-Req)
Option Length Variable
`A' bit Acknowledgement requested.
Reserved Reserved for future use, set to zero by New
Router.
Previous IP Address The MN's IP (IPv4 or IPv6 or both) address
valid on Previous Router. This address is used as
a key in retrieving the MN's feature contexts.
`V' bits When set to `00', indicate presence of IPv6
Previous address only.
When set to `01' indicate presence of IPv4
Koodli, Perkins Expires 27 August 2002 [Page 14]
Internet Draft Context Transfers 27 February 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTREQ | Length | V |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous IP Address of MN (Paddr) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IP Address of MN (Naddr) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suboption Type| Subopt.Length | Context Profile Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Transfer Options Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional context transfer suboptions as needed...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SuboptType=Auth| Ctxt Length | Reserved | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Authorization Token from MN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Context Transfer Request (CT-Req) Message Format
Previous Address only.
When set to `10' indicate presence of both IPv6
and IPv4 Previous addresses.
Context Transfer Options Data (optional)
Feature context requests included as selected
by the mobile node and the New Router, in the
order specified. These are encoded in Sub-Option
Type and Sub-Option Length format, as in the
structure of CTIN message (See Figure 3). These
are present in the non default scenarios. Each
feature context, following the Context Profile
Type, supplies its own data which could include
parameters that identify the microflow.
Context Profile Type (CPT)
This is a standard identifier for the type of
context whose transfer is desired. Each CPT is
assigned an IANA type number.
Koodli, Perkins Expires 27 August 2002 [Page 15]
Internet Draft Context Transfers 27 February 2002
Replay A value used to make sure that each context
transfer request by the MN is uniquely
identifiable.
Authorization Token
An unforgeable value calculated as discussed
in 5.1.
5.4. Context Transfer Reply (CT-Rep) Message
The MN's Previous Access Router uses this message to respond to
CT-Req message. In this message, providing CT-Req processing is
successful, PAR transmits the requested feature contexts matching the
MN's previous IP address(es). Each feature context is formatted in
the TLV format, and the context data is preceded by a corresponding
Context Profile Type. Each feature context must include, whenever
required, those parameters that characterize the microflow. The
format of CT-Rep message is shown in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTREP | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous IP Address of MN (Paddr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suboption Type| Subopt.Length | Context Profile Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Transfer Options Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suboption Type| Subopt.Length | Context Profile Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Transfer Options Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Context Reply Message Format
Option Type Context Transfer Reply (CT-Rep)
Option Length Variable
Previous IP Address The MN's IP (IPv4 or IPv6) address valid on
Previous Router. This address is used as a key in
retrieving the MN's feature contexts.
Koodli, Perkins Expires 27 August 2002 [Page 16]
Internet Draft Context Transfers 27 February 2002
`V' bits When set to `00', indicate presence of IPv6
Previous address only.
When set to `01' indicate presence of IPv4 Previous
Address only.
When set to `10' indicate presence of both IPv6 and
IPv4 Previous addresses.
Context Profile Type
This is a standard object that identifies the type
of context whose transfer desired. Each CPT is
assigned an IANA type number.
Context Transfer Options Data
Feature contexts (enumerated as suboptions) for
each corresponding suboption present in CT-Req
in the order specified. These are encoded in
Sub-Option Type and Sub-Option Length format, as in
the structure of CTIN message (See Figure 3). When
both IPv4 and IPv6 contexts are present, all the
IPv4 contexts (identified by their respective CPTs)
SHOULD be enumerated before the IPv6 contexts.
Because of retransmissions, the New Router may receive the same
CT-Rep message and suboptions several times as part of the same
seamless handover. Therefore, all context suboptions are required
to be specified in such a way that the effect is the same whether
the New Router receives them one time or several times in a CT-Rep
message as part of the same seamless handover.
5.5. Predictive Context Transfer (PCT) Message
The Previous Access Router uses this message to transfer
(typically all) feature contexts when it has not received a CT-Req
message. In order to do so, PAR must be aware of the New Access
Router to which the MN will attach, and should preferably use this
message prior to the completion of MN's IP connectivity establishment
with NAR.
The format of PCT message is similar to that of CT-Rep with the
addition of fields necessary that would allow NAR to verify whether
the MN is authorized to make use of transferred feature contexts.
The Previous Access Router supplies a key and indicates the algorithm
to use in computing a token that NAR could demand from the MN prior
to making the feature contexts available.
Option Type Predictive Context Transfer (PCT)
Koodli, Perkins Expires 27 August 2002 [Page 17]
Internet Draft Context Transfers 27 February 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PCT | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IP Address of MN (Naddr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous IP Address of MN (Paddr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Transfer Options Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ctxt Type=Auth | Ctxt Length | Algorithm | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Predictive Context Transfer Message Format
Option Length Variable
Previous IP Address The MN's IP (IPv4 or IPv6) address valid on
Previous Router. This address is used as a key in
retrieving the MN's feature contexts.
New IP Address The MN's IP (IPv4 or IPv6) address valid on
New Router. This address is used to update the
received feature contexts.
`V' bits When set to `00', indicate presence of IPv6
Previous address only.
When set to `01' indicate presence of IPv4 Previous
Address only.
When set to `10' indicate presence of both IPv6 and
IPv4 Previous addresses.
Context Profile Type
This is a standard object that identifies the type
of context whose transfer is intended. Each CPT is
assigned an IANA type number.
Context Transfer Options Data
Individual feature contexts in the form of sub
options. These are encoded in Sub-Option Type and
Sub-Option Length format, as in the structure of
CTIN message (See Figure 3). When both IPv4 and
Koodli, Perkins Expires 27 August 2002 [Page 18]
Internet Draft Context Transfers 27 February 2002
IPv6 contexts are present, all the IPv4 contexts
(identified by their respective CPTs) SHOULD be
enumerated before the IPv6 contexts.
Algorithm
8-bit algorithm indication for computing the
Authorization Token (See Section 5.1). Default is
HMAC with MD5.
Key Length
8-bit unsigned integer. The length of the key in
units of 4 octets.
Key Encrypted key. The Key is encrypted using a
pre-existing shared key between the Previous Access
Router and New Access Router.
5.6. Context Transfer Reply Acknowledgment (CT-Ack) Message
The New Access Router MAY use this message to acknowledge receipt
of feature contexts in CT-Rep or PCT messages. The format of this
message is shown in Figure 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CT-Ack | Length | V |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous IP Address of MN (Paddr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Transfer Acknowledgment Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Context Transfer Reply Ack Message Format
Option Type Context Transfer Reply Ack (CT-Ack).
Option Length Variable
Previous IP Address
The MN's IP (IPv4 or IPv6 or both) address valid on
Previous Router. This address is used as a key in
retrieving the MN's feature contexts.
Koodli, Perkins Expires 27 August 2002 [Page 19]
Internet Draft Context Transfers 27 February 2002
`V' bits When set to `00', indicate presence of IPv6
Previous address only.
When set to `01' indicate presence of IPv4 Previous
Address only.
When set to `10' indicate presence of both IPv6 and
IPv4 Previous addresses.
`S' bit When set to one, this bit indicates that all
the feature contexts sent in CT-Rep or PCT were
received successfully.
Reserved Set to zero.
Context Transfer Options Data
Feature suboptions acknowledgments appropriate
for each suboption present in CT-Rep or PCT. Each
suboption is an 8-bit integer that indicates
an error code corresponding to (successful or
otherwise) receipt of a feature context. The order
of the suboptions must be the same as the order in
which the feature contexts are enumerated in CT-Rep
or PCT message. These suboptions are only present
when the "S" bit is not set to one.
6. Protocol Behavior with IP Handovers
This section specifies the use of protocol messages described
in the previous sections with handover signaling. There are two
types of signaling for context transfer purposes. Sometimes, the
context transfer takes place without being requested by the New
Access Router. In this ``predictive context transfer'' scenario, the
Previous Access Router, perhaps in response to a request from the
mobile node (or some other network entity), transfers contexts to the
New Access Router without explicit request from the latter. Such a
transfer could take place before the mobile node attaches to the New
Router, so that the desired context could be utilized as soon as the
mobile node obtains new IP connectivity. The New Access Router MUST
acknowledge this predictive context transfer, by sending CT-Ack.
Other times, the context transfer takes place as a reaction to
explicit signaling after the MN attaches to its New Router. In this
``reactive context transfer'' case, the New Access Router sends a
CT-req to the Previous Router. This scenario can be considered as an
extension to the basic handover signaling [3]. This also provides a
fallback approach when the fast handover signaling (or the predictive
approach) experiences a failure.
Koodli, Perkins Expires 27 August 2002 [Page 20]
Internet Draft Context Transfers 27 February 2002
6.1. Basic Handover Signaling
Suppose the MN originates the CTIN message after it establishes
link connectivity with NAR. After the mobile node acquires or
formulates a new IP access address, it sends a CTIN message shown in
Figure 3 to NAR. When NAR receives this CTIN message, it identifies
the suboptions and constructs a CT-Req message for the Previous
Access Router to request context relocation. In the default case,
there would be no suboptions present, indicating the MN's desire
to request all the contexts. The CT-Req message is described
in section 5.3 and MUST use IPsec AH to assure integrity and
authorization.
When the Previous Access Router (PAR) receives the CT-Req message,
it MUST check to see whether it has a security association with
NAR. If so, PAR MUST check for the presence and validity of an
Authentication Option [4]. Then the Previous Access Router MUST
check for the presence and validity of the Authorization Token
supplied by the mobile node to make sure that the context transfer
has been authorized by the mobile node. The Previous Access Router
then constructs a Context Transfer Reply (CT-Rep) message containing
the requested or all feature contexts. These operations are
illustrated in Figure 9.
It is important that context for the mobile node be not destroyed
at the Previous Access Router without authorization. Hence, after
sending the requested state to the New Access Router in the CT-Rep
message, PAR MUST keep the context data for the mobile node intact
for CONTEXT_SAVE_TIME. This allows recovery in case a CT-Rep message
is not received by the router sending the CT-Req message. The
Previous Access Router SHOULD NOT perform garbage collection of
context data until CONTEXT_PURGE_TIME.
6.2. Fast Handover Signaling
In the predictive context transfer scenario, PAR sends a PCT
message. The trigger for this predictive transfer MAY arrive from
the mobile node in a CTIN message. The trigger may also arrive from
any other entity that PAR trusts. See Figure 10.
The PCT message may be embedded in a suitable handover message,
such as the HI message [12] (see sections 7.1, 7.2).
When the New Access Router receives a valid PCT message, it MUST
maintain the contents for at least PRED_CT_TIME, or until it receives
the corresponding CTIN message from the mobile node whichever event
occurs first. In order for the predictive context transfer operation
to be secure, the Previous Access Router MUST have a security
Koodli, Perkins Expires 27 August 2002 [Page 21]
Internet Draft Context Transfers 27 February 2002
+----------+ 2. CT-Req +----------+
| | <--------- | |
| | | |
| PAR |-----------------| NAR |
| | | |
| | ---------> | |
+----------+ 3. CT-Rep +----------+
| ^ |
| | |
~~ 1. CTIN | ~~
|
V V
+-+ +-+
| | movement | |
+-+ -------> +-+
Figure 9: Context Transfer with Basic Handover Signaling
+----------+ 3. CT-Ack +----------+
| | <--------- | |
| | | |
1. CTIN | PAR |-----------------| NAR |
-------> | | | |
| | ---------> | |
+----------+ 2. PCT +----------+
| ^ |
| | |
~~ | ~~
4. CTIN |
V V
+-+ +-+
| | movement | |
+-+ -------> +-+
Figure 10: Context Transfer with Fast Handover Signaling
association with the New Access Router, and it MUST include an IPsec
Authentication Header (AH) in the packet containing the PCT message.
For instance, when the New Access Router receives a HI message with
Koodli, Perkins Expires 27 August 2002 [Page 22]
Internet Draft Context Transfers 27 February 2002
PCT option, it MUST check for the presence and validity of AH using
the security association it has with the Previous Router.
After a NAR has received contexts in PCT, it may not not activate
all necessary contexts until it can verifiably establish the presence
of the MN, perhaps by processing a CTIN message from the MN. The
MN SHOULD send a CTIN message when it connects to NAR in order to
present its context authorization token. The New Access Router MUST
compute its own token using the key supplied in the PCT message and
compare it against that supplied by the MN prior to activating the
contexts. If, due to failure, context is not present at NAR, the
CTIN message triggers context transfer by requiring the New Access
Router to send a CT-Req message.
Subsequent to processing the CTIN message, the New Access Router
MAY send a CTIN-Ack message to the MN. The New Access Router MUST
send a CTIN-Ack if any or all of the feature contexts cannot be
established appropriately.
7. Transport Considerations
7.1. ICMP
The basic ICMP message format is shown in Figure 11.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ICMP Message Format
The context transfer protocol messages (CT-Req, CT-Rep,
PCT, CT-Ack) as well as context transfer initiation (CTIN) and
notification (CTIN-Ack) messages are encapsulated within the Data
portion. Appropriate Type and Code values (TBD) are assigned to each
message. For the checksum field, see [2] and [7].
Koodli, Perkins Expires 27 August 2002 [Page 23]
Internet Draft Context Transfers 27 February 2002
7.2. SCTP
We use SCTP Payload Data Chunk to carry the context transfer
protocol messages [9]. The User Data part of each SCTP message
contains an appropriate context transfer protocol message defined in
this document. For instance, the CT-Rep message with all the feature
contexts belonging to a MN is encapsulated within the User Data part
of an SCTP message. In general, each SCTP message can carry feature
contexts belonging to any MN.
We propose a single stream for context transfer without
in-sequence delivery of SCTP messages. Each message, unless
fragmented, corresponds to a disparate MN's feature context. A
single stream provides simplicity. Having un-ordered delivery allows
the receiver to not block for in-sequence delivery of messages that
belong to different Mobile Nodes. The Payload Protocol Identifier
is set to ``Context Transfer Protocol'', and serves as a means to
identify the contents of the data chunk as belonging to the context
transfer protocol.
The format of Payload Data Chunk taken from [9] is shown in
Figure 12. The fields of interest to context transfer protocol are
described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SCTP Payload Data Chunk
`U' bit The Unordered bit. MUST be set to 1 (one).
Koodli, Perkins Expires 27 August 2002 [Page 24]
Internet Draft Context Transfers 27 February 2002
`B' bit The Beginning fragment bit. See [9].
`E' bit The Ending fragment bit. See [9].
TSN Transmission Sequence Number. See [9].
Stream Identifier S
Identifies the context transfer protocol stream.
Stream Sequence Number n
Since the `U' bit is set to one, the receiver ignores
this number. See [9].
Payload Protocol Identifier
Set to an unsigned integer corresponding to ``Context
Transfer Protocol''.
User Data Contains the context transfer protocol messages
CT-Req, CT-Rep, PCT and CT-Ack.
Koodli, Perkins Expires 27 August 2002 [Page 25]
Internet Draft Context Transfers 27 February 2002
8. Configurable Parameters
Every access router supporting the mobility extensions defined
in this document SHOULD be able to configure each parameter in
the following table. Each table entry contains the name of the
parameter, the default value, and the section of the document in
which the parameter first appears.
Parameter Name Default Value Definition
------------------- ---------------------- -------
CT-Req_RETRIES 3 Section 5.3
CT-Req_REXMIT_TIME 1 seconds Section 5.3
CONTEXT_SAVE_TIME 2 * CT-Req_REXMIT_TIME Section 6.1
CONTEXT_PURGE_TIME 5 * CT-Req_REXMIT_TIME Section 6.1
PRED_CT_TIME 3 seconds Section 6.2
9. Security Considerations
The Previous Router and the New Router MUST use authentication
for messages carrying CT-Req, CT-Rep and PCT; the exact algorithms
employed will depend on their security association. In addition,
when Previous Router uses PCT option, it MUST encrypt the Key using a
pre-existing shared secret with the New Router.
Since authentication data is supplied by the mobile node along
with its smooth handover requests, there is substantially no danger
of loss of handover context due to malicious attacks. If a node uses
the same features and Previous_IP_Address (see section 5.1) more than
255 times, then it SHOULD establish a new security association with
the Previous Router (Prtr) (i.e., the mobile node's default router at
the Previous IP Access Address (Paddr)). However, if the mobile node
fails to change its security association with the Previous Router in
this situation, an attacker could keep track of all 256 available
replay protection values and cause a future disconnection the next
time the mobile node acquires the same care-of address at the same
Previous Router.
10. IANA Considerations
The Context Profile Type introduced in this document requires
IANA Type Numbers for each set of feature contexts that make use of
Profile Types.
Koodli, Perkins Expires 27 August 2002 [Page 26]
Internet Draft Context Transfers 27 February 2002
11. Comparison with the Requirements
In this section, we compare the solution we have proposed against
the requirements specified in [10].
11.1. General Requirements
1. ``The context transfer solution MUST define the characteristics
of the IP level trigger mechanisms that initiate the transfer of
context.''
The CTIN message specified in Section 5.1 can be used as a
general-purpose IP trigger to initiate context transfer.
For instance, when the MN's access router recognizes that
the MN has terminated the link connection (through a link
layer specific mechanism for example), an ``upcall''
containing essentially the CTIN structure can be made to
the context transfer process that then begins the actual
transfer process. The essential elements of the IP trigger
would include the IP address of the MN's target access
router, the MN's new IP address and an enumeration of
various feature contexts that need to be transferred. The
default case, that needs no enumeration, allows transfer of
all feature contexts. The authorization token need not be
present for an ``internal'' trigger.
2. ``The IP level context transfer triggers MAY be initiated by a
link level (layer two) event.''
The proposal in this document would inter-work with link
layer triggers (if and when used).
3. ``The IP level trigger mechanisms for context transfer MUST hide
the specifics of any layer 2 trigger mechanisms.''
The CTIN option specified is independent of any link layer
trigger.
4. ``The IP level context transfer triggers MAY be initiated by IP
level (layer three) signaling.''
The CTIN message specified in this document can be carried
in any appropriate IP signaling message, such as a Fast
Binding Update [12], or in an IP message of its own.
5. ``Any IP level signalling for Context Transfer MUST be separated
from the actual transfer of context.''
Koodli, Perkins Expires 27 August 2002 [Page 27]
Internet Draft Context Transfers 27 February 2002
The CT-Rep and PCT messages, which carry the feature
contexts, are different from CTIN.
6. ``The context transfer solution SHOULD support one-to-many
context transfer.''
The source access router can use the CT-Rep or PCT envelope
to send multiple unicast messages or a single multicast
message when there are multiple receivers for the feature
contexts.
7. ``The context transfer solution MUST support context transfer
before, during and after handover.''
In this document, we specifically describe how context
transfer can be performed during and after handovers. The
``Predictive Context Transfer'' message can be used prior
to actual handover.
8. ``The context transfer solution MUST support a distributed
approach in which the Access Routers act as peers during the
context transfer.''
In this document, the access routers transfer appropriate
contexts. These contexts are typically those that are
created locally on the access router. If contexts present
elsewhere need to be transferred by using the access
routers, a separate protocol outside the scope of this
document would be needed to glean all the relevant contexts
and make them available to the source access router.
9. ``The entities transferring context MUST have completed a mutual
authentication process prior to initiating the transfer.''
Our protocol does not propose dynamically establishing
mutual authentication between the context transfer
entities. Mechanisms outside the scope of this document
would be needed to establish the necessary security
associations between the context transfer peers.
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 CTIN structure allows enumeration of only those feature
contexts for which transfer is desired.
11. ``Context information MAY be transferred in phases.''
Koodli, Perkins Expires 27 August 2002 [Page 28]
Internet Draft Context Transfers 27 February 2002
The ``CT-Rep'' or ``PCT'' message can be used multiple
times to effect transfer in phases.
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.''
Since we only consider all contexts to be local to the AR,
we expect it to be available during all phases of context
transfer.
13. ``The context information provided for transfer MUST be
reliable.''
Since an access router creates the context, we expect it to
be genuine and reliable. Since it is reasonable to expect
that the MN was making use of the feature (e.g., QoS,
header compression etc), the context itself on the access
router must be useful. Furthermore, since our protocol
does not introduce any operations on the context itself,
we anticipate no scenarios that would malform an otherwise
genuine, useful and reliable context.
14. ``The context transfer solution MUST include methods for
interworking with any IETF IP mobility solutions.''
The proposed protocol readily interworks with Fast
Handovers proposed in Mobile IP working group. See
Section 6.2. The proposed protocol also interworks with
base Mobile IP protocol itself. See Section 6.1.
15. ``The context transfer solution MAY include methods for
interworking with non-IETF mobility solutions.''
While this should be possible, we do not have experiences
to report here.
11.2. Protocol Requirements
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.''
The proposed protocol allows for sending all or a subset
of feature contexts necessary to support the MN's traffic.
Specifically, the sub option structure allows for one
or more feature contexts to be uniquely identified and
included in context transfer.
Koodli, Perkins Expires 27 August 2002 [Page 29]
Internet Draft Context Transfers 27 February 2002
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.''
The concept of ``Context Profile Types'' introduced in
this proposal is powerful and versatile in capturing the
meaning of context information to enable inter-operability.
We expect each feature to define its own set of Feature
Profile Types that uniquely define the content and
interpretation of individual feature contexts.
3. ``The context transfer protocol MUST operate autonomously from
the content of the context information being transferred.''
There is nothing proposed in this document that would
contradict the above requirement. In other words, the
proposed protocol does not operate in any context-specific
manner.
4. ``The context transfer protocol design MUST define a standard
method for labeling each feature context being transferred.''
Each feature would define a set of ``Feature Profile
Types''. A ``Feature Profile Type'', such as a QoS Profile
Type (QPT) would define the unique characteristics of each
instance of the feature. For instance, a Compression
Profile Type for IPv6/UDP/RTP-voice-G.723.1 would define
all the necessary and sufficient context parameters for
the associated feature. This CPT, which would be an IANA
assigned type number, would precede the associated context
parameters in each transferred context.
5. ``The context transfer protocol design MUST provide for the
future definition of new feature contexts.''
New ``Feature Profile Types'' can be defined as necessary.
11.3. Transport Reliability
11.4. Security
1. ``The protocol MUST provide for "security provisioning".''
We expect the ARs involved in context transfer to
share appropriate security associations. Such security
associations may be set up by means outside the scope of
the context transfer protocol. However, our protocol
Koodli, Perkins Expires 27 August 2002 [Page 30]
Internet Draft Context Transfers 27 February 2002
provides for context authorization mechanism so that only
an authorized MN is allowed to make use of the transferred
contexts.
2. ``The security provisioning for context transfer MUST NOT require
the creation of application layer security.''
We do not propose application layer security.
3. ``The protocol MUST provide for the security provisioning to be
disabled.''
It is up to an appropriate authority to decide whether
security provisioning should be enabled or disabled. The
protocol does not specifically require the presence or
absence of security provisioning.
11.5. Timing Requirements
1. ``A context transfer MUST complete with a minimum number of
protocol exchanges between the source AR and the rest of the
ARs.''
Our protocol proposes two messages to accomplish context
transfer. When contexts are transferred before the MN
attaches to the new AR, there is a predictive transfer and
acknowledge message sequence. When context transfer takes
place after the MN attaches to the new AR, there is context
request and context reply message pair.
2. ``The context transfer protocol design MUST minimize the amount
of processing required at the sending and receiving Access
Routers.''
The amount of processing needed at the sending router
is limited to collecting all the relevant contexts for
transfer and labeling each context with an appropriate
Profile Type, and computing authentication data. The
amount of processing at the receiving router is limited
to parsing the received contexts using the Profile Types,
verifying authentication data and installing the contexts
in local memory.
3. ``The Context Transfer protocol MUST meet the timing constraints
required by all the feature contexts.''
It is important to recognize that the context state
refers to a MN's packet flows. When the packet flows
Koodli, Perkins Expires 27 August 2002 [Page 31]
Internet Draft Context Transfers 27 February 2002
change network path due to handover, it is important to
synchronize context transfer with handover epoch. This
would ensure not only that the contexts would be present
when needed, but also guarantee that the transferred state
is not stale. Our context transfer protocol is designed to
operate together with handover signaling. This allows for
contexts to be present ``in-time''.
4. ``The context transfer solution MUST provide for the aggregation
of multiple contexts.''
The proposed sub option structure is meant for collecting
all the possible feature contexts to be transferred in a
single message. The sending AR scans and collects all the
feature contexts associated with the MN while constructing
the CT-Rep or PCT option. This ensures the most feature
context aggregation prior to transferring the message.
11.6. Context Update and Synchronization
1. ``The context transfer protocol MUST be capable of updating
context information when it changes.''
The PCT message can be used at any appropriate time to
accomplish context updates.
2. ``A context update MUST preserve the integrity, and thus the
meaning, of the context at each receiving AR.''
We do not propose replicating the contexts at multiple ARs
when the MN is connected to a single AR. Thus, we do not
have to address this requirement.
11.7. Interworking with handover mechanisms
1. ``The context transfer protocol MAY provide input to the handover
process.''
We do not provide such an input in our current proposal.
2. ``The context transfer protocol MUST include methods for
exchanging information with the handover process.''
We expect a separate Candidate Access Router discovery
protocol to assist the context transfer protocol in
determining the target AR. We expect such a discovery
protocol to also assist the handover process.
Koodli, Perkins Expires 27 August 2002 [Page 32]
Internet Draft Context Transfers 27 February 2002
11.8. Partial Handover
1. ``The context transfer protocol MAY provide a mechanism for
supporting partial handovers.''
We do not propose distributing the subsets of contexts
to multiple ARs. However, if a Candidate Access Router
discovery protocol provides more than one target and the
required contexts for each target AR, our protocol does not
inhibit such a transfer.
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
[3] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force,
November 1998.
[4] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[5] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication. Request for Comments
(Informational) 2104, Internet Engineering Task Force,
February 1997.
[6] O. Levkowetz and et al. Problem Description: Reasons For Doing
Context Transfers Between Nodes in an IP Access Network (work in
progress). Internet Draft, Internet Engineering Task Force.
draft-ietf-seamoby-context-transfer-problem-stat-00.txt,
February 2001.
[7] J. Postel. Internet Control Message Protocol. Request for
Comments (Standard) 792, Internet Engineering Task Force,
September 1981.
[8] R. Rivest. The MD5 Message-Digest Algorithm. Request for
Comments (Informational) 1321, Internet Engineering Task Force,
April 1992.
Koodli, Perkins Expires 27 August 2002 [Page 33]
Internet Draft Context Transfers 27 February 2002
[9] R. Stewart and et al. Stream Control Transmission Protocol.
Request for Comments (Proposed Standard) 2960, Internet
Engineering Task Force, October 2000.
[10] H. Syed and et al. General Requirements for Context
Transfer(work in progress). Internet Draft, Internet
Engineering Task Force, March 2001.
[11] D. Trossen and et al. Issues in candidate access router
discovery for seamless IP-level handoffs (work in progress).
Internet Draft, Internet Engineering Task Force, January 2002.
[12] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in
progress). Internet Draft, Internet Engineering Task Force.
draft-designteam-fast-mipv6-01.txt, February 2001.
Koodli, Perkins Expires 27 August 2002 [Page 34]
Internet Draft Context Transfers 27 February 2002
Addresses
Questions about this memo can be directed to the authors:
Rajeev Koodli Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2359 Phone: +1-650 625-2986
EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Koodli, Perkins Expires 27 August 2002 [Page 35]
