Network Working Group A. Ayyangar
Request for Comments: 5150 K. Kompella
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
A. Farrel
Old Dog Consulting
February 2008
Network Working Group A. Ayyangar
Request for Comments: 5150 K. Kompella
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
A. Farrel
Old Dog Consulting
February 2008
Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
基于广义多协议标签交换流量工程（GMPLS-TE）的标签交换路径拼接
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）。本备忘录的分发不受限制。
Abstract
摘要
In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
在某些场景中，可能需要组合多个通用多协议标签交换（GMPLS）标签交换路径（LSP），以便实现单个端到端（e2e）LSP，并且将来自一个组成LSP的所有流量切换到下一个LSP。我们将其称为“LSP缝合”，关键要求是一个组成LSP不得分配给多个e2e LSP。组成LSP将被称为“LSP段”（S-LSP）。
This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.
本文件描述了现有GMPLS信令协议（资源预留协议流量工程（RSVP-TE））的扩展，以建立从S-LSP创建的e2e LSP，并描述了如何使用GMPLS信令和路由协议管理LSP。
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching.
可以配置GMPLS节点以将业务从其作为出口的LSP切换到其作为入口的另一LSP，而不需要任何信令或路由扩展，并且使得操作对其他节点完全透明。这也将导致数据平面中的LSP缝合。但是，本文档不包括LSP缝合的这种情况。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Comparison with LSP Hierarchy ...................................3
3. Usage ...........................................................4
3.1. Triggers for LSP Segment Setup .............................4
3.2. Applications ...............................................5
4. Routing Aspects .................................................5
5. Signaling Aspects ...............................................6
5.1. RSVP-TE Signaling Extensions ...............................7
5.1.1. Creating and Preparing an LSP Segment for
Stitching ...........................................7
5.1.1.1. Steps to Support Penultimate Hop
Popping ....................................8
5.1.2. Stitching the e2e LSP to the LSP Segment ............9
5.1.3. RRO Processing for e2e LSPs ........................10
5.1.4. Teardown of LSP Segments ...........................11
5.1.5. Teardown of e2e LSPs ...............................11
5.2. Summary of LSP Stitching Procedures .......................12
5.2.1. Example Topology ...................................12
5.2.2. LSP Segment Setup ..................................12
5.2.3. Setup of an e2e LSP ................................13
5.2.4. Stitching of an e2e LSP into an LSP Segment ........13
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. Attribute Flags for LSP_ATTRIBUTES Object .................15
7.2. New Error Codes ...........................................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Comparison with LSP Hierarchy ...................................3
3. Usage ...........................................................4
3.1. Triggers for LSP Segment Setup .............................4
3.2. Applications ...............................................5
4. Routing Aspects .................................................5
5. Signaling Aspects ...............................................6
5.1. RSVP-TE Signaling Extensions ...............................7
5.1.1. Creating and Preparing an LSP Segment for
Stitching ...........................................7
5.1.1.1. Steps to Support Penultimate Hop
Popping ....................................8
5.1.2. Stitching the e2e LSP to the LSP Segment ............9
5.1.3. RRO Processing for e2e LSPs ........................10
5.1.4. Teardown of LSP Segments ...........................11
5.1.5. Teardown of e2e LSPs ...............................11
5.2. Summary of LSP Stitching Procedures .......................12
5.2.1. Example Topology ...................................12
5.2.2. LSP Segment Setup ..................................12
5.2.3. Setup of an e2e LSP ................................13
5.2.4. Stitching of an e2e LSP into an LSP Segment ........13
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. Attribute Flags for LSP_ATTRIBUTES Object .................15
7.2. New Error Codes ...........................................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering (TE) Label Switched Path (LSP) is built from a set of different "LSP segments" (S-LSPs) that are connected together in the data plane in such a way that a single end-to-end LSP is realized in the data plane. In this document, we define the concept of LSP stitching and detail the control plane mechanisms and procedures (routing and signaling) to accomplish this. Where applicable, similarities and differences between LSP hierarchy [RFC4206] and LSP stitching are highlighted. Signaling extensions required for LSP stitching are also described here.
缝合广义多协议标签交换（GMPLS）流量工程（TE）标签交换路径（LSP）由一组不同的“LSP段”（S-LSP）构建，这些“LSP段”（S-LSP）在数据平面中连接在一起，从而在数据平面中实现单个端到端LSP。在本文档中，我们定义了LSP缝合的概念，并详细介绍了实现这一点的控制平面机制和过程（路由和信令）。在适用的情况下，突出显示LSP层次[RFC4206]和LSP缝合之间的相似性和差异。这里还描述了LSP缝合所需的信令扩展。
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This results in LSP stitching in the data plane, but requires management intervention at the node where the stitching is performed. With the mechanism described in this document, the node performing the stitching does not require configuration of the pair of S-LSPs to be stitched together. Also, LSP stitching as defined here results in an end-to-end LSP both in the control and data planes.
可以配置GMPLS节点以将业务从其作为出口的LSP切换到其作为入口的另一LSP，而不需要任何信令或路由扩展，并且使得操作对其他节点完全透明。这将导致数据平面中的LSP缝合，但需要在执行缝合的节点处进行管理干预。利用本文中描述的机制，执行缝合的节点不需要将一对S-LSP的配置缝合在一起。此外，此处定义的LSP缝合会在控制平面和数据平面中产生端到端LSP。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
LSP hierarchy ([RFC4206]) provides signaling and routing procedures so that:
LSP层次结构（[RFC4206]）提供信令和路由过程，以便：
a. A Hierarchical LSP (H-LSP) can be created. Such an LSP created in one layer can appear as a data link to LSPs in higher layers. As such, one or more LSPs in a higher layer can traverse this H-LSP as a single hop; we call this "nesting".
a. 可以创建分层LSP（H-LSP）。在一个层中创建的这样一个LSP可以显示为到更高层中LSP的数据链路。同样地，更高层中的一个或多个LSP可以作为单跳遍历该H-LSP；我们称之为“筑巢”。
b. An H-LSP may be managed and advertised (although this is not a requirement) as a Traffic Engineering (TE) link. Advertising an H-LSP as a TE link allows other nodes in the TE domain in which it is advertised to use this H-LSP in path computation. If the H-LSP TE link is advertised in the same instance of control plane (TE domain) in which the H-LSP was provisioned, it is then defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes can form a forwarding adjacency (FA) over this FA-LSP. There is usually no routing adjacency between end points of an FA. An H-LSP may also be advertised as a TE link in a different TE domain. In this case, the end points of the H-LSP are required to have a routing adjacency between them.
b. H-LSP可以作为流量工程（TE）链路进行管理和公布（尽管这不是要求）。将H-LSP广告作为TE链路允许在其广告的TE域中的其他节点在路径计算中使用该H-LSP。如果在供应H-LSP的控制平面（TE域）的相同实例中播发H-LSP TE链路，则将其定义为转发邻接LSP（FA-LSP），并且GMPLS节点可以在该FA-LSP上形成转发邻接（FA）。FA端点之间通常没有路由邻接。H-LSP还可以作为不同TE域中的TE链路进行广告。在这种情况下，要求H-LSP的端点之间具有路由邻接。
c. RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can occur between nodes that do not have a routing adjacency.
c. LSP设置的RSVP信令（[RFC3473]、[RFC3209]）可以在没有路由邻接的节点之间发生。
In case of LSP stitching, instead of an H-LSP, an LSP segment (S-LSP) is created between two GMPLS nodes. An S-LSP for stitching is considered to be the moral equivalent of an H-LSP for nesting. An S-LSP created in one layer, unlike an H-LSP, provides a data link to
在LSP缝合的情况下，代替H-LSP，在两个GMPLS节点之间创建LSP段（S-LSP）。用于缝合的S-LSP被认为是用于嵌套的H-LSP的道德等价物。与H-LSP不同，在一个层中创建的S-LSP为
other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be managed and advertised, although it is not required, as a TE link, either in the same TE domain as it was provisioned or a different one. If so advertised, other GMPLS nodes can use the corresponding S-LSP TE link in path computation. While there is a forwarding adjacency between end points of an H-LSP TE link, there is no forwarding adjacency between end points of an S-LSP TE link. In this aspect, an H-LSP TE link more closely resembles a 'basic' TE link as compared to an S-LSP TE link.
同一层中的其他LSP。与H-LSP类似，S-LSP可以作为TE链路在其被配置的相同TE域中或不同的TE域中进行管理和公布，尽管它不是必需的。如果这样通告，其他GMPLS节点可以在路径计算中使用相应的S-LSP TE链路。虽然H-LSP TE链路的端点之间存在转发邻接，但S-LSP TE链路的端点之间不存在转发邻接。在这方面，与S-LSP TE链路相比，H-LSP TE链路更类似于“基本”TE链路。
While LSP hierarchy allows more than one LSP to be mapped to an H-LSP, in case of LSP stitching, at most one LSP may be associated with an S-LSP. Thus, if LSP-AB is an H-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, and LSP3, can potentially be 'nested into' LSP-AB. This is achieved by exchanging a unique label for each of LSP1..3 over the LSP-AB hop, thereby separating the data corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB. Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other hand, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1, and no other LSPs can be associated with LSP-AB. The entire bandwidth on S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs, several S-LSPs may be bundled into a TE link ([RFC4201]).
虽然LSP层次允许多个LSP映射到H-LSP，但是在LSP缝合的情况下，最多一个LSP可以与S-LSP相关联。因此，如果LSP-AB是节点A和B之间的H-LSP，那么多个LSP，如LSP1、LSP2和LSP3，可能“嵌套”到LSP-AB中。这是通过在LSP-AB跳上为每个LSP1..3交换唯一标签来实现的，从而在遍历H-LSP LSP-AB时分离对应于LSP1..3中的每一个的数据。LSP1..3中的每一个可以在LSP-AB上保留一些带宽。另一方面，如果LSP-AB是S-LSP，则最多可以将一个LSP（例如LSP1）缝合到S-LSP LSP-AB。然后LSP-AB专用于LSP1，并且没有其他LSP可以与LSP-AB关联。S-LSP LSP-AB上的整个带宽分配给LSP1。然而，与H-LSP类似，多个S-LSP可以捆绑到TE链路中（[RFC4201]）。
The LSPs LSP1..3 that are either nested or stitched into another LSP are termed as e2e LSPs in the rest of this document. Routing procedures specific to LSP stitching are detailed in Section 4.
嵌套或缝合到另一个LSP中的LSP LSP1..3在本文档的其余部分称为e2e LSP。特定于LSP缝合的布线程序详见第4节。
Targeted (non-adjacent) RSVP signaling defined in [RFC4206] is required for LSP stitching of an e2e LSP to an S-LSP. Specific extensions for LSP stitching are described in Section 5.1. Therefore, in the control plane, there is one RSVP session corresponding to the e2e LSP as well as one for each S-LSP. The creation and termination of an S-LSP may be dictated by administrative control (statically provisioned) or due to another incoming LSP request (dynamic). Triggers for dynamic creation of an S-LSP may be different from that of an H-LSP and will be described in detail in Section 3.1.
e2e LSP到S-LSP的LSP拼接需要[RFC4206]中定义的目标（非相邻）RSVP信令。LSP缝合的具体扩展在第5.1节中描述。因此，在控制平面中，存在对应于e2e LSP的一个RSVP会话以及对应于每个S-LSP的一个RSVP会话。S-LSP的创建和终止可能由管理控制（静态配置）或另一个传入LSP请求（动态）决定。动态创建S-LSP的触发器可能不同于H-LSP的触发器，将在第3.1节中详细描述。
An S-LSP may be created either by administrative control (configuration trigger) or dynamically due to an incoming LSP request. LSP hierarchy ([RFC4206]) defines one possible trigger for dynamic creation of an FA-LSP by introducing the notion of LSP regions based on Interface Switching Capabilities. As per [RFC4206],
S-LSP可以通过管理控制（配置触发器）创建，也可以根据传入的LSP请求动态创建。LSP层次结构（[RFC4206]）通过引入基于接口交换能力的LSP区域的概念，定义了动态创建FA-LSP的一个可能触发器。根据[RFC4206]，
dynamic FA-LSP creation may be triggered on a node when an incoming LSP request crosses region boundaries. However, this trigger MUST NOT be used for creation of an S-LSP for LSP stitching as described in this document. In case of LSP stitching, the switching capabilities of the previous hop and the next hop TE links MUST be the same. Therefore, local policies configured on the node SHOULD be used for dynamic creation of LSP segments.
当传入的LSP请求跨越区域边界时，节点上可能会触发动态FA-LSP创建。但是，此触发器不得用于创建用于本文档中所述LSP缝合的S-LSP。在LSP缝合的情况下，前一跳和下一跳TE链路的切换能力必须相同。因此，应使用节点上配置的本地策略动态创建LSP段。
Other possible triggers for dynamic creation of both H-LSPs and S-LSPs include cases where an e2e LSP may cross domain boundaries or satisfy locally configured policies on the node as described in [RFC5151].
动态创建H-LSP和S-LSP的其他可能触发器包括e2e LSP可能跨越域边界或满足节点上本地配置的策略的情况，如[RFC5151]所述。
LSP stitching procedures described in this document are applicable to GMPLS nodes that need to associate an e2e LSP with another S-LSP of the same switching type and LSP hierarchy procedures do not apply. For example, if an e2e lambda LSP traverses an LSP segment TE link that is also lambda-switch capable, then LSP hierarchy is not possible; in this case, LSP switching may be an option.
本文档中描述的LSP缝合程序适用于需要将e2e LSP与相同交换类型的另一S-LSP关联的GMPLS节点，LSP层次结构程序不适用。例如，如果e2e lambda LSP穿过同样支持lambda交换机的LSP段TE链路，则LSP层次结构是不可能的；在这种情况下，可以选择LSP切换。
LSP stitching procedures can be used for inter-domain TE LSP signaling to stitch an inter-domain e2e LSP to a local intra-domain TE S-LSP ([RFC4726] and [RFC5151]).
LSP缝合过程可用于域间TE LSP信令，以将域间e2e LSP缝合到本地域内TE S-LSP（[RFC4726]和[RFC5151]）。
LSP stitching may also be useful in networks to bypass legacy nodes that may not have certain new capabilities in the control plane and/or data plane. For example, one suggested usage in the case of point-to-multipoint (P2MP) RSVP LSPs ([RFC4875]) is the use of LSP stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP-capable Label Switching Routers (LSRs) in the network. The LSP segment would traverse legacy LSRs that may be incapable of acting as P2MP branch points, thereby shielding them from the P2MP control and data path. Note, however, that such configuration may limit the attractiveness of RSVP P2MP and should carefully be examined before deployment.
LSP缝合在网络中也可用于绕过在控制平面和/或数据平面中可能没有某些新功能的遗留节点。例如，在点对多点（P2MP）RSVP LSP（[RFC4875]）的情况下，建议使用LSP缝合将P2MP RSVP LSP缝合到网络中支持P2MP的标签交换路由器（LSR）之间的LSP段。LSP段将遍历可能无法充当P2MP分支点的传统LSR，从而使其免受P2MP控制和数据路径的影响。但是，请注意，这种配置可能会限制RSVP P2MP的吸引力，在部署前应仔细检查。
An S-LSP is created between two GMPLS nodes, and it may traverse zero or more intermediate GMPLS nodes. There is no forwarding adjacency between the end points of an S-LSP TE link. So although in the TE topology, the end points of an S-LSP TE link are adjacent, in the data plane, these nodes do not have an adjacency. Hence, any data plane resource identifier between these nodes is also meaningless.
在两个GMPLS节点之间创建一个S-LSP，它可以遍历零个或多个中间GMPLS节点。S-LSP TE链路的端点之间没有转发邻接。因此，尽管在TE拓扑中，S-LSP TE链路的端点是相邻的，但在数据平面中，这些节点没有邻接关系。因此，这些节点之间的任何数据平面资源标识符也没有意义。
The traffic that arrives at the head end of the S-LSP is switched into the S-LSP contiguously with a label swap, and no label is associated directly between the end nodes of the S-LSP itself.
到达S-LSP前端的流量通过标签交换连续切换到S-LSP，并且在S-LSP自身的端节点之间没有直接关联的标签。
An S-LSP MAY be treated and managed as a TE link. This TE link MAY be numbered or unnumbered. For an unnumbered S-LSP TE link, the schemes for assignment and handling of the local and remote link identifiers as specified in [RFC3477] SHOULD be used. When appropriate, the TE information associated with an S-LSP TE link MAY be flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203]. Mechanisms similar to that for regular (basic) TE links SHOULD be used to flood S-LSP TE links. Advertising or flooding the S-LSP TE link is not a requirement for LSP stitching. If advertised, this TE information will exist in the TE database (TED) and can then be used for path computation by other GMPLS nodes in the TE domain in which it is advertised. When so advertising S-LSPs, one should keep in mind that these add to the size and complexity of the link-state database.
S-LSP可以作为TE链路来处理和管理。此TE链接可以编号或不编号。对于未编号的S-LSP TE链路，应使用[RFC3477]中规定的本地和远程链路标识符的分配和处理方案。适当时，与S-LSP TE链路相关联的TE信息可经由ISIS-TE[RFC4205]或OSPF-TE[rfc4023]被淹没。应使用类似于常规（基本）TE链路的机制来泛洪S-LSP TE链路。LSP缝合不需要在S-LSP TE链路上做广告或泛洪。如果播发，该TE信息将存在于TE数据库（TED）中，然后可由播发该信息的TE域中的其他GMPLS节点用于路径计算。在宣传S-LSP时，应该记住，这些增加了链路状态数据库的大小和复杂性。
If an S-LSP is advertised as a TE link in the same TE domain in which it was provisioned, there is no need for a routing adjacency between end points of this S-LSP TE link. If an S-LSP TE link is advertised in a different TE domain, the end points of that TE link SHOULD have a routing adjacency between them.
如果S-LSP作为TE链路在提供它的同一TE域中进行广告，则不需要在该S-LSP TE链路的端点之间建立路由邻接。如果S-LSP TE链路在不同的TE域中播发，则该TE链路的端点之间应具有路由邻接。
The TE parameters defined for an FA in [RFC4206] SHOULD be used for an S-LSP TE link as well. The switching capability of an S-LSP TE link MUST be equal to the switching type of the underlying S-LSP; i.e., an S-LSP TE link provides a data link to other LSPs in the same layer, so no hierarchy is possible.
[RFC4206]中为FA定义的TE参数也应用于S-LSP TE链路。S-LSP TE链路的切换能力必须等于底层S-LSP的切换类型；i、 例如，S-LSP TE链路提供到同一层中其他LSP的数据链路，因此不可能有层次结构。
An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to zero to prevent further e2e LSPs from being admitted into the S-LSP.
S-LSP不得允许多个e2e LSP进入。如果S-LSP被分配给e2e LSP，则无保留带宽应设置为零，以防止更多e2e LSP被允许进入S-LSP。
Multiple S-LSPs between the same pair of nodes MAY be bundled using the concept of Link Bundling ([RFC4201]) into a single TE link. In this case, each component S-LSP may be allocated to at most one e2e LSP. When any component S-LSP is allocated for an e2e LSP, the component's unreserved bandwidth SHOULD be set to zero and the Minimum and Maximum LSP bandwidth of the TE link SHOULD be recalculated. This will prevent more than one LSP from being computed and admitted over an S-LSP.
可以使用链路捆绑的概念（[RFC4201]）将同一对节点之间的多个S-LSP捆绑到单个TE链路中。在这种情况下，每个组件S-LSP最多可分配给一个e2e LSP。当为e2e LSP分配任何组件S-LSP时，该组件的未保留带宽应设置为零，并且应重新计算TE链路的最小和最大LSP带宽。这将防止在S-LSP上计算和接纳多个LSP。
The end nodes of an S-LSP may or may not have a routing adjacency. However, they SHOULD have a signaling adjacency (RSVP neighbor relationship) and will exchange RSVP messages with each other. It
S-LSP的终端节点可以有也可以没有路由邻接。但是，它们应该具有信令邻接（RSVP邻居关系），并相互交换RSVP消息。信息技术
may, in fact, be desirable to exchange RSVP Hellos directly between the LSP segment end points to allow support for state recovery during Graceful Restart procedures as described in [RFC3473].
事实上，可能需要在LSP段端点之间直接交换RSVP Hellos，以便在[RFC3473]中所述的正常重启过程中支持状态恢复。
In order to signal an e2e LSP over an LSP segment, signaling procedures described in Section 8.1.1 of [RFC4206] MUST be used. Additional signaling extensions for stitching are described in the next section.
为了通过LSP段向e2e LSP发送信号，必须使用[RFC4206]第8.1.1节所述的信号发送程序。下一节将介绍用于缝合的附加信号扩展。
The signaling extensions described here MUST be used for stitching an e2e packet or non-packet GMPLS LSP ([RFC3473]) to an S-LSP.
这里描述的信令扩展必须用于将e2e分组或非分组GMPLS LSP（[RFC3473]）缝合到S-LSP。
Stitching an e2e LSP to an LSP segment involves the following two-step process:
将e2e LSP缝合到LSP段涉及以下两个步骤：
1. Creating and preparing the S-LSP for stitching by signaling the desire to stitch between end points of the S-LSP; and
1. 通过在S-LSP的端点之间发出想要缝合的信号来创建和准备S-LSP以进行缝合；和
2. Stitching the e2e LSP to the S-LSP.
2. 将e2e LSP缝合到S-LSP。
If a GMPLS node desires to create an S-LSP, i.e., one to be used for stitching, then it MUST indicate this in the Path message for the S-LSP. This signaling explicitly informs the S-LSP egress node that the ingress node is planning to perform stitching over the S-LSP. Since an S-LSP is not conceptually different from any other LSP, explicitly signaling 'LSP stitching desired' helps clarify the data plane actions to be carried out when the S-LSP is used by some other e2e LSP. Also, in the case of packet LSPs, this is what allows the egress of the S-LSP to carry out label allocation as explained below. Also, so that the head-end node can ensure that correct stitching actions will be carried out at the egress node, the egress node MUST signal this information back to the head-end node in the Resv, as explained below.
如果GMPLS节点希望创建一个S-LSP，即用于缝合的S-LSP，那么它必须在S-LSP的路径消息中指出这一点。该信令明确地通知S-LSP出口节点入口节点正计划在S-LSP上执行缝合。由于S-LSP在概念上与任何其他LSP没有区别，因此显式地发信号表示“所需LSP缝合”有助于澄清当一些其他e2e LSP使用S-LSP时要执行的数据平面动作。此外，在分组LSP的情况下，这是允许S-LSP的出口执行标签分配的原因，如下所述。此外，为了使前端节点能够确保将在出口节点处执行正确的缝合动作，出口节点必须将该信息发回Resv中的前端节点，如下所述。
In order to request LSP stitching on the S-LSP, we define a new bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RFC4420]:
为了在S-LSP上请求LSP缝合，我们在[RFC4420]中定义的LSP_Attributes对象的属性标志TLV中定义了一个新位：
LSP stitching desired bit - This bit SHOULD be set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message for the S-LSP by the head end of the S-LSP that desires LSP stitching. This bit MUST NOT be modified by any other nodes in the network. Nodes other than the egress of the S-LSP SHOULD ignore this bit. The bit number for this flag is defined in Section 7.1.
LSP缝合所需位-该位应在S-LSP路径消息中LSP_Attributes对象的属性标志TLV中由需要LSP缝合的S-LSP的前端设置。网络中的任何其他节点不得修改该位。S-LSP出口以外的节点应忽略该位。该标志的位号在第7.1节中定义。
An LSP segment can be used for stitching only if the egress node of the S-LSP is also ready to participate in stitching. In order to indicate this to the head-end node of the S-LSP, the following new bit is defined in the Flags field of the Record Route object (RRO) Attributes subobject: "LSP segment stitching ready". The bit number for this flag is defined in Section 7.1.
仅当S-LSP的出口节点也准备好参与缝合时，LSP段才可用于缝合。为了向S-LSP的前端节点表明这一点，在记录路由对象（RRO）属性子对象的标志字段中定义了以下新位：“LSP段缝合就绪”。该标志的位号在第7.1节中定义。
If an egress node of the S-LSP receiving the Path message supports the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also recognizes the "LSP stitching desired" bit, but cannot support the requested stitching behavior, then it MUST send back a PathErr message with an error code of "Routing Problem" and an error value of "Stitching unsupported" to the head-end node of the S-LSP. The new error value is defined in Section 7.2.
如果接收路径消息的S-LSP的出口节点支持LSP_ATTRIBUTES对象和属性标志TLV，并且还识别“LSP缝合所需”位，但不支持请求的缝合行为，则它必须发回PathErr消息，错误代码为“Routing Problem”，错误值为“不支持缝合”到S-LSP的前端节点。第7.2节定义了新的错误值。
If an egress node receiving a Path message with the "LSP stitching desired" bit set in the Flags field of received LSP_ATTRIBUTES object recognizes the object, the TLV TLV, and the bit and also supports the desired stitching behavior, then it MUST allocate a non-NULL label for that S-LSP in the corresponding Resv message. Also, so that the head-end node can ensure that the correct label (forwarding) actions will be carried out by the egress node and that the S-LSP can be used for stitching, the egress node MUST set the "LSP segment stitching ready" bit defined in the Flags field of the RRO Attribute subobject.
如果出口节点接收路径消息时，在接收的LSP_属性对象的标志字段中设置了“LSP缝合所需”位，该出口节点识别该对象、TLV TLV和该位，并且还支持所需缝合行为，则它必须在相应的Resv消息中为该S-LSP分配非空标签。此外，为了使前端节点能够确保出口节点将执行正确的标签（转发）操作，并且S-LSP可用于缝合，出口节点必须设置在RRO属性子对象的标志字段中定义的“LSP段缝合就绪”位。
Finally, if the egress node for the S-LSP supports the LSP_ATTRIBUTES object but does not recognize the Attributes Flags TLV, or supports the TLV as well but does not recognize this particular bit, then it SHOULD simply ignore the above request.
最后，如果S-LSP的出口节点支持LSP_ATTRIBUTES对象，但不识别ATTRIBUTES Flags TLV，或者也支持TLV，但不识别该特定位，那么它应该简单地忽略上述请求。
An ingress node requesting LSP stitching MUST examine the RRO Attributes subobject Flags corresponding to the egress node for the S-LSP, to make sure that stitching actions are carried out at the egress node. It MUST NOT use the S-LSP for stitching if the "LSP segment stitching ready" bit is cleared.
请求LSP缝合的入口节点必须检查对应于S-LSP出口节点的RRO Attributes子对象标志，以确保在出口节点执行缝合操作。如果清除“LSP段缝合准备就绪”位，则不得使用S-LSP进行缝合。
Note that this section is only applicable to packet LSPs that use Penultimate Hop Popping (PHP) at the last hop, where the egress node distributes the Implicit NULL Label ([RFC3032]) in the Resv Label. These steps MUST NOT be used for a non-packet LSP and for packet LSPs where PHP is not desired.
注意，本节仅适用于在最后一跳使用倒数第二跳弹出（PHP）的数据包LSP，其中出口节点在Resv标签中分发隐式空标签（[RFC3032]）。这些步骤不得用于非分组LSP和不需要PHP的分组LSP。
When the egress node of a packet S-LSP receives a Path message for an e2e LSP that uses the S-LSP, the egress of the S-LSP SHOULD first check to see if it is also the egress of the e2e LSP. If the egress node is the egress for both the S-LSP and the e2e TE LSP, and this is
当分组S-LSP的出口节点接收到用于使用S-LSP的e2e LSP的路径消息时，S-LSP的出口应当首先检查它是否也是e2e LSP的出口。如果出口节点是S-LSP和e2e-TE-LSP的出口，并且这是
a packet LSP that requires PHP, then the node MUST send back a Resv trigger message for the S-LSP with a new label corresponding to the Implicit or Explicit NULL Label. Note that this operation does not cause any traffic disruption because the S-LSP is not carrying any traffic at this time, since the e2e LSP has not yet been established.
如果是需要PHP的数据包LSP，则节点必须为S-LSP发回一条Resv触发器消息，该消息带有与隐式或显式空标签对应的新标签。注意，由于尚未建立e2e LSP，因此该操作不会导致任何业务中断，因为此时S-LSP没有承载任何业务。
If the e2e LSP and the S-LSP are bidirectional, the ingress of the e2e LSP SHOULD first check whether it is also the ingress of the S-LSP. If so, it SHOULD re-issue the Path message for the S-LSP with an Implicit or Explicit NULL Upstream Label, and only then proceed with the signaling of the e2e LSP.
如果e2e LSP和S-LSP是双向的，则e2e LSP的入口应首先检查它是否也是S-LSP的入口。如果是这样，则应使用隐式或显式空上游标签重新发出S-LSP的路径消息，然后才继续发送e2e LSP的信令。
When a GMPLS node receives an e2e LSP request, depending on the applicable trigger, it may either dynamically create an S-LSP based on procedures described above or map an e2e LSP to an existing S-LSP. The switching type in the Generalized Label Request of the e2e LSP MUST be equal to the switching type of the S-LSP. Other constraints like the explicit path encoded in the Explicit Route object (ERO), bandwidth, and local TE policies MUST also be used for S-LSP selection or signaling. In either case, once an S-LSP has been selected for an e2e LSP, the following procedures MUST be followed in order to stitch an e2e LSP to an S-LSP.
当GMPLS节点接收到e2e LSP请求时，根据适用的触发器，它可以基于上述过程动态创建S-LSP，或者将e2e LSP映射到现有S-LSP。e2e LSP的通用标签请求中的切换类型必须等于S-LSP的切换类型。其他约束，如显式路由对象（ERO）中编码的显式路径、带宽和本地TE策略，也必须用于S-LSP选择或信令。在任何一种情况下，一旦为e2e LSP选择了S-LSP，则必须遵循以下步骤将e2e LSP缝合到S-LSP。
The GMPLS node receiving the e2e LSP setup Path message MUST use the signaling procedures described in [RFC4206] to send the Path message to the end point of the S-LSP. In this Path message, the node MUST identify the S-LSP in the RSVP_HOP. An egress node receiving this RSVP_HOP should also be able to identify the S-LSP TE link based on the information signaled in the RSVP_HOP. If the S-LSP TE link is numbered, then the addressing scheme as proposed in [RFC4206] SHOULD be used to number the S-LSP TE link. If the S-LSP TE link is unnumbered, then any of the schemes proposed in [RFC3477] SHOULD be used to exchange S-LSP TE link identifiers between the S-LSP end points. If the TE link is bundled, the RSVP_HOP SHOULD identify the component link as defined in [RFC4201].
接收e2e LSP设置路径消息的GMPLS节点必须使用[RFC4206]中描述的信令过程将路径消息发送到S-LSP的端点。在此路径消息中，节点必须标识RSVP_跃点中的S-LSP。接收该RSVP_跳的出口节点还应该能够基于RSVP_跳中发送的信息来识别S-LSP TE链路。如果对S-LSP TE链路进行编号，则应使用[RFC4206]中建议的寻址方案对S-LSP TE链路进行编号。如果S-LSP TE链路未编号，则应使用[RFC3477]中提出的任何方案在S-LSP端点之间交换S-LSP TE链路标识符。如果TE链路是捆绑的，则RSVP_-HOP应标识[RFC4201]中定义的组件链路。
In case of a bidirectional e2e TE LSP, an Upstream Label MUST be signaled in the Path message for the e2e LSP over the S-LSP hop. However, since there is no forwarding adjacency between the S-LSP end points, any label exchanged between them has no significance. So the node MAY chose any label value for the Upstream Label. The label value chosen and signaled by the node in the Upstream Label is out of the scope of this document and is specific to the implementation on that node. The egress node receiving this Path message MUST ignore the Upstream Label in the Path message over the S-LSP hop.
在双向e2e TE LSP的情况下，必须在S-LSP跳上e2e LSP的路径消息中用信号通知上游标签。然而，由于S-LSP端点之间没有转发邻接，因此它们之间交换的任何标签都没有意义。因此，节点可以为上游标签选择任何标签值。上游标签中节点选择并发出信号的标签值不在本文档范围内，并且特定于该节点上的实现。接收此路径消息的出口节点必须忽略S-LSP跃点上路径消息中的上游标签。
The egress node receiving this Path message MUST signal a Label in the Resv message for the e2e TE LSP over the S-LSP hop. Again, since there is no forwarding adjacency between the egress and ingress S-LSP nodes, any label exchanged between them is meaningless. So the egress node MAY choose any label value for the Label. The label value chosen and signaled by the egress node is out of the scope of this document and is specific to the implementation on the egress node. The egress S-LSP node SHOULD also carry out data plane operations so that traffic coming in on the S-LSP is switched over to the e2e LSP downstream, if the egress of the e2e LSP is some other node downstream. If the e2e LSP is bidirectional, this means setting up label switching in both directions. The Resv message from the egress S-LSP node is IP routed back to the previous hop (ingress of the S-LSP). The ingress node stitching an e2e TE LSP to an S-LSP MUST ignore the Label object received in the Resv for the e2e TE LSP over the S-LSP hop. The S-LSP ingress node SHOULD also carry out data plane operations so that traffic coming in on the e2e LSP is switched into the S-LSP. It should also carry out actions to handle traffic in the opposite direction if the e2e LSP is bidirectional.
接收该路径消息的出口节点必须在Resv消息中通过S-LSP跳向e2e TE LSP发送标签信号。同样，由于出口和入口LSP节点之间没有转发邻接，因此它们之间交换的任何标签都是无意义的。因此出口节点可以为标签选择任何标签值。由出口节点选择并发出信号的标签值超出了本文档的范围，并且特定于出口节点上的实现。出口S-LSP节点还应执行数据平面操作，以便如果e2e LSP的出口是下游的某个其他节点，则在S-LSP上进入的业务被切换到下游的e2e LSP。如果e2e LSP是双向的，这意味着在两个方向上设置标签切换。来自出口S-LSP节点的Resv消息被IP路由回上一跳（S-LSP的入口）。将e2e TE LSP缝合到S-LSP的入口节点必须忽略在S-LSP跳上e2e TE LSP的Resv中接收的标签对象。S-LSP入口节点还应执行数据平面操作，以便在e2e LSP上进入的业务被切换到S-LSP。如果e2e LSP是双向的，则还应执行操作以处理相反方向的流量。
Note that the label exchange procedure for LSP stitching on the S-LSP hop is similar to that for LSP hierarchy over the H-LSP hop. The difference is the lack of the significance of this label between the S-LSP end points in case of stitching. Therefore, in case of stitching, the recipients of the Label/Upstream Label MUST NOT process these labels. Also, at most one e2e LSP is associated with one S-LSP. If a node at the head end of an S-LSP receives a Path message for an e2e LSP that identifies the S-LSP in the ERO and the S-LSP bandwidth has already been allocated to some other LSP, then regular rules of RSVP-TE pre-emption apply to resolve contention for S-LSP bandwidth. If the LSP request over the S-LSP cannot be satisfied, then the node SHOULD send back a PathErr with the error codes as described in [RFC3209].
请注意，S-LSP跃点上LSP缝合的标签交换过程与H-LSP跃点上LSP层次的标签交换过程类似。不同之处在于，在缝合的情况下，S-LSP端点之间的标签缺乏意义。因此，在缝合的情况下，标签/上游标签的接收者不得处理这些标签。此外，最多一个e2e LSP与一个S-LSP相关联。如果位于S-LSP前端的节点接收到e2e LSP的路径消息，该消息标识ERO中的S-LSP，并且S-LSP带宽已经分配给一些其他LSP，则RSVP-TE抢占的规则适用于解决S-LSP带宽的争用。如果无法满足S-LSP上的LSP请求，则节点应发回PathErr，其中包含[RFC3209]中所述的错误代码。
RRO procedures for the S-LSP specific to LSP stitching are already described in Section 5.1.1. In this section, we will look at the RRO processing for the e2e LSP over the S-LSP hop.
特定于LSP缝合的S-LSP的RRO程序已在第5.1.1节中描述。在本节中，我们将研究e2e LSP在S-LSP跳上的RRO处理。
An e2e LSP traversing an S-LSP SHOULD record in the RRO for that hop, an identifier corresponding to the S-LSP TE link. This is applicable to both Path and Resv messages over the S-LSP hop. If the S-LSP is numbered, then the IPv4 or IPv6 address subobject ([RFC3209]) SHOULD be used to record the S-LSP TE link address. If the S-LSP is unnumbered, then the Unnumbered Interface ID subobject as described in [RFC3477] SHOULD be used to record the node's Router ID and Interface ID of the S-LSP TE link. In either case, the RRO subobject
遍历S-LSP的e2e LSP应在该跳的RRO中记录对应于S-LSP TE链路的标识符。这适用于S-LSP跃点上的Path和Resv消息。如果S-LSP已编号，则应使用IPv4或IPv6地址子对象（[RFC3209]）记录S-LSP TE链路地址。如果S-LSP未编号，则应使用[RFC3477]中描述的未编号接口ID子对象记录节点的路由器ID和S-LSP TE链路的接口ID。无论哪种情况，RRO子对象
SHOULD identify the S-LSP TE link end point. Intermediate links or nodes traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for the e2e LSP over the S-LSP hop.
应确定S-LSP TE链路端点。S-LSP自身所穿越的中间链路或节点不应记录在S-LSP跳上e2e LSP的RRO中。
S-LSP teardown follows the standard procedures defined in [RFC3209] and [RFC3473]. This includes procedures without and with setting the administrative status. Teardown of S-LSP may be initiated by the ingress, egress, or any other node along the S-LSP path. Deletion/teardown of the S-LSP SHOULD be treated as a failure event for the e2e LSP associated with it, and corresponding teardown or recovery procedures SHOULD be triggered for the e2e LSP. In case of S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY treat this to be equivalent to administratively shutting down a TE link along the e2e LSP path and take corresponding actions to notify the ingress of this event. The actual signaling procedures to handle this event is out of the scope of this document.
S-LSP拆卸遵循[RFC3209]和[RFC3473]中定义的标准程序。这包括不设置管理状态和设置管理状态的过程。S-LSP的拆卸可由入口、出口或沿S-LSP路径的任何其他节点发起。应将S-LSP的删除/拆卸视为与其相关联的e2e LSP的故障事件，并应为e2e LSP触发相应的拆卸或恢复程序。在S-LSP为了维护目的而拆卸的情况下，S-LSP入口节点可以将其视为等同于管理性地关闭沿e2e LSP路径的TE链路，并采取相应的动作来通知入口该事件。处理该事件的实际信号程序不在本文件范围内。
e2e LSP teardown also follows standard procedures defined in [RFC3209] and [RFC3473] either without or with the administrative status. Note, however, that teardown procedures of e2e LSP and of S-LSP are independent of each other. So it is possible that while one LSP follows graceful teardown with administrative status, the other LSP is torn down without administrative status (using PathTear/ResvTear/PathErr with state removal).
e2e LSP拆卸也遵循[RFC3209]和[RFC3473]中定义的标准程序，无论是否具有管理状态。然而，请注意，e2e LSP和S-LSP的拆卸程序彼此独立。因此，当一个LSP以管理状态进行优雅拆卸时，另一个LSP可能会在没有管理状态的情况下被拆卸（使用带状态删除的PathTrail/ResvTear/PathErr）。
When an e2e LSP teardown is initiated from the head end, and a PathTear arrives at the GMPLS stitching node, the PathTear message like the Path message MUST be IP routed to the LSP segment egress node with the destination IP address of the Path message set to the address of the S-LSP end node. Router Alert MUST be off and RSVP Time to Live (TTL) check MUST be disabled on the receiving node. PathTear will result in deletion of RSVP states corresponding to the e2e LSP and freeing of label allocations and bandwidth reservations on the S-LSP. The unreserved bandwidth on the S-LSP TE link SHOULD be readjusted.
当e2e LSP拆卸从前端启动，并且Path撕裂到达GMPLS缝合节点时，Path撕裂消息（如Path消息）必须IP路由到LSP段出口节点，并且Path消息的目标IP地址设置为S-LSP端节点的地址。路由器警报必须关闭，并且必须在接收节点上禁用RSVP生存时间（TTL）检查。Path撕裂将导致删除与e2e LSP对应的RSVP状态，并释放S-LSP上的标签分配和带宽保留。应重新调整S-LSP TE链路上的未保留带宽。
Similarly, a teardown of the e2e LSP may be initiated from the tail end either using a ResvTear or a PathErr with state removal. The egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, and MUST use IP addressing to target the ingress of the LSP segment.
类似地，e2e LSP的拆卸可以使用ResvTear或带有状态移除的PathErr从后端发起。S-LSP的出口必须向上游传播ResvTear/PathErr，并且必须使用IP寻址以LSP段的入口为目标。
Graceful LSP teardown using ADMIN_STATUS as described in [RFC3473] is also applicable to stitched LSPs.
[RFC3473]中描述的使用ADMIN_状态的优雅LSP拆卸也适用于缝合LSP。
If the S-LSP was statically provisioned, tearing down of an e2e LSP MAY not result in tearing down of the S-LSP. If, however, the S-LSP was dynamically set up due to the e2e LSP setup request, then, depending on local policy, the S-LSP MAY be torn down if no e2e LSP is utilizing the S-LSP. Although the S-LSP may be torn down while the e2e LSP is being torn down, it is RECOMMENDED that a delay be introduced in tearing down the S-LSP once the e2e LSP teardown is complete, in order to reduce the simultaneous generation of RSVP errors and teardown messages due to multiple events. The delay interval may be set based on local implementation. The RECOMMENDED interval is 30 seconds.
如果S-LSP是静态供应的，则e2e LSP的拆除可能不会导致S-LSP的拆除。然而，如果由于e2e LSP设置请求而动态地设置了S-LSP，则根据本地策略，如果没有e2e LSP使用S-LSP，则S-LSP可能被拆除。尽管在e2e LSP被拆除时S-LSP可能被拆除，但建议在e2e LSP拆除完成后在拆除S-LSP时引入延迟，以减少由于多个事件而同时产生的RSVP错误和拆除消息。可以基于本地实现来设置延迟间隔。建议的间隔为30秒。
The following topology will be used for the purpose of examples quoted in the following sections.
以下拓扑结构将用于以下章节中引用的示例。
e2e LSP
+++++++++++++++++++++++++++++++++++> (LSP1-2)
e2e LSP
+++++++++++++++++++++++++++++++++++> (LSP1-2)
LSP segment (S-LSP)
====================> (LSP-AB)
C --- E --- G
/|\ | / |\
/ | \ | / | \
R1 ---- A \ | \ | / | / B --- R2
\| \ |/ |/
D --- F --- H
LSP segment (S-LSP)
====================> (LSP-AB)
C --- E --- G
/|\ | / |\
/ | \ | / | \
R1 ---- A \ | \ | / | / B --- R2
\| \ |/ |/
D --- F --- H
PATH
====================> (LSP stitching desired)
RESV
<==================== (LSP segment stitching ready)
PATH
====================> (LSP stitching desired)
RESV
<==================== (LSP segment stitching ready)
PATH (Upstream Label)
+++++++++++++++++++++
+++++++ ++++++>
<++++++ +++++++
+++++++++++++++++++++
RESV (Label)
PATH (Upstream Label)
+++++++++++++++++++++
+++++++ ++++++>
<++++++ +++++++
+++++++++++++++++++++
RESV (Label)
Let us consider an S-LSP LSP-AB being set up between two nodes A and B that are more than one hop away. Node A sends a Path message for the LSP-AB with "LSP stitching desired" set in the Flags field of the
让我们考虑在两个节点A和B之间建立一个超过一跳的S LSP LSP-AB。节点A发送LSP-AB的路径消息，并在节点A的标志字段中设置“需要LSP缝合”
LSP_ATTRIBUTES object. If the egress node B is ready to carry out stitching procedures, then B will respond with "LSP segment stitching ready" set in the Flags field of the RRO Attributes subobject, in the RRO sent in the Resv for the S-LSP. Once A receives the Resv for LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for stitching. Node A cannot use LSP-AB for stitching if the bit is cleared in the RRO.
LSP_属性对象。如果出口节点B已准备好执行缝合过程，则B将响应在S-LSP的Resv中发送的RRO中，在RRO属性子对象的标志字段中设置的“LSP段缝合准备就绪”。一旦A收到LSP-AB的Resv并在RRO中看到该位设置，它就可以使用LSP-AB进行缝合。如果在RRO中清除位，则节点A无法使用LSP-AB进行缝合。
Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and ending on node R2, as shown above. If the S-LSP has been advertised as a TE link in the TE domain, and R1 and A are in the same domain, then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and identify the LSP-AB hop in the ERO. If not, R1 may compute hops between A and B and A may use these ERO hops for S-LSP selection or signaling a new S-LSP. If R1 and A are in different domains, then LSP1-2 is an inter-domain LSP. In this case, S-LSP LSP-AB, similar to any other basic TE link in the domain, will not be advertised outside the domain. R1 would use either per-domain path computation ([RFC5152]) or PCE-based computation ([RFC4655]) for LSP1-2.
让我们考虑E2E LSP LSP1-2，在ON R1之前开始一跳，并在节点R2上结束，如上所示。如果S-LSP已在TE域中被通告为TE链路，并且R1和a在同一域中，则R1可计算S-LSP LSP-AB上LSP1-2的路径，并识别ERO中的LSP-AB跳。如果不是，R1可以计算A和B之间的跳数，并且A可以将这些ERO跳数用于S-LSP选择或发信号通知新的S-LSP。如果R1和A在不同的域中，那么LSP1-2是域间LSP。在这种情况下，与域中的任何其他基本TE链路类似，S-LSP LSP-AB将不会在域外播发。R1将对LSP1-2使用每域路径计算（[RFC5152]）或基于PCE的计算（[RFC4655]）。
When the Path message for the e2e LSP LSP1-2 arrives at node A, A matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the switching types are not equal, then LSP-AB cannot be used to stitch LSP1-2. Once the S-LSP LSP-AB to which LSP1-2 will be stitched has been determined, the Path message for LSP1-2 is sent (via IP routing, if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP LSP-AB. When B receives this Path message for LSP1-2, if B is also the egress for LSP1-2, and if this is a packet LSP requiring PHP, then B will send a Resv refresh for LSP-AB with the NULL Label. In this case, since B is not the egress, the Path message for LSP1-2 is propagated to R2. The Resv for LSP1-2 from B is sent back to A with a Label value chosen by B. B also sets up its data plane to swap the Label sent to either G or H on the S-LSP with the Label received from R2. Node A ignores the Label on receipt of the Resv message and then propagates the Resv to R1. A also sets up its data plane to swap the Label sent to R1 with the Label received on the S-LSP from C or D. This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A and B. In the data plane, this yields a series of label swaps from R1 to R2 along e2e LSP LSP1-2.
当e2e LSP LSP1-2的路径消息到达节点A时，A将LSP1-2的切换类型与S-LSP LSP-AB匹配。如果切换类型不相等，则LSP-AB不能用于缝合LSP1-2。一旦LSP1-2将缝合到的S-LSP LSP-AB被确定，LSP1-2的路径消息被发送（如果需要，通过IP路由）到节点B，其中if_ID RSVP_跳标识S-LSP LSP-AB。当B接收到LSP1-2的该路径消息时，如果B也是LSP1-2的出口，并且如果这是需要PHP的分组LSP，然后B将发送带有空标签的LSP-AB的Resv刷新。在这种情况下，由于B不是出口，因此LSP1-2的路径消息被传播到R2。来自B的LSP1-2的Resv用B选择的标签值发送回A。B还设置其数据平面，以将发送到S-LSP上G或H的标签与从R2接收的标签交换。节点A在收到Resv消息时忽略标签，然后将Resv传播到R1。A还将其数据平面设置为将发送到R1的标签与S-LSP上从C或D接收到的标签交换。这将e2e LSP LSP1-2缝合到节点A和B之间的S-LSP LSP-AB。在数据平面中，这将产生沿e2e LSP LSP1-2从R1到R2的一系列标签交换。
From a security point of view, the changes introduced in this document model the changes introduced by [RFC4206]. That is, the control interface over which RSVP messages are sent or received need not be the same as the data interface that the message identifies for switching traffic. But the capability for this function was introduced in [RFC3473] to support the concept of out-of-fiber control channels, so there is nothing new in this concept for signaling or security.
从安全的角度来看，本文档中引入的更改模拟了[RFC4206]引入的更改。也就是说，发送或接收RSVP消息的控制接口不需要与消息为交换业务标识的数据接口相同。但是[RFC3473]中引入了该功能的功能，以支持光纤外控制信道的概念，因此在信令或安全性方面，该概念没有什么新的内容。
The application of this facility means that the "sending interface" or "receiving interface" may change as routing changes. So these interfaces cannot be used to establish security associations between neighbors, and security associations MUST be bound to the communicating neighbors themselves.
该设施的应用意味着“发送接口”或“接收接口”可能会随着路由的变化而变化。因此，这些接口不能用于在邻居之间建立安全关联，安全关联必须绑定到通信邻居本身。
[RFC2747] provides a solution to this issue: 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地址。”
Thus, the mechanisms of [RFC2747] can be used unchanged to establish security associations between control plane neighbors.
因此，[RFC2747]的机制可以不变地用于在控制平面邻居之间建立安全关联。
This document allows the IP destination address of Path and PathTear messages to be the IP address of a next hop node (receiver's address) instead of the RSVP session destination address. This means that the use of the IPsec Authentication Header (AH) (ruled out in [RFC2747]
本文档允许Path和PATHTRAL消息的IP目标地址为下一跳节点的IP地址（接收方地址），而不是RSVP会话目标地址。这意味着使用IPsec身份验证头（AH）（在[RFC2747]中排除）
because RSVP messages were encapsulated in IP packets addressed to the ultimate destination of the Path or PathTear messages) is now perfectly applicable, and standard IPsec procedures can be used to secure the message exchanges.
由于RSVP消息封装在IP数据包中，地址为路径的最终目的地（或路径撕裂消息），因此现在完全适用，并且可以使用标准IPsec过程来保护消息交换。
An analysis of GMPLS security issues can be found in [MPLS-SEC].
有关GMPLS安全问题的分析，请参见[MPLS-SEC]。
IANA has made the following codepoint allocations for this document.
IANA为本文件分配了以下代码点。
The "RSVP TE Parameters" registry includes the "Attributes Flags" sub-registry.
“RSVP TE参数”注册表包括“属性标志”子注册表。
IANA has allocated the following new bit (5) defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object.
IANA已为LSP_Attributes对象中的属性标志TLV分配了以下新位（5）。
LSP stitching bit - Bit Number 5
LSP缝合位-位号5
This bit is only to be used in the Attributes Flags TLV on a Path message.
此位仅用于路径消息上的属性标志TLV。
The 'LSP stitching desired' bit has a corresponding 'LSP segment stitching ready' bit (Bit Number 5) to be used in the RRO Attributes subobject.
“所需LSP缝合”位具有相应的“LSP段缝合就绪”位（位号5），用于RRO属性子对象。
The following text has been includuded in the registry:
注册表中包含以下文本：
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
5 LSP stitching desired Yes No Yes [RFC5150]
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
5 LSP stitching desired Yes No Yes [RFC5150]
The "Resource ReSerVation Protocol (RSVP) Parameters" registry includes the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry.
“资源预留协议（RSVP）参数”注册表包括“错误代码和全局定义的错误值子代码”子注册表。
IANA has assigned a new error sub-code (30) under the RSVP error-code "Routing Problem" (24).
IANA在RSVP错误代码“路由问题”（24）下分配了一个新的错误子代码（30）。
This error code (30) is to be used only in an RSVP PathErr.
此错误代码（30）仅在RSVP PathErr中使用。
The following text has been included in the registry:
注册表中包含以下文本：
24 Routing Problem [RFC3209]
24路由问题[RFC3209]
30 = Stitching unsupported [RFC5150]
30=不支持缝合[RFC5150]
The authors would like to thank Dimitri Papadimitriou and Igor Bryskin for their thorough review of the document and discussions regarding the same.
作者要感谢Dimitri Papadimitriou和Igor Bryskin对该文件的透彻审查和讨论。
[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月。
[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月。
[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月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，J.-P.，和A.Ayyangar，“使用资源预留协议流量工程（RSVP-TE）建立多协议标签交换（MPLS）标签交换路径（LSP）的属性编码”，RFC 4420，2006年2月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年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月。
[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月。
[RFC4205] 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.
[RFC4205]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的中间系统到中间系统（IS-IS）扩展”，RFC 4205，2005年10月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J. L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and R. Graveman., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2007.
[MPLS-SEC]方，L.，Ed.，贝林格，M.，凯伦，R.，勒鲁，J.L.，张，R.，奈特，P.，斯坦，Y.，比塔，N.，和R.格雷文.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2007年7月。
Authors' Addresses
作者地址
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: arthi@juniper.net
加利福尼亚州桑尼维尔马蒂尔达大道北1194号Arthi Ayangar Juniper Networks 94089电子邮件：arthi@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N.Mathilda Avenue Sunnyvale，CA 94089电子邮件：kireeti@juniper.net
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 EMail: jpv@cisco.com
JP Vasseur Cisco Systems，Inc.马萨诸塞州伯斯堡市海弗布鲁克路300号邮编01719电子邮件：jpv@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.