draft-ietf-seamoby-ctp-11.txt   rfc4067.txt 
Seamoby WG J. Loughney (editor) Network Working Group J. Loughney, Ed.
Internet Draft M. Nakhjiri Request for Comments: 4067 M. Nakhjiri
Category: Experimental C. Perkins Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-11.txt> R. Koodli R. Koodli
Expires: Feburary 2005 August 2004 July 2005
Context Transfer Protocol
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Context Transfer Protocol (CXTP)
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2004. All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document presents a context transfer protocol that enables This document presents the Context Transfer Protocol (CXTP) that
authorized context transfers. Context transfers allow better support enables authorized context transfers. Context transfers allow better
for node based mobility so that the applications running on mobile support for node based mobility so that the applications running on
nodes can operate with minimal disruption. Key objectives are to mobile nodes can operate with minimal disruption. Key objectives are
reduce latency, packet losses and avoiding re-initiation of signaling to reduce latency and packet losses, and to avoid the re-initiation
to and from the mobile node. of signaling to and from the mobile node.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 The Problem 1.1. The Problem. . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Conventions Used in This Document 1.2. Conventions Used in This Document. . . . . . . . . . . . 3
1.3 Abbreviations Used in the Document 1.3. Abbreviations Used in the Document . . . . . . . . . . . 3
2. Protocol Overview 2. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Context Transfer Scenarios 2.1. Context Transfer Scenarios . . . . . . . . . . . . . . . 4
2.2 Context Transfer Message Format 2.2. Context Transfer Message Format. . . . . . . . . . . . . 5
2.3 Context Types 2.3. Context Types. . . . . . . . . . . . . . . . . . . . . . 6
2.4 Context Data Block (CTB) 2.4. Context Data Block (CDB) . . . . . . . . . . . . . . . . 7
2.5 Messages 2.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Transport 3. Transport. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Inter-Router Transport 3.1. Inter-Router Transport . . . . . . . . . . . . . . . . . 16
3.2 MN-AR Transport 3.2. MN-AR Transport. . . . . . . . . . . . . . . . . . . . . 19
4. Error Codes and Constants 4. Error Codes and Constants. . . . . . . . . . . . . . . . . . . 20
5. Examples and Signaling Flows 5. Examples and Signaling Flows . . . . . . . . . . . . . . . . . 21
5.1 Network controlled, Initiated by pAR, Predictive 5.1. Network controlled, Initiated by pAR, Predictive . . . . 21
5.2 Network controlled, Initiated by nAR, Reactive 5.2. Network controlled, Initiated by nAR, Reactive . . . . . 21
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3. Mobile controlled, Predictive New L2 up/Old L2 down. . . 22
6. Security Considerations 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1 Threats 6.1. Threats. . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Access Router Considerations 6.2. Access Router Considerations . . . . . . . . . . . . . . 23
6.3 Mobile Node Considerations 6.3. Mobile Node Considerations . . . . . . . . . . . . . . . 24
7. IANA Considerations 7. Acknowledgements & Contributors. . . . . . . . . . . . . . . . 25
8. Acknowledgements & Contributors 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. References 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.1 Normative References 8.2. Informative References . . . . . . . . . . . . . . . . . 26
9.2 Non-Normative References Appendix A. Timing and Trigger Considerations . . . . . . . . . . 28
Appendix A. Timing and Trigger Considerations Appendix B. Multicast Listener Context Transfer . . . . . . . . . 28
Appendix B. Multicast Listener Context Transfer
Authors' Addresses
Full Copyright Statement
Intellectual Property
Acknowledgement
1. Introduction 1. Introduction
This document describes the Context Transfer Protocol overview, which This document describes the 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. The protocol protocols in order to provide seamless mobility. The protocol
supports both IPv4 and IPv6, though support for IPv4 private supports both IPv4 and IPv6, though support for IPv4 private
addresses is for future study. addresses is for future study.
1.1 The Problem 1.1. The Problem
"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) As mentioned in the introduction, the primary motivation is to
need to quickly re-establish context transfer-candidate services quickly re-establish context transfer-candidate services without
without requiring the mobile host to explicitly perform all requiring the mobile host to explicitly perform all protocol flows
protocol flows for those services from scratch. An example of a for those services from scratch. An example of such a service is
service is included in Appendix B. included in Appendix B of this document.
2) An additional motivation is to provide an interoperable solution 2) An additional motivation is to provide an interoperable solution
that supports various Layer 2 radio access technologies. that supports various Layer 2 radio access technologies.
1.2 Conventions Used in This Document 1.2. 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.3 Abbreviations Used in the Document 1.3. Abbreviations Used in the Document
Mobility Related Terminology [TERM] defines basic mobility Mobility Related Terminology [TERM] defines basic mobility
terminology. In addition to the material in that document, we use terminology. In addition to the material in that document, we use
the following terms and abbreviation in this document. the following terms and abbreviations in this document.
CTP Context Transfer Protocol CXTP Context Transfer Protocol
DoS Denial-of-Service DoS Denial-of-Service
FPT Feature Profile Types FPT Feature Profile Types
PCTD Predictive Context Transfer Data PCTD Predictive Context Transfer Data
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 the new or the previous access
access router ("network controlled"). router ("network controlled").
* The mobile node (MN) sends the CT Activate Request (CTAR) to its * The mobile node (MN) sends the CT Activate Request (CTAR) to
current access router (AR) immediately prior to handover whenever its current access router (AR) immediately prior to handover
possible to initiate predictive context transfer. In any case, the when it is possible to initiate a predictive context transfer.
MN always sends the CTAR message to the new AR (nAR). If the In any case, the MN always sends the CTAR message to the new AR
contexts are already present, nAR verifies the authorization token (nAR). If the contexts are already present, nAR verifies the
present in CTAR with its own computation using the parameters authorization token present in CTAR with its own computation
supplied by the previous access router (pAR), and subsequently using the parameters supplied by the previous access router
activates those contexts. If the contexts are not present, nAR (pAR), and subsequently activates those contexts. If the
requests pAR to supply them using the Context Transfer Request contexts are not present, nAR requests pAR to supply them using
message, in which it supplies the authorization token present in the Context Transfer Request message, in which it supplies the
CTAR. 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 A). transfer based on internal or network triggers (see Appendix
A).
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 pAR and the target node is MN's Typically, the source node is an MN's pAR and the target node is an
nAR. Context Transfer takes place when an event, such as a handover, MN's nAR. Context Transfer takes place when an event, such as a
takes place. We call such an event a Context Transfer Trigger. In handover, takes place. We call such an event a Context Transfer
response to such a trigger, the pAR may transfer the contexts; the Trigger. In response to such a trigger, the pAR may transfer the
nAR may request contexts; and the MN may send a message to the contexts; the nAR may request contexts; and the MN may send a message
routers to transfer contexts. Such a trigger must be capable of to the routers to transfer contexts. Such a trigger must be capable
providing the necessary information (such as the MN's IP address) by of providing the necessary information (such as the MN's IP address)
which the contexts are identified, the IP addresses of the access by which the contexts are identified. In addition, the trigger must
routers, and authorization to transfer context. be able to provide the IP addresses of the access routers, and the
authorization to transfer context.
Context transfer protocol messages use Feature Profile Types (FPTs) Context transfer protocol messages use Feature Profile Types (FPTs)
that identify the way that data is organized for the particular that identify the way that data is organized for the particular
feature contexts. The FPTs are registered in a number space (with feature contexts. The FPTs are registered in a number space (with
IANA Type Numbers) that allows a node to unambiguously determine the IANA Type Numbers) that allows a node to unambiguously determine the
type of context and the context parameters present in the protocol type of context and the context parameters present in the protocol
messages. Contexts are transferred by laying out the appropriate messages. Contexts are transferred by laying out the appropriate
feature data within Context Data Blocks according to the format in feature data within Context Data Blocks according to the format in
Section 2.3, as well as any IP addresses necessary to associate the Section 2.3, as well as any IP addresses necessary to associate the
contexts to a particular MN. The context transfer initiation messages contexts to a particular MN. The context transfer initiation
contain parameters that identify the source and target nodes, the messages contain parameters that identify the source and target
desired list of feature contexts and IP addresses to identify the nodes, the desired list of feature contexts, and IP addresses to
contexts. The messages that request transfer of context data also identify the contexts. The messages that request the transfer of
contain an appropriate token to authorize the context transfer. context data also contain an appropriate token to authorize the
context transfer.
Performing context transfer in advance of the MN attaching to nAR can Performing a context transfer in advance of the MN attaching to nAR
increase handover performance. For this to take place, certain can 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 of the impending handover. This is feasible, for
instance, in Mobile IP fast handovers [LLMIP][FMIPV6]. Additionally, instance, in Mobile IP fast handovers [LLMIP][FMIPv6]. Additionally,
many cellular networks have mechanisms to detect handovers in many cellular networks have mechanisms to detect handovers in
advance. However, when the advance knowledge of impending handover is advance. However, when the advance knowledge of impending handover
not available, or if a mechanism such as fast handover fails, is not available, or if a mechanism such as fast handover fails,
retrieving feature contexts after the MN attaches to nAR is the only retrieving feature contexts after the MN attaches to nAR is the only
available means for context transfer. Performing context transfer available means for context transfer. Performing context transfer
after handover might still be better than having to re-establish all after handover might still be better than having to re-establish all
the contexts from scratch. Finally, some contexts may simply need to the contexts from scratch, as shown in [FHCT] and [TEXT]. Finally,
be transferred during handover signaling. For instance, any context some contexts may simply need to be transferred during handover
that gets updated on a per-packet basis must clearly be transferred signaling. For instance, any context that gets updated on a per-
only after packet forwarding to the MN on its previous link is packet basis must clearly be transferred only after packet forwarding
terminated. to the MN on its previous link has been terminated.
2.1 Context Transfer Scenarios 2.1. Context Transfer Scenarios
The Previous Access Router transfers feature contexts under two The Previous Access Router transfers feature contexts under two
general scenarios. general scenarios.
2.1.1 Scenario 1 2.1.1. Scenario 1
The pAR receives a Context Transfer Activate Request (CTAR) message The pAR receives a Context Transfer Activate Request (CTAR) message
from the MN whose feature contexts are to be transferred, or it from the MN whose feature contexts are to be transferred, or it
receives an internally generated trigger (e.g., a link-layer trigger receives an internally generated trigger (e.g., a link-layer trigger
on the interface to which the MN is connected). The CTAR message, on the interface to which the MN is connected). The CTAR message,
described in Section 2.5, provides the IP address of nAR, the IP described in Section 2.5, provides the IP address of nAR, the IP
address of MN on pAR, the list of feature contexts to be transferred address of MN on pAR, the list of feature contexts to be transferred
(by default requesting all contexts to be transferred), and a token (by default requesting all contexts to be transferred), and a token
authorizing the transfer. In response to a CT-Activate Request authorizing the transfer. In response to a CT-Activate Request
message or to the CT trigger, pAR predictively transmits a Context message or to the CT trigger, pAR predictively transmits a Context
Transfer Data (CTD) message that contains feature contexts. This Transfer Data (CTD) message that contains feature contexts. This
message, described in Section 2.5, contains the MN's previous IP message, described in Section 2.5, contains the MN's previous IP
address. It also contains parameters for nAR to compute an address. It also contains parameters for nAR to compute an
authorization token to verify the MN's token present in CTAR message. authorization token to verify the MN's token that is present in the
Recall that the MN always sends CTAR message to nAR regardless of CTAR message. Recall that the MN always sends a CTAR message to nAR
whether it sent the CTAR message to pAR. The reason for this is that regardless of whether it sent the CTAR message to pAR because there
there is no means for the MN to ascertain that context transfer is no means for the MN to ascertain that context transfer has
reliably took place. By always sending the CTAR message to nAR, the reliably taken place. By always sending the CTAR message to nAR, the
Context Transfer Request (see below) can be sent to pAR if necessary. Context Transfer Request (see below) can be sent to pAR if necessary.
When context transfer takes place without the nAR requesting it, nAR When context transfer takes place without the nAR requesting it, nAR
requires MN to present its authorization token. Doing this locally at requires MN to present its authorization token. Doing this locally
nAR when the MN attaches to it improves performance and increases at nAR when the MN attaches to it improves performance and increases
security, since the contexts are highly likely to be present already. security, since the contexts are likely to already be present. Token
Token verification takes place at the router possessing the contexts. verification takes place at the router possessing the contexts.
2.1.2 Scenario 2 2.1.2. Scenario 2
In the second scenario, pAR receives a Context Transfer Request (CT- In the second scenario, pAR receives a Context Transfer Request (CT-
Req), described in Section 2.5, message from nAR. The nAR itself Req) message from nAR, as described in Section 2.5. The nAR itself
generates the CT-Req message as a result of receiving the CTAR generates the CT-Req message as a result of receiving the CTAR
message, or, alternatively, from receiving a context transfer message, or alternatively, from receiving a context transfer trigger.
trigger. In the CT-Req message, nAR supplies the MN's previous IP In the CT-Req message, nAR supplies the MN's previous IP address, the
address, the FPTs for the feature contexts to be transferred, the FPTs for the feature contexts to be transferred, the sequence number
sequence number from the CTAR, and the authorization token from the from the CTAR, and the authorization token from the CTAR. In
CTAR. In response to CT-Req message, pAR transmits a Context Transfer response to a CT-Req message, pAR transmits a Context Transfer Data
Data (CTD) message that includes the MN's previous IP address and (CTD) message that includes the MN's previous IP address and feature
feature contexts. When it receives a corresponding CTD message, nAR contexts. When it receives a corresponding CTD message, nAR may
may generate a CTD Reply (CTDR) message to report the status of generate a CTD Reply (CTDR) message to report the status of
processing the received contexts. The nAR installs the contexts once processing the received contexts. The nAR installs the contexts once
it has received them from the pAR. it has received them from the pAR.
2.2 Context Transfer Message Format 2.2. Context Transfer Message Format
A CTP message consists of a message-specific header and one or more A CXTP message consists of a message-specific header and one or more
data blocks. Data blocks may be bundled together in order to ensure data blocks. Data blocks may be bundled together to ensure a more
a more efficient transfer. On the inter-AR interface, SCTP is used efficient transfer. On the inter-AR interface, SCTP is used so
so fragmentation should not be a problem. On the MN-AR interface, the fragmentation should not be a problem. On the MN-AR interface, the
total packet size, including transport protocol and IP protocol total packet size, including transport protocol and IP protocol
headers SHOULD be less than the path MTU, in order to avoid packet headers, SHOULD be less than the path MTU to avoid packet
fragmentation. Each message contains a three bit version number field fragmentation. Each message contains a 3 bit version number field in
in the low order octet, along with the 5 bit message type code. This the low order octet, along with the 5 bit message type code. This
specification only applies to Version 1 of the protocol, and the specification only applies to Version 1 of the protocol, and the
therefore version number field MUST be set to 0x1. If future therefore version number field MUST be set to 0x1. If future
revisions of the protocol make binary incompatible changes, the revisions of the protocol make binary incompatible changes, the
version number number MUST be incremented. version number MUST be incremented.
2.3 Context Types 2.3. Context Types
Contexts are identified by FPT code, which is a 16-bit unsigned Contexts are identified by the FPT code, which is a 16 bit unsigned
integer. The meaning of each context type is determined by a integer. The meaning of each context type is determined by a
specification document and the context type numbers are to be specification document. The context type numbers are to be tabulated
tabulated in a registry maintained by IANA [IANA], and handled in a registry maintained by IANA [IANA] and handled according to the
according to the message specifications in this document. The message specifications in this document. The instantiation of each
instantiation of each context by nAR is determined by the messages in context by nAR is determined by the messages in this document along
this document along with the specification associated with the with the specification associated with the particular context type.
particular context type. The following diagram illustrates the The following diagram illustrates the general format for CXTP
general format for CTP messages: messages:
+----------------------+ +----------------------+
| Message Header | | Message Header |
+----------------------+ +----------------------+
| CTP Data 1 | | CXTP Data 1 |
+----------------------+ +----------------------+
| CTP Data 2 | | CXTP Data 2 |
+----------------------+ +----------------------+
| ... | | ... |
Each context type specification contains the following details: Each 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 that 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
and date field sizes presented in the specification. data 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.4 Context Data Block (CTB) 2.4. Context Data Block (CDB)
The Context Data Block (CTB) is used both for request and response The Context Data Block (CDB) is used both for request and response
operation. When a request is constructed, only the first 4 octets are operations. When a request is constructed, only the first 4 octets
typically necessary (See CTAR below). When used for transferring the are typically necessary (See CTAR below). When used for transferring
actual feature context itself, the context data is present, and the actual feature context itself, the context data is present, and
sometimes the presence vector is present. the presence vector is sometimes 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feature Profile Type (FTP) | Length |P| Reserved | | Feature Profile Type (FPT) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) | | Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data ~ ~ Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature Profile Type Feature Profile Type
16 bit integer, assigned by IANA, 16 bit integer, assigned by IANA,
indicating the type of data indicating the type of data
included in the Data field included in the Data field.
Length Message length in units of 8 octet words. Length Message length in units of 8 octet words.
'P' bit 0 = No presence vector 'P' bit 0 = No presence vector.
1 = Presence vector present. 1 = Presence vector present.
Reserved Reserved for future use. Set to Reserved Reserved for future use. Set to
zero by the sender. zero by the sender.
Data Context type-dependent data, whose Data Context type-dependent data, whose
length is defined by the Length length is defined by the Length
Field. If the data is not 64-bit Field. If the data is not 64 bit
aligned, the data field is aligned, the data field is
padded with zeros. padded with zeros.
The Feature Profile Type (FPT) code indicates the type of data in the The Feature Profile Type (FPT) code indicates the type of data in the
data field. Typically, this will be context data but it might be an data field. Typically, this will be context data, but it could be an
error indication. The 'P' bit specifies whether or not the "presence error indication. The 'P' bit specifies whether the "presence
vector" is used. When the presence vector is in use, the Presence vector" is used. When the presence vector is in use, it is
Vector is interpreted to indicate whether particular data fields are interpreted to indicate whether particular data fields are present
present (and containing non-default values). The ordering of the (and contain non-default values). The ordering of the bits in the
bits in the presence vector is the same as the ordering of the data presence vector is the same as the ordering of the data fields
fields according to the context type specification, one bit per data according to the context type specification, one bit per data field
field regardless of the size of the data field. The Length field regardless of the size of the data field. The Length field indicates
indicates the size of the CTB in 8 octet words including the first 4 the size of the CDB in 8 octet words, including the first 4 octets
octets starting from FPT. starting from FPT.
Notice that the length of the context data block is defined by the 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 sum of the lengths of each data field specified by the context type
specification, plus 4 octets if the 'P' bit is set, minus the specification, plus 4 octets if the 'P' bit is set, minus the
accumulated size of all the context data that is implicitly given as accumulated size of all the context data that is implicitly given as
a default value. a default value.
2.5 Messages 2.5. Messages
In this section, the CTP messages are defined. The MN for which In this section, the CXTP messages are defined. The MN for which
context transfer protocol operations are undertaken is always context transfer protocol operations are undertaken is always
identified by its previous IP access address. At any time, only one identified by its previous IP access address. Only one context
context transfer operation per MN may be in progress so that the CTDR transfer operation per MN may be in progress at a time so that the
message unambiguously identifies which CTD message is acknowledged CTDR message unambiguously identifies which CTD message is
simply by including the MN's identifying previous IP address. The 'V' acknowledged simply by including the MN's identifying previous IP
flag indicates whether the IP addresses are IPv4 or IPv6. address. The 'V' flag indicates whether the IP addresses are IPv4 or
IPv6.
2.5.1 Context Transfer Activate Request (CTAR) Message 2.5.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 the MN to the nAR to request a context
Even when the MN does not know if contexts need to be transferred, transfer. Even when the MN does not know if contexts need to be
the MN sends the CTAR message. If an acknowledgement for this message transferred, the MN sends the CTAR message. If an acknowledgement
is needed, the MN sets the 'A' flag to 1; otherwise the MN does not for this message is needed, the MN sets the 'A' flag to 1; otherwise
expect an acknowledgement. This message may include a list of FPTs the MN does not expect an acknowledgement. This message may include
that require transfer. a list of FPTs that require 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; otherwise, pAR. In this case, the MN includes the nAR's IP address; otherwise,
if the message is sent to nAR, the pAR address is sent. The MN MUST if the message is sent to nAR, the pAR address is sent. The MN MUST
set the sequence number to the same value for the message sent on set the sequence number to the same value as was set for the message
both pAR and nAR so pAR can determine whether to use a cached sent on both pAR and nAR so pAR can determine whether to use a cached
message. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|A| Reserved | Length | |Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MN's Previous IP Address ~ ~ MN's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Previous (New) AR IP Address ~ ~ Previous (New) AR IP Address ~
skipping to change at page 10, line 36 skipping to change at page 9, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) | | Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) | | Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CXTP protocol = 0x1
Type CTAR = 0x1 Type CTAR = 0x1
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
'A' bit If set, the MN requests an acknowledgement. 'A' bit If set, the MN requests an acknowledgement.
Reserved Set to zero by the sender, ignored by the Reserved Set to zero by the sender, ignored by the
receiver. receiver.
Length Message length in units of octets. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv4 Address as defined in [RFC 791], IPv6 [RFC3513] Address, 16 octets.
4 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
nAR / pAR IP Address Field contains either: nAR / pAR IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 [RFC791] Address, 4 octets, or
4 octets. IPv6 [RFC3513] Address, 16 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
Sequence Number A value used to identify requests and Sequence Number A value used to identify requests and
acknowledgements (see Section 3.2). acknowledgements (see Section 3.2).
Authorization Token Authorization Token An unforgeable value calculated as
An unforgeable value calculated as
discussed below. This authorizes the discussed below. This authorizes the
receiver of CTAR to perform context receiver of CTAR to perform context
transfer. transfer.
Context Block Variable length field defined in Context Block Variable length field defined in
Section 2.4. Section 2.4.
If no context types are specified, all contexts for the MN are If no context types are specified, all contexts for the MN are
requested. requested.
The Authorization Token is calculated as: The Authorization Token is calculated as:
First (32, HMAC_SHA1 First (32, HMAC_SHA1
(Key, (Previous IP address | Sequence Number | CTBs))) (Key, (Previous IP address | Sequence Number | CDBs)))
where Key is a shared secret between the MN and pAR, and CTBs is a where Key is a shared secret between the MN and pAR, and CDB is a
concatenation of all the Context Data Blocks specifying the contexts concatenation of all the Context Data Blocks specifying the contexts
to be transfered which are included in the CTAR message. to be transferred that are included in the CTAR message.
2.5.2 Context Transfer Activate Acknowledge (CTAA) Message 2.5.2. Context Transfer Activate Acknowledge (CTAA) Message
This is an informative message sent by the receiver of CTAR to the MN This is an informative message sent by the receiver of CTAR to the MN
to acknowledge a CTAR message. Acknowledgement is optional, depending to acknowledge a CTAR message. Acknowledgement is optional,
on whether the MN requested it. This message may include a list of depending on whether the MN requested it. This message may include a
FPTs that were not transferred successfully. list of FPTs that were not successfully transferred.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length | |Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP address ~ ~ Mobile Node's Previous IP address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved | | FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CXTP protocol = 0x1
Type CTAA = 0x2 Type CTAA = 0x2
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
Length Message length in units of octets. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 [RFC791] Address, 4 octets, or
4 octets. IPv6 [RFC3513] Address, 16 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
FPT 16 bit unsigned integer, listing the FTP FPT 16 bit unsigned integer, listing the Feature
that was not successfully transferred. Profile Type that was not successfully
transferred.
Status Code An octet, containing failure reason. Status Code An octet, containing failure reason.
2.5.3 Context Transfer Data (CTD) Message ........ more FPTs and status codes as necessary
Sent by pAR to nAR, and includes feature data (CTP data). This 2.5.3. Context Transfer Data (CTD) Message
message handles predictive as well as normal CT. An acknowledgement
Sent by pAR to nAR, and includes feature data (CXTP data). This
message handles both predictive and normal CT. An acknowledgement
flag, 'A', included in this message indicates whether a reply is flag, 'A', included in this message indicates whether a reply is
required by pAR. required by pAR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|A| Reserved | Length | |Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) | | Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 25 skipping to change at page 11, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD
| Key | only | Key | only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
~ First Context Data Block ~ ~ First Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Context Data Block ~ ~ Next Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~ ~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CXTP protocol = 0x1
Type CTD = 0x3 (Context Transfer Data) Type CTD = 0x3 (Context Transfer Data)
PCTD = 0x4 (Predictive Context Transfer PCTD = 0x4 (Predictive Context Transfer
Data) Data)
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
'A' bit When set, the pAR requests an 'A' bit When set, the pAR requests an
acknowledgement. acknowledgement.
Length Message length in units of octets. Length Message length in units of octets.
Elapsed Time The number of milliseconds since the Elapsed Time The number of milliseconds since the
transmission of the first CTD message for transmission of the first CTD message for
skipping to change at page 13, line 44 skipping to change at page 12, line 17
'A' bit When set, the pAR requests an 'A' bit When set, the pAR requests an
acknowledgement. acknowledgement.
Length Message length in units of octets. Length Message length in units of octets.
Elapsed Time The number of milliseconds since the Elapsed Time The number of milliseconds since the
transmission of the first CTD message for transmission of the first CTD message for
this MN. this MN.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 [RFC791] Address, 4 octets, or
4 octets. IPv6 [RFC3513] Address, 16 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
Algorithm Algorithm for carrying out the computation Algorithm Algorithm for carrying out the computation
of the MN Authorization Token. Currently of the MN Authorization Token. Currently
only 1 algorithm is defined, HMAC_SHA1 = 1. only 1 algorithm is defined, HMAC_SHA1 = 1.
Key Length Length of key, in octets. Key Length Length of key, in octets.
Key Shared key between MN and AR for CTP. Key Shared key between MN and AR for CXTP.
Context Data Block The Context Data Block (see Section 2.4). Context Data Block The Context Data Block (see Section 2.4).
When CTD is sent predictively, the supplied parameters including the When CTD is sent predictively, the supplied parameters (including the
algorithm, key length and the key itself, allowing nAR to compute a algorithm, key length, and the key itself) allow the nAR to compute a
token locally and verify against the token present in the CTAR token locally and verify it against the token present in the CTAR
message. This material is also sent if the pAR receives a CTD message. This material is also sent if the pAR receives a CTD
message with a null Authorization Token, indicating that the CT-Req message with a null Authorization Token, indicating that the CT-Req
message has been sent before the nAR received the CTAR message. CTD message was sent before the nAR received the CTAR message. CTD MUST
MUST be protected by IPsec, see Section 6. be protected by IPsec; see Section 6.
As described previously, the algorithm for carrying out the As described previously, the algorithm for carrying out the
computation of the MN Authorization Token is HMAC_SHA1. The token computation of the MN Authorization Token is HMAC_SHA1. The token
authentication calculation algorithm is described in Section 2.5.1. authentication calculation algorithm is described in Section 2.5.1.
For predictive handover, the pAR SHOULD keep track of the CTAR For predictive handover, the pAR SHOULD keep track of the CTAR
sequence number and cache the CTD message until receiving either a sequence number and cache the CTD message until a CTDR message for
CTDR message for the MN's previous IP address from the pAR, the MN's previous IP address has been received from the pAR,
indicating that the context transfer was successful, or until indicating that the context transfer was successful, or until
CT_MAX_HANDOVER_TIME expires. The nAR MAY send a CT-Req message CT_MAX_HANDOVER_TIME expires. The nAR MAY send a CT-Req message
containing the same sequence number if the predictive CTD message containing the same sequence number if the predictive CTD message
failed to arrive or the context was corrupted, In that case, the nAR failed to arrive or the context was corrupted. In this case, the nAR
sends a CT-Req message with a matching sequence number and pAR can sends a CT-Req message with a matching sequence number and pAR can
resend the context. resend the context.
2.5.4 Context Transfer Data Reply (CTDR) Message 2.5.4. Context Transfer Data Reply (CTDR) Message
This message is sent by nAR to pAR depending on the value of the 'A' This message is sent by nAR to pAR depending on the value of the 'A'
flag in CTD. Indicates success or failure. flag in CTD, indicating 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|S| Reserved | Length | |Vers.| Type |V|S| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~ ~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved | | FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ....... ~ ~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CXTP protocol = 0x1
Type CTDR = 0x5 (Context Transfer Data) Type CTDR = 0x5 (Context Transfer Data)
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
'S' bit When set to one, this bit indicates 'S' bit When set to one, this bit indicates
that all feature contexts sent in CTD that all feature contexts sent in CTD
or PCTD were received successfully. or PCTD were received successfully.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
skipping to change at page 15, line 17 skipping to change at page 13, line 41
'S' bit When set to one, this bit indicates 'S' bit When set to one, this bit indicates
that all feature contexts sent in CTD that all feature contexts sent in CTD
or PCTD were received successfully. or PCTD were received successfully.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
Length Message length in units of octets. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 [RFC791] Address, 4 octets, or
4 octets. IPv6 [RFC3513] Address, 16 octets.
IPv6 Address as defined in [RFC 2373],
16 octets. FPT 16 bit unsigned integer, listing the Feature
Profile Type that is being acknowledged.
Status Code A context-specific return value, Status Code A context-specific return value,
zero for success, nonzero when 'S' is zero for success, nonzero when 'S' is
not set to one. not set to one.
FPT 16 bit unsigned integer, listing the FTP 2.5.5. Context Transfer Cancel (CTC) Message
that is being acknowledged.
2.5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length | |Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~ ~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CXTP protocol = 0x1
Type CTC = 0x6 (Context Transfer Cancel) Type CTC = 0x6 (Context Transfer Cancel)
Length Message length in units of octets. Length Message length in units of octets.
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 [RFC791] Address, 4 octets, or
4 octets. IPv6 [RFC3513] Address, 16 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
2.5.6 Context Transfer Request (CT-Req) Message 2.5.6. Context Transfer Request (CT-Req) Message
Sent by nAR to pAR to request start of context transfer. This message Sent by nAR to pAR to request the start of context transfer. This
is sent as a response to CTAR message from the MN. The fields message is sent as a response to a CTAR message. The fields
following the Previous IP address of the MN are included verbatim following the Previous IP address of the MN are included verbatim
from the CTAR message. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length | |Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~ ~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Requested Context Data Block (if present) ~ ~ Next Requested Context Data Block (if present) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~ ~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CXTP protocol = 0x1
Type CTREQ = 0x7 (Context Transfer Request) Type CTREQ = 0x7 (Context Transfer Request)
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored Reserved Set to zero by the sender and ignored
by the receiver. by the receiver.
Length Message length in units of octets. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 [RFC791] Address, 4 octets, or
4 octets. IPv6 [RFC3513] Address, 16 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
Sequence Number Copied from the CTAR message, allows the Sequence Number Copied from the CTAR message, allows the
pAR to distinguish requests for previously pAR to distinguish requests from previously
sent context. sent context.
MN's Authorization Token MN's Authorization Token
An unforgeable value calculated as An unforgeable value calculated as
discussed in Section 2.5.1. This discussed in Section 2.5.1. This
authorizes the receiver of CTAR to authorizes the receiver of CTAR to
perform context transfer. Copied from perform context transfer. Copied from
CTAR. CTAR.
Context Data Request Block Context Data Request Block
A request block for context data, see A request block for context data; see
Section 2.4. Section 2.4.
The sequence number is used by pAR to correlate a request for The sequence number is used by pAR to correlate a request for
previously transmitted context. In predictive transfer, if the MN previously transmitted context. In predictive transfer, if the MN
sends CTAR prior to handover, pAR pushes context to nAR using CTD. If sends CTAR prior to handover, pAR pushes context to nAR using PCTD.
the CTD fails, the nAR will send CT-Req with the same sequence If the CTD fails, the nAR will send a CT-Req with the same sequence
number, allowing the pAR to distinguish which context to resend. pAR number, enabling the pAR to determine which context to resend. The
drops the context after CTP_MAX_TRANSFER_TIME. The sequence number is pAR deletes the context after CXTP_MAX_TRANSFER_TIME. The sequence
not used in reactive transfer. number is not used in reactive transfer.
For predictive transfer the pAR sends the keying material and other For predictive transfer, the pAR sends the keying material and other
information necessary to calculate the Authorization Token, with no information necessary to calculate the Authorization Token without
CT-Req message necessary. For reactive transfer, if the nAR receives having processed a CT-Req message. For reactive transfer, if the nAR
a context transfer trigger but has not yet received the CTAR message receives a context transfer trigger but has not yet received the CTAR
with the authorization token, the Authorization Token field in CT-Req message with the authorization token, the Authorization Token field
is set to zero. The pAR interprets this as an indication to include in CT-Req is set to zero. The pAR interprets this as an indication
the keying material and other information necessary to calculate the to include the keying material and other information necessary to
Authorization Token, and includes this material into the CTD message calculate the Authorization Token, and includes this material into
as if the message were being sent due to predictive transfer. This the CTD message as if the message were being sent due to predictive
provides nAR with the information it needs to calculate the transfer. This provides nAR with the information it needs to
authorization token when the MN sends CTAR. calculate the authorization token when the MN sends CTAR.
3. Transport 3. Transport
3.1 Inter-Router Transport 3.1. Inter-Router Transport
Since the types of access networks in which CTP might be useful are Since most types of access networks in which CXTP might be useful are
not today deployed or, if they have been deployed, have not been not today deployed or, if they have been deployed, have not been
extensively measured, it is difficult to know whether congestion will extensively measured, it is difficult to know whether congestion will
be a problem for CTP. Part of the research task in preparing CTP for be a problem for CXTP. Part of the research task in preparing CXTP
consideration as a candidate for possible standardization is to for consideration as a possible candidate for standardization is to
quantify this issue. However, in order to avoid potential quantify this issue. However, to avoid potential interference with
interference with production applications should a prototype CTP production applications should a prototype CXTP deployment involve
deployment involve running over the public Internet, it seems prudent running over the public Internet, it seems prudent to recommend a
to recommend a default transport protocol that accommodates default transport protocol that accommodates congestion. In
congestion. In addition, since the feature context information has a addition, since the feature context information has a definite
definite lifetime, the transport protocol must accommodate flexible lifetime, the transport protocol must accommodate flexible
retransmission, so stale contexts that are held up by congestion are retransmission, so stale contexts that are held up by congestion are
dropped. Finally, because the amount of context data can be dropped. Finally, because the amount of context data can be
arbitrarily large, the transport protocol should not be limited to a arbitrarily large, the transport protocol should not be limited to a
single packet, or require implementing a custom fragmentation single packet or require implementing a custom fragmentation
protocol. protocol.
These considerations argue that implementations of CTP MUST support These considerations argue that implementations of CXTP MUST support,
and prototype deployments of CTP SHOULD use Stream Control Transport and prototype deployments of CXTP SHOULD use, the Stream Control
Protocol (SCTP) [SCTP] for the transport protocol on the inter-router Transport Protocol (SCTP) [SCTP] as the transport protocol on the
interface, especially if deployment over the public Internet is inter-router interface, especially if deployment over the public
contemplated. SCTP supports congestion control, fragmentation, and Internet is contemplated. SCTP supports congestion control,
partial retransmission based on a programmable retransmission timer. fragmentation, and partial retransmission based on a programmable
SCTP also supports many advanced and complex features, such as retransmission timer. SCTP also supports many advanced and complex
multiple streams and multiple IP addresses for failover, that are not features, such as multiple streams and multiple IP addresses for
necessary for experimental implementation and prototype deployment of failover that are not necessary for experimental implementation and
CTP. In this specification, the use of such SCTP features is not prototype deployment of CXTP. The use of such SCTP features is not
recommended at this time. recommended at this time.
The SCTP Payload Data Chunk carries the context transfer protocol The SCTP Payload Data Chunk carries the context transfer protocol
messages. The User Data part of each SCTP message contains an messages. The User Data part of each SCTP message contains an
appropriate context transfer protocol message defined in this appropriate context transfer protocol message defined in this
document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR
(Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In (Section 2.5.4), CTC (Section 2.5.5), and CT-Req (Section 2.5.6). In
general, each SCTP message can carry feature contexts belonging to general, each SCTP message can carry feature contexts belonging to
any MN. If the SCTP checksum calculation fails, the nAR returns the any MN. If the SCTP checksum calculation fails, the nAR returns the
BAD_CHECKSUM error code in a CTDR message. BAD_CHECKSUM error code in a CTDR message.
A single stream is used for context transfer without in-sequence A single stream is used for context transfer without in-sequence
delivery of SCTP messages. Each message corresponds to a single MN's delivery of SCTP messages. Each message corresponds to a single MN's
feature context collection. A single stream provides simplicity. Use feature context collection. A single stream provides simplicity.
of multiple streams to prevent head-of-line blocking is for future The use of multiple streams to prevent head-of-line blocking is for
study. Having unordered delivery allows the receiver to not block for future study. Unordered delivery allows the receiver to not block
in-sequence delivery of messages that belong to different MNs. The for in-sequence delivery of messages that belong to different MNs.
Payload Protocol Identifier in the SCTP header is 'CTP'. Inter-router The Payload Protocol Identifier in the SCTP header is 'CXTP'.
CTP uses the Seamoby SCTP port [IANA]. Inter-router CXTP uses the Seamoby SCTP port [IANA].
Timeliness of the context transfer information SHOULD be accommodated Timeliness of the context transfer information SHOULD be accommodated
by setting the SCTP maximum retransmission value to by setting the SCTP maximum retransmission value to
CT_MAX_TRANSFER_TIME in order to accommodate the maximum acceptable CT_MAX_TRANSFER_TIME to accommodate the maximum acceptable handover
handover delay time, and the AR SHOULD be configured with delay time. The AR SHOULD be configured with CT_MAX_TRANSFER_TIME to
CT_MAX_TRANSFER_TIME to accommodate the particular wireless link accommodate the particular wireless link technology and local
technology and local wireless propagation conditions. SCTP message wireless propagation conditions. SCTP message bundling SHOULD be
bundling SHOULD be turned off in order to reduce any extra delay in turned off to reduce an extra delay in sending messages. Within
sending messages. Within CTP, the nAR SHOULD estimate the retransmit CXTP, the nAR SHOULD estimate the retransmit timer from the receipt
timer from the receipt of the first fragment of a CTP message and of the first fragment of a CXTP message and avoid processing any IP
avoid processing any IP traffic from the MN until either context traffic from the MN until either context transfer is complete or the
transfer is complete or the estimated retransmit timer expires. If estimated retransmit timer expires. If both routers support PR-SCTP
both routers support PR-SCTP [PR-SCTP], then PR-SCTP SHOULD be used. [PR-SCTP], then PR-SCTP SHOULD be used. PR-SCTP modifies the
PR-SCTP modifies the lifetime parameter of the Send() operation lifetime parameter of the Send() operation (defined in Section 10.1 E
defined in Section 10.1 E in [SCTP] so that it applies to retransmits in [SCTP]) so that it applies to retransmits as well as transmits;
as well as transmits; that is, in PR-SCTP if the lifetime expires and that is, in PR-SCTP, if the lifetime expires and the data chunk has
the data chunk has not been acknowledged, the transmitter stops not been acknowledged, the transmitter stops retransmitting, whereas
retransmitting, whereas in the base protocol the data would be in the base protocol the data would be retransmitted until
retransmitted until acknowledged or the connection timed out. acknowledged or the connection timed out.
The format of Payload Data Chunk taken from [SCTP] is shown in the The format of Payload Data Chunk taken from [SCTP] is shown in the
following diagram. following diagram.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length | | Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN | | TSN |
skipping to change at page 19, line 40 skipping to change at page 18, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 1 (one). 'U' bit The Unordered bit. MUST be set to 1 (one).
'B' bit The Beginning fragment bit. See [SCTP]. 'B' bit The Beginning fragment bit. See [SCTP].
'E' bit The Ending fragment bit. See [SCTP]. 'E' bit The Ending fragment bit. See [SCTP].
TSN Transmission Sequence Number. See [SCTP]. TSN Transmission Sequence Number. See [SCTP].
Stream Identifier S Stream Identifier S
Identifies the context transfer protocol stream. Identifies the context transfer protocol
stream.
Stream Sequence Number n Stream Sequence Number n
Since the 'U' bit is set to one, the Since the 'U' bit is set to one, the
receiver ignores this number. See [SCTP]. receiver ignores this number. See [SCTP].
Payload Protocol Identifier Payload Protocol Identifier
Set to 'CTP' (see [IANA]). Set to 'CXTP' (see [IANA]).
User Data Contains the context transfer protocol messages. User Data Contains the context transfer protocol
messages.
If a CTP deployment will never run over the public Internet, and it If a CXTP deployment will never run over the public Internet, and it
is known that congestion is not a problem in the access network, is known that congestion is not a problem in the access network,
alternative transport protocols MAY be appropriate vehicles for alternative transport protocols MAY be appropriate vehicles for
experimentation. An example is piggybacking CTP messages on top of experimentation. For example, piggybacking CXTP messages on top of
handover signaling for routing, such as provided by FMIPv6 in ICMP handover signaling for routing, such as provided by FMIPv6 in ICMP
[FMIPv6]. Implementations of CTP MAY support ICMP for such purposes. [FMIPv6]. Implementations of CXTP MAY support ICMP for such
If such piggybacking is used, an experimental message extension for purposes. If such piggybacking is used, an experimental message
the protocol on which CTP is piggybacking MUST be designed. Direct extension for the protocol on which CXTP is piggybacking MUST be
deployment on top of a transport protocol for experimental purposes designed. Direct deployment on top of a transport protocol for
is also possible, in that case, the researcher MUST be careful to experimental purposes is also possible. In this case, the researcher
accommodate good Internet transport protocol engineering practices, MUST be careful to accommodate good Internet transport protocol
including using retransmits with exponential backoff. engineering practices, including using retransmits with exponential
backoff.
3.2 MN-AR Transport 3.2. MN-AR Transport
The MN-AR interface MUST implement and SHOULD use ICMP for transport The MN-AR interface MUST implement and SHOULD use ICMP to transport
of the CTAR and CTAA messages. Because ICMP contains no provisions the CTAR and CTAA messages. Because ICMP contains no provisions for
for retransmitting packets if signaling is lost, the CTP protocol retransmitting packets if signaling is lost, the CXTP protocol
incorporates provisions for improving transport performance on the incorporates provisions for improving transport performance on the
MN-AR interface. The MN and AR SHOULD limit the number of context MN-AR interface. The MN and AR SHOULD limit the number of context
data block identifiers included in the CTAR and CTAA messages so that data block identifiers included in the CTAR and CTAA messages so that
the message will fit into a single packet, since ICMP has no the message will fit into a single packet, because ICMP has no
provision for fragmentation above the IP level. CTP uses the provision for fragmentation above the IP level. CXTP uses the
Experimental Mobility ICMP type [IANA]. The ICMP message format for Experimental Mobility ICMP type [IANA]. The ICMP message format for
CTP messages is as follows: CXTP messages is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... | Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - - +-+-+-+-+-+-+-+-+-+-+-+- - - -
skipping to change at page 21, line 16 skipping to change at page 20, line 5
ICMP Fields: ICMP Fields:
Type Experimental Mobility Type (To be assigned by IANA, Type Experimental Mobility Type (To be assigned by IANA,
for IPv4 and IPv6, see [IANA]) for IPv4 and IPv6, see [IANA])
Code 0 Code 0
Checksum The ICMP checksum. Checksum The ICMP checksum.
Sub-type The Experimental Mobility ICMP subtype for CTP, see Sub-type The Experimental Mobility ICMP subtype for CXTP,
[IANA]. see [IANA].
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
Message The body of the CTAR or CTAA message. Message The body of the CTAR or CTAA message.
CTAR messages for which a response is requested but which fail to CTAR messages for which a response is requested but fail to elicit
elicit a response are retransmitted. The initial retransmission a response are retransmitted. The initial retransmission occurs
occurs after a CTP_REQUEST_RETRY wait period. Retransmissions MUST after a CXTP_REQUEST_RETRY wait period. Retransmissions MUST be
be made with exponentially increasing wait intervals (doubling the made with exponentially increasing wait intervals (doubling the
wait each time). CTAR messages should be retransmitted until wait each time). CTAR messages should be retransmitted until
either a response (which might be an error) has been obtained, or either a response (which might be an error) has been obtained, or
until CTP_RETRY_MAX seconds after the initial transmission. until CXTP_RETRY_MAX seconds after the initial transmission.
MNs SHOULD generate the sequence number in the CTAR message MNs SHOULD generate the sequence number in the CTAR message
randomly, and, for predictive transfer, MUST use the same sequence randomly (also ensuring that the same sequence number has not been
number in a CTAR to the nAR as for the pAR. An AR MUST ignore the used in the last 7 seconds), and, for predictive transfer, MUST
CTAR if it has already received one with the same sequence number use the same sequence number in a CTAR message to the nAR as for
and MN IP address. the pAR. An AR MUST ignore the CTAR message if it has already
received one with the same sequence number and MN IP address.
Implementations MAY, for research purposes, try other transport Implementations MAY, for research purposes, try other transport
protocols. Examples are the definition of a Mobile IPv6 Mobility protocols. Examples are the definition of a Mobile IPv6 Mobility
Header [MIPv6] for use with the FMIPv6 Fast Binding Update Header [MIPv6] for use with the FMIPv6 Fast Binding Update
[FMIPv6] to allow bundling of both routing change and context [FMIPv6] to allow bundling of both routing change and context
transfer signaling from the MN to AR, or definition of a UDP transfer signaling from the MN to AR, or definition of a UDP
protocol instead of ICMP. If such implementations are done, they protocol instead of ICMP. If such implementations are done, they
should abide carefully by good Internet transport engineering should abide carefully by good Internet transport engineering
practices and be used for prototype and demonstration purposes practices and be used for prototype and demonstration purposes
only. Deployment on large scale networks should be avoided until only. Deployment on large scale networks should be avoided until
skipping to change at page 22, line 28 skipping to change at page 21, line 26
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before CT_REQUEST_RETRY 3.2 2 seconds Wait interval before
initial retransmit initial retransmit
on MN-AR interface. on MN-AR interface.
CT_RETRY_MAX 3.2 15 seconds Give up retrying CT_RETRY_MAX 3.2 15 seconds Give up retrying
on MN-AR interface. on MN-AR interface.
5. Examples and Signaling Flows 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR, Predictive 5.1. Network Controlled, Initiated by pAR, Predictive
MN nAR pAR MN nAR pAR
| | | | | |
T | | CT trigger T | | CT trigger
I | | | I | | |
M | |<------- CTD ----------| M | |<------- CTD ----------|
E |--------CTAR--------->| | E |------- CTAR -------->| |
: | | | : | | |
| | |-------- CTDR -------->| | | |-------- CTDR -------->|
V | | | V | | |
| | | | | |
5.2 Network controlled, initiated by nAR, Reactive 5.2. Network Controlled, Initiated by nAR, Reactive
MN nAR pAR MN nAR pAR
| | | | | |
T | CT trigger | T | CT trigger |
I | | | I | | |
M | |--------- CT-Req ----->| M | |--------- CT-Req ----->|
E | | | E | | |
: | |<------- CTD ----------| : | |<------- CTD ----------|
| | | | | | | |
V |--------CTAR--------->| | V |------- CTAR -------->| |
| |----- CTDR (opt) ----->| | |----- CTDR (opt) ----->|
| | | | | |
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3. Mobile Controlled, Predictive New L2 up/Old L2 down
CTAR request to nAR CTAR request to nAR
MN nAR pAR MN nAR pAR
| | | | | |
new L2 link up | | new L2 link up | |
| | | | | |
CT trigger | | CT trigger | |
| | | | | |
T |--------CTAR ------->| | T |------- CTAR -------->| |
I | |-------- CT-Req ------>| I | |-------- CT-Req ------>|
M | | | M | | |
E | |<-------- CTD ---------| E | |<-------- CTD ---------|
: | | | : | | |
| | | | | | | |
V | | | V | | |
| | | | | |
It is for future study whether the nAR sends the MN a CTAR reject if Whether the nAR sends the MN a CTAR reject message if CT is not
CT is not supported. supported is for future study.
6. Security Considerations 6. Security Considerations
At this time, the threats to IP handover in general and context At this time, the threats to IP handover in general and context
transfer in particular are incompletely understood, particularly on transfer in particular are not widely understood, particularly on the
the MN to AR link, and mechanisms for countering them are not well MN to AR link, and mechanisms for countering them are not well
defined. Part of the experimental task in preparing CTP for eventual defined. Part of the experimental task in preparing CXTP for
standards track will be to better characterize threats to context eventual standards track will be to better characterize threats to
transfer and design specific mechanisms to counter them. This section context transfer and design specific mechanisms to counter them.
provides some general guidelines about security based on discussions This section provides some general guidelines about security based on
among the Design Team and Working Group members. discussions among the Design Team and Working Group members.
6.1. Threats. 6.1. Threats
The Context Transfer Protocol transfers state between access routers. The Context Transfer Protocol transfers state between access routers.
If the MNs are not authenticated and authorized before moving on the If the MNs are not authenticated and authorized before moving on the
network, there is a potential for masqurading attacks to shift state network, there is a potential for masquerading attacks to shift state
between ARs, causing network disruptions. between ARs, causing network disruptions.
Additionally, DoS attacks can be launched from MNs towards the access Additionally, DoS attacks can be launched from MNs towards the access
routers by requesting multiple context transfers and then routers by requesting multiple context transfers and then by
disappearing. Finally, a rogue access router could flood mobile disappearing. Finally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks, and issue bogus context nodes with packets, attempt DoS attacks, and issue bogus context
transfer requests to surrounding routers. transfer requests to surrounding routers.
Consistency and correctness in context transfer depend on Consistency and correctness in context transfer depend on
interoperable feature context definitions and how CTP is utilized for interoperable feature context definitions and how CXTP is utilized
a particular application. For some considerations regarding for a particular application. For some considerations regarding
consistency and correctness that have general applicability but are consistency and correctness that have general applicability but are
articulated in the context of AAA context transfer, please see [EAP]. articulated in the context of AAA context transfer, please see [EAP].
6.2. Access Router Considerations 6.2. Access Router Considerations
The CTP inter-router interface relies on IETF standardized security The CXTP inter-router interface relies on IETF standardized security
mechanisms for protecting traffic between access routers, as opposed mechanisms for protecting traffic between access routers, as opposed
to creating application security mechanisms. IPsec MUST be supported to creating application security mechanisms. IPsec [RFC2401] MUST be
between access routers. supported between access routers.
In order to avoid the introduction of additional latency due to the To avoid the introduction of additional latency due to the need for
need for establishment of a secure channel between the context establishing a secure channel between the context transfer peers
transfer peers (ARs), the two ARs SHOULD establish such a secure (ARs), the two ARs SHOULD establish such a secure channel in advance.
channel in advance. The two access routers need to engage in a key The two access routers need to engage in a key exchange mechanism
exchange mechanisms such as IKE [RFC2409], establish IPSec SAs, such as IKE [RFC2409], establish IPSec SAs, and define the keys,
defining the keys, algorithms and IPSec protocols (such as ESP) in algorithms, and IPSec protocols (such as ESP) in anticipation of any
anticipation for any upcoming context transfer. This will save time upcoming context transfer. This will save time during handovers that
during handovers that require secure transfer. Such SAs can be require secure transfer. Such SAs can be maintained and used for all
maintained and used for all upcoming context transfers between the upcoming context transfers between the two ARs. Security should be
two ARs. Security should be negotiated prior to the sending of negotiated prior to the sending of context.
context.
Access Routers MUST implement IPsec ESP [ESP] in transport mode with Access Routers MUST implement IPsec ESP [ESP] in transport mode with
non-null encryption and authentication algorithms to provide per- non-null encryption and authentication algorithms to provide per-
packet authentication, integrity protection and confidentiality, and packet authentication, integrity protection and confidentiality, and
MUST implement the replay protection mechanisms of IPsec. In those MUST implement the replay protection mechanisms of IPsec. In those
scenarios where IP layer protection is needed, ESP in tunnel mode scenarios where IP layer protection is needed, ESP in tunnel mode
SHOULD be used. Non-null encryption should be used when using IPSec SHOULD be used. Non-null encryption should be used when using IPSec
ESP. Strong security on the inter-router interface is required to ESP. Strong security on the inter-router interface is required to
protect against attacks by rogue routers, and to ensure protect against attacks by rogue routers, and to ensure
confidentiality on the context transfer authorization key in confidentiality on the context transfer authorization key in
predicative transfer. predicative transfer.
The details of IKE key exchange and other details of the IPsec The details of IKE key exchange and other details of the IPsec
security associations between routers are to be determined as part of security associations between routers are to be determined as part of
the research phase associated with finalizing the protocol for the research phase associated with finalizing the protocol for
standardization. Prior to standardization, these details must be standardization. These details must be determined prior to
determined. Other working groups are currently working on general standardization. Other working groups are currently working on
security for routing protocols. Ideally, a solution for CTP will be general security for routing protocols. Ideally, a possible solution
based on this work, if possible, in order to minimize operational for CXTP will be based on this work to minimize the operational
configuration of routers for different protocols. Requirements for configuration of routers for different protocols. Requirements for
CTP will be brought to the appropriate IETF routing protocol security CXTP will be brought to the appropriate IETF routing protocol
working groups for consideration. security working groups for consideration.
6.3 Mobile Node Considerations 6.3. Mobile Node Considerations
The CTAR message requires the MN and AR to possess a shared secret The CTAR message requires the MN and AR to possess a shared secret
key in order to calculate the authorization token. Validation of this key to calculate the authorization token. Validation of this token
token MUST precede context transfer or installation of context for MUST precede context transfer or installation of context for the MN,
the MN, removing the risk that an attacker could cause an removing the risk that an attacker could cause an unauthorized
unauthorized transfer. How the shared key is established is out of transfer. How the shared key is established is out of scope of this
scope of the current specification. If both the MN and AR know specification. If both the MN and AR know certified public keys of
certified public keys of the other party, Diffie-Helman can be used the other party, Diffie-Hellman can be used to generate a shared
to generate a shared secret [RFC2631]. If an AAA protocol of some secret key [RFC2631]. If an AAA protocol of some sort is run for
sort is run for network entry, the shared key can be established network entry, the shared key can be established using that protocol
using that protocol [PerkCal04]. [PerkCal04].
If predictive context transfer is used, the shared key for If predictive context transfer is used, the shared key for
calculating the authorization token is transferred between ARs. A calculating the authorization token is transferred between ARs. A
transfer of confidential material of this sort poses certain security transfer of confidential material of this sort poses certain security
risks, even if the actual transfer itself is confidential and risks, even if the actual transfer itself is confidential and
authenticated, as is the case for inter-router CTP. The more entities authenticated, as is the case for inter-router CXTP. The more
know the key, the more likely a compromise may occur. In order to entities know the key, the more likely a compromise may occur. To
mitigate this risk, nAR MUST discard the key immediately after using mitigate this risk, nAR MUST discard the key immediately after using
it to validate the authorization token. The MN MUST establish a new it to validate the authorization token. The MN MUST establish a new
key with the AR for future CTP transactions. The MN and AR SHOULD key with the AR for future CXTP transactions. The MN and AR SHOULD
exercise care in using a key established for other purposes for also exercise care in using a key established for other purposes for also
authorizing context transfer. It is RECOMMENDED that a separate key authorizing context transfer. The establishment of a separate key
be established for context transfer authorization. for context transfer authorization is RECOMMENDED.
Replay protection on the MN-AR protocol is provided by limiting the Replay protection on the MN-AR protocol is provided by limiting the
time period in which context is maintained. For predictive transfer, time period in which context is maintained. For predictive transfer,
the pAR receives a CTAR message with a sequence number, transfers the the pAR receives a CTAR message with a sequence number, transfers the
context along with the authorization token key, then drops the context along with the authorization token key, and then drops the
context and the authorization token key immediately upon completion context and the authorization token key immediately upon completion
of the transfer. For reactive transfer, the nAR receives the CTAR, of the transfer. For reactive transfer, the nAR receives the CTAR,
requests the context, including the sequence number and authorization requests the context that includes the sequence number and
token from the CTAR which allows the pAR to check whether the authorization token from the CTAR message that allows the pAR to
transfer is authorized. The pAR drops the context and authorization check whether the transfer is authorized. The pAR drops the context
token key after the transfer has been completed. The pAR and nAR and authorization token key after the transfer has been completed.
ignore any requests containing the same MN IP address if an The pAR and nAR ignore any requests containing the same MN IP address
outstanding CTAR or CTD message is unacknowledged and has not timed if an outstanding CTAR or CTD message is unacknowledged and has not
out. After the key has been dropped, any attempt at replay will fail timed out. After the key has been dropped, any attempt at replay
because the authorization token fails to validate. The AR MUST NOT will fail because the authorization token will fail to validate. The
reuse the key for any MN, including the same MN as originally AR MUST NOT reuse the key for any MN, including the MN that
possessed the key. originally possessed the key.
DoS attacks on the MN-AR interface can be limited by having the AR DoS attacks on the MN-AR interface can be limited by having the AR
rate limit the number of CTAR messages it processes. The AR SHOULD rate limit the number of CTAR messages it processes. The AR SHOULD
limit the number of CTAR messages to CT_REQUEST_RATE. If the request limit the number of CTAR messages to the CT_REQUEST_RATE. If the
exceeds this rate, the AR SHOULD randomly drop messages until the request exceeds this rate, the AR SHOULD randomly drop messages until
rate is established. The actual rate SHOULD be configured on the AR the rate is established. The actual rate SHOULD be configured on the
to match the maximum number of handovers that the access network is AR to match the maximum number of handovers that the access network
expected to support. is expected to support.
7. IANA Considerations
Instructions for IANA allocations are included in [IANA].
8. Acknowledgements & Contributors 7. 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 chairs of
Group chairs of the SeaMoby working group. The team included John the SeaMoby working group. The team included John Loughney, Madjid
Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. Nakhjiri, Rajeev Koodli and Charles Perkins.
Contributors to the Context Transfer Protocol review are Basavaraj Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the
Patil, Pekka Savola, and Antti Tuominen. Context Transfer Protocol review.
The working group chairs are Pat Calhoun and James Kempf, whose The working group chairs are Pat Calhoun and James Kempf, whose
comments have been very helpful during the creation of this comments have been very helpful in the creation of this
specification. specification.
The authors would also like to thank Julien Bournelle, Vijay The authors would also like to thank Julien Bournelle, Vijay
Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf
Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their Motiwala, Phil Neumiller, Hesham Soliman, and Lucian Suciu for their
help and suggestions with this document. help and suggestions with this document.
9. References 8. References
9.1 Normative References 8.1. Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
BCP 9, RFC 2026, October 1996. September 1981.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
ment Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
Considerations Section in RFCs", BCP 26, RFC 2434, October (IKE)", RFC 2409, November 1998.
1998.
[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
RFC 2409, November 1998. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
load (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[SCTP] Stewert, R., et. al., "Stream Control Transmission Proto- [SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
col", RFC 2960, October, 2000. Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension", [PR-SCTP] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Internet Engineering Task Force. Work in Progress. Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate [IANA] Kempf, J., "Instructions for Seamoby and Experimental
Access Router Discovery", Internet Engineering Task Force. Mobility Protocol IANA Allocations", RFC 4065, July 2005.
Work in Progress.
[IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol 8.2. Informative References
IANA Allocations", Internet Engineering Task Force. Work in
Progress.
9.2 Non-Normative References [FHCT] R. Koodli and C. E. Perkins, "Fast Handovers and Context
Transfers", ACM Computing Communication Review, volume
31, number 5, October 2001.
[CTHC] R. Koodli et al., "Context Relocation for Seamless Header [TEXT] M. Nakhjiri, "A time efficient context transfer method
Compression in IP Networks", Internet Draft, Internet with Selective reliability for seamless IP mobility",
Engineering Task Force, Work in Progress. IEEE VTC-2003-Fall, VTC 2003 Proceedings, Vol.3, Oct.
2003.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet [FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
Engineering Task Force. Work in Progress. 4068, July 2005.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", [LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile
Internet Engineering Task Force. Work in Progress. IPv4", Work in Progress.
[RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing [RFC3374] Kempf, J., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network", RFC Context Transfers Between Nodes in an IP Access Network",
3374, May 2001. RFC 3374, September 2002.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet [TERM] Manner, J. and M. Kojo, "Mobility Related Terminology",
Engineering Task Force, Work in Progress. RFC 3753, June 2004.
[RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
June, 1999. 2631, June 1999.
[PerkCal04]C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile [PerkCal04] Perkins, C. and P. Calhoun, "Authentication,
IPv4", Internet Engineering Task Force, Work in Progress. Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005.
[MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
IPv6", Internet Engineering Task Force, Work in Progress. in IPv6", RFC 3775, June 2004.
[RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Discovery (MLD) for IPv6," RFC 2710, October, 1999. Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
for IP Version 6 (IPv6)," RFC 2461, December, 1998. Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] S. Thompson, and T. Narten, "IPv6 Address Autoconfiguration," [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
RFC 2462, December, 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC3095] C. Borman, ed., "RObust Header Compression (ROHC)", RFC 3095, [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
July, 2001. H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
Header Compression (ROHC): Framework and four profiles:
RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[BT] IEEE, "IEEE Standard for information technology - Telecommuni- [BT] IEEE, "IEEE Standard for information technology -
cation and information exchange between systems - LAN/MAN - Telecommunication and information exchange between
Part 15.1: Wireless Medium Access Control (MAC) and Physical systems - LAN/MAN - Part 15.1: Wireless Medium Access
Layer (PHY) specifications for Wireless Personal Area Networks Control (MAC) and Physical Layer (PHY) specifications for
(WPANs)", IEEE Standard 802.15.1, 2002. Wireless Personal Area Networks (WPANs)", IEEE Standard
802.15.1, 2002.
[EAP] B. Aboba, D. Simon, J. Arkko, P. Eron, and H. Levokowetz, [EAP] Aboba, B., Simon, D., Arkko, J., Eron, P., and H.
"Extensible Authentication Protocol (EAP) Key Management Levokowetz, "Extensible Authentication Protocol (EAP) Key
Framework", Internet Draft, work in progress. Management Framework", Work in Progress.
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 latencies that practically prohibit its use for certain types of
services. Mobile IP latency and packet loss is being optimized services. Mobile IP latency and packet loss are optimized through
through several alternative procedures, such as Fast Mobile IP several alternative procedures, such as Fast Mobile IP [FMIPv6] and
[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
zero (optimally) or minimal extra disruption of services in conjunc- zero (optimally) or minimal extra disruption of services in
tion to handovers. This means that the timing of context transfer conjunction with handovers. This means that the timing of context
SHOULD be carefully aligned with basic Mobile IP handover events, and transfer SHOULD be carefully aligned with basic Mobile IP handover
with optimized Mobile IP handover signaling mechanisms, as those pro- events, and with optimized Mobile IP handover signaling mechanisms,
tocols become available. as those protocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms Furthermore, some of those optimized mobile IP handover mechanisms
may provide more flexibility in choosing the timing and order for may provide more flexibility in choosing the timing and ordering for
transfer of various context information. the transfer of various context information.
Appendix B. Multicast Listener Context Transfer Appendix B. Multicast Listener Context Transfer
In the past, credible proposals have been made in the Seamoby Working In the past, credible proposals have been made in the Seamoby Working
Group and elsewhere for using context transfer to speed handover of Group and elsewhere for using context transfer to the speed of
authentication, authorization, and accounting context, distributed handover of authentication, authorization, and accounting context,
firewall context, PPP context, and header compression context. distributed firewall context, PPP context, and header compression
Because the Working Group was not chartered to develop context pro- context. Because the Working Group was not chartered to develop
file definitions for specific applications, none of the drafts sub- context profile definitions for specific applications, none of the
mitted to Seamoby were accepted as Working Group items. At this time, documents submitted to Seamoby were accepted as Working Group items.
work continues to develop a context profile definition for RFC 3095 At this time, work to develop a context profile definition for RFC
header compression context [RFC3095] and to characterize the perfor- 3095 header compression context [RFC3095] and to characterize the
mance gains obtainable by using header compression, but the work is performance gains obtainable by using header compression continues,
not yet complete. In addition, there are several commercial wireless but is not yet complete. In addition, there are several commercial
products that reportedly use non-standard, non-interoperable context wireless products that reportedly use non-standard, non-interoperable
transfer protocols, though none is as yet widely deployed. context transfer protocols, though none is as yet widely deployed.
As a consequence, it is difficult at this time to point to a solid As a consequence, it is difficult at this time to point to a solid
example of how context transfer could result in a commercially example of how context transfer could result in a commercially
viable, widely deployable, interoperable benefit for wireless net- viable, widely deployable, interoperable benefit for wireless
works. This is one reason why CTP is being proposed as an Experimen- networks. This is one reason why CXTP is being proposed as an
tal protocol, rather than Standards Track. However, it nevertheless Experimental protocol, rather than Standards Track. Nevertheless, it
seems valuable to have a simple example that shows how handover could seems valuable to have a simple example that shows how handover could
benefit from using CTP. The example we consider here is transferring benefit from using CXTP. The example we consider here is
IPv6 MLD state [RFC2710]. MLD state is a particularly good example transferring IPv6 MLD state [RFC2710]. MLD state is a particularly
because every IPv6 node must perform at least one MLD messaging good example because every IPv6 node must perform at least one MLD
sequence on the wireless link to establish itself as an MLD listener messaging sequence on the wireless link to establish itself as an MLD
prior to performing router discovery [RFC2461] or duplicate address listener prior to performing router discovery [RFC2461] or duplicate
detection [RFC2462] or before sending/receiving any application- address detection [RFC2462] or before sending/receiving any
specific traffic (including Mobile IP handover signaling, if any). application-specific traffic (including Mobile IP handover signaling,
The node must subscribe to the Solicited Node Multicast Address as if any). The node must subscribe to the Solicited Node Multicast
soon as it comes up on the link. Any application-specific multicast Address as soon as it comes up on the link. Any application-specific
addresses must be re-established as well. Context transfer can signi- multicast addresses must be re-established as well. Context transfer
ficantly speed up re-establishing multicast state by allowing the nAR can significantly speed up re-establishing multicast state by
to initialize MLD for a node that just completed handover without any allowing the nAR to initialize MLD for a node that just completed
MLD signaling on the new wireless link. The same approach could be handover without any MLD signaling on the new wireless link. The
used for transferring multicast context in IPv4. same approach could be used for transferring multicast context in
IPv4.
An approximate quantitative estimate for the amount of savings in An approximate quantitative estimate for the amount of savings in
handover time can be obtained as follows. MLD messages are 24 octets, handover time can be obtained as follows: MLD messages are 24 octets,
to which the headers must be added, because there is no header to which the headers must be added, because there is no header
compression on the new link, with IPv6 header being 40 octets, and a compression on the new link, where the IPv6 header is 40 octets, and
required Router Alert Hop-by-Hop option being 8 octets including pad- a required Router Alert Hop-by-Hop option is 8 octets including
ding. The total MLD message size is 72 octets per subscribed multi- padding. The total MLD message size is 72 octets per subscribed
cast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD
messages per address subscription, since the Report message is unack- Report messages per address subscription, since the Report message is
nowledged. Assuming 2 MLD messages sent for a subscribed address, the unacknowledged. Assuming 2 MLD messages sent for a subscribed
MN would need to send 144 octets per address subscription. If MLD address, the MN would need to send 144 octets per address
messages are sent for both the All Nodes Multicast address and the subscription. If MLD messages are sent for both the All Nodes
Solicited Node Multicast address for the node's link local address, a Multicast address and the Solicited Node Multicast address for the
total of 288 octets are required when the node hands over to the new node's link local address, a total of 288 octets are required when
link. Note that some implementations of IPv6 optimize by not sending the node hands over to the new link. Note that some implementations
an MLD message for the All Nodes Multicast Address, since the router of IPv6 are optimized by not sending an MLD message for the All Nodes
can infer that at least one node is on the link (itself) when it Multicast Address, since the router can infer that at least one node
comes up and always will be, but for purposes of this calculation, we is on the link (itself) when it comes up and always will be.
assume that the IPv6 implementation is conformant and that the mes- However, for purposes of this calculation, we assume that the IPv6
sage is sent. The amount of time required for MLD signaling will, of implementation is conformant and that the message is sent. The
course, depend on the per node available wireless link bandwidth, but amount of time required for MLD signaling will depend on the per node
some representative numbers can be obtained by assuming bandwidths of available wireless link bandwidth, but some representative numbers
20 kbps or 100 kbps. With these two bit rates, the savings from not can be obtained by assuming bandwidths of 20 kbps or 100 kbps. With
having to perform the pre-router discovery messages are 115 msec. and these 2 bit rates, the savings from not having to perform the pre-
23 msec., respectively. If any application-specific multicast router discovery messages are 115 msec. and 23 msec., respectively.
addresses are subscribed, the amount of time saved could be substan- If any application-specific multicast addresses are subscribed, the
tially more. amount of time saved could be more substantial.
This example might seem a bit contrived because MLD isn't used in the This example might seem a bit contrived as MLD is not used in the 3G
3G cellular protocols and wireless local area network protocols typi- cellular protocols, and wireless local area network protocols
cally have enough bandwidth, if radio propagation conditions are typically have enough bandwidth if radio propagation conditions are
optimal, so sending a single MLD message might not be viewed as such optimal. Therefore, sending a single MLD message might not be viewed
a performance burden. An example of a wireless protocol where MLD as a performance burden. An example of a wireless protocol where MLD
context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT].
IEEE 802.15.1 has two IP "profiles": one with and one without PPP. IEEE 802.15.1 has two IP "profiles": one with PPP and one without.
The profile without PPP would use MLD. The 802.15.1 protocol has a The profile without PPP would use MLD. The 802.15.1 protocol has a
maximum bandwidth of about 800 kbps, shared between all nodes on the maximum bandwidth of about 800 kbps, shared between all nodes on the
link, so a host on a moderately loaded 802.15.1 access point could link, so a host on a moderately loaded 802.15.1 access point could
experience the kind of bandwidth described in the previous paragraph. experience the kind of bandwidth described in the previous paragraph.
In addition 802.15.1 handover times typically run upwards of a second
or more because the host must resynchronize its frequency hopping In addition, 802.15.1 handover times are typically run upwards of a
pattern with the access point, so anything the IP layer could do to second or more because the host must resynchronize its frequency
alleviate further delay would be beneficial. hopping pattern with the access point, so anything the IP layer could
do to alleviate further delay would be beneficial.
The context-specific data field for MLD context transfer included in The context-specific data field for MLD context transfer included in
the CTP Context Data Block message for a single IPv6 multicast the CXTP Context Data Block message for a single IPv6 multicast
address has the following format: address has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Subnet Prefix on nAR Wireless Interface + + Subnet Prefix on nAR Wireless Interface +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Subscribed IPv6 Multicast Address + + Subscribed IPv6 Multicast Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Subnet Prefix on nAR Wireless Interface field contains a subnet The Subnet Prefix on a nAR Wireless Interface field contains a subnet
prefix that identifies the interface on which multicast routing prefix that identifies the interface on which multicast routing
should be established. The Subscribed IPv6 Multicast Address field should be established. The Subscribed IPv6 Multicast Address field
contains the multicast address for which multicast routing should be contains the multicast address for which multicast routing should be
established. established.
The pAR sends one MLD context block per subscribed IPv6 multicast The pAR sends one MLD context block per subscribed IPv6 multicast
address. address.
No changes are required in the MLD state machine. No changes are required in the MLD state machine.
Upon receipt of a CTP Context Data Block for MLD, the state machine Upon receipt of a CXTP Context Data Block for MLD, the state machine
takes the following actions: takes the following actions:
- If the router is in the No Listeners present state on the wireless - If the router is in the No Listeners present state on the
interface on which the Subnet Prefix field in the Context Data wireless interface on which the Subnet Prefix field in the
Block is advertised, it transitions into the Listeners Present Context Data Block is advertised, it transitions into the
state for the Subscribed IPv6 Multicast Address field in the Con- Listeners Present state for the Subscribed IPv6 Multicast
text Data Block. This transition is exactly the same as if the Address field in the Context Data Block. This transition is
router had received a Report message. exactly the same as if the router had received a Report
message.
- If the router is in the Listeners present state on that interface, - If the router is in the Listeners present state on that
it remains in that state but restarts the timer, as if it had interface, it remains in that state but restarts the timer, as
received a Report message. if it had received a Report message.
If more than one MLD router is on the link, a router receiving an MLD If more than one MLD router is on the link, a router receiving an MLD
Context Data Block SHOULD send the block to the other routers on the Context Data Block SHOULD send the block to the other routers on the
link. If wireless bandwidth is not an issue, the router MAY instead link. If wireless bandwidth is not an issue, the router MAY instead
send a proxy MLD Report message on the wireless interface that send a proxy MLD Report message on the wireless interface that
advertises the Subnet Prefix field from the Context Data Block. Since advertises the Subnet Prefix field from the Context Data Block.
MLD routers do not keep track of which nodes are listening to munti- Since MLD routers do not keep track of which nodes are listening to
cast addresses, only whether a particular multicast address is being multicast addresses (only whether a particular multicast address is
listened to, proxying the subscription should cause no difficulty. 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
EMail: rajeev.koodli@nokia.com
John Loughney John Loughney
Nokia Nokia
Itdmerenkatu 11-13 Itdmerenkatu 11-13
00180 Espoo 00180 Espoo
Finland Finland
john.loughney@nokia.com
EMail: john.loughney@nokia.com
Madjid F. Nakhjiri Madjid F. Nakhjiri
Motorola Labs Motorola Labs
1031 East Algonquin Rd., Room 2240 1301 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196 Schaumburg, IL, 60196
USA USA
madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
charliep@iprg.nokia.com
Disclaimer of Validity
This document and the information contained herein are provided on an EMail: charles.perkins@.nokia.com
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY \(IF ANY\), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PURPOSE.
Intellectual Property Intellectual Property
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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specifica- such proprietary rights by implementers or users of this
tion can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
 End of changes. 

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