Network Working Group                                   J. Loughney, Ed.
Request for Comments: 4067                                   M. Nakhjiri
Category: Experimental                                        C. Perkins
                                                               R. Koodli
                                                               July 2005
        
                    Context Transfer Protocol (CXTP)
        

Status of This Memo

このメモのステータス

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2005).

著作権(C)インターネット協会(2005)。

Abstract

抽象

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.

この文書では、認可コンテキスト転送を可能にコンテキスト転送プロトコル(CXTP)を提示しています。モバイルノード上で実行されるアプリケーションは、最小限の中断で動作できるように、コンテキスト転送は、ノード・ベースのモビリティのためのより良いサポートを可能にします。主な目的は、待ち時間、パケット損失を低減するために、モバイルノードへとからのシグナル伝達の再起動を避けるためです。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  The Problem. . . . . . . . . . . . . . . . . . . . . . .  2
       1.2.  Conventions Used in This Document. . . . . . . . . . . .  3
       1.3.  Abbreviations Used in the Document . . . . . . . . . . .  3
   2.  Protocol Overview. . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.  Context Transfer Scenarios . . . . . . . . . . . . . . .  4
       2.2.  Context Transfer Message Format. . . . . . . . . . . . .  5
       2.3.  Context Types. . . . . . . . . . . . . . . . . . . . . .  6
       2.4.  Context Data Block (CDB) . . . . . . . . . . . . . . . .  7
       2.5.  Messages . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Transport. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       3.1.  Inter-Router Transport . . . . . . . . . . . . . . . . . 16
       3.2.  MN-AR Transport. . . . . . . . . . . . . . . . . . . . . 19
   4.  Error Codes and Constants. . . . . . . . . . . . . . . . . . . 20
   5.  Examples and Signaling Flows . . . . . . . . . . . . . . . . . 21
       5.1.  Network controlled, Initiated by pAR, Predictive . . . . 21
       5.2.  Network controlled, Initiated by nAR, Reactive . . . . . 21
        
       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. はじめに

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のプライベートアドレスのサポートは今後の検討課題であるもののプロトコルは、IPv4とIPv6の両方をサポートしています。

1.1. The Problem
1.1. 問題

"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無線アクセス技術をサポートし、相互運用可能なソリューションを提供することです。

1.2. Conventions Used in This Document
1.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]に記載されているように解釈されます。

1.3. Abbreviations Used in the Document
1.3. 文書で使用される略語

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.

モビリティ関連用語[TERM]は、基本的なモビリティの用語を定義します。その文書内の物質に加えて、我々は、この文書で次の用語と略語を使用しています。

CXTP Context Transfer Protocol

CXTPコンテキスト転送プロトコル

DoS Denial-of-Service

DoS攻撃サービス拒否

FPT Feature Profile Types

FPT機能プロファイルの種類

PCTD Predictive Context Transfer Data

PCTD予測コンテキスト転送データ

2. Protocol Overview
2.プロトコルの概要

This section provides a protocol overview. A context transfer can be either started by a request from the mobile node ("mobile controlled") or at the initiative of the new or the previous access router ("network controlled").

このセクションでは、プロトコルの概要を説明します。コンテキスト転送は、どちらかのモバイルノード(「モバイルコントロール」)から、または新規または以前のアクセスルータ(「ネットワークコントロール」)の主導で要求することによって開始することができます。

* The mobile node (MN) sends the CT Activate Request (CTAR) to its current access router (AR) immediately prior to handover when it is possible to initiate a predictive context transfer. In any case, the MN always sends the CTAR message to the new AR (nAR). If the contexts are already present, nAR verifies the authorization token present in CTAR with its own computation using the parameters supplied by the previous access router (pAR), and subsequently activates those contexts. If the contexts are not present, nAR requests pAR to supply them using the Context Transfer Request message, in which it supplies the authorization token present in CTAR.

予測コンテキスト転送を開始することが可能である場合*モバイルノード(MN)は、ハンドオーバの直前に、その現在のアクセスルータ(AR)にCT起動要求(CTAR)を送信します。いずれにせよ、MNは、常に新しいAR(新AR)にCTARメッセージを送信します。コンテキストがすでに存在している場合は、NARが、独自の計算が以前のアクセスルータ(PAR)から供給されたパラメータを使用してCTARに存在する認証トークンを検証し、その後、それらの文脈を活性化させます。コンテキストが存在しない場合は、NARが、それはCTARに存在する認証トークンを提供するコンテキスト転送要求メッセージを、使用してそれらを供給するのARを要求します。

* Either nAR or pAR may request or start (respectively) context transfer based on internal or network triggers (see Appendix A).

*新ARまたは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ののARであり、ターゲットノードがMNの新ARです。イベントは、そのようなハンドオーバーとして、行われたときにコンテキスト転送は行われます。私たちは、このようなイベントコンテキスト転送トリガを呼び出します。そのようなトリガーに応答して、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.

コンテキスト転送プロトコルメッセージは、データが特定の機能のコンテキストのために編成されている方法を識別機能プロファイルタイプ(FPTs)を使用します。 FPTsは、ノードが明確コンテキストの種類とプロトコルメッセージ内に存在するコンテキストパラメータを決定することを可能にする(IANAタイプ番号で)数のスペースに登録されています。コンテキストは、任意のIPは特定のMNにコンテキストを関連付けるために必要なアドレスと同様に、コンテキストセクション2.3でフォーマットに従ったデータブロック内の適切な地物データをレイアウトすることにより転送されます。コンテキスト転送開始メッセージは、ソースとターゲットノードを識別するパラメータ、機能コンテキストの所望のリストを含み、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.

