Internet Engineering Task Force (IETF) K. Shiomoto, Ed.
Request for Comments: 6107 NTT
Updates: 3477, 4206 A. Farrel, Ed.
Category: Standards Track Old Dog Consulting
ISSN: 2070-1721 February 2011
Internet Engineering Task Force (IETF) K. Shiomoto, Ed.
Request for Comments: 6107 NTT
Updates: 3477, 4206 A. Farrel, Ed.
Category: Standards Track Old Dog Consulting
ISSN: 2070-1721 February 2011
Procedures for Dynamically Signaled Hierarchical Label Switched Paths
动态信号分层标签交换路径的程序
Abstract
摘要
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.
在多协议标签交换（MPLS）或通用MPLS（GMPLS）网络中设置的标签交换路径（LSP）可用于形成链路，以承载这些网络或其他（客户端）网络中的流量。
Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process.
协议机制已经存在，以促进此类LSP的建立，并捆绑流量工程（TE）链路以减少路由协议的负载。本文档定义了对这些机制的扩展，以支持识别此类LSP的使用，并使TE链路端点能够在信令过程中被分配地址或无编号的标识符。
The mechanisms defined in this document deprecate the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206.
本文件中定义的机制不推荐将用作RFC 4206中所述编号TE链路的LSP的信令技术。
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/rfc6107.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6107.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 and Problem Statement ..............................3
1.1. Background .................................................4
1.1.1. Hierarchical LSPs ...................................4
1.1.2. LSP Stitching Segments ..............................5
1.1.3. Private Links .......................................5
1.1.4. Routing Adjacencies .................................5
1.1.5. Forwarding Adjacencies ..............................5
1.1.6. Client/Server Networks ..............................6
1.1.7. Link Bundles ........................................6
1.2. Desired Function ...........................................7
1.3. Existing Mechanisms ........................................7
1.3.1. LSP Setup ...........................................7
1.3.2. Routing Adjacency Establishment and Link
State Advertisement .................................7
1.3.3. TE Link Advertisement ...............................7
1.3.4. Configuration and Management Techniques .............8
1.3.5. Signaled Unnumbered FAs .............................8
1.3.6. Establishing Numbered FAs through Signaling
and Routing .........................................9
1.4. Overview of Required Extensions ...........................10
1.4.1. Efficient Signaling of Numbered FAs ................10
1.4.2. LSPs for Use as Private Links ......................10
1.4.3. Signaling an LSP for Use in Another Network ........10
1.4.4. Signaling an LSP for Use in a Link Bundle ..........11
1.4.5. Support for IPv4 and IPv6 ..........................11
1.4.6. Backward Compatibility .............................11
2. Overview of Solution ...........................................11
2.1. Common Approach for Numbered and Unnumbered Links .........11
2.2. LSP Usage Indication ......................................12
2.3. IGP Instance Identification ...............................12
2.4. Link Bundle Identification ................................12
1. Introduction and Problem Statement ..............................3
1.1. Background .................................................4
1.1.1. Hierarchical LSPs ...................................4
1.1.2. LSP Stitching Segments ..............................5
1.1.3. Private Links .......................................5
1.1.4. Routing Adjacencies .................................5
1.1.5. Forwarding Adjacencies ..............................5
1.1.6. Client/Server Networks ..............................6
1.1.7. Link Bundles ........................................6
1.2. Desired Function ...........................................7
1.3. Existing Mechanisms ........................................7
1.3.1. LSP Setup ...........................................7
1.3.2. Routing Adjacency Establishment and Link
State Advertisement .................................7
1.3.3. TE Link Advertisement ...............................7
1.3.4. Configuration and Management Techniques .............8
1.3.5. Signaled Unnumbered FAs .............................8
1.3.6. Establishing Numbered FAs through Signaling
and Routing .........................................9
1.4. Overview of Required Extensions ...........................10
1.4.1. Efficient Signaling of Numbered FAs ................10
1.4.2. LSPs for Use as Private Links ......................10
1.4.3. Signaling an LSP for Use in Another Network ........10
1.4.4. Signaling an LSP for Use in a Link Bundle ..........11
1.4.5. Support for IPv4 and IPv6 ..........................11
1.4.6. Backward Compatibility .............................11
2. Overview of Solution ...........................................11
2.1. Common Approach for Numbered and Unnumbered Links .........11
2.2. LSP Usage Indication ......................................12
2.3. IGP Instance Identification ...............................12
2.4. Link Bundle Identification ................................12
2.5. Backward Compatibility ....................................12
3. Mechanisms and Protocol Extensions .............................13
3.1. LSP_TUNNEL_INTERFACE_ID Object ............................13
3.1.1. Existing Definition and Usage ......................13
3.1.2. Unnumbered Links with Action Identification ........13
3.1.3. IPv4 Numbered Links with Action Identification .....16
3.1.4. IPv6 Numbered Links with Action Identification .....17
3.2. Target IGP Identification TLV .............................18
3.3. Component Link Identification TLV .........................19
3.3.1. Unnumbered Component Link Identification ...........20
3.3.2. IPv4 Numbered Component Link Identification ........20
3.3.3. IPv6 Numbered Component Link Identification ........21
3.4. Link State Advertisement ..................................21
3.5. Message Formats ...........................................22
3.6. Error Cases and Non-Acceptance ............................22
3.7. Backward Compatibility ....................................24
4. Security Considerations ........................................25
5. IANA Considerations ............................................25
5.1. New Class Types ...........................................25
5.2. Hierarchy Actions .........................................26
5.3. New Error Codes and Error Values ..........................26
6. Acknowledgements ...............................................27
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
2.5. Backward Compatibility ....................................12
3. Mechanisms and Protocol Extensions .............................13
3.1. LSP_TUNNEL_INTERFACE_ID Object ............................13
3.1.1. Existing Definition and Usage ......................13
3.1.2. Unnumbered Links with Action Identification ........13
3.1.3. IPv4 Numbered Links with Action Identification .....16
3.1.4. IPv6 Numbered Links with Action Identification .....17
3.2. Target IGP Identification TLV .............................18
3.3. Component Link Identification TLV .........................19
3.3.1. Unnumbered Component Link Identification ...........20
3.3.2. IPv4 Numbered Component Link Identification ........20
3.3.3. IPv6 Numbered Component Link Identification ........21
3.4. Link State Advertisement ..................................21
3.5. Message Formats ...........................................22
3.6. Error Cases and Non-Acceptance ............................22
3.7. Backward Compatibility ....................................24
4. Security Considerations ........................................25
5. IANA Considerations ............................................25
5.1. New Class Types ...........................................25
5.2. Hierarchy Actions .........................................26
5.3. New Error Codes and Error Values ..........................26
6. Acknowledgements ...............................................27
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Traffic Engineering (TE) links in a Multiprotocol Label Switching (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as hierarchical LSPs (H-LSPs).
多协议标签交换（MPLS）或通用MPLS（GMPLS）网络中的流量工程（TE）链路可以由标签交换路径（LSP）构建[RFC4206]。这种LSP称为分层LSP（H-LSP）。
The LSPs established in one network may be used as TE links in another network, and this is particularly useful when a server layer network (for example, an optical network) provides LSPs for use as TE links in a client network (for example, a packet network). This enables the construction of a multilayer network (MLN) [RFC5212].
在一个网络中建立的lsp可以用作另一个网络中的TE链路，并且当服务器层网络（例如，光网络）提供lsp以用作客户端网络（例如，分组网络）中的TE链路时，这尤其有用。这使得能够构建多层网络（MLN）[RFC5212]。
When the number of TE links (created from LSPs or otherwise) between a pair of nodes grows large, it is inefficient to advertise them individually. This may cause scaling issues in configuration and in the routing protocols used to carry the advertisements. The solution (described in [RFC4201]) is to collect the TE links together and to advertise them as a single TE link called a link bundle.
当一对节点之间的TE链路（由LSP或其他方式创建）数量增加时，单独播发它们是低效的。这可能会导致配置和用于承载广告的路由协议中出现缩放问题。解决方案（如[RFC4201]所述）是将TE链接收集在一起，并将它们作为称为链接束的单个TE链接发布。
These various mechanisms have proved to be very powerful in building dynamically provisioned networks, but, as set out later in this document, several issues have been identified during deployment with how LSPs are established and made available for use as H-LSPs or as components of a link bundle, and with how these links are advertised appropriately in an interior gateway protocol (IGP). These issues relate to how the LSP's endpoints coordinate two things: the use to which the LSP is put and the identifiers of the endpoints.
事实证明，这些不同的机制在构建动态供应网络方面非常强大，但是，如本文件后面所述，在部署过程中发现了几个问题，即如何建立LSP并将其用作H-LSP或链路包的组件，以及如何在内部网关协议（IGP）中适当地公布这些链接。这些问题涉及LSP端点如何协调两件事：LSP的使用和端点的标识符。
This document provides solutions to these issues by defining mechanisms so that the ends of signaled LSPs can exchange information about:
本文件通过定义机制提供了这些问题的解决方案，以便信号LSP的末端可以交换有关以下方面的信息：
- Whether the LSP is an ordinary LSP or an H-LSP. - In which IGP instances the LSP should be advertised as a link. - How the client networks should make use of the new links. - Whether the link should form part of a bundle (and if so, which bundle). - How the link endpoints should be identified when advertised.
- LSP是普通LSP还是H-LSP。-在哪些IGP实例中，LSP应作为链接发布。-客户端网络应如何利用新链接。-链接是否应构成捆绑包的一部分（如果是，是哪个捆绑包）。-发布时应如何标识链接端点。
This document deprecates one of the mechanisms defined in [RFC4206] for the signaling of LSPs that are to be used as numbered TE links (see Sections 1.3.6 and 1.4.6 for more details), and provides extensions to the other mechanisms defined in [RFC4206] so that the use to which the new LSP is to be put may be indicated during signaling. It also extends the mechanisms defined in [RFC3477] for signaling unnumbered TE links.
本文件不推荐[RFC4206]中定义的用于将用作编号TE链路的LSP信令的机制之一（更多详细信息，请参见第1.3.6节和第1.4.6节），并提供了对[RFC4206]中定义的其他机制的扩展，以便在信令期间可以指示新LSP的用途。它还扩展了[RFC3477]中定义的发送未编号TE链路的机制。
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]中所述进行解释。
[RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of H-LSPs is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of an H-LSP that can carry one or more other LSPs.
[RFC3031]描述了如何堆叠MPLS标签，以便LSP可以与一个LSP嵌套在另一个LSP中。H-LSP的概念在[RFC4206]中通过一组协议机制形式化，用于建立可承载一个或多个其他LSP的H-LSP。
[RFC4206] goes on to explain that an H-LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable (PSC) network, the H-LSP can carry other PSC LSPs using the MPLS label stack. In non-packet networks where the label is implicit, label stacks are not possible, and H-LSPs rely on the ability to nest switching
[RFC4206]接着解释，H-LSP只能根据其切换类型携带其他LSP。这是标签携带方式的一个功能。在支持分组交换（PSC）的网络中，H-LSP可以使用MPLS标签栈承载其他PSC LSP。在标签是隐式的非分组网络中，标签堆栈是不可能的，H-LSP依赖于嵌套交换的能力
technologies. Thus, for example, a lambda switch capable (LSC) LSP can carry a time-division multiplexing (TDM) LSP, but cannot carry another LSC LSP.
技术。因此，例如，支持lambda交换机（LSC）的LSP可以承载时分复用（TDM）LSP，但不能承载另一个LSC LSP。
Signaling mechanisms defined in [RFC4206] allow an H-LSP to be treated as a single hop in the path of another LSP (i.e., one hop of the LSP carried by the H-LSP). This mechanism is known as "non-adjacent signaling".
[RFC4206]中定义的信令机制允许将H-LSP视为另一LSP路径中的单个跳（即，H-LSP承载的LSP的一个跳）。这种机制称为“非相邻信令”。
LSP stitching is defined in [RFC5150]. It enables LSPs of the same switching type to be included (stitched) as hops in an end-to-end LSP. The stitching LSP (S-LSP) is used in the control plane in the same way as an H-LSP, but in the data plane the LSPs are stitched so that there is no label stacking or nesting of technologies. Thus, an S-LSP must be of the same switching technology as the end-to-end LSP that it facilitates.
LSP缝合在[RFC5150]中定义。它允许在端到端LSP中包含（缝合）与跳相同切换类型的LSP。缝合LSP（S-LSP）在控制平面中的使用方式与H-LSP相同，但在数据平面中缝合LSP，因此不存在标签堆叠或嵌套技术。因此，S-LSP必须与它所促进的端到端LSP具有相同的交换技术。
An H-LSP or S-LSP can be used as a private link. Such links are known by their endpoints, but are not more widely known and are not advertised by routing protocols. They can be used to carry traffic between the endpoints, but are not usually used to carry traffic that is going beyond the egress of the LSP.
H-LSP或S-LSP可用作专用链路。这样的链路由它们的端点所知，但并不更广为人知，也不通过路由协议公布。它们可用于承载端点之间的流量，但通常不用于承载超出LSP出口的流量。
A routing adjacency is formed between two IGP speakers that are logically adjacent. In this sense, 'logically adjacent' means that the routers have a protocol tunnel between them through which they can exchange routing protocol messages. The tunnel is also usually available for carrying IP data although a distinction should be made in GMPLS networks between data-plane traffic and control-plane traffic.
在逻辑上相邻的两个IGP扬声器之间形成路由邻接。从这个意义上说，“逻辑相邻”意味着路由器之间有一个协议隧道，它们可以通过该隧道交换路由协议消息。隧道通常也可用于承载IP数据，尽管在GMPLS网络中应区分数据平面流量和控制平面流量。
Routing adjacencies for forwarding data traffic are only relevant in PSC networks (i.e., IP/MPLS networks).
转发数据流量的路由邻接仅与PSC网络（即IP/MPLS网络）相关。
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP.
转发邻接（FA）在[RFC4206]中定义为从LSP创建的数据链路，并在控制平面的同一实例中播发，该控制平面播发LSP从中构建的TE链路。LSP本身称为FA-LSP。
Thus, an H-LSP or S-LSP may form an FA such that it is advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that the LSP traverses.
因此，H-LSP或S-LSP可以形成FA，使得其在路由协议的同一实例中作为TE链路被通告，该实例与用于通告LSP所穿越的TE链路的实例相同。
As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency.
正如在[RFC4206]中所观察到的，FA末端的节点通常不会有路由邻接。
An LSP may be created in one network and used as a link (sometimes called a virtual link) in another network [RFC5212]. In this case, the networks are often referred to as server and client networks, respectively.
LSP可以在一个网络中创建，并用作另一个网络中的链路（有时称为虚拟链路）[RFC5212]。在这种情况下，这些网络通常分别称为服务器网络和客户端网络。
The server network LSP is used as an H-LSP or an S-LSP as described above, but it does not form an FA because the client and server networks run separate instances of the control-plane routing protocols.
如上所述，服务器网络LSP用作H-LSP或S-LSP，但它不形成FA，因为客户端和服务器网络运行控制平面路由协议的单独实例。
The virtual link may be used in the client network as a private link or may be advertised in the client network IGP. Additionally, the link may be used in the client network to form a routing adjacency and/or as a TE link.
虚拟链路可以在客户端网络中用作专用链路，或者可以在客户端网络IGP中通告。此外，链路可在客户端网络中用于形成路由邻接和/或用作TE链路。
[RFC4201] recognizes that a pair of adjacent routers may have a large number of TE links that run between them. This can be a considerable burden to the operator who may need to configure them and to the IGP that must distribute information about each of them. A TE link bundle is defined by [RFC4201] as a TE link that is advertised as an aggregate of multiple TE links that could have been advertised in their own right. All TE links that are collected into a TE link bundle have the same TE properties.
[RFC4201]认识到一对相邻路由器之间可能存在大量运行的TE链路。这对可能需要配置它们的操作员和必须分发关于它们的信息的IGP来说是一个相当大的负担。TE链路束由[RFC4201]定义为TE链路，该TE链路作为多个TE链路的集合进行广告，这些TE链路本可以通过自身的方式进行广告。收集到TE链接束中的所有TE链接都具有相同的TE属性。
Thus, a link bundle is a shorthand that improves the scaling properties of the network.
因此，链接束是一种改进网络缩放特性的简写方法。
Since a TE link may, itself, be an LSP (either an FA or a virtual link), a link bundle may be constructed from FA-LSPs or virtual links.
由于TE链路本身可以是LSP（FA或虚拟链路），因此可以从FA LSP或虚拟链路构造链路束。
It should be possible to signal an LSP and automatically coordinate its use and advertisement in any of the ways described in Section 1.3 with minimum involvement from an operator. The mechanisms used should be applicable to numbered and unnumbered links and should not require implementation complexities.
应能够以第1.3节中所述的任何方式向LSP发出信号，并自动协调其使用和广告，且操作员的参与最少。所使用的机制应适用于编号和未编号的链接，并且不应要求实现的复杂性。
This section briefly introduces existing protocol mechanisms used to satisfy the desired function described in Section 1.2.
本节简要介绍了用于满足第1.2节所述功能的现有协议机制。
Both unidirectional LSPs and bidirectional LSPs are signaled from the ingress label switching router (LSR) to the egress LSR. That is, the ingress LSR is the initiator, and the egress learns about the LSP through the signaling protocol [RFC3209] [RFC3473].
单向LSP和双向LSP都从入口标签交换路由器（LSR）向出口LSR发送信号。即，入口LSR是发起方，出口通过信令协议[RFC3209][RFC3473]了解LSP。
Although hosts can discover routers (for example, through ICMP [RFC1256]), routing adjacencies are usually configured at both ends of the adjacency. This requires that each router know the identity of the router at the other end of the link connecting the routers, and know that the IGP is to be run on this link.
虽然主机可以发现路由器（例如，通过ICMP[RFC1256]），但路由邻接通常在邻接的两端配置。这要求每个路由器知道连接路由器的链路另一端的路由器的身份，并知道IGP将在此链路上运行。
Once a routing adjacency has been established, a pair of routers may use the IGP to share information about the links available for carrying IP traffic in the network.
一旦建立了路由邻接，一对路由器就可以使用IGP来共享关于网络中可用于承载IP业务的链路的信息。
Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], and IS-IS [RFC1195].
合适的路由协议有OSPF版本2[RFC2328]、OSPF版本3[RFC5340]和IS-IS[RFC1195]。
Extensions have been made to IGPs to advertise TE link properties ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and also to advertise link properties in GMPLS networks ([RFC4202], [RFC4203], and [RFC5307]).
对IGP进行了扩展，以公布TE链路属性（[RFC3630]、[RFC5329]、[RFC5305]、[RFC5308]和[ISIS-IPV6-TE]），并在GMPLS网络中公布链路属性（[RFC4202]、[RFC4203]和[RFC5307]）。
TE link advertisement can be performed by the same instance of the IGP as is used for normal link state advertisement, or can use a separate instance. Furthermore, the ends of a TE link advertised in an IGP do not need to form a routing adjacency. This is particularly the case with FAs as described in Section 1.1.5.
TE链路通告可以由IGP的与用于正常链路状态通告的实例相同的实例来执行，或者可以使用单独的实例。此外，在IGP中通告的TE链路的端部不需要形成路由邻接。如第1.1.5节所述，FAs尤其如此。
LSPs are usually created as the result of a management action. This is true even when a control plane is used: the management action is a request to the control plane to signal the LSP.
LSP通常是管理操作的结果。即使在使用控制平面时也是如此：管理操作是向控制平面发出信号通知LSP的请求。
If the LSP is to be used as an H-LSP or S-LSP, management commands can be used to install the LSP as a link. The link must be defined, interface identifiers allocated, and the endpoints configured to know about (and advertise, if necessary) the new link.
如果要将LSP用作H-LSP或S-LSP，则可以使用管理命令将LSP安装为链接。必须定义链接，分配接口标识符，并将端点配置为了解（并在必要时公布）新链接。
If the LSP is to be used as part of a link bundle, the operator must decide which bundle it forms part of and ensure that information is configured at the ingress and egress, along with the necessary interface identifiers.
如果要将LSP用作链路捆绑包的一部分，则运营商必须确定其构成的捆绑包的一部分，并确保在入口和出口处配置信息以及必要的接口标识符。
These mechanisms are perfectly functional and quite common in MLNs, but require configuration coordination and additional management. They are open to user error and misconfiguration that might result in the LSP not being used (a waste of resources) or the LSP being made available in the wrong way with some impact on traffic engineering.
这些机制功能完善，在MLN中非常常见，但需要配置协调和额外的管理。它们容易出现用户错误和配置错误，可能导致LSP未被使用（浪费资源）或LSP以错误的方式提供，从而对流量工程造成一定影响。
[RFC3477] describes how to establish an LSP and to make it available automatically as a TE link in the same instance of the routing protocol as advertises the TE links it traverses, using IPv4-based unnumbered identifiers to identify the new TE link. That is, [RFC3477] describes how to create an unnumbered FA.
[RFC3477]描述了如何建立LSP，以及如何使用基于IPv4的未编号标识符来标识新TE链路，从而使其自动作为TE链路在路由协议的同一实例中可用，同时播发它所穿越的TE链路。也就是说，[RFC3477]描述了如何创建未编号的FA。
The mechanism, as defined in Section 3 of [RFC3477], is briefly as follows:
[RFC3477]第3节中定义的机构简要如下：
- The ingress of the LSP signals the LSP as normal using a Path message, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The sender's LSR Router ID - The sender's interface ID for the TE link being created
- LSP的进入使用路径消息向LSP发送正常信号，并且包括LSP_TUNNEL_INTERFACE_ID对象。LSP_TUNNEL_INTERFACE_ID对象标识：-发送方的LSR路由器ID-正在创建的TE链路的发送方接口ID
- The egress of the LSP responds as normal to accept the LSP and set it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The egress's LSR Router ID - The egress's interface ID for the TE link being created.
- LSP的出口正常响应以接受并设置LSP，并包括一个LSP_TUNNEL_INTERFACE_ID对象。LSP_TUNNEL_INTERFACE_ID对象标识：-出口的LSR路由器ID-正在创建的TE链路的出口接口ID。
- Following the exchange of the Path and Resv messages, both the ingress and the egress know that the LSP is to be advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that it traverses, and also know the unnumbered interface identifiers to use in the advertisement.
- 在路径和Resv消息的交换之后，入口和出口都知道LSP将作为TE链路在路由协议的同一实例中被通告，该实例与用于通告其所穿越的TE链路的实例相同，并且还知道要在通告中使用的未编号的接口标识符。
[RFC3477] does not include mechanisms to support IPv6-based unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers.
[RFC3477]不包括支持基于IPv6的未编号标识符、IPv4或IPv6编号标识符的机制。
[RFC4206] describes procedures to establish an LSP and to make it available automatically as a TE link that is identified using IPv4 addresses in the same instance of the routing protocol as advertises the TE links it traverses (that is, as a numbered FA).
[RFC4206]描述了建立LSP并使其作为TE链路自动可用的过程，该TE链路在路由协议的同一实例中使用IPv4地址标识，作为其所穿越的TE链路（即，作为编号FA）的播发。
The mechanism, as defined in [RFC4206], is briefly as follows:
[RFC4206]中定义的机制简要如下：
- The ingress of the LSP signals the LSP as normal using a Path message, and sets the IPv4 tunnel sender address to the IP address it will use to identify its interface for the TE link being created. This is one address from a /31 pair.
- LSP的进入使用路径消息向LSP发出正常信号，并将IPv4隧道发送方地址设置为IP地址，该地址将用于标识其用于创建TE链路的接口。这是a/31对中的一个地址。
- The egress of the LSP responds as normal to accept the LSP and set it up. It infers the address that it must assign to identify its interface for the TE link being created as the partner address of the /31 pair.
- LSP的出口正常响应以接受LSP并设置它。它推断出它必须分配的地址，以将正在创建的TE链接的接口标识为/31对的伙伴地址。
- The ingress decides whether the LSP is to be advertised as a TE link (i.e., as an FA). If so, it advertises the link in the IGP in the usual way.
- 入口决定是否将LSP广告为TE链路（即，作为FA）。如果是这样，它会以通常的方式在IGP中公布链接。
- If the link is unidirectional, nothing more needs to be done. If the link is bidirectional, the egress must also advertise the link, but it does not know that advertisement is required as there is no indication in the signaling messages.
- 如果链接是单向的，就不需要做更多的事情。如果链路是双向的，出口还必须播发链路，但它不知道需要播发，因为信令消息中没有指示。
- When the ingress's advertisement of the link is received by the egress, it must check to see whether it is the egress of the LSP that formed the link. Typically, this means the egress: - Checks to see if the link advertisement is new. - Checks to see if the Link-ID address in the received advertisement matches its own TE Router ID. - Checks the advertising router ID from the advertisement against the ingress address of each LSP for which it is the egress. - Deduces the LSP that has been advertised as a TE link and issues the corresponding advertisement for the reverse direction.
- 当入口的链路广告被出口接收时，它必须检查是否是LSP的出口形成了链路。通常，这意味着出口：-检查链接广告是否是新的。-检查接收到的播发中的链路ID地址是否与其自身的TE路由器ID匹配。-将播发中的播发路由器ID与作为其出口的每个LSP的入口地址进行检查。-推断已作为TE链路播发的LSP，并针对反向发出相应的播发。
It is possible that some reduction in processing can be achieved by mapping based on the /31 pairing, but nevertheless, there is a fair amount of processing required, and this does not scale well in large networks.
通过基于/31配对的映射，可以在一定程度上减少处理，但是，仍然需要大量的处理，这在大型网络中无法很好地扩展。
Note that this document deprecates this procedure as explained in Section 1.4.6.
注意，如第1.4.6节所述，本文件不推荐该程序。
No explanation is provided in [RFC4206] of how to create numbered IPv6 FAs.
[RFC4206]中没有解释如何创建编号的IPv6 FAs。
This section provides a brief outline of the required protocol extensions.
本节简要介绍了所需的协议扩展。
The mechanism described in Section 1.3.6 is inefficient. The egress must wait until it receives an advertisement from the ingress before it knows that the LSP is to be installed as a TE link and advertised as an FA. Further, it must parse all received advertisements to determine if any is the trigger for it to advertise an FA.
第1.3.6节中描述的机制效率低下。出口必须等到从入口接收到广告后，才知道LSP将作为TE链路安装并作为FA进行广告。此外，它必须解析所有接收到的播发，以确定是否有任何播发是它播发FA的触发器。
An efficient signaling mechanism is required so that the egress is informed by the ingress during LSP establishment.
需要有效的信令机制，以便在LSP建立期间由入口通知出口。
There is currently no mechanism by which an ingress can indicate that an LSP is set up for use as a private link. Any attempt to make it a link would currently cause it to be advertised as an FA.
目前没有一种机制可用于入口指示LSP被设置为用作专用链路。任何试图使其成为链接的行为都会导致当前将其广告为FA。
A signaling mechanism is needed to identify the use to which an LSP is to be put.
需要一种信令机制来识别LSP将被投入的用途。
The existing signaling/routing mechanisms are designed for use in the creation of FAs. That is, the TE link created is advertised in the single IGP instance.
现有的信令/路由机制设计用于创建FAs。也就是说，在单个IGP实例中公布创建的TE链路。
The numbered TE link mechanism (Section 1.3.6) could, in theory, be used in an MLN with multiple IGP instances if the addressing model is kept consistent across the networks, and if the egress searches all advertisements in all IGP instances. However, this is complex and does not work for unnumbered interfaces.
如果寻址模型在整个网络中保持一致，并且出口搜索所有IGP实例中的所有广告，则编号TE链路机制（第1.3.6节）理论上可用于具有多个IGP实例的MLN。但是，这很复杂，不适用于未编号的接口。
A signaling mechanism is required to indicate in which IGP instance the TE link should be advertised.
需要一种信令机制来指示TE链路应该在哪个IGP实例中进行广告。
A signaling mechanism is required to indicate that an LSP is intended to form a component link of a link bundle, and to identify the bundle and the IGP instance in which the bundle is advertised.
需要信令机制来指示LSP旨在形成链路束的组件链路，并识别该束和其中播发该束的IGP实例。
The protocol mechanisms must support IPv4 and IPv6 numbered and unnumbered TE links.
协议机制必须支持IPv4和IPv6编号和未编号的TE链路。
The existing protocol mechanisms for unnumbered FAs as defined in [RFC4206] and [RFC3477] must continue to be supported, and new mechanisms must be devised such that their introduction will not break existing implementations or deployments.
必须继续支持[RFC4206]和[RFC3477]中定义的未编号FAs的现有协议机制，并且必须设计新机制，以确保其引入不会破坏现有实施或部署。
Note that an informal survey in the CCAMP working group established that there are no significant deployments of numbered FAs established using the technique described in [RFC4206] and set out in Section 1.3.6. Therefore, this document deprecates this procedure.
注意，CCAMP工作组的一项非正式调查表明，使用[RFC4206]中所述的技术和第1.3.6节中所述的技术建立的编号FAs没有重大部署。因此，本文档不推荐此过程。
This section provides an overview of the mechanisms and protocol extensions defined in this document. Details are presented in Section 3.
本节概述了本文档中定义的机制和协议扩展。详情见第3节。
The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for all H-LSPs and S-LSPs whether they form numbered or unnumbered IPv4 or IPv6 links. Different Class Types of the object identify the address type for which it applies.
LSP_TUNNEL_INTERFACE_ID对象[RFC3477]已扩展，可用于所有H-LSP和S-LSP，无论它们形成编号或未编号的IPv4或IPv6链路。对象的不同类类型标识其应用的地址类型。
The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions field to say how the LSP is to be used. The following categories are supported:
LSP_TUNNEL_INTERFACE_ID对象在一个新的Actions字段中被赋予标志，以说明如何使用LSP。支持以下类别：
- The LSP is used as an advertised TE link. - The LSP is used to form a routing adjacency. - The LSP is used to form an advertised TE link and a routing adjacency. - The LSP forms a private link and is not advertised. - The LSP is used as part of a link bundle. - The LSP is used as a hierarchical LSP or a stitching segment.
- LSP用作公布的TE链路。-LSP用于形成路由邻接。-LSP用于形成广告TE链路和路由邻接。-LSP形成一个专用链接，不进行广告。-LSP用作链接束的一部分。-LSP用作分层LSP或缝合段。
An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to identify the IGP instance into which the link formed by the LSP is to be advertised. If the TLV is absent and the link is to be advertised as indicated by the Actions field, the link is advertised in the same instance of the IGP as was used to advertise the TE links it traverses.
将可选的TLV添加到LSP_TUNNEL_INTERFACE_ID对象中，以标识由LSP形成的链路要播发到其中的IGP实例。如果TLV不存在，并且按照Actions字段的指示通告链路，则在IGP的同一实例中通告链路，该实例用于通告它所穿越的TE链路。
When an LSP is to be used as a component link of a link bundle, the LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how the bundle is addressed and used, and a new TLV indicates the component link identifier for the link that the LSP creates.
当LSP用作链接束的组件链接时，LSP_TUNNEL_INTERFACE_ID对象引用该束，指示如何寻址和使用该束，新TLV指示LSP创建的链接的组件链接标识符。
Backward compatibility has three aspects.
向后兼容性有三个方面。
- Existing mechanisms for unnumbered FAs described in [RFC3477] and [RFC4206] must continue to work, so that ingress nodes do not have to be updated when egresses are updated.
- [RFC3477]和[RFC4206]中描述的未编号FA的现有机制必须继续工作，以便在更新出口时不必更新入口节点。
- Existing mechanisms for establishing numbered FAs described in [RFC4206] are safely deprecated by this document, as they are not significantly deployed.
- [RFC4206]中描述的用于建立编号FA的现有机制在本文档中被安全地弃用，因为它们没有显著部署。
- New mechanisms must be gracefully rejected by existing egress implementations so that egress nodes do not have to be updated when ingresses are updated.
- 现有出口实现必须优雅地拒绝新机制，以便在更新入口时不必更新出口节点。
This section defines protocol mechanisms and extensions to achieve the function described in the previous section.
本节定义了协议机制和扩展，以实现上一节中描述的功能。
The principal signaling protocol element used to achieve all of the required functions is the LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. The existing definition and usage continues to be supported as described in the next section. Subsequent sections describe new variants of the object (denoted by new Class Types), and additional information carried in the object by means of extensions.
用于实现所有所需功能的主要信令协议元素是[RFC3477]中定义的LSP_TUNNEL_INTERFACE_ID对象。如下一节所述，将继续支持现有的定义和用法。随后的部分描述了对象的新变体（由新的类类型表示），以及通过扩展在对象中携带的附加信息。
This document does not deprecate the mechanisms defined in [RFC3477] and [RFC4206]. Those procedures must continue to operate as described in Section 3.7.
本文件不反对[RFC3477]和[RFC4206]中定义的机制。这些程序必须按照第3.7节所述继续运行。
That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 remains unchanged, and can be used to establish an LSP that will be advertised as an unnumbered TE link in the same instance of the IGP as was used to advertise the TE links that the LSP traverses (that is, as an FA). The procedure is unchanged and operates as summarized in Section 1.3.5.
这意味着类类型为1的LSP_TUNNEL_INTERFACE_ID对象保持不变，并可用于建立一个LSP，该LSP将在IGP的同一实例中作为未编号的TE链路进行播发，该实例用于播发LSP穿过的TE链路（即，作为FA）。该程序未变，并按照第1.3.5节的总结进行操作。
[RFC3477] does not make any suggestions about where in Path or Resv messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See Section 3.5 for recommended placement of this object in new implementations.
[RFC3477]未就LSP_TUNNEL_INTERFACE_ID对象应放置在Path或Resv消息中的位置提出任何建议。请参阅第3.5节，了解新实现中此对象的建议位置。
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an unnumbered interface identifier and to indicate into which instance of the IGP the consequent TE link should be advertised. This does not deprecate the use of C-Type 1.
LSP_TUNNEL_INTERFACE_ID对象的一个新的C-Type变体被定义为携带一个未编号的接口标识符，并指示随后的TE链路应该发布到IGP的哪个实例中。这并不反对使用C-Type 1。
The format of the object is as shown below.
对象的格式如下所示。
C-NUM = 193, C-Type = 4
C-NUM=193，C-Type=4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSR's Router ID
LSR的路由器ID
Unchanged from the definition in [RFC3477].
与[RFC3477]中的定义相同。
Interface ID
接口ID
Unchanged from the definition in [RFC3477].
与[RFC3477]中的定义相同。
Actions
行动
This field specifies how the LSP that is being set up is to be treated.
此字段指定如何处理正在设置的LSP。
The field has meaning only on a Path message. On a Resv message, the field SHOULD be set to reflect the value received on the corresponding Path message, and it MUST be ignored on receipt.
该字段仅在路径消息上有意义。在Resv消息上，该字段应设置为反映在相应路径消息上接收到的值，并且在接收时必须忽略该字段。
The field is composed of bit flags as follows:
该字段由位标志组成，如下所示：
-+-+-+-+-+-+-+-
| | | |H|B|R|T|P|
-+-+-+-+-+-+-+-
-+-+-+-+-+-+-+-
| | | |H|B|R|T|P|
-+-+-+-+-+-+-+-
P-flag (Private) 0 means that the LSP is to be advertised as a link according to the settings of the other flags. 1 means the LSP is to form a private link and is not to be advertised in the IGP, but is to be used according to the settings of the other flags.
P-flag（Private）0表示根据其他标志的设置将LSP作为链路进行广告。1表示LSP将形成专用链路，并且不会在IGP中公布，而是根据其他标志的设置使用。
T-flag (TE link) 0 means that the LSP is to be used as a TE link. 1 means that the LSP is not to be used as a TE link. It may still be used as an IP link providing a routing adjacency as defined by the R-flag.
T标志（TE链路）0表示LSP将用作TE链路。1表示LSP不用作TE链路。它仍然可以用作IP链路，提供由R标志定义的路由邻接。
R-flag (Routing adjacency) 0 means that the link is not to be used as a routing adjacency. 1 means that the link is to be used to form a routing adjacency.
R标志（路由邻接）0表示链路不用作路由邻接。1表示链路将用于形成路由邻接。
B-flag (Bundle) 0 means that the LSP will not form part of a link bundle. 1 means that the LSP will form part of a bundle. See Section 3.3 for more details.
B标志（捆绑）0表示LSP不会构成链接捆绑的一部分。1表示LSP将构成捆绑的一部分。详见第3.3节。
H-flag (Hierarchy/stitching) The use of an LSP as an H-LSP or as an S-LSP is usually implicit from the network technologies of the networks and the LSP, but this is not always the case (for example, in PSC networks). 0 means that the LSP is to be used as a hierarchical LSP. 1 means that the LSP is to be used as a stitching segment.
H标志（层次/缝合）LSP作为H-LSP或S-LSP的使用通常隐含于网络和LSP的网络技术中，但情况并非总是如此（例如，在PSC网络中）。0表示LSP将用作分层LSP。1表示LSP将用作缝合段。
Other bits are reserved for future use. They MUST be set to zero on transmission and SHOULD be ignored on receipt.
其他位保留供将来使用。它们在传输时必须设置为零，在接收时应忽略。
Note that all defined bit flags have meaning at the same time. An LSP that is to form an FA would carry the Actions field set to 0x00. That is: P=0 (advertised) T=0 (TE link) R=0 (not a routing adjacency) B=0 (not a bundle) H=0 (hierarchical LSP)
请注意，所有定义的位标志同时具有含义。要形成FA的LSP将携带设置为0x00的Actions字段。也就是说：P=0（公布的）T=0（TE链路）R=0（不是路由邻接）B=0（不是捆绑）H=0（分层LSP）
Reserved
含蓄的
The Reserved bits MUST be set to zero on transmission and SHOULD be ignored on receipt.
传输时必须将保留位设置为零，接收时应忽略保留位。
TLVs
阈限值
Zero, one, or more TLVs may be present. Each TLV is encoded as follows:
可能存在零个、一个或多个TLV。每个TLV的编码如下所示：
Type (16 bits)
类型（16位）
The identifier of the TLV. Two type values are defined in this document:
TLV的标识符。本文档中定义了两个类型值：
1 IGP Instance Identifier TLV 2 Unnumbered Component Link Identifier TLV 3 IPv4 Numbered Component Link Identifier TLV 4 IPv6 Numbered Component Link Identifier TLV
1 IGP实例标识符TLV 2未编号的组件链接标识符TLV 3 IPv4编号的组件链接标识符TLV 4 IPv6编号的组件链接标识符TLV
Length (16 bits)
长度（16位）
Indicates the total length of the TLV in octets, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
表示TLV的总长度（以八位字节为单位），即4+值字段的长度（以八位字节为单位）。长度不是四的倍数的值字段必须加零，以便TLV与四个八位组对齐。
Value
价值
The data for the TLV padded as described above.
如上所述填充TLV的数据。
If this object is carried in a Path message, it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message, the object is known as the "Reverse Interface ID" for the LSP.
如果此对象在路径消息中携带，则它被称为正在设置的LSP的“转发接口ID”。在Resv消息中，对象称为LSP的“反向接口ID”。
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an IPv4 numbered interface address.
LSP_TUNNEL_INTERFACE_ID对象的一个新的C类型变体被定义为携带IPv4编号的接口地址。
The format of the object is as shown below.
对象的格式如下所示。
C-NUM = 193, C-Type = 2
C-NUM=193，C-Type=2
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 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Interface Address
IPv4接口地址
The address assigned to the interface that the sender applies to this LSP.
分配给发送方应用于此LSP的接口的地址。
Actions
行动
See Section 3.1.2.
见第3.1.2节。
Reserved
含蓄的
See Section 3.1.2.
见第3.1.2节。
TLVs
阈限值
See Section 3.1.2.
见第3.1.2节。
If this object is carried in a Path message, it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message, the object is known as the "Reverse Interface ID" for the LSP.
如果此对象在路径消息中携带，则它被称为正在设置的LSP的“转发接口ID”。在Resv消息中，对象称为LSP的“反向接口ID”。
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined to carry an IPv6 numbered interface address.
LSP_TUNNEL_INTERFACE_ID对象的一个新的C类型变体被定义为携带IPv6编号的接口地址。
The format of the object is as shown below.
对象的格式如下所示。
C-NUM = 193, C-Type = 3
C-NUM=193，C-Type=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Interface Address
IPv6接口地址
The address assigned to the interface the sender applies to this LSP.
分配给发送方应用于此LSP的接口的地址。
Actions
行动
See Section 3.1.2.
见第3.1.2节。
Reserved
含蓄的
See Section 3.1.2.
见第3.1.2节。
TLVs
阈限值
See Section 3.1.2.
见第3.1.2节。
If this object is carried in a Path message, it is known as the "Forward Interface ID" for the LSP that is being set up. On a Resv message, the object is known as the "Reverse Interface ID" for the LSP.
如果此对象在路径消息中携带，则它被称为正在设置的LSP的“转发接口ID”。在Resv消息中，对象称为LSP的“反向接口ID”。
If the LSP being set up is to be advertised as a link, the egress needs to know which instance of the IGP it should use to make the advertisement. The default in [RFC4206] and [RFC3477] is that the LSP is advertised as an FA, that is, in the same instance of the IGP as was used to advertise the TE links that the LSP traverses.
如果要将正在设置的LSP作为链路进行广告，则出口需要知道应该使用哪个IGP实例来进行广告。[RFC4206]和[RFC3477]中的默认值是，LSP作为FA播发，也就是说，在用于播发LSP所穿越的TE链路的IGP实例中。
In order to facilitate an indication from the ingress to the egress of which IGP instance to use, the IGP Identification TLV is defined for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID object defined in this document.
为了便于从入口到出口指示使用哪个IGP实例，定义了IGP标识TLV，以包含在本文件中定义的LSP_TUNNEL_INTERFACE_ID对象的新变体中。
The TLV has meaning only in a Path message. It SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and MUST be ignored if found.
TLV仅在路径消息中有意义。它不应包含在Resv消息中的LSP_TUNNEL_INTERFACE_ID对象中，如果找到，则必须忽略它。
If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in a Path message is clear (i.e., zero), this TLV indicates the IGP instance to use for the advertisement. If the TLV is absent, the same instance of the IGP should be used as is used to advertise the TE links that the LSP traverses. Thus, for an FA, the TLV can be omitted; alternatively, the IGP Instance TLV may be present and identify the IGP instance or carry the reserved value 0xffffffff.
如果路径消息中LSP_TUNNEL_INTERFACE_ID对象的Actions字段中的P标志为清除（即零），则此TLV指示用于播发的IGP实例。如果缺少TLV，则应使用与用于通告LSP穿过的TE链路相同的IGP实例。因此，对于FA，可以省略TLV；或者，IGP实例TLV可以存在并识别IGP实例或携带保留值0xFFFFFF。
If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID object in a Resv message is set (i.e., one) indicating that the LSP is not to be advertised as a link, this TLV SHOULD NOT be present and MUST be ignored if encountered.
如果设置了Resv消息中LSP_TUNNEL_INTERFACE_ID对象的Actions字段中的P标志（即，一个），指示不将LSP作为链接播发，则此TLV不应存在，并且在遇到此TLV时必须忽略。
The TLV is formatted as described in Section 3.1.2. The Type field has the value 1, and the Value field has the following content:
TLV的格式如第3.1.2节所述。类型字段的值为1，值字段的内容如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGP Instance 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGP Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IGP Instance Identifier
IGP实例标识符
A 32-bit identifier assigned to each of the IGP instances within a network, such that ingress and egress LSRs have the same understanding of these numbers. This is a management configuration exercise outside the scope of this document.
分配给网络内每个IGP实例的32位标识符，以便入口和出口LSR对这些数字有相同的理解。这是本文档范围之外的管理配置练习。
Note that the IGP Instance Identifier might be mapped from an instance identifier used in the IGP itself (such as section 2.4 of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter of network policy. See [OSPF-TI] for further discussion of this topic in OSPF, and [ISIS-GENAP] for IS-IS.
注意，根据网络策略，IGP实例标识符可以从IGP本身中使用的实例标识符映射（例如，对于OSPFv3，[RFC5340]的第2.4节，或者对于OSPFv2，[OSPFv2 MI]的第2.4节）。请参见[OSPF-TI]了解OSPF中关于该主题的进一步讨论，参见[ISIS-GENAP]了解IS-IS。
The value 0xffffffff is reserved to mean that the LSP is to be advertised in the same instance of the IGP as was used to advertise the TE links that the LSP traverses.
值0xFFFFFF保留为意味着LSP将在IGP的同一实例中播发，该实例用于播发LSP所穿越的TE链路。
If the LSP that is being set up is to be used as a component link in a link bundle [RFC4201], it is necessary to indicate both the identity of the component link and the identity of the link bundle. Furthermore, it is necessary to indicate how the link bundle (that may be automatically created by the establishment of this LSP) is to be used and advertised.
如果正在设置的LSP将用作链接束[RFC4201]中的组件链接，则必须同时指示组件链接的标识和链接束的标识。此外，有必要指出链路包（可通过建立该LSP自动创建）将如何使用和公布。
If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object is set, the other fields of the object apply to the link bundle itself. That is, the interface identifiers (numbered or unnumbered) and the other flags in the Actions field apply to the link bundle and not to the component link that the LSP will form.
如果设置了LSP_TUNNEL_INTERFACE_ID对象的Actions字段中的B标志，则该对象的其他字段将应用于链接束本身。也就是说，接口标识符（已编号或未编号）和Actions字段中的其他标志适用于链接束，而不是LSP将形成的组件链接。
Furthermore, the IGP Instance Identifier TLV (if present) also applies to the link bundle and not to the component link.
此外，IGP实例标识符TLV（如果存在）也适用于链路包，而不适用于组件链路。
In order to exchange the identity of the component link, the Component Link Identifier TLVs are introduced as set out in the next sections. If the B-flag is set in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in both the Path and Resv objects.
为了交换组件链接的标识，将在下一节中介绍组件链接标识符TLV。如果在路径消息中的LSP_TUNNEL_INTERFACE_ID对象的Actions字段中设置了B标志，则路径和Resv对象中的LSP_TUNNEL_INTERFACE_ID对象中必须正好存在一个TLV。
If the component link is to be unnumbered, the Unnumbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 2, and the Value field has the following content:
如果要取消组件链接的编号，则使用未编号的组件链接标识符TLV。TLV的格式如第3.1.2节所述。类型字段的值为2，值字段的内容如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Component Link Identifier
组件链接标识符
Unnumbered identifier that is assigned to this component link within the bundle [RFC4201].
分配给捆绑包内此组件链接的未编号标识符[RFC4201]。
If the component link is identified with an IPv4 address, the IPv4 Numbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 3, and the Value field has the following content:
如果使用IPv4地址标识组件链接，则使用IPv4编号的组件链接标识符TLV。TLV的格式如第3.1.2节所述。类型字段的值为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address
IPv4地址
The IPv4 address that is assigned to this component link within the bundle.
分配给捆绑包中此组件链接的IPv4地址。
If the component link is identified with an IPv6 address, the IPv6 Numbered Component Link Identifier TLV is used. The TLV is formatted as described in Section 3.1.2. The Type field has the value 4, and the Value field has the following content:
如果组件链接由IPv6地址标识，则使用IPv6编号的组件链接标识符TLV。TLV的格式如第3.1.2节所述。类型字段的值为4，值字段的内容如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address
IPv6地址
The IPv6 address that is assigned to this component link within the bundle.
分配给捆绑包中此组件链接的IPv6地址。
The ingress and egress of an LSP that is set up using the LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in the parameters of the object.
使用LSP_TUNNEL_INTERFACE_ID对象设置的LSP的入口和出口必须按照对象参数中的约定公布LSP。
Where a TE link is created from the LSP, the TE link SHOULD inherit the TE properties of the LSP as described in [RFC5212], but this process is subject to local and network-wide policy.
从LSP创建TE链路时，TE链路应继承LSP的TE属性，如[RFC5212]所述，但此过程受本地和网络范围策略的约束。
It is possible that an LSP will be used to offer capacity and connectivity to multiple other networks. In this case, multiple instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the same Path and Resv messages. Each instance MUST have a different IGP Instance Identifier.
LSP有可能用于提供多个其他网络的容量和连接。在这种情况下，在同一路径和Resv消息中允许LSP_TUNNEL_INTERFACE_ID对象的多个实例。每个实例必须具有不同的IGP实例标识符。
Note, however, that a Path or Resv message MUST NOT contain more than one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if such an object is present, all other instances of the LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance Identifier TLV with IGP Instance Identifier set to a value that identifies some other IGP instance (in particular, not the value 0xffffffff).
但是，请注意，Path或Resv消息不得包含多个具有C-Type 1的LSP_TUNNEL_INTERFACE_ID对象的实例，如果存在此类对象，LSP_TUNNEL_INTERFACE_ID对象的所有其他实例必须包括IGP实例标识符TLV，IGP实例标识符设置为标识其他IGP实例的值（特别是，不是值0xFFFFFF）。
If the link created from an LSP is advertised in the same IGP instance as was used to advertise the TE links that the LSP traverses, the addresses for the new link and for the links from which it is built MUST come from the same address space.
如果从LSP创建的链路在用于播发LSP所经过的TE链路的同一IGP实例中播发，则新链路及其构建链路的地址必须来自同一地址空间。
If the link is advertised into another IGP instance, the addresses MAY be drawn from overlapping address spaces such that some addresses have different meanings in each IGP instance.
如果将链路播发到另一个IGP实例中，则可以从重叠的地址空间中提取地址，使得一些地址在每个IGP实例中具有不同的含义。
In the IGP, the TE Router ID of the ingress LSR is taken from the Tunnel Sender Address in the Sender Template object signaled in the Path message. It is assumed that the ingress LSR knows the TE Router ID of the egress LSR since it has chosen to establish an LSP to that LSR and plans to use the LSP as a TE link.
在IGP中，入口LSR的TE路由器ID取自路径消息中发信号的发送方模板对象中的隧道发送方地址。假设入口LSR知道出口LSR的TE路由器ID，因为它已选择建立到该LSR的LSP并计划将该LSP用作TE链路。
The link interface addresses or link interface identifiers for the forward and reverse direction links are taken from the LSP_TUNNEL_INTERFACE_ID object on the Path and Resv messages, respectively.
正向和反向链路的链路接口地址或链路接口标识符分别取自Path和Resv消息上的LSP_TUNNEL_interface_ID对象。
When an LSP is torn down through explicit action (a PathTear message or a PathErr message with the Path_State_Removed flag set), the ingress and egress LSRs SHOULD withdraw the advertisement of any link that the LSP created and that was previously advertised. The link state advertisement MAY be retained as a virtual link in another layer network according to network-wide policy [PCE-LAYER].
当LSP通过显式操作（设置了Path_State_Removed标志的Path催泪弹消息或PathErr消息）被拆除时，入口和出口LSR应撤回LSP创建的和先前公布的任何链接的公布。根据网络范围策略[PCE-layer]，链路状态广告可以作为虚拟链路保留在另一层网络中。
[RFC3477] does not state where in the Path message or Resv message the LSP_TUNNEL_INTERFACE_ID object should be placed.
[RFC3477]未说明LSP_TUNNEL_INTERFACE_ID对象应放置在路径消息或Resv消息中的何处。
It is RECOMMENDED that new implementations place the LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after the SENDER_TSPEC object, and in the Resv message immediately after the FILTER_SPEC object.
建议新的实现将LSP_TUNNEL_INTERFACE_ID对象放在发送方_TSPEC对象之后的Path消息中，并将其放在筛选器_SPEC对象之后的Resv消息中。
All implementations SHOULD be able to handle received messages with objects in any order, as described in [RFC3209].
如[RFC3209]所述，所有实现都应该能够以任何顺序处理接收到的带有对象的消息。
Error cases and non-acceptance of new object variants caused by back-level implementations are discussed in Section 3.7.
第3.7节讨论了由后台实现引起的错误案例和不接受新对象变体。
An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may have cause to reject the parameters carried in the object for a number of reasons as set out below. In all cases, the egress SHOULD
接收LSP_TUNNEL_INTERFACE_ID对象的出口LSR可能出于如下所述的许多原因拒绝该对象中携带的参数。在任何情况下，出口都应
respond with a PathErr message with the error code as indicated in the list below. In most cases, the error will arise during LSP setup, no Resv state will exist, and the PathErr will cause Path state to be removed. Where the error arises after the LSP has been successfully set up, the PathErr SHOULD be sent with the Path_State_Removed flag [RFC3473] clear so that the LSP remains operational.
用PathErr消息响应，错误代码如下表所示。在大多数情况下，错误将在LSP设置期间出现，不存在Resv状态，并且PathErr将导致路径状态被删除。如果在成功设置LSP后出现错误，则发送PathErr时应清除Path_State_Removed flag[RFC3473]，以便LSP保持运行状态。
The error cases identified are as follows and are reported using the new error code 'LSP Hierarchy Issue' (code 38) and the error values listed below.
确定的错误案例如下所示，并使用新的错误代码“LSP层次结构问题”（代码38）和下面列出的错误值进行报告。
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 1 Link advertisement not supported
38 2 Link advertisement not allowed by policy
38 3 TE link creation not supported
38 4 TE link creation not allowed by policy
38 5 Routing adjacency creation not supported
38 6 Routing adjacency creation not allowed by policy
38 7 Bundle creation not supported
38 8 Bundle creation not allowed by policy
38 9 Hierarchical LSP not supported
38 10 LSP stitching not supported
38 11 Link address type or family not supported
38 12 IGP instance unknown
38 13 IGP instance advertisement not allowed by policy
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 1 Link advertisement not supported
38 2 Link advertisement not allowed by policy
38 3 TE link creation not supported
38 4 TE link creation not allowed by policy
38 5 Routing adjacency creation not supported
38 6 Routing adjacency creation not allowed by policy
38 7 Bundle creation not supported
38 8 Bundle creation not allowed by policy
38 9 Hierarchical LSP not supported
38 10 LSP stitching not supported
38 11 Link address type or family not supported
38 12 IGP instance unknown
38 13 IGP instance advertisement not allowed by policy
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a Resv message, it may need to reject it because of the setting of certain parameters in the object. Since these reasons all represent errors rather than mismatches of negotiable parameters, the ingress SHOULD respond with a PathTear to remove the LSP. The ingress MAY use a ResvErr with one of the following error codes, allowing the egress the option to correct the error in a new Resv message, or to tear down the LSP with a PathErr with the Path_State_Removed flag set. An ingress that uses the ResvErr MUST take precautions against a protocol loop where the egress responds with the same LSP_TUNNEL_INTERFACE_ID object with the same (or different) issues.
当入口LSR在Resv消息上接收到LSP_TUNNEL_INTERFACE_ID对象时，由于对象中的某些参数设置，它可能需要拒绝该对象。由于这些原因都表示错误，而不是可协商参数的不匹配，因此入口应以PathTrain响应以删除LSP。入口可使用带有以下错误代码之一的ResvErr，允许出口选择更正新Resv消息中的错误，或使用设置了Path_State_Removed标志的PathErr来拆除LSP。使用ResvErr的入口必须对协议循环采取预防措施，其中出口使用具有相同（或不同）问题的相同LSP_TUNNEL_INTERFACE_ID对象进行响应。
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 11 Link address type or family not supported
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
38 16 Component link identifier missing
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 11 Link address type or family not supported
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
38 16 Component link identifier missing
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class number of 193. According to [RFC2205], this means that a node that does not understand the object SHOULD ignore the object but forward it, unexamined and unmodified. Thus, there are no issues with transit LSRs supporting the pre-existing or new Class Types of this object.
[RFC3477]中定义的LSP_TUNNEL_INTERFACE_ID对象的类号为193。根据[RFC2205]，这意味着不理解该对象的节点应该忽略该对象，而是转发它，未经检查和修改。因此，公交LSR支持此对象的现有或新类类型不存在任何问题。
A back-level ingress node will behave as follows:
后台入口节点的行为如下所示：
- It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID objects with the new Class Types defined in this document.
- 它不会发出包含LSP_TUNNEL_INTERFACE_ID对象的路径消息，这些对象具有本文档中定义的新类类型。
- It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID objects with the new Class Types defined in this document as described in [RFC2205]. In any case, such a situation would represent an error by the egress.
- 它将拒绝包含LSP_TUNNEL_INTERFACE_ID对象的Resv消息，该对象具有[RFC2205]中所述的本文档中定义的新类类型。在任何情况下，这种情况都将代表出口的错误。
- It will continue to use the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 as defined in [RFC3477]. This behavior is supported by back-level egresses and by egresses conforming to this document.
- 它将继续使用[RFC3477]中定义的类类型为1的LSP_TUNNEL_INTERFACE_ID对象。该行为由后台出口和符合本文件要求的出口支持。
- According to an informal survey, there is no significant deployment of numbered FA establishment following the procedures defined in [RFC4206] and set out in Section 1.3.6 of this document. It is therefore safe to assume that back-level ingress LSRs will not use this mechanism.
- 根据一项非正式调查，按照[RFC4206]中定义的程序和本文件第1.3.6节中规定的程序，没有对编号FA机构进行重大部署。因此，可以安全地假设后级入口LSR不会使用此机制。
A back-level egress node will behave as follows:
后台出口节点的行为如下所示：
- It will continue to support the LSP_TUNNEL_INTERFACE_ID object with Class Type 1, as defined in [RFC3477], if issued by an ingress.
- 它将继续支持类类型为1的LSP_TUNNEL_INTERFACE_ID对象，如[RFC3477]中所定义，如果由入口发出。
- It will reject a Path message that carries an LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types defined in this document using the procedures of [RFC2205]. This will inform the ingress that the egress is a back-level LSR.
- 它将使用[RFC2205]中的过程拒绝包含LSP_TUNNEL_INTERFACE_ID对象和本文档中定义的任何新类类型的路径消息。这将通知入口出口为后级LSR。
- It will not expect to use the procedures for numbered FA establishment defined in [RFC4206] and set out in Section 1.3.6 of this document.
- 不希望使用[RFC4206]中定义的和本文件第1.3.6节中规定的编号FA编制程序。
In summary, the new mechanisms defined in this document do not impact the method to exchange unnumbered FA information described in [RFC3477]. That mechanism can be safely used in combination with the new mechanisms described here and is functionally equivalent to using the new C-Type indicating an unnumbered link with target IGP instance identifier with the Target IGP Instance value set to 0xffffffff.
总之，本文件中定义的新机制不会影响[RFC3477]中描述的交换未编号FA信息的方法。该机制可以安全地与这里描述的新机制结合使用，并且在功能上等同于使用新的C-Type，该C-Type指示具有目标IGP实例标识符且目标IGP实例值设置为0xffffff的未编号链路。
The mechanisms in this document obsolete the method to exchange the numbered FA information described in [RFC4206] as described in Section 1.4.6.
本文件中的机制淘汰了第1.4.6节所述的交换[RFC4206]中所述编号FA信息的方法。
[RFC3477] points out that one can argue that the use of the extra interface identifier that it provides could make an RSVP message harder to spoof. In that respect, the minor extensions to the protocol made in this document do not constitute an additional security risk, but could also be said to improve security.
[RFC3477]指出，可以认为，使用它提供的额外接口标识符可能会使RSVP消息更难伪造。在这方面，本文件中对《议定书》所作的微小扩展并不构成额外的安全风险，但也可以说是提高了安全性。
It should be noted that the ability of an ingress LSR to request that an egress LSR advertise an LSP as a TE link MUST be subject to appropriate policy checks at the egress LSR. That is, the egress LSR MUST NOT automatically accept the word of the ingress unless it is configured with such a policy.
应当注意，入口LSR请求出口LSR将LSP作为TE链路进行广告的能力必须受到出口LSR处的适当策略检查的约束。也就是说，出口LSR不得自动接受入口的字，除非其配置了这样的策略。
Further details of security for MPLS-TE and GMPLS can be found in [RFC5920].
有关MPLS-TE和GMPLS安全性的更多详细信息，请参见[RFC5920]。
IANA maintains a registry of RSVP parameters called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Class Names, Class Numbers, and Class Types". There is an entry in this registry for the LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] with one Class Type defined.
IANA维护一个名为“资源保留协议（RSVP）参数”的RSVP参数注册表，以及一个名为“类名、类号和类类型”的子注册表。此注册表中有[RFC3477]中定义的LSP_TUNNEL_INTERFACE_ID对象的条目，其中定义了一种类类型。
IANA has allocated three new Class Types for this object as defined in Sections 3.1.2, 3.1.3, and 3.1.4 as follows:
IANA为该对象分配了三种新的类类型，如第3.1.2、3.1.3和3.1.4节所定义，如下所示：
C-Type Meaning Reference
---------------------------------------------------------------
2 IPv4 interface identifier with target [RFC6107]
3 IPv6 interface identifier with target [RFC6107]
4 Unnumbered interface with target [RFC6107]
C-Type Meaning Reference
---------------------------------------------------------------
2 IPv4 interface identifier with target [RFC6107]
3 IPv6 interface identifier with target [RFC6107]
4 Unnumbered interface with target [RFC6107]
Section 3.1.2 defines an 8-bit flags field in the LSP_TUNNEL_INTERFACE_ID object. IANA has created a new sub-registry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry called the "Hierarchy Actions" sub-registry as follows:
第3.1.2节定义了LSP_TUNNEL_INTERFACE_ID对象中的8位标志字段。IANA创建了一个新的“通用多协议标签交换（GMPLS）信令参数”注册表子注册表，称为“层次结构操作”子注册表，如下所示：
Registry Name: Hierarchy Actions Reference: [RFC6107] Registration Procedures: Standards Action
注册表名称：层次结构操作参考：[RFC6107]注册过程：标准操作
Registry:
Bit Number Hex Value Name Reference
---------- ----------- ----------------------- ---------
0-2 Unassigned
3 0x10 Hierarchy/stitching (H) [RFC6107]
4 0x08 Bundle (B) [RFC6107]
5 0x04 Routing adjacency (R) [RFC6107]
6 0x02 TE link (T) [RFC6107]
7 0x01 Private (P) [RFC6107]
Registry:
Bit Number Hex Value Name Reference
---------- ----------- ----------------------- ---------
0-2 Unassigned
3 0x10 Hierarchy/stitching (H) [RFC6107]
4 0x08 Bundle (B) [RFC6107]
5 0x04 Routing adjacency (R) [RFC6107]
6 0x02 TE link (T) [RFC6107]
7 0x01 Private (P) [RFC6107]
IANA maintains a registry of RSVP error codes and error values as the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry.
IANA维护RSVP错误代码和错误值的注册表，作为“资源保留协议（RSVP）参数”注册表的“错误代码和全局定义的错误值子代码”子注册表。
IANA has defined a new error code with value 38 as below (see also Section 3.6).
IANA定义了一个值为38的新错误代码，如下所示（另见第3.6节）。
Error Code Meaning
错误代码含义
38 LSP Hierarchy Issue [RFC6107]
38 LSP层次结构问题[RFC6107]
IANA has listed the following error values for this error code (see also Section 3.6).
IANA为此错误代码列出了以下错误值（另请参见第3.6节）。
This Error Code has the following globally-defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
1 = Link advertisement not supported [RFC6107]
2 = Link advertisement not allowed by policy [RFC6107]
3 = TE link creation not supported [RFC6107]
4 = TE link creation not allowed by policy [RFC6107]
5 = Routing adjacency creation not supported [RFC6107]
6 = Routing adjacency creation not allowed by policy [RFC6107]
7 = Bundle creation not supported [RFC6107]
8 = Bundle creation not allowed by policy [RFC6107]
9 = Hierarchical LSP not supported [RFC6107]
10 = LSP stitching not supported [RFC6107]
11 = Link address type or family not supported [RFC6107]
12 = IGP instance unknown [RFC6107]
13 = IGP instance advertisement not allowed by policy [RFC6107]
14 = Component link identifier not valid [RFC6107]
15 = Unsupported component link identifier address [RFC6107]
family
16 = Component link identifier missing [RFC6107]
1 = Link advertisement not supported [RFC6107]
2 = Link advertisement not allowed by policy [RFC6107]
3 = TE link creation not supported [RFC6107]
4 = TE link creation not allowed by policy [RFC6107]
5 = Routing adjacency creation not supported [RFC6107]
6 = Routing adjacency creation not allowed by policy [RFC6107]
7 = Bundle creation not supported [RFC6107]
8 = Bundle creation not allowed by policy [RFC6107]
9 = Hierarchical LSP not supported [RFC6107]
10 = LSP stitching not supported [RFC6107]
11 = Link address type or family not supported [RFC6107]
12 = IGP instance unknown [RFC6107]
13 = IGP instance advertisement not allowed by policy [RFC6107]
14 = Component link identifier not valid [RFC6107]
15 = Unsupported component link identifier address [RFC6107]
family
16 = Component link identifier missing [RFC6107]
The authors would like to thank Lou Berger, Deborah Brungard, John Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable discussions and comments.
作者要感谢Lou Berger、Deborah Brungard、John Drake、Yakov Rekhter、Igor Bryskin和Lucy Yong的宝贵讨论和评论。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]迪林，S.，编辑，“ICMP路由器发现消息”，RFC1256，1991年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 52122008年7月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308]Hopps，C.，“使用IS-IS路由IPv6”，RFC5308，2008年10月。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.
[RFC5329]Ishiguro，K.，Manral，V.，Davey，A.，和A.Lindem，Ed.，“OSPF版本3的流量工程扩展”，RFC 53292008年9月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[ISIS-GENAP] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", Work in Progress, November 2010.
[ISIS-GENAP]Ginsberg，L.，Previdi，S.，和M.Shand，“IS-IS中的广告通用信息”，正在进行的工作，2010年11月。
[ISIS-IPV6-TE] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", Work in Progress, September 2010.
[ISIS-IPV6-TE]Harrison，J.，Berger，J.，和M.Bartlett，“IS-IS中的IPV6流量工程”，正在进行的工作，2010年9月。
[OSPF-TI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport Instance Extensions", Work in Progress, October 2010.
[OSPF-TI]Lindem，A.，Roy，A.，和S.Mirtorabi，“OSPF传输实例扩展”，正在进行的工作，2010年10月。
[OSPFv2-MI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi-Instance Extensions", Work in Progress, October 2010.
[OSPFv2 MI]Lindem，A.，Roy，A.，和S.Mirtorabi，“OSPF多实例扩展”，正在进行的工作，2010年10月。
[PCE-LAYER] Takeda, T., Ed., and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Work in Progress, December 2010.
[PCE-LAYER]武田，T.，Ed.，和A.Farrel，“层间流量工程的PCC-PCE通信和PCE发现要求”，正在进行的工作，2010年12月。
Authors' Addresses
作者地址
Richard Rabbat Google Inc. 1600 Amphitheatre Pkwy Mountain View, CA 94043 United States of America EMail: rabbat@alum.mit.edu
Richard Rabbat Google Inc.1600圆形剧场美国加利福尼亚州Pkwy山景城94043电子邮件：rabbat@alum.mit.edu
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America EMail: arthi@juniper.net
Arthi Ayangar Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美利坚合众国电子邮件：arthi@juniper.net
Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: zali@cisco.com
Zafar Ali Cisco Systems，Inc.加拿大安大略省卡纳塔市创新大道2000号K2K 3E8电子邮件：zali@cisco.com
Editors' Addresses
编辑地址
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
Kohei Shiomoto NTT网络服务系统实验室3-9-11 Midori Musashino，东京180-8585日本电话：+81 422 59 4402电子邮件：Shiomoto。kohei@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk