draft-ietf-seamoby-ctp-03.txt   draft-ietf-seamoby-ctp-04.txt 
Seamoby WG J. Loughney (editor) Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri Internet Draft M. Nakhjiri
Category: Experimental C. Perkins Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-03.txt> R. Koodli <draft-ietf-seamoby-ctp-04.txt> R. Koodli
Expires: December 2003 June 2003 Expires: April 7, 2004 September 8, 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
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 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
mobile nodes to authorize context transfers between access routers. authorized context transfers. Context transfers allow better support
Context transfers allow better support for node based mobility so for node based mobility so that the applications running on mobile
that the applications running on mobile nodes can operate with nodes can operate with minimal disruption. Key objectives are to
minimal disruption. Key objectives are to reduce latency, packet reduce latency, packet losses and avoiding re-initiation of signaling
losses and avoiding re-initiation of signaling to and from the mobile to and from the mobile node.
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
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
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. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Appendix B. Congestion Control Appendix B. Congestion Control
Appendix C. Multicast Listener Context Transfer
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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
This document describes a generic context transfer protocol, which This document describes a generic context transfer protocol, which
provides: 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. The protocol
supports both IPv4 and IPv6, though support for IPv4 private
addresses is for future study.
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
Mobility Related Terminology [TERM] defines basic mobility Mobility Related Terminology [TERM] defines basic mobility
skipping to change at page 4, line 21 skipping to change at page 4, line 22
* 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 typical lly operates between The Context Transfer protocol typically operates between a source
a source node and a target node. In the future, there may be multiple node and a target node. In the future, there may be multiple target
target nodes involved; the protocol described here would work with nodes involved; the protocol described here would work with multiple
multiple target nodes. For simplicity, we describe the protocol target nodes. For simplicity, we describe the protocol assuming a
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). Context Transfer the target node is MN's New Access Router (nAR). Context Transfer
takes place when an event, such as a handover, takes place. We call takes place when an event, such as a handover, takes place. We call
such an event as a Context Transfer Trigger. In response to such a such an event as a Context Transfer Trigger. In response to such a
trigger, the pAR may transfer the contexts; the nAR may request 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; and the MN may send a message to the routers to transfer
contexts. Such a trigger must be capable of providing the necessary contexts. Such a trigger must be capable of providing the necessary
information, such as the MN's IP address with which the contexts are information, such as the MN's IP address with which the contexts are
associated, the IP addresses of the access routers, and authorization associated, the IP addresses of the access routers, and authorization
skipping to change at page 5, line 44 skipping to change at page 5, line 47
(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 [1].* contexts, pAR verifies authorization token before transmitting
the [2].* in the CTD message. the [2]algorithm [3] When context transfer takes place without the
nAR requesting it (scenario one above), nAR requires MN to present
When context transfer takes place without the nAR requesting it its authorization token. Doing this locally at nAR when the MN
(scenario one above), nAR requires MN to present its authorization attaches to it improves performance and increases security, since the
token. Doing this locally at nAR when the MN attaches to it improves contexts are highly likely to be present already. When context
performance and increases security, since the contexts are highly transfer happens with an explicit request from nAR (scenario two
likely to be present already. When context transfer happens with an above), pAR performs such verification since the contexts are still
explicit request from nAR (scenario two above), pAR performs such present at pAR. In either case, token verification takes place at the
verification since the contexts are still present at pAR. In either 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 can Performing context transfer in advance of the MN attaching to nAR can
increase handover performance. For this to take place, certain increase handover performance. For this to take place, certain
conditions must be met. For example, pAR must have sufficient time conditions must be met. For example, pAR must have sufficient time
and knowledge about the impending handover. This is feasible, for and knowledge about the impending handover. This is feasible, for
instance, in Mobile IP fast handovers. Additionally, many cellular instance, in Mobile IP fast handovers. Additially, many cellular
networks have mechanisms to detect handovers in advance. However, networks have mechanisms to detect handovers in advance. However,
when the advance knowledge of impending handover is not available, or when the advance knowledge of impending handover is not available, or
if a mechanism such as fast handover fails, retrieving feature if a mechanism such as fast handover fails, retrieving feature
contexts after the MN attaches to nAR is the only available means for contexts after the MN attaches to nAR is the only available means for
context transfer. Performing context transfer after handover might context transfer. Performing context transfer after handover might
still be better than having to re-establish all the contexts from still be better than having to re-establish all the contexts from
scratch. Finally, some contexts may simply need to be transferred scratch. Finally, some contexts may simply need to be transferred
during handover signaling. For instance, any context that gets during handover signaling. For instance, any context that gets
updated on a per-packet basis must clearly be transferred only after updated on a per-packet basis must clearly be transferred only after
packet forwarding to the MN on its previous link is terminated. packet forwarding to the MN on its previous link is terminated.
The messages (CTD and CTDR) that perform the context transfer between The messages (CTD and CTDR) that perform the context transfer between
the access routers need to be authenticated, so that the access the access routers need to be authenticated, so that the access
routers can be certain that the data has not been tampered with routers can be certain that the data has not been tampered with
during delivery. during delivery.
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 to ensure a more efficient transfer. The total packet size,
including transport protocol and IP protocol headers SHOULD be less including transport protocol and IP protocol headers SHOULD be less
than the path MTU, in order to avoid packet fragmentation. than the path MTU, in order to avoid packet fragmentation.
+----------------------+ +----------------------+
| CTP Header | | CTP Header |
+----------------------+ +----------------------+
| Message Header | | Message Header |
+----------------------+ +----------------------+
| CTP Data 1 | | CTP Data 1 |
+----------------------+ +----------------------+
| CTP Data 2 | | CTP Data 2 |
+----------------------+ +----------------------+
| ... | | ... |
2.2 Context Types 2.2 Context Types
Contexts are identified by context type of Feature Profile Type
Contexts are identified by context type, which is a 32-bit number. (FPT), which is a 15-bit number. The meaning of each context type is
determined by a specification document and the context type numbers
The meaning of each context type is determined by a specification are to be tabulated in a registry maintained by IANA, and handled
document and the context type numbers are to be tabulated in a according to the message specifications in this document. The
registry maintained by IANA, and handled according to the message instantiation of each context by nAR is determined by the messages in
specifications in this document. The instantiation of each context this document along with the specification associated with the
by nAR is determined by the messages in this document along with the particular context type. Each such context type specification
specification associated with the particular context type. Each such contains the following details:
context type specification contains the following details:
- Number, size (in bits), and ordering of data fields in the - Number, size (in bits), and ordering of data fields in the
state variable vector which embodies the context. state variable vector which embodies the context.
- Default values (if any) for each individual datum of the - Default values (if any) for each individual datum of the
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.
2.3 Context Data Block 2.3 Context Data Block
The Context Data Block is used both for request and response operation.
When a particular feature request is constructed, only the first 4 bytes
are typically necessary (See CTAR below). When used for the actual
feature context itself, the context data is present, and sometimes the
presence vector is present.
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 | | Cxt-Type | Length |P| Feature Profile Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if V = 1) | | Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ context type-dependent data / / context type-dependent data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'V' bit specifies whether or not the "presence vector" is used. The Cxt-Type indicates the type of the feature context message itself
When the presence vector is in use, the next 32 bits are interpreted (such as QoS Context Request, QoS Context Transfer etc.), and Feature
to indicate whether particular data fields are present (and, thus, Profile Type (FPT) identifies the way the particular feature context
containing non-default values). The ordering of the bits in the is organized. The 'P' bit specifies whether or not the "presence
presence vector is the same as the ordering of the data fields vector" is used. When the presence vector is in use, the Presentation
according to the context type specification, one bit per data field Vector is interpreted to indicate whether particular data fields are
regardless of the size of the data field. Notice that the length of present (and, thus, containing non-default values). The ordering of
the context data block is defined by the sum of lengths of each data the bits in the presence vector is the same as the ordering of the
field specified by the context type specification, plus 4 bytes if data fields according to the context type specification, one bit per
the 'V' bit is set, minus the accumulated size of all the context data field regardless of the size of the data field.
data that is implicitly given as a default value.
The Length field indicates the size of the CDB in 8 octets including
the first 4 bytes starting from Cxt-Type.
%Notice that the length of %the context data block is defined by the
sum of lengths of each data %field specified by the context type
specification, plus 4 bytes if the %'P' bit is set, minus the
accumulated size of all the context data %that is implicitly given as
a default value.
2.4 Messages 2.4 Messages
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.
In addition, the CTAR message also contains either the Previous
Router's IP address or the New Router's IP address.
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 | | Msg Type | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP address | | Mobile Node's Previous IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ message data / / Context Data Block (variable size, Section 2.3) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 per MN may be in At any one time, only one context transfer operation per MN may be in
progress so that the CTDR message unambiguously 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.
The 'V' flag indicates whether the MN's previous address is IPv4
only, IPv6 only or both addresses are present. See below.
2.4.1 Context Transfer Activate Request (CTAR) Message 2.4.1 Context Transfer Activate Request (CTAR) Message
This message is always sent by MN to nAR to request context transfer This message is always sent by MN to nAR to request context transfer
activation. It is for further to study to see if when the CTAR activation. Even when the MN does not know whether or not contexts
message is sent by the MN to the nAR. If an acknowledgement is are present, the MN sends CTAR message to gain access with nAR. If an
needed, the MN sets the A flag to 1, other wise the MN does not acknowledgement for this message is needed, the MN sets the A flag to
expect an acknowledgement. This message may include a list of FPT 1, otherwise the MN does not expect an acknowledgement. This message
(feature profile types) that require transfer. It may include flags may include a list of FPT (feature profile types) that require
to request secure and/or reliable transfer. transfer. It may include flags to request 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 new
IP address (if known). IP address (if known) rather than previous IP address and pAR's IP
address.
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 |A| rsv | Length | | Type=CTAR | Length | V |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP Address | | Mobile Node's Previous (New) IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Router IP Address | | Previous (New) 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 Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Type (if present) | | Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CTAR is the Mobile Node's Previous IP Address, Type Context Transfer Activate Request (CTAR).
Previous Router's IP address, MN Authorization Token, followed by a
list of context types. If no context types are specified, then all Length Variable
contexts for the mobile node are requested.
Reserved Reserved for future use. Must be set to zero
by the MN.
'V' flag When set to '00', indicate presence of IPv6
Previous (New) address only.
When set to '01' indicate presence of IPv4
Previous (New) Address only.
When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
'R' bit The MN requests reliable transfer.
Replay A value used to make sure that each use of the
CTAR message is uniquely identifiable.
Authorization Token
An unforgeable value calculated as discussed
below. This authorizes the receiver of CTAR
to perform context transfer.
If no context types are specified, then all contexts for the mobile
node are requested. When 'V' is 10, the IPv4 address MUST preceed the
IPv6 address both for the MN and the access router. Since Context
Types clearly define the context including the IP version, context
enumeration need not be in any strict order, although it might be
natural to outline all the IPv4 contexts followed by IPv6 contexts.
The Authorization Token is calculated as:
First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context
Types))), where Key is the shared secret between the MN and pAR, and
Context Types includes all the desired contexts for which the
transfer is desired. In the default scenario, the MN implicitly
(i.e., even without the knowledge of contexts being present) or
explicitly requests transfer of all contexts.
2.4.2 Context Transfer Activate Acknowledge (CTAA) Message 2.4.2 Context Transfer Activate Acknowledge (CTAA) Message
This is an informative message sent nAR to the MN to acknowledge a This is an informative message sent by the receiver of CTAR to the MN
CTAR message. Acknowledgement is optional, since the MN may have to acknowledge a CTAR message. Acknowledgement is optional, depending
already moved and may not receive the reply. This message may include on whether the MN requested it. This message may include a list of
a list of FPT (feature profile types) that were not transferred FPT (feature profile types) that were not transferred successfully.
successfully.
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 | | Type=CTAA | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Router IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed Context Type (if present) | | Mobile Node's Previous IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Failed Context Type (if present) | | Failed FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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. required by nAR. Note that the new AR must defend the new Care-of-
Address using proxy ARP or Neighbor Discovery.
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 | | Type=(P)CTD | Length | V |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) | | 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, when Type=PCTD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Type=Auth | Type Length | Algorithm | Key Length | | Type=Auth | Type Length | Algorithm | Key Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD
| Key... | Key... | only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
| First Context Block | | First Context Data Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Context Block | | Next Context Data Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authorization token type field is present in the predictive When CTD is sent predictively, the supplied parameters including the
scenario only. The supplied parameters, algorithm, key length and the algorithm, key length and the key itself, allow nAR to compute a
key itself, allow nAR to compute a token locally depending on the token locally and verify against the token present in the CTAR
contents of the CTAR message. message.
The algorithm for carrying out the computation of the MN As described previously, the algorithm for carrying out the
Authorization Token is HMAC_SHA1. The input data for computing the computation of the MN Authorization Token is HMAC_SHA1. The input
token are: the MN's Previous IP address, the FPT objects and the data for computing the token are: the MN's Previous IP address, the
Replay field. When support for transferring all contexts is FPT objects and the Replay field. When support for transferring all
requested, a default FPT is used. The Authorization Token is obtained contexts is requested, a default FPT is used. The Authorization Token
by truncating the results of the HMAC_SHA1 computation to retain only is obtained by truncating the results of the HMAC_SHA1 computation to
the leading 32 bits. retain only the leading 32 bits.
2.4.4 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. reliability flag in CTD. Indicates success or failure.
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 | | Type=CTDR | Length | V |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... | | FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OverallStatus is used for reporting overall success or failure, 'V' flag When set to '00', indicate presence of IPv6
which could be based on verification of the MN authorization token Previous address only.
for instance. For certain values of the overall status, it may be When set to '01' indicate presence of IPv4 Previous
that some contexts were successfully transferred and some failed to Address only.
be transferred. In this case, then for each context another status When set to '10' indicate presence of both IPv6 and
code MUST be provided to indicate to pAR those contexts that have IPv4 Previous addresses.
failed and those that have succeeded, along with the reason.
'S' bit When set to one, this bit indicates that all
the feature contexts sent in CTD or PCTD were
received successfully.
Status Code A context-specific return value, present when 'S'
is not set to one.
2.4.5 Context Transfer Cancel (CTC) Message 2.4.5 Context Transfer Cancel (CTC) Message
If transferring a context cannot be completed in a timely fashion, If transferring a context cannot be completed in a timely fashion,
then nAR may send CTC to pAR to cancel an ongoing CT process. then nAR may send CTC to pAR to cancel an ongoing CT 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 | | Type=CTC | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4.6 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. The fields following
the Previous IP address of the MN are included verbatim from the CTAR
message.
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 | | Type=CTREQ | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous 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 Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Type (if present) | | Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message data for CT Request is the Mobile Node's Previous Care-of 'V' bits When set to '00', indicate presence of IPv6
Address, MN Authorization Token, followed by a list of context types. Previous (New) address only.
If no context types are specified, then all contexts for the mobile When set to '01' indicate presence of IPv4
node are requested. The fields including and following the Previous (New) Address only.
Authorization Token Type are inserted from the CTAR message. When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
The algorithm for carrying out the computation is HMAC_SHA1. The Replay A value used to make sure that each use of the
Authorization token is obtained by truncating the results of the CTAR message is uniquely identifiable.
HMAC_SHA1 computation to retain only the leading 32 bits. The input Copied from CTAR.
data for computing the token are: the MN's Previous IP address, the
FPT objects and the Replay field. When support for transferring all Authorization Token
contexts is requested, a default FPT is used. An unforgeable value calculated as discussed
above. This authorizes the receiver of CTAR
to perform context transfer. Copied from
CTAR.
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. possible for that feature context.
skipping to change at page 14, line 47 skipping to change at page 16, line 19
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 to
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 MUST 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
skipping to change at page 15, line 47 skipping to change at page 17, line 20
The Context Profile Type introduced in this document requires IANA Type The Context Profile Type introduced in this document requires IANA Type
Numbers for each set of feature contexts that make use of Profile Types. Numbers for each set of feature contexts that make use of Profile Types.
For registration requests where a Designated Expert should be consulted, For registration requests where a Designated Expert should be consulted,
the responsible IESG area director should appoint the Designated Expert. the responsible IESG area director should appoint the Designated Expert.
7.2 UDP Port 7.2 UDP Port
CTP requires a UDP port assignment. CTP requires a UDP port assignment.
8. Acknowledgements 8. Acknowledgements & Contributors
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.
working group chairs are Pat Calhoun and James Kempf, whose comments
have been very helpful during the creation of this specification. Contributors to the Context Transfer Protocol review are Basavaraj
Patil, Pekka Savola, and Antti Tuominen.
The working group chairs are Pat Calhoun and James Kempf, whose
comments have been very helpful during the creation of this
specification.
The authors would also like to thank Julien Bournelle, Vijay
Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf
Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their
help and suggestions with this document.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 17, line 24 skipping to change at page 19, line 8
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet [RFC2401] 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 [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[RFC2246] 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.
[RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast
Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999.
[RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery
for IP Version 6 (IPv6)," RFC 2461, December, 1998.
[RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfigura-
tion," RFC 2462, December, 1998.
Appendix A. Timing and Trigger Considerations Appendix A. 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 ser- latencies that practically prohibit its use for certain types of ser-
vices. Mobile IP latency and packet loss is being optimized through vices. Mobile IP latency and packet loss is being optimized through
several alternative procedures, such as Fast Mobile IP [FMIPv6] and several alternative procedures, such as Fast Mobile IP [FMIPv6] and
Low Latency Mobile IP [LLMIP]. Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute Feature re-establishment through context transfer should contribute
skipping to change at page 18, line 30 skipping to change at page 20, line 21
and context transfer. Important considerations should be network- and context transfer. Important considerations should be network-
provisioning, intra-domain vs. inter-domain signaling as well as provisioning, intra-domain vs. inter-domain signaling as well as
other considerations. A quick analysis follows. other considerations. A quick analysis follows.
It is assumed that intra-domain time-critical context transfer should It is assumed that intra-domain time-critical context transfer should
take 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 some context transfer solutions. Contexts that are significantly
larger are assumed not so time critical. For a larger number of larger are assumed not so time critical. For a larger number of
users, say one thousand users requesting a smooth handover all in the users, say one thousand users requesting a smooth handover all in the
same second, the total bandwidth needed is still a small fraction of same second, the total bandwidth needed is still a small fraction of
a typical Ethernet or frame relay or ATM link between access routers. a typical Ethernet, frame relay or ATM link between access routers.
So even bursty 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 one Furthermore, physically adjacent access routers should be within 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- congestive errors, the access network may be seriously under-
provisioned. 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 reliability needs, each context has to be considered separately by
the sending access router nAR. If a CTD message is retransmitted the sending access router nAR. If a CTD message is retransmitted
because the CTDR message was not received in time, then those con- because the CTDR message was not received in time, then those con-
texts that are "too late" are included anyway as part of the texts that are "too late" are included anyway as part of the
retransmitted CTD data, in order to ease the ability to verify the retransmitted CTD data, in order to ease the ability to verify the
Mobile Authorization Token. Mobile Authorization Token.
Appendix C. Multicast Listener Context Transfer
Introduction
As an example of how context transfer can improve the performance of
IP layer handover, we consider transferring IPv6 MLD state [RFC2710].
MLD state is a particularly good example because every IPv6 node must
perform two MLD messaging sequences on the wireless link to establish
itself as an MLD listener prior to performing router discovery
[RFC2461] or duplicate address detection [RFC2462] or before
sending/receiving any application-specific traffic (including Mobile
IP handover signaling, if any). The node must subscribe to the All
Nodes Multicast Address and the Solicited Node Multicast Address as
soon as it comes up on the link. In addition, any application-
specific multicast addresses must be re-established as well. Context
transfer can significantly speed up re-establishing multicast state
by allowing the nAR to initialize MLD for a node that just completed
handover; without any MLD signaling on the new wireless link. The
same approach could be used for transferring multicast context in
IPv4.
An approximate qualitative estimate for the amount of savings in
handover time can be obtained as follows. MLD messages are 24 bytes,
to which the IPv6 header, 40 bytes, and a required Routing Header
Type 0, 24 bytes, must be added (because there will be no header
compression on the new link), for a total MLD message size of 88
bytes per message per subscribed address. RFC 2710 recommends that
nodes send 2 to 3 MLD Report messages per address subscription, since
the Report message is unacknowledged. Assuming 2 MLD messages sent
per address subscription, the mobile node would need to send a total
of 4 MLD messages for the two pre-router discovery multicast
addresses (All Nodes Multicast Address and Solicited Node Multicast
Address for the link local address). This gives a total of 176 bytes
per subscribed address or 352 bytes over the wireless link for both
the pre-router discovery multicast addresses. The amount of time
saved will, of course, depend on the wireless link bandwidth, but
some representative numbers can be obtained by assuming bandwidths of
20 kbps or 100 kbps. The former is approximate for a narrowband 3G
cellular link and the latter for a moderately utilized 802.11b WLAN
link, both running Voice over IP (VoIP). With these two bit rates,
the savings from not having to perform the pre-router discovery mes-
sages are 140.8 msec. and 28.2 msec., respectively. If any
application-specific multicast addresses were subscribed, the amount
of time saved could be substantially more. Considering most ATM-based
3G voice cellular protocols try to keep total voice handover delay
less than 40-80 msec., MLD signaling could have a large impact on the
performance of inter-subnet VoIP handover.
The Protocol
The context-specific data field for MLD context transfer included in
the CTP Context Data Block message for a single IPv6 multicast
address has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix on nAR Wireless Interface +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Subscribed IPv6 Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Subnet Prefix on nAR Wireless Interface field contains a subnet
prefix that identifies the interface on which multicast routing
should be established. The Subscribed IPv6 Multicast Address field
contains the multicast address for which multicast routing should be
established.
The pAR sends one MLD context block per subscribed IPv6 multicast
address.
Router MLD State Machine Interactions
No changes are required in the MLD state machine for the routers.
Upon receipt of a CTP Context Data Block for MLD, if the router is in
the No Listeners Present state, it transitions to the Listeners
Present state for the Subscribed IPv6 Multicast Address on the wire-
less interface specified by the Subnet Prefix on nAR Wireless Inter-
face and starts its timer, as if it had received a Report message in
the No Listeners Present state. If the router is in the Listeners
Present state for the multicast address, it remains in that state but
restarts the timer, as if it had received a Report message in that
state.
If more than one MLD router is on the link, a router receiving a MLD
context data block SHOULD send a CTP Context Data Block for the Sub-
scribed IPv6 Multicast Address and the Subnet Prefix on nAR Wireless
Interface to other MLD routers on the link. A router receiving an MLD
context data block MAY send a proxy MLD Report message instead, if
wireless bandwidth is not an issue. Since MLD routers do not keep
track of which nodes are listening to multicast addresses, only
whether a particular multicast address is being listened to, proxying
the subscription should cause no difficulty.
Authors' 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
Itmerenkatu 11-13 Itdmerenkatu 11-13
00180 Espoo 00180 Espoo
Finland Finland
john.loughney@nokia.com john.loughney@nokia.com
Madjid F. Nakhjiri Madjid F. Nakhjiri
Motorola Labs Motorola Labs
1031 East Algonquin Rd., Room 2240 1031 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196 Schaumburg, IL, 60196
USA USA
madjid.nakhjiri@motorola.com madjid.nakhjiri@motorola.com
 End of changes. 

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