discussed below. This authorizes the
receiver of CTAR to perform context
transfer.
Context Block Variable length field defined in
Section 2.4.
If no context types are specified, all contexts for the MN are
requested.
The Authorization Token is calculated as:
First (32, HMAC_SHA1
(Key, (Previous IP address | Sequence Number | CDBs)))
where Key is a shared secret between the MN and pAR, and CDB is a
concatenation of all the Context Data Blocks specifying the contexts
to be transferred that are included in the CTAR message.
2.5.2. Context Transfer Activate Acknowledge (CTAA) Message
This is an informative message sent by the receiver of CTAR to the MN
to acknowledge a CTAR message. Acknowledgement is optional,
depending on whether the MN requested it. This message may include a
list of FPTs that were not successfully transferred.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node’s Previous IP address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Type CTAA = 0x2
’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.
Length Message length in units of octets.
MN’s Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
FPT 16 bit unsigned integer, listing the Feature
Profile Type that was not successfully
transferred.
Status Code An octet, containing failure reason.
........ more FPTs and status codes as necessary
2.5.3. Context Transfer Data (CTD) Message
Sent by pAR to nAR, and includes feature data (CXTP data). This
message handles both predictive and normal CT. An acknowledgement
flag, ’A’, included in this message indicates whether a reply is
required by pAR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node’s Previous Care-of Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Algorithm | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD
| Key | only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
~ First Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Type CTD = 0x3 (Context Transfer Data)
PCTD = 0x4 (Predictive Context Transfer
Data)
’V’ flag When set to ’0’, IPv6 addresses.
When set to ’1’, IPv4 addresses.
’A’ bit When set, the pAR requests an
acknowledgement.
Length Message length in units of octets.
Elapsed Time The number of milliseconds since the
transmission of the first CTD message for
this MN.
MN’s Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
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.
Key Shared key between MN and AR for CXTP.
Context Data Block The Context Data Block (see Section 2.4).
When CTD is sent predictively, the supplied parameters (including the
algorithm, key length, and the key itself) allow the nAR to compute a
token locally and verify it against the token present in the CTAR
message. This material is also sent if the pAR receives a CTD
message with a null Authorization Token, indicating that the CT-Req
message was 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
computation of the MN Authorization Token is HMAC_SHA1. The token
authentication calculation algorithm is described in Section 2.5.1.
For predictive handover, the pAR SHOULD keep track of the CTAR
sequence number and cache the CTD message until a CTDR message for
the MN’s previous IP address has been received 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 this 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
This message is sent by nAR to pAR depending on the value of the ’A’
flag in CTD, indicating success or failure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|S| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node’s Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Type CTDR = 0x5 (Context Transfer Data)
’V’ flag When set to ’0’, IPv6 addresses.
When set to ’1’, IPv4 addresses.
’S’ bit When set to one, this bit indicates
that all feature contexts sent in CTD
or PCTD were received successfully.
Reserved Set to zero by the sender and ignored by
the receiver.
Length Message length in units of octets.
MN’s Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
FPT 16 bit unsigned integer, listing the Feature
Profile Type that is being acknowledged.
Status Code A context-specific return value,
zero for success, nonzero when ’S’ is
not set to one.
2.5.5. Context Transfer Cancel (CTC) Message
If transferring a context cannot be completed in a timely fashion,
then nAR may send CTC to pAR to cancel an ongoing CT process.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node’s Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Type CTC = 0x6 (Context Transfer Cancel)
Length Message length in units of octets.
’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 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
2.5.6. Context Transfer Request (CT-Req) Message
Sent by nAR to pAR to request the start of context transfer. This
message is sent as a response to a CTAR message. The fields
following the Previous IP address of the MN are included verbatim
from the CTAR message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node’s Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Requested Context Data Block (if present) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Type CTREQ = 0x7 (Context Transfer Request)
’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.
Length Message length in units of octets.
MN’s Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
Sequence Number Copied from the CTAR message, allows the
pAR to distinguish requests from 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.
Context Data Request Block
A request block for context data; see
Section 2.4.
The sequence number is used by pAR to correlate a request for
previously transmitted context. In predictive transfer, if the MN
sends CTAR prior to handover, pAR pushes context to nAR using PCTD.
If the CTD fails, the nAR will send a CT-Req with the same sequence
number, enabling the pAR to determine which context to resend. The
pAR deletes the context after CXTP_MAX_TRANSFER_TIME. The sequence
number is not used in reactive transfer.
For predictive transfer, the pAR sends the keying material and other
information necessary to calculate the Authorization Token without
having processed a CT-Req message. For reactive transfer, if the nAR
receives a context transfer trigger but has not yet received the CTAR
message with the authorization token, the Authorization Token field
in CT-Req is set to zero. The pAR interprets this as an indication
to include the keying material and other information necessary to
calculate the Authorization Token, and includes this material into
the CTD message as if the message were being sent due to predictive
transfer. This provides nAR with the information it needs to
calculate the authorization token when the MN sends CTAR.
3. Transport
3.1. Inter-Router Transport
Since most types of access networks in which CXTP might be useful are
not today deployed or, if they have been deployed, have not been
extensively measured, it is difficult to know whether congestion will
be a problem for CXTP. Part of the research task in preparing CXTP
for consideration as a possible candidate for standardization is to
quantify this issue. However, to avoid potential interference with
production applications should a prototype CXTP 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.
These considerations argue that implementations of CXTP MUST support,
and prototype deployments of CXTP SHOULD use, the Stream Control
Transport Protocol (SCTP) [SCTP] as 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 CXTP. 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 corresponds to a single MN’s
feature context collection. A single stream provides simplicity.
The use of multiple streams to prevent head-of-line blocking is for
future study. 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 ’CXTP’.
Inter-router CXTP 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 to accommodate the maximum acceptable handover
delay time. 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 to reduce an extra delay in sending messages. Within
CXTP, the nAR SHOULD estimate the retransmit timer from the receipt
of the first fragment of a CXTP 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.