draft-ietf-seamoby-ctp-01.txt   draft-ietf-seamoby-ctp-02.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: Standards Track C. Perkins
<draft-ietf-seamoby-ctp-01.txt> R. Koodli draft-ietf-seamoby-ctp-02.txt R. Koodli
Expires: September 2003 March 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 [1]. 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
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
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."
skipping to change at page 2, line 9 skipping to change at line 47
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 1. Introduction
1.1 Conventions Used in This Document 1.1 Conventions Used in This Document
1.2 Abbreviation Used in the Document 1.2 Abbreviations Used in the Document
2. Protocol Overview 2. Protocol Overview
2.1 Context Transfer Packet Format 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 Considerations 3. Transport, Reliability and Retransmission of Feature Data
3.1 Congestion Control
3.2 Transport Protocols
4. Open Issues 4. Open Issues
4.1 Reliability 4.1 Failure Handling ti -5 5. Examples and Signaling Flows
4.2 Transport
4.3 Failure Handling
4.4 Zone of Operation
5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 5.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 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. Simplified Example Context Type Specification
Appendix B. Timing and Trigger Considerations Appendix B. Timing and Trigger Considerations
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" [3374] defines the following between Nodes in an IP Access Network" [RFC3374] defines the
main reasons why Context Transfer procedures may be useful in IP following main reasons why Context Transfer procedures may be useful
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.
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 the link connecting a mobile node and the access router is bandwidth-
bandwidth-constrained, the access router may maintain header constrained, the access router may maintain header compression state
compression state on behalf of the mobile node. When such a node on behalf of the mobile node. When such a node moves to a different
moves to a different access router, this state or context relocation access router, this state or context relocation during handover
during handover provides many important benefits, including: 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 from scratch 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 [RFC3374], 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 [RFC2119].
1.2 Abbreviation Used in the Document 1.2 Abbreviations Used in the Document
AR Access Router AR Access Router
CT Context Transfer CT Context Transfer
CTP Context Transfer Protocol CTP Context Transfer Protocol
DoS Denial-of-Service DoS Denial-of-Service
FPT Feature Profile Types FPT Feature Profile Types
skipping to change at page 4, line 44 skipping to change at line 160
SA Security Association 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 can send the CT start request to old or new AR. * The mobile node sends the CT Activate Request to old AR whenever
The former is preferred whenever possible. Sending the request to possible to initiate predictive context transfer. In any case, the
nAR would add extra latency since the new AR, itself, after MN always sends the CTAR message to new AR. If the contexts are
processing the MN's request will need to request context already present, nAR would verify the authorization token present
transmission from pAR. in CTAR with its own computation (using the parameters supplied by
pAR), and subsequently activate those contexts. If the contexts
are not present, nAR requests pAR to supply them using the Context
Transfer Request message, in which it supplies the authorization
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 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 The Context Transfer protocol typically operates between a source
node and a target node. In the future, there may be multiple target node and a target node. In the future, there may be multiple target
nodes involved; the protocol described here would work with multiple nodes involved; the protocol described here would work with multiple
target nodes. For simplicity, we describe the protocol assuming a target nodes. For simplicity, we describe the protocol assuming a
single receiver or target node. 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). We assume that pAR
and nAR share an appropriate security association, set up and nAR share an appropriate security association, set up
independently and prior to context transfer. Any appropriate independently and prior to context transfer. Any appropriate
mechanism may be used in setting up this security association; it mechanism may be used in setting up this security association; it
enables the CT peers to utilize a secure channel for transferring enables the CT peers to utilize a secure channel for transferring
contexts, providing authentication, integrity, and (if needed) contexts, providing authentication, integrity, and (if needed)
confidentiality. confidentiality.
Context Transfer takes place when an event, such as a handover, takes Context Transfer takes place when an event, such as a handover, takes
place. We call such an event as a Context Transfer Trigger. In place. We call such an event as a Context Transfer Trigger. In
response to such a trigger, the pAR may transfer the contexts; the 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 nAR may request contexts; and the MN may send a message to the
transfer contexts. Such a trigger must be capable of providing the routers to transfer contexts. Such a trigger must be capable of
necessary information, such as the MN's IP address with which the providing the necessary information, such as the MN's IP address with
contexts are associated, the IP addresses of the access routers, and which the contexts are associated, the IP addresses of the access
authorization to transfer context. routers, and authorization to transfer context.
Context transfer protocol messages use Context Types that identify Context transfer protocol messages use Feature Profile Types that
the way that data is organized for the particular feature contexts. identify the way that data is organized for the particular feature
The Context Types (CPTs) are registered in a number space (with IANA contexts. The Feature Profile Types (FPTs) are registered in a number
Type Numbers) that allows a node to unambiguously determine the type space (with IANA Type Numbers) that allows a node to unambiguously
of context and the context parameters present in the protocol determine the type of context and the context parameters present in
messages. Contexts are transferred by laying out the appropriate the protocol messages. Contexts are transferred by laying out the
feature data within Context Data Blocks according to the format in appropriate feature data within Context Data Blocks according to the
section 2.3, as well as any IP addresses necessary to associate the format in section 2.3, as well as any IP addresses necessary to
contexts to a particular MN. The context transfer initiation associate the contexts to a particular MN. The context transfer
messages contain parameters that identify the source and target initiation messages contain parameters that identify the source and
nodes, the desired list of feature contexts and IP addresses to target nodes, the desired list of feature contexts and IP addresses
identify the contexts. The messages that actually transfer context to identify the contexts. The messages that request transfer of
data also contain an appropriate token to authorize the context context data also contain an appropriate token to authorize the
transfer. context transfer.
The Previous Access Router transfers feature contexts under two The Previous Access Router transfers feature contexts under two
general scenarios. First, it may receive a Context Transfer Start general scenarios. First, it may receive a Context Transfer Activate
Request (CTSR) message from the MN whose feature contexts are to be Request (CTAR) message from the MN whose feature contexts are to be
transferred, or it receives an internally generated trigger (e.g., a transferred, or it receives an internally generated trigger (e.g., a
link-layer trigger on the interface to which the MN is connected). link-layer trigger on the interface to which the MN is connected).
The CTAR message, described in Section 2.4.1, provides the IP address
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
of NAR, the IP address of MN on PAR, the list of feature contexts to
be transferred (by default requesting all contexts to be be transferred (by default requesting all contexts to be
transferred), and a token authorizing the transfer. It also includes transferred), and a token authorizing the transfer. It also includes
the MN's new IP address (valid on NAR) whenever it is known. In 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 response to a CT-Activate Request message or to the CT trigger, pAR
predictively transmits a Context Transfer Data (CTD) message that predictively transmits a Context Transfer Data (CTD) message that
contains feature contexts. This message, described in Section 2.4.2, contains feature contexts. This message, described in Section 2.4.2,
contains the MN's previous IP address and its new IP address contains the MN's previous IP address and its new IP address (if
(whenever known). It also includes a key, and an indication to use a known). It also contains parameters for nAR to compute an
particular algorithm to assist NAR in computing a token that it could authorization token to verify the MN's token present in CTAR message.
use to check authorization prior to making the contexts available to Recall that the MN always sends CTAR message to nAR regardless of
the MN. whether it sent the CTAR message to pAR. The reason for this is that
there is no means for the MN to ascertain that context transfer
reliably took place. By always sending the CTAR message to nAR, the
Context Transfer Request (see below) can be sent to pAR whenever
necessary.
In the second scenario, pAR receives a Context Transfer Request (CT In the second scenario, pAR receives a Context Transfer Request (CT
Request) described in Section 2.4.5, message from nAR. The nAR Request) described in Section 2.4.5, message from nAR. The nAR
itself generates the CT Request message either as a result of itself generates the CT Request message either as a result of
receiving the CTSR 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 (typically generated by the MN) authorizing transferred, and a token (generated by the MN) authorizing context
context transfer. In response to CT Request message, pAR transmits a transfer. In response to CT Request message, pAR transmits a Context
Context Transfer Data (CTD) message that includes the MN's previous Transfer Data (CTD) message that includes the MN's previous IP
IP address and feature contexts. When it receives a corresponding address and feature contexts. When it receives a corresponding CTD
CTD message, nAR may generate a CTD Reply message (See Section 2.4.3) message, nAR may generate a CTD Reply message (See Section 2.4.3) to
to report the status of processing the received contexts. In this report the status of processing the received contexts.
"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 When context transfer takes place without the nAR requesting it
(scenario one above), nAR should require MN to present its (scenario one above), nAR should require MN to present its
authorization token. Doing this locally at nAR when the MN attaches authorization token. Doing this locally at nAR when the MN attaches
to it improves performance, since the contexts highly likely to be to it improves performance, since the contexts are highly likely to
present already. When context transfer happens with an explicit be present already. When context transfer happens with an explicit
request from NAR (scenario two above), pAR performs such verification request from nAR (scenario two above), pAR performs such verification
since the contexts are still present at pAR. In either case, token since the contexts are still present at pAR. In either case, token
verification takes place at the node possessing the contexts. 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
clearly has potential for better performance. For this to take clearly has potential for better performance. For this to take
place, certain conditions must be met. For example, PAR must have place, certain conditions must be met. For example, pAR must have
sufficient time and knowledge about the impending handover. This is sufficient time and knowledge about the impending handover. This is
feasible for instance in Mobile IP fast handovers. However, when the feasible for instance in Mobile IP fast handovers. However, when the
advance knowledge of impending handover is not available, or if a advance knowledge of impending handover is not available, or if a
mechanism such as fast handover fails, retrieving feature contexts mechanism such as fast handover fails, retrieving feature contexts
after the MN attaches to NAR is the only available means for context after the MN attaches to nAR is the only available means for context
transfer. Performing context transfer after handover might still be transfer. Performing context transfer after handover might still be
better than having to re-establish all the contexts from scratch. better than having to re-establish all the contexts from scratch.
Finally, some contexts may simply need to be transferred during Finally, some contexts may simply need to be transferred during
handover signaling. For instance, any context that gets updated on a handover signaling. For instance, any context that gets updated on a
per-packet basis must clearly be transferred only after packet per-packet basis must clearly be transferred only after packet
forwarding to the MN on its previous link is terminated. Transfer of forwarding to the MN on its previous link is terminated. Transfer of
such contexts must be properly synchronized with appropriate handover such contexts must be properly synchronized with appropriate handover
messages, such as Mobile IP (Fast) Binding Update. messages, such as Mobile IP (Fast) Binding Update.
The messages (CTD and CTDR) which perform the context transfer
between the access routers need to be authenticated, so that the
access routers can be certain that the data has not been tampered
with during delivery. This is especially true since there is no
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.
+----------------------+ +----------------------+
| CTP Header | | CTP Header |
skipping to change at page 8, line 8 skipping to change at line 329
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/RDP Appendix A contains an example context type specification for UDP/RTP
header compression context. 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) |
skipping to change at page 8, line 47 skipping to change at line 368
In this section, a list of the available context transfer message In this section, a list of the available context transfer message
types is given, along with a brief description of their functions. types is given, along with a brief description of their functions.
Generally, messages use the following generic message header format: Generally, messages use the following generic message header format:
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 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 care-of address. At undertaken, is always identified by its previous IP access address.
any one time, only one context transfer operation may be in progress At any one time, only one context transfer operation may be in
so that the CTDR message unambigously identifies which CTD message is progress so that the CTDR message unambigously identifies which CTD
acknowledged simply by including the mobile node's identifying message is acknowledged simply by including the mobile node's
previous care-of address. identifying previous IP address.
2.4.1 Context Transfer Start Request (CTSR) Message 2.4.1 Context Transfer Activate Request (CTAR) Message
Sent by MN to nAR to request start of context transfer. It is for Always sent by MN to nAR to request context transfer activation. It
further to study to see if when the CTSR message is sent by the MN to is for further to study to see if when the CTAR message is sent by
the nAR, it should also be relayed to pAR. Acknowledgement is the MN to the nAR, it should also be relayed to pAR. Acknowledgement
optional, since the MN may have already moved and may not receive the is optional, since the MN may have already moved and may not receive
reply. This message may include a list of FPT (feature profile types) the reply. This message may include a list of FPT (feature profile
that require transfer. It may include flags to request secure and/or types) that require transfer. It may include flags to request secure
reliable transfer. 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 new pAR. In such a case, the MN includes the nAR's IP address and its
IP address (if known). new 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 |reserve| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Router IP Address | | Previous Router IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Type (if present) | | Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Type (if present) | | Next Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CTSR is the Mobile Node's Previous Care-of The message data for CTAR is the Mobile Node's Previous IP Address,
Address, Previous Router's IP address, MN Authorization Token, Previous Router's IP address, MN Authorization Token, followed by a
followed by a list of context types. If no context types are list of context types. If no context types are specified, then all
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 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. required by nAR. This message 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|R|rsv| Length | | Message Type |C|R|rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's New Care-of Address, if C=1 | | Mobile Node's New Care-of Address, if C=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Auth | Type Length | Algorithm | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Context Block | | First Context Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Context Block | | Next Context Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MN Authorization Token is computed over the binary data The Authorization token type field is present in the predictive
represented in the Context Data BLocks of the CTD message. The scenario only. The supplied parameters, algorithm, key length and the
binary data is laid out as the fully specified ordered sequence of key itself, allow nAR to compute a token locally depending on the
data fields according to the defining context specification, as if contents of the CTAR message.
there were no presence vector and therefore no implicitly supplied
default values. Since the mobile node is expected to know the The algorithm for carrying out the computation of the MN
precise contents of the context data to be transferred, and the pAR Authorization Token is HMAC_SHA1. The input data for computing the
is expected to know the security parameters and algorithm used by the token are: the MN's Previous IP address, the FPT objects and the
mobile node to compute the authorization token, the token can be Replay field. When support for transferring all contexts is
supplied by pAR on behalf of the mobile node. requested, a default FPT is used. The Authorization Token is
obtained by truncating the results of the HMAC_SHA1 computation to
retain only the leading 32 bits.
2.4.3 Context Transfer Data Reply (CTDR) Message 2.4.3 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. reliability flag in CTD. Indicates success or failure. This message
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 | ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 28 skipping to change at line 505
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.5 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 CTSR 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Type (if present) | | Requested Context Type (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next 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 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. Address, MN Authorization Token, followed by a list of context types.
If no context types are specified, then all contexts for the mobile If no context types are specified, then all contexts for the mobile
node are requested. The MN Authorization Token is computed by laying node are requested. The fields including and following the
out all the context data according to the specifications given within Authorization Token Type are inserted from the CTAR message.
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
transport protocol. In this section we outline the issues of running
CTP over well-known protocols.
ICMP and UDP do not provide congestion control, while TCP/SCTP do
provide congestion control. The connection setup for those
congestion control transport protocols may introduce delays in start
of data transfer, but do protect the network from becoming
overloaded. This trade off needs to be further studied in terms of
applicability of context transfer. Since the data to be handled by
the context transfer protocol is typically transmitted locally only,
between access routers, the danger for congestion in the network at
large is substantially reduced or eliminated. Some issues affecting
this will be the type of signaling - for example, intra-domain vs.
inter-domain.
Of the existing transport mechanisms, both TCP and SCTP provide
checksums. UDP provides only an optional checksum. In order to
enable use of multiplexing functionality of context transfer
protocol, the UDP checksum MAY be de-activated to provide flexibility
in inserting checksums within context information as needed. This
will decrease the likelihood that the entire context data packet is
dropped due to individual feature data corruptions.
3.1 Congestion Control
Context transfer enables smooth handovers and prevents the need of
re-initializing signaling to and from a mobile node after handover.
Context transfer takes place between access routers.
The goal of congestion control is to prevent congestion by noting
packet loss at the transport layer and reducing the congestion
control window when packet loss occurs, thus effectively restricting
the available in-flight window for packet sending. Additionally, TCP
& SCTP deploy slow-start mechanisms at start-up, in order to prevent
congestion problems at the start of a new TCP/SCTP session.
As some context is time-critical, delays due to congestion control
may reduce the performance of mobile nodes; additionally, signaling
from the mobile node may be increased if the context transfer of time
critical data fails.
Therefore, some analysis is needed on the role of congestion control
and context transfer. Important considerations should be network-
provisioning, intra-domain vs. inter-domain signaling as well as
other considerations. A quick analysis follows.
It is assumed that intra-domain time-critical context transfer should
take no more than one kilobyte, based on existing implementation of
some context transfer solutions. Contexts that are significantly
larger are assumed not so time critical. For a larger number of
users, say one thousand users requesting a smooth handover all in the
same second, the total bandwidth needed is still a small fraction of
a typical Ethernet or frame relay or ATM link between access routers.
So even bursty traffic is unlikely to introduce local congestion.
Furthermore, physically adjacent access routers should be within one
or two IP hops of each other, so the effects of context transfer
should be localized. If transferring real-time contexts triggers
congestive errors, the access network may be seriously under-
provisioned.
In order to handle multiple contexts to be transferred with differing
reliability needs, each context has to be considered separately by
the sending access router nAR. If a CTD message is retransmitted
because the CTDR message was not received in time, then those
contexts that are "too late" should not be included as part of the
retransmitted CTD data.
3.2 Transport Protocols
3.2.1 ICMP
Pros
* No explicit connection setup needed.
* Reliability handled at the upper layer.
* Co-ordination with mobility solutions easier to implement.
Cons
* No transport level signaling
* No reliability
* No ability to fragment data.
* Upper Size limits on packets.
* ICMP messages have low priority in case of congestion
3.2.2 UDP
Pros
* No explicit connection setup needed.
* Reliability handled at the upper layer.
* Co-ordination with mobility solutions easier to implement.
Cons
* No transport level signaling
* No reliability
* No ability to fragment data.
3.2.3 TCP
Pros
* Supports TLS
* Built in reliability
Cons
* 3-way handshake, mitigated if TCP connections are re-used.
Open issues The algorithm for carrying out the computation is HMAC_SHA1. The
* Single TCP connection or multiple TCP connections? Per transfer Authorization token is obtained by truncating the results of the
or per neighbor? HMAC_SHA1 computation to retain only the leading 32 bits. The input
data for computing the token are: the MN's Previous IP address, the
FPT objects and the Replay field. When support for transferring all
contexts is requested, a default FPT is used.
3.3.4 SCTP 3. Transport, Reliability and Retransmission of Feature Data
Pros CTP runs over UDP using port number <TBD>. Some feature contexts may
* Supports TLS specify a reliability factor, MAX_RETRY_INTERVAL, which is the length
* Built in reliability of time that the pAR is allowed to perform retransmissions before
* Message-oriented giving up on the context transfer for that feature context. The
* Multiple streams prevent head-of-line blocking for multiple users. longer the allowed retry interval, the more retransmissions will be
possible for that feature context. It is expected that
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.
Cons For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD
* 3-way handshake, mitigated if STCP connections are re-used. retransmit an unacknowledged CTD message after waiting for
RETRANSMISSION_DELAY milliseconds. This time value is configurable
based on the type of network interface; slower network media
naturally will be configured with longer values for the
RETRANSMISSION_DELAY. Except for the value of the elapsed time
field, the payload of each retransmitted CTD packet is identical to
the payload of the initially transmitted CTD packet, in order to
maintain the ability of the mobile device to present a correctly
calculated authentication token. The number of retransmissions, each
delayed by RETRANSMISSION_DELAY, depends on the maximum value for
MAX_RETRY_INTERVAL as specified by any of the contexts. The value
of the Elapsed Time field is the number of milliseconds since the
transmission of the first CTD message
Open issues UDP provides a optional checksum, which SHOULD be checked. If the
* Partial Reliability SCTP may be interesting, as it allows checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with
selective retransmission. the status value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in
the CTD.
4. 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.
4.1 Reliability 4.1 Failure Handling
Should reliability be handled at the transport layer? Should the
reliability needs of contexts be handled at the CTP data level or CTP
message level?
4.2 Transport
Currently, the issue of which transport protocol should be supported
is open.
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. The details about how failure can be reported for may be needed. The details about how failure can be reported for
some individual contexts but not requiring retransmission of all some individual contexts but not requiring retransmission of all
contexts should be straightforward but remain to be worked out. contexts should be straightforward but remain to be worked out.
4.4 Zone of Operation
Currently, the authors are restricting discussion of CTP to intra-
domain signaling. Discussion of inter-domain signaling left for
later discussions.
Inter-domain signaling places additional requirements on establishing
security relationships that may not be relevant for intra-domain.
Besides, physically adjacent routers may be more than several IP hops
away. Additionally, provisioning inter-domain signaling links may be
much more complicated.
Restricting CTP to intra-domain signaling simplifies security,
transport and provision concerns. Additionally, a restriction to
intra-domain signaling may help to ensure CT completes in sufficient
time to meet time sensitive requirements.
5. Examples and Signaling Flows 5. 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 | | | E |--------CTAR--------->| |
: | | | : | | |
| | |-------- CTDR -------->| | | |-------- CTDR -------->|
V | | | V | | |
| | | | | |
5.2 Network controlled, initiated by nAR 5.2 Network controlled, initiated by nAR
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 | |----- CTDR (opt) ----->| V |--------CTAR--------->| |
| |----- CTDR (opt) ----->|
| | | | | |
Is a new message CT request needed?
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3 Mobile controlled, Predictive New L2 up/old L2 down
CTSR request to nAR (nAR must be able to authenticate MN for CT, CTAR request to nAR (nAR must be able to authenticate MN for CT,
security details later) security details later)
MN nAR pAR MN nAR pAR
| | | | | |
new L2 link up | | new L2 link up | |
| | | | | |
CT trigger | | CT trigger | |
| | | | | |
T |--------CTSR ------->| | T |--------CTAR ------->| |
I | |---- CT request ------>| I | |---- CT Request ------>|
M | | | M | | |
E | |<-------- CTD ---------| E | |<-------- CTD ---------|
: | | | : | | |
| | | | | | | |
V | | | V | | |
| | | | | |
Is a new message CT request needed? In case CT cannot be supported, a CTAR reject (TBD) may be sent to
the MN by nAR.
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 5.4 Mobile controlled, Reactive CT New L2 up/old L2 down
CTSR request to pAR through nAR (the pAR needs to authenticate the CTAR relay to pAR through nAR (the pAR needs to authenticate the
CTSR) CTAR)
MN nAR pAR MN nAR pAR
| | | | | |
new L2 link up | | new L2 link up | |
| | | | | |
CT trigger | | CT trigger | |
| | | | | |
T |------- CTSR -------->|===== CTSR relay =====>| T |------- CTAR -------->|===== CTAR relay =====>|
I | | | I | | |
M | |<------- CTD --------- | M | |<------- CTD --------- |
E | | | E | | |
: | | | : | | |
| | | | | | | |
V | | | V | | |
| | | | | |
The CTSR relay is the CTSR message that is destined to pAR and is
The CTAR relay is the CTAR message that is destined to pAR and is
routed through nAR (routing details later). In case CT cannot be routed through nAR (routing details later). In case CT cannot be
supported, a CTSR reject maybe sent to the MN through nAR. supported, a CTAR reject maybe sent to the MN through nAR.
6. Security Considerations 6. Security Considerations
The Context Transfer Protocol essentially transfers state between The Context Transfer Protocol transfers state between access routers.
access routers. If the mobile nodes are not authenticated and If the mobile nodes are not authenticated and authorized before
authorized before moving on the network, there is a potential for moving on the network, there is a potential for DoS-style attacks to
DoS-style attacks to shift state between ARs, causing network shift state between ARs, causing network disruptions.
disruptions.
In general, CTP relies on IETF standardized security mechanisms for
protecting traffic between access routers, as opposed to creating
application security mechanisms. Both IPsec and TLS [TLS] may be
reasonable mechanisms for securing the context transfer between
access routers.
In order to avoid the introduction of additional latency to context 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
need to engage in a key exchange mechanisms such as IKE [IKE], access routers need to engage in a key exchange mechanisms such as
establish IPSec SAs, defining the keys, algorithms and IPSec IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and
protocols (such as ESP) in anticipation for any upcoming context IPSec protocols (such as ESP) in anticipation for any upcoming
transfer. This will save time during handovers that require secure context transfer. This will save time during handovers that require
transfer of mobile node's context(s). Such SAs can be maintained and secure transfer of mobile node's context(s). Such SAs can be
used for all upcoming context transfers between the two ARs. maintained and used for all upcoming context transfers between the
Security should be negotiated prior to the sending of context. two ARs. Security should be negotiated prior to the sending of
context.
Furthermore, either one or both of the pAR and nAR need to be able 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 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.
7. IANA Considerations 7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
context transfer protocol, in accordance with BCP 26 [RFC2434].
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
skipping to change at page 18, line 32 skipping to change at line 724
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 creating of this specification.
9. References 9. References
9.1 Normative References 9.1 Normative References
[2026] S. Bradner, "The Internet Standards Process -- Revision 3", S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9,
BCP 9, RFC 2026, October 1996. RFC 2026, October 1996.
[2119] S. Bradner, "Key words for use in RFCs to Indicate Require- S. Bradner, "Key words for use in RFCs to Indicate Requirement
ment Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[CT-REQ] G. Kenward et al., "General Requirements for Context S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, November
Transfer", Internet Draft, Internet Engineering Task Force, 1998
Work in Progress.
[CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for G. Kenward et al., "General Requirements for Context Transfer",
Seamless Mobility", Internet Draft, Internet Engineering Internet Draft, Internet Engineering Task Force, Work in Progress.
Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet R. Koodli, C.E. Perkins, "Context Transfer Framework for Seamless
Engineering Task Force. Work in Progress. Mobility", Internet Draft, Internet Engineering Task Force, Work in
Progress.
[IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Con- R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
siderations Section in RFCs", BCP 26, RFC 2434, October Engineering Task Force. Work in Progress.
1998.
[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an IANA
RFC 2409, November 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409,
Internet Engineering Task Force. Work in Progress. November 1998.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", Internet
2246, January 1999. Engineering Task Force. Work in Progress.
9.2 Non-Normative References 9.2 Non-Normative References
[3374] J. Kempf et al., "Problem Description: Reasons For Performing J. Kempf et al., "Problem Description: Reasons For Performing Context
Context Transfers Between Nodes in an IP Access Network", RFC Transfers Between Nodes in an IP Access Network", RFC 3374, Internet
3374, Internet Engineering Task Force, RFC 3374, May 2001. Engineering Task Force, RFC 3374, May 2001.
[2401] S. Kent, R. Atkinson, "Security Architecture for the Internet S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet 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,
January 1999.
Appendix A. Simplified Example Context Type Specification Appendix A. Simplified Example Context Type Specification
This diagram illustrates the method for specifying context type data This diagram illustrates the method for specifying context type data
to be associated with a particular context type for Header Compres- to be associated with a particular context type for Header
sion. Compression.
TBA
Context Type: Header Compression Context Type: Header Compression
Data fields: Data fields:
IP header fields IP header fields
Current IP Source Address 32bits Change recipe Current IP Source Address 32bits Change recipe
Current IP Destination Address 32bits Change recipe Current IP Destination Address 32bits Change recipe
UDP header fields UDP header fields
RTP header fields RTP header fields
Appendix B. Timing and Trigger Considerations Appendix B. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the services Basic Mobile IP handover signaling can introduce disruptions to the
running on top of Mobile IP, which may introduce unwanted latencies that services running on top of Mobile IP, which may introduce unwanted
practically prohibit its use for certain types of services. Mobile IP latency latencies that practically prohibit its use for certain types of services.
and packet loss is being optimized through several alternative procedures, Mobile IP latency and packet loss is being optimized through several
such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP]. alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency
Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute zero Feature re-establishment through context transfer should contribute
(optimally) or minimal extra disruption of services in conjunction to zero (optimally) or minimal extra disruption of services in conjunction
handovers. This means that the timing of context transfer SHOULD be carefully to handovers. This means that the timing of context transfer SHOULD
aligned with basic Mobile IP handover events, and with optimized Mobile IP be carefully aligned with basic Mobile IP handover events, and with
handover signaling mechanisms, as those protocols become available. optimized Mobile IP handover signaling mechanisms, as those protocols
become available.
Furthermore, some of those optimized mobile IP handover mechanisms (such as Furthermore, some of those optimized mobile IP handover mechanisms
BETH) may provide more flexibility is choosing the timing and order for (such as BETH) may provide more flexibility is choosing the timing
transfer of various context information. and order for transfer of various context information.
Appendix C. Congestion Control
Context transfer enables smooth handovers and prevents the need of
re-initializing signaling to and from a mobile node after handover.
Context transfer takes place between access routers.
The goal of congestion control is to prevent congestion by noting
packet loss at the transport layer and reducing the congestion
control window when packet loss occurs, thus effectively restricting
the available in-flight window for packet sending. Additionally,
TCP & SCTP deploy slow-start mechanisms at start-up, in order to
prevent congestion problems at the start of a new TCP/SCTP session.
As some context is time-critical, delays due to congestion control
may reduce the performance of mobile nodes; additionally, signaling
from the mobile node may be increased if the context transfer of
time critical data fails.
Therefore, some analysis is needed on the role of congestion control and
context transfer. Important considerations should be network-provisioning,
intra-domain vs. inter-domain signaling as well as other considerations.
A quick analysis follows.
It is assumed that intra-domain time-critical context transfer should
take no more than one kilobyte, based on existing implementation of
some context transfer solutions. Contexts that are significantly larger
are assumed not so time critical. For a larger number of users, say one
thousand users requesting a smooth handover all in the same second, the
total bandwidth needed is still a small fraction of a typical Ethernet
or frame relay or ATM link between access routers. So even bursty
traffic is unlikely to introduce local congestion.
Furthermore, physically adjacent access routers should be within
one or two IP hops of each other, so the effects of context transfer
should be localized. If transferring real-time contexts triggers
congestive errors, the access network may be seriously under-provisioned.
In order to handle multiple contexts to be transferred with differing
reliability needs, each context has to be considered separately by the
sending access router nAR. If a CTD message is retransmitted because
the CTDR message was not received in time, then those contexts that are
"too late" are included anyway as part of the 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 Author's 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
skipping to change at page 20, line 42 skipping to change at line 893
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 per- intellectual property or other rights that might be claimed to
tain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might this document or the extent to which any license under such rights
or might not be available; neither does it represent that it has made might or might not be available; neither does it represent that it
any effort to identify any such rights. Information on the IETF's has made any effort to identify any such rights. Information on the
procedures with respect to rights in standards-track and standards- IETF's procedures with respect to rights in standards-track and
related documentation can be found in BCP-11. Copies of claims of standards-related documentation can be found in BCP-11. Copies of
rights made available for publication and any assurances of licenses claims of rights made available for publication and any assurances of
to be made available, or the result of an attempt made to obtain a licenses to be made available, or the result of an attempt made to
general license or permission for the use of such proprietary rights obtain a general license or permission for the use of such
by implementers or users of this specification can be obtained from proprietary rights by implementers or users of this specification can
the IETF Secretariat. be obtained from 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/