draft-ietf-seamoby-ctp-04.txt   draft-ietf-seamoby-ctp-05.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-04.txt> R. Koodli <draft-ietf-seamoby-ctp-05.txt> R. Koodli
Expires: April 7, 2004 September 8, 2003 Expires: May 25, 2004 October 25, 2003
Context Transfer Protocol Context Transfer Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 Conventions Used in This Document 1.1 The Problem
1.2 Abbreviations Used in the Document 1.2 Conventions Used in This Document
1.3 Abbreviations Used in the Document
2. Protocol Overview 2. Protocol Overview
2.1 Context Transfer Packet Formats 2.1 Context Transfer Scenarios
2.2 Context Types 2.2 Context Transfer Packet Formats
2.3 Context Data Block 2.3 Context Types
2.4 Messages 2.4 Context Data Block
2.5 Messages
3. Transport, Reliability and Retransmission of Feature Data 3. Transport, Reliability and Retransmission of Feature Data
4. Open Issues 4. Error Codes
4.1 Failure Handling
5. Examples and Signaling Flows 5. Examples and Signaling Flows
5.1 Network controlled, Initiated by pAR 5.1 Network controlled, Initiated by pAR
5.2 Network controlled, Initiated by nAR 5.2 Network controlled, Initiated by nAR
5.3 Mobile controlled, Predictive New L2 up/old L2 down 5.3 Mobile controlled, Predictive New L2 up/old L2 down
6. Security Considerations 6. Security Considerations
6.1 Threats
6.2 Security Details
6.3 IPsec Considerations
7. IANA Considerations 7. IANA Considerations
7.1 Context Profile Types Registry
7.2 UDP Port
8. Acknowledgements 8. Acknowledgements
9. References 9. References
9.1 Normative References 9.1 Normative References
9.2 Non-Normative References 9.2 Non-Normative References
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Appendix B. Congestion Control Appendix B. Multicast Listener Context Transfer
Appendix C. Multicast Listener Context Transfer
Author's Addresses Author's Addresses
1. Introduction 1. Introduction
"Problem Description: Reasons For Performing Context Transfers This document describes the Context Transfer Protocol overview, which
between Nodes in an IP Access Network" [RFC3374] defines the
following main reasons why Context Transfer procedures may be useful
in IP networks.
1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch. An example of a
service is Context Relocation for Seamless Header Compression in IP
Networks [CTHC].
2) An additional motivation is to provide an interoperable solution
that supports various Layer 2 radio access technologies.
This document describes a generic context transfer protocol, which
provides: provides:
* Representation for feature contexts. * Representation for feature contexts.
* Messages to initiate and authorize context transfer, and notify * Messages to initiate and authorize context transfer, and notify
a mobile node of the status of the transfer. a mobile node of the status of the transfer.
* Messages for transferring contexts prior to, during and after * Messages for transferring contexts prior to, during and after
handovers. handovers.
The proposed protocol is designed to work in conjunction with other The proposed protocol is designed to work in conjunction with other
protocols in order to provide seamless mobility. 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
"Problem Description: Reasons For Performing Context Transfers
between Nodes in an IP Access Network" [RFC3374] defines the
following main reasons why Context Transfer procedures may be useful
in IP networks.
1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch. An example of a
service is included in Appendix C.
2) An additional motivation is to provide an interoperable solution
that supports various Layer 2 radio access technologies.
1.1 Conventions Used in This Document 1.1 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Abbreviations Used in the Document 1.2 Abbreviations Used in the Document
Mobility Related Terminology [TERM] defines basic mobility Mobility Related Terminology [TERM] defines basic mobility
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
2. Protocol Overview 2. Protocol Overview
This section provides a protocol overview. A context transfer can be This section provides a protocol overview. A context transfer can be
either started by a request from the mobile node ("mobile either started by a request from the mobile node ("mobile
controlled") or at the initiative of either the new or the previous controlled") or at the initiative of either the new or the previous
access router ("network controlled"). access router ("network controlled").
* The mobile node sends the CT Activate Request to old AR whenever * The mobile node sends the CT Activate Request to old AR whenever
possible to initiate predictive context transfer. In any case, the possible to initiate predictive context transfer. In any case, the
MN always sends the CTAR message to new AR. If the contexts are MN always sends the CTAR message to new AR. If the contexts are
skipping to change at page 4, line 35 skipping to change at page 4, line 37
The Context Transfer protocol typically operates between a source The Context Transfer protocol typically operates between a source
node and a target node. In the future, there may be multiple target node and a target node. In the future, there may be multiple target
nodes involved; the protocol described here would work with multiple nodes involved; the protocol described here would work with multiple
target nodes. For simplicity, we describe the protocol assuming a target nodes. For simplicity, we describe the protocol assuming a
single receiver or target node. single receiver or target node.
Typically, the source node is a MN's Previous Access Router (pAR) and Typically, the source node is a MN's Previous Access Router (pAR) and
the target node is MN's New Access Router (nAR). Context Transfer the target node is MN's New Access Router (nAR). Context Transfer
takes place when an event, such as a handover, takes place. We call takes place when an event, such as a handover, takes place. We call
such an event as a Context Transfer Trigger. In response to such a such an event a Context Transfer Trigger. In response to such a
trigger, the pAR may transfer the contexts; the nAR may request trigger, the pAR may transfer the contexts; the nAR may request
contexts; and the MN may send a message to the routers to transfer contexts; and the MN may send a message to the routers to transfer
contexts. Such a trigger must be capable of providing the necessary contexts. Such a trigger must be capable of providing the necessary
information, such as the MN's IP address with which the contexts are information, such as the MN's IP address with which the contexts are
associated, the IP addresses of the access routers, and authorization associated, the IP addresses of the access routers, and authorization
to transfer context. to transfer context.
Context transfer protocol messages use Feature Profile Types that Context transfer protocol messages use Feature Profile Types that
identify the way that data is organized for the particular feature identify the way that data is organized for the particular feature
contexts. The Feature Profile Types (FPTs) are registered in a number contexts. The Feature Profile Types (FPTs) are registered in a number
skipping to change at page 5, line 10 skipping to change at page 5, line 12
the protocol messages. Contexts are transferred by laying out the the protocol messages. Contexts are transferred by laying out the
appropriate feature data within Context Data Blocks according to the appropriate feature data within Context Data Blocks according to the
format in section 2.3, as well as any IP addresses necessary to format in section 2.3, as well as any IP addresses necessary to
associate the contexts to a particular MN. The context transfer associate the contexts to a particular MN. The context transfer
initiation messages contain parameters that identify the source and initiation messages contain parameters that identify the source and
target nodes, the desired list of feature contexts and IP addresses target nodes, the desired list of feature contexts and IP addresses
to identify the contexts. The messages that request transfer of to identify the contexts. The messages that request transfer of
context data also contain an appropriate token to authorize the context data also contain an appropriate token to authorize the
context transfer. context transfer.
The Previous Access Router transfers feature contexts under two
general scenarios. First, it may receive a Context Transfer Activate
Request (CTAR) message from the MN whose feature contexts are to be
transferred, or it receives an internally generated trigger (e.g., a
link-layer trigger on the interface to which the MN is connected).
The CTAR message, described in Section 2.4.1, provides the IP address
of nAR, the IP address of MN on pAR, the list of feature contexts to
be transferred (by default requesting all contexts to be
transferred), and a token authorizing the transfer. It also includes
the MN's new IP address (valid on nAR) whenever it is known. In
response to a CT-Activate Request message or to the CT trigger, pAR
predictively transmits a Context Transfer Data (CTD) message that
contains feature contexts. This message, described in Section 2.4.2,
contains the MN's previous IP address and its new IP address (if
known). It also contains parameters for nAR to compute an
authorization token to verify the MN's token present in CTAR message.
Recall that the MN always sends CTAR message to nAR regardless of
whether it sent the CTAR message to pAR. The reason for this is that
there is no means for the MN to ascertain that context transfer
reliably took place. By always sending the CTAR message to nAR, the
Context Transfer Request (see below) can be sent to pAR whenever
necessary.
In the second scenario, pAR receives a Context Transfer Request (CT
Request) described in Section 2.4.5, message from nAR. The nAR
itself generates the CT Request message either as a result of
receiving the CTAR message or as a response to an internal trigger
(that indicates the MN's attachment). In the CT-Req message, nAR
supplies the MN's previous IP address, the feature contexts to be
transferred, and a token (generated by the MN) authorizing context
transfer. In response to CT Request message, pAR transmits a Context
Transfer Data (CTD) message that includes the MN's previous IP
address and feature contexts. When it receives a corresponding CTD
message, nAR may generate a CTD Reply message (See Section 2.4.3) to
report the status of processing the received contexts.
[1].* contexts, pAR verifies authorization token before transmitting
the [2]algorithm [3] When context transfer takes place without the
nAR requesting it (scenario one above), nAR requires MN to present
its authorization token. Doing this locally at nAR when the MN
attaches to it improves performance and increases security, since the
contexts are highly likely to be present already. When context
transfer happens with an explicit request from nAR (scenario two
above), pAR performs such verification since the contexts are still
present at pAR. In either case, token verification takes place at the
router possessing the contexts.
Performing context transfer in advance of the MN attaching to nAR can Performing context transfer in advance of the MN attaching to nAR can
increase handover performance. For this to take place, certain increase handover performance. For this to take place, certain
conditions must be met. For example, pAR must have sufficient time conditions must be met. For example, pAR must have sufficient time
and knowledge about the impending handover. This is feasible, for and knowledge about the impending handover. This is feasible, for
instance, in Mobile IP fast handovers. Additially, many cellular instance, in Mobile IP fast handovers. Additionally, many cellular
networks have mechanisms to detect handovers in advance. However, networks have mechanisms to detect handovers in advance. However,
when the advance knowledge of impending handover is not available, or when the advance knowledge of impending handover is not available, or
if a mechanism such as fast handover fails, retrieving feature if a mechanism such as fast handover fails, retrieving feature
contexts after the MN attaches to nAR is the only available means for contexts after the MN attaches to nAR is the only available means for
context transfer. Performing context transfer after handover might context transfer. Performing context transfer after handover might
still be better than having to re-establish all the contexts from still be better than having to re-establish all the contexts from
scratch. Finally, some contexts may simply need to be transferred scratch. Finally, some contexts may simply need to be transferred
during handover signaling. For instance, any context that gets during handover signaling. For instance, any context that gets
updated on a per-packet basis must clearly be transferred only after updated on a per-packet basis must clearly be transferred only after
packet forwarding to the MN on its previous link is terminated. packet forwarding to the MN on its previous link is terminated.
The messages (CTD and CTDR) that perform the context transfer between The messages (CTD and CTDR) that perform the context transfer between
the access routers need to be authenticated, so that the access the access routers need to be authenticated, so that the access
routers can be certain that the data has not been tampered with routers can be certain that the data has not been tampered with
during delivery. during delivery.
2.1 Context Transfer Packet Format 2.1 Context Transfer Scenarios
The packet consists of a common header, message specific header and The Previous Access Router transfers feature contexts under two
one or more data packets. Data packets may be bundled together in general scenarios.
order to ensure a more efficient transfer. The total packet size,
including transport protocol and IP protocol headers SHOULD be less
than the path MTU, in order to avoid packet fragmentation.
+----------------------+ 2.1.1 Scenario 1
| CTP Header |
+----------------------+ The pAR may receive a Context Transfer Activate Request (CTAR)
| Message Header | message from the MN whose feature contexts are to be transferred, or
+----------------------+ it receives an internally generated trigger (e.g., a link-layer
| CTP Data 1 | trigger on the interface to which the MN is connected). The CTAR
+----------------------+ message, described in Section 2.5, provides the IP address of nAR,
| CTP Data 2 | the IP address of MN on pAR, the list of feature contexts to be
+----------------------+ transferred (by default requesting all contexts to be transferred),
| ... | and a token authorizing the transfer. It also includes the MN's new
IP address (valid on nAR) whenever it is known. In response to a CT-
Activate Request message or to the CT trigger, pAR predictively
transmits a Context Transfer Data (CTD) message that contains feature
contexts. This message, described in Section 2.5, contains the MN's
previous IP address and its new IP address (if known). It also
contains parameters for nAR to compute an authorization token to
verify the MN's token present in CTAR message. Recall that the MN
always sends CTAR message to nAR regardless of whether it sent the
CTAR message to pAR. The reason for this is that there is no means
for the MN to ascertain that context transfer reliably took place. By
always sending the CTAR message to nAR, the Context Transfer Request
(see below) can be sent to pAR whenever necessary.
When context transfer takes place without the nAR requesting it, nAR
requires MN to present its authorization token. Doing this locally at
nAR when the MN attaches to it improves performance and increases
security, since the contexts are highly likely to be present already.
Token verification takes place at the router possessing the contexts.
2.1.2 Scenario 2
In the second scenario, pAR receives a Context Transfer Request (CT
Request), described in Section 2.5, message from nAR. The nAR itself
generates the CT Request message either as a result of receiving the
CTAR message or as a response to an internal trigger (that indicates
the MN's attachment). In the CT-Req message, nAR supplies the MN's
previous IP address, the feature contexts to be transferred, and a
token (generated by the MN) authorizing context transfer. In response
to CT Request message, pAR transmits a Context Transfer Data (CTD)
message that includes the MN's previous IP address and feature
contexts. When it receives a corresponding CTD message, nAR may
generate a CTD Reply message to report the status of processing the
received contexts.
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
The packet consists of a message specific header and one or more data
packets. Data packets may be bundled together in order to ensure a
more efficient transfer. The total packet size, including transport
protocol and IP protocol headers SHOULD be less than the path MTU, in
order to avoid packet fragmentation.
2.3 Context Types
2.2 Context Types
Contexts are identified by context type of Feature Profile Type Contexts are identified by context type of Feature Profile Type
(FPT), which is a 15-bit number. The meaning of each context type is (FPT), which is a 15-bit number. The meaning of each context type is
determined by a specification document and the context type numbers determined by a specification document and the context type numbers
are to be tabulated in a registry maintained by IANA, and handled are to be tabulated in a registry maintained by 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. Each such context type specification
contains the following details: contains the following details:
+----------------------+
| Message Header |
+----------------------+
| CTP Data 1 |
+----------------------+
| CTP Data 2 |
+----------------------+
| ... |
- Number, size (in bits), and ordering of data fields in the - Number, size (in bits), and ordering of data fields in the
state variable vector which embodies the context. state variable vector which embodies the context.
- Default values (if any) for each individual datum of the - Default values (if any) for each individual datum of the
context state vector. context state vector.
- Procedures and requirements for creating a context at a new - Procedures and requirements for creating a context at a new
access router, given the data transferred from a previous access router, given the data transferred from a previous
access router, and formatted according to the ordering rules access router, and formatted according to the ordering rules
and date field sizes presented in the specification. and date field sizes presented in the specification.
- If possible, status codes for success or failure related to the - If possible, status codes for success or failure related to the
context transfer. For instance, a QoS context transfer might context transfer. For instance, a QoS context transfer might
have different status codes depending on which elements of the have different status codes depending on which elements of the
context data failed to be instantiated at nAR. context data failed to be instantiated at nAR.
2.3 Context Data Block 2.4 Context Data Block
The Context Data Block is used both for request and response operation. The Context Data Block is used both for request and response
When a particular feature request is constructed, only the first 4 bytes operation. When a particular feature request is constructed, only the
are typically necessary (See CTAR below). When used for the actual first 4 bytes are typically necessary (See CTAR below). When used for
feature context itself, the context data is present, and sometimes the the actual feature context itself, the context data is present, and
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 | | Cxt-Type | Length |P| Feature Profile Type (FTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) | | Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ context type-dependent data / | |
+ data +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cxt-Type Single octet, defined by IANA
Length message length in octets
'P' bit 0 = No presence vector
1 = Presence vector present.
FPT 16 bit integer, listing the feature profile
type contained in the data field.
data Context type-dependent data, whose length is
is defined by the Length Field. If the data
is not 64-bit aligned, the data field is padded
with zeros.
The Cxt-Type indicates the type of the feature context message itself The Cxt-Type indicates the type of the feature context message itself
(such as QoS Context Request, QoS Context Transfer etc.), and Feature (such as QoS Context Request, QoS Context Transfer etc.), and Feature
Profile Type (FPT) identifies the way the particular feature context Profile Type (FPT) identifies the way the particular feature context
is organized. The 'P' bit specifies whether or not the "presence is organized. The 'P' bit specifies whether or not the "presence
vector" is used. When the presence vector is in use, the Presentation vector" is used. When the presence vector is in use, the Presence
Vector is interpreted to indicate whether particular data fields are Vector is interpreted to indicate whether particular data fields are
present (and, thus, containing non-default values). The ordering of present (and containing non-default values). The ordering of the
the bits in the presence vector is the same as the ordering of the bits in the presence vector is the same as the ordering of the data
data fields according to the context type specification, one bit per fields according to the context type specification, one bit per data
data field regardless of the size of the data field. field regardless of the size of the data field.
The Length field indicates the size of the CDB in 8 octets including The Length field indicates the size of the CDB in 8 octets including
the first 4 bytes starting from Cxt-Type. the first 4 bytes starting from Cxt-Type.
%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 as accumulated size of all the context data that is implicitly given
a default value. as a default value.
2.4 Messages 2.5 Messages
In this section, a list of the available context transfer message In this section, a list of the available context transfer message
types is given, along with a brief description of their functions. types is given, along with a brief description of their functions. In
Generally, messages use the following generic message header format. addition, the CTAR message also contains either the Previous Router's
In addition, the CTAR message also contains either the Previous IP address or the New Router's IP address.
Router's IP address or the New Router's IP address.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Context Data Block (variable size, Section 2.3) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Mobile Node, for which context transfer protocol operations are The Mobile Node, for which context transfer protocol operations are
undertaken, is always identified by its previous IP access address. undertaken, is always identified by its previous IP access address.
At any one time, only one context transfer operation per MN may be in At any one time, only one context transfer operation per MN may be in
progress so that the CTDR message unambiguously identifies which CTD progress so that the CTDR message unambiguously identifies which CTD
message is acknowledged simply by including the mobile node's message is acknowledged simply by including the mobile node's
identifying previous IP address. identifying previous IP address.
The 'V' flag indicates whether the MN's previous address is IPv4 The 'V' flag indicates whether the MN's previous address is IPv4
only, IPv6 only or both addresses are present. See below. only, IPv6 only or both addresses are present. See below.
2.4.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 activation. Even when the MN does not know whether or not contexts
are present, the MN sends CTAR message to gain access with nAR. If an are present, the MN sends CTAR message to gain access with nAR. If an
acknowledgement for this message is needed, the MN sets the A flag to acknowledgement for this message is needed, the MN sets the A flag to
1, otherwise the MN does not expect an acknowledgement. This message 1, otherwise the MN does not expect an acknowledgement. This message
may include a list of FPT (feature profile types) that require may include a list of FPT (feature profile types) that require
transfer. It may include flags to request reliable transfer. transfer. It may include flags to request reliable transfer.
The MN may also send this message to pAR while still connected to The MN may also send this message to pAR while still connected to
pAR. In such a case, the MN includes the nAR's IP address and its new pAR. In such a case, the MN includes the nAR's IP address and its new
IP address (if known) rather than previous IP address and pAR's IP IP address (if known) rather than previous IP address and pAR's IP
address. address. If the new IP address is not known, then its previous IP
address is used.
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 |R| Reserved | | Type=CTAR | Length | V |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous (New) IP Address | | Mobile Node's Previous (New) IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous (New) Router IP Address | | Previous (New) Router IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay | | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Context Transfer Activate Request (CTAR). Type CTAR = 1
Length Variable Length message length in octets
MN's IP Address Field contains either:
IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373].
nAR / pAR IP Address Field contains either:
IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373].
Reserved Reserved for future use. Must be set to zero Reserved Reserved for future use. Must be set to zero
by the MN. by the MN.
'V' flag When set to '00', indicate presence of IPv6 'V' flag When set to '00', indicate presence of IPv6
Previous (New) address only. Previous (New) address only.
When set to '01' indicate presence of IPv4 When set to '01' indicate presence of IPv4
Previous (New) Address only. Previous (New) Address only.
When set to '10' indicate presence of both When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses. IPv6 and IPv4 Previous (New) addresses.
'R' bit The MN requests reliable transfer. 'A' bit The MN requests an acknowledgement.
Replay A value used to make sure that each use of the Replay A value used to make sure that each use of the
CTAR message is uniquely identifiable. CTAR message is uniquely identifiable.
Authorization Token Authorization Token An unforgeable value calculated as discussed
An unforgeable value calculated as discussed
below. This authorizes the receiver of CTAR below. This authorizes the receiver of CTAR
to perform context transfer. to perform context transfer.
Context Block Variable length field defined in section 2.4.
If no context types are specified, then all contexts for the mobile If no context types are specified, then all contexts for the mobile
node are requested. When 'V' is 10, the IPv4 address MUST preceed the node are requested. When 'V' is 10, the IPv4 address MUST precede the
IPv6 address both for the MN and the access router. Since Context IPv6 address both for the MN and the access router. Since Context
Types clearly define the context including the IP version, context Types clearly define the context including the IP version, context
enumeration need not be in any strict order, although it might be enumeration need not be in any strict order, although it might be
natural to outline all the IPv4 contexts followed by IPv6 contexts. 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 (Key, (Previous IP address | Replay | Context
Types))), where Key is the shared secret between the MN and pAR, and Types)))
Context Types includes all the desired contexts for which the
transfer is desired. In the default scenario, the MN implicitly
(i.e., even without the knowledge of contexts being present) or
explicitly requests transfer of all contexts.
2.4.2 Context Transfer Activate Acknowledge (CTAA) Message where Key is the shared secret between the MN and pAR, and Context
Types includes all the desired contexts for which the transfer is
desired. In the default scenario, the MN implicitly (i.e., even
without the knowledge of contexts being present) or explicitly
requests transfer of all contexts.
2.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. FPT (feature profile types) 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 | Reserved | | Type=CTAA | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP address | | Mobile Node's Previous IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed FPT (if present) | Status code | Reserved | | FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4.3 Context Transfer Data (CTD) Message Type CTAR = 2
Length message length in octets
Reserved Reserved for future use. Must be set to zero
by the MN.
MN's Prev IP Address Field contains either:
IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373].
FPT 16 bit integer, listing the FTP that was not
Successfully transferred.
Status Code An octet, containing failure reason.
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. A reliability message should handle predictive as well as normal CT. A reliability
flag, R, included in this message indicates whether a reply is flag, R, included in this message indicates whether a reply is
required by nAR. Note that the new AR must defend the new Care-of- required by nAR.
Address using proxy ARP or Neighbor Discovery.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=(P)CTD | Length | V |R| Reserved | | Type=(P)CTD | Length | V |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) | | Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's New Care-of Address, when Type=PCTD | | Mobile Node's New Care-of Address, when Type=PCTD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Type=Auth | Type Length | 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)
PCTD = 4 (Predictive Context Transfer Data)
'V' flag When set to '00', indicate presence of IPv6
Previous (New) address only.
When set to '01' indicate presence of IPv4
Previous (New) Address only.
When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses.
'A' bit The MN requests an acknowledgement.
Length message length in octets
Reserved Reserved for future use. Must be set to zero
by the 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:
IPv4 Address as defined in [RFC 791],
IPv6 Address as defined in [RFC 2373].
This is only applicable for the PCTD message.
Algorithm Algorithm for carrying out the computation
of the MN Authorization Token. Currently
only 1 algorithm is defined, HMAC_SHA1 = 1.
Key Length length of key, in octets.
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, allow 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. message. This message MUST be protected by IPsec ESP.
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 input
data for computing the token are: the MN's Previous IP address, the data for computing the token are:
FPT objects and the Replay field. When support for transferring all
contexts is requested, a default FPT is used. The Authorization Token
is obtained by truncating the results of the HMAC_SHA1 computation to
retain only the leading 32 bits.
2.4.4 Context Transfer Data Reply (CTDR) Message - the MN's Previous IP address,
- the FPT objects,
- the Replay field.
When support for transferring all contexts is requested, a default
FPT is used. The Authorization Token is obtained by truncating the
results of the HMAC_SHA1 computation to retain only the leading 32
bits.
2.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
reliability flag in CTD. Indicates success or failure. reliability flag in CTD. Indicates success or failure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTDR | Length | V |S| Reserved | | Type=CTDR | Length | V |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
Length message length in octets
'V' flag When set to '00', indicate presence of IPv6 'V' flag When set to '00', indicate presence of IPv6
Previous address only. Previous address only.
When set to '01' indicate presence of IPv4 Previous When set to '01' indicate presence of IPv4
Address only. Previous Address only.
When set to '10' indicate presence of both IPv6 and When set to '10' indicate presence of both
IPv4 Previous 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 that all
the feature contexts sent in CTD or PCTD were the feature contexts sent in CTD or PCTD were
received successfully. received successfully.
Status Code A context-specific return value, present when 'S' Reserved Reserved for future use. Must be set to zero
is not set to one. by the MN.
2.4.5 Context Transfer Cancel (CTC) Message MN's Prev IP Contains either:
Address Field IPv4 Address as defined in [RFC 791].
IPv6 Address as defined in [RFC 2373].
Status Code A context-specific return value, present
when 'S' is not set to one.
FPT 16 bit integer, listing the FPT that is being
acknowledged.
Status Code 0 = not successfully transfered
1 = successfully transfered
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 | | Type=CTC | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous Care-of Address | | Mobile Node's Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4.6 Context Transfer Request (CT Request) Message Type CTC = 6 (Context Transfer Data)
Sent by nAR to pAR request start of context transfer. This message is Length message length in octets
sent as a response to CTAR message by the MN. The fields following
Reserved Reserved for future use. Must be set to zero
by the MN.
2.5.6 Context Transfer Request (CT Request) 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
the Previous IP address of the MN are included verbatim from the CTAR the Previous IP address of the MN are included verbatim from the CTAR
message. message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=CTREQ | Length | V | Reserved | | Type=CTREQ | Length | V | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Previous IP Address | | Mobile Node's Previous IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Auth-Token| Type Len | Replay | | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 CTREQ = 7
Length message length in octets
'V' bits When set to '00', indicate presence of IPv6 'V' bits When set to '00', indicate presence of IPv6
Previous (New) address only. Previous (New) address only.
When set to '01' indicate presence of IPv4 When set to '01' indicate presence of IPv4
Previous (New) Address only. Previous (New) Address only.
When set to '10' indicate presence of both When set to '10' indicate presence of both
IPv6 and IPv4 Previous (New) addresses. IPv6 and IPv4 Previous (New) addresses.
Reserved Reserved for future use. Must be set to zero
by the MN.
Replay A value used to make sure that each use of the Replay A value used to make sure that each use of the
CTAR message is uniquely identifiable. CTAR message is uniquely identifiable.
Copied from CTAR. Copied from CTAR.
Authorization Token Authorization Token An unforgeable value calculated as discussed
An unforgeable value calculated as discussed
above. This authorizes the receiver of CTAR above. This authorizes the receiver of CTAR
to perform context transfer. Copied from to perform context transfer. Copied from
CTAR. CTAR.
3. Transport, Reliability and Retransmission of Feature Data 3. Transport, Reliability and Retransmission of Feature Data
CTP runs over UDP using port number <TBD>. Some feature contexts may CTP runs over UDP using port number <TBD>. Some feature contexts may
specify a reliability factor, MAX_RETRY_INTERVAL, which is the length specify a reliability factor, MAX_RETRY_INTERVAL, which is the length
of time that the pAR is allowed to perform retransmissions before of time that the pAR is allowed to perform retransmissions before
giving up on the context transfer for that feature context. The giving up on the context transfer for that feature context. The
longer the allowed retry interval, the more retransmissions will be longer the allowed retry interval, the more retransmissions will be
possible for that feature context. possible for that feature context.
For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD
retransmit an unacknowledged CTD message after waiting for retransmit an unacknowledged CTD message after waiting for
RETRANSMISSION_DELAY milliseconds. This time value is configurable RETRANSMISSION_DELAY milliseconds. This time value is configurable
based on the type of network interface; slower network media based on the type of network interface; slower network media
naturally will be configured with longer values for the naturally will be configured with longer values for the
RETRANSMISSION_DELAY. Except for the value of the elapsed time RETRANSMISSION_DELAY. Except for the value of the elapsed time field,
field, the payload of each retransmitted CTD packet is identical to the payload of each retransmitted CTD packet is identical to the
the payload of the initially transmitted CTD packet, in order to payload of the initially transmitted CTD packet, in order to maintain
maintain the ability of the mobile device to present a correctly the ability of the mobile device to present a correctly calculated
calculated authentication token. The number of retransmissions, each authentication token. The number of retransmissions, each delayed by
delayed by RETRANSMISSION_DELAY, depends on the maximum value for RETRANSMISSION_DELAY, depends on the maximum value for
MAX_RETRY_INTERVAL as specified by any of the contexts. The value MAX_RETRY_INTERVAL as specified by any of the contexts. The value
of the Elapsed Time field is the number of milliseconds since the of the Elapsed Time field is the number of milliseconds since the
transmission of the first CTD message transmission of the first CTD message
UDP provides an optional checksum, which SHOULD be checked. If the UDP provides an optional checksum, which SHOULD be checked. If the
checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with
the status value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in the status value BAD_UDP_CHECKSUM, even if the 'A' bit is not set in
the CTD. the CTD.
4. Error Codes 4. Error Codes
This section lists error codes used by UDP This section lists error codes used by UDP
BAD_UDP_CHECKSUM 0x01 BAD_UDP_CHECKSUM 0x01
5. Examples and Signaling Flows 5. Examples and Signaling Flows
skipping to change at page 14, line 45 skipping to change at page 16, line 42
I | | | I | | |
M | |<------- CTD ----------| M | |<------- CTD ----------|
E |--------CTAR--------->| | E |--------CTAR--------->| |
: | | | : | | |
| | |-------- CTDR -------->| | | |-------- CTDR -------->|
V | | | V | | |
| | | | | |
5.2 Network controlled, initiated by nAR 5.2 Network controlled, initiated by nAR
in 6
MN nAR pAR MN nAR pAR
| | | | | |
T | CT trigger | T | CT trigger |
I | | | I | | |
M | |----- CT Request ----->| M | |----- CT Request ----->|
E | | | E | | |
: | |<------- CTD ----------| : | |<------- CTD ----------|
| | | | | | | |
V |--------CTAR--------->| | V |--------CTAR--------->| |
| |----- CTDR (opt) ----->| | |----- CTDR (opt) ----->|
skipping to change at page 15, line 35 skipping to change at page 17, line 30
: | | | : | | |
| | | | | | | |
V | | | V | | |
| | | | | |
In case CT cannot be supported, a CTAR reject (TBD) may be sent to In case CT cannot be supported, a CTAR reject (TBD) may be sent to
the MN by nAR. the MN by nAR.
6. Security Considerations 6. Security Considerations
At this time, the threats to IP handover in general and context
transfer in particular are incompletely understood, particularly on
the MN to AR link, and mechanisms for countering them are not well
defined. Part of the experimental task in preparing CTP for eventual
standards track will be to better characterize threats to context
transfer and design specific mechanisms to counter them. This section
provides some general guidelines about security based on discussions
among the Design Team and Working Group members.
6.1. Threats. 6.1. Threats.
The Context Transfer Protocol transfers state between access routers. The Context Transfer Protocol transfers state between access routers.
If the mobile nodes are not authenticated and authorized before If the mobile nodes are not authenticated and authorized before
moving on the network, there is a potential for DoS attacks to shift moving on the network, there is a potential for DoS attacks to shift
state between ARs, causing network disruptions. state between ARs, causing network disruptions.
Additionally, DoS attacks can be launched from mobile nodes towards Additionally, DoS attacks can be launched from mobile nodes towards
the access routers by requesting multiple context transfers and then the access routers by requesting multiple context transfers and then
disappearing. Additionally, a rogue access router could flood mobile disappearing. Finally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks. nodes with packets, attempting DoS attacks.
6.2. Security Details 6.2. Security Details
CTP relies on IETF standardized security mechanisms for protecting CTP relies on IETF standardized security mechanisms for protecting
traffic between access routers, as opposed to creating application traffic between access routers, as opposed to creating application
security mechanisms. IPsec MUST be supported between access routers. 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 to context
transfer due to the need for establishment of secure channel between transfer due to the need for establishment of secure channel between
the context transfer peers (ARs), the two ARs SHOULD establish such the context transfer peers (ARs), the two ARs SHOULD establish such
secure channel in advance. If IPSec is used, for example, the two secure channel in advance. If IPSec is used, for example, the two
access routers need to engage in a key exchange mechanisms such as access routers need to engage in a key exchange mechanisms such as
IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and
IPSec protocols (such as ESP) in anticipation for any upcoming IPSec protocols (such as ESP) in anticipation for any upcoming
context transfer. This will save time during handovers that require context transfer. This will save time during handovers that require
secure transfer of mobile node's context(s). Such SAs can be secure transfer of mobile node's context(s). Such SAs can be
maintained and used for all upcoming context transfers between the maintained and used for all upcoming context transfers between the
two ARs. Security should be negotiated prior to the sending of two ARs. Security SHOULD be negotiated prior to the sending of
context. context.
Furthermore, either one or both of the pAR and nAR need to be able to Furthermore, either one or both of the pAR and nAR need to be able to
authenticate the mobile and authorize mobile's credential before authenticate the mobile and authorize mobile's credential before
authorizing the context transfer and release of context to the authorizing the context transfer and release of context to the
mobile. In case the context transfer is request by the MN, a mobile. In case the context transfer is request by the MN, a
mechanism MUST be provided so that requests are authenticated mechanism MUST be provided so that requests are authenticated
(regardless of the security of context transfer itself) to prevent (regardless of the security of context transfer itself) to prevent
the possibility of rogue MNs launching DoS attacks by sending large the possibility of rogue MNs launching DoS attacks by sending large
number of CT requests as well as cause large number of context number of CT requests as well as cause large number of context
skipping to change at page 17, line 5 skipping to change at page 19, line 8
ESP. ESP.
7. IANA Considerations 7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Authority (IANA) regarding registration of values related to the
context transfer protocol, in accordance with BCP 26 [RFC2434]. context transfer protocol, in accordance with BCP 26 [RFC2434].
7.1 Context Profile Types Registry 7.1 Context Profile Types Registry
This document authorized IANA to create a registry for Context Profile This document authorized IANA to create a registry for Context
Types, introduced in this document. For future Context Profile Types, Profile Types, introduced in this document. For future Context
it is recommended that allocations be done on the basis of Designated Profile Types, it is recommended that allocations be done on the
Expert. basis of Designated Expert.
The Context Profile Type introduced in this document requires IANA Type The Context Profile Type introduced in this document requires IANA
Numbers for each set of feature contexts that make use of Profile Types. Type Numbers for each set of feature contexts that make use of
Profile Types.
For registration requests where a Designated Expert should be consulted, For registration requests where a Designated Expert should be
the responsible IESG area director should appoint the Designated Expert. consulted, the responsible IESG area director should appoint the
Designated Expert.
7.2 UDP Port 7.2 UDP Port
CTP requires a UDP port assignment. CTP requires a UDP port assignment.
8. Acknowledgements & 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.
skipping to change at page 17, line 48 skipping to change at page 20, line 8
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
[RFC2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, IP [RFC2434] T. Narten, H. Alvestrand, "Guidelines for
November 1998 Writing an IANA Considerations Section in RFCs", BCP 26,
[CT-REQ] G. Kenward et al., "General Requirements for Context RFC 2434, October 1998.
Transfer", Internet Draft, Internet Engineering Task Force,
Work in Progress.
[CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for
Seamless Mobility", Internet Draft, Internet Engineering
Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
Engineering Task Force. Work in Progress.
IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 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.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Internet Engineering Task Force. Work in Progress.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay-
load (ESP)", RFC 2406, November 1998. load (ESP)", RFC 2406, November 1998.
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
Engineering Task Force. Work in Progress.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
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, Internet Engineering Task Force, RFC 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.
[RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast [RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast
Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999.
[RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery [RFC2461] Narten, T., Nordmark, E., and Simpson. W., "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 Autoconfigura- [RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfigura-
tion," RFC 2462, December, 1998. tion," RFC 2462, December, 1998.
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
skipping to change at page 19, line 34 skipping to change at page 21, line 28
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 conjunc-
tion to handovers. This means that the timing of context transfer tion to handovers. This means that the timing of context transfer
SHOULD be carefully aligned with basic Mobile IP handover events, and SHOULD be carefully aligned with basic Mobile IP handover events, and
with optimized Mobile IP handover signaling mechanisms, as those pro- with optimized Mobile IP handover signaling mechanisms, as those pro-
tocols become available. tocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms Furthermore, some of those optimized mobile IP handover mechanisms
(such as BETH) may provide more flexibility is choosing the timing may provide more flexibility is choosing the timing and order for
and order for transfer of various context information. transfer of various context information.
Appendix B. Congestion Control
Context transfer enables smooth handovers and prevents the need of
re-initializing signaling to and from a mobile node after handover.
Context transfer takes place between access routers.
The goal of congestion control is to prevent congestion by noting
packet loss at the transport layer and reducing the congestion con-
trol window when packet loss occurs, thus effectively restricting the
available in-flight window for packet sending. Additionally, TCP &
SCTP deploy slow-start mechanisms at start-up, in order to prevent
congestion problems at the start of a new TCP/SCTP session.
As some context is time-critical, delays due to congestion control
may reduce the performance of mobile nodes; additionally, signaling
from the mobile node may be increased if the context transfer of time
critical data fails.
Therefore, some analysis is needed on the role of congestion control
and context transfer. Important considerations should be network-
provisioning, intra-domain vs. inter-domain signaling as well as
other considerations. A quick analysis follows.
It is assumed that intra-domain time-critical context transfer should
take no more than one kilobyte, based on existing implementation of
some context transfer solutions. Contexts that are significantly
larger are assumed not so time critical. For a larger number of
users, say one thousand users requesting a smooth handover all in the
same second, the total bandwidth needed is still a small fraction of
a typical Ethernet, frame relay or ATM link between access routers.
So even bursty traffic is unlikely to introduce local congestion.
Furthermore, physically adjacent access routers should be within one
or two IP hops of each other, so the effects of context transfer
should be localized. If transferring real-time contexts triggers
congestive errors, the access network may be seriously under-
provisioned.
In order to handle multiple contexts to be transferred with differing
reliability needs, each context has to be considered separately by
the sending access router nAR. If a CTD message is retransmitted
because the CTDR message was not received in time, then those con-
texts that are "too late" are included anyway as part of the
retransmitted CTD data, in order to ease the ability to verify the
Mobile Authorization Token.
Appendix C. Multicast Listener Context Transfer
Introduction Appendix B. Multicast Listener Context Transfer
As an example of how context transfer can improve the performance of As an example of how context transfer can improve the performance of
IP layer handover, we consider transferring IPv6 MLD state [RFC2710]. IP layer handover, we consider transferring IPv6 MLD state [RFC2710].
MLD state is a particularly good example because every IPv6 node must MLD state is a particularly good example because every IPv6 node must
perform two MLD messaging sequences on the wireless link to establish perform 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 All IP handover signaling, if any). The node must subscribe to the Soli-
Nodes Multicast Address and the Solicited Node Multicast Address as cited Node Multicast Address as soon as it comes up on the link. Any
soon as it comes up on the link. In addition, any application- application-specific multicast addresses must be re-established as
specific multicast addresses must be re-established as well. Context well. Context transfer can significantly speed up re-establishing
transfer can significantly speed up re-establishing multicast state multicast state by allowing the nAR to initialize MLD for a node that
by allowing the nAR to initialize MLD for a node that just completed just completed handover; without any MLD signaling on the new wire-
handover; without any MLD signaling on the new wireless link. The less link. The same approach could be used for transferring multicast
same approach could be used for transferring multicast context in context in IPv4.
IPv4.
An approximate qualitative estimate for the amount of savings in An approximate qualitative 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 IPv6 header, 40 bytes, and a required Routing Header to which the headers must be added, because there is no header
Type 0, 24 bytes, must be added (because there will be no header compression on the new link, with the IPv6 header being 40 bytes, and
compression on the new link), for a total MLD message size of 88 a required Router Alert Hop-by-Hop option being 8 bytes including
bytes per message per subscribed address. RFC 2710 recommends that padding. The total MLD message size is thus 72 bytes per subscribed
nodes send 2 to 3 MLD Report messages per address subscription, since multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD
the Report message is unacknowledged. Assuming 2 MLD messages sent Report messages per address subscription, since the Report message is
per address subscription, the mobile node would need to send a total unacknowledged. Assuming 2 MLD messages sent for a subscribed
of 4 MLD messages for the two pre-router discovery multicast address, the mobile node would need to send 144 bytes per address
addresses (All Nodes Multicast Address and Solicited Node Multicast subscription, and must send at least 144 bytes on every handover, for
Address for the link local address). This gives a total of 176 bytes the link local Solicited Node Multicast address. The amount of time
per subscribed address or 352 bytes over the wireless link for both required for MLD signaling will, of course, depend on the wireless
the pre-router discovery multicast addresses. The amount of time link bandwidth, but some representative numbers can be obtained by
saved will, of course, depend on the wireless link bandwidth, but assuming bandwidths of 20 kbps or 100 kbps. The former is approximate
some representative numbers can be obtained by assuming bandwidths of for a narrowband 3G cellular link and the latter for a heavily util-
20 kbps or 100 kbps. The former is approximate for a narrowband 3G ized 802.11b WLAN link, both running Voice over IP (VoIP). With these
cellular link and the latter for a moderately utilized 802.11b WLAN two bit rates, the savings from not having to perform the required
link, both running Voice over IP (VoIP). With these two bit rates, MLD signaling are 57 msec. and 11 msec., respectively. If any
the savings from not having to perform the pre-router discovery mes- application-specific multicast addresses are subscribed, the amount
sages are 140.8 msec. and 28.2 msec., respectively. If any
application-specific multicast addresses were subscribed, the amount
of time saved could be substantially more. Considering most ATM-based of time saved could be substantially more. Considering most ATM-based
3G voice cellular protocols try to keep total voice handover delay 3G voice cellular protocols try to keep total voice handover delay
less than 40-80 msec., MLD signaling could have a large impact on the less than 40-80 msec., MLD signaling could have a substantial impact
performance of inter-subnet VoIP handover. on the performance of inter-subnet VoIP handover.
The Protocol
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 22, line 19 skipping to change at page 23, line 8
The Subnet Prefix on nAR Wireless Interface field contains a subnet The Subnet Prefix on nAR Wireless Interface field contains a subnet
prefix that identifies the interface on which multicast routing prefix that identifies the interface on which multicast routing
should be established. The Subscribed IPv6 Multicast Address field should be established. The Subscribed IPv6 Multicast Address field
contains the multicast address for which multicast routing should be contains the multicast address for which multicast routing should be
established. established.
The pAR sends one MLD context block per subscribed IPv6 multicast The pAR sends one MLD context block per subscribed IPv6 multicast
address. address.
Router MLD State Machine Interactions The MLD state machine requires no changes to implement context
transfer. Upon receipt of a CTP Context Data Block for MLD, the state
machine takes the following actions:
No changes are required in the MLD state machine for the routers. - If the router is in the No Listeners present state on the wireless
interface on which the Subnet Prefix field from the Context Data
Block is advertised, it transitions into the Listeners Present
state for the Subscribed IPv6 Multicast Address field in the Con-
text Data Block. This transition is exactly the same as if the
router had received a Report message.
Upon receipt of a CTP Context Data Block for MLD, if the router is in - If the router is in the Listeners present state on that interface,
the No Listeners Present state, it transitions to the Listeners it remains in that state but restarts the timer, as if it had
Present state for the Subscribed IPv6 Multicast Address on the wire- received a Report message.
less interface specified by the Subnet Prefix on nAR Wireless Inter-
face and starts its timer, as if it had received a Report message in
the No Listeners Present state. If the router is in the Listeners
Present state for the multicast address, it remains in that state but
restarts the timer, as if it had received a Report message in that
state.
If more than one MLD router is on the link, a router receiving a MLD If more than one MLD router is on the link, a router receiving an MLD
context data block SHOULD send a CTP Context Data Block for the Sub- Context Data Block SHOULD send the block to the other routers on the
scribed IPv6 Multicast Address and the Subnet Prefix on nAR Wireless link. The router MAY instead send a proxy MLD Report message on the
Interface to other MLD routers on the link. A router receiving an MLD wireless interface that advertises the Subnet Prefix field from the
context data block MAY send a proxy MLD Report message instead, if Context Data Block if wireless bandwidth is not an issue. Since MLD
wireless bandwidth is not an issue. Since MLD routers do not keep routers do not keep track of which nodes are listening to which mul-
track of which nodes are listening to multicast addresses, only ticast addresses, only whether a particular multicast address is
whether a particular multicast address is being listened to, proxying being listened to, proxying the subscription should cause no diffi-
the subscription should cause no difficulty. culty.
Authors' Addresses Authors' Addresses
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Rajeev.koodli@nokia.com Rajeev.koodli@nokia.com
John Loughney John Loughney
Nokia Nokia
Itdmerenkatu 11-13 Itdmerenkatu 11-13
00180 Espoo 00180 Espoo
Finland Finland
john.loughney@nokia.com john.loughney@nokia.com
Madjid F. Nakhjiri Madjid F. Nakhjiri
Motorola Labs Motorola Labs
1031 East Algonquin Rd., Room 2240 1031 East Algonquin Rd., Room 2240
 End of changes. 

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