Network Working Group K. Kompella
Request for Comments: 4206 Y. Rekhter
Category: Standards Track Juniper Networks
October 2005
Network Working Group K. Kompella
Request for Comments: 4206 Y. Rekhter
Category: Standards Track Juniper Networks
October 2005
Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).
为了提高通用多协议标签交换（GMPLS）的可伸缩性，可以通过创建此类LSP的层次结构来聚合标签交换路径（LSP）。创建这种层次结构的一种方法是：（A）标签交换路由器（LSR）创建流量工程标签交换路径（TE LSP），（b）LSR从该LSP形成转发邻接（FA）（通过将该LSP作为流量工程（TE）链路宣传到与用于创建LSP的ISIS/OSPF相同的ISIS/OSPF实例），（c）允许其他LSR使用FAs进行路径计算，以及（d）将其他LSR发起的LSP嵌套到该LSP中（通过使用标签堆栈构造）。
This document describes the mechanisms to accomplish this.
本文档描述了实现这一点的机制。
Table of Contents
目录
1. Overview ........................................................2
2. Specification of Requirements ...................................3
3. Routing Aspects .................................................4
3.1. Traffic Engineering Parameters .............................4
3.1.1. Link Type (OSPF Only) ...............................5
3.1.2. Link ID (OSPF Only) .................................5
3.1.3. Local and Remote Interface IP Address ...............5
3.1.4. Local and Remote Link Identifiers ...................5
3.1.5. Traffic Engineering Metric ..........................5
3.1.6. Maximum Bandwidth ...................................5
3.1.7. Unreserved Bandwidth ................................5
3.1.8. Resource Class/Color ................................5
3.1.9. Interface Switching Capability ......................6
3.1.10. SRLG Information ...................................6
4. Other Considerations ............................................6
5. Controlling FA-LSPs Boundaries ..................................7
5.1. LSP Regions ................................................7
6. Signalling Aspects ..............................................8
6.1. Common Procedures ..........................................8
6.1.1. RSVP-TE .............................................8
6.1.2. CR-LDP ..............................................9
6.2. Specific Procedures .......................................10
6.3. FA-LSP Holding Priority ...................................11
7. Security Considerations ........................................11
8. Acknowledgements ...............................................12
9. Normative References ...........................................12
10. Informative References ........................................13
1. Overview ........................................................2
2. Specification of Requirements ...................................3
3. Routing Aspects .................................................4
3.1. Traffic Engineering Parameters .............................4
3.1.1. Link Type (OSPF Only) ...............................5
3.1.2. Link ID (OSPF Only) .................................5
3.1.3. Local and Remote Interface IP Address ...............5
3.1.4. Local and Remote Link Identifiers ...................5
3.1.5. Traffic Engineering Metric ..........................5
3.1.6. Maximum Bandwidth ...................................5
3.1.7. Unreserved Bandwidth ................................5
3.1.8. Resource Class/Color ................................5
3.1.9. Interface Switching Capability ......................6
3.1.10. SRLG Information ...................................6
4. Other Considerations ............................................6
5. Controlling FA-LSPs Boundaries ..................................7
5.1. LSP Regions ................................................7
6. Signalling Aspects ..............................................8
6.1. Common Procedures ..........................................8
6.1.1. RSVP-TE .............................................8
6.1.2. CR-LDP ..............................................9
6.2. Specific Procedures .......................................10
6.3. FA-LSP Holding Priority ...................................11
7. Security Considerations ........................................11
8. Acknowledgements ...............................................12
9. Normative References ...........................................12
10. Informative References ........................................13
An LSR uses Generalized MPLS (GMPLS) TE procedures to create and maintain an LSP. The LSR then may (under local configuration control) announce this LSP as a Traffic Engineering (TE) link into the same instance of the GMPLS control plane (or, more precisely, its ISIS/OSPF component) as the one that was used to create the LSP. We call such a link a "forwarding adjacency" (FA). We refer to the LSP as the "forwarding adjacency LSP", or just FA-LSP. Note that an FA-LSP is both created and used as a TE link by exactly the same instance of the GMPLS control plane. Thus, the concept of an FA is applicable only when an LSP is both created and used as a TE link by exactly the same instance of the GMPLS control plane. Note also that an FA is a TE link between two GMPLS nodes whose path transits zero or more (G)MPLS nodes in the same instance of the GMPLS control plane.
LSR使用通用MPLS（GMPLS）TE过程来创建和维护LSP。然后，LSR可以（在本地配置控制下）将此LSP作为流量工程（TE）链路宣布到GMPLS控制平面（或者更准确地说，其ISIS/OSPF组件）的同一实例中，作为用于创建LSP的实例。我们称这种链接为“转发邻接”（FA）。我们将LSP称为“转发邻接LSP”，或简称FA-LSP。请注意，FA-LSP由GMPLS控制平面的同一实例创建并用作TE链路。因此，FA的概念仅当LSP被GMPLS控制平面的完全相同实例创建并用作TE链路时才适用。还要注意，FA是两个GMPLS节点之间的TE链路，其路径在GMPLS控制平面的同一实例中通过零个或多个（G）MPLS节点。
The nodes connected by a 'basic' TE link may have a routing adjacency; however, the nodes connected by an FA would not usually have a routing adjacency. A TE link of any kind (either 'basic' or FA) would have to have a signaling adjacency in order for it to be used to establish an LSP across it.
由“基本”TE链路连接的节点可以具有路由邻接；然而，由FA连接的节点通常不会有路由邻接。任何类型的TE链路（无论是“基本”还是FA）都必须具有信令邻接才能用于在其上建立LSP。
In general, the creation/termination of an FA and its FA-LSP could be driven either by mechanisms outside of GMPLS (e.g., via configuration control on the LSR at the head-end of the adjacency), or by mechanisms within GMPLS (e.g., as a result of the LSR at the head-end of the adjacency receiving LSP setup requests originated by some other LSRs).
一般来说，FA及其FA-LSP的创建/终止可以由GMPLS之外的机制驱动（例如，通过邻接前端LSR上的配置控制），或者由GMPLS内的机制驱动（例如，由于邻接前端的LSR接收由一些其他LSR发起的LSP设置请求）。
ISIS/OSPF floods the information about FAs just as it floods the information about any other links. As a result of this flooding, an LSR has in its TE link state database the information about not just basic TE links, but FAs as well.
ISIS/OSPF大量传播有关FAs的信息，就像它大量传播有关任何其他链接的信息一样。由于这种泛滥，LSR在其TE链路状态数据库中不仅包含基本TE链路的信息，还包含FAs的信息。
An LSR, when performing path computation, uses not just basic TE links, but FAs as well. Once a path is computed, the LSR uses RSVP/CR-LDP [RSVP-TE, CR-LDP] for establishing label binding along the path.
LSR在执行路径计算时，不仅使用基本TE链路，还使用FAs。一旦计算出路径，LSR使用RSVP/CR-LDP[RSVP-TE，CR-LDP]沿路径建立标签绑定。
In this document we define mechanisms/procedures to accomplish the above. These mechanisms/procedures cover both the routing (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects.
在本文件中，我们定义了实现上述目标的机制/程序。这些机制/程序涵盖路由（ISIS/OSPF）和信令（RSVP/CR-LDP）两个方面。
Note that an LSP may be advertised as a point-to-point link into ISIS or OSPF, to be used in normal SPF by nodes other than the head-end. While this is similar in spirit to an FA, this is beyond the scope of this document.
注意，LSP可以作为到ISIS或OSPF的点对点链路进行广告，由除前端之外的节点在正常SPF中使用。虽然这在精神上类似于FA，但这超出了本文件的范围。
Scenarios where an LSP is created (and maintained) by one instance of the GMPLS control plane, and is used as a (TE) link by another instance of the GMPLS control plane, are outside the scope of this document.
LSP由GMPLS控制平面的一个实例创建（和维护），并由GMPLS控制平面的另一个实例用作（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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
In this section we describe procedures for constructing FAs out of LSPs, and handling of FAs by ISIS/OSPF. Specifically, this section describes how to construct the information needed to advertise LSPs as links into ISIS/OSPF. Procedures for creation/termination of such LSPs are defined in Section 5, "Controlling FA-LSPs boundaries".
在本节中，我们描述了从LSP构建FAs的程序，以及ISIS/OSPF对FAs的处理。具体而言，本节描述了如何构建将LSP作为链接发布到ISIS/OSPF所需的信息。创建/终止此类LSP的程序见第5节“控制FA LSP边界”。
FAs may be represented as either unnumbered or numbered links. If FAs are numbered with IPv4 addresses, the local and remote IPv4 addresses come out of a /31 that is allocated by the LSR that originates the FA-LSP; the head-end address of the FA-LSP is the one specified as the IPv4 tunnel sender address; the remote (tail-end) address can then be inferred. If the LSP is bidirectional, the tail-end can thus know the addresses to assign to the reverse FA.
FAs可以表示为未编号或编号的链接。如果FA使用IPv4地址进行编号，则本地和远程IPv4地址来自发起FA-LSP的LSR分配的a/31；FA-LSP的头端地址是指定为IPv4隧道发送方地址的地址；然后可以推断远程（尾部）地址。如果LSP是双向的，那么后端可以知道要分配给反向FA的地址。
If there are multiple LSPs that all originate on one LSR and all terminate on another LSR, then at one end of the spectrum all these LSPs could be merged (under control of the head-end LSR) into a single FA using the concept of Link Bundling (see [BUNDLE]); while at the other end of the spectrum each such LSP could be advertised as its own adjacency.
如果存在多个LSP，它们都起源于一个LSR，并且都终止于另一个LSR，那么在频谱的一端，可以使用链路捆绑的概念将所有这些LSP（在前端LSR的控制下）合并到单个FA中（参见[捆绑]）；而在频谱的另一端，每一个这样的LSP都可以作为它自己的邻接进行宣传。
When an FA is created under administrative control (static provisioning), the attributes of the FA-LSP have to be provided via configuration. Specifically, the following attributes may be configured for the FA-LSP: the head-end address (if left unconfigured, this defaults to the head-end LSR's Router ID); the tail-end address; bandwidth and resource colors constraints. The path taken by the FA-LSP may be either computed by the LSR at the head-end of the FA-LSP, or specified by explicit configuration; this choice is determined by configuration.
在管理控制（静态资源调配）下创建FA时，必须通过配置提供FA-LSP的属性。具体而言，可以为FA-LSP配置以下属性：前端地址（如果未配置，则默认为前端LSR的路由器ID）；尾端地址；带宽和资源限制。FA-LSP采用的路径可以由FA-LSP前端的LSR计算，或者由显式配置指定；此选项由配置决定。
When an FA is created dynamically, the attributes of its FA-LSP are inherited from the LSP that induced its creation. Note that the bandwidth of the FA-LSP must be at least as big as the LSP that induced it, but may be bigger if only discrete bandwidths are available for the FA-LSP. In general, for dynamically provisioned FAs, a policy-based mechanism may be needed to associate attributes to the FA-LSPs.
动态创建FA时，其FA-LSP的属性将从导致其创建的LSP继承。请注意，FA-LSP的带宽必须至少与引起它的LSP一样大，但如果FA-LSP只有离散带宽可用，则可能更大。通常，对于动态配置的FA，可能需要基于策略的机制将属性关联到FA LSP。
In this section, the Traffic Engineering parameters (see [OSPF-TE] and [ISIS-TE]) for FAs are described.
本节介绍了FAs的流量工程参数（见[OSPF-TE]和[ISIS-TE]）。
The Link Type of an FA is set to "point-to-point".
FA的链接类型设置为“点对点”。
The Link ID is set to the Router ID of the tail-end of FA-LSP.
链路ID设置为FA-LSP后端的路由器ID。
If the FA is to be numbered, the local interface IP address (OSPF) or IPv4 interface address (ISIS) is set to the head-end address of the FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor address (ISIS) is set to the tail-end address of the FA-LSP.
如果要对FA进行编号，则将本地接口IP地址（OSPF）或IPv4接口地址（ISIS）设置为FA-LSP的前端地址。远程接口IP地址（OSPF）或IPv4邻居地址（ISIS）设置为FA-LSP的后端地址。
For an unnumbered FA, the assignment and handling of the local and remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP].
对于未编号的FA，本地和远程链路标识符的分配和处理在[UNNUM-RSVP]、[UNNUM-CRLDP]中指定。
By default the TE metric on the FA is set to max(1, (the TE metric of the FA-LSP path) - 1) so that it attracts traffic in preference to setting up a new LSP. This may be overridden via configuration at the head-end of the FA.
默认情况下，FA上的TE度量设置为max（1，（FA-LSP路径的TE度量）-1），以便它优先于设置新LSP来吸引流量。这可以通过FA前端的配置来覆盖。
By default, the Maximum Reservable Bandwidth and the initial Maximum LSP Bandwidth for all priorities of the FA is set to the bandwidth of the FA-LSP. These may be overridden via configuration at the head-end of the FA (note that the Maximum LSP Bandwidth at any one priority should be no more than the bandwidth of the FA-LSP).
默认情况下，FA的所有优先级的最大可保留带宽和初始最大LSP带宽设置为FA-LSP的带宽。这些可以通过FA前端的配置来覆盖（注意，任何一个优先级的最大LSP带宽不应超过FA-LSP的带宽）。
The initial unreserved bandwidth for all priority levels of the FA is set to the bandwidth of the FA-LSP.
FA的所有优先级的初始无保留带宽设置为FA-LSP的带宽。
By default, an FA does not have resource colors (administrative groups). This may be overridden by configuration at the head-end of the FA.
默认情况下，FA没有资源颜色（管理组）。这可能会被FA前端的配置所覆盖。
The (near-end) Interface Switching Capability associated with the FA is the (near end) Interface Switching Capability of the first link in the FA-LSP.
与FA相关联的（近端）接口交换能力是FA-LSP中第一条链路的（近端）接口交换能力。
When the (near-end) Interface Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the specific information includes Interface MTU and Minimum LSP Bandwidth. The Interface MTU is the minimum MTU along the path of the FA-LSP; the Minimum LSP Bandwidth is the bandwidth of the LSP.
当（近端）接口交换能力字段为PSC-1、PSC-2、PSC-3或PSC-4时，具体信息包括接口MTU和最小LSP带宽。接口MTU是沿FA-LSP路径的最小MTU；最小LSP带宽是LSP的带宽。
An FA advertisement could contain the information about the Shared Risk Link Groups (SRLG) for the path taken by the FA-LSP associated with that FA. This information may be used for path calculation by other LSRs. The information carried is the union of the SRLGs of the underlying TE links that make up the FA-LSP path; it is carried in the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF. See [GMPLS-ISIS, GMPLS-OSPF] for details on the format of this information.
FA广告可以包含与该FA相关的FA-LSP所走路径的共享风险链接组（SRLG）信息。此信息可用于其他LSR的路径计算。所携带的信息是构成FA-LSP路径的基础TE链路的SRLGs的并集；它在is-is中的SRLG TLV或OSPF中TE链路TLV的SRLG子TLV中携带。有关此信息格式的详细信息，请参见[GMPLS-ISIS，GMPLS-OSPF]。
It is possible that the underlying path information might change over time, via configuration updates or dynamic route modifications, resulting in the change of the SRLG TLV.
通过配置更新或动态路由修改，底层路径信息可能会随着时间的推移而改变，从而导致SRLG TLV的改变。
If FAs are bundled (via link bundling), and if the resulting bundled link carries an SRLG TLV, it MUST be the case that the list of SRLGs in the underlying path, followed by each of the FA-LSPs that form the component links, is the same (note that the exact paths need not be the same).
如果FAs被捆绑（通过链路捆绑），并且如果生成的捆绑链路携带SRLG TLV，则基础路径中的SRLGs列表以及构成组件链路的每个FA LSP必须相同（请注意，确切路径不必相同）。
It is expected that FAs will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency.
预计FAs不会用于在相邻端的路由器之间建立ISIS/OSPF对等关系。
It may be desired in some cases to use FAs only in Traffic Engineering path computations. In IS-IS, this can be accomplished by setting the default metric of the extended IS reachability TLV for the FA to the maximum link metric (2^24 - 1). In OSPF, this can be accomplished by not advertising the link as a regular LSA, but only as a TE opaque LSA.
在某些情况下，可能需要仅在交通工程路径计算中使用FAs。在IS-IS中，这可以通过将FA的扩展IS可达性TLV的默认度量设置为最大链路度量（2^24-1）来实现。在OSPF中，这可以通过不作为常规LSA而仅作为TE不透明LSA宣传链路来实现。
To facilitate controlling the boundaries of FA-LSPs, this document introduces two new mechanisms: Interface Switching Capability (see [GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region").
为了便于控制FA LSP的边界，本文件引入了两种新机制：接口交换能力（参见[GMPLS-ISIS，GMPLS-OSPF]）和“LSP区域”（或仅“区域”）。
The information carried in the Interface Switching Capabilities is used to construct LSP regions and to determine regions' boundaries as follows.
接口交换能力中携带的信息用于构建LSP区域，并确定区域边界，如下所示。
Define an ordering among interface switching capabilities as follows: PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two interfaces if-1 and if-2 with interface switching capabilities isc-1 and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than if-2's max LSP bandwidth.
定义接口交换能力之间的顺序如下：PSC-1<PSC-2<PSC-3<PSC-4<TDM<LSC<FSC。给定两个分别具有接口交换能力isc-1和isc-2的接口if-1和if-2，假设if-1<if-2 iff isc-1<isc-2或isc-1==isc-2==TDM，if-1的最大LSP带宽小于if-2的最大LSP带宽。
Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, node-2, ..., link-n, node-n. Moreover, for link-i denote by [link-i, node-(i-1)] the interface that connects link-i to node-(i-1), and by [link-i, node-i] the interface that connects link-i to node-i.
假设LSP的路径如下：节点0、链路1、节点1、链路2、节点2、…、链路n、节点n。此外，对于link-i，用[link-i，node-（i-1）]表示将link-i连接到节点-（i-1）的接口，用[link-i，node-i]表示将link-i连接到节点-i的接口。
If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the LSP has crossed a region boundary at node-i; with respect to that LSP path, the LSR at node-i is an edge LSR. The 'other edge' of the region with respect to the LSP path is node-k, where k is the smallest number greater than i such that [link-(i+1), node-(i+1)] equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k, node-k].
如果[link-（i+1），node-i）]<[link-（i+1），node-（i+1）]，则我们说LSP已经越过了node-i处的区域边界；关于该LSP路径，节点i处的LSR是边缘LSR。关于LSP路径的区域的“另一边缘”是node-k，其中k是大于i的最小数，使得[link-（i+1），node-（i+1）]等于[link-k，node-（k-1）]，并且[link-k，node-（k-1）]>[link-k，node-k]。
Path computation may take region boundaries into account when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose Interface Switching Capability is PSC-1.
当计算LSP的路径时，路径计算可以考虑区域边界。例如，路径计算可将LSP采用的路径限制为仅其接口交换能力为PSC-1的链路。
Note that an interface may have multiple Interface Switching Capabilities. In such a case, the test is whether if-i < if-j depends on the Interface Switching Capabilities chosen for if-i and if-j, which in turn determines whether or not there is a region boundary at node-i.
请注意，一个接口可能具有多个接口切换功能。在这种情况下，测试if-i是否<if-j取决于为if-i和if-j选择的接口切换能力，这反过来决定节点i处是否存在区域边界。
In this section we describe procedures that an LSR at the head-end of an FA uses for handling LSP setup originated by other LSR.
在本节中，我们描述了FA前端的LSR用于处理由其他LSR发起的LSP设置的过程。
As we mentioned before, establishment/termination of FA-LSPs may be triggered either by mechanisms outside of GMPLS (e.g., via administrative control), or by mechanisms within GMPLS (e.g., as a result of the LSR at the edge of an aggregate LSP receiving LSP setup requests originated by some other LSRs beyond LSP aggregate and its edges). Procedures described in Section 6.1, "Common Procedures", apply to both cases. Procedures described in Section 6.2, "Specific Procedures", apply only to the latter case.
如前所述，FA LSP的建立/终止可能由GMPLS之外的机制（例如，通过行政控制）或GMPLS内的机制触发（例如，由于聚合LSP边缘的LSR接收LSP聚合及其边缘以外的其他LSR发出的LSP设置请求）。第6.1节“通用程序”中描述的程序适用于这两种情况。第6.2节“特定程序”中描述的程序仅适用于后一种情况。
For the purpose of processing the ERO in a Path/Request message of an LSP that is to be tunneled over an FA, an LSR at the head-end of the FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP hop away).
为了处理要在FA上进行隧道传输的LSP的路径/请求消息中的ERO，FA-LSP前端的LSR将该FA-LSP尾部的LSR视为相邻（一个IP跳）。
How this is to be achieved for RSVP-TE and CR-LDP is described in the following subsections.
以下小节描述了如何为RSVP-TE和CR-LDP实现这一点。
In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's bandwidth from the unreserved bandwidth of the FA.
在任何一种情况下（RSVP-TE或CR-LDP），当LSP通过FA-LSP进行隧道传输时，FA-LSP前端的LSR从FA的未保留带宽中减去LSP的带宽。
In the presence of link bundling (when link bundling is applied to FAs), when an LSP is tunneled through an FA-LSP, the LSR at the head-end of the FA-LSP also needs to adjust Max LSP bandwidth of the FA.
在存在链路捆绑的情况下（当链路捆绑应用于FAs时），当LSP通过FA-LSP隧道时，FA-LSP前端的LSR也需要调整FA的最大LSP带宽。
If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP, then the Path message MUST contain an IF_ID RSVP_HOP object [GRSVP-TE, GSIG] instead of an RSVP_HOP object; and the data interface identification MUST identify the FA-LSP.
如果使用RSVP-TE向要通过FA-LSP进行隧道传输的LSP发送信号，则路径消息必须包含If_ID RSVP_HOP对象[GRSVP-TE，GSIG]，而不是RSVP_HOP对象；数据接口标识必须标识FA-LSP。
The preferred method of sending the Path message is to set the destination IP address of the Path message to the computed NHOP for that Path message. This NHOP address must be a routable address; in the case of separate control and data planes, this must be a control plane address.
发送路径消息的首选方法是将路径消息的目标IP地址设置为该路径消息的计算NHOP。该NHOP地址必须是可路由地址；对于单独的控制平面和数据平面，这必须是控制平面地址。
Furthermore, the IP header for the Path message MUST NOT have the Router Alert option. The Path message is intended to be IP-routed to the tail-end of the FA-LSP without being intercepted and processed as an RSVP message by any of the intermediate nodes.
此外，Path消息的IP标头不得具有路由器警报选项。Path消息旨在IP路由到FA-LSP的后端，而不被任何中间节点截获并作为RSVP消息处理。
Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general, if the IF_ID RSVP_HOP object is used, this check must be disabled, as the number of hops over the control plane may be greater than one. Instead, the following check is done by the receiver Y of the IF_ID RSVP_HOP object:
最后，不得进行IP TTL与RSVP TTL检查。通常，如果使用if_ID RSVP_HOP对象，则必须禁用此检查，因为控制平面上的跳数可能大于一。相反，以下检查由IF_ID RSVP_HOP对象的接收器Y执行：
1. Make sure that the data interface identified in the IF_ID RSVP_HOP object actually terminates on Y.
1. 确保IF_ID RSVP_HOP对象中标识的数据接口实际上在Y上终止。
2. Find the "other end" of the above data interface, say X. Make sure that the PHOP in the IF_ID RSVP_HOP object is a control channel address that belongs to the same node as X.
2. 找到上述数据接口的“另一端”，例如X。确保IF_ID RSVP_HOP对象中的PHOP是与X属于同一节点的控制通道地址。
How check #2 is carried out is beyond the scope of this document; suffice it to say that it may require a Traffic Engineering Database, or the use of LMP [LMP], or yet other means.
如何进行检查#2超出了本文件的范围；只需说它可能需要一个交通工程数据库，或者使用LMP[LMP]，或者其他方式。
An alternative method is to encapsulate the Path message in an IP tunnel (or, in the case that the Interface Switching Capability of the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the message to the tail-end of the FA-LSP, without the Router Alert option. This option may be needed if intermediate nodes process RSVP messages regardless of whether the Router Alert option is present.
另一种方法是将路径消息封装在IP隧道中（或者，在FA-LSP的接口交换能力为PSC[1-4]的情况下，封装在FA-LSP本身中），并将消息单播到FA-LSP的尾部，而不使用路由器警报选项。如果中间节点处理RSVP消息，则无论是否存在路由器警报选项，都可能需要此选项。
A PathErr sent in response to a Path message with an IF_ID RSVP_HOP object SHOULD contain an IF_ID HOP object. (Note: a PathErr does not normally carry an RSVP_HOP object, but in the case of separated control and data, it is necessary to identify the data channel in the PathErr message.)
为响应带有IF\u ID RSVP\u HOP对象的路径消息而发送的PathErr应包含IF\u ID HOP对象。（注意：PathErr通常不携带RSVP_-HOP对象，但在控制和数据分离的情况下，有必要在PathErr消息中标识数据通道。）
The Resv message back to the head-end of the FA-LSP (PHOP) is IP-routed to the PHOP in the Path message. If necessary, Resv Messages MAY be encapsulated in another IP header whose destination IP address is the PHOP of the received Path message.
返回FA-LSP（PHOP）前端的Resv消息通过IP路由到Path消息中的PHOP。如有必要，Resv消息可以封装在另一个IP报头中，其目的IP地址是所接收路径消息的PHOP。
If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP, then the Request message MUST contain an IF_ID TLV [GCR-LDP] object, and the data interface identification MUST identify the FA-LSP.
如果使用CR-LDP向要通过FA-LSP进行隧道传输的LSP发送信号，则请求消息必须包含If_ID TLV[GCR-LDP]对象，并且数据接口标识必须标识FA-LSP。
Furthermore, the head-end LSR must create a targeted LDP session with the tail-end LSR. The Request (Mapping) message is unicast from the head-end (tail-end) to the tail-end (head-end).
此外，前端LSR必须与后端LSR创建目标LDP会话。请求（映射）消息从前端（后端）单播到后端（前端）。
When an LSR receives a Path/Request message, the LSR determines whether it is at the edge of a region with respect to the ERO carried in the message. The LSR does this by looking up the interface switching capabilities of the previous hop and the next hop in its IGP database, and comparing them using the relation defined in this section. If the LSR is not at the edge of a region, the procedures in this section do not apply.
当LSR接收到路径/请求消息时，LSR确定其是否位于相对于消息中所携带的ERO的区域边缘。LSR通过在其IGP数据库中查找前一个跃点和下一个跃点的接口交换能力，并使用本节中定义的关系对它们进行比较来实现这一点。如果LSR不在区域边缘，则本节中的程序不适用。
If the LSR is at the edge of a region, it must then determine the other edge of the region with respect to the ERO, again using the IGP database. The LSR then extracts (from the ERO) the subsequence of hops from itself to the other end of the region.
如果LSR位于区域边缘，则必须再次使用IGP数据库确定区域相对于ERO的另一个边缘。然后，LSR（从ERO）提取从自身到区域另一端的跳的子序列。
The LSR then compares the subsequence of hops with all existing FA-LSPs originated by the LSR. If a match is found, that FA-LSP has enough unreserved bandwidth for the LSP being signaled, the L3PID of the FA-LSP is compatible with the L3PID of the LSP being signaled, and the LSR uses that FA-LSP as follows. The Path/Request message for the original LSP is sent to the egress of the FA-LSP, not to the next hop along the FA-LSP's path. The PHOP in the message is the address of the LSR at the head-end of the FA-LSP. Before sending the Path/Request message, the ERO in that message is adjusted by removing the subsequence of the ERO that lies in the FA-LSP, and replacing it with just the end point of the FA-LSP.
然后，LSR将跳的子序列与由LSR发起的所有现有FA lsp进行比较。如果找到匹配项，则FA-LSP有足够的未保留带宽用于发送信号的LSP，FA-LSP的L3PID与发送信号的LSP的L3PID兼容，LSR使用该FA-LSP，如下所示。原始LSP的路径/请求消息被发送到FA-LSP的出口，而不是沿着FA-LSP的路径发送到下一跳。消息中的PHOP是FA-LSP前端的LSR地址。在发送路径/请求消息之前，通过移除位于FA-LSP中的ERO子序列，并将其替换为FA-LSP的端点来调整该消息中的ERO。
Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA-LSP. That is, it initiates a new LSP setup just for the FA-LSP. Note that the new LSP may traverse either 'basic' TE links or FAs.
否则（如果没有找到现有的FA-LSP），LSR将设置一个新的FA-LSP。也就是说，它仅为FA-LSP启动新的LSP设置。请注意，新LSP可能会穿越“基本”TE链路或FAs。
After the LSR establishes the new FA-LSP, the LSR announces this LSP into IS-IS/OSPF as an FA.
LSR建立新的FA-LSP后，LSR将该LSP作为FA发布到IS-IS/OSPF中。
The unreserved bandwidth of the FA is computed by subtracting the bandwidth of sessions pending the establishment of the FA-LSP associated from the bandwidth of the FA-LSP.
FA的无保留带宽通过从FA-LSP的带宽中减去等待建立FA-LSP的会话的带宽来计算。
An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP as a matter of policy local to the LSR. It is expected that the FA-LSP would be torn down once there are no more LSPs carried by the FA-LSP. When the FA-LSP is torn down, the FA associated with the FA-LSP is no longer advertised into IS-IS/OSPF.
根据当地的政策，FA-LSP可由位于FA-LSP前端的LSR拆除。一旦FA-LSP不再携带LSP，预计FA-LSP将被拆除。当FA-LSP被拆除时，与FA-LSP相关联的FA不再播发到is-is/OSPF中。
The value of the holding priority of an FA-LSP must be the minimum of the configured holding priority of the FA-LSP and the holding priorities of the LSPs tunneling through the FA-LSP (note that smaller priority values denote higher priority). Thus, if an LSP of higher priority than the FA-LSP tunnels through the FA-LSP, the FA-LSP is itself promoted to the higher priority. However, if the tunneled LSP is torn down, the FA-LSP need not drop its priority to its old value right away; it may be advisable to apply hysteresis in this case.
FA-LSP的保持优先级的值必须是配置的FA-LSP保持优先级和通过FA-LSP隧道传输的LSP保持优先级中的最小值（注意，较小的优先级值表示较高的优先级）。因此，如果通过FA-LSP的优先级高于FA-LSP隧道的FA-LSP，则FA-LSP本身将提升到更高的优先级。然而，如果隧道LSP被拆除，FA-LSP不需要立即将其优先级降低到其旧值；在这种情况下，最好采用滞后。
If the holding priority of an FA-LSP is configured, this document restricts it to 0.
如果配置了FA-LSP的保持优先级，则本文档将其限制为0。
From a security point of view, the primary change introduced in this document is that the implicit assumption of a binding between data interfaces and the interface over which a control message is sent is no longer valid.
从安全性的角度来看，本文档中引入的主要更改是，数据接口与发送控制消息的接口之间绑定的隐式假设不再有效。
This means that the "sending interface" or "receiving interface" is no longer well-defined, as the interface over which an RSVP message is sent may change as routing changes. Therefore, mechanisms that depend on these concepts (for example, the definition of a security association) need a clearer definition.
这意味着“发送接口”或“接收接口”不再是明确定义的，因为发送RSVP消息的接口可能会随着路由的改变而改变。因此，依赖于这些概念的机制（例如，安全关联的定义）需要更明确的定义。
[RFC2747] provides a solution: in Section 2.1, under "Key Identifier", an IP address is a valid identifier for the sending (and by analogy, receiving) interface. Since RSVP messages for a given LSP are sent to an IP address that identifies the next/previous hop for the LSP, one can replace all occurrences of 'sending [receiving] interface' with 'receiver's [sender's] IP address' (respectively). For example, in Section 4, third paragraph, instead of:
[RFC2747]提供了一个解决方案：在第2.1节中，在“密钥标识符”下，IP地址是发送（以及通过类比，接收）接口的有效标识符。由于给定LSP的RSVP消息被发送到标识LSP下一个/上一个跃点的IP地址，因此可以用“接收方[发送方]IP地址”（分别）替换所有出现的“发送[接收]接口”。例如，在第4节第三段中，而不是：
"Each sender SHOULD have distinct security associations (and keys) per secured sending interface (or LIH). ... At the sender, security association selection is based on the interface through which the message is sent."
“每个发件人应在每个安全发送接口（或LIH）上具有不同的安全关联（和密钥）……在发件人处，安全关联选择基于发送消息的接口。”
it should read:
应改为：
"Each sender SHOULD have distinct security associations (and keys) per secured receiver's IP address. ... At the sender, security association selection is based on the IP address to which the message is sent."
“每个发件人的每个安全收件人的IP地址都应该有不同的安全关联（和密钥）……在发件人，安全关联选择基于邮件发送到的IP地址。”
Note that CR-LDP does not have this issue, as CR-LDP messages are sent over TCP sessions, and no assumption is made that these sessions are to direct neighbors. The recommended mechanism for authentication and integrity of LDP message exchange is to use the TCP MD5 option [LDP].
请注意，CR-LDP没有这个问题，因为CR-LDP消息是通过TCP会话发送的，并且没有假设这些会话是指向邻居的。LDP消息交换的身份验证和完整性的推荐机制是使用TCP MD5选项[LDP]。
Another consequence (relevant to RSVP) of the changes proposed in this document is that IP destination address of Path messages be set to the receiver's address, not to the session destination. Thus, the objections raised in Section 1.2 of [RFC2747] should be revisited to see if IPSec AH is now a viable means of securing RSVP-TE messages.
本文档中提出的更改的另一个结果（与RSVP相关）是，Path消息的IP目的地地址设置为接收方地址，而不是会话目的地。因此，应重新审查[RFC2747]第1.2节中提出的异议，以确定IPSec AH现在是否是保护RSVP-TE消息的可行方法。
Many thanks to Alan Hannan, whose early discussions with Yakov Rekhter contributed greatly to the notion of Forwarding Adjacencies. We would also like to thank George Swallow, Quaizar Vohra and Ayan Banerjee.
非常感谢Alan Hannan，他与Yakov Rekhter的早期讨论极大地促进了转发邻接的概念。我们还要感谢George Swallow、Quaizar Vohra和Ayan Banerjee。
[GCR-LDP] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[GCR-LDP]Ashwood Smith，P.和L.Berger，“基于广义多协议标签交换（GMPLS）信令约束的路由标签分发协议（CR-LDP）扩展”，RFC 3472，2003年1月。
[GMPLS-ISIS] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[GMPLS-ISIS]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的中间系统到中间系统（IS-IS）扩展”，RFC 4205，2005年10月。
[GMPLS-OSPF] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[GMPLS-OSPF]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[GRSVP-TE] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GRSVP-TE]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[GSIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GSIG]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“标签分发协议”，RFC 3036，2001年1月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[UNNUM-CRLDP] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[UNNUM-CRLDP]Kompella，K.，Rekhter，Y.，和A.Kullberg，“CR-LDP（约束路由标签分发协议）中的无编号链路信令”，RFC 3480，2003年2月。
[UNNUM-RSVP] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[UNNUM-RSVP]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[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月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[BUNDLE]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 4201，2005年10月。
[LMP] Lang, L., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP]Lang，L.，Ed.，“链路管理协议（LMP）”，RFC 4204，2005年10月。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。