draft-ietf-seamoby-ctp-02.txt   draft-ietf-seamoby-ctp-03.txt 
Seamoby WG J. Loughney (editor) Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri Internet Draft M. Nakhjiri
Category: Standards Track C. Perkins Category: Experimental C. Perkins
draft-ietf-seamoby-ctp-02.txt R. Koodli <draft-ietf-seamoby-ctp-03.txt> R. Koodli
Expires: December 2003 June 2003 Expires: December 2003 June 2003
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 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 37 skipping to change at page 1, line 39
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. Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2003. All Rights Reserved. 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 mobile nodes to authorize context transfers between access routers.
support for node based mobility so that the applications running on Context transfers allow better support for node based mobility so
mobile nodes can operate with minimal disruption. Key objectives are that the applications running on mobile nodes can operate with
to reducing latency, packet losses and avoid re-initiation of minimal disruption. Key objectives are to reduce latency, packet
signaling to and from the mobile node. losses and avoiding re-initiation of signaling to and from the mobile
node.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1 Conventions Used in This Document 1.1 Conventions Used in This Document
1.2 Abbreviations Used in the Document 1.2 Abbreviations Used in the Document
2. Protocol Overview 2. Protocol Overview
2.1 Context Transfer Packet Formats 2.1 Context Transfer Packet Formats
2.2 Context Types 2.2 Context Types
2.3 Context Data Block 2.3 Context Data Block
2.4 Messages 2.4 Messages
3. Transport, Reliability and Retransmission of Feature Data 3. Transport, Reliability and Retransmission of Feature Data
4. Open Issues 4. Open Issues
4.1 Failure Handling ti -5 5. Examples and Signaling Flows 4.1 Failure Handling ti -5 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 5.1 Network controlled, Initiated by pAR
5.2 Network controlled, Initiated by nAR 5.2 Network controlled, Initiated by nAR
5.3 Mobile controlled, Predictive New L2 up/old L2 down 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 6. Security Considerations
7. IANA Considerations 7. IANA Considerations
8. Acknowledgements 8. Acknowledgements
9. References 9. References
9.1 Normative References 9.1 Normative References
9.2 Non-Normative References 9.2 Non-Normative References
Appendix A. Simplified Example Context Type Specification Appendix A. Timing and Trigger Considerations
Appendix B. Timing and Trigger Considerations Appendix B. Congestion Control
Appendix C. Congestion Control
Appendix D. Zone of Operation
Author's Addresses 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" [RFC3374] defines the between Nodes in an IP Access Network" [RFC3374] defines the
following main reasons why Context Transfer procedures may be useful following main reasons why Context Transfer procedures may be useful
in IP networks. in IP 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. An example of a
2) An additional motivation is to provide an interoperable solution service is Context Relocation for Seamless Header Compression in IP
that works for any Layer 2 radio access technology. Networks [CTHC].
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 2) An additional motivation is to provide an interoperable solution
i.e., the Mobile Node) does not need to re-establish its that supports various Layer 2 radio access technologies.
contexts from scratch 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 [RFC3374], a detailed description of motivation, the need and This document describes a generic context transfer protocol, which
benefits of context transfer are outlined. In this document, we 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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Abbreviations Used in the Document 1.2 Abbreviations Used in the Document
AR Access Router Mobility Related Terminology [TERM] defines basic mobility
terminology. In addition to the material in that document, we use
CT Context Transfer the following terms and abbreviation in this document.
CTP Context Transfer Protocol CTP Context Transfer Protocol
DoS Denial-of-Service DoS Denial-of-Service
FPT Feature Profile Types FPT Feature Profile Types
MIP Mobile IP
MN Mobile Node
nAR New Access Router
pAR Previous Access Router
SA Security Association
2. Protocol Overview 2. Protocol Overview
This section provides a protocol overview. A context transfer can be This section provides a protocol overview. A context transfer can be
either started by a request from the mobile node ("mobile either started by a request from the mobile node ("mobile
controlled") or at the initiative of either the new or the previous controlled") or at the initiative of either the new or the previous
access router ("network controlled"). access router ("network controlled").
* The mobile node sends the CT Activate Request to old AR whenever * The mobile node sends the CT Activate Request to old AR whenever
possible to initiate predictive context transfer. In any case, the possible to initiate predictive context transfer. In any case, the
MN always sends the CTAR message to new AR. If the contexts are MN always sends the CTAR message to new AR. If the contexts are
already present, nAR would verify the authorization token present already present, nAR would verify the authorization token present
in CTAR with its own computation (using the parameters supplied by in CTAR with its own computation (using the parameters supplied by
pAR), and subsequently activate those contexts. If the contexts pAR), and subsequently activate those contexts. If the contexts
are not present, nAR requests pAR to supply them using the Context are not present, nAR requests pAR to supply them using the Context
Transfer Request message, in which it supplies the authorization Transfer Request message, in which it supplies the authorization
token present in CTAR. token present in CTAR.
* Either nAR or pAR may request or start (respectively) context * Either nAR or pAR may request or start (respectively) context
transfer based on internal or network triggers (see Appendix B). transfer based on internal or network triggers (see Appendix B).
The Context Transfer protocol typically operates between a source The Context Transfer protocol typical lly operates between
node and a target node. In the future, there may be multiple target a source node and a target node. In the future, there may be multiple
nodes involved; the protocol described here would work with multiple target nodes involved; the protocol described here would work with
target nodes. For simplicity, we describe the protocol assuming a multiple target nodes. For simplicity, we describe the protocol
single receiver or target node. assuming a single receiver or target node.
Typically, the source node is a MN's Previous Access Router (pAR) and 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 the target node is MN's New Access Router (nAR). Context Transfer
and nAR share an appropriate security association, set up takes place when an event, such as a handover, takes place. We call
independently and prior to context transfer. Any appropriate such an event as a Context Transfer Trigger. In response to such a
mechanism may be used in setting up this security association; it trigger, the pAR may transfer the contexts; the nAR may request
enables the CT peers to utilize a secure channel for transferring contexts; and the MN may send a message to the routers to transfer
contexts, providing authentication, integrity, and (if needed) contexts. Such a trigger must be capable of providing the necessary
confidentiality. information, such as the MN's IP address with which the contexts are
associated, the IP addresses of the access routers, and authorization
Context Transfer takes place when an event, such as a handover, takes to transfer context.
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
routers 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 Feature Profile Types that Context transfer protocol messages use Feature Profile Types that
identify the way that data is organized for the particular feature identify the way that data is organized for the particular feature
contexts. The Feature Profile Types (FPTs) are registered in a number contexts. The Feature Profile Types (FPTs) are registered in a number
space (with IANA Type Numbers) that allows a node to unambiguously space (with IANA Type Numbers) that allows a node to unambiguously
determine the type of context and the context parameters present in determine the type of context and the context parameters present in
the protocol messages. Contexts are transferred by laying out the the protocol messages. Contexts are transferred by laying out the
appropriate feature data within Context Data Blocks according to the appropriate feature data within Context Data Blocks according to the
format in section 2.3, as well as any IP addresses necessary to format in section 2.3, as well as any IP addresses necessary to
associate the contexts to a particular MN. The context transfer associate the contexts to a particular MN. The context transfer
skipping to change at line 247 skipping to change at page 5, line 43
receiving the CTAR message or as a response to an internal trigger receiving the CTAR message or as a response to an internal trigger
(that indicates the MN's attachment). In the CT-Req message, nAR (that indicates the MN's attachment). In the CT-Req message, nAR
supplies the MN's previous IP address, the feature contexts to be supplies the MN's previous IP address, the feature contexts to be
transferred, and a token (generated by the MN) authorizing context transferred, and a token (generated by the MN) authorizing context
transfer. In response to CT Request message, pAR transmits a Context transfer. In response to CT Request message, pAR transmits a Context
Transfer Data (CTD) message that includes the MN's previous IP Transfer Data (CTD) message that includes the MN's previous IP
address and feature contexts. When it receives a corresponding CTD address and feature contexts. When it receives a corresponding CTD
message, nAR may generate a CTD Reply message (See Section 2.4.3) to message, nAR may generate a CTD Reply message (See Section 2.4.3) to
report the status of processing the received contexts. report the status of processing the received contexts.
[1].* contexts, pAR verifies authorization token before transmitting
the [2].* in the CTD message.
When context transfer takes place without the nAR requesting it When context transfer takes place without the nAR requesting it
(scenario one above), nAR should require MN to present its (scenario one above), nAR requires MN to present its authorization
authorization token. Doing this locally at nAR when the MN attaches token. Doing this locally at nAR when the MN attaches to it improves
to it improves performance, since the contexts are highly likely to performance and increases security, since the contexts are highly
be present already. When context transfer happens with an explicit likely to be present already. When context transfer happens with an
request from nAR (scenario two above), pAR performs such verification explicit request from nAR (scenario two above), pAR performs such
since the contexts are still present at pAR. In either case, token verification since the contexts are still present at pAR. In either
verification takes place at the router possessing the contexts. case, token verification takes place at the router possessing the
contexts.
Performing context transfer in advance of the MN attaching to nAR Performing context transfer in advance of the MN attaching to nAR can
clearly has potential for better performance. For this to take increase handover performance. For this to take place, certain
place, certain conditions must be met. For example, pAR must have conditions must be met. For example, pAR must have sufficient time
sufficient time and knowledge about the impending handover. This is and knowledge about the impending handover. This is feasible, for
feasible for instance in Mobile IP fast handovers. However, when the instance, in Mobile IP fast handovers. Additionally, many cellular
advance knowledge of impending handover is not available, or if a networks have mechanisms to detect handovers in advance. However,
mechanism such as fast handover fails, retrieving feature contexts when the advance knowledge of impending handover is not available, or
after the MN attaches to nAR is the only available means for context if a mechanism such as fast handover fails, retrieving feature
transfer. Performing context transfer after handover might still be contexts after the MN attaches to nAR is the only available means for
better than having to re-establish all the contexts from scratch. context transfer. Performing context transfer after handover might
Finally, some contexts may simply need to be transferred during still be better than having to re-establish all the contexts from
handover signaling. For instance, any context that gets updated on a scratch. Finally, some contexts may simply need to be transferred
per-packet basis must clearly be transferred only after packet during handover signaling. For instance, any context that gets
forwarding to the MN on its previous link is terminated. Transfer of updated on a per-packet basis must clearly be transferred only after
such contexts must be properly synchronized with appropriate handover packet forwarding to the MN on its previous link is terminated.
messages, such as Mobile IP (Fast) Binding Update.
The messages (CTD and CTDR) which perform the context transfer The messages (CTD and CTDR) that perform the context transfer between
between the access routers need to be authenticated, so that the the access routers need to be authenticated, so that the access
access routers can be certain that the data has not been tampered routers can be certain that the data has not been tampered with
with during delivery. This is especially true since there is no during delivery.
requirement that the access routers be attached to any common network
link, so that they can be more than one hop apart in the access
network. This requires that the access routers have an established
security association. Establishing such security associations is
much easier within a single network domain, but this document does
not restrict the context transfer signaling to happen only within a
single domain. Instead, the requirement it places is that the access
routers need to have a security association.
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.
+----------------------+ +----------------------+
skipping to change at line 329 skipping to change at page 7, line 26
context state vector. context state vector.
- Procedures and requirements for creating a context at a new - Procedures and requirements for creating a context at a new
access router, given the data transferred from a previous access router, given the data transferred from a previous
access router, and formatted according to the ordering rules access router, and formatted according to the ordering rules
and date field sizes presented in the specification. and date field sizes presented in the specification.
- If possible, status codes for success or failure related to the - If possible, status codes for success or failure related to the
context transfer. For instance, a QoS context transfer might context transfer. For instance, a QoS context transfer might
have different status codes depending on which elements of the have different status codes depending on which elements of the
context data failed to be instantiated at nAR. context data failed to be instantiated at nAR.
Appendix A contains an example context type specification for UDP/RTP
header compression context.
2.3 Context Data Block 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Context Type | |V| Context Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if V = 1) | | Presence Vector (if V = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ context type-dependent data / / context type-dependent data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'V' bit specifies whether or not the "presence vector" is used. 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 When the presence vector is in use, the next 32 bits are interpreted
to indicate whether particular data fields are present (and, thus, to indicate whether particular data fields are present (and, thus,
containing non-default values). The ordering of the bits in the containing non-default values). The ordering of the bits in the
presence vector is the same as the ordering of the data fields presence vector is the same as the ordering of the data fields
according to the context type specification, one bit per data field according to the context type specification, one bit per data field
regardless of the size of the data field. Notice that the length of 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 the context data block is defined by the sum of lengths of each data
skipping to change at line 376 skipping to change at page 8, line 20
| Message Type |reserve| Length | | Message Type |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP address | | Mobile Node's Previous IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ message data / / message data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Mobile Node, for which context transfer protocol operations are The Mobile Node, for which context transfer protocol operations are
undertaken, is always identified by its previous IP access address. undertaken, is always identified by its previous IP access address.
At any one time, only one context transfer operation may be in At any one time, only one context transfer operation per MN may be in
progress so that the CTDR message unambigously identifies which CTD progress so that the CTDR message unambiguously identifies which CTD
message is acknowledged simply by including the mobile node's message is acknowledged simply by including the mobile node's
identifying previous IP address. identifying previous IP address.
2.4.1 Context Transfer Activate Request (CTAR) Message 2.4.1 Context Transfer Activate Request (CTAR) Message
Always sent by MN to nAR to request context transfer activation. It This message is always sent by MN to nAR to request context transfer
is for further to study to see if when the CTAR message is sent by activation. It is for further to study to see if when the CTAR
the MN to the nAR, it should also be relayed to pAR. Acknowledgement message is sent by the MN to the nAR. If an acknowledgement is
is optional, since the MN may have already moved and may not receive needed, the MN sets the A flag to 1, other wise the MN does not
the reply. This message may include a list of FPT (feature profile expect an acknowledgement. This message may include a list of FPT
types) that require transfer. It may include flags to request secure (feature profile types) that require transfer. It may include flags
and/or reliable transfer. to request secure and/or reliable transfer.
The MN may also send this message to pAR while still connected to 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 pAR. In such a case, the MN includes the nAR's IP address and its new
new IP address (if known). IP address (if known).
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 |reserve| Length | | Message Type |A| rsv | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP Address | | Mobile Node's Previous IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Router IP Address | | Previous Router IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay | |Type=Auth-Token| Type Len | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Type (if present) | | Requested Context Type (if present) |
skipping to change at line 420 skipping to change at page 9, line 15
| Next Requested Context Type (if present) | | Next Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CTAR is the Mobile Node's Previous IP Address, The message data for CTAR is the Mobile Node's Previous IP Address,
Previous Router's IP address, MN Authorization Token, followed by a Previous Router's IP address, MN Authorization Token, followed by a
list of context types. If no context types are specified, then all list of context types. If no context types are specified, then all
contexts for the mobile node are requested. contexts for the mobile node are requested.
2.4.2 Context Transfer Data (CTD) Message 2.4.2 Context Transfer Activate Acknowledge (CTAA) Message
This is an informative message sent nAR to the MN to acknowledge a
CTAR message. 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 were not transferred
successfully.
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 IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Router IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Failed Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CTAR is the Mobile Node's Previous IP Address,
Previous Router's IP address, MN Authorization Token, followed by a
list of context types that were not successfully transferred. If no
context types are specified, then all contexts for the mobile node
are considered successfully transferred.
2.4.3 Context Transfer Data (CTD) Message
Sent by pAR to nAR, and includes feature data (CTP data). This Sent by pAR to nAR, and includes feature data (CTP data). This
message should handle predictive as well as normal CT. A reliability message should handle predictive as well as normal CT. A reliability
flag, R, included in this message indicates whether a reply is flag, R, included in this message indicates whether a reply is
required by nAR. This message SHOULD be protected by use of IPsec required by nAR.
Authentication Header (AH)[RFC2402]
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 |C|R|rsv| Length | | Message Type |C|R|rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) | | Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 459 skipping to change at page 10, line 40
The Authorization token type field is present in the predictive The Authorization token type field is present in the predictive
scenario only. The supplied parameters, algorithm, key length and the scenario only. The supplied parameters, algorithm, key length and the
key itself, allow nAR to compute a token locally depending on the key itself, allow nAR to compute a token locally depending on the
contents of the CTAR message. contents of the CTAR message.
The algorithm for carrying out the computation of the MN The algorithm for carrying out the computation of the MN
Authorization Token is HMAC_SHA1. The input data for computing the Authorization Token is HMAC_SHA1. The input data for computing the
token are: the MN's Previous IP address, the FPT objects and the token are: the MN's Previous IP address, the FPT objects and the
Replay field. When support for transferring all contexts is Replay field. When support for transferring all contexts is
requested, a default FPT is used. The Authorization Token is requested, a default FPT is used. The Authorization Token is obtained
obtained by truncating the results of the HMAC_SHA1 computation to by truncating the results of the HMAC_SHA1 computation to retain only
retain only the leading 32 bits. the leading 32 bits.
2.4.3 Context Transfer Data Reply (CTDR) Message 2.4.4 Context Transfer Data Reply (CTDR) Message
This message is sent by nAR to pAR depending on the value of the This message is sent by nAR to pAR depending on the value of the
reliability flag in CTD. Indicates success or failure. This message reliability flag in CTD. Indicates success or failure.
SHOULD be protected by use of IPsec Authentication Header
(AH)[RFC2402]
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 |C| rsv | Length | | Message Type |C| rsv | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... | | OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OverallStatus is used for reporting overall success or failure, The OverallStatus is used for reporting overall success or failure,
which could be based on verification of the MN authorization token which could be based on verification of the MN authorization token
for instance. For certain values of the overall status, it may be for instance. For certain values of the overall status, it may be
that some contexts were successfully transferred and some failed to that some contexts were successfully transferred and some failed to
be transferred. In this case, then for each context another status be transferred. In this case, then for each context another status
code MUST be provided to indicate to pAR which contexts have failed code MUST be provided to indicate to pAR those contexts that have
and which have succeeded, along with the reason. failed and those that have succeeded, along with the reason.
2.4.4 Context Transfer Cancel (CTC) Message 2.4.5 Context Transfer Cancel (CTC) Message
If transfering a context requires an ongoing process (i.e., is not If transferring a context cannot be completed in a timely fashion,
short-lived), then nAR may send CTC to pAR to cancel an ongoing CT then nAR may send CTC to pAR to cancel an ongoing CT process.
process.
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 | rsv | Length = 4 | | Message Type | rsv | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4.5 Context Transfer Request (CT Request) Message 2.4.6 Context Transfer Request (CT Request) Message
Sent by nAR to pAR request start of context transfer. This message is Sent by nAR to pAR request start of context transfer. This message is
sent as a response to CTAR message by the MN. sent as a response to CTAR message by the MN.
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 |reserve| Length | | Message Type |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
skipping to change at line 545 skipping to change at page 12, line 28
FPT objects and the Replay field. When support for transferring all FPT objects and the Replay field. When support for transferring all
contexts is requested, a default FPT is used. contexts is requested, a default FPT is used.
3. Transport, Reliability and Retransmission of Feature Data 3. Transport, Reliability and Retransmission of Feature Data
CTP runs over UDP using port number <TBD>. Some feature contexts may CTP runs over UDP using port number <TBD>. Some feature contexts may
specify a reliability factor, MAX_RETRY_INTERVAL, which is the length specify a reliability factor, MAX_RETRY_INTERVAL, which is the length
of time that the pAR is allowed to perform retransmissions before of time that the pAR is allowed to perform retransmissions before
giving up on the context transfer for that feature context. The giving up on the context transfer for that feature context. The
longer the allowed retry interval, the more retransmissions will be longer the allowed retry interval, the more retransmissions will be
possible for that feature context. It is expected that possible for that feature context.
retransmission will be a rare event, because of the physical
proximity of the access routers and likely characteristics of the
network media connecting the access routers.
For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD
retransmit an unacknowledged CTD message after waiting for retransmit an unacknowledged CTD message after waiting for
RETRANSMISSION_DELAY milliseconds. This time value is configurable RETRANSMISSION_DELAY milliseconds. This time value is configurable
based on the type of network interface; slower network media based on the type of network interface; slower network media
naturally will be configured with longer values for the naturally will be configured with longer values for the
RETRANSMISSION_DELAY. Except for the value of the elapsed time RETRANSMISSION_DELAY. Except for the value of the elapsed time
field, the payload of each retransmitted CTD packet is identical to field, the payload of each retransmitted CTD packet is identical to
the payload of the initially transmitted CTD packet, in order to the payload of the initially transmitted CTD packet, in order to
maintain the ability of the mobile device to present a correctly maintain the ability of the mobile device to present a correctly
calculated authentication token. The number of retransmissions, each calculated authentication token. The number of retransmissions, each
delayed by RETRANSMISSION_DELAY, depends on the maximum value for delayed by RETRANSMISSION_DELAY, depends on the maximum value for
MAX_RETRY_INTERVAL as specified by any of the contexts. The value MAX_RETRY_INTERVAL as specified by any of the contexts. The value
of the Elapsed Time field is the number of milliseconds since the of the Elapsed Time field is the number of milliseconds since the
transmission of the first CTD message transmission of the first CTD message
UDP provides a optional checksum, which SHOULD be checked. If the UDP provides an optional checksum, which SHOULD be checked. If the
checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with
the status value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in the status value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in
the CTD. the CTD.
4. Open Issues 4. Error Codes
This section lists error codes used by UDP
This section lists some open issues that need further discussion.
4.1 Failure Handling
Failure of Context Transfer should at least cause no harm to the BAD_UDP_CHECKSUM 0x01
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.
5. Examples and Signaling Flows 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 5.1 Network controlled, Initiated by pAR
MN nAR pAR MN nAR pAR
| | | | | |
T | | CT trigger T | | CT trigger
I | | | I | | |
M | |<------- CTD ----------| M | |<------- CTD ----------|
E |--------CTAR--------->| | E |--------CTAR--------->| |
: | | | : | | |
| | |-------- CTDR -------->| | | |-------- CTDR -------->|
V | | | V | | |
| | | | | |
5.2 Network controlled, initiated by nAR 5.2 Network controlled, initiated by nAR
in 6
MN nAR pAR MN nAR pAR
| | | | | |
T | CT trigger | T | CT trigger |
I | | | I | | |
M | |----- CT Request ----->| M | |----- CT Request ----->|
E | | | E | | |
: | |<------- CTD ----------| : | |<------- CTD ----------|
| | | | | | | |
V |--------CTAR--------->| | V |--------CTAR--------->| |
| |----- CTDR (opt) ----->| | |----- CTDR (opt) ----->|
| | | | | |
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3 Mobile controlled, Predictive New L2 up/old L2 down
CTAR request to nAR (nAR must be able to authenticate MN for CT, CTAR request to nAR
security details later)
MN nAR pAR MN nAR pAR
| | | | | |
new L2 link up | | new L2 link up | |
| | | | | |
CT trigger | | CT trigger | |
| | | | | |
T |--------CTAR ------->| | T |--------CTAR ------->| |
I | |---- CT Request ------>| I | |---- CT Request ------>|
M | | | M | | |
E | |<-------- CTD ---------| E | |<-------- CTD ---------|
: | | | : | | |
| | | | | | | |
V | | | V | | |
| | | | | |
In case CT cannot be supported, a CTAR reject (TBD) may be sent to In case CT cannot be supported, a CTAR reject (TBD) may be sent to
the MN by nAR. the MN by nAR.
5.4 Mobile controlled, Reactive CT New L2 up/old L2 down 6. Security Considerations
CTAR relay to pAR through nAR (the pAR needs to authenticate the 6.1. Threats.
CTAR)
MN nAR pAR The Context Transfer Protocol transfers state between access routers.
| | | If the mobile nodes are not authenticated and authorized before
new L2 link up | | moving on the network, there is a potential for DoS attacks to shift
| | | state between ARs, causing network disruptions.
CT trigger | |
| | |
T |------- CTAR -------->|===== CTAR relay =====>|
I | | |
M | |<------- CTD --------- |
E | | |
: | | |
| | | |
V | | |
| | |
The CTAR relay is the CTAR message that is destined to pAR and is Additionally, DoS attacks can be launched from mobile nodes towards
routed through nAR (routing details later). In case CT cannot be the access routers by requesting multiple context transfers and then
supported, a CTAR reject maybe sent to the MN through nAR. disappearing. Additionally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks.
6. Security Considerations 6.2. Security Details
The Context Transfer Protocol transfers state between access routers. CTP relies on IETF standardized security mechanisms for protecting
If the mobile nodes are not authenticated and authorized before traffic between access routers, as opposed to creating application
moving on the network, there is a potential for DoS-style attacks to security mechanisms. IPsec MUST be supported between access routers.
shift state between ARs, causing network disruptions.
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 secure channel in advance. If IPSec is used, for example, the two
access routers need to engage in a key exchange mechanisms such as access routers need to engage in a key exchange mechanisms such as
IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and
IPSec protocols (such as ESP) in anticipation for any upcoming IPSec protocols (such as ESP) in anticipation for any upcoming
context transfer. This will save time during handovers that require context transfer. This will save time during handovers that require
secure transfer of mobile node's context(s). Such SAs can be secure transfer of mobile node's context(s). Such SAs can be
maintained and used for all upcoming context transfers between the maintained and used for all upcoming context transfers between the
two ARs. Security should be negotiated prior to the sending of two ARs. Security should be negotiated prior to the sending of
context. 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 MUST 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 rogue MNs launching DoS attacks by sending large the possibility of rogue 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. Another important consideration is that the transfers between ARs. Another important consideration is that the
mobile node should claim it's own context, and not some other mobile node should claim it's own context, and not some other
masquerader. One method to achieve this is to provide an masquerader. One method to achieve this is to provide an
authentication cookie to be included with the context transfer authentication cookie to be included with the context transfer
message sent from the pAR to the nAR and confirmed by the mobile node message sent from the pAR to the nAR and confirmed by the mobile node
at the nAR. at the nAR.
6.3. IPsec Considerations
Access Routers MUST implement IPsec ESP [ESP] in transport mode with
non-null encryption and authentication algorithms to provide per-
packet authentication, integrity protection and confidentiality, and
MUST implement the replay protection mechanisms of IPsec. In those
scenarios where IP layer protection is needed, ESP in tunnel mode
SHOULD be used. Non-null encryption should be used when using IPSec
ESP.
7. IANA Considerations 7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Authority (IANA) regarding registration of values related to the
context transfer protocol, in accordance with BCP 26 [RFC2434]. context transfer protocol, in accordance with BCP 26 [RFC2434].
This document authorized IANA to create a registry for Context 7.1 Context Profile Types Registry
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 This document authorized IANA to create a registry for Context Profile
Type Numbers for each set of feature contexts that make use of Types, introduced in this document. For future Context Profile Types,
Profile Types. it is recommended that allocations be done on the basis of Designated
Expert.
For registration requests where a Designated Expert should be The Context Profile Type introduced in this document requires IANA Type
consulted, the responsible IESG area director should appoint the Numbers for each set of feature contexts that make use of Profile Types.
Designated Expert.
For registration requests where a Designated Expert should be consulted,
the responsible IESG area director should appoint the Designated Expert.
7.2 UDP Port
CTP requires a UDP port assignment.
8. Acknowledgements 8. Acknowledgements
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, Rajeev Koodli and Charles Perkins. The Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. The
working group chairs are Pat Calhoun and James Kempf, whose comments working group chairs are Pat Calhoun and James Kempf, whose comments
have been very helpful during the creating of this specification. have been very helpful during the creation of this specification.
9. References 9. References
9.1 Normative References 9.1 Normative References
S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, November [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402,
1998 November 1998
G. Kenward et al., "General Requirements for Context Transfer", [CT-REQ] G. Kenward et al., "General Requirements for Context
Internet Draft, Internet Engineering Task Force, Work in Progress. Transfer", Internet Draft, Internet Engineering Task Force,
Work in Progress.
R. Koodli, C.E. Perkins, "Context Transfer Framework for Seamless [CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for
Mobility", Internet Draft, Internet Engineering Task Force, Work in Seamless Mobility", Internet Draft, Internet Engineering
Progress. Task Force, Work in Progress.
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.
IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an IANA IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
November 1998. RFC 2409, November 1998.
K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", Internet [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay-
load (ESP)", RFC 2406, November 1998.
9.2 Non-Normative References 9.2 Non-Normative References
J. Kempf et al., "Problem Description: Reasons For Performing Context [CTHC] R. Koodli et al., "Context Relocation for Seamless Header
Transfers Between Nodes in an IP Access Network", RFC 3374, Internet Compression in IP Networks", Internet Draft, Internet
Engineering Task Force, RFC 3374, May 2001. Engineering Task Force, Work in Progress.
S. Kent, R. Atkinson, "Security Architecture for the Internet [RFC3374] 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.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
J. Manner, M. Kojo, "Mobility Related Terminology", Internet [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
Appendix A. Simplified Example Context Type Specification Appendix A. Timing and Trigger Considerations
This diagram illustrates the method for specifying context type data
to be associated with a particular context type for Header
Compression.
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 Basic Mobile IP handover signaling can introduce disruptions to the
services running on top of Mobile IP, which may introduce unwanted services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for certain types of services. latencies that practically prohibit its use for certain types of ser-
Mobile IP latency and packet loss is being optimized through several vices. Mobile IP latency and packet loss is being optimized through
alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency several alternative procedures, such as Fast Mobile IP [FMIPv6] and
Mobile IP [LLMIP]. Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute Feature re-establishment through context transfer should contribute
zero (optimally) or minimal extra disruption of services in conjunction zero (optimally) or minimal extra disruption of services in conjunc-
to handovers. This means that the timing of context transfer SHOULD tion to handovers. This means that the timing of context transfer
be carefully aligned with basic Mobile IP handover events, and with SHOULD be carefully aligned with basic Mobile IP handover events, and
optimized Mobile IP handover signaling mechanisms, as those protocols with optimized Mobile IP handover signaling mechanisms, as those pro-
become available. tocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms Furthermore, some of those optimized mobile IP handover mechanisms
(such as BETH) may provide more flexibility is choosing the timing (such as BETH) may provide more flexibility is choosing the timing
and order for transfer of various context information. and order for transfer of various context information.
Appendix C. Congestion Control Appendix B. Congestion Control
Context transfer enables smooth handovers and prevents the need of Context transfer enables smooth handovers and prevents the need of
re-initializing signaling to and from a mobile node after handover. re-initializing signaling to and from a mobile node after handover.
Context transfer takes place between access routers. Context transfer takes place 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 con-
control window when packet loss occurs, thus effectively restricting trol window when packet loss occurs, thus effectively restricting the
the available in-flight window for packet sending. Additionally, available in-flight window for packet sending. Additionally, TCP &
TCP & SCTP deploy slow-start mechanisms at start-up, in order to SCTP deploy slow-start mechanisms at start-up, in order to prevent
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 from the mobile node may be increased if the context transfer of time
time critical data fails. critical data fails.
Therefore, some analysis is needed on the role of congestion control and Therefore, some analysis is needed on the role of congestion control
context transfer. Important considerations should be network-provisioning, and context transfer. Important considerations should be network-
intra-domain vs. inter-domain signaling as well as other considerations. provisioning, intra-domain vs. inter-domain signaling as well as
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 no more than 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 larger some context transfer solutions. Contexts that are significantly
are assumed not so time critical. For a larger number of users, say one larger are assumed not so time critical. For a larger number of
thousand users requesting a smooth handover all in the same second, the users, say one thousand users requesting a smooth handover all in the
total bandwidth needed is still a small fraction of a typical Ethernet same second, the total bandwidth needed is still a small fraction of
or frame relay or ATM link between access routers. So even bursty a typical Ethernet or frame relay or ATM link between access routers.
traffic is unlikely to introduce local congestion. So even bursty traffic is unlikely to introduce local congestion.
Furthermore, physically adjacent access routers should be within Furthermore, physically adjacent access routers should be within one
one or two IP hops of each other, so the effects of context transfer or two IP hops of each other, so the effects of context transfer
should be localized. If transferring real-time contexts triggers should be localized. If transferring real-time contexts triggers
congestive errors, the access network may be seriously under-provisioned. congestive errors, the access network may be seriously under-
provisioned.
In order to handle multiple contexts to be transferred with differing In order to handle multiple contexts to be transferred with differing
reliability needs, each context has to be considered separately by the reliability needs, each context has to be considered separately by
sending access router nAR. If a CTD message is retransmitted because the sending access router nAR. If a CTD message is retransmitted
the CTDR message was not received in time, then those contexts that are because the CTDR message was not received in time, then those con-
"too late" are included anyway as part of the retransmitted CTD data, texts that are "too late" are included anyway as part of the
in order to ease the ability to verify the Mobile Authorization Token. retransmitted CTD data, in order to ease the ability to verify the
Mobile Authorization Token.
Appendix D. Zone of Operation
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.
Author's Addresses Authors' Addresses
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Rajeev.koodli@nokia.com Rajeev.koodli@nokia.com
John Loughney John Loughney
Nokia Nokia
Itdmerenkatu 11-13 Itmerenkatu 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
skipping to change at line 893 skipping to change at page 19, line 30
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 Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to per-
pertain to the implementation or use of the technology described in tain to the implementation or use of the technology described in this
this document or the extent to which any license under such rights document or the extent to which any license under such rights might
might or might not be available; neither does it represent that it or might not be available; neither does it represent that it has made
has made any effort to identify any such rights. Information on the any effort to identify any such rights. Information on the IETF's
IETF's procedures with respect to rights in standards-track and procedures with respect to rights in standards-track and standards-
standards-related documentation can be found in BCP-11. Copies of related documentation can be found in BCP-11. Copies of claims of
claims of rights made available for publication and any assurances of rights made available for publication and any assurances of licenses
licenses to be made available, or the result of an attempt made to to be made available, or the result of an attempt made to obtain a
obtain a general license or permission for the use of such general license or permission for the use of such proprietary rights
proprietary rights by implementers or users of this specification can by implementers or users of this specification can be obtained from
be obtained from the IETF Secretariat. the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
 End of changes. 

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