Internet Engineering Task Force (IETF) P. Seite
Request for Comments: 8278 Orange
Category: Standards Track A. Yegin
ISSN: 2070-1721 Actility
S. Gundavelli
Cisco
January 2018
Internet Engineering Task Force (IETF) P. Seite
Request for Comments: 8278 Orange
Category: Standards Track A. Yegin
ISSN: 2070-1721 Actility
S. Gundavelli
Cisco
January 2018
Mobile Access Gateway (MAG) Multipath Options
移动接入网关（MAG）多路径选项
Abstract
摘要
This specification defines extensions to the Proxy Mobile IPv6 (PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic. This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option.
本规范定义了对代理移动IPv6（PMIPv6）协议的扩展，该协议允许移动接入网关（MAG）向本地移动锚（LMA）注册多个代理转交地址（pCoA），并同时与LMA建立多个IP隧道。该能力允许MAG利用所有可用的接入网络来路由移动节点的IP流量。本文档定义了以下两个新的移动头选项：MAG多路径绑定选项和MAG标识符选项。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8278.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8278.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
3.2. Traffic Distribution Schemes . . . . . . . . . . . . . . 6
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
4.1. MAG Multipath Binding Option . . . . . . . . . . . . . . 7
4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10
4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11
4.4. Signaling Considerations . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
3.2. Traffic Distribution Schemes . . . . . . . . . . . . . . 6
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
4.1. MAG Multipath Binding Option . . . . . . . . . . . . . . 7
4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10
4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11
4.4. Signaling Considerations . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Multihoming support on IP hosts can greatly improve the user experience. With the simultaneous use of multiple access networks, multihoming brings better network connectivity, reliability, and improved quality of communication. The following are some of the goals and benefits of multihoming support:
IP主机上的多宿主支持可以极大地改善用户体验。随着多址网络的同时使用，多址技术带来了更好的网络连通性、可靠性和更好的通信质量。以下是多主机支持的一些目标和好处：
o Redundancy/Fault-Recovery
o 冗余/故障恢复
o Load balancing
o 负载平衡
o Load sharing
o 负荷分担
o Preference settings
o 首选项设置
According to [RFC4908], users of small-scale networks can benefit from a mobile and fixed multihomed architecture using mobile IP [RFC6275] and Network Mobility (NEMO) [RFC3963].
根据[RFC4908]，小型网络的用户可以受益于使用移动IP[RFC6275]和网络移动性（NEMO）[RFC3963]的移动和固定多址体系结构。
The motivation for this work is to extend the PMIPv6 protocol with multihoming extensions [RFC4908] for realizing the following capabilities:
这项工作的动机是通过多主扩展[RFC4908]扩展PMIPv6协议，以实现以下功能：
o Using GRE as mobile tunneling, possibly with its key extension [RFC5845].
o 使用GRE作为移动隧道，可能带有其密钥扩展[RFC5845]。
o Using UDP encapsulation [RFC5844] in order to support NAT traversal in an IPv4 networking environment.
o 使用UDP封装[RFC5844]以支持IPv4网络环境中的NAT穿越。
o Using the prefix delegation mechanism [RFC7148].
o 使用前缀委派机制[RFC7148]。
o Using the Vendor Specific Mobility Option [RFC5094], for example, to allow the MAG and LMA to exchange information (e.g., WAN interface QoS metrics), which allows the appropriate traffic-steering decisions to be made.
o 使用特定于供应商的移动性选项[RFC5094]，例如，允许MAG和LMA交换信息（例如，WAN接口QoS指标），从而允许做出适当的流量控制决策。
PMIPv6 relies on two mobility entities: the MAG, which acts as the default gateway for the end node (either a mobile or a fixed node) attached to the MAG's access links, and the LMA, which acts as the topological anchor point. IP tunnel is created with any one of the supported encapsulation mode between the MAG and the LMA. Then, the MAG and LMA distribute the end node's traffic over these tunnels. All PMIPv6 operations are performed on behalf of the end node and its correspondent node. Thus, it makes PMIPv6 well adapted to multihomed architecture as considered in [RFC4908]. Taking the LTE and WLAN networking environments as examples, the PMIPv6-based multihomed architecture is depicted in Figure 1. In this example, IP flows,
PMIPv6依赖于两个移动实体：MAG（作为连接到MAG的接入链路的终端节点（移动或固定节点）的默认网关）和LMA（作为拓扑锚定点）。IP隧道是使用MAG和LMA之间支持的任何一种封装模式创建的。然后，MAG和LMA在这些隧道上分配终端节点的流量。所有PMIPv6操作都代表终端节点及其对应节点执行。因此，如[RFC4908]所述，它使PMIPv6能够很好地适应多宿体系结构。以LTE和WLAN网络环境为例，图1描述了基于PMIPv6的多址体系结构。在本例中，IP流，
Flow-1 and Flow-3 are routed over Tunnel-1 and Flow-2 is routed over Tunnel-2. However, IP traffic belonging to Flow-4 is distributed on both Tunnel-1 and Tunnel-2 paths.
流量-1和流量-3在通道-1上布线，流量-2在通道-2上布线。然而，属于流4的IP流量分布在隧道1和隧道2路径上。
Flow-1
|
|Flow-2 _----_
| | CoA-1 _( )_ Tunnel-1 Flow-1
| | .---=======( LTE )========\ Flow-3
| | | (_ _) \ Flow-4
| | | '----' \
| | +=====+ \ +=====+ _----_
| '-| | \ | | _( )_
'---| MAG | | LMA |-( Internet )--
.---| | | | (_ _)
| .-| | / | | '----'
| | +=====+ / +=====+
| | | _----_ /
| | | CoA-2 _( )_ Tunnel-2 /
| | .---=======( WLAN )========/ Flow-2
| | (_ _) Flow-4
| | '----'
|Flow-3
|
Flow0-4
Flow-1
|
|Flow-2 _----_
| | CoA-1 _( )_ Tunnel-1 Flow-1
| | .---=======( LTE )========\ Flow-3
| | | (_ _) \ Flow-4
| | | '----' \
| | +=====+ \ +=====+ _----_
| '-| | \ | | _( )_
'---| MAG | | LMA |-( Internet )--
.---| | | | (_ _)
| .-| | / | | '----'
| | +=====+ / +=====+
| | | _----_ /
| | | CoA-2 _( )_ Tunnel-2 /
| | .---=======( WLAN )========/ Flow-2
| | (_ _) Flow-4
| | '----'
|Flow-3
|
Flow0-4
Figure 1: Multihomed MAG Using Proxy Mobile IPv6
图1：使用代理移动IPv6的多宿MAG
The current version of PMIPv6 does not allow a MAG to register more than one pCoA to the LMA. In other words, only one MAG/LMA link, i.e., IP-in-IP tunnel, can be used at the same time. This document overcomes this limitation by defining the multiple pCoAs extension for PMIPv6.
当前版本的PMIPv6不允许MAG向LMA注册多个pCoA。换句话说，只能同时使用一条MAG/LMA链路，即IP隧道中的IP。本文档通过为PMIPv6定义多个PCOA扩展来克服此限制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
All mobility-related terms used in this document are to be interpreted as defined in [RFC5213], [RFC5844], and [RFC7148]. Additionally, this document uses the following term:
本文件中使用的所有移动性相关术语应按照[RFC5213]、[RFC5844]和[RFC7148]中的定义进行解释。此外，本文件使用以下术语：
IP-in-IP
IP中的IP
IP-within-IP encapsulation [RFC2473] [RFC4213]
IP内IP封装[RFC2473][RFC4213]
Figure 2 is the call flow detailing multi-access support with PMIPv6. The MAG in this example scenario is equipped with both WLAN and LTE interfaces and is also configured with the multihoming functionality. The steps of the call flow are as follows:
图2是使用PMIPv6详细说明多访问支持的调用流。本示例场景中的MAG配备有WLAN和LTE接口，并且还配置有多归属功能。调用流程的步骤如下所示：
Steps (1) and (2): The MAG attaches to both WLAN and LTE networks. Then, the MAG obtains two different pCoAs, respectfully.
步骤（1）和（2）：MAG连接到WLAN和LTE网络。然后，MAG分别获得两个不同的PCOA。
Step (3): The MAG sends, over the LTE access, a Proxy Binding Update (PBU) message with the new MAG Multipath Binding (MMB) and MAG Network Access Identifier (MAG-NAI) options to the LMA. The request can be for a physical mobile node attached to the MAG or for a logical mobile node configured on the mobile access gateway. A logical mobile node is a logical representation of a mobile node in the form of a configuration that is always enabled on the MAG. The mobility session that is created (i.e., create a Binding Cache Entry (BCE)) on the LMA will be marked with multipath support.
步骤（3）：MAG通过LTE接入向LMA发送具有新的MAG多路径绑定（MMB）和MAG网络接入标识符（MAG-NAI）选项的代理绑定更新（PBU）消息。该请求可以针对连接到MAG的物理移动节点，或者针对在移动接入网关上配置的逻辑移动节点。逻辑移动节点是以总是在MAG上启用的配置形式的移动节点的逻辑表示。在LMA上创建的移动会话（即，创建绑定缓存项（BCE））将被标记为多路径支持。
Step (4): The LMA sends back a Proxy Binding Acknowledgement (PBA) including the Home Network Prefix (HNP) and other session parameters allocated for that mobility session.
步骤（4）：LMA发回包括归属网络前缀（HNP）和为该移动会话分配的其他会话参数的代理绑定确认（PBA）。
Step (5): IP tunnel is created between the MAG and the LMA over LTE access with any one of the supported encapsulation modes.
步骤（5）：使用任何一种支持的封装模式在MAG和LMA之间通过LTE接入创建IP隧道。
Steps (6) to (8): The MAG repeats steps (3) to (5) on the WLAN access. The MAG includes the HNP, received on step (4) in the PBU. The LMA updates its binding cache by creating a new mobility session for this MAG.
步骤（6）至（8）：MAG在WLAN接入上重复步骤（3）至（5）。MAG包括在PBU中的步骤（4）上接收的HNP。LMA通过为此MAG创建新的移动会话来更新其绑定缓存。
Steps (9) and (10): The IP hosts MN_1 and MN_2 are assigned IP addresses from the mobile network prefix delegated to the MAG by the LMA.
步骤（9）和（10）：IP主机MN_1和MN_2从LMA委托给MAG的移动网络前缀被分配IP地址。
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+
| MN_1| | MN_2| | MAG | | WLAN| | LTE | | LMA |
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+
| | | | | |
| | | | | |
| | | (1) ATTACH | | |
| | | <--------> | | |
| | | (2) ATTACH | |
| | | <---------------------->| |
| | | (3) PBU (MAG-NAI, MMB, ...) |
| | | ------------------------*-------------->|
| | | |
| | | Accept PBU
| | | (allocate HNP,
| | | create BCE)
| | | (4) PBA (MMB, ...) |
| | | <-----------------------*---------------|
| | | (5) TUNNEL INTERFACE CREATION over LTE |
| | |-============== TUNNEL ==*==============-|
| | | |
| | | (6) PBU (MAG-NAI, MMB, ...) |
| | | -----------*--------------------------->|
| | | |
| | | Accept PBU
| | | (update BCE)
| | | (7) PBA (MMB, ...) |
| | | <----------*--------------------------- |
| | | (8) TUNNEL INTERFACE CREATION over WLAN |
| | |-===========*== TUNNEL =================-|
| (9) ATTACH | |
| <---------------> | |
| |(10) ATTACH| |
| |<--------> | |
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+
| MN_1| | MN_2| | MAG | | WLAN| | LTE | | LMA |
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+
| | | | | |
| | | | | |
| | | (1) ATTACH | | |
| | | <--------> | | |
| | | (2) ATTACH | |
| | | <---------------------->| |
| | | (3) PBU (MAG-NAI, MMB, ...) |
| | | ------------------------*-------------->|
| | | |
| | | Accept PBU
| | | (allocate HNP,
| | | create BCE)
| | | (4) PBA (MMB, ...) |
| | | <-----------------------*---------------|
| | | (5) TUNNEL INTERFACE CREATION over LTE |
| | |-============== TUNNEL ==*==============-|
| | | |
| | | (6) PBU (MAG-NAI, MMB, ...) |
| | | -----------*--------------------------->|
| | | |
| | | Accept PBU
| | | (update BCE)
| | | (7) PBA (MMB, ...) |
| | | <----------*--------------------------- |
| | | (8) TUNNEL INTERFACE CREATION over WLAN |
| | |-===========*== TUNNEL =================-|
| (9) ATTACH | |
| <---------------> | |
| |(10) ATTACH| |
| |<--------> | |
Figure 2: Functional Separation of the Control and User Planes
图2：控制平面和用户平面的功能分离
When the MAG has registered a multipath binding with the LMA, there will be multiple established overlay tunnels between them. The MAG and the LMA can use any one, or more, of the available tunnel paths for routing the mobile node's IP traffic. This specification does not recommend or define any specific traffic distribution scheme. However, it identifies two well-known approaches that implementations can potentially use. These approaches are per-flow and per-packet traffic distribution schemes.
当MAG已向LMA注册多路径绑定时，它们之间将存在多个已建立的覆盖隧道。MAG和LMA可以使用任何一个或多个可用隧道路径来路由移动节点的IP流量。本规范不推荐或定义任何特定的交通分配方案。但是，它确定了实现可能使用的两种众所周知的方法。这些方法是每流和每包流量分配方案。
Per-Flow Traffic Distribution:
单流量流量分布：
o In this approach, the MAG and the LMA associate each of the IP flows (upstream and downstream) with a specific tunnel path. The packets in a given IP flow are always routed on the same overlay tunnel path; they are never split and routed concurrently on more than one tunnel path. It is possible for a given flow to be moved from one tunnel path to another, but the flow is never split. The decision to bind a given IP flow to a specific tunnel path is based on the traffic distribution policy. This traffic distribution policy is either statically configured on both the MAG and the LMA or dynamically negotiated over PMIPv6 signaling. The Flow Binding extension [RFC6089] and Traffic Selectors for Flow Bindings [RFC6088] define the mechanism and the semantics for exchanging the traffic policy between two tunnel peers; the same mechanism and the mobility options are used here.
o 在该方法中，MAG和LMA将每个IP流（上游和下游）与特定隧道路径相关联。给定IP流中的数据包总是在相同的覆盖隧道路径上路由；它们决不会在多条隧道路径上同时拆分和路由。给定的流量可以从一条隧道路径移动到另一条隧道路径，但流量永远不会分离。将给定IP流绑定到特定隧道路径的决策基于流量分配策略。该流量分配策略要么在MAG和LMA上静态配置，要么在PMIPv6信令上动态协商。流绑定扩展[RFC6089]和流绑定的流量选择器[RFC6088]定义了在两个隧道对等方之间交换流量策略的机制和语义；这里使用相同的机制和移动性选项。
Per-Packet Traffic Distribution:
每包流量分布：
o In this approach, packets belonging to a given IP flow will be split and routed across more than one tunnel path. The exact approach for traffic distribution or the distribution weights is outside the scope of this specification. In a very simplistic approach, assuming that the established tunnel paths have symmetric characteristics, the packets can be equally distributed on all the available tunnel paths. In a different scenario, when the links have different speeds, the chosen approach can be based on weighted distribution (e.g., n:m ratio). However, in any of these chosen approaches, implementations have to be sensitive to issues related to asymmetric link characteristics and the resulting issues such as reordering, buffering, and the impact on application performance. Care must be taken to ensure that there is no negative impact on the application performance due to the use of this approach.
o 在这种方法中，属于给定IP流的数据包将被分割并跨多个隧道路径路由。流量分配或分配权重的精确方法不在本规范的范围内。在一种非常简单的方法中，假设所建立的隧道路径具有对称特性，则分组可以均匀地分布在所有可用的隧道路径上。在不同的场景中，当链路具有不同的速度时，所选择的方法可以基于加权分布（例如，n:m比率）。然而，在这些选择的方法中，实现必须对与非对称链路特性相关的问题以及由此产生的问题（如重新排序、缓冲和对应用程序性能的影响）敏感。必须注意确保使用这种方法不会对应用程序性能产生负面影响。
The MAG Multipath Binding option is a new mobility header option defined for use with PBU and PBA messages exchanged between the LMA and the MAG.
MAG多路径绑定选项是一个新的移动报头选项，定义用于LMA和MAG之间交换的PBU和PBA消息。
This mobility header option is used for requesting multipath support. It indicates that the MAG is requesting that the LMA register the current CoA associated with the request as one of the many CoAs
此移动报头选项用于请求多路径支持。它表示MAG请求LMA将与请求相关联的当前CoA注册为多个CoA之一
through which the MAG can be reached. It is also used for carrying the information related to the access network associated with the CoA.
通过它可以到达MAG。它还用于承载与CoA相关联的接入网络相关的信息。
The MAG Multipath Binding option does not have any alignment requirement. Its format is as shown in Figure 3:
MAG多路径绑定选项没有任何对齐要求。其格式如图3所示：
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 | If-ATT | If-Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID |B|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | If-ATT | If-Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID |B|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MAG Multipath Binding Option
图3:MAG多路径绑定选项
Type
类型
Type: MAG Multipath Binding (63)
类型：MAG多路径绑定（63）
Length
长
8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
Interface Access-Technology Type (If-ATT)
接口访问技术类型（如果ATT）
This 8-bit field identifies the Access-Technology type of the interface through which the mobile node is connected. The permitted values for this are from the Access Technology Type registry <https://www.iana.org/assignments/mobility-parameters/> defined in [RFC5213].
此8位字段标识移动节点通过其连接的接口的接入技术类型。允许的值来自Access Technology类型注册表<https://www.iana.org/assignments/mobility-parameters/>在[RFC5213]中定义。
Interface Label (If-Label)
接口标签（如果是标签）
This 8-bit unsigned integer represents the interface label.
此8位无符号整数表示接口标签。
The interface label is an identifier configured on the WAN interface of the MAG. All the WAN interfaces of the MAG that are used for sending PBU messages are configured with a label. The labels merely identify the type of WAN interface and are primarily used in application-routing policies. For example, a Wi-Fi interface can be configured with a label "9" and an LTE interface with a label "11". Furthermore, the same label may be configured on two WAN interfaces of similar characteristics (e.g., two Ethernet interfaces with the same label).
接口标签是在MAG的WAN接口上配置的标识符。用于发送PBU消息的MAG的所有WAN接口都配置有标签。标签仅标识WAN接口的类型，主要用于应用程序路由策略。例如，Wi-Fi接口可以配置为标签“9”，LTE接口可以配置为标签“11”。此外，可以在具有类似特征的两个WAN接口（例如，具有相同标签的两个以太网接口）上配置相同标签。
Interface labels are signaled from the MAG to the LMA in the PBU messages and both the LMA and MAG will be able to mark each of the dynamically created Binding/Tunnel with the associated label. These labels are used in generating consistent application-routing rules on the both the LMA and the MAG. For example, there can be a policy requiring HTTP packets to be routed over an interface that has the interface label of "9", and if any of the interfaces with interface label "9" are not available, the traffic needs to be routed over the interface with the interface label "11". The MAG and the LMA will be able to apply this routing rule with the exchange of interface labels in PBU messages and by associating the application flows to tunnels with the matching interface labels.
接口标签在PBU消息中从MAG向LMA发送信号，LMA和MAG将能够使用相关标签标记动态创建的每个绑定/隧道。这些标签用于在LMA和MAG上生成一致的应用程序路由规则。例如，可能存在一种策略，要求HTTP数据包通过接口标签为“9”的接口进行路由，如果任何接口标签为“9”的接口不可用，流量需要通过接口标签为“11”的接口进行路由。MAG和LMA将能够通过交换PBU消息中的接口标签，并通过将到隧道的应用程序流与匹配的接口标签相关联，来应用该路由规则。
Binding Identifier (BID)
绑定标识符（BID）
This 8-bit unsigned integer is used for identifying the binding. The permitted values are 1 through 254. The values 0 and 255 are reserved.
此8位无符号整数用于标识绑定。允许值为1到254。值0和255是保留的。
The MAG identifies each of the mobile node's bindings with a unique identifier. The MAG includes the identifier in the PBU message; when the PBU request is accepted by the LMA, the resulting binding is associated with this BID in the mobile node's Binding Cache entry.
MAG使用唯一标识符标识每个移动节点的绑定。MAG在PBU消息中包括标识符；当LMA接受PBU请求时，产生的绑定与移动节点的绑定缓存条目中的该出价相关联。
Bulk Re-registration Flag (B)
批量重新注册标志（B）
If set to a value of (1), this flag notifies the LMA to consider this as a request to update the binding lifetime of all the mobile node's bindings upon accepting this specific request. The (B) flag MUST NOT be set to a value of (1) if the value of the Registration Overwrite (O) flag is set to a value of (1).
如果设置为（1）的值，则该标志通知LMA将此视为在接受该特定请求时更新所有移动节点绑定的绑定寿命的请求。如果注册覆盖（O）标志的值设置为（1），则（B）标志不得设置为（1）值。
Registration Overwrite (O)
注册覆盖（O）
This flag, if set to a value of (1), notifies the LMA that upon accepting this request, it should replace all of the mobile node's existing bindings with this binding. This flag MUST NOT be set to a value of (1) if the value of the Bulk Re-registration Flag (B) is set to a value of (1). This flag MUST be set to a value of (0) in De-Registration requests.
如果将该标志设置为值（1），则通知LMA在接受该请求时，它应使用该绑定替换所有移动节点的现有绑定。如果批量重新注册标志（B）的值设置为值（1），则不得将该标志设置为值（1）。在注销请求中，此标志必须设置为（0）值。
Reserved
含蓄的
This field is unused in this specification. The value MUST be set to zero (0) by the sender and MUST be ignored by the receiver.
此字段在本规范中未使用。发送方必须将该值设置为零（0），接收方必须忽略该值。
The MAG Identifier option is a new mobility header option defined for use with PBU and PBA messages exchanged between the LMA and the MAG. This mobility header option is used for conveying the MAG's identity.
MAG标识符选项是一个新的移动报头选项，定义用于LMA和MAG之间交换的PBU和PBA消息。该移动报头选项用于传送MAG的身份。
This option does not have any alignment requirements.
此选项没有任何对齐要求。
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MAG Identifier Option
图4:MAG标识符选项
Type
类型
Type: MAG Identifier (64)
类型：MAG标识符（64）
Length
长
8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
Subtype
亚型
One-byte unsigned integer used for identifying the type of the Identifier field. Accepted values for this field are the registered type values from the "Mobile Node Identifier Option Subtypes" registry <https://www.iana.org/assignments/mobility-parameters/>.
一个字节的无符号整数，用于标识标识符字段的类型。此字段的接受值是“移动节点标识符选项子类型”注册表中注册的类型值<https://www.iana.org/assignments/mobility-parameters/>.
Reserved
含蓄的
This field is unused in this specification. The value MUST be set to zero (0) by the sender and MUST be ignored by the receiver.
此字段在本规范中未使用。发送方必须将该值设置为零（0），接收方必须忽略该值。
Identifier
标识符
A variable-length identifier of the type indicated in the Subtype field.
子类型字段中指示的类型的可变长度标识符。
This document defines the following new Status Code value for use in PBA messages.
本文档定义了以下在PBA消息中使用的新状态代码值。
The LMA SHOULD use this error code when rejecting a PBU message from a MAG requesting a multipath binding. The following is the potential reason for rejecting the request:
LMA在拒绝来自MAG请求多路径绑定的PBU消息时应使用此错误代码。以下是拒绝请求的潜在原因：
o The LMA does not support multipath binding.
o LMA不支持多路径绑定。
CANNOT_SUPPORT_MULTIPATH_BINDING (Cannot Support Multipath Binding): 180
无法支持多路径绑定（无法支持多路径绑定）：180
o The MAG, when requesting multipath support, MUST include the MAG Multipath Binding option (Section 4.1) in each of the PBU messages that it sends through the different WAN interfaces. The inclusion of this option serves as a hint that the MAG is requesting multipath support. Furthermore, the MAG Identifier option MUST also be present in the PBU message.
o MAG在请求多路径支持时，必须在通过不同WAN接口发送的每个PBU消息中包含MAG多路径绑定选项（第4.1节）。包含此选项将提示MAG正在请求多路径支持。此外，PBU消息中还必须存在MAG标识符选项。
o If the MAG is aware that the LMA supports the multipath binding option defined in this specification and if it chooses to use multiple paths, then it can send the PBU packets for each of the paths, either sequentially or concurrently. However, if the MAG is not aware of the LMA capability, then it SHOULD first discover the LMA capability by sending PBU packets with multipath on only one path first. This will ensure that the LMA will not be overwriting the binding of one path with the other path.
o 如果MAG知道LMA支持本规范中定义的多路径绑定选项，并且如果它选择使用多条路径，那么它可以顺序或并发地为每条路径发送PBU分组。然而，如果MAG不知道LMA能力，那么它应该首先通过仅在一条路径上发送具有多路径的PBU分组来发现LMA能力。这将确保LMA不会覆盖一条路径与另一条路径的绑定。
o If the LMA supports multipath capability as defined in this specification and if it enables the same for a mobile node's session per the MAG's request, then the LMA MUST include the Multipath Binding option (Section 4.1) without the MAG-NAI option (Section 4.2) in the corresponding PBA reply.
o 如果LMA支持本规范中定义的多路径能力，并且如果它根据MAG的请求为移动节点的会话启用相同的多路径能力，则LMA必须在相应的PBA应答中包括多路径绑定选项（第4.1节），而不包括MAG-NAI选项（第4.2节）。
o If the LMA is a legacy LMA that does not support this specification, the LMA will skip the MAG Multipath Binding option (and MAG-NAI option) and process the rest of the message as specified in the base PMIPv6 specification ([RFC5213]). Furthermore, the LMA will not include the MAG Multipath Binding option (or the MAG-NAI option) in the PBA message. The MAG, upon receiving the PBA message without the MAG Multipath Binding option, SHOULD disable multipath support for the mobile node.
o 如果LMA是不支持此规范的传统LMA，LMA将跳过MAG多路径绑定选项（和MAG-NAI选项），并按照基本PMIPv6规范（[RFC5213]）中的规定处理其余消息。此外，LMA将不在PBA消息中包括MAG多路径绑定选项（或MAG-NAI选项）。MAG在接收到没有MAG多路径绑定选项的PBA消息时，应禁用移动节点的多路径支持。
o If the mobile node is not authorized for multipath support, then the LMA will reject the request by sending a PBA message with the Status field value set to CANNOT_SUPPORT_MULTIPATH_BINDING (Section 4.3). The LMA MUST echo the MAG Multipath Binding option (without the MAG-NAI option) in the PBA message. The MAG, upon receiving this message, SHOULD disable multipath support for the mobile node.
o 如果移动节点未获得多路径支持授权，则LMA将通过发送状态字段值设置为CANNOT_support_multipath_BINDING（第4.3节）的PBA消息来拒绝请求。LMA必须在PBA消息中回显MAG多路径绑定选项（不带MAG-NAI选项）。MAG在收到此消息后，应禁用移动节点的多路径支持。
This specification defines a new mobility option: the MAG Multipath Binding option. The format of this option is described in Section 4.1. The type value 63 has been allocated for this mobility option from the "Mobility Options" registry at <http://www.iana.org/assignments/mobility-parameters>.
该规范定义了一个新的移动性选项：MAG多路径绑定选项。第4.1节描述了该选项的格式。已从位于的“移动选项”注册表为该移动选项分配了类型值63<http://www.iana.org/assignments/mobility-parameters>.
This specification defines a new mobility option: the MAG Identifier option. The format of this option is described in Section 4.2. The type value 64 has been allocated for this mobility option from the "Mobility Options" registry at <http://www.iana.org/assignments/ mobility-parameters>.
本规范定义了一个新的移动性选项：MAG标识符选项。第4.2节描述了该选项的格式。已从位于的“移动选项”注册表为此移动选项分配了类型值64<http://www.iana.org/assignments/ 移动性参数>。
This document defines a new status value: CANNOT_SUPPORT_MULTIPATH_BINDING (180) for use in PBA messages, as described in Section 4.3. This value has been assigned from the "Status Codes" registry at <http://www.iana.org/assignments/mobility-parameters>.
本文档定义了一个新的状态值：无法支持用于PBA消息的多路径绑定（180），如第4.3节所述。此值已从位于的“状态代码”注册表中分配<http://www.iana.org/assignments/mobility-parameters>.
This specification allows a MAG to establish multiple PMIPv6 tunnels with an LMA by registering a care-of address for each of its connected access networks. This essentially allows the mobile node's IP traffic to be routed through any of the tunnel paths based on the negotiated flow policy. This new capability has no impact on the protocol security. Furthermore, this specification defines two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option. These options are carried like any other mobility header option as specified in [RFC5213]. Therefore, it inherits security guidelines from [RFC5213]. Thus, this specification does not weaken the security of the PMIPv6 Protocol and does not introduce any new security vulnerabilities.
该规范允许MAG通过为其每个连接的接入网络注册转交地址，来与LMA建立多个PMIPv6隧道。这基本上允许移动节点的IP流量基于协商的流策略通过任何隧道路径路由。此新功能对协议安全性没有影响。此外，该规范定义了两个新的移动报头选项：MAG多路径绑定选项和MAG标识符选项。这些选项与[RFC5213]中规定的任何其他移动报头选项一样。因此，它继承了[RFC5213]的安全准则。因此，本规范不会削弱PMIPv6协议的安全性，也不会引入任何新的安全漏洞。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，DOI 10.17487/RFC3963，2005年1月<https://www.rfc-editor.org/info/rfc3963>.
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094, December 2007, <https://www.rfc-editor.org/info/rfc5094>.
[RFC5094]Devarapalli，V.，Patel，A.，和K.Leung，“移动IPv6供应商特定选项”，RFC 5094，DOI 10.17487/RFC50942007年12月<https://www.rfc-editor.org/info/rfc5094>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <https://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月<https://www.rfc-editor.org/info/rfc5213>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, <https://www.rfc-editor.org/info/rfc5844>.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，DOI 10.17487/RFC5844，2010年5月<https://www.rfc-editor.org/info/rfc5844>.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, <https://www.rfc-editor.org/info/rfc5845>.
[RFC5845]Muhanna，A.，Khalil，M.，Gundavelli，S.，和K.Leung，“代理移动IPv6的通用路由封装（GRE）密钥选项”，RFC 5845，DOI 10.17487/RFC5845，2010年6月<https://www.rfc-editor.org/info/rfc5845>.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, DOI 10.17487/RFC6088, January 2011, <https://www.rfc-editor.org/info/rfc6088>.
[RFC6088]Tsirtsis，G.，Giarreta，G.，Soliman，H.，和N.Montavont，“流绑定的流量选择器”，RFC 6088，DOI 10.17487/RFC6088，2011年1月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc6089>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 6275，DOI 10.17487/RFC6275，2011年7月<https://www.rfc-editor.org/info/rfc6275>.
[RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014, <https://www.rfc-editor.org/info/rfc7148>.
[RFC7148]Zhou，X.，Korhonen，J.，Williams，C.，Gundavelli，S.，和CJ。Bernardos，“代理移动IPv6的前缀授权支持”，RFC 7148，DOI 10.17487/RFC7148，2014年3月<https://www.rfc-editor.org/info/rfc7148>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，DOI 10.17487/RFC2473，1998年12月<https://www.rfc-editor.org/info/rfc2473>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <https://www.rfc-editor.org/info/rfc4213>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，DOI 10.17487/RFC4213，2005年10月<https://www.rfc-editor.org/info/rfc4213>.
[RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, R., and H. Ohnishi, "Multi-homing for small scale fixed network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/RFC4908, June 2007, <https://www.rfc-editor.org/info/rfc4908>.
[RFC4908]Nagami，K.，Uda，S.，Ogashiwa，N.，Esaki，H.，Wakikawa，R.，和H.Ohnishi，“使用移动IP和NEMO的小型固定网络多宿”，RFC 4908，DOI 10.17487/RFC4908，2007年6月<https://www.rfc-editor.org/info/rfc4908>.
Acknowledgements
致谢
The authors of this document would like to acknowledge the discussions and feedback on this topic from the members of the Distributed Mobility Management Working Group. The authors would also like to thank Jouni Korhonen, Jong Hyouk Lee, Dirk Von-Hugo, Seil Jeon, Carlos Bernardos, Robert Sparks, Adam Roach, Kathleen Moriarty, Hilarie Orman, Ben Campbell, Warren Kumari, and Dhananjay Patki for their review feedback. Special thanks to Mirja Kuehlewind for a very thorough review and suggesting many text improvements.
本文件的作者希望感谢分布式移动性管理工作组成员对此主题的讨论和反馈。作者还要感谢Jouni Korhonen、Jong Hyuk Lee、Dirk Von Hugo、Seil Jeon、Carlos Bernardos、Robert Sparks、Adam Roach、Kathleen Moriarty、Hilarie Orman、Ben Campbell、Warren Kumari和Dhananjay Patki的评论反馈。特别感谢Mirja Kuehlewind进行了非常彻底的审查，并提出了许多文本改进建议。
Authors' Addresses
作者地址
Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France
Pierrick Seite Orange 4号，英国石油公司，邮编91226，法国塞森塞维涅35512
Email: pierrick.seite@orange.com
Email: pierrick.seite@orange.com
Alper Yegin Actility Turkey
阿尔珀·耶金活动土耳其酒店
Email: alper.yegin@actility.com
Email: alper.yegin@actility.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
Email: sgundave@cisco.com
Email: sgundave@cisco.com