Network Working Group J. Loughney, Ed.
Request for Comments: 4067 M. Nakhjiri
Category: Experimental C. Perkins
R. Koodli
July 2005
Network Working Group J. Loughney, Ed.
Request for Comments: 4067 M. Nakhjiri
Category: Experimental C. Perkins
R. Koodli
July 2005
Context Transfer Protocol (CXTP)
上下文传输协议（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).
版权所有（C）互联网协会（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.
本文档介绍了支持授权上下文传输的上下文传输协议（CXTP）。上下文传输允许更好地支持基于节点的移动性，因此在移动节点上运行的应用程序可以在中断最小的情况下运行。关键目标是减少延迟和数据包丢失，并避免与移动节点之间的信令重新启动。
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
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
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
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.
所提出的协议设计为与其他协议协同工作，以提供无缝移动性。该协议支持IPv4和IPv6，但对IPv4专用地址的支持有待于将来的研究。
"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.
“问题描述：在IP访问网络中的节点之间执行上下文传输的原因”[RFC3374]定义了上下文传输过程在IP网络中有用的以下主要原因。
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.
1) 如引言中所述，主要动机是快速重新建立上下文传输候选服务，而无需移动主机从头显式执行这些服务的所有协议流。本文件附录B中包含了此类服务的示例。
2) An additional motivation is to provide an interoperable solution that supports various Layer 2 radio access technologies.
2) 另一个动机是提供支持各种第2层无线接入技术的互操作解决方案。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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
FPT特征配置文件类型
PCTD Predictive Context Transfer Data
预测上下文传输数据
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.
* 当可以发起预测性上下文传输时，移动节点（MN）在切换之前立即向其当前接入路由器（AR）发送CT激活请求（CTAR）。在任何情况下，MN总是向新AR（nAR）发送CTAR消息。如果上下文已经存在，nAR使用前一个访问路由器（pAR）提供的参数通过自己的计算验证CTAR中存在的授权令牌，然后激活这些上下文。如果上下文不存在，NAR请求PAR以使用上下文传递请求消息来提供它们，在上下文传递请求消息中，NAR提供在CTAR中存在的授权令牌。
* Either nAR or pAR may request or start (respectively) context transfer based on internal or network triggers (see Appendix A).
* NAR或PAR可以基于内部或网络触发器请求或启动（分别）上下文转移（见附录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.
通常，源节点是MN的PAR，目标节点是MN的NAR。上下文传输在发生事件（如切换）时发生。我们称这种事件为上下文转移触发器。响应于这样的触发，PAR可以传送上下文；nAR可以请求上下文；并且MN可以向路由器发送消息以传输上下文。这样的触发器必须能够提供必要的信息（如MN的IP地址），通过这些信息可以识别上下文。此外，触发器必须能够提供访问路由器的IP地址，以及传输上下文的授权。
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.
上下文传输协议消息使用特征配置文件类型（FPT），识别特定特征上下文的数据组织方式。FPT注册在一个数字空间中（带有IANA类型编号），该空间允许节点明确确定协议消息中存在的上下文类型和上下文参数。根据第2.3节中的格式，通过在上下文数据块内布置适当的特征数据以及将上下文与特定MN关联所需的任何IP地址来传输上下文。上下文传输启动消息包含标识源节点和目标节点的参数、所需的功能上下文列表以及标识上下文的IP地址。请求传输上下文数据的消息还包含用于授权上下文传输的适当令牌。
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.
在MN连接到nAR之前执行上下文传输可以提高切换性能。要实现这一点，必须满足某些条件。例如，PAR必须有足够的时间和知识的即将移交。例如，在移动IP快速切换[LLMIP][FMIPv6]中，这是可行的。此外，许多蜂窝网络具有提前检测切换的机制。然而，当即将到来的切换的预先知识不可用时，或者如果诸如快速切换之类的机制失败，则在MN连接到nAR之后检索特征上下文是上下文传输的唯一可用手段。切换后执行上下文传输可能仍然比从头开始重新建立所有上下文要好，如[FHCT]和[TEXT]所示。最后，在切换信令期间可能只需要传输一些上下文。例如，在每个分组的基础上更新的任何上下文必须明确地仅在分组在其先前链路上被终止转发到MN之后才被传输。
The Previous Access Router transfers feature contexts under two general scenarios.
先前的访问路由器在两种一般情况下传输特性上下文。
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.
PAR从要传送特征上下文的MN接收上下文转移激活请求（CTAR）消息，或者接收内部生成的触发器（例如，在连接MN的接口上的链路层触发器）。在第2.5节中描述的CTAR消息提供了NAR的IP地址、标准的MN的IP地址、要传输的特征上下文的列表（默认地请求所有要被传送的上下文）和授权传输的令牌。响应于CT激活请求消息或CT触发，PAR预测性地发送包含特征上下文的上下文传输数据（CTD）消息。第2.5节中描述的此消息包含MN以前的IP地址。它还包含用于nAR计算授权令牌以验证CTAR消息中存在的MN令牌的参数。回想一下，MN总是向CNAR发送CTAR消息，而不管它是否将CART消息发送到PAR，因为MN没有办法确定上下文传输是否可靠地发生。通过总是将cTAR消息发送到NAR，上下文转移请求（见下文）可以在必要时被发送到PAR。
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.
当上下文传输在nAR没有请求的情况下进行时，nAR要求MN提供其授权令牌。当MN连接到nAR时，在nAR本地执行此操作可以提高性能并提高安全性，因为上下文可能已经存在。令牌验证在拥有上下文的路由器上进行。
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.
在第二种情况下，PAR接收来自NAR的上下文转移请求（CT-Req）消息，如第2.5节所述。nAR本身通过接收CTAR消息或通过接收上下文传输触发器生成CT Req消息。在CT Req消息中，nAR提供MN以前的IP地址、要传输的功能上下文的FPT、来自CTAR的序列号以及来自CTAR的授权令牌。响应于CT-Req消息，PAR发送包括MN的先前IP地址和特征上下文的上下文传送数据（CTD）消息。当nAR接收到相应的CTD消息时，nAR可生成CTD回复（CTDR）消息以报告处理所接收上下文的状态。NAR一旦从PAR接收到它们，就安装上下文。
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
CXTP消息由消息特定的头和一个或多个数据块组成。数据块可以捆绑在一起以确保更有效的传输。在AR间接口上，使用SCTP以便
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.
碎片化不应该是一个问题。在MN-AR接口上，包括传输协议和IP协议头在内的总数据包大小应小于路径MTU，以避免数据包碎片。每条消息在低阶八位字节中包含一个3位版本号字段，以及5位消息类型代码。本规范仅适用于协议的版本1，因此版本号字段必须设置为0x1。如果协议的未来版本进行二进制不兼容更改，则版本号必须增加。
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:
上下文由FPT代码标识，FPT代码是一个16位无符号整数。每个上下文类型的含义由规范文档确定。上下文类型编号将在IANA[IANA]维护的注册表中制表，并根据本文件中的消息规范进行处理。nAR对每个上下文的实例化由本文档中的消息以及与特定上下文类型关联的规范确定。下图说明了CXTP消息的一般格式：
+----------------------+
| Message Header |
+----------------------+
| CXTP Data 1 |
+----------------------+
| CXTP Data 2 |
+----------------------+
| ... |
+----------------------+
| 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.
- 如果可能，与上下文传输相关的成功或失败状态代码。例如，QoS上下文传输可能具有不同的状态代码，这取决于在nAR未能实例化上下文数据的哪些元素。
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.
上下文数据块（CDB）用于请求和响应操作。构造请求时，通常只需要前4个八位字节（参见下面的CTAR）。当用于传输实际特征上下文本身时，上下文数据存在，并且存在向量有时存在。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
要素配置文件类型16位整数，由IANA分配，表示数据字段中包含的数据类型。
Length Message length in units of 8 octet words.
长度消息长度，以8个八位字节字为单位。
'P' bit 0 = No presence vector. 1 = Presence vector present.
“P”位0=无存在向量。1=存在的存在向量。
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.
数据上下文类型相关的数据，其长度由长度字段定义。如果数据不是64位对齐的，则数据字段用零填充。
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.
特征配置文件类型（FPT）代码表示数据字段中的数据类型。通常，这是上下文数据，但可能是错误指示。“P”位指定是否使用“存在向量”。当使用状态向量时，它被解释为指示是否存在特定的数据字段（并且包含非默认值）。存在向量中的位的顺序与根据上下文类型规范的数据字段的顺序相同，每个数据字段一位，与数据字段的大小无关。长度字段以8个八位字节字表示CDB的大小，包括从FPT开始的前4个八位字节。
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.
请注意，上下文数据块的长度由上下文类型规范指定的每个数据字段的长度之和定义，如果设置了“P”位，则加上4个八位字节，减去所有上下文数据的累积大小（默认值为隐式）。
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.
在本节中，定义了CXTP消息。为其执行上下文传输协议操作的MN始终由其先前的IP访问地址标识。每个MN一次只能进行一个上下文传输操作，因此CTDR消息仅通过包括MN的标识先前的IP地址来明确标识哪个CTD消息被确认。“V”标志指示IP地址是IPv4还是IPv6。
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.
此消息始终由MN发送到nAR以请求上下文传输。即使当MN不知道是否需要传输上下文时，MN也会发送CTAR消息。如果需要对该消息进行确认，则MN将“A”标志设置为1；否则，MN不期望确认。此消息可能包括需要传输的FPT列表。
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.
MN也可以将该消息发送到PAR，同时仍然连接到PAR。在这种情况下，MN包括nAR的IP地址；否则，如果消息被发送到NAR，则发送PAR地址。MN必须将序列号设置为与PAR和NAR上发送的消息所设置的值相同，因此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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
弗斯。CXTP协议的版本号=0x1
Type CTAR = 0x1
类型CTAR=0x1
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
设置为“0”时的“V”标志，IPv6地址。当设置为“1”时，IPv4地址。
'A' bit If set, the MN requests an acknowledgement.
“A”位如果设置，MN请求确认。
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.
MN的上一个IP地址字段包含：IPv4[RFC791]地址，4个八位字节，或IPv6[RFC3513]地址，16个八位字节。
nAR / pAR IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
NAR/PAR IP地址字段包含：IPv4[RCF791]地址，4个八位字节，或IPV[RCF3513]地址，16个八位字节。
Sequence Number A value used to identify requests and acknowledgements (see Section 3.2).
序列号用于识别请求和确认的值（见第3.2节）。
Authorization Token An unforgeable value calculated as discussed below. This authorizes the receiver of CTAR to perform context transfer.
授权令牌一个不可伪造的值，如下所述计算。这授权CTAR的接收方执行上下文传输。
Context Block Variable length field defined in Section 2.4.
第2.4节中定义的上下文块可变长度字段。
If no context types are specified, all contexts for the MN are requested.
如果未指定上下文类型，则会请求MN的所有上下文。
The Authorization Token is calculated as:
授权令牌的计算公式为：
First (32, HMAC_SHA1 (Key, (Previous IP address | Sequence Number | CDBs)))
第一个（32，HMAC|U SHA1（密钥，（以前的IP地址|序列号| CDB）））
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.
其中密钥是MN和PAR之间的共享秘密，CDB是所有上下文数据块的级联，指定要包含在CTAR消息中的上下文。
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.
这是由CTAR的接收器向MN发送的信息性消息，以确认CTAR消息。根据MN是否请求确认，确认是可选的。此消息可能包括未成功传输的FPT列表。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
弗斯。CXTP协议的版本号=0x1
Type CTAA = 0x2
类型CTAA=0x2
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
设置为“0”时的“V”标志，IPv6地址。当设置为“1”时，IPv4地址。
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.
MN的上一个IP地址字段包含：IPv4[RFC791]地址，4个八位字节，或IPv6[RFC3513]地址，16个八位字节。
FPT 16 bit unsigned integer, listing the Feature Profile Type that was not successfully transferred.
FPT 16位无符号整数，列出未成功传输的特征配置文件类型。
Status Code An octet, containing failure reason.
状态代码八位字节，包含故障原因。
........ more FPTs and status codes as necessary
........ more FPTs and status codes as necessary
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.
由PAR发送到NAR，并包含特征数据（CXTP数据）。此消息处理预测性CT和正常CT。包含在该消息中的确认标志“A”指示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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
弗斯。CXTP协议的版本号=0x1
Type CTD = 0x3 (Context Transfer Data) PCTD = 0x4 (Predictive Context Transfer Data)
类型CTD=0x3（上下文传输数据）PCTD=0x4（预测上下文传输数据）
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
设置为“0”时的“V”标志，IPv6地址。当设置为“1”时，IPv4地址。
'A' bit When set, the pAR requests an acknowledgement.
当设置“A”位时，PAR请求确认。
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的第一条CTD消息以来的毫秒数。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MN的上一个IP地址字段包含：IPv4[RFC791]地址，4个八位字节，或IPv6[RFC3513]地址，16个八位字节。
Algorithm Algorithm for carrying out the computation of the MN Authorization Token. Currently only 1 algorithm is defined, HMAC_SHA1 = 1.
用于执行MN授权令牌计算的算法。目前只定义了1个算法，HMAC_SHA1=1。
Key Length Length of key, in octets.
密钥长度密钥的长度，以八位字节为单位。
Key Shared key between MN and AR for CXTP.
密钥CXTP的MN和AR之间的共享密钥。
Context Data Block The Context Data Block (see Section 2.4).
上下文数据块上下文数据块（见第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.
当预测性地发送CTD时，提供的参数（包括算法、密钥长度和密钥本身）允许nAR在本地计算令牌，并根据CTAR消息中的令牌进行验证。如果PAR接收到具有空授权令牌的CTD消息，则该材料也被发送，这表明在NAR接收到CCTAR消息之前发送了CT-Req消息。CTD必须受到IPsec的保护；见第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.
如前所述，用于执行MN授权令牌的计算的算法是HMAC_SHA1。第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
对于预测切换，PAR应跟踪CTAR序列号并缓存CTD消息，直到从PAR接收到MN的先前IP地址的CTDR消息，指示上下文转移成功，或直到CTMax Max HORADOFION时间过期。如果预测CTD消息未能到达或上下文已损坏，nAR可能会发送包含相同序列号的CT Req消息。在这种情况下，nAR
sends a CT-Req message with a matching sequence number and pAR can resend the context.
发送具有匹配序列号的CT-Req消息，PAR可以重发上下文。
This message is sent by nAR to pAR depending on the value of the 'A' flag in CTD, indicating success or failure.
这个消息由NAR发送到PAR，取决于CTD中的“A”标志的值，指示成功或失败。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
弗斯。CXTP协议的版本号=0x1
Type CTDR = 0x5 (Context Transfer Data)
类型CTDR=0x5（上下文传输数据）
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
设置为“0”时的“V”标志，IPv6地址。当设置为“1”时，IPv4地址。
'S' bit When set to one, this bit indicates that all feature contexts sent in CTD or PCTD were received successfully.
“S”位设置为1时，该位表示成功接收了在CTD或PCTD中发送的所有功能上下文。
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.
MN的上一个IP地址字段包含：IPv4[RFC791]地址，4个八位字节，或IPv6[RFC3513]地址，16个八位字节。
FPT 16 bit unsigned integer, listing the Feature Profile Type that is being acknowledged.
FPT 16位无符号整数，列出正在确认的特征配置文件类型。
Status Code A context-specific return value, zero for success, nonzero when 'S' is not set to one.
状态代码特定于上下文的返回值，成功为零，未将“S”设置为1时为非零。
If transferring a context cannot be completed in a timely fashion, then nAR may send CTC to pAR to cancel an ongoing CT process.
如果传输上下文不能及时完成，则NAR可以将CTC发送到PAR以取消正在进行的CT过程。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
弗斯。CXTP协议的版本号=0x1
Type CTC = 0x6 (Context Transfer Cancel)
类型CTC=0x6（上下文传输取消）
Length Message length in units of octets.
长度消息长度，以八位字节为单位。
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
设置为“0”时的“V”标志，IPv6地址。当设置为“1”时，IPv4地址。
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.
MN的上一个IP地址字段包含：IPv4[RFC791]地址，4个八位字节，或IPv6[RFC3513]地址，16个八位字节。
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.
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.translate error, please retry
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
弗斯。CXTP协议的版本号=0x1
Type CTREQ = 0x7 (Context Transfer Request)
类型CTREQ=0x7（上下文传输请求）
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
设置为“0”时的“V”标志，IPv6地址。当设置为“1”时，IPv4地址。
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.
MN的上一个IP地址字段包含：IPv4[RFC791]地址，4个八位字节，或IPv6[RFC3513]地址，16个八位字节。
Sequence Number Copied from the CTAR message, allows the pAR to distinguish requests from previously sent context.
从cTAR消息复制的序列号允许PAR区分请求与先前发送的上下文。
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.
MN的授权令牌是根据第2.5.1节中的讨论计算的不可伪造值。这授权CTAR的接收方执行上下文传输。复制自CTAR。
Context Data Request Block A request block for context data; see Section 2.4.
上下文数据请求块用于上下文数据的请求块；见第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.
序列号由PAR使用以关联先前传输上下文的请求。在预测转移中，如果MN在切换之前发送CTAR，PAR使用PCTD将上下文推送到NAR。如果CTD失败，NAR将发送具有相同序列号的CT-Req，使PAR能够确定要重新发送的上下文。PAR删除CxtpMax传递时间后的上下文。序列号不用于无功传输。
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.
对于预测转移，PAR发送密钥材料和其他必要的信息来计算授权令牌而无需处理CT-Req消息。对于反应式传输，如果nAR接收到上下文传输触发器，但尚未接收到带有授权令牌的CTAR消息，则CT Req中的授权令牌字段设置为零。PAR将此解释为包含密钥材料和计算授权令牌所需的其他信息的指示，并且将该材料包括到CTD消息中，就好像由于预测转移而发送消息一样。这为nAR提供了在MN发送CTAR时计算授权令牌所需的信息。
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.
由于目前尚未部署CXTP可能有用的大多数类型的接入网络，或者，如果已经部署，尚未对其进行广泛测量，因此很难知道拥塞是否会成为CXTP的一个问题。准备CXTP作为标准化的可能候选方案的部分研究任务是量化这个问题。但是，如果原型CXTP部署涉及在公共Internet上运行，为了避免对生产应用程序的潜在干扰，建议使用默认传输协议来解决拥塞问题似乎是明智的。此外，由于特征上下文信息具有确定的生存期，因此传输协议必须适应灵活的重传，从而丢弃因拥塞而停滞的陈旧上下文。最后，由于上下文数据量可以任意大，因此传输协议不应限于单个数据包或要求实现自定义分段协议。
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
这些考虑因素表明，CXTP的实现必须支持流控制传输协议（SCTP）[SCTP]作为路由器间接口上的传输协议，并且CXTP的原型部署应使用该协议，特别是在考虑通过公共互联网部署的情况下。SCTP支持基于可编程重传计时器的拥塞控制、分段和部分重传。SCTP还支持许多高级和复杂的
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.
功能，例如用于故障切换的多个流和多个IP地址，这些功能对于CXTP的实验性实施和原型部署是不必要的。目前不建议使用此类SCTP功能。
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.
SCTP有效负载数据块承载上下文传输协议消息。每个SCTP消息的用户数据部分包含本文档中定义的适当上下文传输协议消息。使用SCTP发送的消息包括CTD（第2.5.3节）、CTDR（第2.5.4节）、CTC（第2.5.5节）和CT Req（第2.5.6节）。通常，每个SCTP消息都可以携带属于任何MN的特征上下文。如果SCTP校验和计算失败，nAR将在CTDR消息中返回BAD_校验和错误代码。
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].
单个流用于上下文传输，而不按顺序传递SCTP消息。每条消息对应于单个MN的功能上下文集合。单个流提供了简单性。使用多个流来防止线首阻塞是为了将来的研究。无序传递允许接收方不阻塞属于不同MN的消息的顺序传递。SCTP标头中的有效负载协议标识符为“CXTP”。路由器间CXTP使用Seamoby SCTP端口[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.
应通过将SCTP最大重传值设置为CT_MAX_transfer_TIME来适应上下文传输信息的及时性，以适应最大可接受切换延迟时间。AR应配置CT_MAX_TRANSFER_TIME，以适应特定的无线链路技术和本地无线传播条件。应关闭SCTP消息绑定，以减少发送消息时的额外延迟。在CXTP中，nAR应该从接收到CXTP消息的第一个片段开始估计重传计时器，并避免处理来自MN的任何IP流量，直到上下文传输完成或估计的重传计时器过期。如果两个路由器都支持PR-SCTP[PR-SCTP]，则应使用PR-SCTP。PR-SCTP修改Send（）操作的生存期参数（在[SCTP]第10.1 E节中定义），使其适用于重传和传输；也就是说，在PR-SCTP中，如果生存期到期且数据块未被确认，则发送器停止重新传输，而在基本协议中，数据将被重新传输，直到确认或连接超时。
The format of Payload Data Chunk taken from [SCTP] is shown in the following diagram.
从[SCTP]获取的有效负载数据块的格式如下图所示。
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
“U”位是无序位。必须设置为1（一）。'B'位是起始片段位。见[SCTP]。
'E' bit The Ending fragment bit. See [SCTP].
“E”位是结束片段位。见[SCTP]。
TSN Transmission Sequence Number. See [SCTP].
TSN传输序列号。见[SCTP]。
Stream Identifier S Identifies the context transfer protocol stream.
流标识符S标识上下文传输协议流。
Stream Sequence Number n Since the 'U' bit is set to one, the receiver ignores this number. See [SCTP].
流序列号n由于“U”位设置为1，接收器忽略该数字。见[SCTP]。
Payload Protocol Identifier Set to 'CXTP' (see [IANA]).
有效负载协议标识符设置为“CXTP”（请参阅[IANA]）。
User Data Contains the context transfer protocol messages.
用户数据包含上下文传输协议消息。
If a CXTP deployment will never run over the public Internet, and it is known that congestion is not a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. For example, piggybacking CXTP messages on top of handover signaling for routing, such as provided by FMIPv6 in ICMP [FMIPv6]. Implementations of CXTP MAY support ICMP for such purposes. If such piggybacking is used, an experimental message extension for the protocol on which CXTP is piggybacking MUST be designed. Direct deployment on top of a transport protocol for experimental purposes is also possible. In this case, the researcher
如果CXTP部署永远不会在公共互联网上运行，并且众所周知，在接入网络中拥塞不是问题，那么替代传输协议可能是合适的实验工具。例如，在切换信令之上搭载CXTP消息以进行路由，如ICMP[FMIPv6]中的FMIPv6提供的。CXTP的实现可能支持ICMP用于此类目的。如果使用这种搭载，则必须为CXTP搭载的协议设计一个实验性的消息扩展。出于实验目的，也可以直接部署在传输协议之上。在这种情况下，研究人员
MUST be careful to accommodate good Internet transport protocol engineering practices, including using retransmits with exponential backoff.
必须小心适应良好的Internet传输协议工程实践，包括使用指数退避的重传。
The MN-AR interface MUST implement and SHOULD use ICMP to transport the CTAR and CTAA messages. Because ICMP contains no provisions for retransmitting packets if signaling is lost, the CXTP protocol incorporates provisions for improving transport performance on the MN-AR interface. The MN and AR SHOULD limit the number of context data block identifiers included in the CTAR and CTAA messages so that the message will fit into a single packet, because ICMP has no provision for fragmentation above the IP level. CXTP uses the Experimental Mobility ICMP type [IANA]. The ICMP message format for CXTP messages is as follows:
MN-AR接口必须实现并应使用ICMP传输CTAR和CTAA消息。由于ICMP不包含在信令丢失时重新传输数据包的规定，因此CXTP协议包含了改进MN-AR接口传输性能的规定。MN和AR应限制CTAR和CTAA消息中包含的上下文数据块标识符的数量，以便消息将适合单个数据包，因为ICMP没有IP级别以上的碎片规定。CXTP使用实验性移动性ICMP类型[IANA]。CXTP消息的ICMP消息格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
IP字段：
Source Address An IP address assigned to the sending interface.
源地址分配给发送接口的IP地址。
Destination Address An IP address assigned to the receiving interface.
目标地址分配给接收接口的IP地址。
Hop Limit 255
跃点限制255
ICMP Fields:
ICMP字段：
Type Experimental Mobility Type (To be assigned by IANA, for IPv4 and IPv6, see [IANA])
类型实验移动类型（由IANA分配，对于IPv4和IPv6，请参见[IANA]）
Code 0
代码0
Checksum The ICMP checksum.
Checksum The ICMP checksum.translate error, please retry
Sub-type The Experimental Mobility ICMP subtype for CXTP, see [IANA].
子类型CXTP的实验移动性ICMP子类型，参见[IANA]。
Reserved Set to zero by the sender and ignored by the receiver.
发送方保留设置为零，接收方忽略。
Message The body of the CTAR or CTAA message.
消息CTAR或CTAA消息的正文。
CTAR messages for which a response is requested but fail to elicit a response are retransmitted. The initial retransmission occurs after a CXTP_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). CTAR messages should be retransmitted until either a response (which might be an error) has been obtained, or until CXTP_RETRY_MAX seconds after the initial transmission.
请求响应但未能引发响应的CTAR消息将被重新传输。初始重新传输发生在CXTP请求重试等待期之后。必须以指数增长的等待间隔（每次等待时间加倍）进行重新传输。应重新传输CTAR消息，直到获得响应（可能是错误），或者直到初始传输后的CXTP_RETRY_MAX秒。
MNs SHOULD generate the sequence number in the CTAR message randomly (also ensuring that the same sequence number has not been used in the last 7 seconds), and, for predictive transfer, MUST use the same sequence number in a CTAR message to the nAR as for the pAR. An AR MUST ignore the CTAR message if it has already received one with the same sequence number and MN IP address.
MNS应该随机地在CTAR消息中生成序列号（也确保在过去的7秒内没有使用相同的序列号），并且对于预测转移，必须在CAR消息中使用相同的序列号到NAR作为PAR。如果AR已接收到具有相同序列号和MN IP地址的CTAR消息，则AR必须忽略CTAR消息。
Implementations MAY, for research purposes, try other transport protocols. Examples are the definition of a Mobile IPv6 Mobility Header [MIPv6] for use with the FMIPv6 Fast Binding Update [FMIPv6] to allow bundling of both routing change and context transfer signaling from the MN to AR, or definition of a UDP protocol instead of ICMP. If such implementations are done, they should abide carefully by good Internet transport engineering practices and be used for prototype and demonstration purposes only. Deployment on large scale networks should be avoided until the transport characteristics are well understood.
出于研究目的，实现可能会尝试其他传输协议。例如，定义用于FMIPv6快速绑定更新[FMIPv6]的移动IPv6移动头[MIPv6]，以允许将路由更改和上下文传输信令从MN绑定到AR，或者定义UDP协议而不是ICMP。如果完成了此类实施，则应严格遵守良好的互联网传输工程实践，并仅用于原型和演示目的。在充分了解传输特性之前，应避免在大规模网络上部署。
Error Code Section Value Meaning
------------------------------------------------------------
Error Code Section Value Meaning
------------------------------------------------------------
BAD_CHECKSUM 3.1 0x01 Error code if the SCTP checksum fails.
如果SCTP校验和失败，则错误的校验和3.1 0x01错误代码。
Constant Section Default Value Meaning
--------------------------------------------------------------------
Constant Section Default Value Meaning
--------------------------------------------------------------------
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of sec. CTAR messages before AR institutes rate limiting.
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of sec. CTAR messages before AR institutes rate limiting.translate error, please retry
CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time pAR should wait before aborting the transfer.
CT-Max转移时间3.1 200毫秒最大时间量PAR应在中止转移之前等待。
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before initial retransmit on MN-AR interface.
在MN-AR接口上首次重新传输之前，CT_请求_重试3.2秒等待间隔。
CT_RETRY_MAX 3.2 15 seconds Give up retrying on MN-AR interface.
CT\u重试\u最多3.2 15秒放弃在MN-AR接口上重试。
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E |------- CTAR -------->| |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E |------- CTAR -------->| |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |--------- CT-Req ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V |------- CTAR -------->| |
| |----- CTDR (opt) ----->|
| | |
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |--------- CT-Req ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V |------- CTAR -------->| |
| |----- CTDR (opt) ----->|
| | |
CTAR request to nAR
向nAR发出CTAR请求
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |------- CTAR -------->| |
I | |-------- CT-Req ------>|
M | | |
E | |<-------- CTD ---------|
: | | |
| | | |
V | | |
| | |
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |------- CTAR -------->| |
I | |-------- CT-Req ------>|
M | | |
E | |<-------- CTD ---------|
: | | |
| | | |
V | | |
| | |
Whether the nAR sends the MN a CTAR reject message if CT is not supported is for future study.
如果CT不受支持，nAR是否向MN发送CTAR拒绝消息供将来研究。
At this time, the threats to IP handover in general and context transfer in particular are not widely understood, particularly on the MN to AR link, and mechanisms for countering them are not well defined. Part of the experimental task in preparing CXTP 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.
目前，对IP切换、尤其是上下文传输的威胁还没有得到广泛的理解，尤其是在MN-to-AR链路上，并且对抗这些威胁的机制也没有得到很好的定义。为最终标准跟踪准备CXTP的部分实验任务将是更好地描述对上下文传输的威胁，并设计特定的机制来应对这些威胁。本节根据设计团队和工作组成员之间的讨论，提供了一些关于安全性的一般指南。
The Context Transfer Protocol transfers state between access routers. If the MNs are not authenticated and authorized before moving on the network, there is a potential for masquerading attacks to shift state between ARs, causing network disruptions.
上下文传输协议在访问路由器之间传输状态。如果MN在网络上移动之前未经过身份验证和授权，则有可能通过伪装攻击在ARs之间转移状态，从而导致网络中断。
Additionally, DoS attacks can be launched from MNs towards the access routers by requesting multiple context transfers and then by disappearing. Finally, a rogue access router could flood mobile nodes with packets, attempt DoS attacks, and issue bogus context transfer requests to surrounding routers.
此外，通过请求多个上下文传输，然后通过消失，可以从MNs向访问路由器发起DoS攻击。最后，恶意访问路由器可能会向移动节点发送大量数据包，尝试DoS攻击，并向周围路由器发出虚假的上下文传输请求。
Consistency and correctness in context transfer depend on interoperable feature context definitions and how CXTP is utilized for a particular application. For some considerations regarding consistency and correctness that have general applicability but are articulated in the context of AAA context transfer, please see [EAP].
上下文传输中的一致性和正确性取决于可互操作的功能上下文定义以及如何将CXTP用于特定应用程序。关于一致性和正确性的一些考虑因素，这些考虑因素具有普遍适用性，但在AAA上下文传输的上下文中进行了阐述，请参见[EAP]。
The CXTP inter-router interface relies on IETF standardized security mechanisms for protecting traffic between access routers, as opposed to creating application security mechanisms. IPsec [RFC2401] MUST be supported between access routers.
CXTP路由器间接口依赖于IETF标准化的安全机制来保护接入路由器之间的通信，而不是创建应用程序安全机制。访问路由器之间必须支持IPsec[RFC2401]。
To avoid the introduction of additional latency due to the need for establishing a secure channel between the context transfer peers (ARs), the two ARs SHOULD establish such a secure channel in advance. The two access routers need to engage in a key exchange mechanism such as IKE [RFC2409], establish IPSec SAs, and define the keys, algorithms, and IPSec protocols (such as ESP) in anticipation of any upcoming context transfer. This will save time during handovers that require secure transfer. Such SAs can be maintained and used for all upcoming context transfers between the two ARs. Security should be negotiated prior to the sending of context.
为了避免由于需要在上下文传输对等方（ARs）之间建立安全通道而引入额外的延迟，两个ARs应该提前建立这样的安全通道。这两个访问路由器需要参与密钥交换机制，如IKE[RFC2409]，建立IPSec SA，并在任何即将到来的上下文传输之前定义密钥、算法和IPSec协议（如ESP）。这将在需要安全传输的切换期间节省时间。这样的SA可以维护并用于两个AR之间即将进行的所有上下文传输。应在发送上下文之前协商安全性。
Access Routers MUST implement IPsec ESP [ESP] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST implement the replay protection mechanisms of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP. Strong security on the inter-router interface is required to protect against attacks by rogue routers, and to ensure confidentiality on the context transfer authorization key in predicative transfer.
访问路由器必须在传输模式下使用非空加密和身份验证算法实现IPsec ESP[ESP]，以提供每包身份验证、完整性保护和机密性，并且必须实现IPsec的重播保护机制。在需要IP层保护的情况下，应使用隧道模式的ESP。使用IPSec时应使用非空加密，尤其是路由器间接口上的强安全性要求能够防止恶意路由器的攻击，并确保谓词传输中上下文传输授权密钥的机密性。
The details of IKE key exchange and other details of the IPsec security associations between routers are to be determined as part of the research phase associated with finalizing the protocol for standardization. These details must be determined prior to standardization. Other working groups are currently working on general security for routing protocols. Ideally, a possible solution for CXTP will be based on this work to minimize the operational configuration of routers for different protocols. Requirements for CXTP will be brought to the appropriate IETF routing protocol security working groups for consideration.
IKE密钥交换的详细信息以及路由器之间IPsec安全关联的其他详细信息将作为与最终确定标准化协议相关的研究阶段的一部分来确定。这些细节必须在标准化之前确定。其他工作组目前正在研究路由协议的一般安全性。理想情况下，CXTP的可能解决方案将基于这项工作，以最小化不同协议路由器的操作配置。CXTP的要求将提交适当的IETF路由协议安全工作组审议。
The CTAR message requires the MN and AR to possess a shared secret key to calculate the authorization token. Validation of this token MUST precede context transfer or installation of context for the MN, removing the risk that an attacker could cause an unauthorized transfer. How the shared key is established is out of scope of this specification. If both the MN and AR know certified public keys of the other party, Diffie-Hellman can be used to generate a shared secret key [RFC2631]. If an AAA protocol of some sort is run for network entry, the shared key can be established using that protocol [PerkCal04].
CTAR消息要求MN和AR拥有一个共享密钥来计算授权令牌。必须在上下文传输或安装MN上下文之前验证此令牌，以消除攻击者可能导致未经授权传输的风险。如何建立共享密钥超出了本规范的范围。如果MN和AR都知道另一方的认证公钥，则可以使用Diffie Hellman生成共享密钥[RFC2631]。如果为网络入口运行某种AAA协议，则可以使用该协议建立共享密钥[PerkCal04]。
If predictive context transfer is used, the shared key for calculating the authorization token is transferred between ARs. A transfer of confidential material of this sort poses certain security risks, even if the actual transfer itself is confidential and authenticated, as is the case for inter-router CXTP. The more entities know the key, the more likely a compromise may occur. To mitigate this risk, nAR MUST discard the key immediately after using it to validate the authorization token. The MN MUST establish a new key with the AR for future CXTP transactions. The MN and AR SHOULD exercise care in using a key established for other purposes for also authorizing context transfer. The establishment of a separate key for context transfer authorization is RECOMMENDED.
如果使用预测性上下文传输，则用于计算授权令牌的共享密钥在ARs之间传输。此类机密材料的传输会带来一定的安全风险，即使实际传输本身是机密且经过验证的，路由器间CXTP就是这样。实体越了解关键，就越有可能发生妥协。为了降低此风险，nAR必须在使用密钥验证授权令牌后立即丢弃密钥。MN必须为未来的CXTP事务与AR建立一个新密钥。MN和AR应谨慎使用为其他目的建立的密钥，以授权上下文传输。建议为上下文传输授权建立单独的密钥。
Replay protection on the MN-AR protocol is provided by limiting the time period in which context is maintained. For predictive transfer, the pAR receives a CTAR message with a sequence number, transfers the context along with the authorization token key, and then drops the context and the authorization token key immediately upon completion of the transfer. For reactive transfer, the nAR receives the CTAR, requests the context that includes the sequence number and authorization token from the CTAR message that allows the pAR to check whether the transfer is authorized. The pAR drops the context and authorization token key after the transfer has been completed. The pAR and nAR ignore any requests containing the same MN IP address if an outstanding CTAR or CTD message is unacknowledged and has not timed out. After the key has been dropped, any attempt at replay will fail because the authorization token will fail to validate. The AR MUST NOT reuse the key for any MN, including the MN that originally possessed the key.
MN-AR协议上的重播保护是通过限制上下文维护的时间段来提供的。对于预测转移，PAR接收具有序列号的CTAR消息，将该上下文连同授权令牌密钥一起传送，然后在传输完成后立即丢弃上下文和授权令牌密钥。对于无功传输，NAR接收CTAR，请求从CTAR消息中包含序列号和授权令牌的上下文，该消息允许PAR检查传输是否被授权。PAR在传输完成后丢弃上下文和授权令牌密钥。如果未确认的CTAR或CTD消息未被超时，PAR和NAR会忽略包含相同MN IP地址的任何请求。密钥被丢弃后，任何重播尝试都将失败，因为授权令牌将无法验证。AR不得对任何MN重复使用密钥，包括最初拥有密钥的MN。
DoS attacks on the MN-AR interface can be limited by having the AR rate limit the number of CTAR messages it processes. The AR SHOULD limit the number of CTAR messages to the CT_REQUEST_RATE. If the request exceeds this rate, the AR SHOULD randomly drop messages until the rate is established. The actual rate SHOULD be configured on the
MN-AR接口上的DoS攻击可以通过AR速率限制其处理的CTAR消息的数量来限制。AR应将CTAR消息的数量限制为CT_请求率。如果请求超过此速率，AR应随机丢弃消息，直到建立速率。应在上配置实际费率
AR to match the maximum number of handovers that the access network is expected to support.
AR匹配接入网络预期支持的最大切换次数。
This document is the result of a design team formed by the chairs of the SeaMoby working group. The team included John Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins.
本文件是由SeaMoby工作组主席组成的设计团队的成果。这支队伍包括约翰·拉夫尼、马吉德·纳基里、拉吉夫·库德利和查尔斯·帕金斯。
Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the Context Transfer Protocol review.
Basavaraj Patil、Pekka Savola和Antti Tuominen对上下文传输协议审查做出了贡献。
The working group chairs are Pat Calhoun and James Kempf, whose comments have been very helpful in the creation of this specification.
工作组主席是Pat Calhoun和James Kempf，他们的意见对本规范的创建非常有帮助。
The authors would also like to thank Julien Bournelle, Vijay Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf Motiwala, Phil Neumiller, Hesham Soliman, and Lucian Suciu for their help and suggestions with this document.
作者还要感谢Julien Bournelle、Vijay Devarapalli、Dan Forsberg、傅晓明、Michael Georgiades、Yusuf Motivala、Phil Neumiller、Hesham Soliman和Lucian Suciu对本文件的帮助和建议。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[PR-SCTP] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[PR-SCTP]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[IANA] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[IANA]Kempf，J.，“Seamoby和实验移动协议IANA分配说明”，RFC 4065，2005年7月。
[FHCT] R. Koodli and C. E. Perkins, "Fast Handovers and Context Transfers", ACM Computing Communication Review, volume 31, number 5, October 2001.
[FHCT]R.Koodli和C.E.Perkins，“快速切换和上下文传输”，ACM计算通信评论，第31卷，第5期，2001年10月。
[TEXT] M. Nakhjiri, "A time efficient context transfer method with Selective reliability for seamless IP mobility", IEEE VTC-2003-Fall, VTC 2003 Proceedings, Vol.3, Oct. 2003.
[文本]M.Nakhjiri，“无缝IP移动性中具有选择性可靠性的时间效率上下文传输方法”，IEEE VTC-2003-Fall，VTC 2003年论文集，第3卷，2003年10月。
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[FMIPv6]Koodli，R.，Ed.“移动IPv6的快速切换”，RFC 4068，2005年7月。
[LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
[LLMIP]K.El Malki等人，“移动IPv4中的低延迟切换”，正在进行中。
[RFC3374] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[RFC3374]Kempf，J.，“问题描述：在IP接入网络中的节点之间执行上下文传输的原因”，RFC 3374，2002年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[TERM] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[术语]方式，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[PerkCal04] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[PerkCal04]Perkins，C.和P.Calhoun，“移动IPv4的身份验证、授权和记帐（AAA）注册密钥”，RFC 3957，2005年3月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIPv6]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[BT] IEEE, "IEEE Standard for information technology - Telecommunication and information exchange between systems - LAN/MAN - Part 15.1: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.1, 2002.
[BT]IEEE，“IEEE信息技术标准-系统间远程通信和信息交换-LAN/MAN-第15.1部分：无线个人区域网络（WPAN）的无线媒体访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.15.12002。
[EAP] Aboba, B., Simon, D., Arkko, J., Eron, P., and H. Levokowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress.
[EAP]Aboba，B.，Simon，D.，Arkko，J.，Eron，P.，和H.Levokowetz，“可扩展认证协议（EAP）密钥管理框架”，正在进行中。
Basic Mobile IP handover signaling can introduce disruptions to the services running on top of Mobile IP, which may introduce unwanted latencies that practically prohibit its use for certain types of services. Mobile IP latency and packet loss are optimized through several alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP].
基本移动IP切换信令可能会对运行在移动IP之上的服务造成中断，这可能会导致不必要的延迟，从而实际上禁止将其用于某些类型的服务。移动IP延迟和数据包丢失通过几种替代程序进行优化，如快速移动IP[FMIPv6]和低延迟移动IP[LLMIP]。
Feature re-establishment through context transfer should contribute zero (optimally) or minimal extra disruption of services in conjunction with handovers. This means that the timing of context transfer SHOULD be carefully aligned with basic Mobile IP handover events, and with optimized Mobile IP handover signaling mechanisms, as those protocols become available.
通过上下文传输进行的功能重建应在切换时对服务造成零（最佳）或最小的额外中断。这意味着，当这些协议可用时，上下文传输的定时应该与基本移动IP切换事件以及优化的移动IP切换信令机制仔细地对齐。
Furthermore, some of those optimized mobile IP handover mechanisms may provide more flexibility in choosing the timing and ordering for the transfer of various context information.
此外，那些优化的移动IP切换机制中的一些可以在选择各种上下文信息的传输的定时和顺序方面提供更大的灵活性。
In the past, credible proposals have been made in the Seamoby Working Group and elsewhere for using context transfer to the speed of handover of authentication, authorization, and accounting context, distributed firewall context, PPP context, and header compression context. Because the Working Group was not chartered to develop context profile definitions for specific applications, none of the documents submitted to Seamoby were accepted as Working Group items. At this time, work to develop a context profile definition for RFC 3095 header compression context [RFC3095] and to characterize the performance gains obtainable by using header compression continues, but is not yet complete. In addition, there are several commercial wireless products that reportedly use non-standard, non-interoperable context transfer protocols, though none is as yet widely deployed.
在过去，Seamoby工作组和其他地方提出了可信的建议，使用上下文传输来加快认证、授权和记帐上下文、分布式防火墙上下文、PPP上下文和报头压缩上下文的移交速度。由于工作组没有被授权为特定应用开发上下文概要定义，因此提交给Seamoby的任何文件都不被接受为工作组项目。此时，为RFC 3095报头压缩上下文[RFC3095]开发上下文配置文件定义并描述通过使用报头压缩可获得的性能增益的工作仍在继续，但尚未完成。此外，据报道，有几种商用无线产品使用非标准、不可互操作的上下文传输协议，但尚未广泛部署。
As a consequence, it is difficult at this time to point to a solid example of how context transfer could result in a commercially viable, widely deployable, interoperable benefit for wireless networks. This is one reason why CXTP is being proposed as an Experimental protocol, rather than Standards Track. Nevertheless, it seems valuable to have a simple example that shows how handover could benefit from using CXTP. The example we consider here is transferring IPv6 MLD state [RFC2710]. MLD state is a particularly good example because every IPv6 node must perform at least one MLD messaging sequence on the wireless link to establish itself as an MLD listener prior to performing router discovery [RFC2461] or duplicate address detection [RFC2462] or before sending/receiving any
因此，目前很难找到一个可靠的例子来说明上下文传输如何为无线网络带来商业上可行、可广泛部署、可互操作的好处。这就是为什么CXTP被提议作为实验性协议而不是标准跟踪的原因之一。尽管如此，有一个简单的例子来说明使用CXTP可以如何从切换中获益，这似乎很有价值。我们在这里考虑的例子是传输IPv6 MLD状态[RCF2210]。MLD状态是一个特别好的示例，因为每个IPv6节点必须在执行路由器发现[RFC2461]或重复地址检测[RFC2462]之前或在发送/接收任何消息之前，在无线链路上执行至少一个MLD消息传递序列，以将自己建立为MLD侦听器
application-specific traffic (including Mobile IP handover signaling, if any). The node must subscribe to the Solicited Node Multicast Address as soon as it comes up on the link. Any application-specific multicast addresses must be re-established as well. Context transfer can significantly speed up re-establishing multicast state by allowing the nAR to initialize MLD for a node that just completed handover without any MLD signaling on the new wireless link. The same approach could be used for transferring multicast context in IPv4.
特定于应用程序的流量（包括移动IP切换信令，如果有）。节点必须在请求的节点多播地址出现在链路上时立即订阅该地址。任何特定于应用程序的多播地址也必须重新建立。上下文传输可以通过允许nAR为刚刚完成切换的节点初始化MLD而显著加快重新建立多播状态的速度，该节点在新无线链路上没有任何MLD信令。同样的方法也可用于在IPv4中传输多播上下文。
An approximate quantitative estimate for the amount of savings in handover time can be obtained as follows: MLD messages are 24 octets, to which the headers must be added, because there is no header compression on the new link, where the IPv6 header is 40 octets, and a required Router Alert Hop-by-Hop option is 8 octets including padding. The total MLD message size is 72 octets per subscribed multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report messages per address subscription, since the Report message is unacknowledged. Assuming 2 MLD messages sent for a subscribed address, the MN would need to send 144 octets per address subscription. If MLD messages are sent for both the All Nodes Multicast address and the Solicited Node Multicast address for the node's link local address, a total of 288 octets are required when the node hands over to the new link. Note that some implementations of IPv6 are optimized by not sending an MLD message for the All Nodes Multicast Address, since the router can infer that at least one node is on the link (itself) when it comes up and always will be. However, for purposes of this calculation, we assume that the IPv6 implementation is conformant and that the message is sent. The amount of time required for MLD signaling will depend on the per node available wireless link bandwidth, but some representative numbers can be obtained by assuming bandwidths of 20 kbps or 100 kbps. With these 2 bit rates, the savings from not having to perform the pre-router discovery messages are 115 msec. and 23 msec., respectively. If any application-specific multicast addresses are subscribed, the amount of time saved could be more substantial.
切换时间节省量的近似定量估计如下所示：MLD消息为24个八位字节，必须添加报头，因为新链路上没有报头压缩，其中IPv6报头为40个八位字节，并且所需的路由器警报逐跳选项为8个八位字节，包括填充。MLD消息的总大小为每个订阅的多播地址72个八位字节。RFC2710建议每个地址订阅节点发送2到3条MLD报告消息，因为报告消息未被确认。假设为订阅地址发送2个MLD消息，MN将需要为每个地址订阅发送144个八位字节。如果为所有节点的多播地址和请求的节点的链路本地地址的多播地址发送MLD消息，则当节点移交给新链路时，总共需要288个八位组。请注意，IPv6的一些实现通过不为所有节点多播地址发送MLD消息进行了优化，因为路由器可以推断至少有一个节点在链路（自身）上，并且总是在链路上。但是，出于此计算的目的，我们假设IPv6实现是一致的，并且消息已发送。MLD信令所需的时间将取决于每个节点可用的无线链路带宽，但是可以通过假设带宽为20 kbps或100 kbps来获得一些代表性的数字。使用这两个比特率，不必执行路由器前发现消息所节省的时间为115毫秒。和23毫秒。如果订阅了任何特定于应用程序的多播地址，则节省的时间量可能会更大。
This example might seem a bit contrived as MLD is not used in the 3G cellular protocols, and wireless local area network protocols typically have enough bandwidth if radio propagation conditions are optimal. Therefore, sending a single MLD message might not be viewed as a performance burden. An example of a wireless protocol where MLD context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. IEEE 802.15.1 has two IP "profiles": one with PPP and one without. The profile without PPP would use MLD. The 802.15.1 protocol has a maximum bandwidth of about 800 kbps, shared between all nodes on the link, so a host on a moderately loaded 802.15.1 access point could experience the kind of bandwidth described in the previous paragraph.
这个例子似乎有点做作，因为在3G蜂窝协议中没有使用MLD，并且如果无线传播条件是最佳的，则无线局域网协议通常具有足够的带宽。因此，发送单个MLD消息可能不会被视为性能负担。MLD上下文传输可能有用的无线协议的一个示例是IEEE 802.15.1（蓝牙）[BT]。IEEE 802.15.1有两个IP“配置文件”：一个有PPP，一个没有PPP。没有PPP的配置文件将使用MLD。802.15.1协议的最大带宽约为800 kbps，在链路上的所有节点之间共享，因此适度加载的802.15.1接入点上的主机可能会体验到上一段中描述的带宽。
In addition, 802.15.1 handover times are typically run upwards of a second or more because the host must resynchronize its frequency hopping pattern with the access point, so anything the IP layer could do to alleviate further delay would be beneficial.
此外，802.15.1切换时间通常超过1秒或更长，因为主机必须与接入点重新同步其跳频模式，因此IP层可以采取任何措施来缓解进一步的延迟都是有益的。
The context-specific data field for MLD context transfer included in the CXTP Context Data Block message for a single IPv6 multicast address has the following format:
单个IPv6多播地址的CXTP上下文数据块消息中包含的MLD上下文传输的上下文特定数据字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix on nAR Wireless Interface +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Subscribed IPv6 Multicast 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix on nAR Wireless Interface +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Subscribed IPv6 Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Subnet Prefix on a nAR Wireless Interface field contains a subnet prefix that identifies the interface on which multicast routing should be established. The Subscribed IPv6 Multicast Address field contains the multicast address for which multicast routing should be established.
nAR无线接口上的子网前缀字段包含子网前缀，该子网前缀标识应在其上建立多播路由的接口。订阅的IPv6多播地址字段包含应为其建立多播路由的多播地址。
The pAR sends one MLD context block per subscribed IPv6 multicast address.
PAR向每个订阅的IPv6组播地址发送一个MLD上下文块。
No changes are required in the MLD state machine.
MLD状态机中不需要任何更改。
Upon receipt of a CXTP Context Data Block for MLD, the state machine takes the following actions:
收到MLD的CXTP上下文数据块后，状态机将执行以下操作：
- If the router is in the No Listeners present state on the wireless interface on which the Subnet Prefix field in the Context Data Block is advertised, it transitions into the Listeners Present state for the Subscribed IPv6 Multicast Address field in the Context Data Block. This transition is exactly the same as if the router had received a Report message.
- 如果路由器在播发上下文数据块中的子网前缀字段的无线接口上处于无侦听器存在状态，则它将转换为上下文数据块中订阅的IPv6多播地址字段的侦听器存在状态。此转换与路由器收到报告消息时完全相同。
- If the router is in the Listeners present state on that interface, it remains in that state but restarts the timer, as if it had received a Report message.
- 如果路由器在该接口上处于侦听器当前状态，它将保持该状态，但会重新启动计时器，就像它已收到报告消息一样。
If more than one MLD router is on the link, a router receiving an MLD Context Data Block SHOULD send the block to the other routers on the link. If wireless bandwidth is not an issue, the router MAY instead send a proxy MLD Report message on the wireless interface that advertises the Subnet Prefix field from the Context Data Block. Since MLD routers do not keep track of which nodes are listening to multicast addresses (only whether a particular multicast address is being listened to) proxying the subscription should cause no difficulty.
如果链路上有多个MLD路由器，则接收MLD上下文数据块的路由器应将该块发送到链路上的其他路由器。如果无线带宽不是问题，路由器可以改为在无线接口上发送代理MLD报告消息，该消息从上下文数据块播发子网前缀字段。由于MLD路由器不跟踪哪些节点正在侦听多播地址（仅限于是否侦听特定的多播地址），代理订阅应该不会造成任何困难。
Authors' Addresses
作者地址
Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Rajeev Koodli诺基亚研究中心313 Fairchild Drive Mountain View，加利福尼亚州94043
EMail: rajeev.koodli@nokia.com
EMail: rajeev.koodli@nokia.com
John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland
John Loughney诺基亚Itdmerenkatu 11-13 00180埃斯波芬兰
EMail: john.loughney@nokia.com
EMail: john.loughney@nokia.com
Madjid F. Nakhjiri Motorola Labs 1301 East Algonquin Rd., Room 2240 Schaumburg, IL, 60196 USA
Madjid F.Nakhjiri摩托罗拉实验室美国伊利诺伊州绍姆堡东阿尔冈金路1301号2240室，邮编60196
EMail: madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
查尔斯·E·珀金斯诺基亚研究中心美国加利福尼亚州山景镇飞兆半导体大道313号，邮编94043
EMail: charles.perkins@.nokia.com
EMail: charles.perkins@.nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。