draft-ietf-seamoby-ctp-08.txt   draft-ietf-seamoby-ctp-09.txt 
Seamoby WG J. Loughney (editor) Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri Internet Draft M. Nakhjiri
Category: Experimental C. Perkins Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-08.txt> R. Koodli <draft-ietf-seamoby-ctp-09.txt> R. Koodli
Expires: July 21, 2004 January 21, 2004 Expires: October 13, 2004 April 14, 2004
Context Transfer Protocol Context Transfer Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026 [RFC2026]. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Copyright Notice
Copyright (C) The Internet Society 2004. All Rights Reserved. Copyright (C) The Internet Society 2004. All Rights Reserved.
Abstract Abstract
This document presents a context transfer protocol that enables This document presents a context transfer protocol that enables
authorized context transfers. Context transfers allow better support authorized context transfers. Context transfers allow better support
for node based mobility so that the applications running on mobile for node based mobility so that the applications running on mobile
nodes can operate with minimal disruption. Key objectives are to nodes can operate with minimal disruption. Key objectives are to
reduce latency, packet losses and avoiding re-initiation of signaling reduce latency, packet losses and avoiding re-initiation of signaling
to and from the mobile node. to and from the mobile node.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1 The Problem 1.1 The Problem
1.2 Conventions Used in This Document 1.2 Conventions Used in This Document
1.3 Abbreviations Used in the Document 1.3 Abbreviations Used in the Document
2. Protocol Overview 2. Protocol Overview
2.1 Context Transfer Scenarios 2.1 Context Transfer Scenarios
2.2 Context Transfer Packet Formats 2.2 Context Transfer Message Format
2.3 Context Types 2.3 Context Types
2.4 Context Data Block 2.4 Context Data Block (CTB)
2.5 Messages 2.5 Messages
3. Transport, Reliability and Retransmission of Feature Data 3. Transport
4. Open Issues 3.1 Inter-Router Transport
4.1 Failure Handling 3.2 MN-AR Transport
4. Error Codes and Constants
5. Examples and Signaling Flows 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 5.1 Network controlled, Initiated by pAR, Predictive
5.2 Network controlled, Initiated by nAR 5.2 Network controlled, Initiated by nAR, Reactive
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3 Mobile controlled, Predictive New L2 up/old L2 down
6. Security Considerations 6. Security Considerations
6.1 Threats
6.2 Access Router Considerations
6.3 Mobile Node Considerations
7. IANA Considerations 7. IANA Considerations
8. Acknowledgements 8. Acknowledgements & Contributors
9. References 9. References
9.1 Normative References 9.1 Normative References
9.2 Non-Normative References 9.2 Non-Normative References
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Appendix B. Multicast Listener Context Transfer Appendix B. Multicast Listener Context Transfer
Author's Addresses 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 overview, 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.
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) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch. An example of a protocol flows for those services from scratch. An example of a
service is included in Appendix C. service is included in Appendix B.
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.1 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.2 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 abbreviation in this document.
CTP Context Transfer Protocol CTP Context Transfer Protocol
DoS Denial-of-Service DoS Denial-of-Service
FPT Feature Profile Types FPT Feature Profile Types
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 either the new or the previous
access router ("network controlled"). access router ("network controlled").
* The mobile node sends the CT Activate Request to old AR whenever * The mobile node (MN) sends the CT Activate Request to its current
possible to initiate predictive context transfer. In any case, the access router (AR) immediately prior to handover whenever possible
MN always sends the CTAR message to new AR. If the contexts are to initiate predictive context transfer. In any case, the MN
already present, nAR would verify the authorization token present always sends the CTAR message to new AR (nAR). If the contexts are
in CTAR with its own computation (using the parameters supplied by already present, nAR verifies the authorization token present in
pAR), and subsequently activate those contexts. If the contexts CTAR with its own computation using the parameters supplied by the
are not present, nAR requests pAR to supply them using the Context previous access router (pAR), and subsequently activates those
Transfer Request message, in which it supplies the authorization contexts. If the contexts are not present, nAR requests pAR to
token present in CTAR. supply them using the Context Transfer Request message, in which
it supplies the authorization token present in CTAR.
* Either nAR or pAR may request or start (respectively) context * * Either nAR or pAR may request or start (respectively) context
transfer based on internal or network triggers (see Appendix B). transfer based on internal or network triggers (see Appendix 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 Previous Access Router (pAR) and Typically, the source node is a MN's pAR and the target node is MN's
the target node is MN's New Access Router (nAR). Context Transfer nAR. Context Transfer takes place when an event, such as a handover,
takes place when an event, such as a handover, takes place. We call takes place. We call such an event a Context Transfer Trigger. In
such an event a Context Transfer Trigger. In response to such a response to such a trigger, the pAR may transfer the contexts; the
trigger, the pAR may transfer the contexts; the nAR may request nAR may request contexts; and the MN may send a message to the
contexts; and the MN may send a message to the routers to transfer routers to transfer contexts. Such a trigger must be capable of
contexts. Such a trigger must be capable of providing the necessary providing the necessary information (such as the MN's IP address) by
information, such as the MN's IP address with which the contexts are which the contexts are identified, the IP addresses of the access
associated, the IP addresses of the access routers, and authorization routers, and authorization to transfer context.
to transfer context.
Context transfer protocol messages use Feature Profile Types that Context transfer protocol messages use Feature Profile Types (FPTs)
identify the way that data is organized for the particular feature that identify the way that data is organized for the particular
contexts. The Feature Profile Types (FPTs) are registered in a number feature contexts. The FPTs are registered in a number space (with
space (with IANA Type Numbers) that allows a node to unambiguously IANA Type Numbers) that allows a node to unambiguously determine the
determine the type of context and the context parameters present in type of context and the context parameters present in the protocol
the protocol messages. Contexts are transferred by laying out the messages. Contexts are transferred by laying out the appropriate
appropriate feature data within Context Data Blocks according to the feature data within Context Data Blocks according to the format in
format in section 2.3, as well as any IP addresses necessary to Section 2.3, as well as any IP addresses necessary to associate the
associate the contexts to a particular MN. The context transfer contexts to a particular MN. The context transfer initiation messages
initiation messages contain parameters that identify the source and contain parameters that identify the source and target nodes, the
target nodes, the desired list of feature contexts and IP addresses desired list of feature contexts and IP addresses to identify the
to identify the contexts. The messages that request transfer of contexts. The messages that request transfer of context data also
context data also contain an appropriate token to authorize the contain an appropriate token to authorize the context transfer.
context transfer.
Performing context transfer in advance of the MN attaching to nAR can Performing context transfer in advance of the MN attaching to nAR can
increase handover performance. For this to take place, certain increase handover performance. For this to take place, certain
conditions must be met. For example, pAR must have sufficient time conditions must be met. For example, pAR must have sufficient time
and knowledge about the impending handover. This is feasible, for and knowledge about the impending handover. This is feasible, for
instance, in Mobile IP fast handovers. Additionally, many cellular instance, in Mobile IP fast handovers [LLMIP][FMIPV6]. Additionally,
networks have mechanisms to detect handovers in advance. However, many cellular networks have mechanisms to detect handovers in
when the advance knowledge of impending handover is not available, or advance. However, when the advance knowledge of impending handover is
if a mechanism such as fast handover fails, retrieving feature not available, or if a mechanism such as fast handover fails,
contexts after the MN attaches to nAR is the only available means for retrieving feature contexts after the MN attaches to nAR is the only
context transfer. Performing context transfer after handover might available means for context transfer. Performing context transfer
still be better than having to re-establish all the contexts from after handover might still be better than having to re-establish all
scratch. Finally, some contexts may simply need to be transferred the contexts from scratch. Finally, some contexts may simply need to
during handover signaling. For instance, any context that gets be transferred during handover signaling. For instance, any context
updated on a per-packet basis must clearly be transferred only after that gets updated on a per-packet basis must clearly be transferred
packet forwarding to the MN on its previous link is terminated. only after packet forwarding to the MN on its previous link is
terminated.
The messages (CTD and CTDR) that perform the context transfer between
the access routers need to be authenticated, so that the access
routers can be certain that the data has not been tampered with
during delivery.
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 may receive a Context Transfer Activate Request (CTAR) The pAR receives a Context Transfer Activate Request (CTAR) message
message from the MN whose feature contexts are to be transferred, or from the MN whose feature contexts are to be transferred, or it
it receives an internally generated trigger (e.g., a link-layer receives an internally generated trigger (e.g., a link-layer trigger
trigger on the interface to which the MN is connected). The CTAR on the interface to which the MN is connected). The CTAR message,
message, described in Section 2.5, provides the IP address of nAR, described in Section 2.5, provides the IP address of nAR, the IP
the IP address of MN on pAR, the list of feature contexts to be address of MN on pAR, the list of feature contexts to be transferred
transferred (by default requesting all contexts to be transferred), (by default requesting all contexts to be transferred), and a token
and a token authorizing the transfer. It also includes the MN's new authorizing the transfer. In response to a CT-Activate Request
IP address (valid on nAR) whenever it is known. In response to a CT- message or to the CT trigger, pAR predictively transmits a Context
Activate Request message or to the CT trigger, pAR predictively Transfer Data (CTD) message that contains feature contexts. This
transmits a Context Transfer Data (CTD) message that contains feature message, described in Section 2.5, contains the MN's previous IP
contexts. This message, described in Section 2.5, contains the MN's address. It also contains parameters for nAR to compute an
previous IP address and its new IP address (if known). It also authorization token to verify the MN's token present in CTAR message.
contains parameters for nAR to compute an authorization token to Recall that the MN always sends CTAR message to nAR regardless of
verify the MN's token present in CTAR message. Recall that the MN whether it sent the CTAR message to pAR. The reason for this is that
always sends CTAR message to nAR regardless of whether it sent the there is no means for the MN to ascertain that context transfer
CTAR message to pAR. The reason for this is that there is no means reliably took place. By always sending the CTAR message to nAR, the
for the MN to ascertain that context transfer reliably took place. By Context Transfer Request (see below) can be sent to pAR if necessary.
always sending the CTAR message to nAR, the Context Transfer Request
(see below) can be sent to pAR whenever 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 at
nAR when the MN attaches to it improves performance and increases 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 highly likely to be present already.
Token verification takes place at the router possessing the contexts. Token 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-
Request), described in Section 2.5, message from nAR. The nAR itself Req), described in Section 2.5, message from nAR. The nAR itself
generates the CT Request message either as a result of receiving the generates the CT-Req message as a result of receiving the CTAR
CTAR message or as a response to an internal trigger (that indicates message, or, alternatively, from receiving a context transfer
the MN's attachment). In the CT- Req message, nAR supplies the MN's trigger. In the CT-Req message, nAR supplies the MN's previous IP
previous IP address, the feature contexts to be transferred, and a address, the FPTs for the feature contexts to be transferred, the
token (generated by the MN) authorizing context transfer. In response sequence number from the CTAR, and the authorization token from the
to CT Request message, pAR transmits a Context Transfer Data (CTD) CTAR. In response to CT-Req message, pAR transmits a Context Transfer
message that includes the MN's previous IP address and feature Data (CTD) message that includes the MN's previous IP address and
contexts. When it receives a corresponding CTD message, nAR may feature contexts. When it receives a corresponding CTD message, nAR
generate a CTD Reply message to report the status of processing the may generate a CTD Reply (CTDR) message to report the status of
received contexts. processing the received contexts. The nAR installs the contexts once
it has received them from the pAR.
When contexts are transferred reactively, the pAR verifies
authorization token before transmitting the contexts, and hence the
key the key is not needed in the CTD message.
2.2 Context Transfer Packet Format 2.2 Context Transfer Message Format
The packet consists of a message specific header and one or more data A CTP message consists of a message-specific header and one or more
packets. Data packets may be bundled together in order to ensure a data blocks. Data blocks may be bundled together in order to ensure
more efficient transfer. The total packet size, including transport a more efficient transfer. On the inter-AR interface, SCTP is used
protocol and IP protocol headers SHOULD be less than the path MTU, in so fragmentation should not be a problem. On the MN-AR interface, the
order to avoid packet fragmentation. total packet size, including transport protocol and IP protocol
headers SHOULD be less than the path MTU, in order to avoid packet
fragmentation. Each message contains a three bit version number field
in the low order octet, along with the 5 bit message type code. This
specification only applies to Version 1 of the protocol, and the
therefore version number field MUST be set to 0x1. If future
revisions of the protocol make binary incompatible changes, the
version number number MUST be incremented.
2.3 Context Types 2.3 Context Types
Contexts are identified by context type of Feature Profile Type Contexts are identified by FPT code, which is a 16-bit unsigned
(FPT), which is a 15-bit number. The meaning of each context type is integer. The meaning of each context type is determined by a
determined by a specification document and the context type numbers specification document and the context type numbers are to be
are to be tabulated in a registry maintained by IANA, and handled tabulated in a registry maintained by IANA [IANA], and handled
according to the message specifications in this document. The according to the message specifications in this document. The
instantiation of each context by nAR is determined by the messages in instantiation of each context by nAR is determined by the messages in
this document along with the specification associated with the this document along with the specification associated with the
particular context type. Each such context type specification particular context type. The following diagram illustrates the
contains the following details: general format for CTP messages:
+----------------------+ +----------------------+
| Message Header | | Message Header |
+----------------------+ +----------------------+
| CTP Data 1 | | CTP Data 1 |
+----------------------+ +----------------------+
| CTP Data 2 | | CTP Data 2 |
+----------------------+ +----------------------+
| ... | | ... |
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 which embodies the context.
- Default values (if any) for each individual datum of the - Default values (if any) for each individual datum of the
context state vector. context state vector.
- Procedures and requirements for creating a context at a new - Procedures and requirements for creating a context at a new
access router, given the data transferred from a previous access router, given the data transferred from a previous
access router, and formatted according to the ordering rules access router, and formatted according to the ordering rules
and date field sizes presented in the specification. and date field sizes presented in the specification.
- If possible, status codes for success or failure related to the - If possible, status codes for success or failure related to the
context transfer. For instance, a QoS context transfer might context transfer. For instance, a QoS context transfer might
have different status codes depending on which elements of the have different status codes depending on which elements of the
context data failed to be instantiated at nAR. context data failed to be instantiated at nAR.
2.4 Context Data Block 2.4 Context Data Block (CTB)
The Context Data Block is used both for request and response The Context Data Block (CTB) is used both for request and response
operation. When a particular feature request is constructed, only the operation. When a request is constructed, only the first 4 bytes are
first 4 bytes are typically necessary (See CTAR below). When used for typically necessary (See CTAR below). When used for transferring the
the actual feature context itself, the context data is present, and actual feature context itself, the context data is present, and
sometimes the presence vector is present. sometimes the presence vector is present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cxt-Type | Length |P| Feature Profile Type (FTP) | | Feature Profile Type (FTP) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) | | Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ Data ~
+ data +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cxt-Type Single octet, defined by IANA
Length message length in units of 8 Feature Profile Type
octet words 16 bit integer, assigned by IANA,
indicating the type of data
included in the Data field
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.
FPT 16 bit integer, listing the feature profile Reserved Reserved for future use. Set to
type contained in the data field. zero by the sender.
data Context type-dependent data, whose length Data Context type-dependent data, whose
is defined by the Length Field. If the data length is defined by the Length
is not 64-bit aligned, the data field is Field. If the data is not 64-bit
aligned, the data field is
padded with zeros. padded with zeros.
The Cxt-Type indicates the type of the feature context message itself The Feature Profile Type (FPT) code indicates the type of data in the
(such as QoS Context Request, QoS Context Transfer etc.), and Feature data field. Typically, this will be context data but it might be an
Profile Type (FPT) identifies the way the particular feature context error indication. The 'P' bit, which is the high order bit in the
is organized. The 'P' bit specifies whether or not the "presence Length field, specifies whether or not the "presence vector" is used.
vector" is used. When the presence vector is in use, the Presence When the presence vector is in use, the Presence Vector 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 containing 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. regardless of the size of the data field. The Length field indicates
the size of the CTB in 8 octet words including the first 4 bytes
The Length field indicates the size of the CDB in 8 octets including starting from FPT.
the first 4 bytes starting from Cxt-Type.
Cxt-Type = 0 is reserved for a general error message. The data field
contains error codes information, and is defined by in specific
context types.
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 lengths of each data field specified by the context type
specification, plus 4 bytes if the 'P' bit is set, minus the specification, plus 4 bytes if the 'P' bit is set, minus the
accumulated size of all the context data that is implicitly given accumulated size of all the context data that is implicitly given as
as a default value. a default value.
2.5 Messages 2.5 Messages
In this section, a list of the available context transfer message In this section, the CTP messages are defined. The MN for which
types is given, along with a brief description of their functions. In context transfer protocol operations are undertaken is always
addition, the CTAR message also contains either the Previous Router's identified by its previous IP access address. At any time, only one
IP address or the New Router's IP address. context transfer operation per MN may be in progress so that the CTDR
message unambiguously identifies which CTD message is acknowledged
The Mobile Node, for which context transfer protocol operations are simply by including the MN's identifying previous IP address. The 'V'
undertaken, is always identified by its previous IP access address. flag indicates whether the IP addresses are IPv4 or IPv6.
At any one time, only one context transfer operation per MN may be in
progress so that the CTDR message unambiguously identifies which CTD
message is acknowledged simply by including the mobile node's
identifying previous IP address.
The 'V' flag indicates whether the MN's previous address is IPv4
only, IPv6 only or both addresses are present. See below.
2.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 MN to nAR to request context transfer.
activation. Even when the MN does not know whether or not contexts Even when the MN does not know if contexts need to be transferred,
are present, the MN sends CTAR message to gain access with nAR. If an the MN sends the CTAR message. If an acknowledgement for this message
acknowledgement for this message is needed, the MN sets the A flag to is needed, the MN sets the 'A' flag to 1; otherwise the MN does not
1, otherwise the MN does not expect an acknowledgement. This message expect an acknowledgement. This message may include a list of FPTs
may include a list of FPT (feature profile types) that require that require transfer.
transfer. It may include flags to request reliable transfer.
The MN may also send this message to pAR while still connected to The MN may also send this message to pAR while still connected to
pAR. In such a case, the MN includes the nAR's IP address and its new pAR. In such a case, the MN includes the nAR's IP address; otherwise,
IP address (if known) rather than previous IP address and pAR's IP if the message is sent to nAR, the pAR address is sent. The MN MUST
address. If the new IP address is not known, then its previous IP set the sequence number to the same value for the message sent on
address is used. both pAR and nAR so pAR can determine whether to use a cached
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTAR | Length | V |A| Reserved | |Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous (New) IP Address | ~ MN's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous (New) Router IP Address | ~ Previous (New) AR IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTAR = 1 Vers. Version number of CTP protocol = 0x1
Length message length in units of 8 Type CTAR = 0x1
octet words
MN's IP Address Field contains either: 'V' flag When set to '0', IPv6 addresses.
IPv4 Address as defined in [RFC 791]. When set to '1', IPv4 addresses.
IPv6 Address as defined in [RFC 2373].
nAR / pAR IP Address Field contains either: 'A' bit If set, the MN requests an
IPv4 Address as defined in [RFC 791]. acknowledgement.
IPv6 Address as defined in [RFC 2373].
Reserved Reserved for future use. Must be set to zero Reserved Set to zero by the sender, ignored by
by the MN. the receiver.
'V' flag When set to '00', indicate presence of IPv6 Length Message length in units of bytes.
Previous (New) address only.
When set to '01' indicate presence of IPv4
Previous (New) Address only.
When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
'A' bit The MN requests an acknowledgement. MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791],
4 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
Replay A value used to make sure that each use of the nAR / pAR IP Address Field contains either:
CTAR message is uniquely identifiable. IPv4 Address as defined in [RFC 791],
4 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
Authorization Token An unforgeable value calculated as discussed Sequence Number A value used to identify requests and
below. This authorizes the receiver of CTAR acknowledgements (see Section 3.2).
to perform context transfer.
Context Block Variable length field defined in section 2.4. Authorization Token An unforgeable value calculated as
discussed below. This authorizes the
receiver of CTAR to perform context
transfer.
If no context types are specified, then all contexts for the mobile Context Block Variable length field defined in
node are requested. When 'V' is 10, the IPv4 address MUST precede the Section 2.4.
IPv6 address both for the MN and the access router. Since Context
Types clearly define the context including the IP version, context If no context types are specified, all contexts for the MN are
enumeration need not be in any strict order, although it might be requested.
natural to outline all the IPv4 contexts followed by IPv6 contexts.
The Authorization Token is calculated as: The Authorization Token is calculated as:
First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context First (32, HMAC_SHA1
Types))), where Key is the shared secret between the MN and pAR, (Key, (Previous IP address | Sequence Number| CTBs)))
and Context Types includes all the desired contexts for which the
transfer is desired. In the default scenario, the MN implicitly where Key is a shared secret between the MN and pAR, and CTBs is a
(i.e., even without the knowledge of contexts being present) or concatenation of all the Context Data Blocks specifying the contexts
explicitly requests transfer of all contexts. to be transfered which 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, depending
on whether the MN requested it. This message may include a list of on whether the MN requested it. This message may include a list of
FPT (feature profile types) that were not transferred successfully. FPTs that were not transferred successfully.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTAA | Length | V | Reserved | |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTAR = 2 Vers. Version number of CTP protocol = 0x1
Length message length in units of 8 Type CTAA = 0x2
octet words
Reserved Reserved for future use. Must be set to 'V' flag When set to '0', IPv6 addresses.
zero by the sender of CTAA Message, i.e. When set to '1', IPv4 addresses.
pAR or nAR.
'V' flag When set to '00', indicate presence of IPv6 Reserved Set to zero by the sender and ignored by
Previous (New) address only. the receiver.
When set to '01' indicate presence of IPv4
Previous (New) Address only.
When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
MN's Prev IP Address Field contains either: Length Message length in units of bytes.
IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373].
FPT 16 bit integer, listing the FTP that was not MN's Previous IP Address Field contains either:
Successfully transferred. IPv4 Address as defined in [RFC 791],
4 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
FPT 16 bit unsigned integer, listing the FTP
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 2.5.3 Context Transfer Data (CTD) Message
Sent by pAR to nAR, and includes feature data (CTP data). This Sent by pAR to nAR, and includes feature data (CTP data). This
message should handle predictive as well as normal CT. An message handles predictive as well as normal CT. An acknowledgement
acknowledgement flag, A, included in this message indicates whether a flag, 'A', included in this message indicates whether a reply is
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=(P)CTD | Length | V |A| Reserved | |Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) | | Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | ~ Mobile Node's Previous Care-of Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's New Care-of Address, when Type=PCTD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Algorithm | Key Length | | Algorithm | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD
| Key | only | Key | only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
| First Context Data Block | ~ First Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Context Data Block | ~ Next Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | ~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTD = 3 (Context Transfer Data) Vers. Version number of CTP protocol = 0x1
PCTD = 4 (Predictive Context Transfer Data)
'V' flag When set to '00', indicate presence of IPv6 Type CTD = 0x3 (Context Transfer Data)
Previous (New) address only. PCTD = 0x4 (Predictive Context Transfer
When set to '01' indicate presence of IPv4 Data)
Previous (New) Address only.
When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
'A' bit The MN requests an acknowledgement. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
Length message length in units of 8 'A' bit When set, the pAR requests an
octet words acknowledgement.
Reserved Reserved for future use. Must be set to Length Message length in units of bytes.
zero by the pAR.
Elapsed Time The number of milliseconds since the Elapsed Time The number of milliseconds since the
transmission of the first CTD message. transmission of the first CTD message for
this MN.
MN's Prev CoA Address Field contains either:
IPv4 Address as defined in [RFC 791],
IPv6 Address as defined in [RFC 2373].
MN's New CoA Address Field contains either:
MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
IPv6 Address as defined in [RFC 2373]. 4 octets.
This is only applicable for the PCTD IPv6 Address as defined in [RFC 2373],
message. 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.
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, allow nAR to compute a algorithm, key length and the key itself, allowing nAR to compute a
token locally and verify against the token present in the CTAR token locally and verify against the token present in the CTAR
message. This message MUST be protected by IPsec. message. This material is also sent if the pAR receives a CTD
message with a null Authorization Token, indicating that the CT-Req
message has been sent before the nAR received the CTAR message. CTD
MUST 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 input computation of the MN Authorization Token is HMAC_SHA1. The token
data for computing the token are: the MN's Previous IP address, the authentication calculation algorithm is described in Section 2.5.1.
FPT objects and the Replay field. When support for transferring all
contexts is requested, a default FPT is used. The Authorization Token For predictive handover, the pAR SHOULD keep track of the CTAR
is obtained by truncating the results of the HMAC_SHA1 computation to sequence number and cache the CTD message until receiving either a
retain only the leading 32 bits. CTDR message for the MN's previous IP address from the pAR,
indicating that the context transfer was successful, or until
CT_MAX_HANDOVER_TIME expires. The nAR MAY send a CT-Req message
containing the same sequence number if the predictive CTD message
failed to arrive or the context was corrupted, In that case, the nAR
sends a CT-Req message with a matching sequence number and pAR can
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 This message is sent by nAR to pAR depending on the value of the 'A'
reliability flag in CTD. Indicates success or failure. flag in CTD. Indicates success or failure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTDR | Length | V |S| Reserved | |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....... | ~ ....... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTDR = 5 (Context Transfer Data) Vers. Version number of CTP protocol = 0x1
Length Message length in units of 8
octet words
'V' flag When set to '00', indicate presence of IPv6
Previous address only.
When set to '01' indicate presence of IPv4 Type CTDR = 0x5 (Context Transfer Data)
Previous Address only. 'V' flag When set to '0', IPv6 addresses.
When set to '10' indicate presence of both When set to '1', IPv4 addresses.
IPv6 and IPv4 Previous addresses.
'S' bit When set to one, this bit indicates that all 'S' bit When set to one, this bit indicates
the feature contexts sent in CTD or PCTD were that all feature contexts sent in CTD
received successfully. or PCTD were received successfully.
Reserved Reserved for future use. Must be set to zero Reserved Set to zero by the sender and ignored by
by the nAR. the receiver.
MN's Prev IP Address Field contains either: Length Message length in units of bytes.
IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373].
Status Code A context-specific return value, present MN's Previous IP Address Field contains either:
when 'S' is not set to one. IPv4 Address as defined in [RFC 791],
4 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
FPT 16 bit integer, listing the FTP that is being Status Code A context-specific return value,
acknowledged. zero for success, nonzero when 'S' is
not set to one.
Status Code 0 = not successfully transfered FPT 16 bit unsigned integer, listing the FTP
1 = successfully transfered that is being acknowledged.
2.5.5 Context Transfer Cancel (CTC) Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTC | Length | Reserved | |Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | ~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTC = 6 (Context Transfer Data) Vers. Version number of CTP protocol = 0x1
Length Message length in units of 8 Type CTC = 0x6 (Context Transfer Cancel)
octet words
Reserved Reserved for future use. Must be set to zero Length Message length in units of bytes.
by the nAR.
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored by
the receiver.
MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791],
4 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 Request) Message
Sent by nAR to pAR to request start of context transfer. This message Sent by nAR to pAR to request start of context transfer. This message
is sent as a response to CTAR message by the MN. The fields following is sent as a response to CTAR message from the MN. The fields
the Previous IP address of the MN are included verbatim from the CTAR following the Previous IP address of the MN are included verbatim
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTREQ | Length | V | Reserved | |Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP Address | ~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token | | MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) | ~ Next Requested Context Data Block (if present) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | ~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CTREQ = 7 Vers. Version number of CTP protocol = 0x1
Length Message length in units of 8 Type CTREQ = 0x7 (Context Transfer Request)
octet words
'V' bits When set to '00', indicate presence of IPv6 'V' flag When set to '0', IPv6 addresses.
Previous (New) address only. When set to '1', IPv4 addresses.
When set to '01' indicate presence of IPv4
Previous (New) Address only.
When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
Reserved Reserved for future use. Must be set to zero Reserved Set to zero by the sender and ignored
by the nAR. by the receiver.
Replay A value used to make sure that each use of the Length Message length in units of bytes.
CTAR message is uniquely identifiable.
Copied from CTAR.
Authorization Token An unforgeable value calculated as discussed MN's Previous IP Address Field contains either:
above. This authorizes the receiver of CTAR IPv4 Address as defined in [RFC 791],
to perform context transfer. Copied from 4 octets.
IPv6 Address as defined in [RFC 2373],
16 octets.
Sequence Number Copied from the CTAR message, allows the
pAR to distinguish requests for previously
sent context.
MN's Authorization Token
An unforgeable value calculated as
discussed in Section 2.5.1. This
authorizes the receiver of CTAR to
perform context transfer. Copied from
CTAR. CTAR.
3. Transport, Reliability and Retransmission of Feature Data Context Data Request Block
A request block for context data, see
Section 2.4.
CTP runs over UDP using port number <TBD>. Some feature contexts may The sequence number is used by pAR to correlate a request for
specify a reliability factor, MAX_RETRY_INTERVAL, which is the length previously transmitted context. In predictive transfer, if the MN
of time that the pAR is allowed to perform retransmissions before sends CTAR prior to handover, pAR pushes context to nAR using CTD. If
giving up on the context transfer for that feature context. The the CTD fails, the nAR will send CT-Req with the same sequence
longer the allowed retry interval, the more retransmissions will be number, allowing the pAR to distinguish which context to resend. pAR
possible for that feature context. drops the context after CTP_MAX_TRANSFER_TIME. The sequence number is
not used in reactive transfer.
For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD For predictive transfer the pAR sends the keying material and other
retransmit an unacknowledged CTD message after waiting for information necessary to calculate the Authorization Token, with no
RETRANSMISSION_DELAY milliseconds. This time value is configurable CT-Req message necessary. For reactive transfer, if the nAR receives
based on the type of network interface; slower network media a context transfer trigger but has not yet received the CTAR message
naturally will be configured with longer values for the with the authorization token, the Authorization Token field in CT-Req
RETRANSMISSION_DELAY. Except for the value of the elapsed time field, is set to zero. The pAR interprets this as an indication to include
the payload of each retransmitted CTD packet is identical to the the keying material and other information necessary to calculate the
payload of the initially transmitted CTD packet, in order to maintain Authorization Token, and includes this material into the CTD message
the ability of the mobile device to present a correctly calculated as if the message were being sent due to predictive transfer. This
authentication token. The number of retransmissions, each delayed by provides nAR with the information it needs to calculate the
RETRANSMISSION_DELAY, depends on the maximum value for authorization token when the MN sends CTAR.
MAX_RETRY_INTERVAL as specified by any of the contexts. The value
of the Elapsed Time field is the number of milliseconds since the
transmission of the first CTD message
UDP provides an optional checksum, which SHOULD be checked. If the 3. Transport
checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with
the status value BAD_UDP_CHECKSUM, even if the 'A' bit is not set in
the CTD.
4. Error Codes 3.1 Inter-Router Transport
This section lists error codes used by UDP Since the types of access networks in which CTP might be useful are
not today deployed or, if they have been deployed, have not been
extensively measured, it is difficult to know whether congestion will
be a problem for CTP. Part of the research task in preparing CTP for
consideration as a candidate for possible standardization is to
quantify this issue. However, in order to avoid potential
interference with production applications should a prototype CTP
deployment involve running over the public Internet, it seems prudent
to recommend a default transport protocol that accommodates
congestion. In addition, since the feature context information has a
definite lifetime, the transport protocol must accommodate flexible
retransmission, so stale contexts that are held up by congestion are
dropped. Finally, because the amount of context data can be
arbitrarily large, the transport protocol should not be limited to a
single packet, or require implementing a custom fragmentation
protocol.
BAD_UDP_CHECKSUM 0x01 These considerations argue that implementations of CTP MUST support
and prototype deployments of CTP SHOULD use Stream Control Transport
Protocol (SCTP) [SCTP] for the transport protocol on the inter-router
interface, especially if deployment over the public Internet is
contemplated. SCTP supports congestion control, fragmentation, and
partial retransmission based on a programmable retransmission timer.
SCTP also supports many advanced and complex features, such as
multiple streams and multiple IP addresses for failover, that are not
necessary for experimental implementation and prototype deployment of
CTP. In this specification, the use of such SCTP features is not
recommended at this time.
The SCTP Payload Data Chunk carries the context transfer protocol
messages. The User Data part of each SCTP message contains an
appropriate context transfer protocol message defined in this
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
general, each SCTP message can carry feature contexts belonging to
any MN. If the SCTP checksum calculation fails, the nAR returns the
BAD_CHECKSUM error code in a CTDR message.
A single stream is used for context transfer without in-sequence
delivery of SCTP messages. Each message, unless fragmented,
corresponds to a single MN's feature context collection. A single
stream provides simplicity. Use of multiple streams to prevent head-
of-line blocking is for future study. Having unordered delivery
allows the receiver to not block for in-sequence delivery of messages
that belong to different MNs. The Payload Protocol Identifier in the
SCTP header is 'CTP'. Inter-router CTP uses the Seamoby SCTP port
[IANA].
Timeliness of the context transfer information SHOULD be accommodated
by setting the SCTP maximum retransmission value to
CT_MAX_TRANSFER_TIME in order to accommodate the maximum acceptable
handover delay time, and the AR SHOULD be configured with
CT_MAX_TRANSFER_TIME to accommodate the particular wireless link
technology and local wireless propagation conditions. SCTP message
bundling SHOULD be turned off in order to reduce any extra delay in
sending messages. Within CTP, the nAR SHOULD estimate the retransmit
timer from the receipt of the first fragment of a CTP message and
avoid processing any IP traffic from the MN until either context
transfer is complete or the estimated retransmit timer expires. If
both routers support PR-SCTP [PR-SCTP], then PR-SCTP SHOULD be used.
PR-SCTP modifies the lifetime parameter of the Send() operation
defined in Section 10.1 E in [SCTP] so that it applies to retransmits
as well as transmits; that is, in PR-SCTP if the lifetime expires and
the data chunk has not been acknowledged, the transmitter stops
retransmitting, whereas in the base protocol the data would be
retransmitted until acknowledged or the connection timed out.
The format of Payload Data Chunk taken from [SCTP] is shown in the
following diagram.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Data (seq n of Stream S) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 1 (one).
'B' bit The Beginning fragment bit. See [SCTP].
'E' bit The Ending fragment bit. See [SCTP].
TSN Transmission Sequence Number. See [SCTP].
Stream Identifier S
Identifies the context transfer protocol stream.
Stream Sequence Number n
Since the 'U' bit is set to one, the
receiver ignores this number. See [SCTP].
Payload Protocol Identifier
Set to 'CTP' (see [IANA]).
User Data Contains the context transfer protocol messages.
If a CTP deployment will never run over the public Internet, and it
is known that congestion is not a problem in the access network,
alternative transport protocols MAY be appropriate vehicles for
experimentation. An example is piggybacking CTP messages on top of
handover signaling for routing, such as provided by FMIPv6 in ICMP
[FMIPv6]. Implementations of CTP MAY support ICMP for such purposes.
If such piggybacking is used, an experimental message extension for
the protocol on which CTP is piggybacking MUST be designed. Direct
deployment on top of a transport protocol for experimental purposes
is also possible, in that case, the researcher MUST be careful to
accommodate good Internet transport protocol engineering practices,
including using retransmits with exponential backoff.
3.2 MN-AR Transport
The MN-AR interface MUST implement and SHOULD use ICMP for transport
of the CTAR and CTAA messages. Because ICMP contains no provisions
for retransmitting packets if signaling is lost, the CTP protocol
incorporates provisions for improving transport performance on the
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
the message will fit into a single packet, since ICMP has no
provision for fragmentation above the IP level. The ICMP message
format for CTP messages is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
Source Address An IP address assigned to the sending
interface.
Destination Address
An IP address assigned to the receiving
interface.
Hop Limit 255
ICMP Fields:
Type Seamoby Type (To be assigned by IANA,
for IPv4 and IPv6, see [IANA])
Code 1
Checksum The ICMP checksum.
Reserved Set to zero by the sender and ignored by
the receiver.
Message The body of the CTAR or CTAA message.
CTAR messages for which a response is requested but which fail to
elicit a response are retransmitted. The initial retransmission
occurs after a CTP_REQUEST_RETRY wait period. Retransmissions MUST
be made with exponentially increasing wait intervals (doubling the
wait each time). CTAR messages should be retransmitted until
either a response (which might be an error) has been obtained, or
until CTP_RETRY_MAX seconds after the initial transmission.
MNs SHOULD generate the sequence number in the CTAR message
randomly, and, for predictive transfer, MUST use the same sequence
number in a CTAR to the nAR as for the pAR. An AR MUST ignore the
CTAR if it has already received one with the same sequence number
and MN IP address.
Implementations MAY, for research purposes, try other transport
protocols. Examples are the definition of a Mobile IPv6 Mobility
Header [MIPv6] for use with the FMIPv6 Fast Binding Update
[FMIPv6] to allow bundling of both routing change and context
transfer signaling from the MN to AR, or definition of a UDP
protocol instead of ICMP. If such implementations are done, they
should abide carefully by good Internet transport engineering
practices and be used for prototype and demonstration purposes
only. Deployment on large scale networks should be avoided until
the transport characteristics are well understood.
4. Error Codes and Constants
Error Code Section Value Meaning
------------------------------------------------------------
BAD_CHECKSUM 3.1 0x01 Error code if the
SCTP checksum fails.
Constant Section Default Value Meaning
--------------------------------------------------------------------
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of
sec. CTAR messages before
AR institutes rate
limiting.
CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time
pAR should wait before
aborting the transfer.
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CT_RETRY_MAX 3.2 15 seconds Give up retrying
on MN-AR interface.
5. Examples and Signaling Flows 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 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 in 0 5.2 Network controlled, initiated by nAR, Reactive
in 6
MN nAR pAR MN nAR pAR
| | | | | |
T | CT trigger | T | CT trigger |
I | | | I | | |
M | |----- CT Request ----->| 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 Request ------>| I | |-------- CT-Req ------>|
M | | | M | | |
E | |<-------- CTD ---------| E | |<-------- CTD ---------|
: | | | : | | |
| | | | | | | |
V | | | V | | |
| | | | | |
In case CT cannot be supported, a CTAR reject (TBD) may be sent to It is for future study whether the nAR sends the MN a CTAR reject if
the MN by nAR. CT is not supported.
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 incompletely understood, particularly on
the MN to AR link, and mechanisms for countering them are not well the 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 CTP for eventual
standards track will be to better characterize threats to context standards track will be to better characterize threats to context
transfer and design specific mechanisms to counter them. This section transfer and design specific mechanisms to counter them. This section
provides some general guidelines about security based on discussions provides some general guidelines about security based on discussions
among the Design Team and Working Group members. 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 mobile nodes are not authenticated and authorized before If the MNs are not authenticated and authorized before moving on the
moving on the network, there is a potential for DoS attacks to shift network, there is a potential for DoS attacks to shift state between
state between ARs, causing network disruptions. ARs, causing network disruptions.
Additionally, DoS attacks can be launched from mobile nodes towards
the access routers by requesting multiple context transfers and then
disappearing. Additionally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks.
6.2. Security Details Additionally, DoS attacks can be launched from MNs towards the access
routers by requesting multiple context transfers and then
disappearing. Finally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks, and issue bogus context
transfer requests to surrounding routers.
CTP relies on IETF standardized security mechanisms for protecting 6.2. Access Router Considerations
traffic between access routers, as opposed to creating application The CTP interrouter interface relies on IETF standardized security
security mechanisms. IPsec MUST be supported between access routers. mechanisms for protecting traffic between access routers, as opposed
to creating application security mechanisms. IPsec MUST be supported
between access routers.
In order to avoid the introduction of additional latency to context In order to avoid the introduction of additional latency due to the
transfer due to the need for establishment of secure channel between need for establishment of a secure channel between the context
the context transfer peers (ARs), the two ARs SHOULD establish such transfer peers (ARs), the two ARs SHOULD establish such a secure
secure channel in advance. If IPSec is used, for example, the two channel in advance. The two access routers need to engage in a key
access routers need to engage in a key exchange mechanisms such as exchange mechanisms such as IKE [RFC2409], establish IPSec SAs,
IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and defining the keys, algorithms and IPSec protocols (such as ESP) in
IPSec protocols (such as ESP) in anticipation for any upcoming anticipation for any upcoming context transfer. This will save time
context transfer. This will save time during handovers that require during handovers that require secure transfer. Such SAs can be
secure transfer of mobile node's context(s). Such SAs can be
maintained and used for all upcoming context transfers between the maintained and used for all upcoming context transfers between the
two ARs. Security should be negotiated prior to the sending of two ARs. Security should be negotiated prior to the sending of
context. context.
Furthermore, either one or both of the pAR and nAR need to be able to
authenticate the mobile and authorize mobile's credential before
authorizing the context transfer and release of context to the
mobile. In case the context transfer is request by the MN, a
mechanism MUST be provided so that requests are authenticated
(regardless of the security of context transfer itself) to prevent
the possibility of rogue MNs launching DoS attacks by sending large
number of CT requests as well as cause large number of context
transfers between ARs. Another important consideration is that the
mobile node should claim it's own context, and not some other
masquerader. One method to achieve this is to provide an
authentication cookie to be included with the context transfer
message sent from the pAR to the nAR and confirmed by the mobile node
at the nAR.
6.3. IPsec Considerations
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. ESP. Strong security on the inter-router interface is required to
protect against attacks by rogue routers, and to ensure
7. IANA Considerations confidentiality on the context transfer authorization key in
predicative transfer.
This section provides guidance to the Internet Assigned Numbers 6.3 Mobile Node Considerations
Authority (IANA) regarding registration of values related to the
context transfer protocol, in accordance with BCP 26 [RFC2434].
7.1 Context Profile Types Registry The CTAR message requires the MN and AR to possess a shared secret
key in order to calculate the authorization token. Validation of this
token MUST precede context transfer or installation of context for
the MN, removing the risk that an attacker could cause an
unauthorized transfer. How the shared key is established is out of
scope of the current specification. If both the MN and AR know
certified public keys of the other party, Diffie-Helman can be used
to generate a shared secret [RFC2631]. If an AAA protocol of some
sort is run for network entry, the shared key can be established
using that protocol [PerkCal04].
This document authorized IANA to create a registry for Context If predictive context transfer is used, the shared key for
Profile Types, introduced in this document. For future Context calculating the authorization token is transferred between ARs. A
Profile Types, it is recommended that allocations be done on the transfer of confidential material of this sort poses certain security
basis of Designated Expert. risks, even if the actual transfer itself is confidential and
authenticated, as is the case for inter-router CTP. The more entities
know the key, the more likely a compromise may occur. In order to
mitigate this risk, nAR MUST discard the key immediately after using
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
exercise care in using a key established for other purposes for also
authorizing context transfer. It is RECOMMENDED that a separate key
be established for context transfer authorization.
The Context Profile Type introduced in this document requires IANA Replay protection on the MN-AR protocol is provided by limiting the
Type Numbers for each set of feature contexts that make use of time period in which context is maintained. For predictive transfer,
Profile Types. the pAR receives a CTAR message with a sequence number, transfers the
context, then drops the context immediately upon completion of the
transfer, along with the authorization token key. For reactive
transfer, the nAR receives the CTAR, requests the context along with
the sequence number and authorization token, allowing the pAR to
check whether the transfer is authorized. The pAR drops the context
and authorization token key after the transfer has been completed.
The pAR and nAR ignore any requests containing the same MN IP address
during the transfer process. After the key has been dropped, any
attempt at replay will fail because the authorization token fails to
validate. The AR MUST NOT reuse the key for other MNs.
For registration requests where a Designated Expert should be DoS attacks on the MN-AR interface can be limited by having the AR
consulted, the responsible IESG area director should appoint the rate limit the number of CTAR messages it processes. The AR SHOULD
Designated Expert. limit the number of CTAR messages to CT_REQUEST_RATE. If the request
exceeds this rate, the AR SHOULD randomly drop messages until the
rate is established. The actual rate SHOULD be configured on the AR
to match the maximum number of handovers that the access network is
expected to support.
7.2 UDP Port 7. IANA Considerations
CTP requires a UDP port assignment. Instructions for IANA allocations are included in [IANA].
8. Acknowledgements & Contributors 8. Acknowledgements & Contributors
This document is the result of a design team formed by the Working This document is the result of a design team formed by the Working
Group chairs of the SeaMoby working group. The team included John Group chairs of the SeaMoby working group. The team included John
Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins.
Contributors to the Context Transfer Protocol review are Basavaraj Contributors to the Context Transfer Protocol review are Basavaraj
Patil, Pekka Savola, and Antti Tuominen. Patil, Pekka Savola, and Antti Tuominen.
skipping to change at page 20, line 17 skipping to change at page 25, line 14
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 9. References
9.1 Normative References 9.1 Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
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 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[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
Protocol", RFC 2960, October, 2000.
[PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension",
Internet Engineering Task Force. Work in Progress.
[CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate
Access Router Discovery", Internet Engineering Task Force.
Work in Progress.
[IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol
IANA Allocations", Internet Engineering Task Force. Work in
Progress.
9.2 Non-Normative References 9.2 Non-Normative References
[CTHC] R. Koodli et al., "Context Relocation for Seamless Header [CTHC] R. Koodli et al., "Context Relocation for Seamless Header
Compression in IP Networks", Internet Draft, Internet Compression in IP Networks", Internet Draft, Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
Engineering Task Force. Work in Progress. Engineering Task Force. Work in Progress.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Internet Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network", RFC Context Transfers Between Nodes in an IP Access Network", RFC
3374, Internet Engineering Task Force, RFC 3374, May 2001. 3374, May 2001.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631,
Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. June, 1999.
[RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery [PerkCal04]C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile
IPv4", Internet Engineering Task Force, Work in Progress.
[MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
IPv6", Internet Engineering Task Force, Work in Progress.
[RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener
Discovery (MLD) for IPv6," RFC 2710, October, 1999.
[RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)," RFC 2461, December, 1998. for IP Version 6 (IPv6)," RFC 2461, December, 1998.
[RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfiguration," [RFC2462] S. Thompson, and T. Narten, "IPv6 Address Autoconfiguration,"
RFC 2462, December, 1998. RFC 2462, December, 1998.
[RFC3095] C. Borman, ed., "RObust Header Compression (ROHC)", RFC 3095,
July, 2001.
[BT] IEEE, "IEEE Standard for information technology - Telecommuni-
cation and information exchange between systems - LAN/MAN -
Part 15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) specifications for Wireless Personal Area Networks
(WPANs)", IEEE Standard 802.15.1, 2002.
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the Basic Mobile IP handover signaling can introduce disruptions to the
services running on top of Mobile IP, which may introduce unwanted services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for certain types of ser- latencies that practically prohibit its use for certain types of
vices. Mobile IP latency and packet loss is being optimized through services. Mobile IP latency and packet loss is being optimized through
several alternative procedures, such as Fast Mobile IP [FMIPv6] and several alternative procedures, such as Fast Mobile IP [FMIPv6] and
Low Latency Mobile IP [LLMIP]. Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute Feature re-establishment through context transfer should contribute
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 to 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 is choosing the timing and order for may provide more flexibility in choosing the timing and order for
transfer of various context information. transfer of various context information.
Appendix B. Multicast Listener Context Transfer Appendix B. Multicast Listener Context Transfer
As an example of how context transfer can improve the performance of In the past, credible proposals have been made in the Seamoby Working
IP layer handover, we consider transferring IPv6 MLD state [RFC2710]. Group and elsewhere for using context transfer to speed handover of
MLD state is a particularly good example because every IPv6 node must authentication, authorization, and accounting context, distributed
perform two MLD messaging sequences on the wireless link to establish firewall context, PPP context, and header compression context.
Because the Working Group was not chartered to develop context
profile definitions for specific applications, none of the drafts
submitted to Seamoby were accepted as Working Group items. At this
time, work continues to develop a context profile definition for RFC
3095 header compression context [RFC3095] and to characterize the
performance gains obtainable by using header compression, but the
work is not yet complete. In addition, there are several commercial
wireless products that reportedly use non-standard, non-interoperable
context transfer protocols, though none is as yet widely deployed.
As a consequence, it is difficult at this time to point to a solid
example of how context transfer could result in a commercially
viable, widely deployable, interoperable benefit for wireless
networks. This is one reason why CTP is being proposed as an
Experimental protocol, rather than Standards Track. However, it
nevertheless seems valuable to have a simple example that shows
how handover could benefit from using CTP. The example we consider
here is transferring IPv6 MLD state [RFC2710]. MLD state is a
particularly good example because every IPv6 node must perform at
least one MLD messaging sequence on the wireless link to establish
itself as an MLD listener prior to performing router discovery itself as an MLD listener prior to performing router discovery
[RFC2461] or duplicate address detection [RFC2462] or before [RFC2461] or duplicate address detection [RFC2462] or before
sending/receiving any application-specific traffic (including Mobile sending/receiving any application-specific traffic (including Mobile
IP handover signaling, if any). The node must subscribe to the Soli- IP handover signaling, if any). The node must subscribe to the
cited Node Multicast Address as soon as it comes up on the link. Any Solicited Node Multicast Address as soon as it comes up on the link.
application-specific multicast addresses must be re-established as Any application-specific multicast addresses must be re-established
well. Context transfer can significantly speed up re-establishing as well. Context transfer can significantly speed up re-establishing
multicast state by allowing the nAR to initialize MLD for a node that multicast state by allowing the nAR to initialize MLD for a node that
just completed handover; without any MLD signaling on the new wire- just completed handover without any MLD signaling on the new
less link. The same approach could be used for transferring multicast wireless link. The same approach could be used for transferring
context in IPv4. multicast context in IPv4.
An approximate qualitative 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 bytes, handover time can be obtained as follows. MLD messages are 24 bytes,
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 bytes, and a compression on the new link, with IPv6 header being 40 bytes, and a
required Router Alert Hop-by-Hop option being 8 bytes including pad- required Router Alert Hop-by-Hop option being 8 bytes including pad-
ding. The total MLD message size is 72 bytes per subscribed multicast ding. The total MLD message size is 72 bytes per subscribed multicast
address. RFC 2710 recommends that nodes send 2 to 3 MLD Report mes- address. RFC 2710 recommends that nodes send 2 to 3 MLD Report
sages per address subscription, since the Report message is unack- 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 address,
mobile node would need to send 144 bytes per address subscription. If the MN would need to send 144 bytes per address subscription. If MLD
MLD messages are sent for both the All Nodes Multicast Address and messages are sent for both the All Nodes Multicast address and the
the Solicited Node Multicast address for the node's link local Solicited Node Multicast address for the node's link local address, a
address, a total of 288 bytes are required when the node hands over total of 288 bytes are required when the node hands over to the new
to the new link. Note that some implementations of IPv6 optimize by link. Note that some implementations of IPv6 optimize by not sending
not sending an MLD message for the All Nodes Multicast Address, since an MLD message for the All Nodes Multicast Address, since the router
the router can infer that at least one node is on the link (itself) can infer that at least one node is on the link (itself) when it
when it comes up and always will be, but for purposes of this calcu- comes up and always will be, but for purposes of this calculation, we
lation, we assume that the IPv6 implementation is conformant and that assume that the IPv6 implementation is conformant and that the
the message is sent. The amount of time required for MLD signaling message is sent. The amount of time required for MLD signaling will,
will, of course, depend on the wireless link bandwidth, but some of course, depend on the per node available wireless link bandwidth,
representative numbers can be obtained by assuming bandwidths of 20 but some representative numbers can be obtained by assuming bandwidths
kbps or 100 kbps. The former is approximate for a narrowband 3G cel- of 20 kbps or 100 kbps. With these two bit rates, the savings from not
lular links and the latter for a heavily utilized 802.11b WLAN link, having to perform the pre-router discovery messages are 115 msec. and
both running Voice over IP (VoIP). With these two bit rates, the sav- 23 msec., respectively. If any application-specific multicast
ings from not having to perform the pre-router discovery messages are addresses are subscribed, the amount of time saved could be
115 msec. and 23 msec., respectively. If any application-specific substantially more.
multicast addresses are subscribed, the amount of time saved could be
substantially more. Considering most ATM-based 3G voice cellular pro- This example might seem a bit contrived because MLD isn't used in the
tocols try to keep total voice handover delay less than 40- 80 msec., 3G cellular protocols and wireless local area network protocols
MLD signaling could have a large impact on the performance of inter- typically have enough bandwidth, if radio propagation conditions are
subnet VoIP handover. optimal, so sending a single MLD message might not be viewed as such
a performance burden. An example of a wireless protocol where MLD
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.
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
link, so a host on a moderately loaded 802.15.1 access point could
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
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 CTP 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 +
skipping to change at page 23, line 36 skipping to change at page 30, line 6
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 CTP 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 wireless
interface on which the Subnet Prefix field from the Context Data interface on which the Subnet Prefix field in the Context Data
Block is advertised, it transitions into the Listeners Present Block is advertised, it transitions into the Listeners Present
state for the Subscribed IPv6 Multicast Address field in the Con- state for the Subscribed IPv6 Multicast Address field in the
text Data Block. This transition is exactly the same as if the Context Data Block. This transition is exactly the same as if the
router had received a Report message. 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 interface,
it remains in that state but restarts the timer, as if it had it remains in that state but restarts the timer, as if it had
received a Report message. 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. The router MAY instead send a proxy MLD Report message on the link. If wireless bandwidth is not an issue, the router MAY instead
wireless interface that advertises the Subnet Prefix field from the send a proxy MLD Report message on the wireless interface that
Context Data Block if wireless bandwidth is not an issue. Since MLD advertises the Subnet Prefix field from the Context Data Block. Since
routers do not keep track of which nodes are listening to munticast MLD routers do not keep track of which nodes are listening to munticast
addresses, only whether a particular multicast address is being addresses, only whether a particular multicast address is being
listened to, proxying the subscription should cause no difficulty. 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
skipping to change at page 24, line 36 skipping to change at page 31, line 9
USA USA
madjid.nakhjiri@motorola.com madjid.nakhjiri@motorola.com
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
charliep@iprg.nokia.com charliep@iprg.nokia.com
Intellectual Property Considerations Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
"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.
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 or other rights that might be claimed to per- Intellectual Property Rights or other rights that might be claimed to
tain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might this document or the extent to which any license under such rights
or might not be available; neither does it represent that it has made might or might not be available; nor does it represent that it has
any effort to identify any such rights. Information on the IETF's made any independent effort to identify any such rights. Information
procedures with respect to rights in standards-track and standards- on the procedures with respect to rights in RFC documents can be
related documentation can be found in BCP-11. Copies of claims of found in BCP 78 and BCP 79.
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a Copies of IPR disclosures made to the IETF Secretariat and any
general license or permission for the use of such proprietary rights assurances of licenses to be made available, or the result of an
by implementers or users of this specification can be obtained from attempt made to obtain a general license or permission for the use of
the IETF Secretariat. such proprietary rights by implementers or users of this specifica-
tion can be obtained from the IETF on-line IPR repository at
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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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