[要約] RFC 7864は、フローモビリティをサポートするためのProxy Mobile IPv6の拡張に関するものです。このRFCの目的は、モバイルネットワークでのフローモビリティのサポートを向上させることです。
Internet Engineering Task Force (IETF) CJ. Bernardos, Ed.
Request for Comments: 7864 UC3M
Updates: 5213 May 2016
Category: Standards Track
ISSN: 2070-1721
Proxy Mobile IPv6 Extensions to Support Flow Mobility
フローモビリティをサポートするプロキシモバイルIPv6拡張機能
Abstract
概要
Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.
プロキシモバイルIPv6（PMIPv6）を使用すると、モバイルノードは異なるインターフェイスを介して同じPMIPv6ドメインに接続できます。このドキュメントでは、複数の物理インターフェイスでネットワークベースのフローモビリティをサポートするために必要なPMIPv6プロトコルの拡張機能について説明します。
This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.
このドキュメントはRFC 5213を更新します。このドキュメントで説明する拡張機能は、モバイルノードのさまざまなインターフェイスに割り当てられたプレフィックスを管理するためにローカルモビリティアンカーとモバイルアクセスゲートウェイによって実行される操作と、転送ポリシーの処理方法で構成されますネットワークにより、一貫したフローモビリティ管理を保証します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7864.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7864で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the PMIPv6 Flow Mobility Extensions . . . . . . . 4
3.1. Use Case Scenarios . . . . . . . . . . . . . . . . . . . 4
3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. MN Sharing a Common Set of Prefixes on All MAGs . . . 6
3.2.2. MN with Different Sets of Prefixes on Each MAG . . . 9
3.3. Use of PBU/PBA Signaling . . . . . . . . . . . . . . . . 11
3.4. Use of Flow-Level Information . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 13
4.2. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . 13
4.3. Flow Mobility Acknowledgement (FMA) . . . . . . . . . . . 14
5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 14
5.1. Multiple Proxy Care-of Address Registration . . . . . . . 14
5.2. Flow Mobility Cache (FMC) . . . . . . . . . . . . . . . . 15
6. Mobile Node Considerations . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network-based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two new functional entities, the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the entity detecting the Mobile Node's (MN's) attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefixes (HNPs) to the MN and is the topological anchor for all traffic belonging to the MN.
[RFC5213]で指定されているプロキシモバイルIPv6（PMIPv6）は、PMIPv6ドメインに接続するホストにネットワークベースのモビリティ管理を提供します。 PMIPv6では、ローカルモビリティアンカー（LMA）とモバイルアクセスゲートウェイ（MAG）の2つの新しい機能エンティティが導入されています。 MAGは、モバイルノード（MN）の接続を検出し、IP接続を提供するエンティティです。 LMAは、MNに1つ以上のホームネットワークプレフィックス（HNP）を割り当てるエンティティであり、MNに属するすべてのトラフィックのトポロジアンカーです。
PMIPv6 allows an MN to connect to the same PMIPv6 domain through different interfaces. This document specifies protocol extensions to Proxy Mobile IPv6 between the LMA and MAGs to enable "flow mobility" and, hence, distribute specific traffic flows on different physical interfaces. It is assumed that the MN IP-layer interface can simultaneously and/or sequentially attach to multiple MAGs, possibly over multiple media. One form to achieve this multiple attachment is described in [RFC7847], which allows the MN supporting traffic flows on different physical interfaces, regardless of the assigned prefixes on those physical interfaces. Another alternative is to configure the IP stack of the MN to behave according to the Weak ES Model (commonly referred to as the weak host model) [RFC1122].
PMIPv6を使用すると、MNは異なるインターフェイスを介して同じPMIPv6ドメインに接続できます。このドキュメントでは、LMAとMAG間のプロキシモバイルIPv6のプロトコル拡張を指定して、「フローモビリティ」を有効にし、特定のトラフィックフローを異なる物理インターフェイスに分散します。 ＭＮ ＩＰ層インターフェースは、おそらく複数の媒体を介して、複数のＭＡＧに同時におよび／または順次接続することができると想定されている。この複数のアタッチメントを実現する1つの形式は、[RFC7847]で説明されています。これにより、MNは、物理インターフェイスに割り当てられたプレフィックスに関係なく、異なる物理インターフェイス上のトラフィックフローをサポートできます。別の代替案は、弱いESモデル（一般にウィークホストモデルと呼ばれる）[RFC1122]に従って動作するようにMNのIPスタックを構成することです。
In particular, this document specifies how to enable "flow mobility" in the PMIPv6 network (i.e., LMAs and MAGs). In order to do so, two main operations are required: i) proper prefix management by the PMIPv6 network and ii) consistent flow forwarding policies. This memo analyzes different potential use case scenarios, involving different prefix assignment requirements and, therefore, different PMIPv6 network extensions to enable "flow mobility".
特に、このドキュメントでは、PMIPv6ネットワーク（つまり、LMAとMAG）で「フローモビリティ」を有効にする方法を指定します。これを行うには、2つの主要な操作が必要です。i）PMIPv6ネットワークによる適切なプレフィックス管理と、ii）一貫したフロー転送ポリシーです。このメモは、異なるプレフィックス割り当て要件、したがって「フローモビリティ」を有効にするためのさまざまなPMIPv6ネットワーク拡張を含む、さまざまな潜在的なユースケースシナリオを分析します。
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]で説明されているように解釈されます。
The following terms used in this document are defined in the Proxy Mobile IPv6 [RFC5213]:
このドキュメントで使用される次の用語は、Proxy Mobile IPv6 [RFC5213]で定義されています。
o Local Mobility Anchor (LMA)
o ローカルモビリティアンカー（LMA）
o Mobile Access Gateway (MAG)
o モバイルアクセスゲートウェイ（MAG）
o Proxy Mobile IPv6 Domain (PMIPv6-Domain) o LMA Address (LMAA)
oプロキシモバイルIPv6ドメイン（PMIPv6-ドメイン）o LMAアドレス（LMAA）
o Proxy Care-of Address (Proxy-CoA)
o プロキシ気付アドレス（Proxy-CoA）
o Home Network Prefix (HNP)
o ホームネットワークプレフィックス（HNP）
The following terms used in this document are defined in the Multiple Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]:
このドキュメントで使用されている次の用語は、複数気付アドレス登録[RFC5648]およびモバイルIPv6のフローバインディングとネットワークモビリティ（NEMO）基本サポート[RFC6089]で定義されています。
o Binding Identification (BID) Number
o バインディングID（BID）番号
o Flow Identifier (FID)
o フロー識別子（FID）
o Traffic Selector (TS)
o トラフィックセレクター（TS）
The following terms are defined and used in this document:
このドキュメントでは、次の用語が定義および使用されています。
o Flow Mobility Initiate (FMI): Message sent by the LMA to the MAG conveying the information required to enable flow mobility in a PMIPv6-Domain.
o フローモビリティ開始（FMI）：LMAからMAGに送信されたメッセージで、PMIPv6-ドメインでフローモビリティを有効にするために必要な情報を伝達します。
o Flow Mobility Acknowledgement (FMA): Message sent by the MAG in reply to an FMI message.
o Flow Mobility Acknowledgement（FMA）：MAGがFMIメッセージへの応答として送信するメッセージ。
o Flow Mobility Cache (FMC): Conceptual data structure to support the flow mobility management operations described in this document.
o フローモビリティキャッシュ（FMC）：このドキュメントで説明するフローモビリティ管理操作をサポートするための概念的なデータ構造。
In contrast to a typical handover where connectivity to a physical medium is relinquished and then re-established, flow mobility assumes that an MN can have simultaneous access to more than one network. In this specification, it is assumed that the LMA is aware of the MN's ability to have simultaneous access to both access networks and the ability to handle the same or a different set of prefixes on each access. How this is done is outside the scope of this specification.
物理メディアへの接続が放棄されてから再確立される一般的なハンドオーバーとは対照的に、フローモビリティは、MNが複数のネットワークに同時にアクセスできることを前提としています。この仕様では、LMAがMNの両方のアクセスネットワークへの同時アクセス機能と、各アクセスで同じまたは異なる一連のプレフィックスを処理する機能を認識していることを前提としています。これがどのように行われるかは、この仕様の範囲外です。
There are different flow mobility scenarios. In some of them, the MN might share a common set of prefixes among all its physical interfaces; in others, the MN might have a different subset of prefixes configured on each of the physical interfaces. The different scenarios are the following: 1. At the time of a new network attachment, the MN obtains the same prefix or the same set of prefixes as already assigned to an existing session. This is not the default behavior with basic PMIPv6 [RFC5213], and the LMA needs to be able to provide the same assignment even for the simultaneous attachment (as opposed to the handover scenario only).
さまざまなフローモビリティシナリオがあります。それらのいくつかでは、MNはすべての物理インターフェイス間で共通の一連のプレフィックスを共有する場合があります。他の場合では、MNは各物理インターフェイスで設定されたプレフィックスの異なるサブセットを持つ場合があります。異なるシナリオは次のとおりです。1.新しいネットワーク接続時に、MNは既存のセッションに既に割り当てられているものと同じプレフィックスまたは同じプレフィックスのセットを取得します。これは基本的なPMIPv6 [RFC5213]のデフォルトの動作ではなく、LMAは同時接続に対しても同じ割り当てを提供できる必要があります（ハンドオーバーシナリオのみとは対照的に）。
2. At the time of a new network attachment, the MN obtains a new prefix or a new set of prefixes for the new session. This is the default behavior with basic PMIPv6 [RFC5213].
2. 新しいネットワーク接続時に、MNは新しいセッションの新しいプレフィックスまたはプレフィックスの新しいセットを取得します。これは、基本的なPMIPv6 [RFC5213]のデフォルトの動作です。
A combination of the two above-mentioned scenarios is also possible. At the time of a new network attachment, the MN obtains a combination of prefix(es) in use and new prefix(es). This is a hybrid of the two scenarios described before. The local policy determines whether the new prefix is exclusive to the new attachment or can be assigned to an existing attachment as well.
上記の2つのシナリオの組み合わせも可能です。新しいネットワーク接続時に、MNは使用中のプレフィックスと新しいプレフィックスの組み合わせを取得します。これは、前述の2つのシナリオのハイブリッドです。ローカルポリシーは、新しいプレフィックスが新しい添付ファイルに排他的であるか、または既存の添付ファイルにも割り当てることができるかを決定します。
The operational description of how to enable flow mobility in each of these scenarios is provided in Sections 3.2.1 and 3.2.2.
これらの各シナリオでフローモビリティを有効にする方法については、セクション3.2.1および3.2.2で説明しています。
The extensions described in this document support all the aforementioned scenarios.
このドキュメントで説明する拡張機能は、前述のすべてのシナリオをサポートしています。
This section describes how the PMIPv6 extensions described in this document enable flow mobility support.
このセクションでは、このドキュメントで説明するPMIPv6拡張機能がどのようにフローモビリティサポートを有効にするかについて説明します。
Both the MN and the LMA MUST have local policies in place to ensure that packets are forwarded coherently for unidirectional and bidirectional communications. The details about how this consistency is ensured are out of the scope of this document. Either the MN or the LMA can initiate IP flow mobility. If the MN makes the flow mobility decision, then the LMA follows that decision and updates its forwarding state accordingly. The network can also trigger mobility on the MN side via out-of-band mechanisms (e.g., 3GPP / Access Network Discovery and Selection Function (ANDSF) sends updated routing policies to the MN). In a given scenario and MN, the decision on IP flow mobility MUST be taken either by the MN or the LMA, but it MUST NOT be taken by both.
MNとLMAはどちらも、パケットが一方向および双方向通信用にコヒーレントに転送されることを保証するために、適切なローカルポリシーを備えている必要があります。この一貫性がどのように保証されるかについての詳細は、このドキュメントの範囲外です。 MNまたはLMAのいずれかがIPフローモビリティを開始できます。 MNがフローモビリティの決定を行う場合、LMAはその決定に従い、それに応じて転送状態を更新します。ネットワークは、アウトオブバンドメカニズムを介してMN側でモビリティをトリガーすることもできます（たとえば、3GPP / Access Network Discovery and Selection Function（ANDSF）が更新されたルーティングポリシーをMNに送信します）。所定のシナリオとMNでは、IPフローモビリティの決定はMNまたはLMAのいずれかによって行われる必要がありますが、両方で行われることはできません。
This scenario corresponds to the first use case scenario described in Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at the time of a new attachment are needed to ensure that the same prefix (or set of prefixes) is assigned to all the interfaces of the same MN that are simultaneously attached. Subsequently, no further signaling is necessary between the local mobility anchor and the MAG, and flows are forwarded according to policy rules on the LMA and the MN.
このシナリオは、セクション3.1で説明した最初のユースケースシナリオに対応しています。同時に接続される同じMNのすべてのインターフェイスに同じプレフィックス（またはプレフィックスのセット）が確実に割り当てられるようにするには、新しい接続時の基本的なPMIPv6 [RFC5213]シグナリングの拡張が必要です。その後、ローカルモビリティアンカーとMAGの間でそれ以上のシグナリングは必要なく、フローはLMAとMNのポリシールールに従って転送されます。
If the LMA assigns a common prefix (or set of prefixes) to the different physical interfaces attached to the domain, then every MAG already has all the routing knowledge required to forward uplink or downlink packets after the Proxy Binding Update / Proxy Binding Acknowledgement (PBU/PBA) registration for each MAG, and the LMA does not need to send any kind of signaling in order to move flows across the different physical interfaces (because moving flows is a local decision of the LMA). Optionally, signaling MAY be exchanged in case the MAG needs to know about flow-level information (e.g., to link flows with proper QoS paths and/or inform the MN [RFC7222]).
LMAがドメインに接続されたさまざまな物理インターフェースに共通のプレフィックス（またはプレフィックスのセット）を割り当てる場合、すべてのMAGは、プロキシバインディング更新/プロキシバインディング確認（PBU）の後にアップリンクまたはダウンリンクパケットを転送するために必要なすべてのルーティング知識をすでに持っています/ PBA）MAGごとに登録します。LMAは、異なる物理インターフェイス間でフローを移動するために、いかなる種類のシグナリングも送信する必要はありません（フローの移動はLMAのローカルな決定であるため）。オプションで、MAGがフローレベルの情報について知る必要がある場合（たとえば、フローを適切なQoSパスにリンクするため、および/またはMNに通知するために）シグナリングを交換できます[RFC7222]。
The LMA needs to know when to assign the same set of prefixes to all the different physical interfaces of the MN. This can be achieved by different means, such as policy configuration, default policies, etc. In this document, a new Handoff Indicator (HI) ("Attachment over a new interface sharing prefixes" (6) value) is defined that allows the MAG to indicate to the LMA that the same set of prefixes MUST be assigned to the MN. The considerations of Section 5.4.1 of [RFC5213] are updated by this specification as follows:
LMAは、MNのすべての異なる物理インターフェースに同じプレフィックスのセットをいつ割り当てるかを知る必要があります。これは、ポリシー構成、デフォルトポリシーなど、さまざまな方法で実現できます。このドキュメントでは、MAGを許可する新しいハンドオフインジケーター（HI）（「プレフィックスを共有する新しいインターフェイスのアタッチメント」（6）値）が定義されています。同じプレフィックスのセットがMNに割り当てられている必要があることをLMAに示すため。 [RFC5213]のセクション5.4.1の考慮事項は、この仕様によって次のように更新されています。
o If there is at least one Home Network Prefix Option present in the request with a NON_ZERO prefix value, there exists a Binding Cache Entry (BCE) (with all HNPs in the BCE matching the prefix values of all Home Network Prefix Options of the received Proxy Binding Update message), and the entry matches the MN identifier in the Mobile Node Identifier Option of the received Proxy Binding Update message, and the value of the HI of the received Proxy Binding Update is equal to "Attachment over a new interface sharing prefixes".
o NON_ZEROプレフィックス値を持つ要求に少なくとも1つのホームネットワークプレフィックスオプションが存在する場合、バインディングキャッシュエントリ（BCE）が存在します（BCE内のすべてのHNPは、受信したプロキシのすべてのホームネットワークプレフィックスオプションのプレフィックス値と一致します）バインディングアップデートメッセージ）、およびエントリは、受信したプロキシバインディングアップデートメッセージのモバイルノード識別子オプションのMN識別子と一致し、受信したプロキシバインディングアップデートのHIの値は、「プレフィックスを共有する新しいインターフェイス上の添付ファイル」に等しい。
1. If there is a Mobile Node Link-layer Identifier Option present in the request, and the BCE matches the Access Technology Type (ATT) and the MN-LL-Identifier, then the request MUST be considered as a request for updating that BCE.
1. 要求にモバイルノードリンク層識別子オプションが存在し、BCEがアクセステクノロジタイプ（ATT）およびMN-LL-Identifierと一致する場合、要求はそのBCEを更新するための要求と見なさなければなりません（MUST）。
2. If there is a Mobile Node Link-layer Identifier Option present in the request, and the BCE does not match the Access Technology Type (ATT) and the MN-LL-Identifier, then the request MUST be considered as a request for creating a new mobility session sharing the same set of HNPs assigned to the existing BCE found.
2. リクエストにモバイルノードリンク層識別子オプションが存在し、BCEがアクセステクノロジータイプ（ATT）とMN-LL-Identifierに一致しない場合、そのリクエストは新しいリクエストを作成するためのリクエストと見なさなければなりません（MUST）。既存のBCEに割り当てられた同じHNPセットを共有するモビリティセッションが見つかりました。
3. If there is not a Mobile Node Link-layer Identifier Option present in the request, then the request MUST be considered as a request for creating a new mobility session sharing the same set of HNPs assigned to the existing BCE found.
3. 要求にモバイルノードリンク層識別子オプションが存在しない場合、その要求は、見つかった既存のBCEに割り当てられた同じHNPセットを共有する新しいモビリティセッションを作成するための要求と見なさなければなりません（MUST）。
LMA Binding Cache
+---+ ========================
|LMA| MN1, ATT1, pref1, MAG1
+---+ MN1, ATT2, pref1, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
Figure 1: Shared Prefix Across Physical Interfaces Scenario
図1：物理インターフェイス間での共有プレフィックスシナリオ
Next, an example of how flow mobility works in this case is shown. In Figure 1, a mobile node (MN1) has two different physical interfaces (if1 of access technology type ATT1, and if2 of access technology type ATT2). Each physical interface is attached to a different MAG, both of them controlled by the same LMA. Both physical interfaces are assigned the same prefix (pref1) upon attachment to the MAGs. If the IP layer at the MN shows one single logical interface (e.g., as described in [RFC7847]), then the mobile node has one single IPv6 address configured at the IP layer: pref1::mn1. Otherwise, per interface IPv6 addresses (e.g., pref1::if1 and pref1::if2) would be configured; each address MUST be valid on every interface. We assume the first case in the following example (and in the rest of this document). Initially, flow X goes through MAG1 and flow Y through MAG2. At a certain point, flow Y can be moved to also go through MAG1. Figure 2 shows the scenario in which no flow-level information needs to be exchanged, so there is no signaling between the LMA and the MAGs.
次に、この場合のフローモビリティの動作例を示します。図1では、モバイルノード（MN1）に2つの異なる物理インターフェイス（アクセステクノロジータイプATT1のif1とアクセステクノロジータイプATT2のif2）があります。各物理インターフェイスは異なるMAGに接続され、両方とも同じLMAによって制御されます。両方の物理インターフェイスには、MAGへの接続時に同じプレフィックス（pref1）が割り当てられます。 MNのIPレイヤーに単一の論理インターフェイスが示されている場合（[RFC7847]で説明されているように）、モバイルノードにはIPレイヤーで設定された単一のIPv6アドレスpref1 :: mn1があります。そうでない場合は、インターフェースごとにIPv6アドレス（たとえば、pref1 :: if1およびpref1 :: if2）が構成されます。各アドレスは、すべてのインターフェースで有効でなければなりません。次の例（およびこのドキュメントの残りの部分）では、最初のケースを想定しています。最初、フローXはMAG1を通過し、フローYはMAG2を通過します。ある時点で、フローYを移動してMAG1も通過させることができます。図2は、フローレベルの情報を交換する必要がないシナリオを示しています。そのため、LMAとMAGの間のシグナリングはありません。
Note that if different IPv6 addresses are configured at the IP layer, IP-session continuity is still possible (for each of the configured IP addresses). This is achieved by the network delivering packets destined to a particular IP address of the MN to the right of MN's physical interface where the flow is selected to be moved, and the MN also selecting the same interface when sending traffic back uplink.
異なるIPv6アドレスがIPレイヤーで構成されている場合でも、IPセッションの継続性は可能です（構成されたIPアドレスごとに）。これは、フローが移動するように選択されたMNの物理インターフェイスの右側にあるMNの特定のIPアドレス宛てのパケットをネットワークが配信し、MNがトラフィックをアップリンクに戻すときに同じインターフェイスを選択することによって実現されます。
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN1 |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<----------------------------->|<---------->if2
| | | | |
| ============ | | ============
| || flow || | | || flow ||
| || policy || | | || policy ||
| || update || | | || update ||
| ============ | | ============
| | | | |
| flow Y to | flow Y to | flow Y to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<------------->|<-------------------------->if1
| | | | |
Figure 2: Flow Mobility Message Sequence with a Common Set of Prefixes
図2：プレフィックスの共通セットを持つフローモビリティメッセージシーケンス
Figure 3 shows the state of the different network entities after moving flow Y in the previous example. This document reuses some of the terminology and mechanisms of the flow bindings and multiple care-of address registration specifications. Note that, in this case the BIDs shown in the figure are assigned locally by the LMA, since there is no signaling required in this scenario. In any case, alternative implementations of flow routing at the LMA MAY be used, as it does not impact the operation of the solution in this case.
図3は、前の例でフローYを移動した後のさまざまなネットワークエンティティの状態を示しています。このドキュメントでは、フローバインディングのいくつかの用語とメカニズム、および複数の気付アドレス登録仕様を再利用しています。このシナリオではシグナリングが必要ないため、この場合、図に示すBIDはLMAによってローカルに割り当てられることに注意してください。いずれの場合でも、LMAでのフロールーティングの代替実装を使用できます。これは、この場合のソリューションの動作に影響を与えないためです。
LMA Binding Cache LMA flowmob state
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS)
+---+ =========================== ===================
|LMA| 1, MN1, ATT1, pref1, MAG1 1, flow X
+---+ 2, MN1, ATT2, pref1, MAG2 1, flow Y
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | ::/0 LMA
| |
| | MAG2 routing state
| +-------+ | ================================
| | I P | | (dest) (next hop)
| +---+---+ | pref1::/64 p2p-iface-with-MN1
|---|if1|if2|----| ::/0 LMA
+---+---+
MN1
Figure 3: Data Structures with a Common Set of Prefixes
図3：共通のプレフィックスセットを持つデータ構造
A different flow mobility scenario happens when the LMA assigns different sets of prefixes to physical interfaces of the same mobile node. This covers the second case, or a combination of scenarios, described in Section 3.1. In this case, additional signaling is required between the LMA and the MAG to enable relocating flows between the different attachments, so the MAGs are aware of the prefixes for which the MN is going to receive traffic, and local routing entries are configured accordingly.
LMAが同じモバイルノードの物理インターフェイスに異なるプレフィックスのセットを割り当てると、異なるフローモビリティシナリオが発生します。これは、セクション3.1で説明されている2番目のケース、またはシナリオの組み合わせをカバーしています。この場合、異なるアタッチメント間のフローの再配置を可能にするために、LMAとMAGの間に追加のシグナリングが必要です。そのため、MAGは、MNがトラフィックを受信するプレフィックスを認識し、それに応じてローカルルーティングエントリが構成されます。
In this case, signaling is required when a flow is to be moved from its original interface to a new one. Since the LMA cannot send a PBA message that has not been triggered in response to a received PBU message, the solution defined in this specification makes use of two mobility messages: FMI and FMA, which actually use the format of the Update Notifications for PMIPv6 defined in [RFC7077]. The trigger for the flow movement can be on the MN (e.g., by using layer-2 signaling with the MAG), or on the network (e.g., based on congestion and measurements), which then notifies the MN for the final IP flow mobility decision (as stated in Section 3.1). Policy management
この場合、フローを元のインターフェイスから新しいインターフェイスに移動するときに、シグナリングが必要です。 LMAは、受信したPBUメッセージに応答してトリガーされていないPBAメッセージを送信できないため、この仕様で定義されているソリューションは、2つのモビリティメッセージを使用します。FMIとFMAは、定義されたPMIPv6の更新通知の形式を実際に使用します[RFC7077]。フローの移動のトリガーは、MN（たとえば、MAGでレイヤー2シグナリングを使用すること）、またはネットワーク（たとえば、輻輳と測定に基づく）にあり、最終的なIPフローモビリティについてMNに通知します。決定（セクション3.1に記載）。ポリシー管理
functions (e.g., 3GPP/ANDSF) can be used for that purpose; however, how the network notifies the MN is out of the scope of this document.
その目的のために関数（3GPP / ANDSFなど）を使用できます。ただし、ネットワークがMNに通知する方法は、このドキュメントの範囲外です。
If the flow is being moved from its default path (which is determined by the destination prefix) to a different one, the LMA constructs a FMI message. This message includes a Home Network Prefix Option for each of the prefixes that are requested to be provided with flow mobility support on the new MAG (note that these prefixes are not anchored by the target MAG, and therefore the MAG MUST NOT advertise them on the MAG-MN link), with the off-link bit (L) set to one. This message MUST be sent to the new target MAG, i.e., the one selected to be used in the forwarding of the flow. The MAG replies with an FMA. The message sequence is shown in Figure 4.
フローがデフォルトのパス（宛先プレフィックスによって決定される）から別のパスに移動される場合、LMAはFMIメッセージを作成します。このメッセージには、新しいMAGでフローモビリティサポートを提供するように要求された各プレフィックスのホームネットワークプレフィックスオプションが含まれます（これらのプレフィックスはターゲットMAGによってアンカーされていないため、MAGはそれらをアドバタイズしないでください） MAG-MNリンク）。オフリンクビット（L）が1に設定されています。このメッセージは、新しいターゲットMAG、つまりフローの転送で使用するために選択されたMAGに送信する必要があります。 MAGはFMAで応答します。メッセージシーケンスを図4に示します。
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN1 |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::mn1 | pref2::mn1 | pref2::mn1 |
|<----------->|<----------------------------->|<---------->if2
| | | | |
| ============ | | ============
| || flow || | | || flow ||
| || policy || | | || policy ||
| || update || | | || update ||
| ============ | | ============
| | | | |
| | FMI[MN1-ID, HNPs] | |
| |-------------->| | |
| | FMA | | |
| |<--------------| | |
| flow Y to | flow Y to | flow Y to |
| pref2::mn1 | pref2::mn1 | pref2::mn1 |
|<----------->|<------------->|<-------------------------->if1
| | | | |
Figure 4: Flow Mobility Message Sequence When the LMA Assigns Different Sets of Prefixes per Physical Interface
図4：LMAが物理インターフェイスごとに異なるプレフィックスセットを割り当てる場合のフローモビリティメッセージシーケンス
The state in the network after moving a flow, in the case where the LMA assigns a different set of prefixes is shown in Figure 5.
LMAが異なるプレフィックスのセットを割り当てる場合のフロー移動後のネットワークの状態を図5に示します。
LMA Binding Cache LMA flowmob state
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS)
+---+ ============================ ===================
|LMA| 1, MN1, ATT1, pref1, 1, flow X
+---+ pref2, MAG1 1, flow Y
//\\ 2, MN1, ATT2, pref2, MAG2
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | pref2::/64 p2p-iface-with-MN1
| | ::/0 LMA
| |
| +-------+ | MAG2 routing state
| | I P | | ================================
| +---+---+ | (dest) (next hop)
|---|if1|if2|----| pref2::/64 p2p-iface-with-MN1
+---+---+ ::/0 LMA
MN1
Figure 5: Data Structures When the LMA Assigns a Different Set of Prefixes
図5：LMAが異なるプレフィックスのセットを割り当てる場合のデータ構造
This specification introduces the FMI/FMA signaling, which allows the LMA to exchange required information with the MAG to enable flow mobility without waiting to receive a PBU. However, there are scenarios in which the trigger for flow mobility might be related to a new MN's interface attachment. In this case, the PBA sent in response to the PBU received from the new MAG can convey the same signaling that the FMI does. In this case, the LMA MUST include a Home Network Prefix Option in the PBA for each of the prefixes that are requested to be provided with flow mobility support on the new MAG with the off-link bit (L) set to one.
この仕様はFMI / FMAシグナリングを導入しています。これにより、LMAは必要な情報をMAGと交換して、PBUの受信を待たずにフローモビリティを実現できます。ただし、フローモビリティのトリガーが新しいMNのインターフェイスアタッチメントに関連している可能性があるシナリオがあります。この場合、新しいMAGから受信したPBUに応答して送信されるPBAは、FMIが行うのと同じシグナリングを伝達できます。この場合、LMAは、オフリンクビット（L）が1に設定された新しいMAGでフローモビリティサポートを提供するように要求される各プレフィックスのホームネットワークプレフィックスオプションをPBAに含める必要があります。
This specification does not mandate flow-level information to be exchanged between the LMA and the MAG to provide flow mobility support. It only requires that the LMA keeps a flow-level state (Section 5.2). However, there are scenarios in which the MAG might need to know which flow(s) is/are coming within a prefix that has been moved, to link it/them to the proper QoS path(s) and optionally, inform the MN about it. This section describes the extensions used to include flow-level information in the signaling defined between the LMA and the MAG.
この仕様は、フローモビリティサポートを提供するためにLMAとMAGの間で交換されるフローレベルの情報を義務付けていません。 LMAがフローレベルの状態を維持することのみが必要です（セクション5.2）。ただし、MAGは、移動されたプレフィックス内に着信しているフローを認識し、適切なQoSパスにリンクし、オプションでMNに通知する必要があるシナリオがあります。それ。このセクションでは、LMAとMAGの間で定義されたシグナリングにフローレベル情報を含めるために使用される拡張機能について説明します。
This specification reuses some of the mobility extensions and message formats defined in [RFC5648] and [RFC6089], namely the Flow Identification Mobility Option and the Flow Mobility Sub-Options.
この仕様は、[RFC5648]と[RFC6089]で定義されているモビリティ拡張とメッセージ形式の一部、つまり、フロー識別モビリティオプションとフローモビリティサブオプションを再利用しています。
If the LMA wants to convey flow-level information to the MAG, it MUST include in the FMI (or the PBA) a Flow Identification Mobility Option for all the flows that the MAG needs to be aware of with flow granularity. Each Flow Identification Mobility Option MUST include a Traffic Selector Sub-Option including such flow-level information.
LMAがフローレベルの情報をMAGに伝えたい場合は、FMI（またはPBA）に、MAGがフローの粒度で認識する必要があるすべてのフローのフロー識別モビリティオプションを含める必要があります。各フロー識別モビリティオプションには、そのようなフローレベル情報を含むトラフィックセレクタサブオプションを含める必要があります。
To remove a flow-binding state at the MAG, the LMA simply sends an FMI (or a PBA, if it is in response to a PBU) message that includes flow identification options for all the flows that need to be refreshed, modified, or added, and simply omits those that need to be removed.
MAGでフローバインディング状態を削除するには、LMAは、更新、変更、または更新が必要なすべてのフローのフロー識別オプションを含むFMI（またはPBU、PBUへの応答の場合）メッセージを送信するだけです。追加し、単に削除する必要があるものを省略します。
Note that even if a common set of prefixes is used, providing the MAG with flow-level information requires signaling to be exchanged, in this case between the LMA and the MAG. This is done by sending an FMI message (or a PBA, if it is sent in response to a PBU).
プレフィックスの共通セットが使用されている場合でも、MAGにフローレベル情報を提供するには、この場合はLMAとMAGの間でシグナリングを交換する必要があることに注意してください。これは、FMIメッセージ（または、PBUへの応答として送信される場合はPBA）を送信することによって行われます。
This section defines modifications to the PMIPv6 [RFC5213] protocol messages.
このセクションでは、PMIPv6 [RFC5213]プロトコルメッセージへの変更を定義します。
This specification requires implementation of Update Notification (UPN) [RFC7077] and Update Notification Ack (UPA) [RFC7077] messages with the specific Notification Reason and Status Code values as defined by this document. This document does not require implementation of any other aspects of [RFC7077].
この仕様では、このドキュメントで定義されている特定の通知理由とステータスコードの値を含む更新通知（UPN）[RFC7077]および更新通知確認（UPA）[RFC7077]メッセージの実装が必要です。このドキュメントは、[RFC7077]の他の側面の実装を必要としません。
A new flag (L) is included in the Home Network Prefix Option to indicate to the MAG whether the conveyed prefix has to be hosted on-link or not on the point-to-point interface with the MN. A prefix is hosted off-link for the flow mobility purposes defined in this document. The rest of the Home Network Prefix Option format remains the same as defined in [RFC5213].
新しいフラグ（L）がホームネットワークプレフィックスオプションに含まれ、MNとのポイントツーポイントインターフェイスで、伝えられたプレフィックスをリンク上でホストする必要があるかどうかをMAGに示します。このドキュメントで定義されているフローモビリティの目的で、プレフィックスはオフリンクでホストされます。ホームネットワークプレフィックスオプションの残りの形式は、[RFC5213]で定義されているものと同じです。
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 | Length |L| Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Off-link Home Network Prefix Flag (L):
オフリンクホームネットワークプレフィックスフラグ（L）：
The Off-link Home Network Prefix Flag is set to indicate to the MAG that the HNP conveyed in the option is not to be hosted on-link, but has to be considered for flow mobility purposes, and therefore added to the MAG routing table. If the flag is set to 0, the MAG assumes that the HNP has to be hosted on-link.
オフリンクホームネットワークプレフィックスフラグは、オプションで伝達されるHNPがオンリンクでホストされないことをMAGに示すように設定されますが、フローモビリティの目的で考慮する必要があるため、MAGルーティングテーブルに追加されます。フラグが0に設定されている場合、MAGはHNPがリンク上でホストされる必要があると想定します。
The FMI message used in this specification is the UPN message specified in [RFC7077]. The message format, transport, and security considerations are as specified in [RFC7077]. The format of the message is specified in Section 4.1 of [RFC7077]. This specification does not modify the UPN message; however, it defines the following new notification reason value for use in this specification:
この仕様で使用されるFMIメッセージは、[RFC7077]で指定されているUPNメッセージです。メッセージのフォーマット、トランスポート、およびセキュリティに関する考慮事項は、[RFC7077]で指定されています。メッセージの形式は、[RFC7077]のセクション4.1で指定されています。この仕様はUPNメッセージを変更しません。ただし、この仕様で使用する次の新しい通知理由値が定義されています。
Notification Reason:
通知理由：
FLOW-MOBILITY (8). Request to add/refresh the prefix(es) conveyed in the Home Network Prefix Options included in the message to the set of prefixes for which flow mobility is provided.
フローモビリティ（8）。メッセージに含まれるホームネットワークプレフィックスオプションで伝達されるプレフィックスを、フローモビリティが提供されるプレフィックスのセットに追加/更新する要求。
The Mobility Options field of an FMI MUST contain the MN-ID, followed by one or more Home Network Prefix Options. Prefixes for which flow mobility was provided that are not present in the message MUST be removed from the set of flow mobility-enabled prefixes.
FMIのモビリティオプションフィールドには、MN-IDと、それに続く1つ以上のホームネットワークプレフィックスオプションが含まれている必要があります。メッセージに存在しない、フローモビリティが提供されたプレフィックスは、フローモビリティ対応のプレフィックスのセットから削除する必要があります。
The FMA message used in this specification is the UPA message specified in Section 4.2 of [RFC7077]. The message format, transport, and security considerations are as specified in [RFC7077]. The format of the message is specified in Section 4.2 of [RFC7077]. This specification does not modify the UPA message, however, it defines the following new status code values for use in this specification:
この仕様で使用されるFMAメッセージは、[RFC7077]のセクション4.2で指定されたUPAメッセージです。メッセージのフォーマット、トランスポート、およびセキュリティに関する考慮事項は、[RFC7077]で指定されています。メッセージの形式は、[RFC7077]のセクション4.2で指定されています。この仕様はUPAメッセージを変更しませんが、この仕様で使用する次の新しいステータスコード値を定義します。
Status Code:
ステータスコード：
0: Success
0：成功
131: Reason unspecified
131：理由不明
132: MN not attached
132：MNが接続されていません
When the Status code is 0, the Mobility Options field of an FMA MUST contain the MN-ID, followed by one or more Home Network Prefix Options.
ステータスコードが0の場合、FMAのモビリティオプションフィールドにはMN-IDが含まれている必要があり、その後に1つ以上のホームネットワークプレフィックスオプションが続きます。
This section summarizes the extensions to PMIPv6 that are necessary to manage flow mobility.
このセクションでは、フローモビリティを管理するために必要なPMIPv6の拡張機能をまとめています。
The binding cache structure of the LMA is extended to allow multiple proxy care-of address (Proxy-CoA) registrations, and support the mobile node using the same address (prefix) beyond a single interface and MAG. The LMA maintains multiple BCEs for an MN. The number of BCEs for an MN is equal to the number of the MN's interfaces attached to any MAGs.
LMAのバインディングキャッシュ構造が拡張され、複数のプロキシ気付アドレス（Proxy-CoA）登録が可能になり、単一のインターフェースとMAGを超えて同じアドレス（プレフィックス）を使用するモバイルノードをサポートします。 LMAは、MNの複数のBCEを維持します。 MNのBCEの数は、MAGに接続されたMNのインターフェイスの数と同じです。
This specification reuses the extensions defined in [RFC5648] to manage multiple registrations, but in the context of PMIPv6. The binding cache is therefore extended to include more than one proxy care-of address and to associate each of them with a BID. Note that the BID is a local identifier, assigned and used by the local mobility anchor to identify which entry of the FMC is used to decide how to route a given flow.
この仕様は、[RFC5648]で定義されている拡張機能を再利用して、複数の登録を管理しますが、PMIPv6のコンテキストで行います。したがって、バインディングキャッシュが拡張され、複数のプロキシ気付アドレスが含まれ、それぞれにBIDが関連付けられます。 BIDはローカル識別子であり、特定のフローのルーティング方法を決定するために使用されるFMCのエントリを識別するためにローカルモビリティアンカーによって割り当てられ、使用されることに注意してください。
+---------+-----+-------+------+-----------+------------+
| BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA |
+---------+-----+-------+------+-----------+------------+
| 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) |
| 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) |
+---------+-----+-------+------+-----------+------------+
Figure 6: Extended Binding Cache
図6：拡張バインディングキャッシュ
Figure 6 shows an example of an extended binding cache, containing two BCEs of a mobile node MN1 attached to the network using two different access technologies. Both of the attachments share the same prefix (HNP1), but they are bound to two different Proxy-CoAs (two MAGs).
図6は、2つの異なるアクセステクノロジーを使用してネットワークに接続されたモバイルノードMN1の2つのBCEを含む拡張バインディングキャッシュの例を示しています。両方のアタッチメントは同じプレフィックス（HNP1）を共有しますが、それらは2つの異なるProxy-CoA（2つのMAG）にバインドされます。
Each LMA MUST maintain an FMC as shown in Figure 7. The FMC is a conceptual list of entries that is separate from the binding cache. This conceptual list contains an entry for each of the registered flows. This specification reuses the format of the flow-binding list defined in [RFC6089]. Each entry includes the following fields:
各LMAは、図7に示すようにFMCを維持する必要があります。FMCは、バインディングキャッシュとは別の概念的なエントリのリストです。この概念リストには、登録された各フローのエントリが含まれています。この仕様は、[RFC6089]で定義されたフローバインディングリストの形式を再利用します。各エントリには、次のフィールドが含まれています。
o Flow Identifier Priority (FID-PRI)
o フロー識別子の優先度（FID-PRI）
o Flow Identifier (FID)
o フロー識別子（FID）
o Traffic Selector (TS)
o トラフィックセレクター（TS）
o Binding Identification (BID)
o バインディング識別（BID）
o Action
o アクション
o Active/Inactive
o アクティブ/非アクティブ
+---------+-----+-----+------+---------+----------+
| FID-PRI | FID | TS | BIDs | Action | A/I |
+---------+-----+-----+------+---------+----------+
| 10 | 2 | TCP | 1 | Forward | Active |
| 20 | 4 | UDP | 1,2 | Forward | Inactive |
+---------+-----+-----+------+---------+----------+
Figure 7: Flow Mobility Cache
図7：フローモビリティキャッシュ
The BID field contains the identifier of the BCE to which the packets matching the flow information described in the TS field will be forwarded. When it is decided that a flow is to be moved, the affected BID(s) of the table are updated.
BIDフィールドには、TSフィールドに記述されているフロー情報と一致するパケットが転送されるBCEの識別子が含まれます。フローを移動すると決定された場合、影響を受けるテーブルのBIDが更新されます。
Similar to the flow binding described in [RFC6089], each entry of the FMC points to a specific BID. When a flow is moved, the LMA simply updates the pointer of the flow-binding entry with the BID of the interface to which the flow will be moved. The TS in the flow-binding table is defined in [RFC6088]. TS is used to classify the packets of flows based on specific parameters such as service type, source, and destination address, etc. The packets matching with the same TS will be applied the same forwarding policy. FID-PRI is the order of precedence to take action on the traffic. The action may be to forward or drop. If a binding entry becomes "Inactive", it does not affect data traffic. An entry becomes "Inactive" only if all of the BIDs are de-registered.
[RFC6089]で説明されているフローバインディングと同様に、FMCの各エントリは特定のBIDを指します。フローが移動すると、LMAはフローバインディングエントリのポインタを、フローの移動先のインターフェイスのBIDで更新するだけです。フローバインディングテーブルのTSは、[RFC6088]で定義されています。 TSは、サービスタイプ、送信元、宛先アドレスなどの特定のパラメーターに基づいてフローのパケットを分類するために使用されます。同じTSと一致するパケットには、同じ転送ポリシーが適用されます。 FID-PRIは、トラフィックに対してアクションを実行するための優先順位です。アクションは転送またはドロップです。バインディングエントリが「非アクティブ」になっても、データトラフィックには影響しません。エントリは、すべてのBIDが登録解除された場合にのみ「非アクティブ」になります。
The MAG MAY also maintain a similar data structure. In case no full flow mobility state is required at the MAG, the Binding Update List (BUL) data structure is enough: no extra conceptual data entries are needed. If full per-flow state is required at the MAG, it SHOULD also maintain an FMC structure.
MAGも同様のデータ構造を維持できます。 MAGで完全なフローモビリティ状態が必要ない場合、Binding Update List（BUL）データ構造で十分です。追加の概念的なデータエントリは必要ありません。 MAGで完全なフローごとの状態が必要な場合は、FMC構造も維持する必要があります（SHOULD）。
This specification assumes that the mobile node IP-layer interface can simultaneously and/or sequentially attach to multiple MAGs, possibly over multiple media. The MN MUST be able to enforce uplink policies to select the right outgoing interface. One alternative to achieve this multiple attachment is described in [RFC7847], which allows the MN supporting traffic flows on different physical interfaces, regardless of the assigned prefixes on those physical interfaces. Another alternative is configuring the IP stack of the MN to behave according to the weak host model [RFC1122].
この仕様では、モバイルノードのIPレイヤーインターフェイスが、複数のメディアを介して、複数のMAGに同時におよび/または順次接続できることを前提としています。 MNは、適切な発信インターフェイスを選択するために、アップリンクポリシーを適用できる必要があります。この複数のアタッチメントを実現する1つの代替案が[RFC7847]で説明されています。これにより、MNは、物理インターフェイスに割り当てられたプレフィックスに関係なく、異なる物理インターフェイス上のトラフィックフローをサポートできます。別の選択肢は、弱いホストモデル[RFC1122]に従って動作するようにMNのIPスタックを構成することです。
This specification establishes new assignments to the IANA mobility parameters registry:
この仕様は、IANAモビリティパラメータレジストリへの新しい割り当てを確立します。
o Handoff Indicator Option type: "Attachment over a new interface sharing prefixes" has been assigned the value 6 from the "Handoff Indicator Option type values" registry defined in <http://www.iana.org/assignments/mobility-parameters>.
o ハンドオフインジケーターオプションタイプ：「プレフィックスを共有する新しいインターフェイス上の添付ファイル」には、<http://www.iana.org/assignments/mobility-parameters>で定義されている「ハンドオフインジケーターオプションタイプの値」レジストリから値6が割り当てられています。
o Update Notification Reason: "FLOW-MOBILITY" has been assigned the value 8 from the "Update Notification Reasons Registry" defined in <http://www.iana.org/assignments/mobility-parameters>.
o 更新通知理由：「FLOW-MOBILITY」には、<http://www.iana.org/assignments/mobility-parameters>で定義されている「更新通知理由レジストリ」から値8が割り当てられています。
o Update Notification Acknowledgement Status: "Reason unspecified" has been assigned the value 131 and "MN not attached" has been assigned the value 132 from the "Update Notification Acknowledgement Status Registry".
o 更新通知確認ステータス：「理由未指定」には値131が割り当てられ、「MN未接続」には「更新通知確認ステータスレジストリ」から値132が割り当てられています。
The protocol-signaling extensions defined in this document share the same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose any additional security threats to those already identified in [RFC5213] and [RFC7077].
このドキュメントで定義されているプロトコルシグナリング拡張は、Proxy Mobile IPv6 [RFC5213]と同じセキュリティ上の懸念を共有しており、[RFC5213]と[RFC7077]ですでに特定されているセキュリティの脅威をもたらすことはありません。
The MAG and the LMA MUST use the IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this document.
MAGとLMAは、このドキュメントで説明されているシグナリングを保護するために、プロキシモバイルIPv6 [RFC5213]によって義務付けられているIPsecセキュリティメカニズムを使用する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、DOI 10.17487 / RFC5213、August 2008、<http ：//www.rfc-editor.org/info/rfc5213>。
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, DOI 10.17487/RFC5648, October 2009, <http://www.rfc-editor.org/info/rfc5648>.
[RFC5648]脇川R.、Ed。、Devarapalli、V.、Tsirtsis、G.、Ernst、T。、およびK. Nagami、「Multiple Care-of Addresses Registration」、RFC 5648、DOI 10.17487 / RFC5648、2009年10月、<http://www.rfc-editor.org/info/rfc5648>。
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, DOI 10.17487/RFC6088, January 2011, <http://www.rfc-editor.org/info/rfc6088>.
[RFC6088] Tsirtsis、G.、Giarreta、G.、Soliman、H。、およびN. Montavont、「フローバインディングのトラフィックセレクター」、RFC 6088、DOI 10.17487 / RFC6088、2011年1月、<http：//www.rfc -editor.org/info/rfc6088>。
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, DOI 10.17487/RFC6089, January 2011, <http://www.rfc-editor.org/info/rfc6089>.
[RFC6089] Tsirtsis、G.、Soliman、H.、Montavont、N.、Giaretta、G。、およびK. Kuladinithi、「モバイルIPv6およびネットワークモビリティ（NEMO）基本サポートにおけるフローバインディング」、RFC 6089、DOI 10.17487 / RFC6089、2011年1月、<http://www.rfc-editor.org/info/rfc6089>。
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, DOI 10.17487/RFC7077, November 2013, <http://www.rfc-editor.org/info/rfc7077>.
[RFC7077]クリシュナン、S。、ガンダベリ、S。、リープシュ、M。、横田、H.、J。コロネン、「プロキシモバイルIPv6の更新通知」、RFC 7077、DOI 10.17487 / RFC7077、2013年11月、<http ：//www.rfc-editor.org/info/rfc7077>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, <http://www.rfc-editor.org/info/rfc7222>.
[RFC7222] Liebsch、M.、Seite、P.、Yokota、H.、Korhonen、J。、およびS. Gundavelli、「Proxy-of-Service Option for Proxy Mobile IPv6」、RFC 7222、DOI 10.17487 / RFC7222、May 2014、<http://www.rfc-editor.org/info/rfc7222>。
[RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface Support for IP Hosts with Multi-Access Support", RFC 7847, DOI 10.17487/RFC7847, May 2016, <http://www.rfc-editor.org/info/rfc7847>.
[RFC7847]メリア、T。、エド。およびS. Gundavelli編、「マルチアクセスサポートを備えたIPホストの論理インターフェイスサポート」、RFC 7847、DOI 10.17487 / RFC7847、2016年5月、<http://www.rfc-editor.org/info/rfc7847 >。
Acknowledgments
謝辞
The authors would like to thank Vijay Devarapalli, Mohana Dahamayanthi Jeyatharan, Kent Leung, Bruno Mongazon-Cazavet, Chan-Wah Ng, Behcet Sarikaya, and Tran Minh Trung for their valuable contributions, which helped generate this document.
著者は、このドキュメントの作成に貢献してくれた貴重な貢献をしてくれたVijay Devarapalli、Mohana Dahamayanthi Jeyatharan、Kent Leung、Bruno Mongazon-Cazavet、Chan-Wah Ng、Behcet Sarikaya、Tran Minh Trungに感謝します。
The authors would also like to thank Juan-Carlos Zuniga, Pierrick Seite, and Julien Laganier for all the useful discussions on this topic.
著者はまた、このトピックに関する有益な議論を行ってくれたJuan-Carlos Zuniga、Pierrick Seite、およびJulien Laganierにも感謝します。
Finally, the authors would like to thank Marco Liebsch, Juan-Carlos Zuniga, Dirk von Hugo, Fabio Giust, and Daniel Corujo for their reviews of this document.
最後に、このドキュメントのレビューを提供してくれたMarco Liebsch、Juan-Carlos Zuniga、Dirk von Hugo、Fabio Giust、Daniel Corujoに感謝します。
The work of Carlos J. Bernardos has been partially performed in the framework of the H2020-ICT-2014-2 project 5G NORMA.
Carlos J. Bernardosの作業は、H2020-ICT-2014-2プロジェクト5G NORMAのフレームワークで部分的に実行されました。
Contributors
貢献者
This document reflects contributions from the following authors (in alphabetical order).
このドキュメントは、以下の著者からの寄稿を反映しています（アルファベット順）。
Kuntal Chowdhury Email: kc@altiostar.com
Kuntal Chowdhury Eメール：kc@altiostar.com
Sri Gundavelli Email: sgundave@cisco.com
Sri Gundavelliメール：sgundave@cisco.com
Youn-Hee Han Email: yhhan@kut.ac.kr
Youn-Hee Hanメール：yhhan@kut.ac.kr
Yong-Geun Hong Email: yonggeun.hong@gmail.com
Yong-GE UN hongメール：UN。红@ Gmail.comを使用してください
Rajeev Koodli Email: rajeevkoodli@google.com
Rajeev Koodliメール：rajeevkoodly@google.com
Telemaco Melia Email: telemaco.melia@googlemail.com
Telemaco Meliaメール：telemaco.melia@googlemail.com
Frank Xia Email: xiayangsong@huawei.com
フランクX IAメール：夏阳送@ Huawei.com
Author's Address
著者のアドレス
Carlos J. Bernardos (editor) Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
カルロスJ.ベルナルドス（編集者）カルロスIIIデマドリッドAv。ユニバーシダド、30 Leganes、マドリード28911スペイン
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/