RFC4067 日本語訳
4067 Context Transfer Protocol (CXTP). J. Loughney, Ed., M. Nakhjiri,C. Perkins, R. Koodli. July 2005. (Format: TXT=77718 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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)
Context Transfer Protocol (CXTP)
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
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.
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
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
Loughney, et al. Experimental [Page 1] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 1] RFC 4067 Context Transfer Protocol (CXTP) July 2005
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
1. Introduction
1. Introduction
This document describes the Context Transfer Protocol, which provides:
This document describes the Context Transfer Protocol, which provides:
* Representation for feature contexts.
* Representation for feature contexts.
* Messages to initiate and authorize context transfer, and notify
a mobile node of the status of the transfer.
* 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.
* 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.
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
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.
"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.
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.
2) An additional motivation is to provide an interoperable solution that supports various Layer 2 radio access technologies.
Loughney, et al. Experimental [Page 2] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 2] RFC 4067 Context Transfer Protocol (CXTP) July 2005
1.2. Conventions Used in This Document
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].
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
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.
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
CXTP Context Transfer Protocol
DoS Denial-of-Service
DoS Denial-of-Service
FPT Feature Profile Types
FPT Feature Profile Types
PCTD Predictive Context Transfer Data
PCTD Predictive Context Transfer Data
2. Protocol Overview
2. Protocol Overview
This section provides a protocol overview. A context transfer can be
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").
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.
* 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).
* 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.
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.
Loughney, et al. Experimental [Page 3] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 3] RFC 4067 Context Transfer Protocol (CXTP) July 2005
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.
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.
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.
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
2.1. Context Transfer Scenarios
The Previous Access Router transfers feature contexts under two general scenarios.
The Previous Access Router transfers feature contexts under two general scenarios.
Loughney, et al. Experimental [Page 4] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 4] RFC 4067 Context Transfer Protocol (CXTP) July 2005
2.1.1. Scenario 1
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.
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.
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
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.
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
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
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
Loughney, et al. Experimental [Page 5] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 5] RFC 4067 Context Transfer Protocol (CXTP) July 2005
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.
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
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:
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 |
+----------------------+
| ... |
+----------------------+ | Message Header | +----------------------+ | CXTP Data 1 | +----------------------+ | CXTP Data 2 | +----------------------+ | ... |
Each context type specification contains the following details:
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.
- 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.
- 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.
- 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.
- 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.
Loughney, et al. Experimental [Page 6] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 6] RFC 4067 Context Transfer Protocol (CXTP) July 2005
2.4. Context Data Block (CDB)
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.
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
Length Message length in units of 8 octet words.
'P' bit 0 = No presence vector.
1 = Presence vector present.
'P' bit 0 = No presence vector. 1 = Presence vector present.
Reserved Reserved for future use. Set to
zero by the sender.
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.
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.
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.
Loughney, et al. Experimental [Page 7] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 7] RFC 4067 Context Transfer Protocol (CXTP) July 2005
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.
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
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.
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
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.
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.
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.
Loughney, et al. Experimental [Page 8] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 8] RFC 4067 Context Transfer Protocol (CXTP) July 2005
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
Vers. Version number of CXTP protocol = 0x1
Type CTAR = 0x1
Type CTAR = 0x1
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
'A' bit If set, the MN requests an acknowledgement.
'A' bit If set, the MN requests an acknowledgement.
Reserved Set to zero by the sender, ignored by the
receiver.
Reserved Set to zero by the sender, ignored by the receiver.
Length Message length in units of octets.
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'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.
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).
Sequence Number A value used to identify requests and acknowledgements (see Section 3.2).
Loughney, et al. Experimental [Page 9] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 9] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Authorization Token An unforgeable value calculated as
discussed below. This authorizes the
receiver of CTAR to perform context
transfer.
Authorization Token An unforgeable value calculated as discussed below. This authorizes the receiver of CTAR to perform context transfer.
Context Block Variable length field defined in
Section 2.4.
Context Block Variable length field defined in Section 2.4.
If no context types are specified, all contexts for the MN are requested.
If no context types are specified, all contexts for the MN are requested.
The Authorization Token is calculated as:
The Authorization Token is calculated as:
First (32, HMAC_SHA1
(Key, (Previous IP address | Sequence Number | CDBs)))
First (32, HMAC_SHA1 (Key, (Previous IP address | Sequence Number | CDBs)))
where Key is a shared secret between the MN and pAR, and CDB is a concatenation of all the Context Data Blocks specifying the contexts to be transferred that are included in the CTAR message.
where Key is a shared secret between the MN and pAR, and CDB is a concatenation of all the Context Data Blocks specifying the contexts to be transferred that are included in the CTAR message.
2.5.2. Context Transfer Activate Acknowledge (CTAA) Message
2.5.2. Context Transfer Activate Acknowledge (CTAA) Message
This is an informative message sent by the receiver of CTAR to the MN to acknowledge a CTAR message. Acknowledgement is optional, depending on whether the MN requested it. This message may include a list of FPTs that were not successfully transferred.
This is an informative message sent by the receiver of CTAR to the MN to acknowledge a CTAR message. Acknowledgement is optional, depending on whether the MN requested it. This message may include a list of FPTs that were not successfully transferred.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Vers. Version number of CXTP protocol = 0x1
Type CTAA = 0x2
Type CTAA = 0x2
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored by
the receiver.
Reserved Set to zero by the sender and ignored by the receiver.
Loughney, et al. Experimental [Page 10] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney, et al. Experimental [Page 10] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Length Message length in units of octets.
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.
ミネソタのPrevious IP Address Fieldはどちらかを含んでいます: IPv4[RFC791]アドレス、4つの八重奏、またはIPv6[RFC3513]アドレス、16の八重奏。
FPT 16 bit unsigned integer, listing the Feature
Profile Type that was not successfully
transferred.
首尾よく移されなかったFeature Profile Typeを記載して、FPT16は符号のない整数に噛み付きました。
Status Code An octet, containing failure reason.
失敗理由を含む状態Code An八重奏。
........ more FPTs and status codes as necessary
…… 必要に応じてより多くのFPTsとステータスコード
2.5.3. Context Transfer Data (CTD) Message
2.5.3. 文脈転送データ(CTD)メッセージ
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データ)を含めます。 このメッセージは予言のものと同様に正常なコネチカットを扱います。 承認旗('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| タイプ|V|A| 予約されます。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経過したTime(ミリセカンドによる)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous Care-of Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | アルゴリズム| キー長| +++++++++++++++++++++++++++++++++PCTD| キー| 単に ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Vers。 CXTPプロトコル=0x1のバージョン番号
Type CTD = 0x3 (Context Transfer Data)
PCTD = 0x4 (Predictive Context Transfer
Data)
0×3(文脈転送データ)CTD=PCTD=0×4をタイプしてください。(予言の文脈転送データ)
Loughney, et al. Experimental [Page 11] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[11ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'V'旗のWhenは'0'、IPv6アドレスにセットしました。 '1'に設定されると、IPv4アドレスです。
'A' bit When set, the pAR requests an
acknowledgement.
ビット、Whenはセットして、pARは承認を要求します。
Length Message length in units of octets.
ユニットの八重奏における長さのMessageの長さ。
Elapsed Time The number of milliseconds since the
transmission of the first CTD message for
this MN.
最初のCTDのトランスミッション以来のミリセカンドの数がこのミネソタへ通信させる経過したTime。
MN's Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
ミネソタのPrevious IP Address Fieldはどちらかを含んでいます: 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.
ミネソタAuthorization Tokenの計算を行うためのアルゴリズムAlgorithm。 現在の、1つのアルゴリズムだけが定義されて、HMAC_SHA1は=1です。
Key Length Length of key, in octets.
八重奏におけるキーの主要なLength Length。
Key Shared key between MN and AR for CXTP.
CXTPに、ミネソタとARの間で主要な主要なShared。
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がヌルAuthorization Tokenと共にCTDメッセージを受け取るなら、この材料を送ります、nARがCTARメッセージを受け取る前にコネチカット-Reqメッセージが送られたのを示して。 CTD MUST、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.
以前に説明されるように、ミネソタAuthorization Tokenの計算を行うためのアルゴリズムは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からミネソタの前のIPアドレスへのCTDRメッセージを受け取ったか、またはコネチカット_マックス_HANDOVER_タイム誌が期限が切れるまで、pAR SHOULDはCTAR一連番号の動向をおさえて、CTDメッセージをキャッシュします。 nARは予言のCTDメッセージが到着しなかったか、または文脈が崩壊したなら同じ一連番号を含むコネチカット-Reqメッセージを送るかもしれません。 この場合nAR
Loughney, et al. Experimental [Page 12] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[12ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
sends a CT-Req message with a matching sequence number and pAR can resend the context.
合っている一連番号とpARがあるメッセージが再送できるコネチカット-Reqに文脈を送ります。
2.5.4. Context Transfer Data Reply (CTDR) Message
2.5.4. 文脈転送データ回答(CTDR)メッセージ
This message is sent by nAR to pAR depending on the value of the 'A' flag in CTD, indicating success or failure.
このメッセージはnARによってCTDの'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|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| タイプ|V|S| 予約されます。| 長さ| モバイル..ノード..前..アドレス| FPT(存在しているなら)| ステータスコード| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Vers。 CXTPプロトコル=0x1のバージョン番号
Type CTDR = 0x5 (Context Transfer Data)
CTDR=0x5をタイプしてください。(文脈転送データ)
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'V'旗のWhenは'0'、IPv6アドレスにセットしました。 '1'に設定されると、IPv4アドレスです。
'S' bit When set to one, this bit indicates
that all feature contexts sent in CTD
or PCTD were received successfully.
''ビットWhenが1つに用意ができていたか、このビットが、すべてがCTDで送られた文脈を特徴とするのを示すか、または首尾よくPCTDを受け取りました。
Reserved Set to zero by the sender and ignored by
the receiver.
送付者であって受信機によって無視されるのはSetをゼロまで予約しました。
Length Message length in units of octets.
ユニットの八重奏における長さのMessageの長さ。
MN's Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
ミネソタのPrevious IP Address Fieldはどちらかを含んでいます: IPv4[RFC791]アドレス、4つの八重奏、またはIPv6[RFC3513]アドレス、16の八重奏。
FPT 16 bit unsigned integer, listing the Feature
Profile Type that is being acknowledged.
承認されているFeature Profile Typeを記載して、FPT16は符号のない整数に噛み付きました。
Status Code A context-specific return value,
zero for success, nonzero when 'S' is
not set to one.
'状態Code A文脈詳細が値、成功のためのゼロを返して、非零がいつか、'1つにはセットがありません。
Loughney, et al. Experimental [Page 13] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[13ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
2.5.5. Context Transfer Cancel (CTC) Message
2.5.5. 文脈転送キャンセル(CTC)メッセージ
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に送るかもしれません。
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| タイプ|V| 予約されます。| 長さ| モバイル..ノード..前..アドレス
Vers. Version number of CXTP protocol = 0x1
Vers。 CXTPプロトコル=0x1のバージョン番号
Type CTC = 0x6 (Context Transfer Cancel)
CTC=0x6をタイプしてください。(文脈転送キャンセル)
Length Message length in units of octets.
ユニットの八重奏における長さのMessageの長さ。
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'V'旗のWhenは'0'、IPv6アドレスにセットしました。 '1'に設定されると、IPv4アドレスです。
Reserved Set to zero by the sender and ignored by
the receiver.
送付者であって受信機によって無視されるのはSetをゼロまで予約しました。
MN's Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
ミネソタのPrevious IP Address Fieldはどちらかを含んでいます: IPv4[RFC791]アドレス、4つの八重奏、またはIPv6[RFC3513]アドレス、16の八重奏。
2.5.6. Context Transfer Request (CT-Req) Message
2.5.6. 文脈転送要求(コネチカット-Req)メッセージ
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.
文脈転送の始まりを要求するためにnARによってpARに送られます。 CTARメッセージへの応答としてこのメッセージを送ります。 ミネソタのPrevious IPアドレスに従う分野はCTARメッセージから逐語的に含まれています。
Loughney, et al. Experimental [Page 14] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[14ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
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| タイプ|V| 予約されます。| 長さ| モバイル..ノード..前..アドレス| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mn承認トークン| 次..現在 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
Vers。 CXTPプロトコル=0x1のバージョン番号
Type CTREQ = 0x7 (Context Transfer Request)
CTREQ=0x7をタイプしてください。(文脈転送要求)
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'V'旗のWhenは'0'、IPv6アドレスにセットしました。 '1'に設定されると、IPv4アドレスです。
Reserved Set to zero by the sender and ignored
by the receiver.
送付者であって受信機によって無視されるのはSetをゼロまで予約しました。
Length Message length in units of octets.
ユニットの八重奏における長さのMessageの長さ。
MN's Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
ミネソタのPrevious IP Address Fieldはどちらかを含んでいます: IPv4[RFC791]アドレス、4つの八重奏、またはIPv6[RFC3513]アドレス、16の八重奏。
Sequence Number Copied from the CTAR message, allows the
pAR to distinguish requests from previously
sent context.
以前に送られた文脈と要求を区別するpARはCTARからの系列Number Copiedを通信させます。
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.
ミネソタはセクション2.5.1で議論するように計算してありますAuthorization Token An unforgeableが、評価する。 これは、CTARの受信機が文脈転送を実行するのを認可します。 CTARから、コピーされます。
Context Data Request Block
A request block for context data; see
Section 2.4.
文脈Data Request Block Aは文脈データのためにブロックを要求します。 セクション2.4を見てください。
Loughney, et al. Experimental [Page 15] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[15ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
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によって使用されます。 予言の転送では、ミネソタが引き渡しの前にCTARを送るなら、pARは、nARにPCTDを使用することで文脈を押します。 CTDが失敗すると、nARは同じ一連番号と共にコネチカット-Reqを送るでしょう、pARが、どの文脈を再送したらよいかを決定するのを可能にして。 pARはCXTP_マックス_TRANSFER_タイム誌の後に文脈を削除します。 一連番号は反応転送に使用されません。
For predictive transfer, the pAR sends the keying material and other information necessary to calculate the Authorization Token without having processed a CT-Req message. For reactive transfer, if the nAR receives a context transfer trigger but has not yet received the CTAR message with the authorization token, the Authorization Token field in CT-Req is set to zero. The pAR interprets this as an indication to include the keying material and other information necessary to calculate the Authorization Token, and includes this material into the CTD message as if the message were being sent due to predictive transfer. This provides nAR with the information it needs to calculate the authorization token when the MN sends CTAR.
予言の転送のために、pARはコネチカット-Reqメッセージを処理していなくてAuthorization Tokenについて計算するのに必要な材料と他の情報を合わせるのに送ります。 反応転送において、nARが文脈転送引き金を受けますが、承認トークンでまだCTARメッセージを受け取っていないなら、コネチカット-ReqのAuthorization Token分野はゼロに設定されます。 pARはAuthorization Tokenについて計算するために合わせることの材料と他の必要情報を含むように指示としてこれを解釈して、まるで予言の転送のためメッセージを送るかのようにCTDメッセージにこの材料を含めます。 これはそれがミネソタがCTARを送るとき、承認トークンについて計算するために必要とする情報をnARに提供します。
3. Transport
3. 輸送
3.1. Inter-Router Transport
3.1. 相互ルータ輸送
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展開が、公共のインターネットを中を走らせることを伴うなら、混雑を収容するデフォルトトランスポート・プロトコルを推薦するのは慎重に思えます。 さらに、特徴文脈情報には明確な寿命があるので、トランスポート・プロトコルはフレキシブルな「再-トランスミッション」を収容しなければなりません、非常に聞き古したである、混雑で妨げられる文脈は下げられます。 最終的に、文脈データの量が任意に大きい場合があるので、トランスポート・プロトコルは、単一のパケットに制限されるべきではありませんし、またカスタム断片化プロトコルを実装するのを必要とするべきではありません。
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 MUSTサポートの実装、およびCXTP SHOULD使用のプロトタイプ展開、相互ルータのトランスポート・プロトコルとしてのStream Control Transportプロトコル(SCTP)[SCTP]が連結すると主張します、特に公共のインターネットの上の展開が熟考されるなら。 SCTPは、混雑がプログラマブル再送信タイマーに基づくコントロールと、断片化と、部分的な「再-トランスミッション」であるとサポートします。 また、SCTPは進められた多く、複合体をサポートします。
Loughney, et al. Experimental [Page 16] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[16ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
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有効搭載量Data Chunkは文脈転送プロトコルメッセージを伝えます。 それぞれのSCTPメッセージのUser Data部分は本書では定義された適切な文脈転送プロトコルメッセージを含んでいます。 SCTPが使用させられたメッセージは、CTD(セクション2.5.3)と、CTDR(セクション2.5.4)と、CTC(セクション2.5.5)と、コネチカット-Req(セクション2.5.6)です。 一般に、それぞれのSCTPメッセージはどんなミネソタにも属す特徴文脈を運ぶことができます。 SCTPチェックサム計算が失敗するなら、nARはCTDRメッセージのBAD_CHECKSUMエラーコードを返します。
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メッセージの配送なしで使用されます。 各メッセージは単一のミネソタの特徴文脈収集に対応しています。 ただ一つのストリームは簡単さを提供します。 今後の研究には系列のヘッドブロッキングを防ぐ複数のストリームの使用があります。 順不同の配送は受信機を連続して異なったMNsに属すメッセージの配送のためのどんなブロックまでも許容しません。 SCTPヘッダーの有効搭載量プロトコルIdentifierは'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.
文脈のタイムリーは情報SHOULDを移します。コネチカット_マックス_TRANSFER_タイム誌へのSCTPの最大の「再-トランスミッション」価値に最大の許容できる引き渡し遅延時間を収容するように設定することによって、設備されてください。 AR SHOULD、コネチカット_マックス_TRANSFER_タイム誌によって構成されて、特定のワイヤレスのリンク技術と地方のワイヤレスの伝播状態に対応してください。 SCTPは、SHOULDを添付しながら、通信します。メッセージを送りながら付加的な遅れを下げるために、オフにされます。 CXTPの中では、nAR SHOULDは、CXTPメッセージの最初の断片の領収書から再送信タイマを見積もって、文脈転送が完全であるか、またはおよそ再送信タイマが期限が切れるまで、ミネソタからどんなIPトラフィックも処理するのを避けます。 両方のルータが、PR-SCTPが[PR-SCTP]、当時のPR-SCTP SHOULDであるとサポートするなら、使用されてください。 PR-SCTPはSend()操作(セクション10.1では、[SCTP]でEを定義する)の生涯パラメタを変更します。それが申し込むそうは、再送して、伝わります。 すなわち、PR-SCTPでは、寿命が期限が切れて、データ塊が承認されていないなら、送信機は、ベースプロトコルで、データが承認されるまで再送されただろうか、または接続が外で調節しましたが、再送するのを止めます。
Loughney, et al. Experimental [Page 17] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[17ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
The format of Payload Data Chunk taken from [SCTP] is shown in the following diagram.
[SCTP]から取られた有効搭載量Data Chunkの書式は以下のダイヤグラムで示されます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0をタイプしてください。| 予約されます。|U|B|E| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ストリーム識別子S| ストリームSequence Number n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量プロトコル識別子| ユーザ
'U' bit The Unordered bit. MUST be set to 1 (one).
'B' bit The Beginning fragment bit. See [SCTP].
'U'はUnorderedビットに噛み付きました。 1(1)に設定しなければなりません。 'B'はBeginning断片ビットに噛み付きました。 [SCTP]を見てください。
'E' bit The Ending fragment bit. See [SCTP].
'E'はEnding断片ビットに噛み付きました。 [SCTP]を見てください。
TSN Transmission Sequence Number. See [SCTP].
TSNトランスミッション一連番号。 [SCTP]を見てください。
Stream Identifier S
Identifies the context transfer protocol
stream.
文脈転送プロトコルが流すIdentifier S Identifiesを流してください。
Stream Sequence Number n
Since the 'U' bit is set to one, the
receiver ignores this number. See [SCTP].
'U'が噛み付いたストリームSequence Number n Sinceは1つに用意ができて、受信機はこの数を無視します。 [SCTP]を見てください。
Payload Protocol Identifier
Set to 'CXTP' (see [IANA]).
有効搭載量プロトコル識別子は'CXTP'にセットしました([IANA]を見てください)。
User Data Contains the context transfer protocol
messages.
文脈が移すユーザData Containsはメッセージについて議定書の中で述べます。
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展開が公共のインターネットを決して中を走らせないで、混雑がアクセスネットワークで問題でないことが知られているなら、代替のトランスポート・プロトコルは実験のための適切な手段であるかもしれません。 例えば、FMIPv6によってICMP[FMIPv6]に供給されるようにルーティングのために合図しながら、引き渡しの上でCXTPメッセージを背負うこと。 CXTP MAYの実装はそのような目的のためにICMPをサポートします。 そのような便乗が使用されているなら、CXTPが便乗しているプロトコルのための実験的なメッセージ拡張子を設計しなければなりません。 また、実験目的のためのトランスポート・プロトコルの上のダイレクト展開も可能です。 この場合研究者
Loughney, et al. Experimental [Page 18] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[18ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
MUST be careful to accommodate good Internet transport protocol engineering practices, including using retransmits with exponential backoff.
良いインターネットトランスポート・プロトコルエンジニアリング方式を収容するのに慎重でなければならなく、使用するのを含んでいるのを指数のbackoffで再送されます。
3.2. MN-AR Transport
3.2. ミネソタ-AR輸送
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:
ミネソタ-ARインタフェースは実装しなければなりません、そして、SHOULDはCTARとCTAAメッセージを輸送するのにICMPを使用します。 ICMPがシグナリングが無くなるならパケットを再送するための条項を全く含んでいないので、CXTPプロトコルはミネソタ-ARインタフェースに関する輸送性能を向上させるための条項を取り入れます。 メッセージが単一のパケットに収まるようにCTARとCTAAメッセージに識別子を含んでいて、ミネソタとAR SHOULDは文脈データ・ブロックの数を制限します、IPレベルを超えてICMPには断片化への支給が全くないので。 CXTPはExperimental Mobility 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ… +-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
IP分野:
Source Address An IP address assigned to the sending
interface.
送付インタフェースに割り当てられたソースAddress An IPアドレス。
Destination Address
An IP address assigned to the receiving
interface.
受信インタフェースに割り当てられた送付先Address An IPアドレス。
Hop Limit 255
ホップ限界255
ICMP Fields:
ICMP分野:
Type Experimental Mobility Type (To be assigned by IANA,
for IPv4 and IPv6, see [IANA])
実験移動性タイプをタイプしてください。(IPv4とIPv6のためにIANAによって割り当てられるには、[IANA]を見てください)
Code 0
コード0
Checksum The ICMP checksum.
チェックサム、ICMPチェックサム。
Loughney, et al. Experimental [Page 19] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[19ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
Sub-type The Experimental Mobility ICMP subtype for CXTP,
see [IANA].
サブタイプ、Experimental Mobility ICMP subtype、CXTPに関しては、[IANA]を見てください。
Reserved Set to zero by the sender and ignored by
the receiver.
送付者であって受信機によって無視されるのはSetをゼロまで予約しました。
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_REQUEST_RETRY待ちの期間の後に現れます。 指数関数的に増加する待ち間隔でRetransmissionsを作らなければなりません(その都度待ちを倍にして)。 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 SHOULDはCTARメッセージで手当たりしだいに(また、同じ一連番号が最後の7秒間使用されていないのを確実にする)一連番号を生成して、pARのようにCTARメッセージで同じ一連番号をnARに使用しなければなりません。 同じ一連番号とミネソタIPアドレスで既に1を受け取ったなら、アルゴンは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 Fast Binding Update[FMIPv6]との使用がミネソタからARまで合図するルーティング変化と文脈転送の両方のバンドリング、またはICMPの代わりにUDPプロトコルの定義を許すモバイルIPv6 Mobility Header[MIPv6]の定義です。 そのような実装が完了しているなら、それらは、慎重に良いインターネット交通工学習慣を守って、プロトタイプとデモンストレーションの目的だけに使用されるべきです。 輸送の特性がよく理解されるまで、大規模ネットワークにおける展開は避けられるべきです。
4. Error Codes and Constants
4. エラーコードと定数
Error Code Section Value Meaning ------------------------------------------------------------
エラーコードセクション値の意味------------------------------------------------------------
BAD_CHECKSUM 3.1 0x01 Error code if the
SCTP checksum fails.
BAD_CHECKSUM3.1 0×01ErrorコードはSCTPチェックサムであるなら失敗します。
Loughney, et al. Experimental [Page 20] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[20ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
Constant Section Default Value Meaning --------------------------------------------------------------------
一定のセクションデフォルト値意味--------------------------------------------------------------------
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of
sec. CTAR messages before
AR institutes rate
limiting.
コネチカット_REQUESTの_のRATE6.3 10の要求/最大の番号の秒 AR研究所の前のCTARメッセージは制限を評定します。
CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time
pAR should wait before
aborting the transfer.
転送を中止する前にpARが待つはずであるコネチカット_マックス_TRANSFER_タイム誌3.1 200ms Maximum時間。
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
初期である前にコネチカット_REQUEST_RETRY3.2 2秒、Wait間隔はミネソタ-ARインタフェースで再送します。
CT_RETRY_MAX 3.2 15 seconds Give up retrying
on MN-AR interface.
コネチカット_RETRY_MAX3.2 15秒、ミネソタ-ARで再試行することへのGiveは連結します。
5. Examples and Signaling Flows
5. 例とシグナリング流れ
5.1. Network Controlled, Initiated by pAR, Predictive
5.1. ネットワーク、制御されて、平価で開始されて、予言
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E |------- CTAR -------->| |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |
Mn nAR平価| | | T| | コネチカット引き金I| | | M| | <、-、-、-、-、-、-- CTD----------| E|------- CTAR-------->|、| : | | | | | |-------- CTDR-------->| V| | | | | |
5.2. Network Controlled, Initiated by nAR, Reactive
5.2. nARによって開始されて、反応していた状態で制御されたネットワーク
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |--------- CT-Req ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V |------- CTAR -------->| |
| |----- CTDR (opt) ----->|
| | |
Mn nAR平価| | | T| コネチカット引き金| I| | | M| |--------- コネチカット-Req----->| E| | | : | | <、-、-、-、-、-、-- CTD----------| | | | | V|------- CTAR-------->|、|、| |----- CTDR(選びます)----->|、|、|、|
Loughney, et al. Experimental [Page 21] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[21ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
5.3. Mobile Controlled, Predictive New L2 up/Old L2 down
5.3. モバイル制御されて、予言の新しいL2上がっているか古いL2はダウンします。
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平価| | | 新しいL2は結び付きます。| | | | | コネチカット引き金| | | | | T|------- CTAR-------->|、| I| |-------- コネチカット-Req------>| M| | | E| | <、-、-、-、-、-、-、-- CTD---------| : | | | | | | | V| | | | | |
Whether the nAR sends the MN a CTAR reject message if CT is not supported is for future study.
今後の研究にはコネチカットがサポートされないならnARがCTAR廃棄物メッセージをミネソタに送るかどうかがあります。
6. Security Considerations
6. セキュリティ問題
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引き渡しと特に文脈転送への脅威は特にARリンクへのミネソタで広く理解されていません、そして、それらを打ち返すためのメカニズムはよく定義されません。 最後の標準化過程のためにCXTPを準備することにおける実験タスクの一部は、文脈転送への脅威を特徴付けるほうがよくて、それらを打ち返すように特定のメカニズムを設計することでしょう。 このセクションはDesign Teamと作業部会のメンバーの中で議論に基づくセキュリティに関するいくつかの一般的ガイドラインを提供します。
6.1. Threats
6.1. 脅威
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.
Context Transferプロトコルはアクセスルータの間の状態を移します。 MNsがネットワークで移行する前に認証されて、認可されないなら、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攻撃を試みて、にせの文脈転送要求を出すかもしれません。
Loughney, et al. Experimental [Page 22] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[22ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
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]を見てください。
6.2. Access Router Considerations
6.2. アクセスルータ問題
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)の間の安全なチャンネルを確立する必要性のため追加潜在の導入を避けるために、2ARs SHOULDはあらかじめ、そのような安全なチャンネルを確立します。 2つのアクセスルータが、どんな今度の文脈転送を予測してIKE[RFC2409]などの主要な交換メカニズムに従事するのが必要であり、IPSec SAsを設立して、キー、アルゴリズム、およびIPSecプロトコル(超能力などの)を定義します。 これは安全な転送を必要とする身柄の引き渡しの間の時間を節約するでしょう。 2ARsの間のすべての今度の文脈転送にそのようなSAsを維持して、使用できます。 セキュリティは文脈の発信の前に交渉されるべきです。
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.
アクセスRoutersが、IPsecが交通機関において超能力[超能力]であると非ヌル暗号化と提供する認証アルゴリズムで実装しなければならない、-、パケット認証、保全保護、および秘密性、反復操作による保護がIPsecのメカニズムであると実装しなければなりません。 IP層の保護が必要であり、トンネルモードにおける超能力がSHOULDであるそれらのシナリオでは、使用されてください。 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ルーティング・プロトコルセキュリティワーキンググループにもたらされるでしょう。
Loughney, et al. Experimental [Page 23] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[23ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
6.3. Mobile Node Considerations
6.3. モバイルノード問題
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メッセージは、ミネソタとARには承認トークンについて計算するために主要な共有秘密キーがあるのを必要とします。 このトークンの合法化はミネソタのための文脈の文脈転送かインストールに先行しなければなりません、攻撃者が権限のない転送を引き起こす場合があった危険を取り除いて。 この仕様の範囲の外に共有されたキーがどう設立されるかがあります。 ミネソタとARが知っている両方が相手の公開鍵を公認したなら、共有された秘密鍵が[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はキーを捨てなければなりません。 ミネソタは将来のCXTPトランザクションのためにARと共に新しいキーを設立しなければなりません。 ミネソタとAR SHOULDはまた、文脈転送を認可するのに他の目的のために設立されたキーを使用するのに注意を訓練します。 文脈転送承認のための別々のキーの設立はRECOMMENDEDです。
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.
文脈が維持される期間を制限することによって、ミネソタ-ARプロトコルにおける反復操作による保護を提供します。 予言の転送のために、pARは一連番号でCTARメッセージを受け取って、承認トークンキーと共に文脈を移して、次に、すぐ転送の完成のときに主要な文脈と承認トークンを下げます。 反応転送のために、nARはCTARを受けて、要求は転送が認可されているかどうかpARをチェックするCTARメッセージからの一連番号と承認トークンを含んでいる文脈です。 転送が終了した後にpARは文脈と承認トークンキーを下げます。 pARとnARは傑出しているCTARかCTDメッセージが認められなく、外で調節されていないなら同じミネソタIPアドレスを含むどんな要求も無視します。 キーが下げられた後に承認トークンが失敗するので再生への試みが有効にしないいずれでもあります。 アルゴンは元々キーを所有していたミネソタを含むどんなミネソタにもキーを再利用してはいけません。
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
ARレートにそれが処理するCTARメッセージの数を制限させることによって、ミネソタ-ARインタフェースに対するDoS攻撃を制限できます。 AR SHOULDはCTARメッセージの数を_コネチカットREQUEST_RATEに制限します。 要求がこのレートを超えているなら、レートが確立されるまで、AR SHOULDは手当たりしだいにメッセージを下げます。 構成されていて、実際がSHOULDを評定する、オン
Loughney, et al. Experimental [Page 24] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[24ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
AR to match the maximum number of handovers that the access network is expected to support.
アクセスネットワークがサポートすると予想される身柄の引き渡しの最大数を合わせるAR。
7. Acknowledgements & Contributors
7. 承認と貢献者
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ワーキンググループのいすによって形成されたデザインチームの結果です。 チームはジョンLoughney、Madjid Nakhjiri、Rajeev Koodli、およびチャールズ・パーキンスを含めました。
Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the Context Transfer Protocol review.
Basavarajパティル、ペッカSavola、およびAntti TuominenはContext Transferプロトコルレビューに貢献しました。
The working group chairs are Pat Calhoun and James Kempf, whose comments have been very helpful in the creation of this specification.
ワーキンググループいすは、パットCalhounとジェームス・ケンフです。そのコメントはこの仕様の作成に非常に役立っています。
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.
また、作者はこのドキュメントによる彼らの助けと提案についてジュリアンBournelle、ビジェイDevarapalli、ダン・フォルスバーグ、Xiaomingフー、マイケルGeorgiades、ユスフMotiwala、フィルNeumiller、Heshamソリマン、およびルシアン・スチウに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、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] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年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] スチュワート、R.、Ramalho(M.、シェ、Q.、Tuexen、M.、およびP.コンラッド)は「制御伝動のプロトコルの(SCTP)部分的な信頼性の拡大を流します」、RFC3758、2004年5月。
Loughney, et al. Experimental [Page 25] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[25ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
[IANA] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[IANA] ケンフ、J.、「Seamobyと実験的な移動性プロトコルIANA配分のための指示」、RFC4065、2005年7月。
8.2. Informative References
8.2. 有益な参照
[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.パーキンス、「速い身柄の引き渡しと背景転送」、ACM Computing Communication Review、第31巻、No.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.
[TEXT]M.Nakhjiri、「シームレスのIPの移動性のためのSelectiveの信頼性がある時間の効率的な文脈転写法」、2003年のIEEE VTC秋、VTC2003Proceedings、Vol.3(2003年10月)。
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[FMIPv6] Koodli、R.、エド、「速く、モバイルIPv6"、RFC4068、2005年7月に、引き渡します」。
[LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile
IPv4", Work in Progress.
[LLMIP] K. El Malki他、「モバイルIPv4"の低遅延Handoffs、処理中の作業。」
[RFC3374] Kempf, J., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network",
RFC 3374, September 2002.
[RFC3374]ケンフ、J.、「問題記述:」 「IPアクセスネットワークでノードの間の文脈転送を実行する理由」、RFC3374、2002年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[TERM] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
2004年6月のRFC3753年の「移動性は用語を関係づけた」という[用語]方法、J.、およびM.Kojo。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[RFC2631] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。
[PerkCal04] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005.
[PerkCal04] パーキンスとC.とP.カルフーン、「モバイルIPv4"、RFC3957、2005年3月のための認証、承認、および会計(AAA)登録キー。」
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[MIPv6] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[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.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
Loughney, et al. Experimental [Page 26] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[26ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンと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] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 フレームワークと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[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 Standard--システムの間の電気通信と情報交換--LAN/MAN--15.1を分けてください」 「Wirelessパーソナル・エリア・ネットワーク(WPANs)のためのワイヤレスのMedium Access Control(MAC)とPhysical Layer(PHY)仕様」、IEEE Standard、802.15、.1、2002
[EAP] Aboba, B., Simon, D., Arkko, J., Eron, P., and H.
Levokowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", Work in Progress.
B.、サイモン、D.、Arkko、J.、Eron、P.、およびH.Levokowetz、「拡張認証プロトコル(EAP)Key Managementフレームワーク」という[EAP]Abobaは進行中で働いています。
Loughney, et al. Experimental [Page 27] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[27ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
Appendix A. Timing and Trigger Considerations
付録A.タイミングと引き金の問題
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潜在とパケット損失はいくつかの交替手続きで最適化されます、FastのモバイルIP[FMIPv6]やLow Latencyのモバイル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.
文脈転送による特徴再建は身柄の引き渡しに関連してサービスのゼロ(最適である)か最小量の付加的な分裂を寄付するべきです。 これは、文脈転送SHOULDのタイミングが慎重に基本的なモバイル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引き渡しメカニズムがタイミングを選んで、様々な文脈情報の転送のために注文するのにより多くの柔軟性を提供するかもしれません。
Appendix B. Multicast Listener Context Transfer
付録B.マルチキャストリスナー文脈転送
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に提出されたドキュメントのいずれも作業部会項目として認められませんでした。RFC3095ヘッダー圧縮文脈[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がStandards TrackよりむしろExperimentalプロトコルとして提案されている1つの理由です。 それにもかかわらず、引き渡しがCXTPを使用するのからどう利益を得ることができたかを示している簡単な例を持っているのは貴重に思えます。 私たちがここで考える例はIPv6 MLD状態[RFC2710]を移しています。 あらゆるIPv6ノードがルータ発見[RFC2461]か写しアドレス検出[RFC2462]を実行する前かいずれも送るか、または受ける前にMLDリスナーとして定着するように少なくとも1つのMLDメッセージング系列をワイヤレスのリンクに実行しなければならないので、MLD状態は特に好例です。
Loughney, et al. Experimental [Page 28] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[28ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
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引き渡しシグナリングを含んでいますもしあれば)。 リンクに近づくとすぐに、ノードはSolicited Node Multicast Addressに加入しなければなりません。 また、どんなアプリケーション特有のマルチキャストアドレスも復職させなければなりません。 文脈転送は、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の八重奏であり、必要なホップによるRouter Alert Hopオプションはそっと歩くのを含む8つの八重奏です。 申し込まれたマルチキャストアドレスあたり総MLDメッセージサイズは72の八重奏です。 RFC2710は、ノードがアドレス購読あたり2〜3つのMLD Reportメッセージを送ることを勧めます、Reportメッセージが認められないので。 MLDメッセージが申し込まれたアドレス、ミネソタに送った仮定2は、アドレス購読あたり144の八重奏を送る必要があるでしょう。 新しいリンクへのノード手であるときに、ノードのリンクローカルアドレスのためのAll Nodes MulticastアドレスとSolicited Node Multicastアドレスの両方のためにMLDメッセージを送るなら、合計288の八重奏を必要とします。 IPv6のいくつかの実装がAll Nodes Multicast AddressへのMLDメッセージを送らないことによって最適化されることに注意してください、ルータが、それが来て、いつもあるとき、リンク(それ自体)の上に少なくとも1つのノードがあると推論できるので。 しかしながら、この計算の目的のために、私たちは、IPv6実装がconformantであり、メッセージが送られると思います。 MLDシグナリングのための所要時間がよる、ノードの利用可能なワイヤレスのリンク帯域幅に従って、20キロビット毎秒か100キロビット毎秒の帯域幅を仮定することによって、数個の代表している数しか得ることができません。 プレルータ発見メッセージを実行する有でないのからのこれらの2つのビット伝送速度、貯蓄で、115msec23msecがそうである、それぞれ。 何かアプリケーション特有のマルチキャストアドレスが申し込まれるなら、節約された時間は、より実質的であるかもしれません。
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.
この例は、MLDがそうように少し案出されて、ラジオ伝播状態が最適であるなら3Gのセルプロトコルで中古の、そして、ワイヤレスでないローカル・エリア・ネットワークプロトコルには十分な帯域幅が通常あるように思えるかもしれません。 したがって、ただ一つのMLDメッセージを送るのは性能負担として見なされないかもしれません。 MLD文脈転送が役に立つかもしれないワイヤレスのプロトコルに関する例はIEEE802.15.1(ブルートゥース)[BT]です。 IEEE802.15.1には、2IP「プロフィール」があります: PPPがある1と1 PPPのないプロフィールはMLDを使用するでしょう。 802.15.1プロトコルにはリンクの上のすべてのノードの間で共有されたおよそ800キロビット毎秒の最大の帯域幅があるので、適度にロードされた802.15.1アクセスポイントのホストは前のパラグラフで説明された帯域幅の種類を経験できました。
Loughney, et al. Experimental [Page 29] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[29ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
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が回を引き渡す、ホストが再連動しなければならないのでそれがアクセスポイントがあるパターン、IP層がさらなる遅れを軽減するためにできたことが頻度の跳んでいるそうであるだろう有益である通常実行された1秒以上はそうです。
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 Context Data Blockメッセージに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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + nARワイヤレスインターフェース+のサブネット接頭語| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 申し込まれたIPv6マルチキャストアドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Wireless InterfaceフィールドのSubnet Prefixはマルチキャストルーティングが確立されるべきであるインタフェースを特定するサブネット接頭語を含んでいます。 Subscribed IPv6 Multicast Address分野はマルチキャストルーティングが確立されるべきであるマルチキャストアドレスを含んでいます。
The pAR sends one MLD context block per subscribed IPv6 multicast address.
pARは申し込まれたIPv6マルチキャストアドレスあたり1つの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 Context Data Blockを受け取り次第、州のマシンは以下の行動を取ります:
- 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.
- ルータがContext Data BlockのSubnet Prefix分野が広告に掲載されているワイヤレスインターフェースのいいえListeners現状にあるなら、それはContext Data BlockのSubscribed IPv6 Multicast Address分野のためにListeners Present状態に移行します。 まるでルータがReportメッセージを受け取ったかのようにこの変遷はまさに同じです。
Loughney, et al. Experimental [Page 30] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[30ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
- 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.
- ルータがそのインタフェースのListeners現状にあるなら、その州に残っていますが、タイマを再開します、まるでReportメッセージを受け取ったかのように。
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.
1つ以上のMLDルータがそうなら、リンクでリンク、MLD Context Data Block SHOULDを受けるルータでは他のルータにブロックを送ってください。 無線の帯域幅が問題、ルータが代わりにプロキシMLD Reportメッセージを送るかもしれないということでないなら、ワイヤレスインターフェースでは、それはContext Data BlockからSubnet Prefix分野の広告を出します。 MLDルータが動向をおさえないので、どのノードが購読をproxyingしながらマルチキャストアドレス(特定のマルチキャストアドレスが聞かれているか否かに関係なくだけ)を聞いているかが困難を全く引き起こすべきではありません。
Loughney, et al. Experimental [Page 31] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[31ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
Authors' Addresses
作者のアドレス
Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Rajeev Koodliノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
EMail: rajeev.koodli@nokia.com
メール: rajeev.koodli@nokia.com
John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland
ジョンLoughneyノキアItdmerenkatu11-13 00180エスポーフィンランド
EMail: john.loughney@nokia.com
メール: john.loughney@nokia.com
Madjid F. Nakhjiri Motorola Labs 1301 East Algonquin Rd., Room 2240 Schaumburg, IL, 60196 USA
Madjid F.Nakhjiriモトローラ研究室1301の東余地のアルゴンキン族2240スカンバーブ、IL60196通り(米国)
EMail: madjid.nakhjiri@motorola.com
メール: madjid.nakhjiri@motorola.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
EMail: charles.perkins@.nokia.com
メール: charles.perkins@.nokia.com
Loughney, et al. Experimental [Page 32] RFC 4067 Context Transfer Protocol (CXTP) July 2005
Loughney、他 実験的な[32ページ]RFC4067文脈転送プロトコル(CXTP)2005年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Loughney, et al. Experimental [Page 33]
Loughney、他 実験的[33ページ]
一覧
スポンサーリンク
