Internet Engineering Task Force (IETF) P. Dutta
Request for Comments: 7392 M. Bocci
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 L. Martini
Cisco Systems
December 2014
Internet Engineering Task Force (IETF) P. Dutta
Request for Comments: 7392 M. Bocci
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 L. Martini
Cisco Systems
December 2014
Explicit Path Routing for Dynamic Multi-Segment Pseudowires
动态多段伪导线的显式路径布线
Abstract
摘要
When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.
当通过显式路径设置时，可能需要动态多段伪线（MS PW），以提供一个简单的解决方案，为服务提供不同的主和备用MS PW的1:1保护，或为特殊MS PW启用受控信令（严格或松散）。本文件规定了沿显式路径建立动态MS PWs所需的扩展和程序。
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/rfc7392.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7392.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................2
2. Requirements Language and Terminology ...........................3
3. Explicit Path in MS-PW Signaling ................................3
3.1. S-PE Addressing ............................................3
3.2. Explicit Route TLV (ER-TLV) ................................3
3.3. Explicit Route Hop TLV (ER-Hop TLV) ........................4
3.4. ER-Hop Semantics ...........................................4
3.4.1. ER-Hop Type: IPv4 Prefix ............................4
3.4.2. ER-Hop Type: IPv6 Prefix ............................4
3.4.3. ER-Hop Type: L2 PW Address ..........................5
4. Explicit Route TLV Processing ...................................6
4.1. Next-Hop Selection .........................................6
4.2. Adding ER Hops to the Explicit Route TLV ...................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Normative References ............................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................10
1. Introduction ....................................................2
2. Requirements Language and Terminology ...........................3
3. Explicit Path in MS-PW Signaling ................................3
3.1. S-PE Addressing ............................................3
3.2. Explicit Route TLV (ER-TLV) ................................3
3.3. Explicit Route Hop TLV (ER-Hop TLV) ........................4
3.4. ER-Hop Semantics ...........................................4
3.4.1. ER-Hop Type: IPv4 Prefix ............................4
3.4.2. ER-Hop Type: IPv6 Prefix ............................4
3.4.3. ER-Hop Type: L2 PW Address ..........................5
4. Explicit Route TLV Processing ...................................6
4.1. Next-Hop Selection .........................................6
4.2. Adding ER Hops to the Explicit Route TLV ...................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Normative References ............................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................10
Procedures for dynamically establishing Multi-Segment Pseudowires (MS-PWs), where their paths are automatically determined using a dynamic routing protocol, are defined in [RFC7267]. For 1:1 protection of MS-PWs with primary and backup paths, MS-PWs need to be established through a diverse set of Switching Provider Edges (S-PEs) to avoid any single points of failure at the PW level. [RFC7267] allows this through BGP-based mechanisms. This document defines an additional mechanism that allows Source Terminating Provider Edges (ST-PEs) to explicitly choose the path that a PW would take through the intervening S-PEs. Explicit path routing of dynamic MS-PWs may also be required for controlled setup of dynamic MS-PWs and network resource management.
[RFC7267]中定义了动态建立多段伪线（MS PW）的过程，其中使用动态路由协议自动确定其路径。对于具有主路径和备份路径的MS PWs的1:1保护，需要通过一组不同的交换提供程序边缘（S-PE）建立MS PWs，以避免PW级别的任何单点故障。[RFC7267]允许通过基于BGP的机制实现这一点。本文档定义了一种额外的机制，允许源端接提供程序边缘（ST PE）明确选择PW将通过中间S-PE的路径。动态MS PWs的受控设置和网络资源管理也可能需要动态MS PWs的显式路径路由。
Note that in many deployments the ST-PE will not have a view of the topology of S-PEs and so the explicit route will need to be supplied from a management application. How that management application determines the explicit route is outside the scope of this document.
请注意，在许多部署中，ST-PE无法查看S-PE的拓扑结构，因此需要从管理应用程序提供显式路由。该管理应用程序确定显式路由的方式超出了本文档的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the terminology defined in [RFC7267], [RFC4447], and [RFC5036].
本文件使用[RFC7267]、[RFC4447]和[RFC5036]中定义的术语。
The following additional terminology is used:
使用以下附加术语：
Abstract Node: A group of nodes (S-PEs) representing an explicit hop along the path of an MS-PW. An abstract node is identified by an IPv4, IPv6, or S-PE address.
抽象节点：表示沿MS-PW路径的显式跃点的一组节点（S-PE）。抽象节点由IPv4、IPv6或S-PE地址标识。
This section describes the Label Distribution Protocol (LDP) extensions required for signaling explicit paths in dynamic MS-PW setup messages. An explicitly routed MS-PW is set up using a Label Mapping message that carries an ordered list of the S-PEs that the MS-PW is expected to traverse. The ordered list is encoded as a series of Explicit Route Hop TLVs (ER-Hop TLVs) encoded in an ER-TLV that is carried in a Label Mapping message.
本节描述动态MS-PW设置消息中显式路径信令所需的标签分发协议（LDP）扩展。显式路由MS-PW使用标签映射消息进行设置，该消息携带MS-PW预期要遍历的S-PE的有序列表。有序列表被编码为一系列显式路由跳TLV（ER-Hop TLV），编码在标签映射消息中携带的ER-TLV中。
An S-PE address is used to identify a given S-PE among the set of S-PEs belonging to the Packet Switched Networks (PSNs) that may be used by an MS-PW. Each S-PE MUST be assigned an address as specified in Section 3.2 of [RFC7267]. An S-PE that is capable of dynamic MS-PW signaling, but has not been assigned an S-PE address, and that receives a Label Mapping message for a dynamic MS-PW MUST follow the procedures in Section 3.2 of [RFC7267].
S-PE地址用于在属于MS-PW可以使用的分组交换网络（psn）的S-PE集合中识别给定的S-PE。必须按照[RFC7267]第3.2节的规定为每个S-PE分配一个地址。能够动态MS-PW信令，但尚未分配S-PE地址，并且接收动态MS-PW标签映射消息的S-PE必须遵循[RFC7267]第3.2节中的程序。
The ER-TLV specifies the path to be taken by the MS-PW being established. Each hop along the path is represented by an abstract node, which is a group of one or more S-PEs, identified by an IPv4, IPv6, or S-PE address. The ER-TLV format is as per Section 4.1 of [RFC3212].
ER-TLV指定正在建立的MS-PW所采用的路径。路径上的每个跃点由一个抽象节点表示，抽象节点是一个或多个S-PE的组，由IPv4、IPv6或S-PE地址标识。ER-TLV格式符合[RFC3212]第4.1节的要求。
The ER-TLV contains one or more ER-Hop TLVs as defined in Section 3.3.
ER-TLV包含第3.3节中定义的一个或多个ER-Hop TLV。
The contents of an ER-TLV are a series of variable-length ER-Hop TLVs. Each hop contains the identification of an "abstract node" that represents the hop to be traversed. The ER-Hop TLV format is as specified in Section 4.2 of [RFC3212].
ER-TLV的内容是一系列可变长度的ER-Hop TLV。每个跃点都包含表示要遍历的跃点的“抽象节点”的标识。ER-Hop TLV格式如[RFC3212]第4.2节所述。
[RFC3212] defines four ER-Hop TLV Types: IPv4 Prefix, IPv6 Prefix, Autonomous System Number, and LSP-ID. This document specifies the following new ER-Hop TLV Type:
[RFC3212]定义了四种ER-Hop TLV类型：IPv4前缀、IPv6前缀、自治系统编号和LSP-ID。本文档指定了以下新的ER-Hop TLV类型：
Value Type
------ --------------------------------
0x0805 L2 PW Address of Switching Point
Value Type
------ --------------------------------
0x0805 L2 PW Address of Switching Point
ER-Hop TLV
ER-Hop TLV
Details of the ER-Hop semantics are defined in Section 3.4.
ER-Hop语义的详细信息在第3.4节中定义。
This section describes the various semantics associated with the ER-Hop TLV.
本节描述与ER Hop TLV相关的各种语义。
The semantics of the IPv4 ER-Hop TLV Type are specified in [RFC3212], Section 4.7.1.
[RFC3212]第4.7.1节规定了IPv4 ER-Hop TLV类型的语义。
The semantics of the IPv6 ER-Hop TLV Type are specified in [RFC3212], Section 4.7.2.
[RFC3212]第4.7.2节规定了IPv6 ER-Hop TLV类型的语义。
The semantics of the L2 PW Address ER-Hop TLV Type, which contains the L2 PW Address derived from the Generalized PWid Forwarding Equivalence Class (FEC) AII Type 2 structure as defined in [RFC5003], are as follows.
L2 PW地址ER Hop TLV类型的语义如下所示，该类型包含从[RFC5003]中定义的广义PWid转发等价类（FEC）AII类型2结构派生的L2 PW地址。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ER-Hop Type | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ER-Hop Type | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node.
U/F当接收节点不知道TLV时，必须将这些位设置为零，并遵循[RFC5036]的程序。
Type A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW Address, Value = 0x0805.
键入一个14位字段，其中包含ER Hop 3的值，L2 PW地址，值=0x0805。
Length Specifies the length of the value field in bytes = 18.
长度指定值字段的长度，单位为字节=18。
L Bit Set to indicate a loose hop. Cleared to indicate a strict hop.
L位设置为指示松散跃点。清除以指示严格的跃点。
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
PreLen Prefix Length 1-96 (including the length of the Global ID, Prefix, and AC ID fields).
PreLen前缀长度1-96（包括全局ID、前缀和AC ID字段的长度）。
All other fields (AII Type, Length, Global ID, Prefix, and AC ID) define the L2 PW Address and are to be set and interpreted as defined in Section 3.2 of [RFC5003].
所有其他字段（AII类型、长度、全局ID、前缀和AC ID）定义L2 PW地址，并按照[RFC5003]第3.2节的规定进行设置和解释。
A PW Label Mapping message containing an Explicit Route TLV specifies the next hop for a given MS-PW path. Selection of this next hop by the ST-PE or S-PE inserting the ER-Hop TLV may involve a selection from a set of possible alternatives. The mechanism for making a selection from this set is implementation specific and is outside the scope of this document. The mechanism used to select a particular path is also outside the scope of this document, but each node MUST determine a loop-free path if it is to signal the MS-PW. [RFC6073], Section 7.6 provides a mechanism by which a node can check that the path taken by an MS-PW does not include loops.
包含显式路由TLV的PW标签映射消息指定给定MS-PW路径的下一跳。由插入ER-hop TLV的ST-PE或S-PE选择该下一跳可能涉及从一组可能的备选方案中进行选择。从该集合中进行选择的机制是特定于实现的，不在本文档的范围内。用于选择特定路径的机制也不在本文档的范围内，但如果要向MS-PW发送信号，则每个节点必须确定无循环路径。[RFC6073]，第7.6节提供了一种机制，通过该机制，节点可以检查MS-PW所采用的路径是否不包括循环。
As noted in Section 1, in many deployments the ST-PE will not have a view of the topology of S-PEs and so the path will need to be supplied from a management application.
如第1节所述，在许多部署中，ST-PE没有S-PE拓扑视图，因此需要从管理应用程序提供路径。
If a loop-free path cannot be found by an ST-PE or S-PE, then a node MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot determine a loop-free path, then the received Label Mapping message MUST be released with a status code of "PW Loop Detected" as per Section 4.2.3 of [RFC7267].
如果ST-PE或S-PE无法找到无环路路径，则节点不得尝试向MS-PW发送信号。对于S-PE，如果无法确定无环路路径，则必须按照[RFC7267]第4.2.3节的规定，释放接收到的标签映射消息，状态代码为“PW loop Detected”。
To determine the next hop for the MS-PW path, a node performs the following steps. Note that these procedures assume that a valid S-PE address has been assigned to the node, as per Section 3.1, above.
为了确定MS-PW路径的下一个跃点，节点执行以下步骤。请注意，这些程序假定已根据上述第3.1节为节点分配了有效的S-PE地址。
1. The node receiving the Label Mapping message that contains an ER-TLV MUST evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop (i.e., it does not lie within the prefix as determined by the prefix length specified in the ER-Hop TLV), it has received the message in error. Therefore, the node MUST reply with a Label Release message with a "Bad Initial ER-Hop Error" (0x04000004) status code. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. If there is no ER-Hop TLV contained in the ER-TLV, the message is also in error, and the node SHOULD return a "Bad Explicit Routing TLV Error" (0x04000001) status code in a Label Release message sent to the upstream node. Note that this statement does not
1. 接收包含ER-TLV的标签映射消息的节点必须计算第一个ER跃点。如果在第一ER-Hop中未设置L位，并且如果该节点不是由第一ER-Hop描述的抽象节点的一部分（即，它不在由ER-Hop TLV中指定的前缀长度确定的前缀内），则它已接收到错误消息。因此，节点必须使用带有“错误初始ER跃点错误”（0x0400004）状态代码的标签释放消息进行回复。如果设置了L位并且本地节点不是由第一ER跳描述的抽象节点的一部分，则该节点选择沿着由第一ER跳描述的抽象节点的路径的下一跳。如果ER-TLV中不包含ER-Hop TLV，则消息也会出错，并且节点应在发送到上游节点的标签释放消息中返回“错误显式路由TLV错误”（0x04000001）状态代码。请注意，此语句没有
preclude a Label Mapping message with no ER-TLV. If a Label Mapping message with no ER-TLV is received, then it MUST be processed as per [RFC7267].
排除没有ER-TLV的标签映射消息。如果收到没有ER-TLV的标签映射消息，则必须按照[RFC7267]进行处理。
2. If there are no further ER-Hop TLVs following the first ER-Hop TLV, this indicates the end of the explicit route. The Explicit Route TLV MUST be removed from the Label Mapping message. This node may or may not be the end of the PW. Processing continues as per Section 4.2, where a new Explicit Route TLV MAY be added to the Label Mapping message.
2. 如果在第一个ER-Hop TLV之后没有其他ER-Hop TLV，则表示显式路由的结束。必须从标签映射消息中删除显式路由TLV。该节点可能是也可能不是PW的末端。按照第4.2节继续处理，其中可将新的显式路由TLV添加到标签映射消息中。
3. If a second ER-Hop TLV does exist, and the node is also a part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above. Note that this makes the second ER-Hop into the first ER-Hop for the iteration for the next PW segment.
3. 如果第二ER-Hop TLV确实存在，并且该节点也是由第二ER-Hop描述的抽象节点的一部分，则该节点删除第一ER-Hop并继续进行上述步骤2的处理。请注意，这使得第二个ER跃点成为下一个PW段迭代的第一个ER跃点。
4. The node determines if it is topologically adjacent to the abstract node described by the second ER-Hop. That is, it is directly connected to the next node by a PW control-plane adjacency. If so, the node selects a particular next hop that is a member of the abstract node. The node then deletes the first ER-Hop and continues processing as per Section 4.2, below.
4. 该节点确定它是否在拓扑上与第二ER跃点描述的抽象节点相邻。也就是说，它通过PW控制平面邻接直接连接到下一个节点。如果是，则节点选择作为抽象节点成员的特定下一跳。然后，节点删除第一个ER跃点，并按照下面第4.2节继续处理。
5. Next, the node selects a next hop within the abstract node of the first ER-Hop that is along the path to the abstract node of the second ER-Hop. If no such path exists, then there are two cases:
5. 接下来，该节点在第一ER跃点的抽象节点内选择沿着到第二ER跃点的抽象节点的路径的下一跳。如果不存在此类路径，则有两种情况：
A. If the second ER-Hop is a strict ER Hop, then there is an error, and the node MUST return a Label Release message to the upstream node with a "Bad Strict Node Error" (0x04000002) status code.
A.如果第二个ER跃点是严格ER跃点，则存在错误，并且节点必须向上游节点返回带有“错误严格节点错误”（0x04000002）状态代码的标签释放消息。
B. Otherwise, if the second ER-Hop is a loose ER Hop, then the node selects any next hop that is along the path to the next abstract node. If no path exists within the MPLS domain, then there is an error, and the node MUST return a Label Release message to the upstream node with a "Bad Loose Node Error" (0x04000003) status code.
B.否则，如果第二个ER跃点是松散的ER跃点，则节点选择沿着到下一个抽象节点的路径的任何下一个跃点。如果MPLS域中不存在路径，则存在错误，并且节点必须向上游节点返回标签释放消息，其中包含“坏的松散节点错误”（0x04000003）状态代码。
6. Finally, the node replaces the first ER-Hop with any ER Hop that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted.
6. 最后，该节点用表示包含下一跳的抽象节点的任何ER-Hop替换第一个ER-Hop。这是必要的，以便在下一跳接收到显式路由时，它将被接受。
7. Progress the Label Mapping message to the next hop.
7. 将标签映射消息前进到下一个跃点。
After selecting a next hop, the node MAY alter the explicit route in the following ways.
在选择下一跳之后，节点可以通过以下方式改变显式路由。
If, as part of executing the algorithm in Section 4.1, the Explicit Route TLV is removed, then the node MAY add a new Explicit Route TLV.
如果作为执行第4.1节中算法的一部分，删除了显式路由TLV，则节点可以添加新的显式路由TLV。
Otherwise, if the node is a member of the abstract node for the first ER-Hop, then a series of ER Hops MAY be inserted before the First ER Hop or the first ER-Hop MAY be replaced. Each ER Hop in this series MUST denote an abstract node that is a subset of the current abstract node.
否则，如果该节点是第一ER-Hop的抽象节点的成员，则可以在第一ER-Hop之前插入一系列ER-Hop，或者可以替换第一ER-Hop。该系列中的每个ER跃点必须表示一个抽象节点，该节点是当前抽象节点的子集。
Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary series of ER Hops MAY be inserted prior to the first ER-Hop.
或者，如果第一ER跳是松散的ER跳，则可以在第一ER跳之前插入任意系列的ER跳。
RFC 5036 [RFC5036] defines the LDP TLV name space, which is maintained by IANA, in the LDP "TLV Type Name Space" registry. TLV types for the Explicit Route TLV, the IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already defined in this registry.
RFC 5036[RFC5036]在LDP“TLV类型名称空间”注册表中定义LDP TLV名称空间，该空间由IANA维护。此注册表中已定义显式路由TLV、IPv4前缀ER Hop TLV和IPv6前缀ER Hop TLV的TLV类型。
IANA has assigned a further code point from the IETF consensus portion of this registry as follows:
IANA已从该注册中心的IETF共识部分分配了另一个代码点，如下所示：
TLV Type Value Reference
------------------------------------ ------ -------------
L2 PW Address of Switching Point 0x0805 This Document
TLV Type Value Reference
------------------------------------ ------ -------------
L2 PW Address of Switching Point 0x0805 This Document
This document introduces no new security considerations beyond those discussed in [RFC5036], [RFC4447], and [RFC7267]. The security considerations detailed in those documents apply to the protocol extensions described in this RFC.
除[RFC5036]、[RFC4447]和[RFC7267]中讨论的内容外，本文档未引入任何新的安全注意事项。这些文件中详述的安全注意事项适用于本RFC中描述的协议扩展。
As with [RFC7267], it should be noted that the path selection mechanisms specified in this document enable the network to automatically select the S-PEs that are used to forward packets on the MS-PW. Appropriate tools, such as the Virtual Circuit Connectivity Verification (VCCV) trace mechanisms specified in [RFC6073], can be used by an operator of the network to verify the path taken by the MS-PW and therefore be satisfied that the path does not represent an additional security risk.
与[RFC7267]一样，应注意，本文件中指定的路径选择机制使网络能够自动选择用于在MS-PW上转发数据包的S-PE。网络运营商可使用适当的工具，如[RFC6073]中规定的虚拟电路连通性验证（VCCV）跟踪机制，验证MS-PW所采用的路径，从而确保该路径不代表额外的安全风险。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002, <http://www.rfc-editor.org/info/rfc3212>.
[RFC3212]Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.，和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 32122002年1月<http://www.rfc-editor.org/info/rfc3212>.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007, <http://www.rfc-editor.org/info/rfc5003>.
[RFC5003]Metz，C.，Martini，L.，Balus，F.，和J.Sugimoto，“聚合的附件个人标识符（AII）类型”，RFC 5003，2007年9月<http://www.rfc-editor.org/info/rfc5003>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 60732011年1月<http://www.rfc-editor.org/info/rfc6073>.
[RFC7267] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, June 2014, <http://www.rfc-editor.org/info/rfc7267>.
[RFC7267]Martini，L.，Bocci，M.和F.Balus，“多段伪导线的动态放置”，RFC 7267，2014年6月<http://www.rfc-editor.org/info/rfc7267>.
Acknowledgements
致谢
The authors gratefully acknowledge the contribution of the RFC 3212 [RFC3212] authors for the specification of the ER TLV and the ER-Hop TLV, which are reused by this document. The authors also gratefully acknowledge the input of Lizhong Jin.
作者衷心感谢RFC 3212[RFC3212]作者对ER TLV和ER Hop TLV规范的贡献，本文件重复使用了这两种规范。作者还感谢金立中的贡献。
Authors' Addresses
作者地址
Pranjal Kumar Dutta Alcatel-Lucent 701 E. Middlefield Road Mountain View, California 94043 United States
美国加利福尼亚州米德尔菲尔德山景路东701号帕兰贾尔·库马尔·杜塔阿尔卡特-朗讯94043
EMail: pranjal.dutta@alcatel-lucent.com
EMail: pranjal.dutta@alcatel-lucent.com
Matthew Bocci Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom
Matthew Bocci Alcatel-Lucent Voyager Place，英国伯克斯市梅登黑德Shoppenivers路SL6 2PJ
EMail: matthew.bocci@alcatel-lucent.com
EMail: matthew.bocci@alcatel-lucent.com
Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, Colorado 80112 United States
美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室卢卡·马蒂尼思科系统公司，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com