[要約] RFC 4067は、Context Transfer Protocol (CXTP)に関する仕様であり、コンテキスト情報の転送を目的としています。CXTPは、ネットワーク上でのコンテキスト情報の効率的な転送を実現するためのプロトコルです。
Network Working Group J. Loughney, Ed.
Request for Comments: 4067 M. Nakhjiri
Category: Experimental C. Perkins
R. Koodli
July 2005
Context Transfer Protocol (CXTP)
コンテキスト転送プロトコル（CXTP）
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.
このドキュメントでは、承認されたコンテキスト転送を可能にするコンテキスト転送プロトコル（CXTP）を提示します。コンテキスト転送により、モバイルノードで実行されるアプリケーションが最小限の破壊で動作できるように、ノードベースのモビリティをより適切にサポートできます。主な目的は、レイテンシとパケットの損失を減らし、モバイルノードとの間でのシグナリングの再開始を回避することです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem. . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Conventions Used in This Document. . . . . . . . . . . . 3
1.3. Abbreviations Used in the Document . . . . . . . . . . . 3
2. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Context Transfer Scenarios . . . . . . . . . . . . . . . 4
2.2. Context Transfer Message Format. . . . . . . . . . . . . 5
2.3. Context Types. . . . . . . . . . . . . . . . . . . . . . 6
2.4. Context Data Block (CDB) . . . . . . . . . . . . . . . . 7
2.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Transport. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Inter-Router Transport . . . . . . . . . . . . . . . . . 16
3.2. MN-AR Transport. . . . . . . . . . . . . . . . . . . . . 19
4. Error Codes and Constants. . . . . . . . . . . . . . . . . . . 20
5. Examples and Signaling Flows . . . . . . . . . . . . . . . . . 21
5.1. Network controlled, Initiated by pAR, Predictive . . . . 21
5.2. Network controlled, Initiated by nAR, Reactive . . . . . 21
5.3. Mobile controlled, Predictive New L2 up/Old L2 down. . . 22
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Threats. . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Access Router Considerations . . . . . . . . . . . . . . 23
6.3. Mobile Node Considerations . . . . . . . . . . . . . . . 24
7. Acknowledgements & Contributors. . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Timing and Trigger Considerations . . . . . . . . . . 28
Appendix B. Multicast Listener Context Transfer . . . . . . . . . 28
This document describes the Context Transfer Protocol, which provides:
このドキュメントでは、次のことを提供するコンテキスト転送プロトコルについて説明します。
* Representation for feature contexts.
* 機能コンテキストの表現。
* Messages to initiate and authorize context transfer, and notify a mobile node of the status of the transfer.
* コンテキスト転送を開始および承認し、転送のステータスのモバイルノードに通知するメッセージ。
* Messages for transferring contexts prior to, during and after handovers.
* ハンドオーバーの前、最中、後にコンテキストを転送するためのメッセージ。
The proposed protocol is designed to work in conjunction with other protocols in order to provide seamless mobility. The protocol supports both IPv4 and IPv6, though support for IPv4 private addresses is for future study.
提案されたプロトコルは、シームレスなモビリティを提供するために、他のプロトコルと組み合わせて動作するように設計されています。プロトコルはIPv4とIPv6の両方をサポートしていますが、IPv4プライベートアドレスのサポートは将来の研究のためです。
"Problem Description: Reasons For Performing Context Transfers between Nodes in an IP Access Network" [RFC3374] defines the following main reasons why Context Transfer procedures may be useful in IP networks.
「問題の説明：IPアクセスネットワーク内のノード間でコンテキスト転送を実行する理由」[RFC3374]は、コンテキスト転送手順がIPネットワークで役立つ可能性がある次の主な理由を定義します。
1) As mentioned in the introduction, the primary motivation is to quickly re-establish context transfer-candidate services without requiring the mobile host to explicitly perform all protocol flows for those services from scratch. An example of such a service is included in Appendix B of this document.
1) 導入部で述べたように、主な動機は、モバイルホストがこれらのサービスのすべてのプロトコルフローをゼロから明示的に実行することを要求することなく、コンテキスト転送サービスサービスを迅速に再確立することです。このようなサービスの例は、このドキュメントの付録Bに含まれています。
2) An additional motivation is to provide an interoperable solution that supports various Layer 2 radio access technologies.
2) 追加の動機は、さまざまなレイヤー2ラジオアクセステクノロジーをサポートする相互運用可能なソリューションを提供することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Mobility Related Terminology [TERM] defines basic mobility terminology. In addition to the material in that document, we use the following terms and abbreviations in this document.
モビリティ関連用語[用語]は、基本的なモビリティ用語を定義します。その文書の資料に加えて、このドキュメントでは、次の用語と略語を使用します。
CXTP Context Transfer Protocol
CXTPコンテキスト転送プロトコル
DoS Denial-of-Service
DOSサービスの否定
FPT Feature Profile Types
FPT機能プロファイルタイプ
PCTD Predictive Context Transfer Data
PCTD予測コンテキスト転送データ
This section provides a protocol overview. A context transfer can be either started by a request from the mobile node ("mobile controlled") or at the initiative of the new or the previous access router ("network controlled").
このセクションでは、プロトコルの概要を説明します。コンテキスト転送は、モバイルノード（「モバイル制御」）からのリクエストによって、または新しいまたは以前のアクセスルーター（「ネットワーク制御」）のイニシアチブによって開始できます。
* The mobile node (MN) sends the CT Activate Request (CTAR) to its current access router (AR) immediately prior to handover when it is possible to initiate a predictive context transfer. In any case, the MN always sends the CTAR message to the new AR (nAR). If the contexts are already present, nAR verifies the authorization token present in CTAR with its own computation using the parameters supplied by the previous access router (pAR), and subsequently activates those contexts. If the contexts are not present, nAR requests pAR to supply them using the Context Transfer Request message, in which it supplies the authorization token present in CTAR.
* モバイルノード（MN）は、予測コンテキスト転送を開始することができるときに、ハンドオーバーの直前にCT Activate Request（CTAR）を現在のアクセスルーター（AR）に送信します。いずれにせよ、MNは常にCTARメッセージを新しいAR（NAR）に送信します。コンテキストが既に存在している場合、NARは、以前のアクセスルーター（PAR）によって提供されたパラメーターを使用して、CTARに存在する認証トークンをCTARに確認し、その後それらのコンテキストをアクティブにします。コンテキストが存在しない場合、NARは、CTARに存在する承認トークンを提供するコンテキスト転送要求メッセージを使用してそれらを提供するように依頼します。
* Either nAR or pAR may request or start (respectively) context transfer based on internal or network triggers (see Appendix A).
* NARまたはPARのいずれかが、内部またはネットワークのトリガーに基づいて、それぞれ（それぞれ）コンテキスト転送を要求または開始することができます（付録Aを参照）。
The Context Transfer protocol typically operates between a source node and a target node. In the future, there may be multiple target nodes involved; the protocol described here would work with multiple target nodes. For simplicity, we describe the protocol assuming a single receiver or target node.
コンテキスト転送プロトコルは通常、ソースノードとターゲットノードの間で動作します。将来、複数のターゲットノードが関与する可能性があります。ここで説明するプロトコルは、複数のターゲットノードで動作します。簡単にするために、単一の受信機またはターゲットノードを仮定したプロトコルについて説明します。
Typically, the source node is an MN's pAR and the target node is an MN's nAR. Context Transfer takes place when an event, such as a handover, takes place. We call such an event a Context Transfer Trigger. In response to such a trigger, the pAR may transfer the contexts; the nAR may request contexts; and the MN may send a message to the routers to transfer contexts. Such a trigger must be capable of providing the necessary information (such as the MN's IP address) by which the contexts are identified. In addition, the trigger must be able to provide the IP addresses of the access routers, and the authorization to transfer context.
通常、ソースノードはMNのPARで、ターゲットノードはMNのNARです。コンテキスト転送は、ハンドオーバーなどのイベントが行われるときに行われます。このようなイベントをコンテキスト転送トリガーと呼びます。このようなトリガーに応じて、PARはコンテキストを転送する場合があります。NARはコンテキストを要求する場合があります。MNは、コンテキストを転送するためにルーターにメッセージを送信する場合があります。このようなトリガーは、コンテキストが特定される必要な情報（MNのIPアドレスなど）を提供できる必要があります。さらに、トリガーはアクセスルーターのIPアドレスとコンテキストを転送する許可を提供できる必要があります。
Context transfer protocol messages use Feature Profile Types (FPTs) that identify the way that data is organized for the particular feature contexts. The FPTs are registered in a number space (with IANA Type Numbers) that allows a node to unambiguously determine the type of context and the context parameters present in the protocol messages. Contexts are transferred by laying out the appropriate feature data within Context Data Blocks according to the format in Section 2.3, as well as any IP addresses necessary to associate the contexts to a particular MN. The context transfer initiation messages contain parameters that identify the source and target nodes, the desired list of feature contexts, and IP addresses to identify the contexts. The messages that request the transfer of context data also contain an appropriate token to authorize the context transfer.
コンテキスト転送プロトコルメッセージは、特定の機能コンテキストのデータが編成される方法を識別する機能プロファイルタイプ（FPT）を使用します。FPTは、ノードがプロトコルメッセージに存在するコンテキストのタイプとコンテキストパラメーターを明確に決定できるようにする数値スペース（IANAタイプ番号）に登録されています。コンテキストは、セクション2.3の形式に従ってコンテキストデータブロック内の適切な機能データをレイアウトすることにより、およびコンテキストを特定のMNに関連付けるために必要なIPアドレスをレイアウトすることにより転送されます。コンテキスト転送開始メッセージには、ソースとターゲットノード、機能コンテキストの目的のリスト、およびコンテキストを識別するIPアドレスを識別するパラメーターが含まれています。コンテキストデータの転送を要求するメッセージには、コンテキスト転送を承認するための適切なトークンも含まれています。
Performing a context transfer in advance of the MN attaching to nAR can increase handover performance. For this to take place, certain conditions must be met. For example, pAR must have sufficient time and knowledge of the impending handover. This is feasible, for instance, in Mobile IP fast handovers [LLMIP][FMIPv6]. Additionally, many cellular networks have mechanisms to detect handovers in advance. However, when the advance knowledge of impending handover is not available, or if a mechanism such as fast handover fails, retrieving feature contexts after the MN attaches to nAR is the only available means for context transfer. Performing context transfer after handover might still be better than having to re-establish all the contexts from scratch, as shown in [FHCT] and [TEXT]. Finally, some contexts may simply need to be transferred during handover signaling. For instance, any context that gets updated on a per-packet basis must clearly be transferred only after packet forwarding to the MN on its previous link has been terminated.
NARに付着するMNに先立ってコンテキスト転送を実行すると、ハンドオーバーパフォーマンスが向上する可能性があります。これを行うには、特定の条件を満たす必要があります。たとえば、PARには、差し迫ったハンドオーバーの十分な時間と知識が必要です。これは、たとえば、モバイルIP高速ハンドオーバー[llmip] [fmipv6]で実行可能です。さらに、多くのセルラーネットワークには、事前に手OVERを検出するメカニズムがあります。ただし、差し迫った引き渡しに関する事前の知識が利用できない場合、または高速ハンドオーバーなどのメカニズムが失敗した場合、MNがNARに付着した後に機能コンテキストを取得することが、コンテキスト転送のための唯一の利用可能な手段です。[FHCT]および[テキスト]に示すように、ハンドオーバー後にコンテキスト転送を実行することは、すべてのコンテキストをゼロから再確立するよりも優れている可能性があります。最後に、一部のコンテキストは、ハンドオーバーシグナル伝達中に単に転送する必要がある場合があります。たとえば、パケットごとに更新されるコンテキストは、以前のリンクでMNへのパケット転送が終了した後にのみ明確に転送される必要があります。
The Previous Access Router transfers feature contexts under two general scenarios.
以前のアクセスルーター転送は、2つの一般的なシナリオの下でコンテキストを機能させます。
The pAR receives a Context Transfer Activate Request (CTAR) message from the MN whose feature contexts are to be transferred, or it receives an internally generated trigger (e.g., a link-layer trigger on the interface to which the MN is connected). The CTAR message, described in Section 2.5, provides the IP address of nAR, the IP address of MN on pAR, the list of feature contexts to be transferred (by default requesting all contexts to be transferred), and a token authorizing the transfer. In response to a CT-Activate Request message or to the CT trigger, pAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts. This message, described in Section 2.5, contains the MN's previous IP address. It also contains parameters for nAR to compute an authorization token to verify the MN's token that is present in the CTAR message. Recall that the MN always sends a CTAR message to nAR regardless of whether it sent the CTAR message to pAR because there is no means for the MN to ascertain that context transfer has reliably taken place. By always sending the CTAR message to nAR, the Context Transfer Request (see below) can be sent to pAR if necessary.
PARは、機能コンテキストを転送するMNからコンテキスト転送アクティベートリクエスト（CTAR）メッセージを受信するか、内部生成されたトリガーを受信します（たとえば、MNが接続されているインターフェイスのリンク層トリガー）。セクション2.5で説明されているCTARメッセージは、NARのIPアドレス、PARのMNのIPアドレス、転送される機能コンテキストのリスト（デフォルトではすべてのコンテキストを要求する）、および転送の承認を許可するトークンを提供します。CT-ActivateリクエストメッセージまたはCTトリガーに応答して、特徴コンテキストを含むコンテキスト転送データ（CTD）メッセージを予測的に送信します。セクション2.5で説明されているこのメッセージには、MNの以前のIPアドレスが含まれています。また、NARがCTARメッセージに存在するMNのトークンを検証するための認証トークンを計算するパラメーターも含まれています。MNがCTARメッセージをPARに送信したかどうかにかかわらず、MNは常にNARにCTARメッセージを送信することを思い出してください。常にCTARメッセージをNARに送信することにより、必要に応じてコンテキスト転送要求（以下を参照）をPARに送信できます。
When context transfer takes place without the nAR requesting it, nAR requires MN to present its authorization token. Doing this locally at nAR when the MN attaches to it improves performance and increases security, since the contexts are likely to already be present. Token verification takes place at the router possessing the contexts.
NARがそれを要求することなくコンテキスト転送が行われた場合、NARはMNが認証トークンを提示することを要求します。MNがそれに付着したときにNARでこれをローカルに行うと、コンテキストがすでに存在する可能性が高いため、パフォーマンスが向上し、セキュリティが向上します。トークンの検証は、コンテキストを所有するルーターで行われます。
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番目のシナリオでは、PARは、セクション2.5で説明されているように、NARからコンテキスト転送要求（CT-REQ）メッセージを受信します。NAR自体は、CTARメッセージを受信した結果、またはコンテキスト転送トリガーの受信からCT-REQメッセージを生成します。CT-REQメッセージでは、NARはMNの以前のIPアドレス、転送される機能コンテキストのFPT、CTARからのシーケンス番号、およびCTARからの承認トークンを提供します。CT-REQメッセージに応じて、PARは、MNの以前のIPアドレスと機能コンテキストを含むコンテキスト転送データ（CTD）メッセージを転写します。対応するCTDメッセージを受信すると、NARはCTD応答（CTDR）メッセージを生成して、受信したコンテキストを処理するステータスを報告できます。NARは、PARから受信したらコンテキストをインストールします。
A CXTP message consists of a message-specific header and one or more data blocks. Data blocks may be bundled together to ensure a more efficient transfer. On the inter-AR interface, SCTP is used so 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.
CXTPメッセージは、メッセージ固有のヘッダーと1つ以上のデータブロックで構成されています。データブロックをまとめて、より効率的な転送を確保することができます。Inter-ARインターフェイスでは、SCTPが使用されるため、フラグメンテーションは問題になりません。MN-ARインターフェイスでは、トランスポートプロトコルおよびIPプロトコルヘッダーを含む合計パケットサイズは、パケットの断片化を避けるためにPATH MTUよりも少ないはずです。各メッセージには、5ビットメッセージタイプコードとともに、低次のオクテットの3ビットバージョン番号フィールドが含まれています。この仕様はプロトコルのバージョン1にのみ適用されるため、バージョン番号フィールドは0x1に設定する必要があります。プロトコルの将来の改訂がバイナリの互換性のない変更を行う場合、バージョン番号をインクリメントする必要があります。
Contexts are identified by the FPT code, which is a 16 bit unsigned integer. The meaning of each context type is determined by a specification document. The context type numbers are to be tabulated in a registry maintained by IANA [IANA] and handled according to the message specifications in this document. The instantiation of each context by nAR is determined by the messages in this document along with the specification associated with the particular context type. The following diagram illustrates the general format for CXTP messages:
コンテキストはFPTコードによって識別されます。FPTコードは、16ビット署名されていない整数です。各コンテキストタイプの意味は、仕様文書によって決定されます。コンテキストタイプ番号は、IANA [IANA]によって維持されているレジストリで表され、このドキュメントのメッセージ仕様に従って処理されます。NARによる各コンテキストのインスタンス化は、特定のコンテキストタイプに関連付けられた仕様とともに、このドキュメントのメッセージによって決定されます。次の図は、CXTPメッセージの一般的な形式を示しています。
+----------------------+
| Message Header |
+----------------------+
| CXTP Data 1 |
+----------------------+
| CXTP Data 2 |
+----------------------+
| ... |
Each context type specification contains the following details:
各コンテキストタイプの仕様には、次の詳細が含まれています。
- Number, size (in bits), and ordering of data fields in the state variable vector that embodies the context.
- 数、サイズ（ビット内）、およびコンテキストを具体化する状態変数ベクトルのデータフィールドの順序付け。
- Default values (if any) for each individual datum of the context state vector.
- コンテキスト状態ベクトルの個々のデータムごとのデフォルト値（もしあれば）。
- Procedures and requirements for creating a context at a new access router, given the data transferred from a previous access router and formatted according to the ordering rules and data field sizes presented in the specification.
- 以前のアクセスルーターから転送され、仕様で提示された順序付けルールとデータフィールドサイズに従ってフォーマットされたデータを考慮して、新しいアクセスルーターでコンテキストを作成するための手順と要件。
- If possible, status codes for success or failure related to the context transfer. For instance, a QoS context transfer might have different status codes depending on which elements of the context data failed to be instantiated at nAR.
- 可能であれば、コンテキスト転送に関連する成功または失敗のステータスコード。たとえば、QoSコンテキスト転送は、コンテキストデータの要素がNARでインスタンス化されなかったことに応じて、異なるステータスコードを持つ場合があります。
The Context Data Block (CDB) is used both for request and response operations. When a request is constructed, only the first 4 octets are typically necessary (See CTAR below). When used for transferring the actual feature context itself, the context data is present, and the presence vector is sometimes present.
コンテキストデータブロック（CDB）は、リクエスト操作と応答操作の両方に使用されます。リクエストが作成されると、通常、最初の4オクテットのみが必要です（以下のCTARを参照）。実際の機能コンテキスト自体を転送するために使用される場合、コンテキストデータが存在し、存在ベクトルが存在する場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feature Profile Type (FPT) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature Profile Type 16 bit integer, assigned by IANA, indicating the type of data included in the Data field.
IANAによって割り当てられた機能プロファイルタイプ16ビット整数は、データフィールドに含まれるデータのタイプを示しています。
Length Message length in units of 8 octet words.
8オクテットの単語の単位の長さのメッセージ長。
'P' bit 0 = No presence vector. 1 = Presence vector present.
'P'ビット0 =存在ベクトルなし。1 =存在ベクターが存在します。
Reserved Reserved for future use. Set to zero by the sender.
将来の使用のために予約された予約。送信者によってゼロに設定されます。
Data Context type-dependent data, whose length is defined by the Length Field. If the data is not 64 bit aligned, the data field is padded with zeros.
データコンテキストタイプ依存データ。その長さは長さフィールドによって定義されます。データが64ビットアライメントされていない場合、データフィールドにゼロがパッドに入っています。
The Feature Profile Type (FPT) code indicates the type of data in the data field. Typically, this will be context data, but it could be an error indication. The 'P' bit specifies whether the "presence vector" is used. When the presence vector is in use, it is interpreted to indicate whether particular data fields are present (and contain non-default values). The ordering of the bits in the presence vector is the same as the ordering of the data fields according to the context type specification, one bit per data field regardless of the size of the data field. The Length field indicates the size of the CDB in 8 octet words, including the first 4 octets starting from FPT.
機能プロファイルタイプ（FPT）コードは、データフィールドのデータのタイプを示します。通常、これはコンテキストデータになりますが、エラーの表示になる可能性があります。「P」ビットは、「存在ベクトル」が使用されているかどうかを指定します。存在ベクトルが使用されている場合、特定のデータフィールドが存在するかどうかを示す（および非デフォルト値が含まれている）と解釈されます。存在ベクトルのビットの順序付けは、コンテキストタイプの仕様に応じたデータフィールドの順序と同じです。データフィールドのサイズに関係なく、データフィールドごとに1ビットです。長さのフィールドは、FPTから始まる最初の4オクテットを含む、8オクテットの単語でCDBのサイズを示します。
Notice that the length of the context data block is defined by the sum of the lengths of each data field specified by the context type specification, plus 4 octets if the 'P' bit is set, minus the accumulated size of all the context data that is implicitly given as a default value.
コンテキストデータブロックの長さは、コンテキストタイプの仕様で指定された各データフィールドの長さの合計と、「P」ビットが設定されている場合は4オクテットで定義され、すべてのコンテキストデータの蓄積されたサイズを差し引いた4オクテットで定義されていることに注意してください。暗黙的にデフォルト値として与えられます。
In this section, the CXTP messages are defined. The MN for which context transfer protocol operations are undertaken is always identified by its previous IP access address. Only one context transfer operation per MN may be in progress at a time so that the CTDR message unambiguously identifies which CTD message is acknowledged simply by including the MN's identifying previous IP address. The 'V' flag indicates whether the IP addresses are IPv4 or IPv6.
このセクションでは、CXTPメッセージが定義されています。コンテキスト転送プロトコル操作が実施されるMNは、以前のIPアクセスアドレスによって常に識別されます。CTDRメッセージは、MNの以前のIPアドレスを識別するだけでCTDメッセージが確認されるCTDRメッセージを明確に識別するために、一度に1 MNあたり1つのコンテキスト転送操作のみが進行中です。「V」フラグは、IPアドレスがIPv4かIPv6かを示します。
This message is always sent by the MN to the nAR to request a context transfer. Even when the MN does not know if contexts need to be transferred, the MN sends the CTAR message. If an acknowledgement for this message is needed, the MN sets the 'A' flag to 1; otherwise the MN does not expect an acknowledgement. This message may include a list of FPTs that require transfer.
このメッセージは常にMNによってNARに送信され、コンテキスト転送を要求します。MNがコンテキストを転送する必要があるかどうかがわからない場合でも、MNはCTARメッセージを送信します。このメッセージの承認が必要な場合、MNは「A」フラグを1に設定します。それ以外の場合、MNは謝辞を期待していません。このメッセージには、転送が必要なFPTのリストが含まれている場合があります。
The MN may also send this message to pAR while still connected to pAR. In this case, the MN includes the nAR's IP address; otherwise, if the message is sent to nAR, the pAR address is sent. The MN MUST set the sequence number to the same value as was set for the message sent on both pAR and nAR so pAR can determine whether to use a cached message.
MNは、PARに接続されている間、このメッセージをPARに送信する場合もあります。この場合、MNにはNARのIPアドレスが含まれています。それ以外の場合、メッセージがNARに送信された場合、PARアドレスが送信されます。MNは、PARとNARの両方で送信されたメッセージに設定されたのと同じ値にシーケンス番号を設定する必要があるため、PARはキャッシュされたメッセージを使用するかどうかを決定できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MN's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Previous (New) AR IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
節CXTPプロトコルのバージョン番号= 0x1
Type CTAR = 0x1
タイプCTAR = 0x1
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
「0」に設定すると、「V」フラグ、IPv6アドレス。「1」に設定すると、IPv4アドレスがアドレス指定されます。
'A' bit If set, the MN requests an acknowledgement.
'A'ビットを設定すると、MNは謝辞を要求します。
Reserved Set to zero by the sender, ignored by the receiver.
レシーバーによって無視された送信者によってゼロに予約されたセット。
Length Message length in units of octets.
オクテットの単位の長さのメッセージ長。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MNの以前のIPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクターのいずれかが含まれています。
nAR / pAR IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
NAR / PAR IPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクテットのいずれかが含まれます。
Sequence Number A value used to identify requests and acknowledgements (see Section 3.2).
シーケンス番号リクエストと謝辞を識別するために使用される値（セクション3.2を参照）。
Authorization Token An unforgeable value calculated as discussed below. This authorizes the receiver of CTAR to perform context transfer.
許可トークン以下で説明するように計算された容認できない価値を取得します。これにより、CTARの受信者がコンテキスト転送を実行することを許可します。
Context Block Variable length field defined in Section 2.4.
セクション2.4で定義されているコンテキストブロック変数長さフィールド。
If no context types are specified, all contexts for the MN are requested.
コンテキストタイプが指定されていない場合、MNのすべてのコンテキストが要求されます。
The Authorization Token is calculated as:
承認トークンは次のように計算されます。
First (32, HMAC_SHA1 (Key, (Previous IP address | Sequence Number | CDBs)))
最初（32、hmac_sha1（key、（前のIPアドレス|シーケンス番号| CDB）））））
where Key is a shared secret between the MN and pAR, and CDB is a concatenation of all the Context Data Blocks specifying the contexts to be transferred that are included in the CTAR message.
キーはMNとPARの間の共有秘密であり、CDBはCTARメッセージに含まれるコンテキストを指定するすべてのコンテキストデータブロックの連結です。
This is an informative message sent by the receiver of CTAR to the MN to acknowledge a CTAR message. Acknowledgement is optional, depending on whether the MN requested it. This message may include a list of FPTs that were not successfully transferred.
これは、CTARメッセージを確認するためにCTARの受信者からMNに送信された有益なメッセージです。MNが要求したかどうかに応じて、謝辞はオプションです。このメッセージには、正常に転送されなかったFPTのリストが含まれる場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
節CXTPプロトコルのバージョン番号= 0x1
Type CTAA = 0x2
タイプCTAA = 0x2
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
「0」に設定すると、「V」フラグ、IPv6アドレス。「1」に設定すると、IPv4アドレスがアドレス指定されます。
Reserved Set to zero by the sender and ignored by the receiver.
予約セットは送信者によってゼロになり、受信機によって無視されます。
Length Message length in units of octets.
オクテットの単位の長さのメッセージ長。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MNの以前のIPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクターのいずれかが含まれています。
FPT 16 bit unsigned integer, listing the Feature Profile Type that was not successfully transferred.
FPT 16ビット符号なし整数。正常に転送されなかった機能プロファイルタイプをリストします。
Status Code An octet, containing failure reason.
ステータスコード障害理由を含むオクテットをコードします。
........ more FPTs and status codes as necessary
Sent by pAR to nAR, and includes feature data (CXTP data). This message handles both predictive and normal CT. An acknowledgement flag, 'A', included in this message indicates whether a reply is required by pAR.
PARでNARに送信され、機能データ（CXTPデータ）が含まれています。このメッセージは、予測と通常のCTの両方を処理します。このメッセージに含まれる承認フラグ「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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
節CXTPプロトコルのバージョン番号= 0x1
Type CTD = 0x3 (Context Transfer Data) PCTD = 0x4 (Predictive Context Transfer Data)
タイプCTD = 0x3（コンテキスト転送データ）PCTD = 0x4（予測コンテキスト転送データ）
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
「0」に設定すると、「V」フラグ、IPv6アドレス。「1」に設定すると、IPv4アドレスがアドレス指定されます。
'A' bit When set, the pAR requests an acknowledgement.
「A」を設定すると、PARは謝辞を要求します。
Length Message length in units of octets.
オクテットの単位の長さのメッセージ長。
Elapsed Time The number of milliseconds since the transmission of the first CTD message for this MN.
このMNの最初のCTDメッセージの送信以来、ミリ秒数の経過時間。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MNの以前のIPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクターのいずれかが含まれています。
Algorithm Algorithm for carrying out the computation of the MN Authorization Token. Currently only 1 algorithm is defined, HMAC_SHA1 = 1.
MN認証トークンの計算を実行するためのアルゴリズムアルゴリズム。現在、1つのアルゴリズムのみが定義されています、hmac_sha1 = 1。
Key Length Length of key, in octets.
キーのキー長の長さ、オクテット。
Key Shared key between MN and AR for CXTP.
CXTPのMNとARの間でキー共有キー。
Context Data Block The Context Data Block (see Section 2.4).
コンテキストデータブロックコンテキストデータブロック（セクション2.4を参照）。
When CTD is sent predictively, the supplied parameters (including the algorithm, key length, and the key itself) allow the nAR to compute a token locally and verify it against the token present in the CTAR message. This material is also sent if the pAR receives a CTD message with a null Authorization Token, indicating that the CT-Req message was sent before the nAR received the CTAR message. CTD MUST be protected by IPsec; see Section 6.
CTDが予測的に送信されると、付属のパラメーター（アルゴリズム、キー長、キー自体を含む）により、NARはトークンをローカルに計算し、CTARメッセージに存在するトークンに対して検証できます。この資料は、PARがNULL AuthorizationトークンでCTDメッセージを受信した場合にも送信され、NARがCTARメッセージを受信する前にCT-REQメッセージが送信されたことを示します。CTDはIPSECによって保護する必要があります。セクション6を参照してください。
As described previously, the algorithm for carrying out the computation of the MN Authorization Token is HMAC_SHA1. The token authentication calculation algorithm is described in Section 2.5.1.
前述のように、MN認証トークンの計算を実行するためのアルゴリズムはhmac_sha1です。トークン認証計算アルゴリズムは、セクション2.5.1で説明されています。
For predictive handover, the pAR SHOULD keep track of the CTAR sequence number and cache the CTD message until a CTDR message for the MN's previous IP address has been received from the pAR, indicating that the context transfer was successful, or until CT_MAX_HANDOVER_TIME expires. The nAR MAY send a CT-Req message containing the same sequence number if the predictive CTD message failed to arrive or the context was corrupted. In this case, the nAR sends a CT-Req message with a matching sequence number and pAR can resend the context.
予測的なハンドオーバーの場合、PARはCTARシーケンス番号を追跡し、MNの以前のIPアドレスのCTDRメッセージがPARから受信されるまでCTDメッセージをキャッシュする必要があります。これは、コンテキスト転送が成功したことを示します。NARは、予測CTDメッセージが到着に失敗するか、コンテキストが破損した場合、同じシーケンス番号を含むCT-REQメッセージを送信する場合があります。この場合、NARは一致するシーケンス番号を持つCT-REQメッセージを送信し、PARはコンテキストを再送信できます。
This message is sent by nAR to pAR depending on the value of the 'A' flag in CTD, indicating success or failure.
このメッセージは、CTDの「A」フラグの値に応じてNARによってPARに送信され、成功または失敗を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|S| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
節CXTPプロトコルのバージョン番号= 0x1
Type CTDR = 0x5 (Context Transfer Data)
タイプCTDR = 0x5（コンテキスト転送データ）
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
「0」に設定すると、「V」フラグ、IPv6アドレス。「1」に設定すると、IPv4アドレスがアドレス指定されます。
'S' bit When set to one, this bit indicates that all feature contexts sent in CTD or PCTD were received successfully.
1つに設定されたときの 'S'ビットは、CTDまたはPCTDで送信されたすべての機能コンテキストが正常に受信されたことを示しています。
Reserved Set to zero by the sender and ignored by the receiver.
予約セットは送信者によってゼロになり、受信機によって無視されます。
Length Message length in units of octets.
オクテットの単位の長さのメッセージ長。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MNの以前のIPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクターのいずれかが含まれています。
FPT 16 bit unsigned integer, listing the Feature Profile Type that is being acknowledged.
fpt 16ビット符号なし整数、承認されている機能プロファイルタイプをリストします。
Status Code A context-specific return value, zero for success, nonzero when 'S' is not set to one.
ステータスコードコンテキスト固有の返品値、成功のためのゼロ、「S」が1つに設定されていないゼロではありません。
If transferring a context cannot be completed in a timely fashion, then nAR may send CTC to pAR to cancel an ongoing CT process.
コンテキストをタイムリーに完了できない場合、NARはCTCをPARに送信して進行中のCTプロセスをキャンセルする場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
節CXTPプロトコルのバージョン番号= 0x1
Type CTC = 0x6 (Context Transfer Cancel)
タイプCTC = 0x6（コンテキスト転送キャンセル）
Length Message length in units of octets.
オクテットの単位の長さのメッセージ長。
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
「0」に設定すると、「V」フラグ、IPv6アドレス。「1」に設定すると、IPv4アドレスがアドレス指定されます。
Reserved Set to zero by the sender and ignored by the receiver.
予約セットは送信者によってゼロになり、受信機によって無視されます。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MNの以前のIPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクターのいずれかが含まれています。
Sent by nAR to pAR to request the start of context transfer. This message is sent as a response to a CTAR message. The fields following the Previous IP address of the MN are included verbatim from the CTAR message.
NARによってPARに送られ、コンテキスト転送の開始を要求します。このメッセージは、CTARメッセージへの応答として送信されます。MNの前のIPアドレスに続くフィールドには、CTARメッセージから逐語的に含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Requested Context Data Block (if present) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CXTP protocol = 0x1
節CXTPプロトコルのバージョン番号= 0x1
Type CTREQ = 0x7 (Context Transfer Request)
タイプctreq = 0x7（コンテキスト転送要求）
'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.
「0」に設定すると、「V」フラグ、IPv6アドレス。「1」に設定すると、IPv4アドレスがアドレス指定されます。
Reserved Set to zero by the sender and ignored by the receiver.
予約セットは送信者によってゼロになり、受信機によって無視されます。
Length Message length in units of octets.
オクテットの単位の長さのメッセージ長。
MN's Previous IP Address Field contains either: IPv4 [RFC791] Address, 4 octets, or IPv6 [RFC3513] Address, 16 octets.
MNの以前のIPアドレスフィールドには、IPv4 [RFC791]アドレス、4オクテット、またはIPv6 [RFC3513]アドレス、16オクターのいずれかが含まれています。
Sequence Number Copied from the CTAR message, allows the pAR to distinguish requests from previously sent context.
CTARメッセージからコピーされたシーケンス番号により、PARはリクエストを以前に送信したコンテキストと区別できます。
MN's Authorization Token An unforgeable value calculated as discussed in Section 2.5.1. This authorizes the receiver of CTAR to perform context transfer. Copied from CTAR.
MNの承認トークンセクション2.5.1で説明したように計算された寛大な値を計算します。これにより、CTARの受信者がコンテキスト転送を実行することを許可します。CTARからコピー。
Context Data Request Block A request block for context data; see Section 2.4.
コンテキストデータ要求コンテキストデータの要求ブロックをブロックします。セクション2.4を参照してください。
The sequence number is used by pAR to correlate a request for previously transmitted context. In predictive transfer, if the MN sends CTAR prior to handover, pAR pushes context to nAR using PCTD. If the CTD fails, the nAR will send a CT-Req with the same sequence number, enabling the pAR to determine which context to resend. The pAR deletes the context after CXTP_MAX_TRANSFER_TIME. The sequence number is not used in reactive transfer.
シーケンス番号は、以前に送信されたコンテキストのリクエストを相関させるためにPARによって使用されます。予測転送では、MNが引き渡す前にCTARを送信する場合、PARはPCTDを使用してNARにコンテキストをプッシュします。CTDが失敗した場合、NARは同じシーケンス番号でCT-REQを送信し、PARがどのコンテキストを再送信するかを決定できるようにします。PARは、CXTP_MAX_TRANSFER_TIMEの後にコンテキストを削除します。シーケンス番号は、リアクティブ転送では使用されません。
For predictive transfer, the pAR sends the keying material and other information necessary to calculate the Authorization Token without having processed a CT-Req message. For reactive transfer, if the nAR receives a context transfer trigger but has not yet received the CTAR message with the authorization token, the Authorization Token field in CT-Req is set to zero. The pAR interprets this as an indication to include the keying material and other information necessary to calculate the Authorization Token, and includes this material into the CTD message as if the message were being sent due to predictive transfer. This provides nAR with the information it needs to calculate the authorization token when the MN sends CTAR.
予測転送のために、PARは、CT-REQメッセージを処理せずに認証トークンを計算するために必要なキーイング素材およびその他の情報を送信します。リアクティブ転送の場合、NARがコンテキスト転送トリガーを受信したが、認証トークンを使用してCTARメッセージをまだ受信していない場合、CT-REQの承認トークンフィールドはゼロに設定されています。PARは、これを承認トークンを計算するために必要なキーイング素材およびその他の情報を含めることを示す兆候として解釈し、この資料をCTDメッセージに含めて、予測転送のためにメッセージが送信されているかのように含まれています。これにより、MNがCTARを送信したときに認証トークンを計算するために必要な情報がNARに提供されます。
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を準備する研究タスクの一部は、この問題を定量化することです。ただし、Prototype 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 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.
これらの考慮事項は、CXTPの実装をサポートする必要があり、CXTPのプロトタイプの展開は、特にパブリックインターネット上の展開が検討されている場合、ルーター間インターフェイスのトランスポートプロトコルとして、ストリーム制御トランスポートプロトコル（SCTP）[SCTP]を使用する必要があると主張しています。SCTPは、プログラム可能な再送信タイマーに基づいて、混雑制御、断片化、および部分的な再送信をサポートします。SCTPは、CXTPの実験的実装やプロトタイプの展開には必要ない複数のストリームやフェールオーバーの複数のIPアドレスなど、多くの高度で複雑な機能もサポートしています。この時点では、このようなSCTP機能の使用は推奨されません。
The SCTP Payload Data Chunk carries the context transfer protocol messages. The User Data part of each SCTP message contains an appropriate context transfer protocol message defined in this document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR (Section 2.5.4), CTC (Section 2.5.5), and CT-Req (Section 2.5.6). In general, each SCTP message can carry feature contexts belonging to any MN. If the SCTP checksum calculation fails, the nAR returns the BAD_CHECKSUM error code in a CTDR message.
SCTPペイロードデータチャンクには、コンテキスト転送プロトコルメッセージが搭載されています。各SCTPメッセージのユーザーデータ部分には、このドキュメントで定義されている適切なコンテキスト転送プロトコルメッセージが含まれています。SCTPを使用して送信されるメッセージは、CTD（セクション2.5.3）、CTDR（セクション2.5.4）、CTC（セクション2.5.5）、およびCT-REQ（セクション2.5.6）です。一般に、各SCTPメッセージは、任意のMNに属する機能コンテキストを運ぶことができます。SCTPチェックサムの計算が失敗した場合、NARはCTDRメッセージのbad_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メッセージのシーケンス配信なしでコンテキスト転送に使用されます。各メッセージは、単一のMNの機能コンテキストコレクションに対応します。単一のストリームはシンプルさを提供します。一次ブロックを防ぐために複数のストリームを使用することは、将来の研究のためです。順序付けられていない配信により、受信者は、異なるMNSに属するメッセージのシーケンス配信をブロックしないことができます。SCTPヘッダーのペイロードプロトコル識別子は「CXTP」です。インタールーターCXTPは、Seamoby SCTPポート[IANA]を使用します。
Timeliness of the context transfer information SHOULD be accommodated by setting the SCTP maximum retransmission value to CT_MAX_TRANSFER_TIME to accommodate the maximum acceptable handover delay time. The AR SHOULD be configured with CT_MAX_TRANSFER_TIME to accommodate the particular wireless link technology and local wireless propagation conditions. SCTP message bundling SHOULD be turned off to reduce an extra delay in sending messages. Within CXTP, the nAR SHOULD estimate the retransmit timer from the receipt of the first fragment of a CXTP message and avoid processing any IP traffic from the MN until either context transfer is complete or the estimated retransmit timer expires. If both routers support PR-SCTP [PR-SCTP], then PR-SCTP SHOULD be used. PR-SCTP modifies the lifetime parameter of the Send() operation (defined in Section 10.1 E in [SCTP]) so that it applies to retransmits as well as transmits; that is, in PR-SCTP, if the lifetime expires and the data chunk has not been acknowledged, the transmitter stops retransmitting, whereas in the base protocol the data would be retransmitted until acknowledged or the connection timed out.
コンテキスト転送情報の適時性は、SCTPの最大再送信値をCT_MAX_TRANSFER_TIMEに設定して、最大許容可能なハンドオーバー遅延時間に対応することで対応する必要があります。ARは、特定のワイヤレスリンクテクノロジーとローカルワイヤレス伝播条件に対応するために、CT_MAX_TRANSFER_TIMEで構成する必要があります。SCTPメッセージバンドルは、メッセージの送信の余分な遅延を減らすためにオフにする必要があります。CXTP内で、NARは、CXTPメッセージの最初のフラグメントの受信から再送信タイマーを推定し、MNからのIPトラフィックの処理を避ける必要があります。両方のルーターがPR-SCTP [PR-SCTP]をサポートする場合、PR-SCTPを使用する必要があります。PR-SCTPは、送信と送信に適用されるように、send（）操作の寿命パラメーター（[sctp]のセクション10.1 eで定義）を変更します。つまり、PR-SCTPでは、寿命が期限切れになり、データチャンクが認められていない場合、送信機は再送信を停止しますが、基本プロトコルでは、データが認められるか、接続がタイムアウトされるまで再送信されます。
The format of Payload Data Chunk taken from [SCTP] is shown in the following diagram.
[sctp]から取得したペイロードデータチャンクの形式を次の図に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Data (seq n of Stream S) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 1 (one).
'B' bit The Beginning fragment bit. See [SCTP].
'E' bit The Ending fragment bit. See [SCTP].
'e'ビットエンディングフラグメントビット。[sctp]を参照してください。
TSN Transmission Sequence Number. See [SCTP].
TSN伝送シーケンス番号。[sctp]を参照してください。
Stream Identifier S Identifies the context transfer protocol stream.
ストリーム識別子Sは、コンテキスト転送プロトコルストリームを識別します。
Stream Sequence Number n Since the 'U' bit is set to one, the receiver ignores this number. See [SCTP].
ストリームシーケンス番号n 'u'ビットが1に設定されるため、受信者はこの数値を無視します。[sctp]を参照してください。
Payload Protocol Identifier Set to 'CXTP' (see [IANA]).
ペイロードプロトコル識別子は「cxtp」に設定されています（[iana]を参照）。
User Data Contains the context transfer protocol messages.
ユーザーデータには、コンテキスト転送プロトコルメッセージが含まれています。
If a CXTP deployment will never run over the public Internet, and it is known that congestion is not a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. For example, piggybacking CXTP messages on top of handover signaling for routing, such as provided by FMIPv6 in ICMP [FMIPv6]. Implementations of CXTP MAY support ICMP for such purposes. If such piggybacking is used, an experimental message extension for the protocol on which CXTP is piggybacking MUST be designed. Direct deployment on top of a transport protocol for experimental purposes is also possible. In this case, the researcher MUST be careful to accommodate good Internet transport protocol engineering practices, including using retransmits with exponential backoff.
CXTPの展開がパブリックインターネット上で実行されない場合、および渋滞がアクセスネットワークで問題ではないことが知られている場合、代替輸送プロトコルは実験に適した車両になる可能性があります。たとえば、ICMP [FMIPv6]でFMIPv6によって提供されるなど、ルーティングのハンドオーバーシグナルの上にCXTPメッセージをピギーバックします。CXTPの実装は、このような目的でICMPをサポートする場合があります。このようなピギーバックを使用する場合、CXTPがピギーバックを設計する必要があるプロトコルの実験的なメッセージ拡張機能を設計する必要があります。実験目的で輸送プロトコルの上に直接展開することも可能です。この場合、研究者は、指数関数的なバックオフを使用した再送信を使用するなど、優れたインターネット輸送プロトコルエンジニアリングの実践に注意する必要があります。
The MN-AR interface MUST implement and SHOULD use ICMP to transport the CTAR and CTAA messages. Because ICMP contains no provisions for retransmitting packets if signaling is lost, the CXTP protocol incorporates provisions for improving transport performance on the MN-AR interface. The MN and AR SHOULD limit the number of context data block identifiers included in the CTAR and CTAA messages so that the message will fit into a single packet, because ICMP has no provision for fragmentation above the IP level. CXTP uses the Experimental Mobility ICMP type [IANA]. The ICMP message format for CXTP messages is as follows:
MN-ARインターフェイスは、ICMPを使用してCTARおよびCTAAメッセージを輸送する必要があります。ICMPには、シグナリングが失われた場合、パケットを再送信するための規定が含まれていないため、CXTPプロトコルにはMN-ARインターフェイスの輸送パフォーマンスを改善するための規定が組み込まれています。MNとARは、CTARおよびCTAAメッセージに含まれるコンテキストデータブロック識別子の数を制限して、ICMPにはIPレベルを超える断片化の規定がないため、メッセージが単一のパケットに収まるように制限する必要があります。CXTPは、実験モビリティICMPタイプ[IANA]を使用します。CXTPメッセージのICMPメッセージ形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
IPフィールド：
Source Address An IP address assigned to the sending interface.
ソースアドレス送信インターフェイスに割り当てられたIPアドレス。
Destination Address An IP address assigned to the receiving interface.
宛先アドレス受信インターフェイスに割り当てられたIPアドレス。
Hop Limit 255
ホップ制限255
ICMP Fields:
ICMPフィールド：
Type Experimental Mobility Type (To be assigned by IANA, for IPv4 and IPv6, see [IANA])
タイプ実験モビリティタイプ（IANAによって割り当てられ、IPv4およびIPv6の場合、[IANA]を参照）
Code 0
コード0
Checksum The ICMP checksum.
ICMPチェックサムのチェックサム。
Sub-type The Experimental Mobility ICMP subtype for CXTP, see [IANA].
サブタイプCXTPの実験モビリティICMPサブタイプ、[IANA]を参照してください。
Reserved Set to zero by the sender and ignored by the receiver.
予約セットは送信者によってゼロになり、受信機によって無視されます。
Message The body of the CTAR or CTAA message.
メッセージCTARまたはCTAAメッセージの本文。
CTAR messages for which a response is requested but fail to elicit a response are retransmitted. The initial retransmission occurs after a CXTP_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). CTAR messages should be retransmitted until either a response (which might be an error) has been obtained, or until CXTP_RETRY_MAX seconds after the initial transmission.
応答が要求されているが応答の引き出しに失敗するCTARメッセージが再送信されます。最初の再送信は、CXTP_REQUEST_RETRYの待機期間後に発生します。再送信は、指数関数的に増加する待機間隔で行う必要があります（毎回待機を2倍にします）。CTARメッセージは、応答（エラーである可能性がある）が取得されるまで、または最初の送信の数秒後にcxtp_retry_maxのいずれかになるまで再送信する必要があります。
MNs SHOULD generate the sequence number in the CTAR message randomly (also ensuring that the same sequence number has not been used in the last 7 seconds), and, for predictive transfer, MUST use the same sequence number in a CTAR message to the nAR as for the pAR. An AR MUST ignore the CTAR message if it has already received one with the same sequence number and MN IP address.
MNSは、CTARメッセージのシーケンス番号をランダムに生成する必要があります（同じシーケンス番号が過去7秒で使用されていないことも保証します）。パーのために。ARは、同じシーケンス番号とMN IPアドレスのあるものを既に受信している場合、CTARメッセージを無視する必要があります。
Implementations MAY, for research purposes, try other transport protocols. Examples are the definition of a Mobile IPv6 Mobility Header [MIPv6] for use with the FMIPv6 Fast Binding Update [FMIPv6] to allow bundling of both routing change and context transfer signaling from the MN to AR, or definition of a UDP protocol instead of ICMP. If such implementations are done, they should abide carefully by good Internet transport engineering practices and be used for prototype and demonstration purposes only. Deployment on large scale networks should be avoided until the transport characteristics are well understood.
実装は、研究目的で、他の輸送プロトコルを試してみることができます。例は、FMIPv6高速バインディングアップデート[FMIPv6]で使用するモバイルIPv6モビリティヘッダー[MIPV6]の定義です。。そのような実装が行われた場合、それらは優れたインターネット輸送エンジニアリングの慣行に慎重に順守し、プロトタイプとデモンストレーションの目的でのみ使用する必要があります。大規模なネットワークでの展開は、輸送特性がよく理解されるまで避ける必要があります。
Error Code Section Value Meaning
------------------------------------------------------------
BAD_CHECKSUM 3.1 0x01 Error code if the SCTP checksum fails.
bad_checksum 3.1 0x01エラーコードsctpチェックサムが失敗した場合。
Constant Section Default Value Meaning
--------------------------------------------------------------------
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of sec. CTAR messages before AR institutes rate limiting.
CT_REQUEST_RATE 6.3 10リクエスト/最大数秒。AR研究所の前のCTARメッセージは、制限を制限します。
CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time pAR should wait before aborting the transfer.
CT_MAX_TRANSFER_TIME 3.1 200 ms最大時間額額は、転送を中止する前に待つ必要があります。
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before initial retransmit on MN-AR interface.
CT_REQUEST_RETRY 3.2 2秒待つ間隔MN-ARインターフェイスでの最初の再送信。
CT_RETRY_MAX 3.2 15 seconds Give up retrying on MN-AR interface.
CT_RETRY_MAX 3.2 15秒MN-ARインターフェイスで再試行を放棄します。
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E |------- CTAR -------->| |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |--------- CT-Req ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V |------- CTAR -------->| |
| |----- CTDR (opt) ----->|
| | |
CTAR request to nAR
NARへのCTARリクエスト
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |------- CTAR -------->| |
I | |-------- CT-Req ------>|
M | | |
E | |<-------- CTD ---------|
: | | |
| | | |
V | | |
| | |
Whether the nAR sends the MN a CTAR reject message if CT is not supported is for future study.
CTがサポートされていない場合、NARがMNにCTAR拒否メッセージを送信するかどうかは、将来の研究のためです。
At this time, the threats to IP handover in general and context transfer in particular are not widely understood, particularly on the MN to AR link, and mechanisms for countering them are not well defined. Part of the experimental task in preparing CXTP for eventual standards track will be to better characterize threats to context transfer and design specific mechanisms to counter them. This section provides some general guidelines about security based on discussions among the Design Team and Working Group members.
現時点では、特にIPハンドオーバーとコンテキスト転送に対する脅威は、特にMNからARリンクで広く理解されていません。それらに対抗するためのメカニズムは十分に定義されていません。最終的な標準の追跡のためにCXTPを準備する際の実験的タスクの一部は、コンテキスト転送に対する脅威をよりよく特徴づけ、特定のメカニズムに対抗することです。このセクションでは、設計チームとワーキンググループメンバー間の議論に基づいて、セキュリティに関するいくつかの一般的なガイドラインを提供します。
The Context Transfer Protocol transfers state between access routers. If the MNs are not authenticated and authorized before moving on the network, there is a potential for masquerading attacks to shift state between ARs, causing network disruptions.
コンテキスト転送プロトコルは、アクセスルーター間の状態を転送します。ネットワークを移動する前に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攻撃を開始できます。最後に、Rogue Accessルーターは、パケットでモバイルノードをあふれさせ、DOS攻撃を試み、偽のコンテキスト転送要求を周囲のルーターに発行できます。
Consistency and correctness in context transfer depend on interoperable feature context definitions and how CXTP is utilized for a particular application. For some considerations regarding consistency and correctness that have general applicability but are articulated in the context of AAA context transfer, please see [EAP].
コンテキスト転送の一貫性と正確性は、相互運用可能な機能コンテキスト定義と、特定のアプリケーションにCXTPがどのように使用されるかに依存します。一般的な適用性を備えているが、AAAコンテキスト転送のコンテキストで明確にされている一貫性と正確性に関するいくつかの考慮事項については、[EAP]を参照してください。
The CXTP inter-router interface relies on IETF standardized security mechanisms for protecting traffic between access routers, as opposed to creating application security mechanisms. IPsec [RFC2401] MUST be supported between access routers.
CXTPインタールーターインターフェイスは、アプリケーションセキュリティメカニズムを作成するのではなく、アクセスルーター間のトラフィックを保護するためのIETF標準化されたセキュリティメカニズムに依存しています。IPSEC [RFC2401]は、アクセスルーター間でサポートする必要があります。
To avoid the introduction of additional latency due to the need for establishing a secure channel between the context transfer peers (ARs), the two ARs SHOULD establish such a secure channel in advance. The two access routers need to engage in a key exchange mechanism such as IKE [RFC2409], establish IPSec SAs, and define the keys, algorithms, and IPSec protocols (such as ESP) in anticipation of any upcoming context transfer. This will save time during handovers that require secure transfer. Such SAs can be maintained and used for all upcoming context transfers between the two ARs. Security should be negotiated prior to the sending of context.
コンテキスト転送ピア（ARS）間に安全なチャネルを確立する必要があるため、追加のレイテンシの導入を回避するために、2つのARはこのような安全なチャネルを事前に確立する必要があります。2つのアクセスルーターは、IKE [RFC2409]などの重要な交換メカニズムに従事し、IPSEC SASを確立し、今後のコンテキスト転送を見越してキー、アルゴリズム、およびIPSECプロトコル（ESPなど）を定義する必要があります。これにより、安全な転送が必要な手監督中の時間を節約できます。このようなSAは、2つのAR間の今後のすべてのコンテキスト転送に維持および使用できます。セキュリティは、コンテキストを送信する前に交渉する必要があります。
Access Routers MUST implement IPsec ESP [ESP] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST implement the replay protection mechanisms of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP. Strong security on the inter-router interface is required to protect against attacks by rogue routers, and to ensure confidentiality on the context transfer authorization key in predicative transfer.
アクセスルーターは、パケットごとの認証、整合性の保護、機密性を提供するために、非ヌル暗号化および認証アルゴリズムを使用してトランスポートモードでIPSEC ESP [ESP]を実装する必要があり、IPSECのリプレイ保護メカニズムを実装する必要があります。IPレイヤー保護が必要なシナリオでは、ESPのトンネルモードを使用する必要があります。IPSEC ESPを使用する場合は、非ヌル暗号化を使用する必要があります。Rogueルーターによる攻撃から保護し、述語転送でコンテキスト転送承認キーに関する機密性を確保するために、ルーター間インターフェイスの強力なセキュリティが必要です。
The details of IKE key exchange and other details of the IPsec security associations between routers are to be determined as part of the research phase associated with finalizing the protocol for standardization. These details must be determined prior to standardization. Other working groups are currently working on general security for routing protocols. Ideally, a possible solution for CXTP will be based on this work to minimize the operational configuration of routers for different protocols. Requirements for CXTP will be brought to the appropriate IETF routing protocol security working groups for consideration.
IKEキーエクスチェンジの詳細およびルーター間のIPSECセキュリティ関連の詳細は、標準化のプロトコルの最終化に関連する研究段階の一部として決定されます。これらの詳細は、標準化の前に決定する必要があります。他のワーキンググループは現在、ルーティングプロトコルの一般的なセキュリティに取り組んでいます。理想的には、CXTPの可能なソリューションは、さまざまなプロトコルのルーターの動作構成を最小限に抑えるために、この作業に基づいています。CXTPの要件は、検討のために適切なIETFルーティングプロトコルセキュリティワーキンググループにもたらされます。
The CTAR message requires the MN and AR to possess a shared secret key to calculate the authorization token. Validation of this token MUST precede context transfer or installation of context for the MN, removing the risk that an attacker could cause an unauthorized transfer. How the shared key is established is out of scope of this specification. If both the MN and AR know certified public keys of the other party, Diffie-Hellman can be used to generate a shared secret key [RFC2631]. If an AAA protocol of some sort is run for network entry, the shared key can be established using that protocol [PerkCal04].
CTARメッセージでは、MNとARが認証トークンを計算するための共有秘密鍵を所有する必要があります。このトークンの検証は、MNのコンテキスト転送またはコンテキストのインストールに先行する必要があり、攻撃者が不正な転送を引き起こす可能性があるというリスクを削除する必要があります。共有キーの確立方法は、この仕様の範囲外です。MNとARの両方が相手の認定公開キーを知っている場合、Diffie-Hellmanを使用して共有秘密の鍵を生成できます[RFC2631]。ネットワークエントリのために何らかの種類のAAAプロトコルが実行される場合、そのプロトコル[Perkcal04]を使用して共有キーを確立できます。
If predictive context transfer is used, the shared key for calculating the authorization token is transferred between ARs. A transfer of confidential material of this sort poses certain security risks, even if the actual transfer itself is confidential and authenticated, as is the case for inter-router CXTP. The more entities know the key, the more likely a compromise may occur. To mitigate this risk, nAR MUST discard the key immediately after using it to validate the authorization token. The MN MUST establish a new key with the AR for future CXTP transactions. The MN and AR SHOULD exercise care in using a key established for other purposes for also authorizing context transfer. The establishment of a separate key for context transfer authorization is RECOMMENDED.
予測コンテキスト転送が使用されている場合、ARS間で認証トークンを計算するための共有キーが転送されます。この種類の機密資料の転送は、実際の転送自体が機密であり、認証されている場合でも、特定のセキュリティリスクをもたらします。より多くのエンティティがキーを知っているほど、妥協が発生する可能性が高くなります。このリスクを軽減するために、NARは、それを使用して認証トークンを検証する後すぐにキーを破棄する必要があります。MNは、将来のCXTPトランザクションのARで新しいキーを確立する必要があります。MNとARは、コンテキスト転送を許可するために他の目的のために確立されたキーを使用する際にケアを行使する必要があります。コンテキスト転送承認のための個別のキーの確立が推奨されます。
Replay protection on the MN-AR protocol is provided by limiting the time period in which context is maintained. For predictive transfer, the pAR receives a CTAR message with a sequence number, transfers the context along with the authorization token key, and then drops the context and the authorization token key immediately upon completion of the transfer. For reactive transfer, the nAR receives the CTAR, requests the context that includes the sequence number and authorization token from the CTAR message that allows the pAR to check whether the transfer is authorized. The pAR drops the context and authorization token key after the transfer has been completed. The pAR and nAR ignore any requests containing the same MN IP address if an outstanding CTAR or CTD message is unacknowledged and has not timed out. After the key has been dropped, any attempt at replay will fail because the authorization token will fail to validate. The AR MUST NOT reuse the key for any MN, including the MN that originally possessed the key.
MN-ARプロトコルのリプレイ保護は、コンテキストが維持される期間を制限することにより提供されます。予測転送のために、PARはシーケンス番号を持つCTARメッセージを受信し、承認トークンキーとともにコンテキストを転送し、転送の完了後すぐにコンテキストと承認トークンキーをドロップします。反応転送の場合、NARはCTARを受信し、CTARメッセージからシーケンス番号と承認トークンを含むコンテキストを要求します。これにより、PARが転送が承認されているかどうかを確認します。PARは、転送が完了した後、コンテキストと承認トークンキーをドロップします。PARとNARは、未解決のCTARまたはCTDメッセージが承認されておらず、タイミングを出していない場合、同じMN IPアドレスを含むリクエストを無視します。キーが削除された後、承認トークンが検証に失敗するため、リプレイの試みは失敗します。ARは、元々キーを所有していたMNを含むMNのキーを再利用してはなりません。
DoS attacks on the MN-AR interface can be limited by having the AR rate limit the number of CTAR messages it processes. The AR SHOULD limit the number of CTAR messages to the CT_REQUEST_RATE. If the request exceeds this rate, the AR SHOULD randomly drop messages until the rate is established. The actual rate SHOULD be configured on the AR to match the maximum number of handovers that the access network is expected to support.
MN-ARインターフェイスに対するDOS攻撃は、ARレートが処理するCTARメッセージの数を制限することにより制限できます。ARは、CTARメッセージの数をCT_REQUEST_RATEに制限する必要があります。要求がこのレートを超える場合、ARはレートが確立されるまでメッセージをランダムにドロップする必要があります。実際のレートは、アクセスネットワークがサポートすると予想されるハンドオーバーの最大数と一致するようにARで構成する必要があります。
This document is the result of a design team formed by the chairs of the SeaMoby working group. The team included John Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins.
このドキュメントは、Seamobyワーキンググループの椅子によって形成された設計チームの結果です。チームには、ジョン・ラウニー、マジッド・ナクジリ、ラジーエフ・クッドリ、チャールズ・パーキンスが含まれていました。
Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the Context Transfer Protocol review.
Basavaraj Patil、Pekka Savola、およびAntti Tuominenは、コンテキスト転送プロトコルのレビューに貢献しました。
The working group chairs are Pat Calhoun and James Kempf, whose comments have been very helpful in the creation of this specification.
ワーキンググループの椅子は、パットカルホーンとジェームズケンプフであり、そのコメントはこの仕様の作成に非常に役立ちました。
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.
著者はまた、ジュリエン・ボーンレル、ヴィジェイ・デヴァラパリ、ダン・フォースバーグ、Xiaoming Fu、マイケル・ジョージアデス、ユスフ・モティワラ、フィル・ノウミラー、ヘシャム・ソリマン、ルシアン・スウシュの助けとこの文書の提案に感謝したいと思います。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[IANA] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[IANA] Kempf、J。、「Seamoby and Experimental Mobility Protocol Ianaの割り当ての指示」、RFC 4065、2005年7月。
[FHCT] R. Koodli and C. E. Perkins, "Fast Handovers and Context Transfers", ACM Computing Communication Review, volume 31, number 5, October 2001.
[FHCT] R. KoodliおよびC. E. Perkins、「高速ハンドオーバーとコンテキスト転送」、ACMコンピューティングコミュニケーションレビュー、第31巻、5番、2001年10月。
[TEXT] M. Nakhjiri, "A time efficient context transfer method with Selective reliability for seamless IP mobility", IEEE VTC-2003-Fall, VTC 2003 Proceedings, Vol.3, Oct. 2003.
[テキスト] M. Nakhjiri、「シームレスなIPモビリティの選択的信頼性を備えた時間効率の良いコンテキスト転送方法」、IEEE VTC-2003-FALL、VTC 2003 Proceedings、Vol.3、2003年。
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[Fmipv6] Koodli、R.、ed。、「モバイルIPv6用の高速ハンドオーバー」、RFC 4068、2005年7月。
[LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
[llmip] K. El Malki et al。、「モバイルIPv4の低レイテンシーハンドオフ」、進行中の作業。
[RFC3374] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[RFC3374] Kempf、J。、「問題説明：IPアクセスネットワーク内のノード間のコンテキスト転送を実行する理由」、RFC 3374、2002年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[TERM] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[Term] Mather、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
[PerkCal04] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[Perkcal04] Perkins、C。およびP. Calhoun、「モバイルIPv4の認証、認証、および会計（AAA）登録キー」、RFC 3957、2005年3月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[Mipv6] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[BT] IEEE, "IEEE Standard for information technology - Telecommunication and information exchange between systems - LAN/MAN - Part 15.1: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.1, 2002.
[BT] IEEE、「情報技術のIEEE標準 - システム間の電気通信と情報交換 - LAN/MAN -PART 15.1：ワイヤレスパーソナルエリアネットワーク（WPAN）のワイヤレスメディアアクセスコントロール（MAC）および物理レイヤー（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.
[EAP] Aboba、B.、Simon、D.、Arkko、J.、Eron、P。、およびH. Levokowetz、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、進行中の作業。
Basic Mobile IP handover signaling can introduce disruptions to the services running on top of Mobile IP, which may introduce unwanted latencies that practically prohibit its use for certain types of services. Mobile IP latency and packet loss are optimized through several alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP].
基本的なモバイルIPハンドオーバーシグナル伝達は、モバイルIPの上に実行されるサービスに混乱をもたらす可能性があり、特定の種類のサービスでの使用を実際に禁止する不要なレイテンシーを導入する可能性があります。モバイルIPレイテンシとパケット損失は、高速モバイルIP [FMIPv6]やLow Latency Mobile IP [LLMIP]など、いくつかの代替手順を通じて最適化されます。
Feature re-establishment through context transfer should contribute zero (optimally) or minimal extra disruption of services in conjunction with handovers. This means that the timing of context transfer SHOULD be carefully aligned with basic Mobile IP handover events, and with optimized Mobile IP handover signaling mechanisms, as those protocols become available.
コンテキスト転送による機能の再確立は、手眼のゼロ（最適）または最小限のサービスの妨害を最小限に抑える必要があります。これは、コンテキスト転送のタイミングを、基本的なモバイルIPハンドオーバーイベントと、これらのプロトコルが利用可能になるにつれて、最適化されたモバイルIPハンドオーバーシグナル伝達メカニズムと慎重に整合する必要があることを意味します。
Furthermore, some of those optimized mobile IP handover mechanisms may provide more flexibility in choosing the timing and ordering for the transfer of various context information.
さらに、これらの最適化されたモバイルIPハンドオーバーメカニズムの一部は、さまざまなコンテキスト情報の転送のタイミングと注文を選択する際の柔軟性を高める可能性があります。
In the past, credible proposals have been made in the Seamoby Working Group and elsewhere for using context transfer to the speed of handover of authentication, authorization, and accounting context, distributed firewall context, PPP context, and header compression context. Because the Working Group was not chartered to develop context profile definitions for specific applications, none of the documents submitted to Seamoby were accepted as Working Group items. At this time, work to develop a context profile definition for RFC 3095 header compression context [RFC3095] and to characterize the performance gains obtainable by using header compression continues, but is not yet complete. In addition, there are several commercial wireless products that reportedly use non-standard, non-interoperable context transfer protocols, though none is as yet widely deployed.
過去には、認証、承認、会計コンテキスト、分散ファイアウォールコンテキスト、PPPコンテキスト、ヘッダー圧縮コンテキストの引き渡し速度へのコンテキスト転送を使用するために、Seamobyワーキンググループおよびその他の場所で信頼できる提案が行われてきました。ワーキンググループは、特定のアプリケーションのコンテキストプロファイル定義を開発するためにチャーターされていなかったため、Seamobyに提出されたドキュメントはワーキンググループアイテムとして受け入れられませんでした。この時点で、RFC 3095ヘッダー圧縮コンテキスト[RFC3095]のコンテキストプロファイル定義を開発し、ヘッダー圧縮を使用して得られるパフォーマンスの向上を特徴付けるように作業しますが、まだ完全ではありません。さらに、非標準の非透過性コンテキスト転送プロトコルを使用すると伝えられるいくつかの商用ワイヤレス製品がありますが、まだ広く展開されていません。
As a consequence, it is difficult at this time to point to a solid example of how context transfer could result in a commercially viable, widely deployable, interoperable benefit for wireless networks. This is one reason why CXTP is being proposed as an Experimental protocol, rather than Standards Track. Nevertheless, it seems valuable to have a simple example that shows how handover could benefit from using CXTP. The example we consider here is transferring IPv6 MLD state [RFC2710]. MLD state is a particularly good example because every IPv6 node must perform at least one MLD messaging sequence on the wireless link to establish itself as an MLD listener prior to performing router discovery [RFC2461] or duplicate address detection [RFC2462] or before sending/receiving any 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.
結果として、現時点では、コンテキストの転送が、ワイヤレスネットワークにとって商業的に実行可能で広く展開可能な相互運用可能な利益をもたらす可能性があることの確かな例を示すことは困難です。これが、標準の追跡ではなく、CXTPが実験プロトコルとして提案されている理由の1つです。それにもかかわらず、CXTPを使用することでハンドオーバーがどのように利益を得ることができるかを示す簡単な例があることは価値があるようです。ここで検討する例は、IPv6 MLD状態[RFC2710]の転送です。すべてのIPv6ノードは、ワイヤレスリンクで少なくとも1つのMLDメッセージングシーケンスを実行して、ルーター発見[RFC2461]または再現アドレス検出[RFC2462]または送信/受信する前にMLDリスナーとしての地位を確立する必要があるため、特に良い例です。アプリケーション固有のトラフィック（モバイルIPハンドオーバーシグナル、ある場合は、モバイルIPハンドオーバーシグナルを含む）。ノードは、リンクに表示されるとすぐに、勧誘されたノードマルチキャストアドレスを購読する必要があります。アプリケーション固有のマルチキャストアドレスも再確立する必要があります。コンテキスト転送は、新しいワイヤレスリンクで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オクテットで、ヘッダーを追加する必要があります。および必要なルーターアラートホップバイホップオプションは、パディングを含む8オクテットです。合計MLDメッセージサイズは、サブスクライブされたマルチキャストアドレスあたり72オクテットです。RFC 2710は、レポートメッセージが承認されていないため、ノードがアドレスサブスクリプションごとに2〜3 MLDレポートメッセージを送信することを推奨しています。サブスクライブアドレスに送信された2つのMLDメッセージを仮定すると、MNはアドレスあたり144オクテットを送信する必要があります。すべてのノードマルチキャストアドレスとノードのリンクローカルアドレスの勧誘されたノードマルチキャストアドレスの両方に対してMLDメッセージが送信される場合、ノードが新しいリンクに引き渡すと、合計288オクテットが必要です。IPv6のいくつかの実装は、すべてのノードマルチキャストアドレスにMLDメッセージを送信しないことで最適化されていることに注意してください。ルーターは、少なくとも1つのノードがリンク（それ自体）に登場し、常にあることを推測できるためです。ただし、この計算の目的のために、IPv6の実装がコンフォーマルであり、メッセージが送信されると想定しています。MLDシグナル伝達に必要な時間は、20 kbpsまたは100 kbpsの帯域幅を想定することで、一部の代表的な数値を取得できます。これらの2ビットレートでは、プレルーター発見メッセージを実行する必要がないことからの節約は115ミリ秒です。それぞれ23ミリ秒。アプリケーション固有のマルチキャストアドレスがサブスクライブされている場合、節約される時間の量はより実質的になる可能性があります。
This example might seem a bit contrived as MLD is not used in the 3G cellular protocols, and wireless local area network protocols typically have enough bandwidth if radio propagation conditions are optimal. Therefore, sending a single MLD message might not be viewed as a performance burden. An example of a wireless protocol where MLD context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. IEEE 802.15.1 has two IP "profiles": one with PPP and one without. The profile without PPP would use MLD. The 802.15.1 protocol has a maximum bandwidth of about 800 kbps, shared between all nodes on the link, so a host on a moderately loaded 802.15.1 access point could experience the kind of bandwidth described in the previous paragraph.
MLDは3Gセルラープロトコルでは使用されていないため、この例が少し不自然に見えるかもしれません。また、無線伝播条件が最適な場合、ワイヤレスローカルエリアネットワークプロトコルには通常、十分な帯域幅があります。したがって、単一のMLDメッセージを送信することは、パフォーマンスの負担とは見なされない場合があります。MLDコンテキスト転送が役立つ可能性のあるワイヤレスプロトコルの例は、IEEE 802.15.1（Bluetooth）[BT]です。IEEE 802.15.1には2つのIP「プロファイル」があります。1つはPPPとなしで1つあります。PPPのないプロファイルはMLDを使用します。802.15.1プロトコルの最大帯域幅は約800 kbpsで、リンク上のすべてのノード間で共有されるため、適度にロードされた802.15.1アクセスポイントのホストは、前の段落で説明されている帯域幅の種類を体験できます。
In addition, 802.15.1 handover times are typically run upwards of a second or more because the host must resynchronize its frequency hopping pattern with the access point, so anything the IP layer could do to alleviate further delay would be beneficial.
さらに、802.15.1のハンドオーバー時間は、通常、ホストがアクセスポイントと周波数ホッピングパターンを再同時期にする必要があるため、通常は1秒以上上に走るため、IPレイヤーがさらに遅延を軽減するためにできることはすべて有益です。
The context-specific data field for MLD context transfer included in the CXTP Context Data Block message for a single IPv6 multicast address has the following format:
単一のIPv6マルチキャストアドレスのCXTPコンテキストデータブロックメッセージに含まれるMLDコンテキスト転送のコンテキスト固有のデータフィールドには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix on nAR Wireless Interface +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Subscribed IPv6 Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Subnet Prefix on a nAR Wireless Interface field contains a subnet prefix that identifies the interface on which multicast routing should be established. The Subscribed IPv6 Multicast Address field contains the multicast address for which multicast routing should be established.
NARワイヤレスインターフェイスフィールドのサブネットプレフィックスには、マルチキャストルーティングを確立するインターフェイスを識別するサブネットプレフィックスが含まれています。購読されたIPv6マルチキャストアドレスフィールドには、マルチキャストルーティングを確立するマルチキャストアドレスが含まれています。
The pAR sends one MLD context block per subscribed IPv6 multicast address.
PARは、サブスクライブされたIPv6マルチキャストアドレスごとに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コンテキストデータブロックを受信すると、State Machineは次のアクションを実行します。
- If the router is in the No Listeners present state on the wireless interface on which the Subnet Prefix field in the Context Data Block is advertised, it transitions into the Listeners Present state for the Subscribed IPv6 Multicast Address field in the Context Data Block. This transition is exactly the same as if the router had received a Report message.
- ルーターがコンテキストデータブロックのサブネットプレフィックスフィールドが宣伝されているワイヤレスインターフェイスに表示されていない状態にあるリスナーが表示されている場合、コンテキストデータブロックのサブスクライブIPv6マルチキャストアドレスフィールドのリスナーが状態に遷移します。この遷移は、ルーターがレポートメッセージを受信した場合とまったく同じです。
- If the router is in the Listeners present state on that interface, it remains in that state but restarts the timer, as if it had received a Report message.
- ルーターがそのインターフェイスに存在するリスナーにある場合、それはその状態に残りますが、まるでレポートメッセージを受信したかのようにタイマーを再起動します。
If more than one MLD router is on the link, a router receiving an MLD Context Data Block SHOULD send the block to the other routers on the link. If wireless bandwidth is not an issue, the router MAY instead send a proxy MLD Report message on the wireless interface that advertises the Subnet Prefix field from the Context Data Block. Since MLD routers do not keep track of which nodes are listening to multicast addresses (only whether a particular multicast address is being listened to) proxying the subscription should cause no difficulty.
複数のMLDルーターがリンク上にある場合、MLDコンテキストデータブロックを受信するルーターは、リンク上の他のルーターにブロックを送信する必要があります。ワイヤレス帯域幅が問題でない場合、ルーターは代わりに、コンテキストデータブロックからサブネットプレフィックスフィールドを宣伝するワイヤレスインターフェイスにプロキシMLDレポートメッセージを送信する場合があります。MLDルーターは、どのノードがマルチキャストアドレスを聞いているかを追跡していないため（特定のマルチキャストアドレスが聴かれているかどうかのみ）、サブスクリプションをプロキシングすることは困難を引き起こさないはずです。
Authors' Addresses
著者のアドレス
Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View、California 94043 USA
EMail: rajeev.koodli@nokia.com
John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland
John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland
EMail: john.loughney@nokia.com
Madjid F. Nakhjiri Motorola Labs 1301 East Algonquin Rd., Room 2240 Schaumburg, IL, 60196 USA
Madjid F. Nakhjiri Motorola Labs 1301 East Algonquin Rd。、Room 2240 Schaumburg、IL、60196 USA
EMail: madjid.nakhjiri@motorola.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
EMail: charles.perkins@.nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。