Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri
Category: Standards Track C. Perkins
<draft-ietf-seamoby-ctp-01.txt> R. Koodli
Expires: September 2003 March 2003
Context Transfer Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2003. All Rights Reserved.
Abstract
This document presents a context transfer protocol that enables
authorized context transfers. Context transfers allows better
support for node based mobility so that the applications running on
mobile nodes can operate with minimal disruption. Key objectives are
to reducing latency, packet losses and avoid re-initiation of
signaling to and from the mobile node.
Loughney et al. expires August 2003 [Page 1]
Internet-Draft February 2003
Table of Contents
1. Introduction
1.1 Conventions Used in This Document
1.2 Abbreviation Used in the Document
2. Protocol Overview
2.1 Context Transfer Packet Format
2.2 Context Types
2.3 Context Data Block
2.4 Messages
3. Transport Considerations
3.1 Congestion Control
3.2 Transport Protocols
4. Open Issues
4.1 Reliability
4.2 Transport
4.3 Failure Handling
4.4 Zone of Operation
5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR
5.2 Network controlled, Initiated by nAR
5.3 Mobile controlled, Predictive New L2 up/old L2 down
5.4 Mobile controlled, Reactive CT New L2 up/old L2 down
6. Security Considerations
7. IANA Considerations
8. Acknowledgements
9. References
9.1 Normative References
9.2 Non-Normative References
Appendix A. Simplified Example Context Type Specification
Appendix B. Timing and Trigger Considerations
Author's Addresses
Loughney et al. expires August 2003 [Page 2]
Internet-Draft February 2003
1. Introduction
"Problem Description: Reasons For Performing Context Transfers
between Nodes in an IP Access Network" [3374] defines the following
main reasons why Context Transfer procedures may be useful in IP
networks.
1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch.
2) An additional motivation is to provide an interoperable solution
that works for any Layer 2 radio access technology.
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 an
AAA session state and a QoS state for a node's packet streams. When
the link connecting a mobile node and the access router is
bandwidth-constrained, the access router may maintain header
compression state on behalf of the mobile node. 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 reestablished,
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 [3374], 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 mobile node of the status of the transfer.
* Messages for transferring contexts prior to, during and after
Loughney et al. expires August 2003 [Page 3]
Internet-Draft February 2003
handovers.
The proposed protocol is designed to work in conjunction with other
protocols in order to provide seamless mobility.
1.1 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2119].
1.2 Abbreviation Used in the Document
AR Access Router
CT Context Transfer
CTP Context Transfer Protocol
DoS Denial-of-Service
FPT Feature Profile Types
MIP Mobile IP
MN Mobile Node
nAR New Access Router
pAR Previous Access Router
SA Security Association
2. Protocol Overview
This section provides a protocol overview. A context transfer can be
either started by a request from the mobile node ("mobile
controlled") or at the initiative of either the new or the previous
access router ("network controlled").
* The mobile node can send the CT start request to old or new AR.
The former is preferred whenever possible. Sending the request to
nAR would add extra latency since the new AR, itself, after
processing the MN's request will need to request context
transmission from pAR.
* Either nAR or pAR may request or start (respectively) context
transfer based on internal or network triggers (see Appendix B).
Loughney et al. expires August 2003 [Page 4]
Internet-Draft February 2003
The MN will send a context transfer request to the pAR (including
proper authentication material). After checking authentication, pAR
starts the context transfer procedure.
The Context Transfer protocol typically operates between a source
node and a target node. In the future, there may be multiple target
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.
Context Transfer takes place when an event, such as a handover, takes
place. We call such an event as a Context Transfer Trigger. In
response to such a trigger, the pAR may transfer the contexts; the
NAR may request contexts and the MN may send a message to the PAR to
transfer contexts. Such a trigger must be capable of providing the
necessary information, such as the MN's IP address with which the
contexts are associated, the IP addresses of the access routers, and
authorization to transfer context.
Context transfer protocol messages use Context Types that identify
the way that data is organized for the particular feature contexts.
The Context Types (CPTs) are registered in a number space (with IANA
Type Numbers) that allows a node to unambiguously determine the type
of context and the context parameters present in the protocol
messages. Contexts are transferred by laying out the appropriate
feature data within Context Data Blocks according to the format in
section 2.3, 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. The messages that actually transfer context
data also contain an appropriate token to authorize the context
transfer.
The Previous Access Router transfers feature contexts under two
general scenarios. First, it may receive a Context Transfer Start
Request (CTSR) message from the MN whose feature contexts are to be
transferred, or it receives an internally generated trigger (e.g., a
link-layer trigger on the interface to which the MN is connected).
Loughney et al. expires August 2003 [Page 5]
Internet-Draft February 2003
The CTSR message, described in Section 2.4.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 CT-Start Request message or to the CT trigger, PAR
predictively transmits a Context Transfer Data (CTD) message that
contains feature contexts. This message, described in Section 2.4.2,
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
Request) described in Section 2.4.5, message from nAR. The nAR
itself generates the CT Request message either as a result of
receiving the CTSR message or as a response to an internal trigger
(that indicates the MN's attachment). In the 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 Request message, pAR transmits a
Context Transfer Data (CTD) message that includes the MN's previous
IP address and feature contexts. When it receives a corresponding
CTD message, nAR may generate a CTD Reply message (See Section 2.4.3)
to report the status of processing the received 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 the CTD message.
When context transfer takes place without the 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 highly likely to be
present already. When context transfer happens with an explicit
request from NAR (scenario two above), pAR performs such verification
since the contexts are still present at pAR. In either case, token
verification takes place at the node possessing the contexts.
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. 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 might still be
Loughney et al. expires August 2003 [Page 6]
Internet-Draft February 2003
better than having to re-establish all the contexts from scratch.
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 terminated. Transfer of
such contexts must be properly synchronized with appropriate handover
messages, such as Mobile IP (Fast) Binding Update.
2.1 Context Transfer Packet Format
The packet consists of a common header, message specific header and
one or more data packets. Data packets may be bundled together in
order ensure a more efficient transfer. The total packet size,
including transport protocol and IP protocol headers SHOULD be less
than the path MTU, in order to avoid packet fragmentation.
+----------------------+
| CTP Header |
+----------------------+
| Message Header |
+----------------------+
| CTP Data 1 |
+----------------------+
| CTP Data 2 |
+----------------------+
| ... |
2.2 Context Types
Contexts are identified by context type, which is a 32-bit number.
The meaning of each context type is determined by a specification
document and the context type numbers are to be tabulated in a
registry maintained by IANA, and handled according to the message
specifications in this document. The instantiation of each context
by nAR is determined by the messages in this document along with the
specification associated with the particular context type. Each such
context type specification contains the following details:
- Number, size (in bits), and ordering of data fields in the
state variable vector which embodies the context.
- Default values (if any) for each individual datum of the
context state vector.
- Procedures and requirements for creating a context at a new
access router, given the data transferred from a previous
access router, and formatted according to the ordering rules
and date field sizes presented in the specification.
- If possible, status codes for success or failure related to the
Loughney et al. expires August 2003 [Page 7]
Internet-Draft February 2003
context transfer. For instance, a QoS context transfer might
have different status codes depending on which elements of the
context data failed to be instantiated at nAR.
Appendix A contains an example context type specification for UDP/RDP
header compression context.
2.3 Context Data Block
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Context Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if V = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ context type-dependent data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'V' bit specifies whether or not the "presence vector" is used.
When the presence vector is in use, the next 32 bits are interpreted
to indicate whether particular data fields are present (and, thus,
containing non-default values). The ordering of the bits in the
presence vector is the same as the ordering of the data fields
according to the context type specification, one bit per data field
regardless of the size of the data field. Notice that the length of
the context data block is defined by the sum of lengths of each data
field specified by the context type specification, plus 4 bytes if
the 'V' bit is set, minus the accumulated size of all the context
data that is implicitly given as a default value.
2.4 Messages
In this section, a list of the available context transfer message
types is given, along with a brief description of their functions.
Generally, messages use the following generic message header format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ message data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney et al. expires August 2003 [Page 8]
Internet-Draft February 2003
The Mobile Node, for which context transfer protocol operations are
undertaken, is always identified by its previous care-of address. At
any one time, only one context transfer operation may be in progress
so that the CTDR message unambigously identifies which CTD message is
acknowledged simply by including the mobile node's identifying
previous care-of address.
2.4.1 Context Transfer Start Request (CTSR) Message
Sent by MN to nAR to request start of context transfer. It is for
further to study to see if when the CTSR message is sent by the MN to
the nAR, it should also be relayed to pAR. Acknowledgement is
optional, since the MN may have already moved and may not receive the
reply. This message may include a list of FPT (feature profile types)
that require transfer. It may include flags to request secure and/or
reliable transfer.
The MN may also send this message to pAR while still connected to
pAR. In such a case, the MN includes the nAR's IP address and its new
IP address (if known).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Router IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CTSR is the Mobile Node's Previous Care-of
Address, Previous Router's IP address, MN Authorization Token,
followed by a list of context types. If no context types are
specified, then all contexts for the mobile node are requested.
2.4.2 Context Transfer Data (CTD) Message
Sent by pAR to nAR, and includes feature data (CTP data). This
message should handle predictive as well as normal CT. A reliability
Loughney et al. expires August 2003 [Page 9]
Internet-Draft February 2003
flag, R, included in this message indicates whether a reply is
required by nAR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |C|R|rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's New Care-of Address, if C=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Context Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Context Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MN Authorization Token is computed over the binary data
represented in the Context Data BLocks of the CTD message. The
binary data is laid out as the fully specified ordered sequence of
data fields according to the defining context specification, as if
there were no presence vector and therefore no implicitly supplied
default values. Since the mobile node is expected to know the
precise contents of the context data to be transferred, and the pAR
is expected to know the security parameters and algorithm used by the
mobile node to compute the authorization token, the token can be
supplied by pAR on behalf of the mobile node.
2.4.3 Context Transfer Data Reply (CTDR) Message
This message is sent by nAR to pAR depending on the value of the
reliability flag in CTD. Indicates success or failure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |C| rsv | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OverallStatus is used for reporting overall success or failure,
Loughney et al. expires August 2003 [Page 10]
Internet-Draft February 2003
which could be based on verification of the MN authorization token
for instance. For certain values of the overall status, it may be
that some contexts were successfully transferred and some failed to
be transferred. In this case, then for each context another status
code MUST be provided to indicate to pAR which contexts have failed
and which have succeeded, along with the reason.
2.4.4 Context Transfer Cancel (CTC) Message
If transfering a context requires an ongoing process (i.e., is not
short-lived), then nAR may send CTC to pAR to cancel an ongoing CT
process.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | rsv | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4.5 Context Transfer Request (CT Request) Message
Sent by nAR to pAR request start of context transfer. This message is
sent as a response to CTSR message by the MN.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CT Request is the Mobile Node's Previous Care-of
Address, MN Authorization Token, followed by a list of context types.
If no context types are specified, then all contexts for the mobile
node are requested. The MN Authorization Token is computed by laying
out all the context data according to the specifications given within
the Context Type document, without any abbreviation or implicit
Loughney et al. expires August 2003 [Page 11]
Internet-Draft February 2003
specification as for default values.
3. Transport Considerations
It is not the intention of this work to define a new general-purpose
transport protocol. In this section we outline the issues of running
CTP over well-known protocols.
ICMP and UDP do not provide congestion control, while TCP/SCTP do
provide congestion control. The connection setup for those
congestion control transport protocols may introduce delays in start
of data transfer, but do protect the network from becoming
overloaded. This trade off needs to be further studied in terms of
applicability of context transfer. Since the data to be handled by
the context transfer protocol is typically transmitted locally only,
between access routers, the danger for congestion in the network at
large is substantially reduced or eliminated. Some issues affecting
this will be the type of signaling - for example, intra-domain vs.
inter-domain.
Of the existing transport mechanisms, both TCP and SCTP provide
checksums. UDP provides only an optional checksum. In order to
enable use of multiplexing functionality of context transfer
protocol, the UDP checksum MAY be de-activated to provide flexibility
in inserting checksums within context information as needed. This
will decrease the likelihood that the entire context data packet is
dropped due to individual feature data corruptions.
3.1 Congestion Control
Context transfer enables smooth handovers and prevents the need of
re-initializing signaling to and from a mobile node after handover.
Context transfer takes place between access routers.
The goal of congestion control is to prevent congestion by noting
packet loss at the transport layer and reducing the congestion
control window when packet loss occurs, thus effectively restricting
the available in-flight window for packet sending. Additionally, TCP
& SCTP deploy slow-start mechanisms at start-up, in order to prevent
congestion problems at the start of a new TCP/SCTP session.
As some context is time-critical, delays due to congestion control
may reduce the performance of mobile nodes; additionally, signaling
from the mobile node may be increased if the context transfer of time
critical data fails.
Therefore, some analysis is needed on the role of congestion control
Loughney et al. expires August 2003 [Page 12]
Internet-Draft February 2003
and context transfer. Important considerations should be network-
provisioning, intra-domain vs. inter-domain signaling as well as
other considerations. A quick analysis follows.
It is assumed that intra-domain time-critical context transfer should
take no more than one kilobyte, based on existing implementation of
some context transfer solutions. Contexts that are significantly
larger are assumed not so time critical. For a larger number of
users, say one thousand users requesting a smooth handover all in the
same second, the total bandwidth needed is still a small fraction of
a typical Ethernet or frame relay or ATM link between access routers.
So even bursty traffic is unlikely to introduce local congestion.
Furthermore, physically adjacent access routers should be within one
or two IP hops of each other, so the effects of context transfer
should be localized. If transferring real-time contexts triggers
congestive errors, the access network may be seriously under-
provisioned.
In order to handle multiple contexts to be transferred with differing
reliability needs, each context has to be considered separately by
the sending access router nAR. If a CTD message is retransmitted
because the CTDR message was not received in time, then those
contexts that are "too late" should not be included as part of the
retransmitted CTD data.
3.2 Transport Protocols
3.2.1 ICMP
Pros
* No explicit connection setup needed.
* Reliability handled at the upper layer.
* Co-ordination with mobility solutions easier to implement.
Cons
* No transport level signaling
* No reliability
* No ability to fragment data.
* Upper Size limits on packets.
* ICMP messages have low priority in case of congestion
3.2.2 UDP
Pros
* No explicit connection setup needed.
* Reliability handled at the upper layer.
* Co-ordination with mobility solutions easier to implement.
Loughney et al. expires August 2003 [Page 13]
Internet-Draft February 2003
Cons
* No transport level signaling
* No reliability
* No ability to fragment data.
3.2.3 TCP
Pros
* Supports TLS
* Built in reliability
Cons
* 3-way handshake, mitigated if TCP connections are re-used.
Open issues
* Single TCP connection or multiple TCP connections? Per transfer
or per neighbor?
3.3.4 SCTP
Pros
* Supports TLS
* Built in reliability
* Message-oriented
* Multiple streams prevent head-of-line blocking for multiple users.
Cons
* 3-way handshake, mitigated if STCP connections are re-used.
Open issues
* Partial Reliability SCTP may be interesting, as it allows
selective retransmission.
4. Open Issues
This section lists some open issues that need further discussion.
4.1 Reliability
Should reliability be handled at the transport layer? Should the
reliability needs of contexts be handled at the CTP data level or CTP
message level?
4.2 Transport
Currently, the issue of which transport protocol should be supported
is open.
Loughney et al. expires August 2003 [Page 14]
Internet-Draft February 2003
4.3 Failure Handling
Failure of Context Transfer should at least cause no harm to the
network or to the user session. Failure reporting to the mobile node
may be needed. The details about how failure can be reported for
some individual contexts but not requiring retransmission of all
contexts should be straightforward but remain to be worked out.
4.4 Zone of Operation
Currently, the authors are restricting discussion of CTP to intra-
domain signaling. Discussion of inter-domain signaling left for
later discussions.
Inter-domain signaling places additional requirements on establishing
security relationships that may not be relevant for intra-domain.
Besides, physically adjacent routers may be more than several IP hops
away. Additionally, provisioning inter-domain signaling links may be
much more complicated.
Restricting CTP to intra-domain signaling simplifies security,
transport and provision concerns. Additionally, a restriction to
intra-domain signaling may help to ensure CT completes in sufficient
time to meet time sensitive requirements.
5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E | | |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |
5.2 Network controlled, initiated by nAR
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |----- CT request ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V | |----- CTDR (opt) ----->|
| | |
Loughney et al. expires August 2003 [Page 15]
Internet-Draft February 2003
Is a new message CT request needed?
5.3 Mobile controlled, Predictive New L2 up/old L2 down
CTSR request to nAR (nAR must be able to authenticate MN for CT,
security details later)
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |--------CTSR ------->| |
I | |---- CT request ------>|
M | | |
E | |<-------- CTD ---------|
: | | |
| | | |
V | | |
| | |
Is a new message CT request needed?
In case CT cannot be supported, a CTSR reject may be sent to the MN
by nAR.
5.4 Mobile controlled, Reactive CT New L2 up/old L2 down
CTSR request to pAR through nAR (the pAR needs to authenticate the
CTSR)
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |------- CTSR -------->|===== CTSR relay =====>|
I | | |
M | |<------- CTD --------- |
E | | |
: | | |
| | | |
V | | |
| | |
Loughney et al. expires August 2003 [Page 16]
Internet-Draft February 2003
The CTSR relay is the CTSR message that is destined to pAR and is
routed through nAR (routing details later). In case CT cannot be
supported, a CTSR reject maybe sent to the MN through nAR.
6. Security Considerations
The Context Transfer Protocol essentially transfers state between
access routers. If the mobile nodes are not authenticated and
authorized before moving on the network, there is a potential for
DoS-style attacks to shift state between ARs, causing network
disruptions.
In general, CTP relies on IETF standardized security mechanisms for
protecting traffic between access routers, as opposed to creating
application security mechanisms. Both IPsec and TLS [TLS] may be
reasonable mechanisms for securing the context transfer between
access routers.
In order to avoid the introduction of additional latency to context
transfer due to the need for establishment of secure channel between
the context transfer peers (ARs), the two ARs SHOULD establish such
secure channel in advance. If IPSec is used, for example, the two AR
need to engage in a key exchange mechanisms such as IKE [IKE],
establish IPSec SAs, defining the keys, algorithms and IPSec
protocols (such as ESP) in anticipation for any upcoming context
transfer. This will save time during handovers that require secure
transfer of mobile node's context(s). Such SAs can be maintained and
used for all upcoming context transfers between the two ARs.
Security should be negotiated prior to the sending of context.
Furthermore, either one or both of the pAR and nAR need to be able
authenticate the mobile and authorize mobile's credential before
authorizing the context transfer and release of context to the
mobile. In case the context transfer is request by the MN, a
mechanism MSUT be provided so that requests are authenticated
(regardless of the security of context transfer itself) to prevent
the possibility of rouge MNs launching DoS attacks by sending large
number of CT requests as well as cause large number of context
transfers between ARs.Another important consideration is that the
mobile node should claim it's own context, and not some other
masquerader. One method to achieve this is to provide an
authentication cookie to be included with the context transfer
message sent from the pAR to the nAR and confirmed by the mobile node
at the nAR.
Loughney et al. expires August 2003 [Page 17]
Internet-Draft February 2003
7. IANA Considerations
This document authorized IANA to create a registry for Context
Profile Types, introduced in this document. For future Context
Profile Types, it is recommended that allocations be done on the
basis of Designated Expert.
The Context Profile Type introduced in this document requires IANA
Type Numbers for each set of feature contexts that make use of
Profile Types.
For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the
Designated Expert.
8. Acknowledgements
This document is the result of a design team formed by the Working
Group chairs of the SeaMoby working group. The team included John
Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. The
working group chairs are Pat Calhoun and James Kempf, whose comments
have been very helpful during the creating of this specification.
9. References
9.1 Normative References
[2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, RFC 2119, March 1997.
[CT-REQ] G. Kenward et al., "General Requirements for Context
Transfer", Internet Draft, Internet Engineering Task Force,
Work in Progress.
[CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for
Seamless Mobility", Internet Draft, Internet Engineering
Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
Engineering Task Force. Work in Progress.
[IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Con-
siderations Section in RFCs", BCP 26, RFC 2434, October
Loughney et al. expires August 2003 [Page 18]
Internet-Draft February 2003
1998.
[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Internet Engineering Task Force. Work in Progress.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
9.2 Non-Normative References
[3374] J. Kempf et al., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network", RFC
3374, Internet Engineering Task Force, RFC 3374, May 2001.
[2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress.
Appendix A. Simplified Example Context Type Specification
This diagram illustrates the method for specifying context type data
to be associated with a particular context type for Header Compres-
sion.
TBA
Context Type: Header Compression
Data fields:
IP header fields
Current IP Source Address 32bits Change recipe
Current IP Destination Address 32bits Change recipe
UDP header fields
RTP header fields
Appendix B. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the services
running on top of Mobile IP, which may introduce unwanted latencies that
practically prohibit its use for certain types of services. Mobile IP latency
and packet loss is being optimized through several alternative procedures,
such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute zero
(optimally) or minimal extra disruption of services in conjunction to
handovers. This means that the timing of context transfer SHOULD be carefully
aligned with basic Mobile IP handover events, and with optimized Mobile IP
handover signaling mechanisms, as those protocols become available.
Loughney et al. expires August 2003 [Page 19]
Internet-Draft February 2003
Furthermore, some of those optimized mobile IP handover mechanisms (such as
BETH) may provide more flexibility is choosing the timing and order for
transfer of various context information.
Author's Addresses
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Rajeev.koodli@nokia.com
John Loughney
Nokia
Itdmerenkatu 11-13
00180 Espoo
Finland
john.loughney@nokia.com
Madjid F. Nakhjiri
Motorola Labs
1031 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196
USA
madjid.nakhjiri@motorola.com
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
charliep@iprg.nokia.com
Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights
by implementers or users of this specification can be obtained from
the IETF Secretariat.
Loughney et al. expires August 2003 [Page 20]
Internet-Draft February 2003
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Loughney et al. expires August 2003 [Page 21]