draft-ietf-seamoby-ctp-00.txt   draft-ietf-seamoby-ctp-01.txt 
Seamoby WG Seamoby WG J. Loughney (editor)
Internet Draft J. Loughney (editor) Internet Draft M. Nakhjiri
Document: draft-ietf-seamoby-ctp-00.txt Nokia Category: Standards Track C. Perkins
M. Nakhjiri <draft-ietf-seamoby-ctp-01.txt> R. Koodli
Motorola Expires: September 2003 March 2003
C. Perkins
Nokia
Expires: October 2002 October 2002
Context Transfer Protocol Context Transfer Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 31 skipping to change at page 1, line 28
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2003. All Rights Reserved.
Abstract Abstract
This document presents a context transfer protocol that enables This document presents a context transfer protocol that enables
authorized context transfers. Context transfers allows better authorized context transfers. Context transfers allows better
support for node based mobility so that the applications running on support for node based mobility so that the applications running on
mobile nodes can operate with minimal disruption. Key objectives are mobile nodes can operate with minimal disruption. Key objectives are
to reducing latency, packet losses and avoid re-initiation of to reducing latency, packet losses and avoid re-initiation of
signaling to and from the mobile node. signaling to and from the mobile node.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction
1.1 Conventions Used in This Document..........................4 1.1 Conventions Used in This Document
1.2 Abbreviation Used in the Document..........................4 1.2 Abbreviation Used in the Document
2. Protocol Overview..............................................4 2. Protocol Overview
2.1 Context Transfer Packet Format.............................4 2.1 Context Transfer Packet Format
2.2 Messages...................................................5 2.2 Context Types
2.3 Message Types..............................................5 2.3 Context Data Block
2.4 Data Format................................................6 2.4 Messages
3. Timing and Trigger Considerations..............................6 3. Transport Considerations
3.1 Starting Event.............................................7 3.1 Congestion Control
4. Transport Considerations.......................................7 3.2 Transport Protocols
4.1 Congestion Control.........................................8 4. Open Issues
4.2 ICMP.......................................................8 4.1 Reliability
4.3 UDP........................................................9 4.2 Transport
4.4 TCP........................................................9 4.3 Failure Handling
4.5 SCTP.......................................................9 4.4 Zone of Operation
5. Open Issues....................................................9 5. Examples and Signaling Flows
5.1 Reliability................................................9 5.1 Network controlled, Initiated by pAR
5.2 Transport.................................................10 5.2 Network controlled, Initiated by nAR
5.3 Failure Handling..........................................10 5.3 Mobile controlled, Predictive New L2 up/old L2 down
5.4 Zone of Operation.........................................10 5.4 Mobile controlled, Reactive CT New L2 up/old L2 down
6. Examples and Signaling Flows..................................10 6. Security Considerations
7. Security Considerations.......................................10 7. IANA Considerations
8. IANA Considerations...........................................11 8. Acknowledgements
9. Acknowledgements..............................................12 9. References
10. References...................................................12 9.1 Normative References
10.1 Normative References.....................................12 9.2 Non-Normative References
10.2 Non-Normative References.................................12 Appendix A. Simplified Example Context Type Specification
Author's Addresses...............................................13 Appendix B. Timing and Trigger Considerations
Author's Addresses
1. Introduction 1. Introduction
"Problem Description: Reasons For Performing Context Transfers "Problem Description: Reasons For Performing Context Transfers
between Nodes in an IP Access Network" [3374] defines the following between Nodes in an IP Access Network" [3374] defines the following
main reasons why Context Transfer procedures may be useful in IP main reasons why Context Transfer procedures may be useful in IP
networks. networks.
1) The primary motivation, as mentioned in the introduction, is the 1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services need to quickly re-establish context transfer-candidate services
skipping to change at page 3, line 16 skipping to change at page 3, line 16
"Problem Description: Reasons For Performing Context Transfers "Problem Description: Reasons For Performing Context Transfers
between Nodes in an IP Access Network" [3374] defines the following between Nodes in an IP Access Network" [3374] defines the following
main reasons why Context Transfer procedures may be useful in IP main reasons why Context Transfer procedures may be useful in IP
networks. networks.
1) The primary motivation, as mentioned in the introduction, is the 1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch. protocol flows for those services from scratch.
2) An additional motivation is to provide an interoperable solution 2) An additional motivation is to provide an interoperable solution
that works for any Layer 2 radio access technology. that works for any Layer 2 radio access technology.
Access Routers typically establish state in order to effect certain Access Routers typically establish state in order to effect certain
forwarding treatments to packet streams belonging to nodes sharing forwarding treatments to packet streams belonging to nodes sharing
the access router. For instance, an access router may establish an 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 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- the link connecting a mobile node and the access router is
constrained, the access router may maintain header compression state bandwidth-constrained, the access router may maintain header
on behalf of the mobile node. When such a node moves to a different compression state on behalf of the mobile node. When such a node
access router, this state or context relocation during handover moves to a different access router, this state or context relocation
provides many important benefits, including: during handover provides many important benefits, including:
. Seamless operation of application streams. The handover node * Seamless operation of application streams. The handover node
(i.e., the Mobile Node) does not need to re-establish its (i.e., the Mobile Node) does not need to re-establish its
contexts at the new access router contexts at the new access router
* Performance benefits. When contexts need to be reestablished,
. Performance benefits. When contexts need to be reestablished,
performance of transport protocols would suffer until the performance of transport protocols would suffer until the
contexts are in place. For instance, when the required QoS contexts are in place. For instance, when the required QoS
state is not present, a stream's packets would not receive the state is not present, a stream's packets would not receive the
desired per-hop behavior treatment, subjecting them to higher desired per-hop behavior treatment, subjecting them to higher
likelihood of unacceptable delays and packet losses. likelihood of unacceptable delays and packet losses.
* Bandwidth savings. Re-establishing multiple contexts over an
. Bandwidth savings. Re-establishing multiple contexts over an
expensive, low-speed link can be avoided by relocating contexts expensive, low-speed link can be avoided by relocating contexts
over a potentially higher-speed wire. over a potentially higher-speed wire.
* Reduced susceptibility to errors, since much more of the
. Reduced susceptibility to errors, since much more of the
protocol operates over reliable networks, replacing protocol operates over reliable networks, replacing
renegotiations over a potentially error-prone link. renegotiations over a potentially error-prone link.
In [3374], a detailed description of motivation, the need and In [3374], a detailed description of motivation, the need and
benefits of context transfer are outlined. In this document, we benefits of context transfer are outlined. In this document, we
describe a generic context transfer protocol, which provides: describe a generic context transfer protocol, which provides:
. Representation for feature contexts. * Representation for feature contexts.
* Messages to initiate and authorize context transfer, and notify
. Messages to initiate and authorize context transfer, and notify
a mobile node of the status of the transfer. a mobile node of the status of the transfer.
* Messages for transferring contexts prior to, during and after
. Messages for transferring contexts prior to, during and after
handovers. handovers.
The proposed protocol is designed to work in conjunction with other The proposed protocol is designed to work in conjunction with other
protocols in order to provide seamless mobility. protocols in order to provide seamless mobility.
1.1 Conventions Used in This Document 1.1 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2119]. document are to be interpreted as described in RFC-2119 [2119].
skipping to change at page 4, line 46 skipping to change at page 4, line 39
MN Mobile Node MN Mobile Node
nAR New Access Router nAR New Access Router
pAR Previous Access Router pAR Previous Access Router
SA Security Association SA Security Association
2. Protocol Overview 2. Protocol Overview
This section provides a 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).
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).
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
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 2.1 Context Transfer Packet Format
The packet consists of a common header, message specific header and The packet consists of a common header, message specific header and
one or more data packets. Data packets may be bundled together in one or more data packets. Data packets may be bundled together in
order ensure a more efficient transfer. The total packet size, order ensure a more efficient transfer. The total packet size,
including transport protocol and IP protocol headers SHOULD be less including transport protocol and IP protocol headers SHOULD be less
than the path MTU, in order to avoid packet fragmentation. than the path MTU, in order to avoid packet fragmentation.
+----------------------+ +----------------------+
| CTP Header | | CTP Header |
+----------------------+ +----------------------+
| Message Header | | Message Header |
+----------------------+ +----------------------+
| CTP Data 1 | | CTP Data 1 |
+----------------------+ +----------------------+
| CTP Data 2 | | CTP Data 2 |
+----------------------+ +----------------------+
| ... | | ... |
2.2 Messages 2.2 Context Types
Generic message header format. 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
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
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 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 | Length | |V| Context Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authorization Token | | Presence Vector (if V = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data / / context type-dependent data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3 Message Types 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.
Context Transfer Start Request (CTSR) Message 2.4 Messages
Sent by MN or nAR to pAR request start of context transfer. It is In this section, a list of the available context transfer message
for further to study to see if when the CTSR message is sent by the types is given, along with a brief description of their functions.
MN to the nAR, it should also be relayed to pAR). Acknowledgement Generally, messages use the following generic message header format:
is optional, since if the CTSR message is sent by the MN, 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.
Context Transfer Initiate Ack (CTIN-Ack) Message 0 1 2 3
Sent by nAR to pAR, showing nAR's readiness to accept MN's context. 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
This message is used when reliability is required. In other words, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
if the reliability flag is set, this message must be sent. | Message Type |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ message data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Context Transfer Data (CTD) Message 2.4.1 Context Transfer Start Request (CTSR) Message
Sent by pAR to nAR, and includes feature data (CTP data). This Sent by MN to nAR to request start of context transfer. It is for
message should handle predictive as well as normal CT. A further to study to see if when the CTSR message is sent by the MN to
reliability flag included in this message indicates whether a reply the nAR, it should also be relayed to pAR. Acknowledgement is
is required by nAR. 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.
Context Transfer Data Reply (CTDR) Message 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).
This message is sent by nAR to pAR depending on the value of the 0 1 2 3
reliability flag in CTD. Indicates success or failure. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Context Transfer Cancel (CTA) Message 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.
Sent by nAR to pAR to cancel an ongoing CT process, for example 2.4.2 Context Transfer Data (CTD) Message
mobile node has moved, or nAR has waited too long for
retransmissions.
2.4 Data Format Sent by pAR to nAR, and includes feature data (CTP data). This
message should handle predictive as well as normal CT. A reliability
flag, R, included in this message indicates whether a reply is
required by nAR.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Length | | Message Type |C|R|rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ context feature data / | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. Timing and Trigger Considerations 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.
Basic Mobile IP handover signaling can introduce disruptions to the 2.4.3 Context Transfer Data Reply (CTDR) Message
services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for many 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 This message is sent by nAR to pAR depending on the value of the
zero (optimally) or minimally to the disruption of services in reliability flag in CTD. Indicates success or failure.
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 more stable.
In addition whenever possible, the context transfer procedure MUST 0 1 2 3
take measures to minimize the service disruption (packet loss) caused 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
by the context transfer procedure itself. This will be elaborated +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
further in the future updates of this draft. | Message Type |C| rsv | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1 Starting Event The OverallStatus is used for reporting overall success or failure,
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.
CT can be either started by a request from the MN or at the 2.4.4 Context Transfer Cancel (CTC) Message
initiative of new AR or pAR.
. MN can send the CT start request to old or new AR. The former is If transfering a context requires an ongoing process (i.e., is not
preferred since the MN is expected to have more satisfactory short-lived), then nAR may send CTC to pAR to cancel an ongoing CT
trust relationship with pAR than with nAR. Also sending the process.
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 new AR or old AR may request or start (respectively) 0 1 2 3
context transfer based on internal or network triggers. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here we prefer the following approach: 2.4.5 Context Transfer Request (CT Request) Message
The MN will send a context transfer request to the old AR (including Sent by nAR to pAR request start of context transfer. This message is
proper authentication material). After checking authentication and if sent as a response to CTSR message by the MN.
the pAR has a trust relationship with nAR, the old AR starts the
context transfer procedure.
4. Transport Considerations 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
specification as for default values.
3. Transport Considerations
It is not the intention of this work to define a new general-purpose 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 transport protocol. In this section we outline the issues of running
CTP over well-known protocols. CTP over well-known protocols.
A general note, however, on congestion control. ICMP and UDP do not ICMP and UDP do not provide congestion control, while TCP/SCTP do
provide congestion control, while TCP/SCTP do provide congestion provide congestion control. The connection setup for those
control. Congestion control may delay the transfer of context, but congestion control transport protocols may introduce delays in start
do protect the network. This trade off needs to be further studied of data transfer, but do protect the network from becoming
in terms of applicability of context transfer. Some issues affecting 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. this will be the type of signaling - for example, intra-domain vs.
inter-domain. inter-domain.
Of the existing transport mechanisms, both TCP and SCTP provide Of the existing transport mechanisms, both TCP and SCTP provide
checksums. UDP provides only an optional checksum. In order to make checksums. UDP provides only an optional checksum. In order to
efficient use of multiplexing functionality of context transfer enable use of multiplexing functionality of context transfer
protocol, the UDP checksum MUST be de-activated. This will decrease protocol, the UDP checksum MAY be de-activated to provide flexibility
the likelihood that the entire context data packet is dropped due to in inserting checksums within context information as needed. This
individual feature data corruptions. will decrease the likelihood that the entire context data packet is
dropped due to individual feature data corruptions.
4.1 Congestion Control 3.1 Congestion Control
Context transfer is essentially an optimization to enable smooth Context transfer enables smooth handovers and prevents the need of
handovers and to prevent the need of re-initializing signaling to and re-initializing signaling to and from a mobile node after handover.
from a mobile node after handover. Context transfer takes place Context transfer takes place between access routers.
between access routers.
The goal of congestion control is to prevent congestion by noting The goal of congestion control is to prevent congestion by noting
packet loss at the transport layer and reducing the congestion packet loss at the transport layer and reducing the congestion
control window when packet loss occurs, thus effectively restricting control window when packet loss occurs, thus effectively restricting
the available in-flight window for packet sending. Additionally, TCP the available in-flight window for packet sending. Additionally, TCP
& SCTP deploy slow-start mechanisms at start-up, in order to prevent & SCTP deploy slow-start mechanisms at start-up, in order to prevent
congestion problems at the start of a new TCP/SCTP session. congestion problems at the start of a new TCP/SCTP session.
As some context is time-critical, delays due to congestion control As some context is time-critical, delays due to congestion control
may reduce the performance of mobile nodes; additionally, signaling may reduce the performance of mobile nodes; additionally, signaling
from the mobile node may be increased if the context transfer of time from the mobile node may be increased if the context transfer of time
critical data fails. critical data fails.
Therefore, some analysis is needed on the role of congestion control Therefore, some analysis is needed on the role of congestion control
and context transfer. Important considerations should be network- and context transfer. Important considerations should be network-
provisioning, intra-domain vs. inter-domain signaling as well as provisioning, intra-domain vs. inter-domain signaling as well as
other considerations. A quick analysis follows. other considerations. A quick analysis follows.
It is assumed that intra-domain time-critical context transfer should It is assumed that intra-domain time-critical context transfer should
take approximately one kilobyte, based on existing implementation of take no more than one kilobyte, based on existing implementation of
some context transfer solutions. Contexts that are significantly some context transfer solutions. Contexts that are significantly
larger are assumed not so time critical. For a larger number of larger are assumed not so time critical. For a larger number of
users, say one thousand users requesting a smooth handover all in the users, say one thousand users requesting a smooth handover all in the
same second, the total bandwidth needed is still a small fraction of same second, the total bandwidth needed is still a small fraction of
a typical Ethernet or frame relay or ATM link between access routers. a typical Ethernet or frame relay or ATM link between access routers.
So even bursty traffic will be fine. Additionally, physically So even bursty traffic is unlikely to introduce local congestion.
adjacent access routers should be with in one or two IP hops of each Furthermore, physically adjacent access routers should be within one
other, so the effects of context transfer should be localized If or two IP hops of each other, so the effects of context transfer
transferring real-time contexts triggers congestive errors, the should be localized. If transferring real-time contexts triggers
access network may be seriously under-provisioned. congestive errors, the access network may be seriously under-
provisioned.
4.2 ICMP 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 Pros
. No explicit connection setup needed. * No explicit connection setup needed.
. Reliability handled at the upper layer. * Reliability handled at the upper layer.
. Co-ordination with mobility solutions easier to implement. * Co-ordination with mobility solutions easier to implement.
Cons Cons
. No transport level signaling * No transport level signaling
. No reliability * No reliability
. No ability to fragment data. * No ability to fragment data.
. Upper Size limits on packets. * Upper Size limits on packets.
* ICMP messages have low priority in case of congestion
. ICMP messages have low priority in case of congestion
4.3 UDP 3.2.2 UDP
Pros Pros
. No explicit connection setup needed. * No explicit connection setup needed.
. Reliability handled at the upper layer. * Reliability handled at the upper layer.
. Co-ordination with mobility solutions easier to implement. * Co-ordination with mobility solutions easier to implement.
Cons Cons
. No transport level signaling * No transport level signaling
. No reliability * No reliability
. No ability to fragment data. * No ability to fragment data.
4.4 TCP 3.2.3 TCP
Pros Pros
. Supports TLS * Supports TLS
. Built in reliability * Built in reliability
Cons Cons
. 3-way handshake, mitigated if TCP connections are re-used. * 3-way handshake, mitigated if TCP connections are re-used.
Open issues Open issues
. Single TCP connection or multiple TCP connections? * Single TCP connection or multiple TCP connections? Per transfer
or per neighbor?
4.5 SCTP 3.3.4 SCTP
Pros Pros
. Supports TLS * Supports TLS
. Built in reliability * Built in reliability
. Message-oriented * Message-oriented
. Multiple streams prevent head-of-line blocking for multiple * Multiple streams prevent head-of-line blocking for multiple users.
users.
Cons Cons
. 4-way handshake (though data can be included on 4th), mitigated * 3-way handshake, mitigated if STCP connections are re-used.
if TCP connections are re-used.
Open issues Open issues
. Partial Reliability SCTP may have interesting applicability * Partial Reliability SCTP may be interesting, as it allows
here. selective retransmission.
5. Open Issues 4. Open Issues
This section lists some open issues that need further discussion. This section lists some open issues that need further discussion.
5.1 Reliability 4.1 Reliability
Should reliability be handled at the transport layer? Should the Should reliability be handled at the transport layer? Should the
reliability needs of contexts be handled at the CTP data level or CTP reliability needs of contexts be handled at the CTP data level or CTP
message level? How to handle multiple contexts to be transferred message level?
with differing reliability needs.
5.2 Transport 4.2 Transport
Currently, the issue of which transport protocol should be supported Currently, the issue of which transport protocol should be supported
is open. is open.
5.3 Failure Handling 4.3 Failure Handling
Failure of Context Transfer should at least cause no harm to the Failure of Context Transfer should at least cause no harm to the
network or to the user session. Failure reporting to the mobile node network or to the user session. Failure reporting to the mobile node
may be needed. It is for further study how to handle failures of may be needed. The details about how failure can be reported for
context transfer. some individual contexts but not requiring retransmission of all
contexts should be straightforward but remain to be worked out.
5.4 Zone of Operation 4.4 Zone of Operation
Currently, the authors are restricting discussion of CTP to intra- Currently, the authors are restricting discussion of CTP to intra-
domain signaling. Discussion of inter-domain signaling left for domain signaling. Discussion of inter-domain signaling left for
later discussions. later discussions.
Inter-domain signaling is more complicated. For example, the Inter-domain signaling places additional requirements on establishing
physically adjacent routers may be more than several IP hops away. security relationships that may not be relevant for intra-domain.
Additionally, provisioning inter-domain signaling links may be much Besides, physically adjacent routers may be more than several IP hops
more complicated. away. Additionally, provisioning inter-domain signaling links may be
much more complicated.
Restricting CTP to intra-domain signaling simplifies security, Restricting CTP to intra-domain signaling simplifies security,
transport and provision concerns. Additionally, a restriction to transport and provision concerns. Additionally, a restriction to
intra-domain signaling may help to ensure CT completes in sufficient intra-domain signaling may help to ensure CT completes in sufficient
time to meet time sensitive requirements. time to meet time sensitive requirements.
6. Examples and Signaling Flows 5. Examples and Signaling Flows
To be added. 5.1 Network controlled, Initiated by pAR
7. Security Considerations 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) ----->|
| | |
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 | | |
| | |
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 The Context Transfer Protocol essentially transfers state between
access routers. If the mobile nodes are not authenticated and access routers. If the mobile nodes are not authenticated and
authorized before moving on the network, there is a potential for authorized before moving on the network, there is a potential for
DoS-style attacks by bad guys trying to shift state between ARs, DoS-style attacks to shift state between ARs, causing network
causing network disruptions. disruptions.
In general, CTP MUST rely on IETF standardized security mechanisms In general, CTP relies on IETF standardized security mechanisms for
for protecting traffic between access routers, as opposed to creating protecting traffic between access routers, as opposed to creating
application security mechanisms. Both IPsec and TLS [TLS] may be application security mechanisms. Both IPsec and TLS [TLS] may be
reasonable mechanisms for securing the context transfer between reasonable mechanisms for securing the context transfer between
access routers. access routers.
In order to avoid the introduction of additional latency to context In order to avoid the introduction of additional latency to context
transfer due to the need for establishment of secure channel between transfer due to the need for establishment of secure channel between
the context transfer peers (ARs), the two ARs SHOULD establish such the context transfer peers (ARs), the two ARs SHOULD establish such
secure channel in advance. If IPSec is used, for example, the two AR 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], need to engage in a key exchange mechanisms such as IKE [IKE],
establish IPSec SAs, defining the keys, algorithms and IPSec establish IPSec SAs, defining the keys, algorithms and IPSec
skipping to change at page 11, line 27 skipping to change at page 17, line 42
Security should be negotiated prior to the sending of context. Security should be negotiated prior to the sending of context.
Furthermore, either one or both of the pAR and nAR need to be able Furthermore, either one or both of the pAR and nAR need to be able
authenticate the mobile and authorize mobile's credential before authenticate the mobile and authorize mobile's credential before
authorizing the context transfer and release of context to the authorizing the context transfer and release of context to the
mobile. In case the context transfer is request by the MN, a mobile. In case the context transfer is request by the MN, a
mechanism MSUT be provided so that requests are authenticated mechanism MSUT be provided so that requests are authenticated
(regardless of the security of context transfer itself) to prevent (regardless of the security of context transfer itself) to prevent
the possibility of rouge MNs launching DoS attacks by sending large the possibility of rouge MNs launching DoS attacks by sending large
number of CT requests as well as cause large number of context number of CT requests as well as cause large number of context
transfers between ARs. transfers between ARs.Another important consideration is that the
mobile node should claim it's own context, and not some other
Another important consideration is that the mobile node should claim masquerader. One method to achieve this is to provide an
it's own context, and not some other masquerader. One method to authentication cookie to be included with the context transfer
achieve this is to provide an authentication cookie to be included message sent from the pAR to the nAR and confirmed by the mobile node
with the context transfer message sent from the pAR to the nAR and at the nAR.
confirmed by the mobile node at the nAR.
8. IANA Considerations
This section provides guidance to the Internet Assigned Numbers 7. IANA Considerations
Authority (IANA) regarding registration of values related to the
Diameter protocol, in accordance with BCP 26 [IANA].
This document authorized IANA to create a registry for Context This document authorized IANA to create a registry for Context
Profile Types, introduced in this document. For future Context Profile Types, introduced in this document. For future Context
Profile Types, it is recommended that allocations be done on the Profile Types, it is recommended that allocations be done on the
basis of Designated Expert. basis of Designated Expert.
The Context Profile Type introduced in this document requires IANA The Context Profile Type introduced in this document requires IANA
Type Numbers for each set of feature contexts that make use of Type Numbers for each set of feature contexts that make use of
Profile Types. Profile Types.
For registration requests where a Designated Expert should be For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the consulted, the responsible IESG area director should appoint the
Designated Expert. Designated Expert.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Rajeev Koodli, whose prior Context
Transfer Framework was used as the basis for part of this work.
This document is the result of a design team formed by the Working This document is the result of a design team formed by the Working
Group chairs of the SeaMoby working group. The team included John Group chairs of the SeaMoby working group. The team included John
Loughney, Madjid Nakhjiri and Charles Perkins. The Working Group Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. The
chairs, Pat Calhoun and James Kempf monitored the design team. working group chairs are Pat Calhoun and James Kempf, whose comments
have been very helpful during the creating of this specification.
10. References 9. References
10.1 Normative References 9.1 Normative References
[2026] S. Bradner, "The Internet Standards Process -- Revision 3", [2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[2119] S. Bradner, "Key words for use in RFCs to Indicate [2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
Requirement Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
[CT-REQ] G. Kenward et al., "General Requirements for Context [CT-REQ] G. Kenward et al., "General Requirements for Context
Transfer", Internet Draft, Internet Engineering Task Force, Transfer", Internet Draft, Internet Engineering Task Force,
Work in Progress. Work in Progress.
[CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for [CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for
Seamless Mobility", Internet Draft, Internet Engineering Seamless Mobility", Internet Draft, Internet Engineering
Task Force, Work in Progress. Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
Engineering Task Force. Work in Progress. Engineering Task Force. Work in Progress.
[IANA] Narten, Alvestrand, "Guidelines for Writing an IANA [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Con-
Considerations Section in RFCs", BCP 26, RFC 2434, October siderations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Internet Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
10.2 Non-Normative References 9.2 Non-Normative References
[3374] J. Kempf et al., "Problem Description: Reasons For [3374] J. Kempf et al., "Problem Description: Reasons For Performing
Performing Context Transfers Between Nodes in an IP Context Transfers Between Nodes in an IP Access Network", RFC
Access Network", RFC 3374, Internet Engineering Task 3374, Internet Engineering Task Force, RFC 3374, May 2001.
Force, RFC 3374, May 2001.
[2401] S. Kent, R. Atkinson, "Security Architecture for the [2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Internet Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Internet Engineering Task Force, Work in Progress. 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.
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 Author's Addresses
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Rajeev.koodli@nokia.com
John Loughney John Loughney
Nokia Nokia
Itmerenkatu 11-13 Itdmerenkatu 11-13
00180 Espoo 00180 Espoo
Finland Finland
john.loughney@nokia.com john.loughney@nokia.com
Madjid F. Nakhjiri Madjid F. Nakhjiri
Motorola Labs Motorola Labs
1031 East Algonquin Rd., Room 2240 1031 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196 Schaumburg, IL, 60196
USA USA
madjid.nakhjiri@motorola.com madjid.nakhjiri@motorola.com
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
charliep@iprg.nokia.com 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.
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.
 End of changes. 

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