新ARに取り付けMNの事前にコンテキスト転送を実行すると、ハンドオーバー性能を向上させることができます。これは場所を取るためには、一定の条件が満たされなければなりません。例えば、PARが切迫し、ハンドオーバーのに十分な時間と知識を持っている必要があります。これは、[FMIPv6と] [LLMIP]モバイルIPの高速ハンドオーバには、例えば、実現可能です。さらに、多くの携帯電話ネットワークは、事前にハンドオーバを検出するためのメカニズムを持っています。しかし、差し迫ったハンドオーバの事前知識が利用できない、またはそのような高速ハンドオーバなどのメカニズムが失敗した場合、MNが新ARにアタッチした後、機能コンテキストを取得すると、コンテキスト転送のためにのみ利用可能な手段です。ハンドオーバ後の実行コンテキスト転送は、まだ[FHCT]と[TEXT]に示すように、最初からすべてのコンテキストを再確立することよりも良いかもしれません。最後に、いくつかの状況では、単にハンドオーバシグナリングの間に転送する必要があるかもしれません。例えば、パケットごとに更新される任意の文脈が明確にその前のリンク上のMNへのパケット転送が終了した後にのみ転送する必要があります。

2.1. Context Transfer Scenarios
2.1. コンテキスト転送シナリオ

The Previous Access Router transfers feature contexts under two general scenarios.

前のアクセスルータの転送は、2つの一般的なシナリオの下でコンテキストを備えています。

2.1.1. Scenario 1
2.1.1. シナリオ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.

パー機能コンテキストが転送される、またはそれが内部で生成トリガー(MNが接続されているインターフェイス上で、例えば、リンク層トリガ)を受信MNからコンテキスト転送起動要求(CTAR)メッセージを受信します。 2.5節で説明したCTARメッセージは、新ARのIPアドレス、(転送されるすべてのコンテキストを要求デフォルトでは)並みのMNのIPアドレス、転送する機能コンテキストのリスト、および転送を許可トークンを提供します。 CT-起動要求メッセージまたはCTトリガに応答して、PARが予測機能コンテキストを含むコンテキスト転送データ(CTD)メッセージを送信します。 2.5節で説明このメッセージは、MNの以前のIPアドレスが含まれています。新ARは、CTARメッセージ内に存在するMNのトークンを検証するための認証トークンを計算することもパラメータが含まれています。 MNは関係なく、常にMNは、そのコンテキスト転送が確実に行われた確認するために何の意味がないので、それは、ParにCTARメッセージを送信したかどうかの新ARにCTARメッセージを送ることを思い出してください。必要に応じて、常に新ARにCTARメッセージを送信することにより、コンテキスト転送要求が(下記参照)のARに送信することができます。

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.

コンテキスト転送が新ARがそれを要求せずに行われると、NARがその認証トークンを提示するMNが必要です。コンテキストがすでに存在する可能性があるため、MNは、それに接続する際に、新ARで局所的にこれを行うと、パフォーマンスが向上し、セキュリティが向上します。トークンの検証は、コンテキストを持つルータで行われます。

2.1.2. Scenario 2
2.1.2. シナリオ2

In the second scenario, pAR receives a Context Transfer Request (CT-Req) message from nAR, as described in Section 2.5. The nAR itself generates the CT-Req message as a result of receiving the CTAR message, or alternatively, from receiving a context transfer trigger. In the CT-Req message, nAR supplies the MN's previous IP address, the FPTs for the feature contexts to be transferred, the sequence number from the CTAR, and the authorization token from the CTAR. In response to a CT-Req message, pAR transmits a Context Transfer Data (CTD) message that includes the MN's previous IP address and feature contexts. When it receives a corresponding CTD message, nAR may generate a CTD Reply (CTDR) message to report the status of processing the received contexts. The nAR installs the contexts once it has received them from the pAR.

セクション2.5で説明したように第2のシナリオでは、PARが、新ARからコンテキスト転送要求(CT-REQ)メッセージを受信します。新AR自体は、コンテキスト転送トリガを受信すると、CTARメッセージを受信し、あるいは結果としてCT-Reqメッセージを生成します。 CT-Reqメッセージには、NARが、転送する機能コンテキストのFPTs、CTARからシーケンス番号、およびCTARから認証トークンをMNの以前のIPアドレスを提供します。 CT-Reqメッセージに応えて、PARがMNの以前のIPアドレスと機能コンテキストを含んでいるコンテキスト転送データ(CTD)メッセージを送信します。それは、対応するCTDメッセージを受信した場合、新ARは、受信されたコンテキストの処理のステータスを報告するCTD応答(CTDR)メッセージを生成してもよいです。それは、Parからそれらを受け取った後、NARがコンテキストをインストールします。

2.2. Context Transfer Message Format
2.2. コンテキスト転送メッセージの形式

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つのまたは複数のデータブロックから成ります。データブロックは、より効率的な転送を保証するために一緒に束ねてもよいです。断片化は問題にはならないので、インターARインタフェースに、SCTPを使用します。 MN-ARインタフェース上、トランスポートプロトコルとIPプロトコルヘッダを含む全パケットサイズは、パケットの断片化を避けるために、パスMTU未満であるべきです。各メッセージは、5ビットのメッセージタイプコードと一緒に、下位オクテットに3ビットのバージョン番号フィールドを含みます。この仕様は、プロトコルのバージョン1に適用され、したがって、バージョン番号フィールドが0x1に設定されなければなりません。プロトコルの将来の改訂は、バイナリ互換性のない変更を加えた場合、バージョン番号は増加しなければなりません。

