Internet Engineering Task Force (IETF) CJ. Bernardos, Ed.
Request for Comments: 7864 UC3M
Updates: 5213 May 2016
Category: Standards Track
ISSN: 2070-1721
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.
这是一份互联网标准跟踪文件。
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/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.
版权所有（c）2016 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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）。MAG是检测移动节点（MN）连接并提供IP连接的实体。LMA是将一个或多个家庭网络前缀（hnp）分配给MN的实体，并且是属于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的协议扩展，以实现“流量移动性”，从而在不同的物理接口上分配特定的流量。假设MN-IP层接口可以同时和/或顺序地连接到多个mag，可能通过多个介质。[RFC7847]中描述了实现这种多重连接的一种形式，它允许MN支持不同物理接口上的流量，而不管这些物理接口上分配的前缀是什么。另一种选择是配置MN的IP堆栈，使其根据弱ES模型（通常称为弱主机模型）[RFC1122]工作。
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）中启用“流量移动性”。为此，需要两个主要操作：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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following terms used in this document are defined in the Proxy Mobile IPv6 [RFC5213]:
本文档中使用的以下术语在代理移动IPv6[RFC5213]中定义：
o Local Mobility Anchor (LMA)
o 本地移动锚（LMA）
o Mobile Access Gateway (MAG)
o 移动接入网关（MAG）
o Proxy Mobile IPv6 Domain (PMIPv6-Domain)
o 代理移动IPv6域（PMIPv6域）
o LMA Address (LMAA)
o LMA地址（LMAA）
o Proxy Care-of Address (Proxy-CoA)
o 代理转交地址（代理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]:
本文档中使用的以下术语在移动IPv6和网络移动（NEMO）基本支持[RFC6089]中的多个转交地址注册[RFC5648]和流绑定中定义：
o Binding Identification (BID) Number
o 具有约束力的标识（投标）编号
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 流量移动确认（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:
存在不同的流移动场景。在某些情况下，MN可能在其所有物理接口之间共享一组公共前缀；在其他情况下，MN可能在每个物理接口上配置了不同的前缀子集。不同的场景如下所示：
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).
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.
上述两种情况的组合也是可能的。在新网络连接时，MN获得正在使用的前缀和新前缀的组合。这是前面描述的两种场景的混合。本地策略确定新前缀是新附件的专用前缀，还是也可以分配给现有附件。
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遵循该决策并相应地更新其转发状态。网络还可以通过带外机制（例如，3GPP/接入网络发现和选择功能（ANDSF）向MN发送更新的路由策略）触发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节中描述的第一个用例场景。需要在新连接时扩展基本PMIPv6[RFC5213]信令，以确保将相同的前缀（或前缀集）分配给同时连接的同一MN的所有接口。随后，本地移动性锚和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已经具有在针对每个MAG的代理绑定更新/代理绑定确认（PBU/PBA）注册之后转发上行链路或下行链路分组所需的所有路由知识，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的所有不同物理接口。这可以通过不同的方式实现，例如策略配置、默认策略等。在本文档中，定义了一个新的切换指示符（HI）（“新接口上的附件共享前缀”（6）值），该值允许MAG向LMA指示必须将同一组前缀分配给MN。本规范更新了[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 如果请求中至少有一个家庭网络前缀选项具有非零前缀值，则存在绑定缓存项（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标识符，则该请求必须被视为更新该BCE的请求。
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标识符不匹配，则该请求必须被视为创建新的移动会话的请求，该移动会话共享分配给现有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。
LMA Binding Cache
+---+ ========================
|LMA| MN1, ATT1, pref1, MAG1
+---+ MN1, ATT2, pref1, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
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
接下来，展示了流移动性在这种情况下如何工作的示例。在图1中，移动节点（MN1）具有两个不同的物理接口（接入技术类型ATT1的if1和接入技术类型ATT2的if2）。每个物理接口都连接到不同的MAG，它们都由相同的LMA控制。两个物理接口在连接到MAG时分配相同的前缀（pref1）。如果MN处的IP层显示一个逻辑接口（如[RFC7847]中所述），则移动节点在IP层配置了一个IPv6地址：pref1:：mn1。否则，将配置每个接口的IPv6地址（例如，pref1:：if1和pref1:：if2）；每个地址在每个接口上都必须有效。我们在下面假设第一种情况
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.
示例（以及本文档的其余部分）。最初，流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.
请注意，如果在IP层配置了不同的IPv6地址，IP会话连续性仍然是可能的（对于每个配置的IP地址）。这是通过网络将目的地为MN的特定IP地址的分组传送到MN的物理接口的右侧来实现的，其中选择移动流，并且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
| | | | |
+-----+ +------+ +------+ +-----+
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后不同网络实体的状态。本文档重用了流绑定和多个转交地址注册规范的一些术语和机制。注意，在这种情况下，图中所示的投标由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
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节中描述的场景组合。在这种情况下，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无法发送未被触发的PBA消息来响应接收到的PBU消息，因此本规范中定义的解决方案使用了两条移动消息：FMI和FMA，它们实际上使用了[RFC7077]中定义的PMIPv6更新通知格式。流移动的触发器可以在MN上（例如，通过使用MAG的第2层信令），或者在网络上（例如，基于拥塞和测量），然后通知MN进行最终IP流移动决策（如第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。杂志以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
| | | | |
+-----+ +------+ +------+ +-----+
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
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必须在PBA中针对请求在新MAG上提供流移动性支持的每个前缀包括家庭网络前缀选项，其中断开链路比特（L）设置为1。
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（或PBA，如果是响应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消息（或PBA，如果是响应PBU发送的）。
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），以向MAG指示所传送的前缀是否必须承载在链路上或不承载在与MN的点到点接口上。出于本文档中定义的流量移动性目的，在链路外托管前缀。家庭网络前缀选项格式的其余部分与[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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
断开链路归属网络前缀标志被设置为向MAG指示在选项中传送的HNP不在链路上承载，而是必须考虑用于流移动性目的，并且因此被添加到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，后跟一个或多个家庭网络前缀选项。必须从启用流移动性的前缀集中删除消息中不存在的为其提供流移动性的前缀。
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，后跟一个或多个家庭网络前缀选项。
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) |
+---------+-----+-------+------+-----------+------------+
+---------+-----+-------+------+-----------+------------+
| 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显示了扩展绑定缓存的示例，其中包含使用两种不同访问技术连接到网络的移动节点MN1的两个BCE。两个附件共享相同的前缀（HNP1），但它们绑定到两个不同的代理COA（两个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必须维护一个FMC，如图7所示。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 具有约束力的标识（投标）
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 |
+---------+-----+-----+------+---------+----------+
+---------+-----+-----+------+---------+----------+
| 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字段包含BCE的标识符，与TS字段中描述的流信息匹配的数据包将被转发到BCE。当决定移动流时，表中受影响的投标将被更新。
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的每个条目都指向一个特定的投标。当一个流被移动时，LMA简单地用流将被移动到的接口的BID更新流绑定条目的指针。流绑定表中的TS在[RFC6088]中定义。TS用于根据特定参数（如服务类型、源和目标地址等）对流的数据包进行分类。与相同TS匹配的数据包将应用相同的转发策略。FID-PRI是对流量采取行动的优先顺序。动作可能是向前或向下。如果绑定条目变为“非活动”，则不会影响数据流量。只有在所有投标都取消注册的情况下，条目才会变为“非活动”。
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不需要全流移动状态，绑定更新列表（BUL）数据结构就足够了：不需要额外的概念数据条目。如果MAG需要全流量状态，还应保持FMC结构。
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必须能够实施上行策略以选择正确的传出接口。[RFC7847]中描述了实现这种多重连接的一种备选方案，它允许MN支持不同物理接口上的流量，而不管这些物理接口上分配的前缀如何。另一种选择是配置MN的IP堆栈，使其按照弱主机模型[RFC1122]运行。
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 切换指示器选项类型：“新接口上的附件共享前缀”已从中定义的“切换指示器选项类型值”注册表中分配了值6<http://www.iana.org/assignments/mobility-parameters>.
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”已从中定义的“更新通知原因注册表”中分配了值8<http://www.iana.org/assignments/mobility-parameters>.
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].
本文档中定义的协议信令扩展与代理移动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.，和B.Patil，“代理移动IPv6”，RFC 5213，DOI 10.17487/RFC5213，2008年8月<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]Wakikawa，R.，Ed.，Devarapalli，V.，Tsirtsis，G.，Ernst，T.，和K.Nagami，“多重托管地址注册”，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.Kuladinhi，“移动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]Krishnan，S.，Gundavelli，S.，Liebsch，M.，Yokota，H.，和J.Korhonen，“代理移动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.，Ed.“互联网主机的要求-通信层”，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，“代理移动IPv6的服务质量选项”，RFC 7222，DOI 10.17487/RFC7222，2014年5月<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]Melia，T.，Ed.和S.Gundavelli，Ed.，“具有多访问支持的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.
作者还要感谢胡安·卡洛斯·祖尼加、皮埃里克·塞特和朱利安·拉加尼尔就这一主题进行的所有有益讨论。
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电子邮件：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
洪永根电邮：永根。hong@gmail.com
Rajeev Koodli Email: rajeevkoodli@google.com
Rajeev Koodli电子邮件：rajeevkoodli@google.com
Telemaco Melia Email: telemaco.melia@googlemail.com
Telemaco Melia电子邮件：Telemaco。melia@googlemail.com
Frank Xia Email: xiayangsong@huawei.com
Xia Frank电子邮件：xiayangsong@huawei.com
Author's Address
作者地址
Carlos J. Bernardos (editor) Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
卡洛斯·J·贝尔纳多斯（编辑）马德里卡洛斯三世大学。西班牙马德里勒冈30号大学28911
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/