Request for Comments: 4067 M. Nakhjiri
Category: Experimental C. Perkins
R. Koodli
July 2005
Context Transfer Protocol (CXTP)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document presents the Context Transfer Protocol (CXTP) that
enables authorized context transfers. Context transfers allow better
support for node based mobility so that the applications running on
mobile nodes can operate with minimal disruption. Key objectives are
to reduce latency and packet losses, and to avoid the re-initiation
of signaling to and from the mobile node.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem. . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Conventions Used in This Document. . . . . . . . . . . . 3
1.3. Abbreviations Used in the Document . . . . . . . . . . . 3
2. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Context Transfer Scenarios . . . . . . . . . . . . . . . 4
2.2. Context Transfer Message Format. . . . . . . . . . . . . 5
2.3. Context Types. . . . . . . . . . . . . . . . . . . . . . 6
2.4. Context Data Block (CDB) . . . . . . . . . . . . . . . . 7
2.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Transport. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Inter-Router Transport . . . . . . . . . . . . . . . . . 16
3.2. MN-AR Transport. . . . . . . . . . . . . . . . . . . . . 19
4. Error Codes and Constants. . . . . . . . . . . . . . . . . . . 20
5. Examples and Signaling Flows . . . . . . . . . . . . . . . . . 21
5.1. Network controlled, Initiated by pAR, Predictive . . . . 21
5.2. Network controlled, Initiated by nAR, Reactive . . . . . 21
5.3. Mobile controlled, Predictive New L2 up/Old L2 down. . . 22
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Threats. . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Access Router Considerations . . . . . . . . . . . . . . 23
6.3. Mobile Node Considerations . . . . . . . . . . . . . . . 24
7. Acknowledgements & Contributors. . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Timing and Trigger Considerations . . . . . . . . . . 28
Appendix B. Multicast Listener Context Transfer . . . . . . . . . 28
1. Introduction
This document describes the Context Transfer Protocol, which
provides:
* Representation for feature contexts.
* Messages to initiate and authorize context transfer, and notify
a mobile node of the status of the transfer.
* Messages for transferring contexts prior to, during and after
handovers.
The proposed protocol is designed to work in conjunction with other
protocols in order to provide seamless mobility. The protocol
supports both IPv4 and IPv6, though support for IPv4 private
addresses is for future study.
1.1. 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) As mentioned in the introduction, the primary motivation is 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 such a service is
included in Appendix B of this document.
2) An additional motivation is to provide an interoperable solution
that supports various Layer 2 radio access technologies.
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Abbreviations Used in the Document
Mobility Related Terminology [TERM] defines basic mobility
terminology. In addition to the material in that document, we use
the following terms and abbreviations in this document.
CXTP Context Transfer Protocol
DoS Denial-of-Service
FPT Feature Profile Types
PCTD Predictive Context Transfer Data
2. Protocol Overview
This section provides a protocol overview. A context transfer can be
either started by a request from the mobile node ("mobile
controlled") or at the initiative of the new or the previous access
router ("network controlled").
* The mobile node (MN) sends the CT Activate Request (CTAR) to
its current access router (AR) immediately prior to handover
when it is possible to initiate a predictive context transfer.
In any case, the MN always sends the CTAR message to the new AR
(nAR). If the contexts are already present, nAR verifies the
authorization token present in CTAR with its own computation
using the parameters supplied by the previous access router
(pAR), and subsequently activates those contexts. If the
contexts are not present, nAR requests pAR to supply them using
the Context Transfer Request message, in which it supplies the
authorization token present in CTAR.
* Either nAR or pAR may request or start (respectively) context
transfer based on internal or network triggers (see Appendix
A).
The Context Transfer protocol typically operates between a source
node and a target node. In the future, there may be multiple target
nodes involved; the protocol described here would work with multiple
target nodes. For simplicity, we describe the protocol assuming a
single receiver or target node.
Typically, the source node is an MN’s pAR and the target node is an
MN’s nAR. Context Transfer takes place when an event, such as a
handover, takes place. We call such an event a Context Transfer
Trigger. In response to such a 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. Such a trigger must be capable
of providing the necessary information (such as the MN’s IP address)
by which the contexts are identified. In addition, the trigger must
be able to provide the IP addresses of the access routers, and the
authorization to transfer context.
Context transfer protocol messages use Feature Profile Types (FPTs)
that identify the way that data is organized for the particular
feature contexts. The FPTs are registered in a number space (with
IANA Type Numbers) that allows a node to unambiguously determine the
type of context and the context parameters present in the protocol
messages. Contexts are transferred by laying out the appropriate
feature data within Context Data Blocks according to the format in
Section 2.3, as well as any IP addresses necessary to associate the
contexts to a particular MN. The context transfer initiation
messages contain parameters that identify the source and target
nodes, the desired list of feature contexts, and IP addresses to
identify the contexts. The messages that request the transfer of
context data also contain an appropriate token to authorize the
context transfer.
Performing a context transfer in advance of the MN attaching to nAR
can increase handover performance. For this to take place, certain
conditions must be met. For example, pAR must have sufficient time
and knowledge of the impending handover. This is feasible, for
instance, in Mobile IP fast handovers [LLMIP][FMIPv6]. Additionally,
many cellular networks have mechanisms to detect handovers in
advance. However, when the advance knowledge of impending handover
is not available, or if a mechanism such as fast handover fails,
retrieving feature contexts after the MN attaches to nAR is the only
available means for context transfer. Performing context transfer
after handover might still be better than having to re-establish all
the contexts from scratch, as shown in [FHCT] and [TEXT]. Finally,
some contexts may simply need to be transferred during handover
signaling. For instance, any context that gets updated on a per-
packet basis must clearly be transferred only after packet forwarding
to the MN on its previous link has been terminated.
2.1. Context Transfer Scenarios
The Previous Access Router transfers feature contexts under two
general scenarios.
2.1.1. Scenario 1
The pAR receives 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.5, 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. 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. It also contains parameters for nAR to compute an
authorization token to verify the MN’s token that is present in the
CTAR message. Recall that the MN always sends a CTAR message to nAR
regardless of whether it sent the CTAR message to pAR because there
is no means for the MN to ascertain that context transfer has
reliably taken place. By always sending the CTAR message to nAR, the
Context Transfer Request (see below) can be sent to pAR if 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 likely to already be present. 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-
Req) message from nAR, as described in Section 2.5. The nAR itself
generates the CT-Req message as a result of receiving the CTAR
message, or alternatively, from receiving a context transfer trigger.
In the CT-Req message, nAR supplies the MN’s previous IP address, the
FPTs for the feature contexts to be transferred, the sequence number
from the CTAR, and the authorization token from the CTAR. In
response to a CT-Req 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 (CTDR) message to report the status of
processing the received contexts. The nAR installs the contexts once
it has received them from the pAR.
2.2. Context Transfer Message Format
A CXTP message consists of a message-specific header and one or more
data blocks. Data blocks may be bundled together to ensure a more
efficient transfer. On the inter-AR interface, SCTP is used so
fragmentation should not be a problem. On the MN-AR interface, the
total packet size, including transport protocol and IP protocol
headers, SHOULD be less than the path MTU to avoid packet
fragmentation. Each message contains a 3 bit version number field in
the low order octet, along with the 5 bit message type code. This
specification only applies to Version 1 of the protocol, and the
therefore version number field MUST be set to 0x1. If future
revisions of the protocol make binary incompatible changes, the
version number MUST be incremented.
2.3. Context Types
Contexts are identified by the FPT code, which is a 16 bit unsigned
integer. The meaning of each context type is determined by a
specification document. The context type numbers are to be tabulated
in a registry maintained by IANA [IANA] and handled according to the
message specifications in this document. The instantiation of each
context by nAR is determined by the messages in this document along
with the specification associated with the particular context type.
The following diagram illustrates the general format for CXTP
messages:
+----------------------+
| Message Header |
+----------------------+
| CXTP Data 1 |
+----------------------+
| CXTP Data 2 |
+----------------------+
| ... |
Each context type specification contains the following details:
- Number, size (in bits), and ordering of data fields in the
state variable vector that embodies the context.
- Default values (if any) for each individual datum of the
context state vector.
- Procedures and requirements for creating a context at a new
access router, given the data transferred from a previous
access router and formatted according to the ordering rules and
data field sizes presented in the specification.
- If possible, status codes for success or failure related to the
context transfer. For instance, a QoS context transfer might
have different status codes depending on which elements of the
context data failed to be instantiated at nAR.
2.4. Context Data Block (CDB)
The Context Data Block (CDB) is used both for request and response
operations. When a request is constructed, only the first 4 octets
are typically necessary (See CTAR below). When used for transferring
the actual feature context itself, the context data is present, and
the presence vector is sometimes present.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feature Profile Type (FPT) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature Profile Type
16 bit integer, assigned by IANA,
indicating the type of data
included in the Data field.
Length Message length in units of 8 octet words.
’P’ bit 0 = No presence vector.
1 = Presence vector present.
Reserved Reserved for future use. Set to
zero by the sender.
Data Context type-dependent data, whose
length is defined by the Length
Field. If the data is not 64 bit
aligned, the data field is
padded with zeros.
The Feature Profile Type (FPT) code indicates the type of data in the
data field. Typically, this will be context data, but it could be an
error indication. The ’P’ bit specifies whether the "presence
vector" is used. When the presence vector is in use, it is
interpreted to indicate whether particular data fields are present
(and contain non-default values). The ordering of the bits in the
presence vector is the same as the ordering of the data fields
according to the context type specification, one bit per data field
regardless of the size of the data field. The Length field indicates
the size of the CDB in 8 octet words, including the first 4 octets
starting from FPT.
Notice that the length of the context data block is defined by the
sum of the lengths of each data field specified by the context type
specification, plus 4 octets if the ’P’ bit is set, minus the
accumulated size of all the context data that is implicitly given as
a default value.
2.5. Messages
In this section, the CXTP messages are defined. The MN for which
context transfer protocol operations are undertaken is always
identified by its previous IP access address. Only one context
transfer operation per MN may be in progress at a time so that the
CTDR message unambiguously identifies which CTD message is
acknowledged simply by including the MN’s identifying previous IP
address. The ’V’ flag indicates whether the IP addresses are IPv4 or
IPv6.
2.5.1. Context Transfer Activate Request (CTAR) Message
This message is always sent by the MN to the nAR to request a context
transfer. Even when the MN does not know if contexts need to be
transferred, the MN sends the CTAR message. If an acknowledgement
for this message is needed, the MN sets the ’A’ flag to 1; otherwise
the MN does not expect an acknowledgement. This message may include
a list of FPTs that require transfer.
The MN may also send this message to pAR while still connected to
pAR. In this case, the MN includes the nAR’s IP address; otherwise,
if the message is sent to nAR, the pAR address is sent. The MN MUST
set the sequence number to the same value as was set for the message
sent on both pAR and nAR so pAR can determine whether to use a cached
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|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MN’s Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Previous (New) AR IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Type CTAR = 0x1
’V’ flag When set to ’0’, IPv6 addresses.
When set to ’1’, IPv4 addresses.
’A’ bit If set, the MN requests an acknowledgement.
Reserved Set to zero by the sender, 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.
nAR / pAR IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
Sequence Number A value used to identify requests and
acknowledgements (see Section 3.2).
Authorization Token An unforgeable value calculated as