Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 7307 Huawei Technology
Category: Standards Track K. Raza
ISSN: 2070-1721 C. Zhou
Cisco Systems
L. Fang
Microsoft
L. Li
China Mobile
D. King
Old Dog Consulting
July 2014
Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 7307 Huawei Technology
Category: Standards Track K. Raza
ISSN: 2070-1721 C. Zhou
Cisco Systems
L. Fang
Microsoft
L. Li
China Mobile
D. King
Old Dog Consulting
July 2014
LDP Extensions for Multi-Topology
多拓扑的LDP扩展
Abstract
摘要
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.
IP网络中支持多拓扑（MT）路由，并使用MT感知IGP。为了在多协议标签交换（MPLS）标签分发协议（LDP）网络中提供MT路由，需要新的扩展。
This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.
本文档描述了在MPLS环境中支持MT路由所需的LDP协议扩展。
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/rfc7307.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7307.
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 ....................................................4
2. Terminology .....................................................4
3. Signaling Extensions ............................................5
3.1. Topology-Scoped Forwarding Equivalence Class (FEC) .........5
3.2. New Address Families: MT IP ................................5
3.3. LDP FEC Elements with MT IP AF .............................6
3.4. IGP MT-ID Mapping and Translation ..........................7
3.5. LDP MT Capability Advertisement ............................7
3.5.1. Protocol Extension ..................................7
3.5.2. Procedures ..........................................9
3.6. Label Spaces ..............................................10
3.7. Reserved MT-ID Values .....................................10
4. MT Applicability on FEC-Based Features .........................10
4.1. Typed Wildcard FEC Element ................................10
4.2. Signaling LDP Label Advertisement Completion ..............11
4.3. LSP Ping ..................................................11
4.3.1. New FEC Sub-Types ..................................11
4.3.2. MT LDP IPv4 FEC Sub-TLV ............................12
4.3.3. MT LDP IPv6 FEC Sub-TLV ............................13
4.3.4. Operation Considerations ...........................13
5. Error Handling .................................................14
5.1. MT Error Notification for Invalid Topology ID .............14
6. Backwards Compatibility ........................................14
7. MPLS Forwarding in MT ..........................................14
8. Security Considerations ........................................14
9. IANA Considerations ............................................15
10. Manageability Considerations ..................................17
10.1. Control of Function and Policy ...........................17
10.2. Information and Data Models ..............................17
10.3. Liveness Detection and Monitoring ........................17
10.4. Verify Correct Operations ................................17
10.5. Requirements on Other Protocols ..........................17
10.6. Impact on Network Operations .............................17
11. Contributors ..................................................18
12. Acknowledgements ..............................................19
13. References ....................................................19
13.1. Normative References .....................................19
13.2. Informative References ...................................19
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Signaling Extensions ............................................5
3.1. Topology-Scoped Forwarding Equivalence Class (FEC) .........5
3.2. New Address Families: MT IP ................................5
3.3. LDP FEC Elements with MT IP AF .............................6
3.4. IGP MT-ID Mapping and Translation ..........................7
3.5. LDP MT Capability Advertisement ............................7
3.5.1. Protocol Extension ..................................7
3.5.2. Procedures ..........................................9
3.6. Label Spaces ..............................................10
3.7. Reserved MT-ID Values .....................................10
4. MT Applicability on FEC-Based Features .........................10
4.1. Typed Wildcard FEC Element ................................10
4.2. Signaling LDP Label Advertisement Completion ..............11
4.3. LSP Ping ..................................................11
4.3.1. New FEC Sub-Types ..................................11
4.3.2. MT LDP IPv4 FEC Sub-TLV ............................12
4.3.3. MT LDP IPv6 FEC Sub-TLV ............................13
4.3.4. Operation Considerations ...........................13
5. Error Handling .................................................14
5.1. MT Error Notification for Invalid Topology ID .............14
6. Backwards Compatibility ........................................14
7. MPLS Forwarding in MT ..........................................14
8. Security Considerations ........................................14
9. IANA Considerations ............................................15
10. Manageability Considerations ..................................17
10.1. Control of Function and Policy ...........................17
10.2. Information and Data Models ..............................17
10.3. Liveness Detection and Monitoring ........................17
10.4. Verify Correct Operations ................................17
10.5. Requirements on Other Protocols ..........................17
10.6. Impact on Network Operations .............................17
11. Contributors ..................................................18
12. Acknowledgements ..............................................19
13. References ....................................................19
13.1. Normative References .....................................19
13.2. Informative References ...................................19
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. It would be advantageous for Communications Service Providers (CSPs) to support an MPLS Multi-Topology (MPLS-MT) environment. The benefits of MPLS-MT technology are features for various network scenarios, including:
IP网络中支持多拓扑（MT）路由，并使用MT感知IGP。通信服务提供商（CSP）支持MPLS多拓扑（MPLS-MT）环境将是有利的。MPLS-MT技术的优点是适用于各种网络场景的功能，包括：
o A CSP may want to assign varying Quality of Service (QoS) profiles to different traffic classes, based on a specific topology in an MT routing network;
o CSP可能希望基于MT路由网络中的特定拓扑将不同的服务质量（QoS）简档分配给不同的业务类别；
o Separate routing and MPLS domains may be used to isolate multicast and IPv6 islands within the backbone network;
o 单独的路由和MPLS域可用于隔离主干网内的多播和IPv6孤岛；
o Specific IP address space could be routed across an MT based on security or operational isolation requirements;
o 基于安全或操作隔离要求，特定IP地址空间可以在MT上路由；
o Low-latency links could be assigned to an MT for delay-sensitive traffic;
o 低延迟链路可分配给MT，用于延迟敏感业务；
o Management traffic may be divided from customer traffic using different MTs utilizing separate links, thus ensuring that management traffic is separated from customer traffic.
o 可以使用不同的MTs（使用单独的链路）将管理流量与客户流量分开，从而确保管理流量与客户流量分开。
This document describes the Label Distribution Protocol (LDP) procedures and protocol extensions required to support MT routing in an MPLS environment.
本文档描述了在MPLS环境中支持MT路由所需的标签分发协议（LDP）过程和协议扩展。
This document defines two new Forwarding Equivalence Class (FEC) types for use in Label Switched Path (LSP) ping [RFC4379].
本文档定义了两种新的转发等价类（FEC）类型，用于标签交换路径（LSP）ping[RFC4379]。
This document uses MPLS terminology defined in [RFC5036]. Additional terms are defined below:
本文件使用[RFC5036]中定义的MPLS术语。其他术语定义如下：
o MT-ID: A 16-bit value used to represent the Multi-Topology ID.
o MT-ID：用于表示多拓扑ID的16位值。
o Default MT Topology: A topology that is built using the MT-ID default value of 0.
o 默认MT拓扑：使用MT-ID默认值0构建的拓扑。
o MT Topology: A topology that is built using the corresponding MT-ID.
o MT拓扑：使用相应的MT-ID构建的拓扑。
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]中所述进行解释。
LDP assigns and binds a label to a FEC, where a FEC is a list of one or more FEC elements. To set up LSPs for unicast IP routing paths, LDP assigns local labels for IP prefixes and advertises these labels to its peers so that an LSP is set up along the routing path. To set up MT LSPs for IP prefixes under a given topology scope, the LDP prefix-related FEC element must be extended to include topology information. This implies that the MT-ID becomes an attribute of the prefix-related FEC element, and all FEC-Label binding operations are performed under the context of a given topology (MT-ID).
LDP将标签分配并绑定到FEC，其中FEC是一个或多个FEC元素的列表。为了为单播IP路由路径设置LSP，LDP为IP前缀分配本地标签，并向其对等方播发这些标签，以便沿路由路径设置LSP。要为给定拓扑范围下的IP前缀设置MT LSP，必须扩展与LDP前缀相关的FEC元素以包含拓扑信息。这意味着MT-ID成为前缀相关FEC元素的属性，并且所有FEC标签绑定操作都在给定拓扑（MT-ID）的上下文下执行。
The following section ("New Address Families: MT IP") defines the extension required to bind the prefix-related FEC to a topology.
以下部分（“新地址系列：MT IP”）定义了将前缀相关FEC绑定到拓扑所需的扩展。
Section 2.1 of the LDP base specification [RFC5036] defines the Address Prefix FEC element. The Prefix encoding is defined for a given "Address Family" (AF), and has length (in bits) specified by the "PreLen" field.
LDP基本规范[RFC5036]第2.1节定义了地址前缀FEC元素。前缀编码是为给定的“地址族”（AF）定义的，其长度（以位为单位）由“PreLen”字段指定。
To extend IP address families for MT, two new Address Families named "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes within a topology scope.
为了扩展MT的IP地址族，使用两个名为“MT IP”和“MT IPv6”的新地址族在拓扑范围内指定IPv4和IPv6前缀。
The format of data associated with these new Address Families is described below:
与这些新地址族关联的数据格式如下所述：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MT IP Address Family Format
图1:MT IP地址系列格式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MT IPv6 Address Family Format
图2:MT IPv6地址族格式
Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and "MT IPv6" AF respectively, and the field "MT-ID" corresponds to the 16-bit Topology ID for a given address.
其中，“IP地址”分别是“MT IP”和“MT IPv6”AF的IPv4和IPv6地址/前缀，字段“MT-ID”对应于给定地址的16位拓扑ID。
The definition and usage for the remaining fields in the FEC elements are as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to the default topology and MUST be ignored on receipt so as to not cause any conflict/confusion with existing non-MT procedures.
FEC元素中其余字段的定义和用法与IP/IPv6 AF的定义相同。MT-ID 0的值对应于默认拓扑，在收到时必须忽略，以免与现有的非MT过程产生任何冲突/混淆。
The defined FEC elements with "MT IP" Address Family can be used in any LDP message and procedures that currently specify and allow the use of FEC elements with IP/IPv6 Address Family.
定义的具有“MT IP”地址族的FEC元素可用于当前指定并允许使用具有IP/IPv6地址族的FEC元素的任何LDP消息和过程。
The following section specifies the format extensions of the existing LDP FEC elements to support MT. The "Address Family" of these FEC elements will be set to "MT IP" or "MT IPv6".
下节规定了现有LDP FEC元素的格式扩展以支持MT。这些FEC元素的“地址系列”将设置为“MT IP”或“MT IPv6”。
The MT Prefix FEC element encoding is as follows:
MT前缀FEC元素编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MT Prefix FEC Element Format
图3:MT前缀FEC元素格式
The MT Typed Wildcard FEC element encoding is as follows:
MT类型的通配符FEC元素编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | MT-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MT Typed Wildcard FEC Element
图4:MT类型的通配符FEC元素
The above format can be used for any LDP FEC element that allows use of the IP/IPv6 Address Family. In the scope of this document, the allowed "FEC Type" in a MT Typed Wildcard FEC element is the Prefix FEC element.
上述格式可用于允许使用IP/IPv6地址系列的任何LDP FEC元素。在本文档的范围内，MT类型的通配符FEC元素中允许的“FEC类型”是前缀FEC元素。
The non-reserved non-special IGP MT-ID values can be used and carried in LDP without the need for translation. However, there is a need for translating reserved or special IGP MT-ID values to corresponding LDP MT-IDs. The assigned, unassigned, and special LDP MT-ID values have been assigned as described in Section 9 ("IANA Considerations").
非保留的非特殊IGP MT-ID值可以在LDP中使用和携带，而无需翻译。然而，需要将保留的或特殊的IGP MT-ID值转换为相应的LDP MT ID。已分配、未分配和特殊LDP MT-ID值已按照第9节（“IANA注意事项”）中所述进行分配。
How future LDP MT-ID values are allocated is outside the scope of this document. Instead, a separate document will be created to detail the allocation policy and process for requesting new MT-ID values.
如何分配未来LDP MT-ID值不在本文件范围内。相反，将创建一个单独的文档来详细说明分配策略和请求新MT-ID值的过程。
We specify a new LDP capability, named "Multi-Topology (MT)", which is defined in accordance with the LDP capability guidelines [RFC5561]. The LDP "MT" capability can be advertised by an LDP speaker to its peers either during the LDP session initialization or after the LDP session is set up. The advertisement is to announce the capability of the Label Switching Router (LSR) to support MT for the given IP address family. An LDP speaker MUST NOT send messages containing MT FEC elements unless the peer has said it can handle it.
我们指定了一种新的LDP能力，名为“多拓扑（MT）”，它是根据LDP能力指南[RFC5561]定义的。LDP“MT”能力可由LDP演讲者在LDP会话初始化期间或在LDP会话建立之后向其对等方通告。广告将宣布标签交换路由器（LSR）支持给定IP地址系列的MT的能力。LDP演讲者不得发送包含MT FEC元素的消息，除非对方表示可以处理。
The MT capability is specified using the Multi-Topology Capability TLV. The Multi-Topology Capability TLV format is in accordance with the LDP capability guidelines as defined in [RFC5561]. To be able to
MT能力是使用多拓扑能力TLV指定的。多拓扑能力TLV格式符合[RFC5561]中定义的LDP能力指南。能够
specify IP address family, the capability-specific data (i.e., the "Capability Data" field of Capability TLV) is populated using the "Typed Wildcard FEC element" as defined in [RFC5918].
指定IP地址系列，使用[RFC5918]中定义的“类型化通配符FEC元素”填充特定于能力的数据（即能力TLV的“能力数据”字段）。
The format of the Multi-Topology Capability TLV is as follows:
多拓扑能力TLV的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Multi-Topology Cap.(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
~ Typed Wildcard FEC element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Multi-Topology Cap.(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
~ Typed Wildcard FEC element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Multi-Topology Capability TLV Format
图5：多拓扑能力TLV格式
Where:
哪里：
o U-bit: MUST be 1 so that the TLV will be silently ignored by a recipient if it is unknown, according to the rules of [RFC5036].
o U位：必须为1，以便根据[RFC5036]的规则，如果TLV未知，则收件人将自动忽略它。
o F-bit: MUST be 0 as per Section 3 ("Specifying Capabilities in LDP Messages") of LDP Capabilities [RFC5561].
o 根据LDP功能[RFC5561]第3节（“在LDP消息中指定功能”），F位必须为0。
o Multi-Topology Capability: Capability TLV type (IANA assigned)
o 多拓扑能力：能力TLV类型（IANA分配）
o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be set to 0 or 1 in dynamic "Capability" message to advertise or withdraw the capability, respectively.
o S位：如果在LDP“初始化”消息中使用，则必须为1。可在动态“能力”消息中设置为0或1，以分别公布或撤回能力。
o Typed Wildcard FEC element(s): One or more elements specified as the "Capability data".
o 类型化通配符FEC元素：指定为“能力数据”的一个或多个元素。
o Length: length of Value field, starting from the S-bit, in octets.
o 长度：值字段的长度，从S位开始，以八位字节为单位。
o The encoding of the Typed Wildcard FEC element, as defined in [RFC5918], is defined in Section 4.1 ("Typed Wildcard FEC element") of this document. The MT-ID field of the MT Typed Wildcard FEC element MUST be set to "Wildcard Topology" when it is specified in the MT Capability TLV.
o [RFC5918]中定义的类型化通配符FEC元素的编码在本文件第4.1节（“类型化通配符FEC元素”）中定义。在MT能力TLV中指定MT类型的通配符FEC元素的MT-ID字段时，必须将其设置为“通配符拓扑”。
To announce its MT capability for an IP address family, LDP FEC type, and Multi-Topology, an LDP speaker sends an "MT Capability" including the exact Typed Wildcard FEC element with the corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "Prefix"), and corresponding "MT-ID". To announce its MT capability for both the IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi-Topologies, an LDP speaker sends an "MT Capability" with one or more MT Typed FEC elements in it.
为了宣布其针对IP地址系列、LDP FEC类型和多拓扑的MT能力，LDP扬声器发送“MT能力”，包括确切类型的通配符FEC元素和相应的“AddressFamily”字段（即，对于IPv4设置为“MT IP”，对于IPv6地址系列设置为“MT IPv6”）、相应的“FEC类型”字段（即，设置为“前缀”）和相应的“MT-ID”。要宣布其对IPv4和IPv6地址系列、多个FEC类型或多个多拓扑的MT能力，LDP扬声器发送一个包含一个或多个MT类型FEC元素的“MT能力”。
o The capability for supporting multi-topology in LDP can be advertised during LDP session initialization stage by including the LDP MT capability TLV in LDP Initialization message. After an LDP session is established, the MT capability can also be advertised or withdrawn using the Capability message (only if the "Dynamic Capability Announcement" capability [RFC5561] has already been successfully negotiated).
o 通过在LDP初始化消息中包含LDP MT能力TLV，可以在LDP会话初始化阶段公布LDP中支持多拓扑的能力。在建立LDP会话后，还可以使用能力消息通告或撤回MT能力（仅当“动态能力公告”能力[RFC5561]已成功协商时）。
o If an LSR has not advertised MT capability, its peer MUST NOT send to this LSR any LDP messages with FEC elements that include an MT identifier.
o 如果LSR没有公布MT能力，则其对等方不得向该LSR发送包含MT标识符的FEC元素的任何LDP消息。
o If an LSR is changed from non-MT capable to MT capable, it sets the S-bit in the MT capability TLV and advertises via the Capability message (if it supports Dynamic Capability Announcement). The existing LSP is treated as an LSP for default MT (ID 0).
o 如果LSR从不支持MT更改为支持MT，它将在MT能力TLV中设置S位，并通过能力消息进行播发（如果它支持动态能力公告）。现有LSP被视为默认MT（ID 0）的LSP。
o If an LSR is changed from LDP-MT capable to non-MT capable, it initiates withdrawal of all label mapping for existing LSPs of all non-default MTs. It also cleans up all the LSPs of all non-default MTs locally. Then, it clears the S-bit in the MT capability TLV and advertises via the Capability message (if it supports Dynamic Capability Announcement). When an LSR knows the peer node is changed from LDP-MT capable to non-MT capable, it cleans up all the LSPs of all non-default MTs locally and initiates withdrawal of all label mapping for existing LSPs of all non-default MTs. Each side of the node sends a label release to its peer once it receives the label release messages even though each side has already cleaned up all the LSPs locally.
o 如果LSR从LDP-MT功能更改为非MT功能，它将启动所有非默认MT的现有LSP的所有标签映射的撤销。它还将本地清理所有非默认MT的所有LSP。然后，它清除MT能力TLV中的S位，并通过能力消息进行播发（如果它支持动态能力公告）。当LSR知道对等节点从LDP-MT能力更改为非MT能力时，它在本地清除所有非默认MT的所有LSP，并启动所有非默认MT的现有LSP的所有标签映射的撤销。节点的每一侧在收到标签释放消息后向其对等方发送标签释放，即使每一侧已经在本地清除了所有LSP。
o If an LSR does not support "Dynamic Capability Announcement", it MUST reset the session with its peer whenever the LSR changes its local capability with regards to supporting LDP MT.
o 如果LSR不支持“动态能力公告”，则每当LSR改变其本地能力以支持LDP MT时，它必须重置与其对等方的会话。
o If an LSR is changed from IGP-MT capable to non-MT capable, it may wait until the routes update to withdraw the FEC and release the label mapping for existing LSPs of a specific MT.
o 如果LSR从具有IGP-MT能力更改为不具有MT能力，则它可以等待路由更新以撤回FEC并释放特定MT的现有LSP的标签映射。
The use of multiple topologies for LDP does not require different label spaces for each topology. An LSR can use the same label space for all MT FECs as for the default topology.
LDP使用多个拓扑并不需要每个拓扑使用不同的标签空间。LSR可以为所有MT FEC使用与默认拓扑相同的标签空间。
Similarly, signaling for different topologies can and should be done within a single LDP session.
类似地，不同拓扑的信令可以而且应该在单个LDP会话中完成。
Certain MT topologies are assigned to serve predetermined purposes.
某些MT拓扑被分配用于预定目的。
In Section 9 ("IANA Considerations"), this document defines a new IANA registry "MPLS Multi-Topology Identifiers" to keep LDP MT-ID reserved values.
在第9节（“IANA注意事项”）中，本文件定义了一个新的IANA注册表“MPLS多拓扑标识符”，以保留LDP MT-ID保留值。
If an LSR receives a FEC element with an "MT-ID" value that is "Unassigned" for future use (and not IANA allocated yet), the LSR MUST abort the processing of the FEC element and SHOULD send a notification message with status code "Invalid Topology ID" to the sender.
如果LSR接收到具有“MT-ID”值的FEC元素，且该值为“未分配”以供将来使用（且尚未分配IANA），则LSR必须中止FEC元素的处理，并应向发送方发送状态代码为“无效拓扑ID”的通知消息。
[RFC5918] extends base LDP and defines the Typed Wildcard FEC element framework. The Typed Wildcard FEC element can be used in any LDP message to specify a wildcard operation/action for a given type of FEC.
[RFC5918]扩展了基本LDP并定义了类型化通配符FEC元素框架。类型化通配符FEC元素可在任何LDP消息中用于为给定类型的FEC指定通配符操作/操作。
The MT extensions defined in this document do not require any extension to procedures for the Typed Wildcard FEC element, and these procedures apply as is to MT wildcarding. The MT extensions, though, allow use of "MT IP" or "MT IPv6" in the Address Family field of the Typed Wildcard FEC element in order to use wildcard operations in the context of a given topology. The use of MT-scoped address family also allows us to specify MT-ID in these operations.
本文档中定义的MT扩展不需要对类型化通配符FEC元素的过程进行任何扩展，这些过程适用于MT通配符。但是，MT扩展允许在类型化通配符FEC元素的地址族字段中使用“MT IP”或“MT IPv6”，以便在给定拓扑的上下文中使用通配符操作。使用MT作用域地址系列还允许我们在这些操作中指定MT-ID。
The defined format in Section 4.1 ("Typed Wildcard FEC element") allows an LSR to perform wildcard FEC operations under the scope of a topology. If an LSR wishes to perform a wildcard operation that applies to all topologies, it can use a "Wildcard Topology" MT-ID.
第4.1节（“类型化通配符FEC元素”）中定义的格式允许LSR在拓扑范围内执行通配符FEC操作。如果LSR希望执行适用于所有拓扑的通配符操作，则可以使用“通配符拓扑”MT-ID。
For example, upon local de-configuration of a topology "x", an LSR may send a typed wildcard Label Withdraw message with MT-ID "x" to withdraw all its labels from the peer that advertised under the scope of topology "x". Additionally, upon a global configuration change, an LSR may send a typed wildcard Label Withdraw message with the MT-ID set to "Wildcard Topology" to withdraw all its labels under all topologies from the peer.
例如，在拓扑“x”的本地取消配置时，LSR可以发送具有MT-ID“x”的类型化通配符标签撤销消息，以从拓扑“x”范围下播发的对等方撤销其所有标签。此外，在全局配置更改时，LSR可以发送类型化的通配符标签撤销消息，将MT-ID设置为“通配符拓扑”，以从对等方撤销其所有拓扑下的所有标签。
[RFC5919] specifies extensions and procedures for an LDP speaker to signal its convergence for a given FEC type towards a peer. The procedures defined in [RFC5919] apply as they are to an MT FEC element. This allows an LDP speaker to signal its IP convergence using Typed Wildcard FEC element, and its MT IP convergence per topology using a MT Typed Wildcard FEC element.
[RFC5919]指定LDP扬声器的扩展和程序，以向对等方发出给定FEC类型收敛的信号。[RFC5919]中定义的程序适用于MT FEC元件。这允许LDP说话者使用类型化通配符FEC元素来表示其IP收敛，并使用MT类型化通配符FEC元素来表示其每个拓扑的MT IP收敛。
[RFC4379] defines procedures to detect data-plane failures in MPLS LSPs via LSP ping. That specification defines a "Target FEC Stack" TLV that describes the FEC stack being tested. This TLV is sent in an MPLS Echo Request message towards the LSP's egress LSR and is forwarded along the same data path as other packets belonging to the FEC.
[RFC4379]定义了通过LSP ping检测MPLS LSP中数据平面故障的过程。该规范定义了描述正在测试的FEC堆栈的“目标FEC堆栈”TLV。该TLV在MPLS Echo请求消息中发送到LSP的出口LSR，并沿着与属于FEC的其他分组相同的数据路径转发。
"Target FEC Stack" TLV contains one or more sub-TLVs pertaining to different FEC types. Section 3.2 of [RFC4379] defines the Sub-Types and format of the FEC. To support LSP ping for MT LDP LSPs, this document defines the following extensions to [RFC4379].
“目标FEC堆栈”TLV包含一个或多个子TLV，属于不同的FEC类型。[RFC4379]第3.2节定义了FEC的子类型和格式。为了支持MT LDP LSP的LSP ping，本文档定义了[RFC4379]的以下扩展。
We define two new FEC types for LSP ping:
我们为LSP ping定义了两种新的FEC类型：
o MT LDP IPv4 FEC
o MT-LDP-IPv4-FEC
o MT LDP IPv6 FEC
o MT-LDP-IPv6-FEC
We also define the following new sub-types for sub-TLVs to specify these FECs in the "Target FEC Stack" TLV of [RFC4379]:
我们还为子TLV定义了以下新的子类型，以在[RFC4379]的“目标FEC堆栈”TLV中指定这些FEC：
Sub-Type Length Value Field
-------- ------ -----------------
31 8 MT LDP IPv4 prefix
32 20 MT LDP IPv6 prefix
Sub-Type Length Value Field
-------- ------ -----------------
31 8 MT LDP IPv4 prefix
32 20 MT LDP IPv6 prefix
Figure 6: New Sub-Types for Sub-TLVs
图6：子TLV的新子类型
The rules and procedures of using these sub-TLVs in an MPLS echo request message are the same as defined for LDP IPv4/IPv6 FEC sub-TLV types in [RFC4379].
在MPLS回送请求消息中使用这些子TLV的规则和过程与[RFC4379]中为LDP IPv4/IPv6 FEC子TLV类型定义的规则和过程相同。
The format of the "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC Stack" [RFC4379] is:
“目标FEC堆栈”[RFC4379]中使用的“MT LDP IPv4 FEC”子TLV的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 31 (MT LDP IPv4 FEC) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 31 (MT LDP IPv4 FEC) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MT LDP IPv4 FEC Sub-TLV
图7:MT LDP IPv4 FEC子TLV
The format of this sub-TLV is similar to the LDP IPv4 FEC sub-TLV as defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix Length" fields, this new sub-TLV also specifies the MT-ID (Multi-Topology ID). The Length for this sub-TLV is 5.
此子TLV的格式类似于[RFC4379]中定义的LDP IPv4 FEC子TLV。除了“IPv4前缀”和“前缀长度”字段外，此新子TLV还指定MT-ID（多拓扑ID）。该子TLV的长度为5。
The term "Must Be Zero" (MBZ) is used in object descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt.
术语“必须为零”（MBZ）用于保留字段的对象描述中。这些字段在发送时必须设置为零，在接收时忽略。
The format of the "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC Stack" [RFC4379] is:
“目标FEC堆栈”[RFC4379]中使用的“MT LDP IPv6 FEC”子TLV的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 (MT LDP IPv6 FEC) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 (MT LDP IPv6 FEC) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MT LDP IPv6 FEC Sub-TLV
图8:MT LDP IPv6 FEC子TLV
The format of this sub-TLV is similar to the LDP IPv6 FEC sub-TLV as defined in [RFC4379]. In addition to the "IPv6 prefix" and "Prefix Length" fields, this new sub-TLV also specifies the MT-ID (Multi-Topology ID). The Length for this sub-TLV is 17.
此子TLV的格式类似于[RFC4379]中定义的LDP IPv6 FEC子TLV。除了“IPv6前缀”和“前缀长度”字段外，这个新的子TLV还指定MT-ID（多拓扑ID）。该子TLV的长度为17。
To detect data-plane failures using LSP ping for a specific topology, the router will initiate an LSP ping request with the target FEC stack TLV containing the LDP MT IP Prefix Sub-TLV in the Echo Request packet. The Echo Request packet is sent with the label bound to the IP Prefix in the topology. Once the Echo Request packet reaches the target router, it will process the packet and perform checks for the LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described in [RFC4379] and respond according to the processing rules in [RFC4379]. For the case that the LSP ping with return path is not specified, the reply packet must go through the default topology instead of the topology where the Echo Request goes through.
为了使用针对特定拓扑的LSP ping来检测数据平面故障，路由器将启动LSP ping请求，目标FEC堆栈TLV在Echo请求分组中包含LDP MT IP前缀子TLV。发送回显请求数据包时，标签绑定到拓扑中的IP前缀。一旦回声请求数据包到达目标路由器，它将处理该数据包，并按照[RFC4379]中所述检查目标FEC堆栈中存在的LDP MT IP前缀子TLV，并根据[RFC4379]中的处理规则进行响应。对于未指定带返回路径的LSP ping的情况，应答数据包必须通过默认拓扑，而不是回送请求通过的拓扑。
It should be noted that the existing MIB modules for an MPLS LSR [RFC3813] and MPLS LDP managed objects [RFC3815] do not provide the necessary information to support the extensions in this document. For example, the absence of the MT-ID as an index into the MIB modules means that there is no way to disambiguate different topology instances.
应该注意的是，MPLS LSR[RFC3813]和MPLS LDP管理对象[RFC3815]的现有MIB模块没有提供支持本文档中扩展的必要信息。例如，没有MT-ID作为MIB模块的索引意味着无法消除不同拓扑实例的歧义。
The extensions defined in this document utilize the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for a session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all multi-topology label mappings learned via the session.
本文件中定义的扩展使用[RFC5036]中定义的现有LDP错误处理。如果LSR从会话的对等方接收到错误通知，它将通过关闭会话的TCP传输连接并丢弃通过会话学习到的所有多拓扑标签映射来终止LDP会话。
An LSR should respond with an "Invalid Topology ID" status code in the LDP Notification message when it receives an LDP message with a FEC element specifying an MT-ID that is not locally known or not supported. The LSR MUST also discard the entire message before sending the Notification message.
当LSR接收到LDP消息时，其应在LDP通知消息中使用“无效拓扑ID”状态码进行响应，该LDP消息中的FEC元素指定了本地未知或不受支持的MT-ID。LSR还必须在发送通知消息之前丢弃整个消息。
The MPLS-MT solution is backwards compatible with existing LDP enhancements defined in [RFC5036], including message authenticity, integrity of message, and topology loop detection.
MPLS-MT解决方案与[RFC5036]中定义的现有LDP增强功能向后兼容，包括消息真实性、消息完整性和拓扑循环检测。
The legacy node that does not support MT should not receive any MT-related LDP messages. In case bad things happen, according to [RFC5036], processing of such messages should be aborted.
不支持MT的传统节点不应接收任何与MT相关的LDP消息。根据[RFC5036]，如果发生了不好的事情，则应中止对此类消息的处理。
Although forwarding is out of the scope of this document, we include some forwarding consideration for informational purposes here.
虽然转发不在本文档的范围内，但出于信息目的，我们在此提供了一些转发注意事项。
The specified signaling mechanisms allow all the topologies to share the platform-specific label space. This feature allows the existing data-plane techniques to be used. Also, there is no way for the data plane to associate a received packet with any one topology, meaning that topology-specific label spaces cannot be used.
指定的信令机制允许所有拓扑共享特定于平台的标签空间。此功能允许使用现有的数据平面技术。此外，数据平面无法将接收到的数据包与任何一个拓扑关联，这意味着不能使用特定于拓扑的标签空间。
The use of MT over existing MPLS solutions does not offer any specific security benefit.
在现有MPLS解决方案上使用MT不会带来任何特定的安全好处。
General LDP communication security threats and how these may be mitigated are described in [RFC5036]; these threats include:
[RFC5036]中描述了一般LDP通信安全威胁以及如何缓解这些威胁；这些威胁包括：
o spoofing
o 欺骗
o privacy
o 隐私
o denial of service
o 拒绝服务
For further discussion regarding possible LDP communication threats and mitigation techniques, see [RFC5920].
有关可能的LDP通信威胁和缓解技术的进一步讨论，请参阅[RFC5920]。
This document introduces the following new protocol elements, which have been assigned by IANA:
本文件介绍了IANA分配的以下新协议元素：
o New LDP Capability TLV: "Multi-Topology Capability" TLV (0x050C) from the LDP Parameters registry "TLV Type Name Space".
o 新的LDP功能TLV：来自LDP参数注册表“TLV类型名称空间”的“多拓扑功能”TLV（0x050C）。
o New Status Code: "Invalid Topology ID" (0x00000031) from the LDP Parameters registry "Status Code Name Space").
o 新状态代码：LDP参数注册表“状态代码名称空间”中的“无效拓扑ID”（0x00000031）。
Registry:
Range/Value Description
-------------- ------------------------------
0x00000031 Invalid Topology ID
Registry:
Range/Value Description
-------------- ------------------------------
0x00000031 Invalid Topology ID
Figure 9: New Code Point for LDP Multi-Topology Extensions
图9:LDP多拓扑扩展的新码点
o New address families under the IANA registry "Address Family Numbers":
o IANA注册“地址系列号”下的新地址系列：
Number Description
-------- ------------------------------------
29 MT IP: Multi-Topology IP version 4
30 MT IPv6: Multi-Topology IP version 6
Number Description
-------- ------------------------------------
29 MT IP: Multi-Topology IP version 4
30 MT IPv6: Multi-Topology IP version 6
Figure 10: Address Family Numbers
图10：地址系列号
o New registry "MPLS Multi-Topology Identifiers".
o 新注册表“MPLS多拓扑标识符”。
This is a registry of the "Multiprotocol Label Switching Architecture (MPLS)" category.
这是“多协议标签交换体系结构（MPLS）”类别的注册。
The initial registrations and allocation policies for this registry are:
此注册表的初始注册和分配策略为：
Range/Value Purpose Reference
----------- ------------------------------------- ----------
0 Default/standard topology RFC 7307
1 IPv4 in-band management RFC 7307
2 IPv6 routing topology RFC 7307
3 IPv4 multicast topology RFC 7307
4 IPv6 multicast topology RFC 7307
5 IPv6 in-band management RFC 7307
6-3995 Unassigned for future IGP topologies RFC 7307
Assigned by Standards Action RFC 7307
3996-4095 Experimental RFC 7307
4096-65534 Unassigned for MPLS topologies RFC 7307
Assigned by Standards Action
65535 Wildcard Topology RFC 7307
Range/Value Purpose Reference
----------- ------------------------------------- ----------
0 Default/standard topology RFC 7307
1 IPv4 in-band management RFC 7307
2 IPv6 routing topology RFC 7307
3 IPv4 multicast topology RFC 7307
4 IPv6 multicast topology RFC 7307
5 IPv6 in-band management RFC 7307
6-3995 Unassigned for future IGP topologies RFC 7307
Assigned by Standards Action RFC 7307
3996-4095 Experimental RFC 7307
4096-65534 Unassigned for MPLS topologies RFC 7307
Assigned by Standards Action
65535 Wildcard Topology RFC 7307
Figure 11: MPLS Multi-Topology Identifier Registry
图11:MPLS多拓扑标识符注册表
o New Sub-TLV Types for LSP ping: The following new sub-type values under TLV type 1 (Target FEC Stack) have been registered from the "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry within the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
o LSP ping的新子TLV类型：TLV类型1（目标FEC堆栈）下的以下新子类型值已从“多协议标签交换（MPLS）标签交换路径（LSP）ping参数”注册表中的“TLV类型1、16和21的子TLV”子注册表中注册。
Sub-Type Value Field
-------- ------------------
31 MT LDP IPv4 prefix
32 MT LDP IPv6 prefix
Sub-Type Value Field
-------- ------------------
31 MT LDP IPv4 prefix
32 MT LDP IPv6 prefix
Figure 12: New Sub-TLV Types for LSP Ping
图12：LSP Ping的新子TLV类型
As highlighted at the end of Section 3.4 ("IGP MT-ID Mapping and Translation"), a new document will be created to detail the policy and process for allocating new MT-ID values.
如第3.4节（“IGP MT-ID映射和翻译”）末尾所述，将创建一份新文件，详细说明分配新MT-ID值的政策和流程。
There are capabilities that should be configurable to enable good manageability. One such example is to allow that the LDP Multi-Topology capability be enabled or disabled. It is assumed that the mapping of the LDP MT-ID and IGP MT-ID is manually configured on every router by default. If an automatic mapping between IGP MT-IDs and LDP MT-IDs is needed, there must be explicit configuration to do so.
有些功能应该是可配置的，以实现良好的可管理性。一个这样的示例是允许启用或禁用LDP多拓扑能力。假设LDP MT-ID和IGP MT-ID的映射默认在每个路由器上手动配置。如果需要在IGP MT ID和LDP MT ID之间进行自动映射，则必须有明确的配置。
Any extensions that may be required for existing MIBs are beyond the scope of this document.
现有MIB可能需要的任何扩展超出了本文档的范围。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements.
本文件中定义的机制并不意味着任何新的活性检测和监控要求。
In order to debug an LDP-MT-enabled network, it may be necessary to associate between the LDP label advertisement and the IGP routing advertisement. In this case, the user MUST understand the mapping mechanism to convert the IGP MT-ID to the LDP MT-ID. The method and type of mapping mechanism is out of the scope of this document.
为了调试支持LDP-MT的网络，可能需要在LDP标签广告和IGP路由广告之间进行关联。在这种情况下，用户必须了解将IGP MT-ID转换为LDP MT-ID的映射机制。映射机制的方法和类型不在本文档的范围内。
If the LDP MT-ID has an implicit dependency on IGP MT-ID, then the corresponding IGP MT features will need to be supported.
如果LDP MT-ID对IGP MT-ID具有隐式依赖性，则需要支持相应的IGP MT特性。
Mechanisms defined in this document do not have any impact on network operations.
本文档中定义的机制对网络操作没有任何影响。
Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 USA
宁苏塔塔通信公司美国德克萨斯州普莱诺费尔伯恩市2613号，邮编75082
EMail: ning.so@tatacommunications.com
EMail: ning.so@tatacommunications.com
Raveendra Torvi Juniper Networks 10 Technology Park Drive Westford, MA 01886-3140 US
美国马萨诸塞州韦斯特福德科技园大道10号Ravendra Torvi Juniper Networks美国01886-3140
EMail: rtorvi@juniper.net
EMail: rtorvi@juniper.net
Huaimo Chen Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US
美国马萨诸塞州阿克顿市纳戈科技园125号华为技术中心，邮编01719
Emily Chen 2717 Seville Blvd, Apt. 1205 Clearwater, FL 33764 US
美国佛罗里达州克利尔沃特市塞维利亚大道2717号1205室，邮编33764
EMail: emily.chen220@gmail.com
EMail: emily.chen220@gmail.com
Chen Li China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China
陈丽中国移动北京寻乌区西边门内大街53A 01719
EMail: lichenyj@chinamobile.com
EMail: lichenyj@chinamobile.com
Lu Huang China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China
中国移动北京寻乌区西边门内大街53A路黄路01719号
The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai, Pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel, Alia Atlas, and Loa Anderson for their valuable comments on this document.
作者感谢Dan Tappan、Nabil Bitar、Huang Xin、Eric Rosen、IJsbrand Wijnands、Dimitri Papadimitriou、Yiqun Chai、Pranjal Dutta、George Swallow、Curtis Villamizar、Adrian Farrel、Alia Atlas和Loa Anderson对本文件的宝贵意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 59182010年8月。
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, August 2010.
[RFC5919]Asati，R.，Mohapatra，P.，Chen，E.，和B.Thomas，“信号LDP标签广告完成”，RFC 5919，2010年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. Srinivasan, C., Viswanathan, A., and T. Nadeau,
[RFC3813]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月。斯里尼瓦桑，C.，维斯瓦纳坦，A.，和T.纳多，
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815]Cucchiara，J.，Sjostrand，H.，和J.Luciani，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月。
Authors' Addresses
作者地址
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US EMail: quintin.zhao@huawei.com
Quintin Zhao华为技术125 Nagog Technology Park Acton，MA 01719美国电子邮件：Quintin。zhao@huawei.com
Kamran Raza Cisco Systems 2000 Innovation Drive Kanata, ON K2K-3E8 Canada EMail: skraza@cisco.com
Kamran Raza Cisco Systems 2000创新驱动卡纳塔，地址：K2K-3E8加拿大电子邮件：skraza@cisco.com
Chao Zhou Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US EMail: czhou@cisco.com
潮州思科系统有限公司马萨诸塞州博克斯伯勒市海狸溪路300号01719美国电子邮件：czhou@cisco.com
Luyuan Fang Microsoft 5600 148th Ave NE Redmond, WA 98052 US EMail: lufang@microsoft.com
卢元芳微软5600美国华盛顿州雷德蒙东北148大街98052电子邮件：lufang@microsoft.com
Lianyuan Li China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China EMail: lilianyuan@chinamobile.com
中国移动北京市寻乌区西边门内大街53A涟源里01719中国电子邮件：lilianyuan@chinamobile.com
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk
Daniel King老狗咨询电子邮件：daniel@olddog.co.uk