2.3. Context Types
2.3. コンテキストタイプ

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:

コンテキストは16ビットの符号なし整数であるFPTコードによって識別されます。各コンテキストタイプの意味は、仕様書によって決定されます。コンテキストタイプ番号は、レジストリIANA [IANA]によって維持し、この文書に記載されているメッセージの仕様に従って処理において集計されます。新ARによって各コンテキストのインスタンスは、特定のコンテキスト・タイプに関連付けられた仕様に沿ってこの文書に記載されているメッセージによって決定されます。次の図は、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のコンテキスト転送は、データが新ARにインスタンス化に失敗したコンテキストの要素に応じて異なるステータスコードを持っているかもしれません。

2.4. Context Data Block (CDB)
2.4. コンテキストデータブロック(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.

コンテキストデータブロック(CDB)は、要求と応答の操作の両方に使用されます。要求が構成されている場合、最初の4つのオクテットは、典型的に必要である(以下CTARを参照します)。実際の特徴コンテキスト自体を転送するために使用される場合、コンテキストデータが存在し、プレゼンスベクトルが時々存在します。

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Feature Profile Type (FPT) | Length |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Presence Vector (if P = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |機能プロファイルタイプ(FPT)|長さ| P |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |プレゼンスベクトル(P = 1の場合)| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜データ〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

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ビットにかかわらず、データフィールドのサイズの、コンテキストタイプ仕様に従ってデータフィールドの順序と同じです。 Lengthフィールドは、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つのオクテットの和によって定義されることがわかり、マイナスそのすべてのコンテキストデータの累積サイズ暗黙的にデフォルト値として与えられています。

2.5. Messages
2.5. メッセージ

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メッセージを識別するようのみMNごとにコンテキスト転送動作時に進行中であってもよいです。 「V」フラグはIPアドレスはIPv4またはIPv6であるか否かを示します。

2.5.1. Context Transfer Activate Request (CTAR) Message
2.5.1. コンテキスト転送起動要求(CTAR)メッセージ

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.

このメッセージは、常にコンテキスト転送を要求するために、新ARにMNによって送信されます。コンテキストを転送する必要がある場合は、MNがわからない場合でも、MNは、CTARメッセージを送信します。このメッセージの確認が必要な場合、MNは1に「A」フラグをセットそうでない場合はMNは、確認応答を期待していません。このメッセージは、転送を必要とFPTsのリストを含むことができます。

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.

まだのARに接続しながら、MNはまた、PAR発このメッセージを送信することができます。この場合、MNは、新ARのIPアドレスを含んでいます。メッセージは、新ARに送信された場合にそうでない場合、パーアドレスが送信されます。 MNはそうパーキャッシュされたメッセージを使用するかどうかを決定することができるのARと新ARの両方に送信されたメッセージに設定されたものと同じ値にシーケンス番号を設定しなければなりません。

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の。|タイプ| V | A |予約|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜MNの前のIPアドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜前(新)AR IPアドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | MN許可トークン| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |要求されたコンテキストデータブロック(存在する場合)| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |次に要求コンテキストデータブロック(存在する場合)| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ........ | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Vers. Version number of CXTP protocol = 0x1

VERS。 CXTPプロトコルのバージョン番号= 0x1の

Type CTAR = 0x1

CTAR = 0x1のを入力

'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.

「0」、IPv6アドレスに設定「V」フラグ。 「1」に設定すると、IPv4が対応しています。

'A' bit If set, the MN requests an acknowledgement.

「」ビットを設定した場合、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.

新AR / 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(キー、(前のIPアドレス|シーケンス番号| 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.

キーは、MNとのARの間の共有秘密であり、CDBは、データブロックは、CTARメッセージに含まれて転送されるコンテキストを指定して、すべてのコンテキストの連結です。

2.5.2. Context Transfer Activate Acknowledge (CTAA) Message
2.5.2. コンテキスト転送の有効化(CTAA)メッセージを確認

This is an informative message sent by the receiver of CTAR to the MN to acknowledge a CTAR message. Acknowledgement is optional, depending on whether the MN requested it. This message may include a list of FPTs that were not successfully transferred.

これは、CTARメッセージを確認するためにMNにCTARの受信機によって送信される情報メッセージです。謝辞は、MNがそれを要求したかどうかに応じて、オプションです。このメッセージは正常に転送されなかったFPTsのリストを含むことができます。

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の。|タイプ| V |予約|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜移動ノードの前のIPアドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | FPT(存在する場合)|ステータスコード|予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ........ | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Vers. Version number of CXTP protocol = 0x1

VERS。 CXTPプロトコルのバージョン番号= 0x1の

Type CTAA = 0x2

タイプCTAA = 0x2の

'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.

「0」、IPv6アドレスに設定「V」フラグ。 「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

........より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.

新ARへのARによって送信され、特徴データ(CXTPデータ)を含みます。このメッセージは、両方の予測と通常のCTを処理します。このメッセージに含まれる受信確認フラグ、「A」は、応答がのARによって必要とされるかどうかを示します。

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 |予約|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |経過時間(ミリ秒)| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜移動ノードの前の気付アドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ^ |アルゴリズム|キーの長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + PCTD |キー|のみ+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + V〜まずコンテキストデータブロック〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜次のコンテキストデータブロック〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜........〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Vers. Version number of CXTP protocol = 0x1

VERS。 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」、IPv6アドレスに設定「V」フラグ。 「1」に設定すると、IPv4が対応しています。

'A' bit When set, the pAR requests an acknowledgement.

設定「」ビットは、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が予測送信されると、(アルゴリズム、鍵長、キー自体を含む)指定されたパラメータは、新ARがローカルトークンを計算し、CTARメッセージ内に存在するトークンに対してそれを確認することを可能にします。 PARを新ARは、CTARメッセージを受信する前に、CT-Reqメッセージが送信されたことを示す、ヌル許可トークンとCTDメッセージを受信した場合、この材料はまた、送信されます。 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メッセージは、コンテキスト転送が成功した、またはCT_MAX_HANDOVER_TIMEの有効期限が切れるまでのことを示すパーから受信されるまでCTDメッセージをキャッシュします。予測CTDメッセージが到着することができなかった、または文脈が破損した場合新ARは、同じシーケンス番号を含むCT-Reqメッセージを送信することができます。この場合、新ARは、一致シーケンス番号を有するCT-Reqメッセージを送信およびPARは、コンテキストを再送信することができます。

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.

このメッセージは、成功または失敗を示す、CTDで「」フラグの値に応じてPAR発新ARによって送信されます。

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 |予約|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜移動ノードの前のIPアドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 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.

「0」、IPv6アドレスに設定「V」フラグ。 「1」に設定すると、IPv4が対応しています。

'S' bit When set to one, this bit indicates that all feature contexts sent in CTD or PCTD were received successfully.

いずれかに設定「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に設定されていないとき。

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が現在進行中のCT処理をキャンセルするためにPAR発CTCを送信することができます。

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 |予約|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜移動ノードの前のIPアドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

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.

オクテット単位での長さはメッセージの長さ。

'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses.

「0」、IPv6アドレスに設定「V」フラグ。 「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オクテット。

2.5.6. Context Transfer Request (CT-Req) Message
2.5.6. コンテキスト転送要求(CT-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.

コンテキスト転送の開始を要求するためにPAR発、新ARによって送信されます。このメッセージは、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) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 |予約|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜移動ノードの前のIPアドレス〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 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.

「0」、IPv6アドレスに設定「V」フラグ。 「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.

第2.5.1項で述べたように計算MNの許可トークンアン偽造値。これは、コンテキスト転送を実行する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.

シーケンス番号は、以前に送信されたコンテキストの要求を相関させるためのARによって使用されます。 MNは、ハンドオーバ前にCTARを送信した場合、予測転送において、PARがPCTDを使用して新ARにコンテキストを押します。 CTDが失敗した場合、NARが再送信するためにどの文脈を決定するためのARを可能に、同じシーケンス番号とCT-REQを送信します。 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メッセージを処理せずに許可トークンを計算するために必要な鍵材料及び他の情報を送信します。新ARは、コンテキスト転送トリガを受信するが、まだ許可トークンとCTARメッセージを受信して​​いない場合には反応転送については、CT-REQで許可トークンフィールドはゼロに設定されています。 PARでキーイング材料を含むように指示し、許可トークンを計算するのに必要な他の情報としてこれを解釈し、メッセージが原因予測転送に送られたかのようCTDメッセージにこの材料を含みます。これは、MNが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 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チェックサム計算が失敗した場合、新ARが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の機能のコンテキストコレクションに対応しています。単一のストリームは、シンプルさを提供します。ヘッドオブラインブロッキングを防止するための複数のストリームを使用することは、今後の検討課題です。順不同配信は、受信機が別のMNに属するメッセージのインシーケンス配信のためにブロックしないことを可能にします。 SCTPヘッダ内のペイロードプロトコル識別子は「CXTP」です。ルータ間CXTPは[IANA] Seamoby SCTPポートを使用しています。

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.

コンテキスト転送情報の適時性は、最大許容ハンドオーバ遅延時間に対応するためにCT_MAX_TRANSFER_TIMEにSCTP最大再送値を設定することにより、収容されるべきです。 ARは、特定の無線リンク技術とローカル無線伝播条件に適応するようにCT_MAX_TRANSFER_TIMEで構成されるべきです。 SCTPメッセージバンドルは、メッセージの送信に余分な遅延を低減するためにオフにする必要があります。 CXTP内、新ARはCXTPメッセージの最初のフラグメントの受信から再送信タイマを推定し、いずれかのコンテキスト転送が完了したまたは推定再送タイマが満了するまで、MNからのすべてのIPトラフィックを処理避けるべきです。両方のルータは、PR-SCTP [PR-SCTP]をサポートしている場合、PR-SCTPを使用しなければなりません。それは送信と同様に再送するように適用されるようにPR-SCTPは、送信()オペレーション([SCTP]セクションで定義された10.1 E)の寿命パラメータを修正します。ライフタイムの期限が切れると、データチャンクが確認されていない場合には、送信機が肯定応答されるまで、データが再送されるか、または接続がタイムアウトベースのプロトコルでに対し、再送を停止し、PR-SCTPです。

The format of Payload Data Chunk taken from [SCTP] is shown in the following diagram.

[SCTP]から取られたペイロードデータチャンクのフォーマットは、次の図に示されています。

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ User Data (seq n of Stream S) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | = 0を入力し|予約| U | B | E |長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TSN | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ストリーム識別子S |ストリームシーケンス番号N | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ペイロードプロトコル識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜ユーザデータ(ストリームSの配列のN)〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

'U' bit The Unordered bit. MUST be set to 1 (one). 'B' bit The Beginning fragment bit. See [SCTP].

「U」を順不同ビットビット。 1(1)に設定しなければなりません。 「B」は、以降フラグメントビットビット。 [SCTP]を参照してください。

'E' bit The Ending fragment bit. See [SCTP].

「E」はエンディングフラグメントビットビット。 [SCTP]を参照してください。

TSN Transmission Sequence Number. See [SCTP].

TSN送信シーケンス番号。 [SCTP]を参照してください。

Stream Identifier S Identifies the context transfer protocol stream.

ストリーム識別子Sは、コンテキスト転送プロトコルのストリームを識別する。

Stream Sequence Number n Since the 'U' bit is set to one, the receiver ignores this number. See [SCTP].

ストリームシーケンス番号N「U」ビットが1に設定されているので、受信側は、この番号を無視します。 [SCTP]を参照してください。

Payload Protocol Identifier Set to 'CXTP' (see [IANA]).

'CXTP' へのペイロードプロトコル識別子セット([IANA]を参照)。

User Data Contains the context transfer protocol messages.

ユーザーデータは、コンテキスト転送プロトコルメッセージが含まれています。

If a CXTP deployment will never run over the public Internet, and it is known that congestion is not a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. For example, piggybacking CXTP messages on top of handover signaling for routing, such as provided by FMIPv6 in ICMP [FMIPv6]. Implementations of CXTP MAY support ICMP for such purposes. If such piggybacking is used, an experimental message extension for the protocol on which CXTP is piggybacking MUST be designed. Direct deployment on top of a transport protocol for experimental purposes is also possible. In this case, the researcher

CXTPの展開は、公共のインターネット上で実行されることはありません、輻輳がアクセスネットワークに問題がないことが知られている場合は、代わりのトランスポートプロトコルは、実験のために適切な車かもしれ。例えば、[FMIPv6と】ICMPにFMIPv6とによって提供されるような、ルーティングのためのシグナリングのハンドオーバの上CXTPメッセージをピギーバック。 CXTPの実装は、そのような目的のためにICMPをサポートするかもしれません。このようなピギーバックを使用する場合、CXTPがピギーバックされたプロトコルのための実験メッセージ拡張は、設計されなければなりません。実験目的のためのトランスポートプロトコルの上に直接展開することも可能です。この場合には、研究者

MUST be careful to accommodate good Internet transport protocol engineering practices, including using retransmits with exponential backoff.

指数バックオフして再送を使用することを含む優れたインターネットトランスポートプロトコルエンジニアリングの実践を、対応するために注意しなければなりません。

3.2. MN-AR Transport
A.o.マナーTransberh

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インタフェースは実装しなければならないとCTARとCTAAメッセージを転送するためにICMPを使用すべきです。 ICMPは、シグナリングが失われた場合、パケットを再送するための条項が含まれていないので、CXTPプロトコルは、MN-ARインターフェイス上で輸送性能を向上させるための条項が組み込まれています。 MN及びARは、コンテキストデータブロック識別子の数を制限する必要がICMPはIPレベル以上断片化のための規定を持っていないため、メッセージは、単一のパケットに収まるようCTAR及びCTAAメッセージに含まれます。 CXTPは、実験的なモビリティICMPタイプ[IANA]を使用しています。次のようにCXTPメッセージのICMPメッセージの形式は次のとおりです。

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message... +-+-+-+-+-+-+-+-+-+-+-+- - - -

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|コード|チェックサム| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブタイプ|予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |メッセージ... + - + - + - + - + - + - + - + - + - + - + - + - - - -

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待機期間後に発生します。再送は、指数関数的に増加する待機間隔(待機たび倍加)を用いて行わなければなりません。 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.

MNは、(また、同じシーケンス番号が、最後の7秒で使用されていないことを保証する)ランダムCTARメッセージ内のシーケンス番号を生成する必要があります、そして、予測転送用、として新ARにCTARメッセージ内の同じシーケンス番号を使用する必要がありますARのため。それはすでに同じシーケンス番号とMNのIPアドレスと1を受信した場合、ARは、CTARメッセージを無視しなければなりません。

Implementations MAY, for research purposes, try other transport protocols. Examples are the definition of a Mobile IPv6 Mobility Header [MIPv6] for use with the FMIPv6 Fast Binding Update [FMIPv6] to allow bundling of both routing change and context transfer signaling from the MN to AR, or definition of a UDP protocol instead of ICMP. If such implementations are done, they should abide carefully by good Internet transport engineering practices and be used for prototype and demonstration purposes only. Deployment on large scale networks should be avoided until the transport characteristics are well understood.

実装は、研究目的のために、他のトランスポートプロトコルをしようとします。例は、定義されたモバイルIPv6のモビリティヘッダ[MIPv6の】FMIPv6とファストICMPの代わりにアップデート[FMIPv6と】UDPプロトコルの両方のルーティング変更およびコンテキストARにMNからシグナリング転送、または定義のバンドリングを可能にするために、結合に使用するための。そのような実装が行われている場合、彼らは良いインターネットトランスポートエンジニアリングの実践によって慎重に遵守すべきであるとプロトタイプとデモンストレーションの目的にのみ使用すること。輸送特性がよく理解されるまで、大規模なネットワークでの展開は避けるべきです。

4. Error Codes and Constants
4.エラーコードと定数
   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ミリ秒の最大量は、転送を中止する前に待機しなければなりません。

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インターフェイス上で再試行を放棄します。

5. Examples and Signaling Flows
5.例とシグナリングフロー
5.1. Network Controlled, Initiated by pAR, Predictive
5.1. ネットワークのAR、予測によって開始され、制御
                 MN                    nAR                     pAR
                 |                      |                       |
            T    |                      |                  CT trigger
            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) ----->|
                 |                      |                       |
        
5.3. Mobile Controlled, Predictive New L2 up/Old L2 down
5.3. モバイル制御され、予測新しいL2アップ/旧L2ダウン

CTAR request to nAR

新ARに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.

新ARは、CTがサポートされていない場合、MN 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リンクにMNに、理解されていないが、それらに対処するためのメカニズムは十分に定義されていません。最終的な標準化トラックのCXTPを製造するのに実験的なタスクの一部は、よりよいそれらに対抗するためにコンテキスト転送および設計特定のメカニズムへの脅威を特徴付けることになります。このセクションでは、設計チームとワーキンググループメンバー間の議論に基づいてセキュリティに関するいくつかの一般的なガイドラインを提供します。

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.

コンテキスト転送プロトコルは、アクセスルータ間で状態を転送します。 MNが認証され、ネットワーク上を移動する前に許可されていない場合は、ネットワークの混乱を引き起こし、のAR間で状態をシフトする攻撃をマスカレードの可能性があります。

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.

また、DoS攻撃は、複数のコンテキスト転送を要求し、その後消えによってによってアクセスルータに向けてのMNから起動することができます。最後に、不正アクセスルータは、パケットをモバイルノードをあふれさせる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]を参照してください。

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)との間のセキュアチャネルを確立するための必要性にさらなる待ち時間の導入を回避するために、2つのアクセスルータは、事前に安全なチャネルを確立すべきです。 2つのアクセスルータは、IKE [RFC2409]として鍵交換メカニズムに関与IPSec SAを確立し、任意の今後のコンテキスト転送を見越して鍵、アルゴリズム、および(例えば、ESPなど)のIPSecプロトコルを定義する必要があります。これは、安全な転送を必要とするハンドオーバ中の時間の節約になります。そのようなSAが維持二つのARの間のすべての今後のコンテキスト転送のために使用することができます。セキュリティは、前のコンテキストの送信に交渉されるべきです。

Access Routers MUST implement IPsec ESP [ESP] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST implement the replay protection mechanisms of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP. Strong security on the inter-router interface is required to protect against attacks by rogue routers, and to ensure confidentiality on the context transfer authorization key in predicative transfer.

アクセスルータは、パケットごとの認証、完全性保護と機密性を提供するために、およびIPsecのリプレイ保護メカニズムを実装しなければならない非ヌル暗号化および認証アルゴリズムとトランスポートモードで[ESP] IPsecのESPを実装しなければなりません。 IP層の保護が必要とされるこれらのシナリオでは、トンネルモードでESPを使用すべきです。 null以外の暗号化は、IPSec ESPを使用する際に使用すべきです。ルータ間のインターフェイス上で強力なセキュリティが不正なルータによる攻撃から保護するために、と断定転送におけるコンテキスト転送認証キーの機密性を確保するために必要とされます。

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ルーティングプロトコルのセキュリティワーキンググループにもたらされるだろう。

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メッセージは、認証トークンを計算するための共有秘密鍵を所有する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.

予測コンテキスト転送を使用する場合は、許可トークンを算出するための共有鍵は、アクセスルータ間で転送されます。この種の機密資料の転送は、ルータ間CXTPの場合のように実際の転送自体は、機密情報や認証された場合でも、特定のセキュリティリスクをもたらします。より多くのエンティティが鍵を知って、より多くの可能性が高い妥協が発生することがあります。このリスクを軽減するために、NARが認証トークンを検証するためにそれを使用した直後に鍵を捨てなければなりません。 MNは、将来CXTP取引のためのARと新しい鍵を確立する必要があります。 MNとARは、コンテキスト転送を許可するために、他の目的のために設立され、キーを使用して注意を払うべきです。コンテキスト転送承認のための独立したキーの確立が推奨されます。

Replay protection on the MN-AR protocol is provided by limiting the time period in which context is maintained. For predictive transfer, the pAR receives a CTAR message with a sequence number, transfers the context along with the authorization token key, and then drops the context and the authorization token key immediately upon completion of the transfer. For reactive transfer, the nAR receives the CTAR, requests the context that includes the sequence number and authorization token from the CTAR message that allows the pAR to check whether the transfer is authorized. The pAR drops the context and authorization token key after the transfer has been completed. The pAR and nAR ignore any requests containing the same MN IP address if an outstanding CTAR or CTD message is unacknowledged and has not timed out. After the key has been dropped, any attempt at replay will fail because the authorization token will fail to validate. The AR MUST NOT reuse the key for any MN, including the MN that originally possessed the key.

MN-ARプロトコルにリプレイ保護は、コンテキストが維持される時間を制限することによって提供されます。予測転送のために、PARが、シーケンス番号にCTARメッセージを受信する認可トークンキーとともにコンテキストを転送し、そして、コンテキスト転送が完了すると直ちに認可トークンキーをドロップ。反応転送のために、新ARは、CTARを受信PARを転送が許可されているかどうかチェックすることを可能にするCTARメッセージからシーケンス番号と許可トークンを含むコンテキストを要求します。 PARで転送が完了した後にコンテキストと認証トークンキーを削除します。優れたCTARまたはCTDメッセージは未確認で、タイムアウトしていない場合のARとNARが同じMNのIPアドレスを含むすべての要求を無視します。キーが削除された後、認証トークンが検証に失敗するため、リプレイの試みは失敗します。 ARはもともと鍵を持っMN含めて、任意のMNのためのキーを再利用してはいけません。

DoS attacks on the MN-AR interface can be limited by having the AR rate limit the number of CTAR messages it processes. The AR SHOULD limit the number of CTAR messages to the CT_REQUEST_RATE. If the request exceeds this rate, the AR SHOULD randomly drop messages until the rate is established. The actual rate SHOULD be configured on the

MN-ARインタフェース上のDoS攻撃は、AR率は、処理するCTARメッセージの数を制限することによって制限することができます。 ARはCT_REQUEST_RATEにCTARメッセージの数を制限する必要があります。要求はこのレートを超える場合は料金が確立されるまで、ARはランダムにメッセージを削除する必要があります。実際のレートは上で設定する必要があります

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、マジドNakhjiri、ラジーブKoodliとチャールズ・パーキンスが含まれています。

Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the Context Transfer Protocol review.

Basavarajパティル、ペッカSavola、およびアンティトゥオミネンは、コンテキスト転送プロトコルの見直しに貢献しました。

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.

著者らはまた、この文書で彼らの助けと提案のためにジュリアンBournelle、ビジェイDevarapalli、ダンフォースバーグ、暁明フー、マイケルGeorgiades、ユスフMotiwala、フィル・Neumiller、Heshamソリマン、そしてルシアンSuciuに感謝したいと思います。

8. References
8.参照文献
8.1. Normative References
8.1. 引用規格

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換(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.デアリング、 "インターネットプロトコルバージョン6(IPv6)のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[ESP]ケント、S.とR.アトキンソン、 "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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、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]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル(SCTP)部分的な信頼性拡張"、RFC 3758、2004年5月。

[IANA] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.

[IANA]ケンプ、J.、RFC 4065、2005年7月 "Seamobyと実験モビリティプロトコルのIANAの割り当てのための手順"。

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コンピューティングコミュニケーションレビュー、ボリューム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秋、VTC 2003の会報、第3巻、2003年10月。

[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.

[FMIPv6と] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。

[LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.

【LLMIP] K.エルMalkiら、「モバイルIPv4における低遅延ハンドオフ」、進行中の作業。

[RFC3374] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.

[RFC3374]ケンプ、J.、「問題の説明:IPアクセスネットワーク内のノード間のコンテキスト転送を実行した理由」、RFC 3374、2002年9月。

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。

[TERM] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.

[TERM]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。

[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.

[RFC2631]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、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]パーキンス、C.とP.カルフーン、 "モバイルIPv4のための認証、許可、アカウンティング(AAA)の登録キー"、RFC 3957、2005年3月。

[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[MIPv6の]ジョンソン、D.、パーキンス、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "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.シンプソン、 "IPバージョン6のための近隣探索(IPv6)の"、RFC 2461、1998年12月。

[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮(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 - パート15.1:無線媒体アクセス制御(MAC)及び無線パーソナルエリアネットワークのための物理層(PHY)仕様(WPANの)」、 IEEE 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.、サイモン、D.、Arkko、J.、Eron、P.、およびH. Levokowetz、 "拡張認証プロトコル(EAP)鍵管理フレームワーク"、ProgressのWork。

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待ち時間及びパケット損失は、高速モバイルIP [FMIPv6と]と低レイテンシモバイルIP [LLMIP]のようないくつかの代替手順によって最適化されます。

Feature re-establishment through context transfer should contribute zero (optimally) or minimal extra disruption of services in conjunction with handovers. This means that the timing of context transfer SHOULD be carefully aligned with basic Mobile IP handover events, and with optimized Mobile IP handover signaling mechanisms, as those protocols become available.

コンテキスト転送スルー機能の再確立がハンドオーバと連携してサービスのゼロ(最適)または最小限の余分な混乱を貢献すべきです。これらのプロトコルが利用可能になるので、これは、コンテキスト転送のタイミングを注意深く基本モバイルIPハンドオーバイベントと、および最適化されたモバイルIPハンドオーバシグナリングメカニズムと位置合わせされるべきであることを意味します。

Furthermore, some of those optimized mobile IP handover mechanisms may provide more flexibility in choosing the timing and ordering for the transfer of various context information.

さらに、これらの最適化されたモバイルIPハンドオーバ機構の一部は、タイミングを選択し、様々なコンテキスト情報の転送のために注文でより多くの柔軟性を提供することができます。

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に提出された書類はいずれもワーキンググループ項目として受け入れられませんでした。この時点で、RFC 3095ヘッダー圧縮コンテキスト[RFC3095]のコンテキストプロファイル定義を開発するために動作し続けヘッダ圧縮を用いて得られるパフォーマンスの向上を特徴付けるために、まだ完了していません。また、何もまだ広く展開されていないものの、伝え、非標準、非相互運用可能コンテキスト転送プロトコルを使用して、いくつかの商用ワイヤレス製品があります。

As a consequence, it is difficult at this time to point to a solid example of how context transfer could result in a commercially viable, widely deployable, interoperable benefit for wireless networks. This is one reason why CXTP is being proposed as an Experimental protocol, rather than Standards Track. Nevertheless, it seems valuable to have a simple example that shows how handover could benefit from using CXTP. The example we consider here is transferring IPv6 MLD state [RFC2710]. MLD state is a particularly good example because every IPv6 node must perform at least one MLD messaging sequence on the wireless link to establish itself as an MLD listener prior to performing router discovery [RFC2461] or duplicate address detection [RFC2462] or before sending/receiving any

その結果、それは、コンテキスト転送は、無線ネットワークのための商業的に実現可能な、広く展開可能な、相互運用可能な利益をもたらすことができる方法の一例の固体を指すように、この時点では困難です。これはCXTPはむしろ標準化過程よりも実験プロトコール、として提案されている理由の一つです。それにもかかわらず、ハンドオーバがCXTPを使用してから利益を得ることができる方法を示して簡単な例を持っている貴重なようです。我々はここで考える例では、IPv6 MLD状態[RFC2710]を転送しています。 MLDの状態は、すべてのIPv6ノードが前ルータの発見[RFC2461]またはアドレス検出[RFC2462]を複製を実行するか、送信する前に、MLDリスナーとしての地位を確立するために、無線リンク上の少なくとも1つのMLDメッセージシーケンスを実行しなければならないので、特に良好な例である/受信しますどれか

application-specific traffic (including Mobile IP handover signaling, if any). The node must subscribe to the Solicited Node Multicast Address as soon as it comes up on the link. Any application-specific multicast addresses must be re-established as well. Context transfer can significantly speed up re-establishing multicast state by allowing the nAR to initialize MLD for a node that just completed handover without any MLD signaling on the new wireless link. The same approach could be used for transferring multicast context in IPv4.

(もしあれば、モバイルIPハンドオーバシグナリングを含む)、アプリケーション固有のトラフィック。ノードは、すぐにそれがリンクの上に来るよう要請ノードマルチキャストアドレスに加入しなければなりません。任意のアプリケーション固有のマルチキャストアドレスは、同様に再確立されなければなりません。コンテキスト転送は著しく再確立新ARは、ちょうど任意のMLDは、新しい無線リンク上でシグナリングすることなくハンドオーバを完了ノードについてMLDを初期化することを可能にすることによって、マルチキャスト状態をスピードアップすることができます。同じアプローチは、IPv4マルチキャストコンテキストを転送するために使用することができます。

An approximate quantitative estimate for the amount of savings in handover time can be obtained as follows: MLD messages are 24 octets, to which the headers must be added, because there is no header compression on the new link, where the IPv6 header is 40 octets, and a required Router Alert Hop-by-Hop option is 8 octets including padding. The total MLD message size is 72 octets per subscribed multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report messages per address subscription, since the Report message is unacknowledged. Assuming 2 MLD messages sent for a subscribed address, the MN would need to send 144 octets per address subscription. If MLD messages are sent for both the All Nodes Multicast address and the Solicited Node Multicast address for the node's link local address, a total of 288 octets are required when the node hands over to the new link. Note that some implementations of IPv6 are optimized by not sending an MLD message for the All Nodes Multicast Address, since the router can infer that at least one node is on the link (itself) when it comes up and always will be. However, for purposes of this calculation, we assume that the IPv6 implementation is conformant and that the message is sent. The amount of time required for MLD signaling will depend on the per node available wireless link bandwidth, but some representative numbers can be obtained by assuming bandwidths of 20 kbps or 100 kbps. With these 2 bit rates, the savings from not having to perform the pre-router discovery messages are 115 msec. and 23 msec., respectively. If any application-specific multicast addresses are subscribed, the amount of time saved could be more substantial.

次のようにハンドオーバ時間の節約量のおおよその定量的な推定値を得ることができる:MLDメッセージヘッダーを追加する必要のある24個のオクテットであり、IPv6ヘッダは40オクテットである新しいリンクにはヘッダ圧縮がないため、および必要なルータアラートホップバイホップオプションは、パディングを含む8つのオクテットです。総MLDメッセージのサイズが加入されたマルチキャストアドレスあたり72オクテットです。 RFC 2710は、レポートメッセージが未確認であるため、ノードは、アドレスのサブスクリプションごとに2〜3 MLDレポートメッセージを送信することをお勧めします。購読アドレスに送信された2つのMLDメッセージを想定すると、MNはアドレスサブスクリプションごとに144個のオクテットを送信する必要があります。 MLDメッセージは、すべてのノードマルチキャストアドレスとノードのリンクローカルアドレスの要請ノードマルチキャストアドレスの両方に送信された場合は、288オクテットの合計は、新しいリンクを介して時にノードの手を必要としています。ルータは少なくとも1つのノードは、それがされるまで、常に来るリンク(自体)上にあると推測することができるためのIPv6のいくつかの実装は、すべてのノードマルチキャストアドレスのためのMLDメッセージを送信しないことにより、最適化されていることに注意してください。しかし、この計算の目的のために、我々は、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(ブルートゥース)[BT]です。 PPPと1つずつなし:IEEE 802.15.1は、2つのIP「プロファイル」を持っています。 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ハンドオーバ時間は、典型的には、ホストがアクセスポイントとその周波数ホッピングパターンを再同期する必要があるため、上向き秒以上の実行、その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:

MLDのコンテキスト転送のためのコンテキスト固有のデータフィールドは、単一のIPv6マルチキャストアドレスのCXTPコンテキストデータブロックのメッセージに含まれる次の形式を有します。

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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | +新ARワイヤレスインターフェイスのサブネットプレフィックス+ | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | + + | | +購読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.

新AR無線インターフェースフィールド上のサブネットプレフィックスは、マルチキャストルーティングが確立されなければならないインターフェイスを識別するサブネット・プレフィックスを含んでいます。購読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:

CXTPコンテキストMLDのためのデータブロックを受信すると、ステートマシンは、次のアクションを実行します:

- 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

ラジーブKoodliノキア・リサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA

EMail: rajeev.koodli@nokia.com

メールアドレス:rajeev.koodli@nokia.com

John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland

ジョンLoughneyノキアItdmerenkatu 11-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

マジドF. NakhjiriモトローラLabsの1301東アルゴンキンRdを。、ルーム2240シャンバーグ、イリノイ、60196 USA

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フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA

EMail: charles.perkins@.nokia.com

Eメール:charles.perkins @ .nokia.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2005).

著作権(C)インターネット協会(2005)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。