Internet Engineering Task Force (IETF) G. Tsirtsis
Request for Comments: 6089 Qualcomm
Updates: 5648 H. Soliman
Category: Standards Track Elevate Technologies
ISSN: 2070-1721 N. Montavont
IT/TB
G. Giaretta
Qualcomm
K. Kuladinithi
University of Bremen
January 2011
Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
モバイルIPv6やネットワークモビリティ（NEMO）基本サポートのフローバインディング
Abstract
抽象
This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses.
この文書では、ノードが気付アドレスに1つ以上のフローを結合することを可能モバイルIPv6への拡張を紹介します。これらの拡張機能は、マルチホームノードが特定のアドレスへのインバウンドの流れを指示するためにホームエージェントや他のモバイルIPv6エンティティを指示することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6089.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6089で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 5
4.1. Definition Update for Binding Identifier Mobility
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Flow Identification Mobility Option . . . . . . . . . . . 5
4.2.1. Flow Identification Sub-Options Definition . . . . . . 7
4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 11
4.3. Flow Bindings Entries List and Its Relationship to
Binding Cache . . . . . . . . . . . . . . . . . . . . . . 12
5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Preferred Care-of Address . . . . . . . . . . . . . . 15
5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 15
5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 15
5.2.2. Sending BU with Flow Identification Mobility
Options . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 17
5.2.4. Removing Flow Bindings . . . . . . . . . . . . . . . . 18
5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 19
5.2.7. Return Routability Procedure . . . . . . . . . . . . . 19
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 19
5.3.1. Handling Binding Identifier Mobility Options . . . . . 20
5.3.2. Handling Flow Identification Mobility Options . . . . 20
5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 23
5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 23
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 24
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 24
6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. Security considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and Network Mobility (NEMO) Basic Support [RFC3963] allow a mobile node / mobile router to manage its mobility using the binding update message, which binds one care-of address to one home address and associated mobile networks. The binding update message can be sent to the home agent. In Mobile IPv6, the binding update can also be sent to a correspondent node or to a mobility anchor point (see [RFC5380]). The semantics of the binding update are limited to care-of address changes. That is, [RFC3775], [RFC5555], and [RFC3963] do not allow a mobile node / mobile router to bind more than one address to the home address. In [RFC5648], Mobile IPv6 and NEMO Basic Support are extended to allow the binding of more than one care-of address to a home address. This specification further extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow them to specify policies associated with each binding. A policy can contain a request for special treatment of a particular IPv4 or IPv6 flow, which is viewed as a group of packets matching a traffic selector. Hence, this specification allows a mobile node / mobile router to bind a particular flow to a care-of address without affecting other flows using the same home address. In addition, this specification allows to bind a particular flow to a particular care-of address directly with correspondent node and mobility agents (i.e., home agents [RFC3775] and mobility anchor points [RFC5380]).
モバイルIPv6 [RFC3775]、デュアルスタックMIPv6の（DSMIPv6）[RFC5555]、及びネットワークモビリティ（NEMO）基本サポート[RFC3963]は、移動ノード/モバイルルータ一の気付に結合する結合更新メッセージを使用してモビリティを管理することを可能にします1つのホームアドレスと関連するモバイルネットワークに対応。バインディング更新メッセージは、ホームエージェントに送信することができます。モバイルIPv6では、バインディングアップデートは、（[RFC5380]を参照）通信相手ノードまたはモビリティアンカーポイントに送信することができます。バインディングアップデートの意味は気付するアドレス変更制限されています。すなわち、移動ノード/モバイルルータは、ホームアドレスに複数のアドレスをバインドすることはできません[RFC3775]、[RFC5555]、および[RFC3963]、です。 [RFC5648]で、モバイルIPv6とNEMOベーシックサポートは、複数の気付アドレスホームアドレスへの結合を可能にするように拡張されています。この仕様は、さらにそれらが各結合に関連付けられたポリシーを指定することができるように、モバイルIPv6、DSMIPv6、及びNEMOベーシックサポートを拡張します。ポリシーは、トラフィックセレクタの一致するパケットのグループと見なされる特定のIPv4またはIPv6フローの特殊な治療のための要求を含むことができます。したがって、この仕様は、モバイルノード/モバイルルータは同じホームアドレスを使用して他のフローに影響を与えることなく、気付アドレスへの特定の流れをバインドすることができます。また、本明細書では、通信相手ノード及びモビリティエージェント（すなわち、ホームエージェント[RFC3775]及びモビリティアンカーポイント[RFC5380]）を直接特定の気付アドレスに特定の流れを結合することを可能にします。
In this document, a flow is defined as a set of IP packets matching a traffic selector. A traffic selector can identify the source and destination IP addresses, transport protocol number, the source and destination port numbers and other fields in IP and higher-layer headers. This specification does not define traffic selectors, which are going to be defined in other specifications. This specification, however, does define the traffic selector sub-option format to be used for any specific traffic selector.
この文書では、フローは、トラフィックセレクタと一致するIPパケットの集合として定義されます。トラフィックセレクタは、ソースおよび宛先IPアドレス、トランスポートプロトコル番号、ソース及び宛先ポート番号とIPの他のフィールドと上位層ヘッダを識別することができます。この仕様は、他の仕様で定義されてしようとしているトラフィックセレクタを定義していません。本明細書では、しかし、任意の特定のトラフィックセレクタに使用されるトラフィックセレクタサブオプションのフォーマットを定義し。
Using the flow identifier option introduced in this specification, a mobile node / mobile router can bind one or more flows to a care-of address while maintaining the reception of other flows on another care-of address. The mobile node / mobile router assembles the flow binding requests based on local policies, link characteristics, and the types of applications running at the time. Such policies are outside the scope of this document.
別の気付アドレスに他のフローの受信を維持しながら、本明細書に導入されたフロー識別子オプションを使用して、モバイルノード/モバイルルータの気付アドレスに1つ以上のフローに結合することができます。モバイルノード/モバイルルータはローカルポリシー、リンク特性、および時間に実行しているアプリケーションの種類に基づいて要求を結合流れを組み立てます。このような政策は、この文書の範囲外です。
It should be noted that the flow identification mobility option can be associated with any binding update, whether it is sent to a mobility agent or a correspondent node.
フロー識別モビリティオプションは、それがモビリティエージェント又はコレスポンデントノードへ送信されるかどうか、任意のバインディング更新に関連付けることができることに留意すべきです。
Note that per-packet load balancing may have negative impacts on TCP congestion avoidance mechanisms as it is desirable to maintain order between packets belonging to the same TCP connection. This behavior is specified in [RFC2702]. Other negative impacts are also foreseen for other types of real-time connections due to the potential variations in round-trip time between packets. Moreover, per-packet load-balancing will negatively affect traffic with anti-replay protection mechanisms. Hence, per-packet load balancing is not envisioned in this specification.
同じTCP接続に属するパケットの順序を維持することが望ましいように、そのパケット単位のロードバランシングはTCPの輻輳回避メカニズムにマイナスの影響を与える可能性があります。この動作は、[RFC2702]で指定されています。他の負の影響はまた、パケット間の往復時間の潜在的な変化にリアルタイムの他のタイプの接続のために予見されています。また、パケット単位のロードバランシングは、マイナスのアンチリプレイ保護メカニズムを持つトラフィックに影響を与えます。したがって、パケット単位のロードバランシングはこの仕様で想定されていません。
In the rest of the document, the term "mobile node" is used to designate either a mobile node as defined in [RFC3775] and [RFC5648], or a mobile router as defined in [RFC3963] unless stated otherwise.
特に明記しない限り、文書の残りの部分では、用語「モバイル・ノード」は、[RFC3963]で定義されるように[RFC3775]及び[RFC5648]、又はモバイルルータに定義されているモバイルノードのいずれかを指定するために使用されます。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Terms used in this document are defined in [RFC3753] and [RFC4885]. The following terms are also used in this document:
このドキュメントで使用される用語は、[RFC3753]と[RFC4885]で定義されています。次の用語はまた、このドキュメントで使用されています。
Flow: A flow is a sequence of packets for which the mobile node (MN) desires special handling either by the home agent (HA), the corresponding node (CN) or the mobility anchor point (MAP).
フロー：フローは、モバイルノード（MN）は、ホームエージェント（HA）のいずれかにより、特殊な取り扱いを希望するためのパケットのシーケンスである、対応するノード（CN）またはモビリティアンカーポイント（MAP）。
Traffic Selector: One or more parameters that can be matched against fields in the packet's headers for the purpose of classifying a packet. Examples of such parameters include the source and destination IP addresses, transport protocol number, the source and destination port numbers, and other fields in IP and higher-layer headers.
トラフィックセレクタ：パケットを分類する目的のために、パケットのヘッダ内のフィールドに照合することができる1つ以上のパラメータ。そのようなパラメータの例は、ソースおよび宛先IPアドレス、トランスポートプロトコル番号、ソース及び宛先ポート番号、及びIPの他のフィールドと上位層ヘッダを含みます。
Flow binding: It consists of a traffic selector, and one or more binding identifiers (BIDs). IP packets from one or more flows that match the traffic selector associated with the flow binding are forwarded to the BIDs associated with the same flow binding.
フローは結合：これは、トラフィックセレクタで構成され、1以上の結合識別子（のBID）。流れは結合に関連するトラフィックセレクタに一致する1つ以上のフローからのIPパケットは、結合同じフローに関連のBIDに転送されます。
Flow Identifier: A flow identifier uniquely identifies a flow binding associated with a mobile node. It is generated by a mobile node and is cached in the table of flow binding entries maintained by the MN, HA, CN, or MAP.
フロー識別子：フロー識別子は、一意のモバイルノードに関連付けられているバインディングフローを識別する。これは、モバイルノードによって生成され、MN、HA、CN、またはMAPによって維持フローバインディングエントリのテーブルにキャッシュされています。
This section introduces extensions to Mobile IPv6 that are necessary for supporting the flow binding mechanism described in this document.
このセクションでは、本書で説明したフローの結合機構をサポートするために必要であるモバイルIPv6への拡張を導入します。
This specification updates the definition of the Binding Identifier Mobility option defined in [RFC5648], as follows:
次のようにこの仕様は、[RFC5648]で定義されたバインディング識別子モビリティオプションの定義を更新します。
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| BID-PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 Care-of Address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 1: The Binding Identifier Mobility Option
図1：バインディング識別子モビリティオプション
BID-PRI
BID-IN
This is a 7-bit unsigned integer placing each BID to a relative priority (PRI) with other registered BIDs. Value '0' is reserved and MUST NOT be used. A lower number in this field indicates a higher priority, while BIDs with the same BID-PRI value have equal priority meaning that, the BID used is an implementation issue. This is consistent with current practice in packet classifiers.
これは、他の登録のBIDとの相対的な優先順位（PRI）にそれぞれBIDを確定する7ビットの符号なし整数です。値「0」が予約されており、使用してはいけません。同じBID-PRI値の入札が、使用BIDは、実装の問題であることに等しい優先順位の意味を有するが、この分野でのより低い数値は、より高い優先度を示します。これは、パケット分類における現在の慣行と一致しています。
The flow identification mobility option is a new mobility option [RFC3775], and it is included in the binding update and acknowledgement messages. This option contains information that allows the receiver of a binding update to install policies on a traffic flow and route it to a given care-of address. Multiple options may exist within the same binding update message. The alignment requirement for this option is 2n.
フロー識別モビリティオプションは、新しいモビリティオプション[RFC3775]であり、それは、バインディング更新と受信確認メッセージに含まれています。このオプションは、バインディングアップデートの受信機は与えられた気付アドレスへのトラフィックフローとルートそれをポリシーをインストールすることを可能にする情報が含まれています。複数のオプションは、同じバインディング更新メッセージ内に存在し得ます。このオプションのアライメント要件は2Nです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID-PRI | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Flow Identification Mobility Option
図2：フロー識別モビリティオプション
Option Type
オプションタイプ
45
４５
Option Len
唯一のオプション
Length of the option in octets as per [RFC3775].
[RFC3775]あたりとしてオクテット内のオプションの長さ。
FID
、IN
The Flow Identifier field is a 16-bit unsigned integer that includes the unique identifier for the flow binding. This field is used to refer to an existing flow binding or to create a new flow binding. The value of this field is set by the mobile node. FID = 0 is reserved and MUST NOT be used.
フロー識別子フィールドは、バインディングフローの一意の識別子を含む16ビットの符号なし整数です。このフィールドは、バインディング新しいフローを作成するために結合するか、または既存のフローを参照するために使用されます。このフィールドの値は、モバイルノードによって設定されています。 FID = 0は、予約されており、使用してはいけません。
FID-PRI
PRI、IN
This is a 16-bit unsigned integer priority field to indicate the priority of a particular option. This field is needed in cases where two different flow descriptions in two different options overlap. The priority field decides which policy should be executed in those cases. A lower number in this field indicates a higher priority. Value '0' is reserved and MUST NOT be used. FID-PRI MUST be unique to each of the flows pertaining to a given MN. In other words, two FIDs MUST NOT be associated with the same FID-PRI value.
これは、特定のオプションの優先順位を示すために16ビットの符号なし整数の優先フィールドです。このフィールドは、二つの異なるオプションが2つの異なる流れの説明が重複する場合に必要とされています。優先順位フィールドは、そのような場合に実行されるべき政策を決定します。このフィールドの下位数が高い優先順位を示しています。値「0」が予約されており、使用してはいけません。 FID-PRIは、所与のMNに関連するフローの各々に対して一意でなければなりません。換言すれば、2つのFIDは、同一のFID-PRI値に関連してはいけません。
Status
状態
This 8-bit unsigned integer field indicates the success or failure of the flow binding operation for the particular flow in the option. This field is not relevant to the binding update message as a whole or to other flow identification options. This field is only relevant when included in the Binding Acknowledgement message and must be ignored in the binding update message. The following values are reserved for the Status field within the flow identification mobility option:
この8ビット符号なし整数フィールドは、オプションで、特定のフローのためのフローの結合操作の成功または失敗を示します。このフィールドは、全体として、または他のフロー識別オプションにバインディングアップデートメッセージに関連しません。このフィールドは、Binding Acknowledgementメッセージに含まれたときにのみ関連し、バインディング更新メッセージでは無視されなければなりません。次の値は、フロー識別モビリティオプション内のStatusフィールド用に予約されています。
0 Flow binding successful
0フローは成功結合します
128 Administratively prohibited
管理上禁止さ128
129 Flow binding rejected, reason unspecified
129フローが未指定拒否、理由を結合
130 Flow identification mobility option malformed
不正な130フロー識別モビリティオプション
131 BID not found
131 BIDが見つかりません
132 FID not found
132 FIDが見つかりません
133 Traffic selector format not supported
133トラフィックセレクタ形式がサポートされていません
Sub-options (optional)
サブオプション（オプション）
Zero or more sub-options, defined in Section 4.2.1.
4.2.1項で定義されたゼロ以上のサブオプション。
Flow identification sub-options are encoded within the remaining space of the flow identification mobility option, using a sub-option type-length-value (TLV) format as follows:
次のようにフロー識別サブオプションは、サブオプションタイプ - 長さ - 値（TLV）形式を使用して、フロー識別モビリティオプションの残りの空間内で符号化されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Opt Type |Sub-Opt Length | Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Identification Sub-Option Format
図3：フロー識別サブオプションフォーマット
Sub-Opt Type
サブオプトタイプ
8-bit unsigned integer indicating the sub-option Type. When processing a flow identification mobility option containing an option for which the sub-option Type value is not recognized by the receiver, the receiver MUST silently ignore and skip over the sub-option, correctly handling any remaining sub-options in the same option.
サブオプションタイプを示す8ビットの符号なし整数。サブオプションタイプ値は、受信機によって認識されていないオプションを含むフロー識別モビリティオプションを処理する場合、受信機は静かに無視しなければならないと正確に同じオプションの任意の残りのサブオプションを処理し、サブオプションをスキップ。
Sub-Opt Len
サブオプトレン
8-bit unsigned integer, representing the length in octets of the flow identification sub-option. This field indicates the length of the sub-option not including the Sub-Opt Type and Sub-Opt Length fields. Note that Sub-Opt Type '0' (Section 4.2.1.1) is a special case that does not take a Sub-Opt Length field.
フロー識別サブオプションのオクテットの長さを示す8ビットの符号なし整数。このフィールドは、サブOPTタイプとサブオプト長フィールドを含まないサブオプションの長さを示します。サブOPTタイプ「0」（セクション4.2.1.1）がサブオプトLengthフィールドを取らない特殊なケースであること。なお、
Sub-Option Data
サブオプションデータ
A variable length field that contains data specific to the sub-option.
サブオプションに固有のデータが含まれている可変長フィールド。
The following subsections specify the sub-option Types that are currently defined for use in the flow identification option. Implementations MUST silently ignore any sub-options that they do not understand.
以下のサブセクションでは、現在、フロー識別・オプションで使用するために定義されたサブオプションのタイプを指定します。実装は静かに、彼らは理解していない任意のサブオプションを無視しなければなりません。
These sub-options may have alignment requirements. Following the convention in [RFC3775], regarding mobility options, these sub-options are aligned in a packet so that multi-octet values within the sub-option Data field of each sub-option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8).
これらのサブオプションは、アライメント要件を有することができます。モビリティオプションについては、[RFC3775]のコンベンションに続いて、これらのサブオプションは、パケットに配列されているように、自然な境界（上の各サブオプションの秋のサブオプションのデータフィールド内のマルチオクテット値すなわち、幅n個のフィールドオクテットがヘッダの先頭からnオクテットの整数倍に配置され、用のn = 1、2、4、または8）されています。
The Pad1 sub-option does not have any alignment requirements. Its format is as follows:
パッド1のサブオプションは、任意のアライメント要件はありません。形式は以下の通りです：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Sub-Opt Type |
+-+-+-+-+-+-+-+-+
Sub-Opt Type
サブオプトタイプ
0
０
NOTE: The format of the Pad1 sub-option is a special case -- it has neither sub-option Length nor sub-option Data fields.
注：パッド1のサブオプションの形式は特殊なケースである - それは、サブオプションの長さもサブオプションのデータフィールドもありません。
The Pad1 sub-option is used to insert one octet of padding in the flow identification option. If more than one octet of padding is required, the PadN sub-option, described next, should be used rather than multiple Pad1 sub-options.
パッド1サブオプションは、フロー識別オプションでパディングの1つのオクテットを挿入するために使用されます。パディングの複数のオクテットが必要な場合は、次に説明パッドNサブオプションは、複数のパッド1サブオプションではなく、使用されるべきです。
The PadN sub-option does not have any alignment requirements. Its format is as follows:
パッドNサブオプションは、任意のアライメント要件はありません。形式は以下の通りです：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Sub-Opt Type | Sub-Opt Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Sub-Opt Type
サブオプトタイプ
1
１
Sub-Opt Len
サブオプトレン
Set to the length of the sub-option.
サブオプションの長さに設定してください。
Sub-Opt Data
8つのサブ日
0 or more bytes set to 0 by the sender and ignored by the receiver.
0以上のバイトは、送信者によって0に設定され、受信機によって無視します。
The PadN sub-option is used to insert two or more octets of padding in the flow identification mobility option. For N octets of padding, the sub-option Length field contains the value N, and the sub-option Data field consists of N-2 zero-valued octets. PadN sub-option Data MUST be ignored by the receiver.
パッドNサブオプションは、フロー識別モビリティオプションでパディングの2つの以上のオクテットを挿入するために使用されます。パディングのNオクテットのために、サブオプション長フィールドは値Nを含み、サブオプションのデータフィールドはN-2ゼロ値のオクテットで構成されています。パッドNサブオプションデータは、受信機で無視しなければなりません。
This section introduces the binding reference sub-option, included in the flow identification mobility option. A node MUST NOT include more than one binding reference sub-options in a given flow binding identification option. The binding reference sub-option includes one or more BIDs defined in Multiple Care-of Addresses (MCoA) [RFC5648]. This sub-option associates the flow described in a flow identification mobility option with one or more registered BIDs.
このセクションでは、フロー識別モビリティオプションに含まれる結合基準サブオプションを導入します。ノードは、所定のフローバインディング識別オプションに複数の結合基準サブオプションを含めることはできません。結合基準サブオプションは、複数の気付アドレス（MCoA）で定義された1件のまたは複数の入札[RFC5648]を含みます。このサブオプションは、一つ以上の登録のBIDとフロー識別モビリティオプションで説明したフローを関連付けます。
When binding a flow using this sub-option, the binding identifier mobility option, defined in [RFC5648], MUST be included in either the same or an earlier binding update (BU). The binding reference sub-option is shown below. The alignment requirement for this sub-option is 2n.
このサブオプションを使用してフローをバインドするとき、[RFC5648]で定義された結合識別子モビリティオプションは、同じまたは以前のバインディングアップデート（BU）のいずれかに含まれなければなりません。結合基準サブオプションを以下に示します。このサブオプションのアライメント要件は2Nです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Opt Type | Sub-Opt Len | BID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID ........
+-+-+-+-+-+-+-+-+-+-
Figure 4: The Binding Reference Sub-Option
図4：バインディング基準サブオプション
Sub-Opt Type
サブオプトタイプ
2
２
Sub-Opt Len
サブオプトレン
Variable
変数
BID
入札
A 16-bit unsigned integer indicating the BID that the mobile node wants to associate with the flow identification option. One or more BID fields can be included in this sub-option. Since each BID is 2 bytes long, the value of the Sub-opt Len field indicates the number of BIDs present. Number of BIDs = Sub-Opt Len/2.
モバイルノードは、フロー識別オプションに関連付けることを望むBIDを示す16ビットの符号なし整数。一つまたは複数のBIDフィールドがこのサブオプションに含めることができます。各BIDは2バイト長であるため、サブOPT LENフィールドの値は、本入札の数を示します。入札数=サブオプトレン/ 2。
The traffic selector sub-option includes the parameters used to match packets for a specific flow binding. A node MUST NOT include more than one traffic selector sub-option in a given flow binding identification option.
トラフィックセレクタのサブオプションは、特異的結合のフローのためのパケットを一致させるために使用されるパラメータを含みます。ノードは、所定のフローバインディング識別オプションで複数のトラフィックセレクタサブオプションを含めることはできません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Opt Type | Sub-Opt Len | TS Format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Selector ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Traffic Selector Sub-Option
図5：トラフィックセレクタサブオプション
Sub-Opt Type
サブオプトタイプ
3
３
Sub-Opt Len
サブオプトレン
Variable
変数
TS Format
TSフォーマット
An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and MUST NOT be used.
トラフィックセレクタのフォーマットを示す8ビットの符号なし整数。値「0」が予約されており、使用してはいけません。
Reserved
予約済み
An 8-bit reserved field. It MUST be set to zero by the sender and ignored by the receiver.
8ビットの予約フィールド。これは、送信者によってゼロに設定し、受信機で無視しなければなりません。
Traffic Selector
トラフィックセレクタ
A variable-length field, the format and content of which is out of scope for this specification. The traffic selector defined in [RFC6088] is mandatory to implement.
可変長フィールドは、この明細書の範囲外であるのフォーマットとコンテンツ。 [RFC6088]で定義されたトラフィックセレクタを実装するために必須です。
The flow summary mobility option is a new mobility option [RFC3775], which includes one or more flow identifiers (FIDs) for the purpose of refreshing their state. The alignment requirement for this option is 2n.
流れの概要モビリティオプションは、それらの状態をリフレッシュするために、一つ以上のフロー識別子（のFID）を含む新しいモビリティオプション[RFC3775]、です。このオプションのアライメント要件は2Nです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID ........
+-+-+-+-+-+-+-+-+-+-
Figure 6: The Flow Summary Mobility Option
図6：フローの概要モビリティオプション
Option Type
オプションタイプ
44
４４
Option Length
オプション長
Length of the option in octets as per [RFC3775].
[RFC3775]あたりとしてオクテット内のオプションの長さ。
FID
、IN
A 16-bit unsigned integer indicating a registered FID. One or more FID fields can be included in this option. Number of FIDs = Option Len/2.
登録されたFIDを示す16ビットの符号なし整数。一つ以上のFIDフィールドは、このオプションに含めることができます。 FID =オプションレン/ 2の数。
The conceptual Mobile IPv6 binding cache was defined in [RFC3775] to identify the mobile IP state maintained by the mobile node, mobility agent, and correspondent node. The binding cache includes, among others, the mobile node's home address, the registered care-of address, and the lifetime of the binding. The binding cache has been extended by [RFC5648] to include more than one care-of addresses and to associate each of them with a binding identifier (BID).
概念モバイルIPv6バインディング・キャッシュは、モバイルノード、モビリティエージェント、及び通信相手ノードによって維持されるモバイルIPの状態を識別するために[RFC3775]で定義されました。バインディングキャッシュは、とりわけ、モバイルノードのホームアドレス、登録済みの気付アドレス、および結合の寿命が含まれています。バインディング・キャッシュは、複数の気付アドレスを含むようにし、結合識別子（BID）とそれらの各々を関連付けるために[RFC5648]によって拡張されています。
This specification does not modify the Mobile IPv6 binding cache any further.
この仕様は、更なるモバイルIPv6バインディングキャッシュを変更しません。
Flow bindings can be thought of as a conceptual list of entries that is separate from the binding cache. The flow bindings list contains an entry for each of the registered flow bindings. Flow binding entries point to an entry in the binding cache by means of the BID. Each flow binding entry includes the following parameters:
フローバインディングがバインディングキャッシュから分離されたエントリーの概念リストとして考えることができます。フロー・バインディングのリストが登録されたフロー・バインディングのそれぞれのためのエントリが含まれています。フローバインディングエントリはBIDによるバインディングキャッシュ内のエントリを指します。各フローバインディングエントリは、次のパラメータが含まれています。
o FID (Flow Identifier): For a given mobile node, identified by its primary home address, the FID MUST uniquely identify an entry, i.e., a unique flow binding. Each mobile node can only have a single entry identified by a given FID at any one time. A given FID number space is used for all the addresses associated to a given MN by the HA (e.g., via [RFC3963]). Different mobile nodes use the same FID number space.
O FID（フロー識別子）：プライマリホームアドレスによって識別される所与の移動ノードについては、FIDは、一意のエントリ、すなわち、ユニークなフローは結合を識別しなければなりません。各モバイルノードは、任意の一時点において所与FIDによって識別される単一のエントリを有することができます。与えられたFID番号空間は、HAによって所定のMNに関連するすべてのアドレスのために使用される（[RFC3963]を介して、例えば、）。異なるモバイルノードが同一のFID番号スペースを使用します。
o A Traffic Selector: Included in a traffic selector sub-option.
トラフィックセレクタサブオプションに含まれるもの：交通セレクタO。
o BID(s): The list of BIDs associated with the entry as defined by the binding reference sub-option included in the FID option that created it.
O BID（S）：結合基準サブオプションによって定義されるエントリに関連付けられた入札のリストは、それを作成したFIDオプションに含まれます。
o Active/Inactive flag: This flag indicates whether the entry is active or inactive.
アクティブ/非アクティブフラグ（O）このフラグは、エントリがアクティブか非アクティブかどうかを示します。
o FID-PRI: This field indicates the priority of the flow binding and is used to break the tie between overlapping flow bindings.
FID-PRI O：このフィールドは、バインディングフローの優先度を示し、重複フローバインディング間のタイを壊すために使用されます。
The flow bindings list is associated with a given mobile node, and the correspondent binding cache. An entry in the flow bindings list, however, is identified by the FID and the list is ordered according to the FID-PRI field as defined in the FID option that created each entry.
フロー・バインディングのリストは、所与の移動ノードに関連付けられ、そして対応キャッシュ結合されます。フロー・バインディングのリストのエントリは、しかしながら、FIDによって識別され、リストには、各エントリを作成FIDオプションで定義されているようFID-PRIフィールドに従って順序付けされます。
A valid BID is required to make the entry 'Active'. If all of the BIDs pointed to by a given entry are deregistered [RFC5648], the flow binding entry becomes 'Inactive', in other words it does not affect data traffic. Note that an entry becomes 'Inactive' only if all of the BIDs are deregistered. If only some of the BIDs are still valid, the invalid BIDs are simply ignored.
有効なBIDは、「アクティブ」エントリを作成するために必要とされます。入札の全ては、指定されたエントリで指される場合は、[RFC5648]を登録解除され、エントリを結合流れは、他の言葉で、それはデータトラフィックには影響しませんが、「非アクティブ」になります。エントリは入札のすべてが登録解除されている場合にのみ、「非アクティブ」になることに注意してください。入札の一部だけがまだ有効である場合、不正な入札が単に無視されます。
Also, note that the state described in this section is maintained by the mobile node as well as in mobility agents and correspondent nodes. As such, the mobile node is fully aware of which BIDs are valid at any time and which flow binding entries are active/inactive. Section 5 defines how these flow binding entries are manipulated by the mobile node in detail.
また、このセクションで説明状態は、移動ノードによって、ならびにモビリティエージェントとコレスポンデントノードに維持されることに注意してください。このように、モバイルノードは、入札が任意の時点で有効であるとのバインディングエントリを流れる十分承知しているアクティブ/非アクティブです。セクション5は、これらが詳細にモバイルノードによって操作されるバインディングエントリを流す方法を定義します。
As an example, the following represents an ordered flow binding entry table for a mobile node that has registered multiple care-of addresses and flow bindings.
一例として、以下は、複数の気付アドレス及びフローバインディングを登録している移動ノードのエントリテーブルを結合規則正しい流れを表します。
FID-PRI FID Traffic Selector BIDs A/I
------- --- ---------------- ---- -------
10 4 TCP 2 Active
30 2 srcAddr=IPy 4 Inactive
40 5 UDP 1,3 Active
Ordered Flow Binding Entries
注文の流れバインディングエントリ
According to the above list of flow binding entries, all TCP traffic will match the first entry, and will be forwarded to BID2, corresponding to a given care-of address (IP3), as shown below.
フローバインディングエントリの上記のリストによると、すべてのTCPトラフィックは最初のエントリと一致し、以下に示すように、所定の気付アドレス（IP3）に対応し、BID2に転送されます。
The second entry is marked as 'Inactive' since the BID 4 does not exist in the ordered list of BID entries below. Inactive entries do not affect traffic, i.e., packets are not matched against them.
BID 4は、以下のBIDエントリの順序付きリストに存在しないため、2番目のエントリを「非アクティブ」としてマークされています。非アクティブなエントリはすなわち、パケットがそれらに対して一致しないトラフィックには影響しません。
Any UDP traffic that does not match any of the earlier entries will match the third rule, at which point it will be replicated and forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and IP2 shown below.
以前のエントリのいずれとも一致しないすべてのUDPトラフィックがどのでそれが複製され、気付には下記アドレスIP1とIP2対応する、入札単価1及び3に転送されるポイント、3番目のルールに一致します。
Finally, any remaining packets that do not match any of the entries above will be simply forwarded to the care-of address indicated by the highest order BID in the table below. In the example, such packets will be forwarded to BID1 corresponding to care-of address IP1.
最後に、上記項目のいずれかに一致しない任意の残りのパケットを単純に転送される気付アドレス下表の最上位BIDによって示されます。一例では、そのようなパケットが気付するアドレスIP1対応BID1に転送されます。
BID-PRI BID CoA
--------- --- ---
20 1 IP1
30 3 IP2
30 2 IP3
Ordered BID Entries
注文したBIDエントリ
Mobility agent and corresponding node implementations should take care to avoid flow binding rules affecting the fundamental operation of Mobile IPv6 and its extensions. In particular, flow binding rules MUST NOT apply to Mobile IPv6 signaling generated by mobility agents and corresponding nodes communicating with a given mobile node, since that could adversely affect the operation of the protocol. Other, non-MIPv6 traffic generated by these entities SHOULD be matched against the mobile node's flow binding rules as normal.
モビリティエージェントと対応するノードの実装はモバイルIPv6およびその拡張機能の基本的な動作に影響を与えるルールを結合流れを避けるために注意を払う必要があります。特に、それは不利プロトコルの動作に影響を与える可能性があるので、結合規則は、所与の移動ノードと通信モビリティエージェントと対応ノードによって生成されたシグナリングモバイルIPv6には適用されてはいけません流れます。これらのエンティティによって生成された他、非MIPv6のトラフィックは通常通り、移動ノードの流れ結合ルールに対して一致させる必要があります。
This specification introduces a flow bindings list of entries and an ordered list of flow binding identifiers, allowing mobile nodes to associate flow binding policies with the registered care-of addresses.
この仕様は、モバイルノードが登録さ気付アドレスで流れ結合ポリシーを関連付けることができるように、エントリおよび識別子を結合フローの順序リストのフローバインディングのリストを紹介します。
The flow identification mobility option defines how the mobile node can control a set of flow binding entries maintained in a mobility agent, or correspondent node.
フロー識別モビリティオプションは、モバイルノードがモビリティエージェント、又はコレスポンデントノードに維持フローバインディングエントリのセットを制御することができる方法を定義します。
This specification allows mobile nodes to direct flows to a particular care-of address. The granularity of what constitutes a flow depends on the traffic selector used.
この仕様は、特定の気付アドレスへの直接フローにモバイルノードを可能にします。流れを構成するものの粒度は、使用されるトラフィックセレクタに依存します。
The remainder of this section discusses how mobile nodes can use the options and sub-options defined in this document when sending binding updates to the correspondent node, home agent, or mobility anchor point. In addition, refresh, deletion, and modification of flow binding entries are all discussed below.
このセクションの残りの部分は、モバイルノードがコレスポンデント・ノード、ホーム・エージェント、又はモビリティ・アンカー・ポイントにバインディング更新を送信するとき、この文書で定義されたオプションとサブオプションを使用する方法について説明します。また、リフレッシュ、フローバインディングエントリの削除、および修正はすべて、以下に議論されます。
Any node that supports this specification MUST maintain an ordered list of care-of addresses for each mobile node for which it maintains a list of flow bindings. The ordered list of care-of addresses is built based on the BID-PRI field of the binding identifier mobility option (see Section 4.1).
この仕様をサポートする任意のノードは、それが流れバインディングのリストを維持するために、各モバイルノードに対して気付アドレスの順序付きリストを維持しなければなりません。気付アドレスの順序付きリストは、バインディング識別子モビリティオプションのBID-PRIフィールド（4.1節を参照）に基づいて構築されています。
The ordered list of BIDs is used to determine how to forward a packet to a given mobile node when the packet does not match any of the flow binding entries defined in Section 4.3. A packet that does not match any of the flow binding entries SHOULD be forwarded to the care-of address identified by the BID with the highest priority, i.e., lowest BID-PRI value.
入札の順序付きリストは、パケットは、セクション4.3で定義されたフローバインディングエントリのいずれにも一致しないとき、所与の移動ノードにパケットを転送する方法を決定するために使用されています。フローバインディングエントリのいずれとも一致しないパケットを転送すべき気付の最高優先度、すなわち、最も低いBID-PRI値を有するBIDによって識別されるアドレス。
This specification allows the mobile node to maintain several bindings with its mobility agent and correspondent nodes, and it allows it to direct packets to different care-of addresses according to flow bindings.
この仕様は、モビリティエージェントとコレスポンデントノードといくつかのバインディングを維持するために、モバイルノードができ、そしてそれは、フロー・バインディングに応じて異なる気付アドレスにパケットを指示することを可能にします。
The mobility agent and correspondent node list of flow bindings is manipulated by the mobile node, via flow identification and flow summary mobility options included in binding update messages. Each flow binding update can add, modify, refresh, or delete a given binding. More than one flow identification mobility option MAY be included in the same binding update, but each of them MUST include a different FID. In other words, two flow identification options in the same message cannot be about the same flow binding.
フロー・バインディングのモビリティエージェントとコレスポンデントノードリストが更新メッセージをバインディングに含まれるフロー識別フロー要約モビリティオプションを介して、モバイルノードによって操作されます。それぞれは、追加、変更、更新、または特定の結合を削除することができ、更新を結合流れ。複数のフロー識別モビリティオプションは、同じ結合更新に含まれてもよいが、それらの各々は、異なるFIDを含まなければなりません。換言すれば、同じメッセージ内の2つのフロー識別オプションが結合同じフローについてことができません。
All flow binding state MUST be refreshed in every binding update the mobile node sends. Any previously registered flow binding that is not included in a given binding update will be deleted. So, any flow bindings that are not added or modified by a flow identification mobility option, but have previously registered and need to be maintained, MUST be included in a flow summary mobility option.
すべての流れ結合状態は、モバイルノードが送信するすべてのバインディングアップデートで更新する必要があります。それは、与えられたバインディング更新に含まれていない結合任意予め登録フローが削除されます。追加または変更されたフロー識別モビリティオプションではなく、以前に登録し維持する必要がある、流れの概要モビリティオプションに含まれなければならないていないされているので、任意のフローバインディング。
This specification (see Section 4.1) updates the definition of the binding identifier mobility option, originally defined in [RFC5648]. According to this specification, the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus places them in an ordered list, as also described in Section 4.3.
この仕様は、（セクション4.1を参照）元々[RFC5648]で定義されたバインディング識別子モビリティオプションの定義を更新します。この仕様によると、BIDオプションは、各登録気付アドレス優先順位を割り当てるBID-PRIフィールドを含み、また、4.3節で説明したようにこのように、順序付けられたリストに配置します。
To ensure backwards compatibility with [RFC5648], for the purpose of this specification, the field BID-PRI MUST NOT be set to zero.
本明細書の目的のために、[RFC5648]との下位互換性を確保するために、フィールドBID-PRIをゼロに設定してはいけません。
Receiver implementation of this specification will take a BID-PRI field of value zero as an indication that this is a BID option of the format defined in [RFC5648].
本明細書の受信機の実装は、これは[RFC5648]で定義されたフォーマットのBIDオプションであることを示すように値ゼロのBID-PRIフィールドを取ります。
Mobile nodes supporting this specification MUST use the BID option format defined in Section 4.1. Mobile nodes MUST also register all care-of addresses using the updated BID option format, either in the same BU as any flow identification mobility options using them or in earlier BUs.
この仕様をサポートするモバイルノードはセクション4.1で定義されたBIDオプションの形式を使用しなければなりません。モバイルノードは、また、それらを使用して、任意のフロー識別モビリティオプションと同じBU中またはそれ以前のバス内のいずれかで、すべてのケア - の更新BIDオプションの形式を使用してアドレスを登録する必要があります。
When adding a new flow binding, a mobile node sends the flow identification mobility option in the binding update, with the FID field set to a value that is not already present in the list of flow binding entries maintained by the receiver. The care-of address(es) associated with each flow identification mobility option in the binding update must be logically registered by this binding update, or must have already been registered by the receiver of the binding update in an earlier binding update, as defined in Section 5.2.1.
新しいフローが結合追加するとき、モバイルノードは既に受信機によって維持フローバインディングエントリのリストに存在しない値に設定FIDフィールドと、バインディング更新のフロー識別モビリティオプションを送信します。気付アドレス（ES）バインディング更新中の各フロー識別モビリティオプションに関連付けられているが、論理的に、このバインディング更新によって登録されなければならない、又はで定義されるように既に、以前のバインディングアップデートでバインディング更新の受信機によって登録されていなければなりません5.2.1。
The flow identification mobility option MUST include a unique flow identifier in the FID field. The FID need only be unique for the receiver of the binding update and for the same sender, i.e., the same FID can be used across different receivers of the binding update, for the same sender. The FID-PRI field is set to the desired unique priority of the FID, defining the order of the flow binding to be added in the list of flow binding entries, as defined in Section 4.3. The Status field is set to zero in all binding update messages.
フロー識別モビリティオプションは、FIDフィールドに一意のフロー識別子を含まなければなりません。 FIDは、すなわち、同一のFIDは、同一の送信者のために、バインディング更新の異なる受信機間で使用することができ、バインディング更新の受信機のためと同じ送信者に対して一意でのみ必要。 FID-PRIフィールドは、セクション4.3で定義されるように、フローバインディングエントリのリストに追加される結合フローの順序を定義する、FIDの所望の固有の優先順位に設定されています。 Statusフィールドは、すべてのバインディング更新メッセージにゼロに設定されています。
Since this flow identification mobility option is requesting the addition of a new flow binding in the list of flow bindings maintained by the receiver, the mobile node MUST include exactly one traffic selector sub-option (see Section 4.2.1.4) describing the flow associated with the new flow binding. The TS Format field of the traffic selector sub-option MUST be set to the non-zero value of the format used by the mobile node.
このフロー識別モビリティオプションが受信機によって維持フロー・バインディングのリストに結合する新たなフローの追加を要求しているので、モバイルノードは、関連付けられた流れを説明する（セクション4.2.1.4を参照）、正確に1つのトラフィックセレクタサブオプションを含まなければなりません結合新しい流れ。トラフィックセレクタサブオプションのTSフォーマットフィールドは、モバイルノードによって使用される形式の非ゼロ値に設定しなければなりません。
The mobile node MUST also include exactly one BID reference sub-option (see Section 4.2.1.3) to associate the flow binding with a given set of BIDs and corresponding CoAs.
モバイルノードは、入札単価と対応のCoAの所与のセットとの結合流を関連付ける正確に一つのBID基準サブオプション（セクション4.2.1.3を参照）を含まなければなりません。
Flow binding modification is essentially a process where parameters associated with an existing flow binding in the list of flow binding entries are replaced by parameters included in the flow identification mobility option, and the same FID is maintained. With this procedure, the mobile node can change the priority, the BID(s), and/or the traffic selector associated with a flow binding.
フロー結合修飾は、基本的に流れバインディングエントリのリストに結合既存のフローに関連付けられたパラメータは、フロー識別モビリティオプションに含まれるパラメータによって置換される処理であり、同一のFIDが維持されます。この手順で、移動ノードは、BID（単数または複数）を優先順位を変更することができ、及び/又はトラフィックセレクタは、流れがバインディングに関連付けられています。
To modify an existing flow binding, the mobile node MUST send a binding update with a flow identification option, with the FID field set to one of the FID values already in the list of flow binding entries. The FID-PRI field MUST be set to the priority value for the flow binding entry. The Status field is set to zero since this option is in a binding update.
結合既存のフローを変更するために、モバイルノードが既にフローバインディングエントリのリストにおけるFID値のいずれかにFIDフィールドセットで、フロー識別オプションを使用してバインディング更新を送信しなければなりません。 FID-PRIフィールドは、フローバインディングエントリの優先順位の値に設定しなければなりません。このオプションは、バインディングアップデートであるため、Statusフィールドはゼロに設定されています。
The mobile node MAY include exactly one traffic selector sub-option (see Section 4.2.1.4) describing the updated flow to be associated with the flow binding. The mobile node MAY, however, omit the traffic selector sub-option if it wants the traffic selector currently associated with the flow binding entry identified by the FID field to be maintained.
モバイルノードは、フローは、結合に関連する更新された流れを説明正確に1つのトラフィックセレクタサブオプション（セクション4.2.1.4を参照）を含むことができます。それは現在、FIDフィールドによって識別されたフローバインディングエントリに関連付けられたトラフィックセレクタを維持することを望む場合、移動ノードMAYは、しかし、トラフィックセレクタサブオプションを省略します。
The mobile node MAY include exactly one binding reference sub-option (see Section 4.2.1.3) to associate the existing flow binding with a new set of CoAs. The mobile node MAY omit the binding reference sub-option if it wants the BIDs currently associated with the flow binding entry identified by the FID field to be maintained.
モバイルノードのCoAが一連の新しいとの結合既存のフローを関連付ける正確に一つの結合基準サブオプション（セクション4.2.1.3を参照）を含むことができます。それが現在維持するFIDフィールドによって識別されたフローバインディングエントリに関連付けられているのBIDを望む場合、モバイルノードは、バインディング基準サブオプションを省略することができます。
Note that it is also possible for the mobile node to effectively modify the effect of a flow binding entry without actually changing the entry itself. This can be done by changing the CoA associated with a given BID, which is a process defined in detail in [RFC5648].
モバイルノードが効果的に実際のエントリ自体を変更せずにフローバインディングエントリの効果を変更することも可能であることに留意されたいです。これは、[RFC5648]に詳細に定義されたプロセスであり、所与のBID、関連付けられたCoAを変更することによって行うことができます。
When the mobile node sends a binding update, it MUST refresh all flow bindings it wants to maintain even if it does not want to change any of their parameters.
モバイルノードは、バインディングアップデートを送信するとき、それはそれはそれらのパラメータを変更したくない場合であっても維持したいすべてのフローバインディングをリフレッシュする必要があります。
To refresh an existing flow binding, the mobile node MUST send a binding update with a flow summary option. The flow summary option MUST include one or more FID fields, as indicated in Section 4.2.2. Each FID field included MUST be set to one of the FID values already in the list of flow binding entries. Each flow summary mobility option can identify up to 127 FIDs, so more than one such option can be included in a binding update message as required. A given FID SHOULD NOT be included more than once in all of the flow summary mobility options included in a given binding update message.
結合既存のフローを更新するには、モバイルノードは、フローの要約オプション付きのバインディングアップデートを送らなければなりません。流れの概要オプションは、セクション4.2.2に示すように、一つ以上のFIDフィールドを含まなければなりません。含まれる各FIDフィールドが既にフローバインディングエントリのリストにFID値のいずれかに設定されなければなりません。必要に応じて、複数のそのようなオプションは、バインディング更新メッセージに含めることができるので、各フローの概要モビリティオプションは、127件のFIDまで識別することができます。与えられたFIDは、一度与えられたバインディング更新メッセージに含まれるフローの概要モビリティオプションのすべてにおいてよりも含めるべきではありません。
Any flow bindings (active or inactive) that are not identified in a binding update will be removed from the list of flow binding entries.
バインディングアップデートで同定されていない（アクティブまたは非アクティブ）は、任意のフロー・バインディングは、フローバインディングエントリのリストから削除されます。
Note that any inactive flow bindings, i.e., flow bindings without associated BIDs that are marked as 'Inactive' in the list of flow binding entries (see Section 4.3), MUST also be refreshed, or modified, to be maintained. If they are not included in a BU message, they will be removed.
（4.3節を参照）のエントリを結合フローのリストで「非アクティブ」としてマークされている関連のBIDせず、すなわち、フロー・バインディング、非アクティブフローバインディングことに注意し、また維持するために、更新、又は変更されなければなりません。それらはBUメッセージに含まれていない場合、それらは削除されます。
Removal of flow binding entries is performed implicitly by omission of a given FID from a binding update.
フローバインディングエントリの除去は、バインディング更新からのFIDの省略によって暗黙的に行われます。
To remove a flow binding, the MN simply sends a binding update message that includes flow identification and flow summary mobility options for all the FIDs that need to be refreshed, modified, or added, and simply omits any FIDs that need to be removed.
結合流を除去するために、MNは、単純に、リフレッシュするために必要なすべてのFIDためのフロー識別・フロー要約モビリティオプションを含むバインディングアップデートメッセージを送信し、変更または追加され、簡単に除去する必要がある任意のFIDを省略しています。
Note that a mobile node can also render a flow binding inactive by removing the BIDs associated with it, without removing the flow binding itself. The procedure for removing a BID is defined in detail in [RFC5648].
モバイルノードはまた、それ自体を結合流を除去することなく、それに関連のBIDを除去することによって、非アクティブバインディング流れをレンダリングすることができることに留意されたいです。 BIDを除去するための手順は、[RFC5648]に詳細に定義されています。
When all the BIDs associated with a flow binding are removed, the flow binding MUST be marked as 'Inactive' in the list of flow binding entries, as shown in Section 4.3. In other words, the state associated with the flow binding MUST be maintained, but it no longer affects the mobile node's traffic. The MN can return an inactive flow binding to the active state by using the flow binding modification process, described in Section 5.2.2.2, to associate it again with one or more valid BIDs.
バインディングフローに関連付けられたすべての入札が削除される場合には、セクション4.3に示すように、結合フローは、エントリを結合フローのリストで「非アクティブ」としてマークする必要があります。言い換えれば、流れは、結合に関連した状態が維持されてはならないが、それはもはや、モバイルノードのトラフィックに影響を与えます。 MNは、1つ以上の有効なのBIDと、再びそれを関連付けるために、5.2.2.2項で説明した改質処理を、結合フローを使用してアクティブ状態に結合し、非アクティブフローを返すことができます。
This specification is compatible with the home registration procedures defined in [RFC3775] and [RFC5648]. More specifically, if the mobile node performs a deregistration in the [RFC3775] style, all of its bindings, including flow bindings are deleted. If the mobile node, however, performs a home registration in the [RFC5648] style, then the home link is associated with a specific BID and so, as far as this specification is concerned, it is treated as any other link associated with a given BID.
この仕様は、[RFC3775]及び[RFC5648]で定義されたホーム登録手順と互換性があります。モバイルノードは、[RFC3775]スタイルで登録解除を実行する場合、より具体的には、フロー・バインディングを含むそのバインディングの全てが削除されています。モバイルノードが、しかしながら、[RFC5648]のスタイルでホーム登録を行う場合には、ホーム・リンクは、特定のBIDに関連付けられているので、限り、本明細書に関しては、それが与えられたと関連する任意の他のリンクとして扱われます入札。
According to [RFC3775], all nodes are required to silently ignore mobility options not understood while processing binding updates. As such, a mobile node receiving a Binding Acknowledgement message in response to the transmission of a binding update message MUST determine if the Binding Acknowledgement message contains a copy of every flow identification mobility options included in the binding update. A Binding Acknowledgement without flow identification option(s), in response to a binding update with flow identification mobility option, would indicate the inability (or unwillingness) on behalf of the source node to support the extensions presented in this document.
[RFC3775]によれば、すべてのノードがサイレントバインディング更新の処理中に理解されていないモビリティオプションを無視する必要があります。 Binding Acknowledgementメッセージがバインディングアップデートに含まれるすべてのフロー識別モビリティオプションのコピーが含まれている場合など、バインディングアップデートメッセージの送信に応答して、バインド肯定応答メッセージを受信した移動ノードが決定しなければなりません。フロー識別オプション（複数可）なしで結合確認は、フロー識別モビリティオプションを使用してバインディング更新に応答して、この文書の拡張をサポートするためにソースノードに代わってできないこと（または不本意）を示すであろう。
If a received Binding Acknowledgement contains a copy of each flow identification mobility option that was sent within the binding update, the Status field of each flow identification option indicates the status of the flow binding on the distant node.
受信した結合確認バインディングアップデート内で送信された各フロー識別モビリティオプションのコピーが含まれている場合は、各フロー識別オプションのステータスフィールドは、遠隔ノードに結合フローの状態を示しています。
A mobile node may perform route optimization with correspondent nodes, as defined in [RFC3775]. Route optimization allows a mobile node to bind a care-of address to a home address in order to allow the correspondent node to direct the traffic to the current location of the mobile node. Before sending a binding update to correspondent node, the Return Routability Procedure needs to be performed between the mobile node and the correspondent node. This procedure is not affected by the extensions defined in this document.
モバイルノードは、[RFC3775]で定義されるように、コレスポンデントノードとルート最適化を実行することができます。ルート最適化は、モバイルノードがコレスポンデントノードは、モバイルノードの現在の場所にトラフィックを指示することを可能にするためにホームアドレスに気付アドレスをバインドすることができます。コレスポンデントノードへのバインディングアップデートを送信する前に、リターンルータビリティ手順は、モバイルノードとコレスポンデントノードとの間で行われる必要があります。この手順は、この文書で定義された拡張の影響を受けません。
This specification allows the mobility agents (home agents and mobility anchor points), and correspondent nodes to maintain several flow bindings for a given home address and to direct packets to different care-of addresses according to flow bindings. This section details the home agent operations necessary to implement this specification. These operations are identical for MAPs and CNs, unless otherwise stated.
この仕様は、モビリティエージェント（ホームエージェントとモビリティアンカーポイント）、および通信相手ノード与えられたホームアドレスのためのいくつかのフローバインディングを維持するために、フローバインディングに応じて異なる気付アドレスにパケットを指示することができます。このセクションでは、この仕様を実装するために必要なホームエージェントの操作を詳しく説明します。特に明記しない限り、これらの操作は、地図およびCNSのために同じです。
Note that route optimization is only defined for mobile nodes (MIPv6 [RFC3775]) and not mobile routers (NEMOv6 [RFC3963]). Thus, these sections only apply to correspondent nodes with respect to mobile nodes and not mobile routers.
最適化は唯一のモバイルノード（MIPv6の[RFC3775]）としないモバイルルータ（NEMOv6 [RFC3963]）で定義されたルートに留意されたいです。したがって、これらのセクションは、モバイルノードとしないモバイルルータに対して対応ノードに適用されます。
This specification (see Section 4.1) updates the definition of the binding identifier mobility option, originally defined in [RFC5648]. According to this specification, the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus places them in an ordered list (see Section 4.3).
この仕様は、（セクション4.1を参照）元々[RFC5648]で定義されたバインディング識別子モビリティオプションの定義を更新します。この仕様によると、BIDオプションは、各登録気付アドレス優先順位を割り当てるBID-PRIフィールドを含んでいて、順序付けられたリストに配置します（4.3節を参照してください）。
Home agents receiving BUs including BID options and flow identification options MUST logically process BID options first. This is because BID reference sub-options included in the flow identification mobility options might refer to BIDs defined in BID options included in the same message.
BIDオプションおよびフロー識別オプションを含むバス受信ホームエージェントは、論理的に最初のBIDオプションを処理しなければなりません。 BID基準サブオプションは、モビリティオプションが同じメッセージに含まれるBIDオプションで定義されたのBIDを参照する可能性があるフロー識別に含まれるためです。
The BID option is processed as defined in [RFC5648], but then the BID to care-of address mapping is placed in an ordered list according to the BID-PRI field of the BID option.
BIDオプションのBID-PRIフィールドに応じて、[RFC5648]で定義されるようにBIDオプションが処理され、その後気付のためのBIDアドレスマッピングは、順序付けられたリストに配置されます。
Binding identifier registrations and deregistrations indirectly affect the MN's flow binding entries. The home agent MUST update the flow binding entries table accordingly as BIDs are added or removed (as per [RFC5648]). For example, as discussed in Section 4.3, if all of the BIDs associated with a given flow binding entry are removed (i.e., become invalid) the entry MUST be marked as 'Inactive'. While if any of the invalid BIDs associated with an inactive flow binding entry are registered (i.e., become valid), the entry MUST be marked as 'Active'.
結合識別子の登録と登録解除は間接的にMNの流れバインディングエントリに影響を与えます。ホームエージェントは、入札が追加または削除される応じとしてフローバインディングエントリテーブルを更新しなければならない（あたりとして[RFC5648]）。セクション4.3で議論するように、所与のフローバインディングエントリに関連付けられた入札のすべてが削除された場合、例えば、エントリが「非アクティブ」としてマークされなければならない（即ち、無効になります）。非アクティブなフローバインディングエントリに関連付けられた無効な入札のいずれか（すなわち、有効になる）が登録されている場合が、エントリが「アクティブ」としてマークされなければなりません。
When the home agent receives a binding update that includes at least one flow identification mobility option, it first performs the operation described in section 10.3.1 of RFC 3775, followed by the operations defined in Section 5.3.1 of this document.
ホームエージェントは、少なくとも一つのフロー識別モビリティオプションを含むバインディングアップデートを受信すると、最初にこの文書のセクション5.3.1で定義された動作に続く、RFC 3775のセクション10.3.1に記載の動作を行います。
Home agents that do not support this specification will ignore the flow identification mobility options and all their sub-options, having no effect on the operation of the rest of the protocol.
この仕様をサポートしていないホームエージェントは、プロトコルの残りの部分の動作に影響を与えない、フロー識別モビリティオプションとそのすべてのサブオプションを無視します。
If the binding update is accepted, and the home agent is willing to support flow bindings for this MN, the home agent checks the flow identification mobility options.
バインディング更新が受け入れられ、ホームエージェントは、このMNのフローバインディングをサポートするために喜んでいる場合は、ホームエージェントは、フロー識別モビリティオプションをチェックします。
If more than one flow identification mobility option in the same BU has the same value in the FID field, all the flow identification mobility options MUST be rejected.
同BUで複数のフロー識別モビリティオプションは、FIDフィールドに同じ値を持っている場合は、すべてのフロー識別モビリティオプションは拒絶しなければなりません。
If all FID fields have different values the flow identification mobility options can be processed further and in any order, as defined by the following subsections.
全てFIDフィールドが異なる値を持つ場合、次のサブセクションによって定義されるようなフロー識別モビリティオプションは、さらに任意の順序で処理することができます。
If the FID field of the flow identification mobility option is not already present in the list of flow binding entries for this mobile node, then this is a request for a new entry.
フロー識別モビリティオプションのFIDフィールドがすでにこのモバイルノードのためのフローバインディングエントリのリストに存在しない場合、これは新しいエントリの要求です。
If the flow identification mobility option does not include a traffic selector sub-option, the home agent MUST reject this request by copying the flow identification mobility option in the Binding Acknowledgement (BA) and setting the Status field to the value defined in Figure 2 for "Flow identification option malformed".
フロー識別モビリティオプションは、トラフィックセレクタサブオプションが含まれていない場合、ホームエージェントはバインディング肯定応答（BA）におけるフロー識別モビリティオプションをコピーしについては、図2に定義された値にステータスフィールドを設定することによって、この要求を拒絶しなければなりません「不正な形式の識別オプションをフロー」。
If the flow identification option does include a traffic selector sub-option, but the format indicated in the TS Format field is not supported, the home agent MUST reject this request by copying the flow identification mobility option in the BA, and setting the Status field to the value defined in Figure 2 for "Traffic Selector format not supported".
フロー識別オプションがサポートされていないトラフィックセレクタサブオプションが、TS形式]フィールドに示されているフォーマットが含まれていた場合は、ホームエージェントは、BAにおけるフロー識別モビリティオプションをコピーし、Statusフィールドを設定することによって、この要求を拒絶しなければなりません「サポートされていないトラフィックセレクタの書式」については、図2に定義された値に設定します。
Then, the home agent MUST check the binding reference sub-option.
その後、ホームエージェントはバインディング参照サブオプションをチェックしなければなりません。
If the binding reference sub-option is not included, the home agent MUST reject this request by copying the flow identification mobility option in the BA and setting the Status field to the value defined for "Flow identification mobility option malformed" in Section 4.2.
結合参照サブオプションが含まれていない場合は、ホームエージェントは、BAにおけるフロー識別モビリティオプションをコピーし、4.2節で「不正な形式のフロー識別モビリティオプション」のために定義された値にStatusフィールドを設定することによって、この要求を拒絶しなければなりません。
If the binding reference sub-option is present and includes one or more BIDs that are not present in the binding cache of the mobile node, the home agent MUST reject this request by copying the flow identification option in the BA and setting the Status field to the value defined for "BID not found" in Section 4.2.
結合基準サブオプションが存在し、モバイルノードのバインディング・キャッシュに存在しない一回の又は複数の入札を含む場合、ホームエージェントは、BAにおけるフロー識別オプションをコピーし、Statusフィールドに設定することによって、この要求を拒絶しなければなりません4.2節では、「見つからないBID」に定義された値。
If the binding reference sub-option is present and includes one or more BIDs, and the BIDs exist in the mobile node's binding cache, the home agent SHOULD add a new entry in the mobile node's list of flow binding entries, as defined below.
結合参照サブオプションが存在しているとの1つまたは複数の入札を含み、入札は、モバイルノードのバインディングキャッシュに存在する場合は以下に定義するように、ホームエージェントは、フローバインディングエントリのモバイルノードのリストに新しいエントリを追加する必要があります。
When the home agent decides to add an entry in the mobile node's list of flow binding entries, as discussed above, it MUST do it according to the following rules: the entry MUST be placed according to the order indicated by the FID-PRI field of the flow identification mobility option and it MUST include:
ホームエージェントは、上述したように、フローバインディングエントリのモバイルノードのリストにエントリを追加することを決定するとき、それは次の規則に従って、それに従わなければならない：エントリを配置しなければならないのFID-PRIフィールドによって示される順序に従ってフロー識別モビリティオプションとそれが含まれている必要があります
the FID as a key to the entry,
エントリへの鍵としてFID、
the traffic selector included in the corresponding sub-option,
トラフィックセレクタは、対応するサブオプションに含まれ、
the BIDs indicated in the binding reference sub-option, and
結合基準サブオプションに示されている単価、
the entry MUST be marked as 'Active', as shown in Section 4.3.
4.3節に示すように、エントリは、「アクティブ」としてマークされなければなりません。
If the FID field of the flow identification mobility option is already present in the list of flow binding entries for this mobile node, then this is a request to update the existing entry.
フロー識別モビリティオプションのFIDフィールドは、このモバイルノードのためのフローバインディングエントリのリスト中に既に存在する場合、これは既存のエントリを更新するための要求です。
The flow binding modification is essentially a process where parameters associated with an existing flow binding entry are replaced by the parameters included in a flow identification mobility option with the same FID as the existing entry.
フロー結合修飾は、基本的に既存のフローエントリをバインディングに関連付けられているパラメータは、既存のエントリと同じFIDとフロー識別モビリティオプションに含まれるパラメータによって置換されているプロセスです。
The home agent MUST change the priority of the entry according to the FID-PRI field of the flow identification mobility option.
ホームエージェントは、フロー識別モビリティオプションのFID-PRIフィールドに応じて、エントリの優先順位を変更する必要があります。
Since this flow identification mobility option is designed to update an existing entry, it may or may not include a traffic selector sub-option. Specifically:
このフロー識別モビリティオプションが既存のエントリを更新するように設計されているので、またはトラフィックセレクタサブオプションを含んでも含まなくてもよいです。具体的に：
if a traffic selector sub-option is not included in the flow identification mobility option, then the traffic selector already associated with entry MUST be maintained;
トラフィックセレクタサブオプションはフロー識別モビリティオプションに含まれていない場合、その後、既にエントリに関連付けられたトラフィックセレクタを維持しなければなりません。
otherwise, the traffic selector in the entry MUST be replaced by the traffic selector in the sub-option.
そうでない場合、エントリ内のトラフィックセレクタは、サブオプション内のトラフィックセレクタに置き換えなければなりません。
Since this flow identification mobility option is designed to update an existing entry, it may or may not include a binding reference sub-option. Specifically:
このフロー識別モビリティオプションが既存のエントリを更新するように設計されているので、または結合基準サブオプションを含んでも含まなくてもよいです。具体的に：
if a binding reference sub-option is not included in the flow identification mobility option, then the BIDs already associated with entry MUST be maintained;
結合基準サブオプションは、フロー識別モビリティオプションに含まれていない場合、その後、既にエントリに関連付けられた入札は維持されなければなりません。
otherwise, the BIDs in the entry MUST be replaced by the BIDs in the sub-option.
そうでない場合は、エントリ内の入札は、サブオプションでのBIDに置き換えなければなりません。
When the home agent receives a binding update that includes flow summary mobility options, it first performs the operation described so far in Section 5.3.
ホームエージェントが流れ要約モビリティオプションが含まバインディングアップデートを受信したとき、それは最初のセクション5.3で、これまでに説明した動作を実行します。
If the value of any of the FID fields included in a flow summary mobility option is not present in the list of flow binding entries for this mobile node, the home agent MUST reject this flow binding refresh by including a flow identification mobility option in the BA for each FID that is not found, and by setting the FID field to the value of the FID that is not found and the Status field to the value defined for "FID not found" in Section 4.2.
FIDのフィールドのいずれかの値が流れの概要モビリティオプションに含まれている場合は、このモバイルノードのためのエントリを結合フローのリストに存在しない、ホームエージェントは、BAにおけるフロー識別モビリティオプションを含めることによって、リフレッシュを結合この流れを拒絶しなければなりません見つからなかった各FIDため、および4.2項で「見つかりませんFID」に対して定義された値に見出されないFID及びStatusフィールドの値にFIDフィールドを設定すること。
If the value of the FID field is present in the mobile nodes list of flow binding entries the, home agent SHOULD refresh the flow binding entry identified by the FID without changing any of the other parameters associated with it.
FIDフィールドの値が流れバインディングエントリのモバイルノードリストに存在する場合、ホームエージェントは、それに関連する他のパラメータのいずれかを変更することなく、FIDによって識別されたフローバインディングエントリを更新すべきです。
If a given FID is included more than once in the same or different flow summary mobility options in the same binding update message, the duplicates can be simply ignored.
与えられたFIDは、複数回同じバインディング更新メッセージ内の同じ又は異なる流れ要約モビリティオプションよりも含まれている場合、重複を単に無視することができます。
Note that, an [RFC3775] deregistration binding update (with a zero lifetime) would result in deleting all bindings, including all flow bindings regardless of the presence of flow summary mobility options. A binding update (with a zero lifetime) would result in deleting all bindings, including all flow bindings regardless of the presence of flow summary mobility options. A specific binding deregistration, however, as defined in [RFC5648] (with lifetime of zero and one or more binding identifier mobility options identifying specific BIDs) does not remove all the bindings for the MN, and thus it SHOULD include flow summary mobility options to maintain the flow bindings that need to be preserved.
（ゼロ寿命を有する）[RFC3775]登録解除バインディング更新に関係なく、フロー要約モビリティオプションが存在するすべてのフロー・バインディングを含むすべてのバインディングを削除することになる、ということに注意してください。 （ゼロ寿命の）バインディング更新は、すべてのバインディングを削除するにかかわらず、流れの概要モビリティオプションが存在するすべてのフローのバインディングを含むことになります。登録解除を特異的結合は、しかしながら、[RFC5648]（特定のBIDを識別する0と1以上の結合識別子モビリティオプションの寿命を有する）で定義されているMNのためのすべてのバインディングを削除しないので、それはに流れ要約モビリティオプションを含むべきです保存する必要のあるフローバインディングを維持します。
Removal of flow bindings is performed implicitly by omission of a given FID from a binding update.
フロー・バインディングの除去は、バインディング更新からのFIDの省略によって暗黙的に行われます。
When a valid binding update is received, any registered FIDs that are not explicitly referred to in a flow identification mobility option or in a flow summary mobility option, in the same binding update, MUST be removed from the list of flow binding entries for the mobile node.
有効なバインディング更新を受信した場合、同じ結合更新に明示的フロー識別モビリティオプションまたはフローの概要モビリティオプションで言及されていない任意の登録のFIDは、移動のためのフローバインディングエントリのリストから除去されなければなりませんノード。
Upon the reception of a binding update, the home agent is required to send back a Binding Acknowledgement. The status code in the Binding Acknowledgement must be set as recommended in [RFC3775]. This status code does not give information on the success or failure of flow bindings.
バインディングアップデートを受信すると、ホームエージェントはバインディング確認応答を返送する必要があります。 [RFC3775]に推奨されているように結合確認のステータスコードが設定されなければなりません。このステータスコードは、フローバインディングの成功または失敗についての情報を与えるものではありません。
In order to inform the mobile node about the status of the flow binding(s) requested by a mobile node, flow identification options SHOULD be included in the Binding Acknowledgement message. Specifically, the home agent SHOULD copy each flow identification mobility option received in the binding update and set its status code to an appropriate value. Note that the home agent does not need to respond specifically regarding FIDs included in a flow summary mobility option but only to those in flow identification mobility options. If an operation requested in a flow identification option by a mobile node is performed successfully by the home agent, the Status field on the copied flow identification mobility option in the BA, SHOULD be set to the value defined for "Flow binding successful" in Section 4.2; otherwise, it SHOULD be set to one of the rejection codes also defined in Section 4.2. Section 5.3.2 identifies a number of cases where specific error codes should be used.
モバイルノードによって要求されたバインディング流（複数可）の状態に関するモバイルノードに通知するために、フロー識別オプションがBinding Acknowledgementメッセージに含まれるべきです。具体的には、各フロー識別モビリティオプションをコピーする必要があり、ホームエージェントはバインディングアップデートで受信され、適切な値にそのステータスコードを設定します。流れの概要モビリティオプションにだけフロー識別モビリティオプションのものに含まれるホームエージェントはのFIDについて、具体的に応答する必要はないことに注意してください。モバイルノードによってフロー識別オプションで要求された操作は、ホームエージェントによって正常に実行されている場合は、BAでコピーされたフロー識別モビリティオプションのステータスフィールドは、セクションに「フローが成功した結合」のために定義された値に設定する必要があります4.2。そうでない場合、それはまた、セクション4.2で定義された拒否コードのいずれかに設定されるべきです。セクション5.3.2は、特定のエラーコードが使用されなければならない場合の数を識別する。
Home agents that support this specification MAY refuse to maintain flow bindings by setting the Status field of any flow identification mobility options to the value defined for "Administratively prohibited" in Section 4.2, or by just ignoring all the flow binding options.
この仕様をサポートするホームエージェントは、4.2節で、または単にすべてのフローバインディングのオプションを無視して「管理上禁止」のために定義された値に任意のフロー識別モビリティオプションのStatusフィールドを設定することにより、フローバインディングを維持するために拒否することができます。
Note that BID options and their Status field are handled as defined in [RFC5648]. The BID-PRI field in a BID option included in the Binding Acknowledgement is copied from the BID-PRI field of the corresponding BID option in the binding request.
[RFC5648]で定義されてなお、BIDオプションとそのStatusフィールドが処理されます。 BIDオプションでBID-PRIフィールドは、バインディング要求の対応するBIDオプションのBID-PRIフィールドからコピーされる結合確認に含まれます。
This section defines packet processing rules according to this specification. This specification does not change any of the packet interception rules defined in [RFC3775] and [RFC5555]. These rules apply to HAs, MAPs, and CNs as part of the routing process for any packet with a destination address set to a valid home address of the mobile node. For nodes other than CNs, this also applies to packets with a destination address set to an address under any of the registered prefixes. These rules apply equally to IPv6 packets as well as to IPv4 packets as per [RFC5555].
このセクションでは、この仕様に従ってパケット処理規則を定義します。この仕様は、[RFC3775]及び[RFC5555]で定義されたパケット傍受ルールのいずれかを変更しません。これらのルールは、モバイルノードの有効なホームアドレスに設定された宛先アドレスを持つパケットのルーティングプロセスの一環として、マップ、およびCNSを持っているために適用されます。 CN以外のノードのために、これはまた、登録されたプレフィックスのいずれかにアドレスに設定された宛先アドレスを持つパケットに適用されます。これらのルールは、[RFC5555]に従ってIPv4パケットIPv6パケットに同様に等しく適用されます。
Before a packet is forwarded to the mobile node, it MUST be matched against the ordered list of flow bindings stored in the list of flow binding entries for this mobile node (see Section 4.3). A match is attempted with the traffic selector included in the first line (highest order) of the table. The first entry that creates a match defines how the packet is routed. When a packet matches the traffic selector of a given entry, a copy of the packet is forwarded to each of the care-of addresses associated with the BIDs indicated in the same line of the table.
パケットがモバイルノードに転送される前に、それはこのモバイルノードのためのフローバインディングエントリのリストに保存されているフロー・バインディングの順序付きリストと照合しなければならない（4.3節を参照してください）。一致がテーブルの最初の行（最上位）に含まれるトラフィックセレクタと試みています。試合を作成する最初のエントリは、パケットがルーティングされる方法を定義します。パケットが所与のエントリのトラフィックセレクタと一致した場合、パケットのコピーが気付テーブルの同じ行に示されているのBIDに関連付けられているアドレスの各々に転送されます。
If any of the BIDs indicated does not correspond to a valid care-of address, e.g., the BID was deregistered then, that BID has no effect on the traffic. In other words, packets matching the flow binding are forwarded to the remaining BIDs, pointing to registered care-of addresses. If none of the BIDs pointed to in a flow binding entry is valid, then the entry is considered to be inactive (as defined in Section 4.3) and is skipped. In other words, packets should not be matched against that entry.
入札のいずれか示し、有効な気付アドレスに対応しない場合、例えば、BIDは、次に登録抹消し、そのBIDは、トラフィックに影響を及ぼしません。換言すれば、結合のフローに一致するパケットは、登録の気付アドレスを指し、残りのBIDに転送されます。入札のどれもバインディングエントリが有効である流れの中で指さない場合、エントリは不活性であると考えられている（4.3節で定義されている）と、スキップされます。言い換えれば、パケットは、そのエントリと照合すべきではありません。
If a packet does not match any of the active flow binding entries for the given MN, the packet SHOULD be forwarded to the highest order care-of address, i.e., the one associated with the BID with the lowest BID-PRI.
パケットが所与のMNのエントリを結合するアクティブなフローのいずれにも一致しない場合、パケットは、最上位に転送されるべき気付アドレス、すなわち、最も低いBID-PRIとのBIDに関連する一つ。
If a packet is fragmented, only the first fragment contains all IP and transport layer headers, while subsequent fragments only contain an IP header without transport layer headers. For this reason, it is possible that subsequent fragments do not match the same traffic selector as the initial fragment of such a packet. Unless specific measures are taken, the likely outcome is that the initial fragment is routed as the MN intended while subsequent fragments are routed differently, and probably based on the default flow binding. HAs, MAPs, and CNs SHOULD take care to forward all fragments of a given packet the same way, and in accordance to the flow binding matching the first fragment of said packet. This should be possible given the fact that fragment headers include enough information to identify a fragment as part of a specific packet, but the details of how this is ensured are implementation specific and are not defined in this specification.
パケットが断片化されている場合、後続の断片のみが、トランスポート層ヘッダなしでIPヘッダが含まれているが、最初のフラグメントは、すべてのIPトランスポート層ヘッダを含んでいます。このため、それ以降のフラグメントは、このようなパケットの最初のフラグメントと同じトラフィックセレクタに一致しないことも可能です。具体的な対策が取られない限り、起こりそうな結果は、後続のフラグメントが異なってルーティングされ、おそらくデフォルトのバインディングのフローに基づいている間、MNが意図したように、最初のフラグメントがルーティングされていることです。た、地図、およびCNSは、与えられたパケットのすべてのフラグメントと同じ方法で転送するように世話をする、前記パケットの最初のフラグメントと一致する結合の流れに応じてすべきです。これは、フラグメントヘッダが特定パケットの一部として断片を同定するのに十分な情報を含んでいるという事実所与可能でなければならないが、これは保証される方法の詳細は、実装固有のものであり、本明細書で定義されていません。
The options and sub-options defined in this specification add to those defined in [RFC3775] and other related specifications, all of which potentially add to the size of binding update messages. Implementations SHOULD take care to minimize fragmentation by forming binding updates that are shorter than what the path MTU allows whenever possible.
本明細書で定義されたオプションとサブオプションは、潜在的に更新メッセージをバインディングのサイズに追加全ては[RFC3775]と他の関連する仕様で定義されたもの、に加えます。実装は、パスMTUは、可能な限り可能にするものよりも短いバインディングアップデートを形成することにより、断片化を最小限に抑えるために世話をする必要があります。
This specification offers a number of mechanisms for reducing the size of binding updates. The operations defined in this specification that require the most verbose options are those registering new BIDs, Section 4.1, and identifying new flows, Section 4.2.1.4. Implementations are encouraged to keep binding updates to sizes below that of the path's MTU by making full use of the BID reference sub-option, Section 4.2.1.3, and flow summary option, Section 4.2.2, which allows them to refer to already registered care-of addresses and flow bindings, while registering new ones in subsequent binding update messages.
この仕様は、バインディングアップデートのサイズを低減するための多くの機構を提供しています。最も詳細なオプションを必要とし、この仕様で定義された操作は新しいのBID、セクション4.1を登録し、新しいフローは、セクション4.2.1.4を特定するものがあります。実装が既に登録されているためにそれらを参照することができますsummaryオプション、セクション4.2.2を、BID参照サブオプション、セクション4.2.1.3を駆使して、パスのMTUのそれ以下のサイズにバインディングの更新を維持し、流れるように奨励されています気付アドレスとフローバインディング、その後の結合更新メッセージに新しいものを登録中。
This document introduces a new option that adds more granularity to the binding update and acknowledgement messages defined in [RFC3775], [RFC5555], and [RFC3963], so it inherits the security considerations discussed in these documents. The new option allows the mobile node to associate some flows to one interface and other flows to another interface. Since the flow identification mobility option is part of the mobility header, it uses the same security as the binding update, whether it is sent to a mobility agent or to a correspondent node.
この文書は、新しい[RFC3775]で定義されたバインディング更新と受信確認メッセージに、より粒度を追加するオプション、[RFC5555]、および[RFC3963]を紹介するので、これらの文書で説明したセキュリティの考慮事項を継承します。新しいオプションは、モバイルノードが別のインターフェイスにいくつかのいずれかのインターフェイスにフローおよびその他のフローを関連付けることができます。フロー識別モビリティオプションは、モビリティヘッダの一部であるため、それはモビリティエージェント又はコレスポンデントノードへ送信されるかどうか、バインディング更新と同じセキュリティを使用します。
This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence, it becomes doubly critical that authentication and integrity services are applied to binding updates.
この仕様は、MNとその通信相手ノードとの間の通信に攻撃の新しい基本的なラインアップを開きません。しかし、それはバインディングアップデートのものより細かい粒度の攻撃を可能にします。攻撃者がMNになりすましたりMNによって送られたバインディングアップデートを変更することができる場合たとえば、攻撃者は、攻撃者の選択したアドレスに攻撃者に特別な関心の流れをそらすまたは複製することができます。したがって、認証と整合性サービスがバインディングアップデートに適用されていることを二重に重要になります。
Finally, when the optional anti-replay feature of Encapsulating Security Payload (ESP) [RFC4303] is employed and packets to/from different CoAs are sent on the same security association (SA), some packets could be discarded at the receiver due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic to/from different CoAs, but with the same HoA in the selector values, on different SAs to support Multiple Care-of Addresses appropriately. To permit this, the IPsec implementation SHOULD establish and maintain multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support Multiple Care-of Addresses is locally determined by the sender and is not negotiated by the Internet Key Exchange version 2 (IKEv2) protocol [RFC5996]. The receiver will process the packets from the different SAs without prejudice.
カプセル化セキュリティペイロード（ESP）[RFC4303]のオプションのアンチリプレイ機能が使用され、パケットがする/別のCoAから同じセキュリティアソシエーション（SA）上で送信された場合、最終的に、いくつかのパケットが起因して、受信機で廃棄することができますこの機能で使用されるメカニズムを窓掛け。したがって、送信者は別のCoAからの/へのトラフィックを置くべきであるが、セレクタ値の同一のHoAと、別のSAに適切複数気付アドレスをサポートします。これを可能にするために、IPsec実装は、同じセレクタで、与えられた送信者と受信者との間で複数のSAを確立し、維持する必要があります。複数の気付アドレスをサポートするために、これらの並列SAの間でトラフィックの分布が局部的に送信者によって決定され、インターネットキー交換バージョン2（IKEv2）プロトコル[RFC5996]で交渉されていません。受信機は、偏見なしに異なるのSAからのパケットを処理します。
This specification requires the following IANA assignments on existing namespaces as well as the creation of some new namespaces.
この仕様は、既存の名前空間で次のIANAの割り当てだけでなく、いくつかの新しい名前空間を作成する必要があります。
New Mobility Options [RFC3775]: This registry is available from http://www.iana.org under "Mobile IPv6 parameters". The following type numbers have been assigned for:
新しいモビリティオプション[RFC3775]：このレジストリは、「モバイルIPv6パラメータ」の下でhttp://www.iana.orgから入手可能です。以下のタイプの番号がために割り当てられています：
44 Flow Identification Mobility Option, defined in Section 4.2
セクション4.2で定義された44のフロー識別モビリティオプション、
45 Flow Summary Mobility Option, defined in Section 4.2.2
4.2.2で定義された45のフローの概要モビリティ・オプション、
A new "Flow Identification Mobility Option Status Codes" namespace has been created. The following 'Status' codes are defined in this specification, in Section 4.2:
「フロー識別モビリティオプションのステータス・コード」の新しい名前空間が作成されています。以下の「ステータス」のコードは4.2節で、この仕様で定義されています。
0 Flow binding successful
0フローは成功結合します
1-127 Unassigned. Available for success codes to be allocated via Standards Action or IESG Approval as per [RFC5226].
1-127割り当てられていません。 [RFC5226]あたりとして標準化アクションやIESGの承認を経て割り当てるべき成功のコードのために利用できます。
128 Administratively prohibited
管理上禁止さ128
129 Flow binding rejected, reason unspecified
129フローが未指定拒否、理由を結合
130 Flow identification mobility option malformed
不正な130フロー識別モビリティオプション
131 BID not found
131 BIDが見つかりません
132 FID not found
132 FIDが見つかりません
133 Traffic selector format not supported
133トラフィックセレクタ形式がサポートされていません
134-250 Unassigned. Available for reject codes to be allocated via Standards Action or IESG Approval as per [RFC5226].
134から250まで割り当てられていません。 [RFC5226]に従って標準アクションまたはIESG承認を介して割り当てられるコードを拒否するための利用可能。
251-255 Reserved for experimental use. This small number of status codes should be sufficient for experiments with currently unforeseen error conditions.
251から255は、実験的な使用のために予約します。ステータスコードのこの小さな数は、現在、予期せぬエラー条件での実験のために十分なものでなければなりません。
A new "Flow Identification Sub-Options" namespace for the flow identification mobility option has been created. The sub-option space is defined in Figure 3. The following sub-option Type values are defined in this specification:
フロー識別モビリティ・オプションの新しい「フロー識別サブオプション」名前空間が作成されました。サブオプションの空間は、以下のサブオプションタイプの値は、本明細書で定義されている図3に定義されます。
0 Pad
0パッド
1 PadN
1 PADN
2 BID Reference
2 BIDリファレンス
3 Traffic Selector
3トラフィックセレクタ
4-250 Unassigned. Available for allocation based on Standards Action or IESG Approval as per [RFC5226].
4-250割り当てられていません。 [RFC5226]あたりなどの標準アクションまたはIESG承認に基づいて割り当てに使用できます。
251-255 Reserved for experimental use. This small number of sub-option Types should be sufficient for experiments with additional parameters associated with a flow.
251から255は、実験的な使用のために予約します。サブオプションタイプのこの小さな数は、フローに関連する追加パラメータを用いた実験のために十分なものでなければなりません。
A new "Traffic Selector Format" namespace for the traffic selector sub-option has been created. The traffic selector format space is defined by the TS Format field in Figure 5. The following values are defined in this specification:
トラフィックセレクタサブオプションの新しい「トラフィックセレクタの書式」の名前空間が作成されました。トラフィックセレクタフォーマット空間は、次の値は、本明細書で定義されている図5にTSフォーマットフィールドによって定義されます。
0 Reserved
0予約
1-250 Unassigned. Available for allocation based on Standards Action or IESG Approval as per [RFC5226].
1-250割り当てられていません。 [RFC5226]あたりなどの標準アクションまたはIESG承認に基づいて割り当てに使用できます。
251-255 Reserved for experimental use. This small number of traffic selector format types should be sufficient for experiments with different ways of representing a traffic selector.
251から255は、実験的な使用のために予約します。トラフィックセレクタ・フォーマット・タイプのこの小さな数は、トラフィックセレクタを表現する様々な方法を用いた実験のために十分であるべきです。
Similar to the procedures specified for Mobile IPv6 [RFC3775] number spaces, future allocations from the new number spaces requires Standards Action or IESG Approval as per [RFC5226].
モバイルIPv6 [RFC3775]ナンバースペースに指定された手順と同様にして、新しい番号空間から将来の割り当ては、[RFC5226]に従って標準アクションまたはIESG承認を必要とします。
We would like to explicitly acknowledge the following person who coauthored one of the documents used as source material for this document.
私たちは、明示的に、この文書の原料として使用されるドキュメントの1つを共同執筆し、次の人を承認したいと思います。
Nikolaus A. Fikouras, niko@comnets.uni-bremen.de
ニコラスA. Fikouras、niko@comnets.uni-bremen.de
We would also like to acknowledge the following people in alphabetical order for their contributions to this specification: C. Castelluccia, D. Craig, K. ElMalki, K. Georgios, C. Goerg, C. Kaas-Petersen, J. Laganier, T. Noel, V. Park, F.-N. Pavlidou, P. Stupar. Also, Gabor Fekete for the analysis that led to the inclusion of the BID reference sub-option, and Henrik Levkowetz for suggesting support for other ways of describing flows.
また、この仕様への貢献のためのアルファベット順に次の方々に感謝します：C.カステルッシア、D.クレイグ、K. ElMalki、K.ゲオルギオス、C. Goerg、C.カース・ピーターソン、J. Laganier、T 。ノエル、V.パーク、F.-N. Pavlidou、P. Stupar。また、BIDの基準サブオプションを含めることにつながった分析のためのガボールFekete、およびヘンリックLevkowetz流れを説明する他の方法のためのサポートを示唆しました。
[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月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマン、H.、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648] Wakikawa、R.、Devarapalli、V.、Tsirtsis、G.、エルンスト、T.、およびK.永見、 "複数の気付アドレスの登録"、RFC 5648、2009年10月。
[RFC6088] Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011.
"フローバインディングのためのトラフィックセレクタ" [RFC6088] Tsirtsis、G.、Giaretta、G.、ソリマン、H.、およびN. Montavont、RFC 6088、2011年1月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885]エルンスト、T.およびH-Y。 LACH、 "ネットワークモビリティサポート用語"、RFC 4885、2007年7月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]ソリマン、H.、カステルッシア、C.、ElMalki、K.、およびL. Bellier、 "階層モバイルIPv6（HMIPv6の）モビリティ・マネジメント"、RFC 5380、2008年10月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
Authors' Addresses
著者のアドレス
George Tsirtsis Qualcomm
ジョージTsirtsisクアルコム
EMail: tsirtsis@qualcomm.com
メールアドレス：tsirtsis@qualcomm.com
Hesham Soliman Elevate Technologies
ヒシャムスレイマン・テクノロジーズペスト
EMail: hesham@elevatemobile.com
メールアドレス：hesham@elevatemobile.com
Nicolas Montavont Institut Telecom / Telecom Bretagne 2, rue de la chataigneraie Cesson Sevigne 35576 France
ニコラスMontavont研究所テレコム/テレコムブルターニュ2、RUE・デ・ラ・Chataigneraie 35576セッソンセヴィニエフランス
Phone: (+33) 2 99 12 70 23 EMail: nicolas.montavont@telecom-bretagne.eu URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
電話番号：（+33）2 99 12 70 23 Eメール：nicolas.montavont@telecom-bretagne.eu URI：http://www.rennes.enst-bretagne.fr/~nmontavo//
Gerardo Giaretta Qualcomm
ヘラルドGiarettaクアルコム
EMail: gerardog@qualcomm.com
メールアドレス：gerardog@qualcomm.com
Koojana Kuladinithi University of Bremen ComNets-ikom Otto-Hahn-Allee NW 1 Bremen, Bremen 28359 Germany
ブレーメンのKoojana Kuladinithi大学ComNetsのIKOMオットー・ハーンダレ1 NWブレーメン、ブレーメン28359ドイツ
Phone: +49-421-218-8264 Fax: +49-421-218-3601 EMail: koo@comnets.uni-bremen.de URI: http://www.comnets.uni-bremen.de/~koo/
電話：+ 49-421-218-8264ファックス：+ 49-421-218-3601電子メール：koo@comnets.uni-bremen.de URI：http://www.comnets.uni-bremen.de/~koo/