Network Working Group B. Jamoussi, Editor, Nortel Networks
Request for Comments: 3212 L. Andersson, Utfors AB
Category: Standards Track R. Callon, Juniper Networks
R. Dantu, Netrake Corporation
L. Wu, Cisco Systems
P. Doolan, OTB Consulting Corp.
T. Worster
N. Feldman, IBM Corp.
A. Fredette, ANF Consulting
M. Girish, Atoga Systems
E. Gray, Sandburst
J. Heinanen, Song Networks, Inc.
T. Kilty, Newbridge Networks, Inc.
A. Malis, Vivace Networks
January 2002
Network Working Group B. Jamoussi, Editor, Nortel Networks
Request for Comments: 3212 L. Andersson, Utfors AB
Category: Standards Track R. Callon, Juniper Networks
R. Dantu, Netrake Corporation
L. Wu, Cisco Systems
P. Doolan, OTB Consulting Corp.
T. Worster
N. Feldman, IBM Corp.
A. Fredette, ANF Consulting
M. Girish, Atoga Systems
E. Gray, Sandburst
J. Heinanen, Song Networks, Inc.
T. Kilty, Newbridge Networks, Inc.
A. Malis, Vivace Networks
January 2002
Constraint-Based LSP Setup using LDP
使用LDP的基于约束的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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol).
本文件规定了使用LDP（标签分发协议）支持CR LSP（基于约束的路由标签交换路径）的机制和TLV（类型/长度/值）。
This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP.
本规范提出了由入口LSR（标签交换路由器）发起的CR-LSP的端到端设置机制。我们还指定了一些机制，以提供使用LDP保留资源的方法。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
Table of Contents
目录
1. Introduction....................................................3
2. Constraint-based Routing Overview...............................4
2.1 Strict and Loose Explicit Routes...............................5
2.2 Traffic Characteristics........................................5
2.3 Preemption.....................................................5
2.4 Route Pinning..................................................6
2.5 Resource Class.................................................6
3. Solution Overview...............................................6
3.1 Required Messages and TLVs.....................................7
3.2 Label Request Message..........................................7
3.3 Label Mapping Message..........................................9
3.4 Notification Message..........................................10
3.5 Release , Withdraw, and Abort Messages........................11
4. Protocol Specification.........................................11
4.1 Explicit Route TLV (ER-TLV)...................................11
4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................12
4.3 Traffic Parameters TLV........................................13
4.3.1 Semantics...................................................15
4.3.1.1 Frequency.................................................15
4.3.1.2 Peak Rate.................................................16
4.3.1.3 Committed Rate............................................16
4.3.1.4 Excess Burst Size.........................................16
4.3.1.5 Peak Rate Token Bucket....................................16
4.3.1.6 Committed Data Rate Token Bucket..........................17
4.3.1.7 Weight....................................................18
4.3.2 Procedures..................................................18
4.3.2.1 Label Request Message.....................................18
4.3.2.2 Label Mapping Message.....................................18
4.3.2.3 Notification Message......................................19
4.4 Preemption TLV................................................19
4.5 LSPID TLV.....................................................20
4.6 Resource Class (Color) TLV....................................21
4.7 ER-Hop semantics..............................................22
4.7.1. ER-Hop 1: The IPv4 prefix..................................22
4.7.2. ER-Hop 2: The IPv6 address.................................23
4.7.3. ER-Hop 3: The autonomous system number....................24
4.7.4. ER-Hop 4: LSPID............................................24
4.8. Processing of the Explicit Route TLV.........................26
4.8.1. Selection of the next hop..................................26
4.8.2. Adding ER-Hops to the explicit route TLV...................27
4.9 Route Pinning TLV.............................................28
4.10 CR-LSP FEC Element...........................................28
5. IANA Considerations............................................29
5.1 TLV Type Name Space...........................................29
5.2 FEC Type Name Space...........................................30
5.3 Status Code Space.............................................30
1. Introduction....................................................3
2. Constraint-based Routing Overview...............................4
2.1 Strict and Loose Explicit Routes...............................5
2.2 Traffic Characteristics........................................5
2.3 Preemption.....................................................5
2.4 Route Pinning..................................................6
2.5 Resource Class.................................................6
3. Solution Overview...............................................6
3.1 Required Messages and TLVs.....................................7
3.2 Label Request Message..........................................7
3.3 Label Mapping Message..........................................9
3.4 Notification Message..........................................10
3.5 Release , Withdraw, and Abort Messages........................11
4. Protocol Specification.........................................11
4.1 Explicit Route TLV (ER-TLV)...................................11
4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................12
4.3 Traffic Parameters TLV........................................13
4.3.1 Semantics...................................................15
4.3.1.1 Frequency.................................................15
4.3.1.2 Peak Rate.................................................16
4.3.1.3 Committed Rate............................................16
4.3.1.4 Excess Burst Size.........................................16
4.3.1.5 Peak Rate Token Bucket....................................16
4.3.1.6 Committed Data Rate Token Bucket..........................17
4.3.1.7 Weight....................................................18
4.3.2 Procedures..................................................18
4.3.2.1 Label Request Message.....................................18
4.3.2.2 Label Mapping Message.....................................18
4.3.2.3 Notification Message......................................19
4.4 Preemption TLV................................................19
4.5 LSPID TLV.....................................................20
4.6 Resource Class (Color) TLV....................................21
4.7 ER-Hop semantics..............................................22
4.7.1. ER-Hop 1: The IPv4 prefix..................................22
4.7.2. ER-Hop 2: The IPv6 address.................................23
4.7.3. ER-Hop 3: The autonomous system number....................24
4.7.4. ER-Hop 4: LSPID............................................24
4.8. Processing of the Explicit Route TLV.........................26
4.8.1. Selection of the next hop..................................26
4.8.2. Adding ER-Hops to the explicit route TLV...................27
4.9 Route Pinning TLV.............................................28
4.10 CR-LSP FEC Element...........................................28
5. IANA Considerations............................................29
5.1 TLV Type Name Space...........................................29
5.2 FEC Type Name Space...........................................30
5.3 Status Code Space.............................................30
6. Security Considerations........................................31
7. Acknowledgments................................................31
8. Intellectual Property Consideration............................31
9. References.....................................................32
Appendix A: CR-LSP Establishment Examples.........................33
A.1 Strict Explicit Route Example.................................33
A.2 Node Groups and Specific Nodes Example........................34
Appendix B. QoS Service Examples..................................36
B.1 Service Examples..............................................36
B.2 Establishing CR-LSP Supporting Real-Time Applications.........38
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications.38
Author's Addresses................................................39
Full Copyright Statement..........................................42
6. Security Considerations........................................31
7. Acknowledgments................................................31
8. Intellectual Property Consideration............................31
9. References.....................................................32
Appendix A: CR-LSP Establishment Examples.........................33
A.1 Strict Explicit Route Example.................................33
A.2 Node Groups and Specific Nodes Example........................34
Appendix B. QoS Service Examples..................................36
B.1 Service Examples..............................................36
B.2 Establishing CR-LSP Supporting Real-Time Applications.........38
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications.38
Author's Addresses................................................39
Full Copyright Statement..........................................42
Label Distribution Protocol (LDP) is defined in [1] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and other constraints. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by, [2] and [3]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). Other uses for CR-LSPs include MPLS-based VPNs [4]. More information about the applicability of CR-LDP can be found in [5].
标签分发协议（LDP）在[1]中定义，用于在一个MPLS域内分发标签。通常使用MPLS，特别是LDP可以提供的最重要的服务之一是支持在路由网络上基于约束的流量路由。基于约束的路由提供了将用于设置路径的信息扩展到路由协议可用信息之外的机会。例如，可以基于显式路由约束、QoS约束和其他约束设置LSP。基于约束的路由（CR）是一种用于满足[2]和[3]提出的流量工程要求的机制。通过扩展LDP以支持基于约束的路由标签交换路径（CR LSP），可以满足这些要求。CR LSP的其他用途包括基于MPLS的VPN[4]。有关CR-LDP适用性的更多信息，请参见[5]。
The need for constraint-based routing (CR) in MPLS has been explored elsewhere [2], and [3]. Explicit routing is a subset of the more general constraint-based routing function. At the MPLS WG meeting held during the Washington IETF (December 1997) there was consensus that LDP should support explicit routing of LSPs with provision for indication of associated (forwarding) priority. In the Chicago meeting (August 1998), a decision was made that support for explicit path setup in LDP will be moved to a separate document. This document provides that support and it has been accepted as a working document in the Orlando meeting (December 1998).
MPLS中基于约束的路由（CR）的需求已在其他地方探讨过[2]，和[3]。显式路由是更通用的基于约束的路由函数的子集。在华盛顿IETF（1997年12月）期间举行的MPLS工作组会议上，一致认为LDP应支持LSP的显式路由，并提供相关（转发）优先级指示。在芝加哥会议（1998年8月）上，决定将LDP中明确路径设置的支持转移到单独的文件中。本文件提供了这种支持，并在奥兰多会议（1998年12月）上作为工作文件被接受。
This specification proposes an end-to-end setup mechanism of a constraint-based routed LSP (CR-LSP) initiated by the ingress LSR. We also specify mechanisms to provide means for reservation of resources using LDP.
本规范提出了由入口LSR发起的基于约束的路由LSP（CR-LSP）的端到端设置机制。我们还指定了一些机制，以提供使用LDP保留资源的方法。
This document introduce TLVs and procedures that provide support for:
本文件介绍了TLV和程序，为以下方面提供支持：
- Strict and Loose Explicit Routing - Specification of Traffic Parameters - Route Pinning - CR-LSP Preemption though setup/holding priorities - Handling Failures - LSPID - Resource Class
- 严格和松散的显式路由-流量参数规范-路由固定-通过设置/保持优先级的CR-LSP抢占-处理故障-LSPID-资源类
Section 2 introduces the various constraints defined in this specification. Section 3 outlines the CR-LDP solution. Section 4 defines the TLVs and procedures used to setup constraint-based routed label switched paths. Appendix A provides several examples of CR-LSP path setup. Appendix B provides Service Definition Examples.
第2节介绍了本规范中定义的各种约束。第3节概述了CR-LDP解决方案。第4节定义了用于设置基于约束的路由标签交换路径的TLV和程序。附录A提供了CR-LSP路径设置的几个示例。附录B提供了服务定义示例。
Constraint-based routing is a mechanism that supports the Traffic Engineering requirements defined in [3]. Explicit Routing is a subset of the more general constraint-based routing where the constraint is the explicit route (ER). Other constraints are defined to provide a network operator with control over the path taken by an LSP. This section is an overview of the various constraints supported by this specification.
基于约束的路由是一种支持[3]中定义的流量工程要求的机制。显式路由是更一般的基于约束的路由的子集，其中约束是显式路由（ER）。定义了其他约束，以使网络运营商能够控制LSP所采用的路径。本节概述了本规范支持的各种约束。
Like any other LSP a CR-LSP is a path through an MPLS network. The difference is that while other paths are setup solely based on information in routing tables or from a management system, the constraint-based route is calculated at one point at the edge of network based on criteria, including but not limited to routing information. The intention is that this functionality shall give desired special characteristics to the LSP in order to better support the traffic sent over the LSP. The reason for setting up CR-LSPs might be that one wants to assign certain bandwidth or other Service Class characteristics to the LSP, or that one wants to make sure that alternative routes use physically separate paths through the network.
与任何其他LSP一样，CR-LSP是通过MPLS网络的路径。不同之处在于，虽然其他路径仅基于路由表中的信息或来自管理系统的信息进行设置，但基于约束的路由是基于标准在网络边缘的一个点上计算的，包括但不限于路由信息。其目的是，该功能应为LSP提供所需的特殊特性，以便更好地支持通过LSP发送的流量。设置CR-LSP的原因可能是希望为LSP分配某些带宽或其他服务类特征，或者希望确保替代路由使用通过网络的物理上独立的路径。
An explicit route is represented in a Label Request Message as a list of nodes or groups of nodes along the constraint-based route. When the CR-LSP is established, all or a subset of the nodes in a group may be traversed by the LSP. Certain operations to be performed along the path can also be encoded in the constraint-based route.
显式路由在标签请求消息中表示为沿基于约束的路由的节点或节点组列表。当建立CR-LSP时，LSP可以遍历组中的所有节点或节点的子集。沿路径执行的某些操作也可以在基于约束的路由中进行编码。
The capability to specify, in addition to specified nodes, groups of nodes, of which a subset will be traversed by the CR-LSP, allows the system a significant amount of local flexibility in fulfilling a request for a constraint-based route. This allows the generator of the constraint-based route to have some degree of imperfect information about the details of the path.
除了指定的节点外，还可以指定节点组，其中一个子集将由CR-LSP遍历，这使得系统在满足基于约束的路由请求时具有很大的本地灵活性。这允许基于约束的路由的生成器具有关于路径细节的某种程度的不完善信息。
The constraint-based route is encoded as a series of ER-Hops contained in a constraint-based route TLV. Each ER-Hop may identify a group of nodes in the constraint-based route. A constraint-based route is then a path including all of the identified groups of nodes in the order in which they appear in the TLV.
基于约束的路由被编码为包含在基于约束的路由TLV中的一系列ER跳。每个ER跳可以识别基于约束的路由中的一组节点。然后，基于约束的路由是一条路径，包括所有已识别的节点组，这些节点组按它们在TLV中出现的顺序排列。
To simplify the discussion, we call each group of nodes an "abstract node". Thus, we can also say that a constraint-based route is a path including all of the abstract nodes, with the specified operations occurring along that path.
为了简化讨论，我们将每组节点称为“抽象节点”。因此，我们也可以说，基于约束的路由是一条包含所有抽象节点的路径，指定的操作沿着该路径发生。
The traffic characteristics of a path are described in the Traffic Parameters TLV in terms of a peak rate, committed rate, and service granularity. The peak and committed rates describe the bandwidth constraints of a path while the service granularity can be used to specify a constraint on the delay variation that the CR-LDP MPLS domain may introduce to a path's traffic.
路径的流量特性在流量参数TLV中根据峰值速率、提交速率和服务粒度进行描述。峰值速率和提交速率描述路径的带宽约束，而服务粒度可用于指定CR-LDP MPLS域可能对路径流量引入的延迟变化的约束。
CR-LDP signals the resources required by a path on each hop of the route. If a route with sufficient resources can not be found, existing paths may be rerouted to reallocate resources to the new path. This is the process of path preemption. Setup and holding priorities are used to rank existing paths (holding priority) and the new path (setup priority) to determine if the new path can preempt an existing path.
CR-LDP向路由的每个跳上的路径发送所需资源的信号。如果找不到具有足够资源的路由，则可以重新路由现有路径，以将资源重新分配到新路径。这是路径抢占的过程。设置和保留优先级用于对现有路径（保留优先级）和新路径（设置优先级）进行排序，以确定新路径是否可以抢占现有路径。
The setupPriority of a new CR-LSP and the holdingPriority attributes of the existing CR-LSP are used to specify priorities. Signaling a higher holding priority express that the path, once it has been
新CR-LSP的setupPriority和现有CR-LSP的holdingPriority属性用于指定优先级。发出更高保持优先级的信号表示，一旦路径
established, should have a lower chance of being preempted. Signaling a higher setup priority expresses the expectation that, in the case that resource are unavailable, the path is more likely to preempt other paths. The exact rules determining bumping are an aspect of network policy.
一旦建立，被抢占的机会就会降低。发送更高设置优先级的信号表示，在资源不可用的情况下，路径更有可能抢占其他路径。确定碰撞的确切规则是网络策略的一个方面。
The allocation of setup and holding priority values to paths is an aspect of network policy.
为路径分配设置和保持优先级值是网络策略的一个方面。
The setup and holding priority values range from zero (0) to seven (7). The value zero (0) is the priority assigned to the most important path. It is referred to as the highest priority. Seven (7) is the priority for the least important path. The use of default priority values is an aspect of network policy. The recommended default value is (4).
设置和保持优先级值的范围从零（0）到七（7）。值零（0）是分配给最重要路径的优先级。它被称为最高优先级。七（7）是最不重要路径的优先级。使用默认优先级值是网络策略的一个方面。建议的默认值为（4）。
The setupPriority of a CR-LSP should not be higher (numerically less) than its holdingPriority since it might bump an LSP and be bumped by the next "equivalent" request.
CR-LSP的setupPriority不应高于（数值小于）其holdingPriority，因为它可能会碰撞LSP并被下一个“等效”请求碰撞。
Route pinning is applicable to segments of an LSP that are loosely routed - i.e. those segments which are specified with a next hop with the "L" bit set or where the next hop is an abstract node. A CR-LSP may be setup using route pinning if it is undesirable to change the path used by an LSP even when a better next hop becomes available at some LSR along the loosely routed portion of the LSP.
路由钉扎适用于松散路由的LSP段，即，通过设置“L”位的下一跳指定的段或下一跳为抽象节点的段。如果即使在沿着LSP的松散路由部分的一些LSR处变得更好的下一跳可用时也不希望改变LSP使用的路径，则可以使用路由钉扎来设置CR-LSP。
The network operator may classify network resources in various ways. These classes are also known as "colors" or "administrative groups". When a CR-LSP is being established, it's necessary to indicate which resource classes the CR-LSP can draw from.
网络运营商可以以各种方式对网络资源进行分类。这些类也称为“颜色”或“管理组”。在建立CR-LSP时，需要指出CR-LSP可以从哪些资源类中提取。
CR-LSP over LDP Specification is designed with the following goals:
CR-LSP over LDP规范的设计目标如下：
1. Meet the requirements outlined in [3] for performing traffic engineering and provide a solid foundation for performing more general constraint-based routing.
1. 满足在[ 3 ]中概述的用于执行流量工程的要求，并为执行更一般的基于约束的路由提供了坚实的基础。
2. Build on already specified functionality that meets the requirements whenever possible. Hence, this specification is based on [1].
2. 尽可能在满足需求的已指定功能的基础上构建。因此，本规范基于[1]。
3. Keep the solution simple.
3. 保持解决方案简单。
In this document, support for unidirectional point-to-point CR-LSPs is specified. Support for point-to-multipoint, multipoint-to-point, is for further study (FFS).
在本文档中，指定了对单向点到点CR LSP的支持。支持点对多点，多点对点，是为了进一步研究（FFS）。
Support for constraint-based routed LSPs in this specification depends on the following minimal LDP behaviors as specified in [1]:
本规范中对基于约束的路由LSP的支持取决于[1]中规定的以下最小LDP行为：
- Use of Basic and/or Extended Discovery Mechanisms. - Use of the Label Request Message defined in [1] in downstream on demand label advertisement mode with ordered control. - Use of the Label Mapping Message defined in [1] in downstream on demand mode with ordered control. - Use of the Notification Message defined in [1]. - Use of the Withdraw and Release Messages defined in [1]. - Use of the Loop Detection (in the case of loosely routed segments of a CR-LSP) mechanisms defined in [1].
- 使用基本和/或扩展发现机制。-在具有有序控制的下游按需标签广告模式中使用[1]中定义的标签请求消息。-在下游按需模式下使用[1]中定义的标签映射消息，并进行有序控制。-使用[1]中定义的通知消息：使用[1]中定义的撤销和释放消息：使用[1]中定义的环路检测（在CR-LSP的松散路由段的情况下）机制。
In addition, the following functionality is added to what's defined in [1]:
此外，在[1]中定义的功能中添加了以下功能：
- The Label Request Message used to setup a CR-LSP includes one or more CR-TLVs defined in Section 4. For instance, the Label Request Message may include the ER-TLV.
- 用于设置CR-LSP的标签请求消息包括第4节中定义的一个或多个CR TLV。例如，标签请求消息可以包括ER-TLV。
- An LSR implicitly infers ordered control from the existence of one or more CR-TLVs in the Label Request Message. This means that the LSR can still be configured for independent control for LSPs established as a result of dynamic routing. However, when a Label Request Message includes one or more of the CR-TLVs, then ordered control is used to setup the CR-LSP. Note that this is also true for the loosely routed parts of a CR-LSP.
- LSR根据标签请求消息中存在的一个或多个CR TLV隐式推断有序控制。这意味着LSR仍然可以配置为对作为动态路由结果建立的LSP进行独立控制。然而，当标签请求消息包括一个或多个CR TLV时，则使用有序控制来设置CR-LSP。请注意，CR-LSP的松散布线部分也是如此。
- New status codes are defined to handle error notification for failure of established paths specified in the CR-TLVs. All of the new status codes require that the F bit be set.
- 定义了新的状态代码，用于处理CR TLV中指定的已建立路径故障的错误通知。所有新状态代码都要求设置F位。
Optional TLVs MUST be implemented to be compliant with the protocol. However, they are optionally carried in the CR-LDP messages to signal certain characteristics of the CR-LSP being established or modified.
必须实现可选TLV，以符合协议。然而，它们可选地被携带在CR-LDP消息中以表示正在建立或修改的CR-LSP的某些特征。
Examples of CR-LSP establishment are given in Appendix A to illustrate how the mechanisms described in this document work.
附录A中给出了CR-LSP建立的示例，以说明本文件中描述的机制是如何工作的。
Any Messages, TLVs, and procedures not defined explicitly in this document are defined in the LDP Specification [1]. The reader can use [7] as an informational document about the state transitions, which relate to CR-LDP messages.
本文件中未明确定义的任何消息、TLV和过程均在LDP规范[1]中定义。读者可以使用[7]作为与CR-LDP消息相关的状态转换的信息文档。
The following subsections are meant as a cross-reference to the [1] document and indication of additional functionality beyond what's defined in [1] where necessary.
以下各小节是对[1]文件的交叉引用，并在必要时指出了超出[1]定义的其他功能。
Note that use of the Status TLV is not limited to Notification messages as specified in Section 3.4.6 of [1]. A message other than a Notification message may carry a Status TLV as an Optional Parameter. When a message other than a Notification carries a Status TLV the U-bit of the Status TLV should be set to 1 to indicate that the receiver should silently discard the TLV if unprepared to handle it.
注意，状态TLV的使用不限于[1]第3.4.6节中规定的通知消息。通知消息以外的消息可以携带状态TLV作为可选参数。当通知以外的消息包含状态TLV时，状态TLV的U位应设置为1，以指示如果未准备好处理TLV，则接收方应自动放弃该TLV。
The Label Request Message is as defined in 3.5.8 of [1] with the following modifications (required only if any of the CR-TLVs is included in the Label Request Message):
标签请求消息如[1]第3.5.8条所定义，并进行了以下修改（仅当标签请求消息中包含任何CR TLV时才需要）：
- The Label Request Message MUST include a single FEC-TLV element. The CR-LSP FEC TLV element SHOULD be used. However, the other FEC- TLVs defined in [1] MAY be used instead for certain applications.
- 标签请求消息必须包含单个FEC-TLV元素。应使用CR-LSP FEC TLV元件。然而，在[1]中定义的其他FEC-TLV可用于某些应用。
- The Optional Parameters TLV includes the definition of any of the Constraint-based TLVs specified in Section 4.
- 可选参数TLV包括第4节中规定的任何基于约束的TLV的定义。
- The Procedures to handle the Label Request Message are augmented by the procedures for processing of the CR-TLVs as defined in Section 4.
- 第4节中定义的CR TLV处理程序补充了处理标签请求消息的程序。
The encoding for the CR-LDP Label Request Message is as follows:
CR-LDP标签请求报文的编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pinning TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pinning TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Mapping Message is as defined in 3.5.7 of [1] with the following modifications:
标签映射消息如[1]第3.5.7条所定义，并进行了以下修改：
- The Label Mapping Message MUST include a single Label-TLV.
- 标签映射消息必须包含单个标签TLV。
- The Label Mapping Message Procedures are limited to downstream on demand ordered control mode.
- 标签映射消息过程仅限于下游按需订购控制模式。
A Mapping message is transmitted by a downstream LSR to an upstream LSR under one of the following conditions:
在以下条件之一下，映射消息由下游LSR发送到上游LSR：
1. The LSR is the egress end of the CR-LSP and an upstream mapping has been requested.
1. LSR是CR-LSP的出口端，已请求上游映射。
2. The LSR received a mapping from its downstream next hop LSR for an CR-LSP for which an upstream request is still pending.
2. LSR从其下游下一跳LSR接收到一个CR-LSP的映射，该CR-LSP的上游请求仍处于挂起状态。
The encoding for the CR-LDP Label Mapping Message is as follows:
CR-LDP标签映射报文的编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Notification Message is as defined in Section 3.5.1 of [1] and the Status TLV encoding is as defined in Section 3.4.6 of [1]. Establishment of an CR-LSP may fail for a variety of reasons. All such failures are considered advisory conditions and they are signaled by the Notification Message.
通知消息的定义见[1]第3.5.1节，状态TLV编码的定义见[1]第3.4.6节。CR-LSP的建立可能由于各种原因而失败。所有此类故障都被视为咨询条件，并通过通知消息发出信号。
Notification Messages carry Status TLVs to specify events being signaled. New status codes are defined in Section 4.11 to signal error notifications associated with the establishment of a CR-LSP and the processing of the CR-TLV. All of the new status codes require that the F bit be set.
通知消息携带状态TLV，以指定发出信号的事件。第4.11节定义了新的状态代码，以发出与CR-LSP的建立和CR-TLV的处理相关的错误通知。所有新状态代码都要求设置F位。
The Notification Message MAY carry the LSPID TLV of the corresponding CR-LSP.
通知消息可携带相应CR-LSP的LSPID TLV。
Notification Messages MUST be forwarded toward the LSR originating the Label Request at each hop and at any time that procedures in this specification - or in [1] - specify sending of a Notification Message in response to a Label Request Message.
通知消息必须在每个跃点转发到发起标签请求的LSR，并且在本规范或[1]中的程序规定响应标签请求消息发送通知消息的任何时间。
The encoding of the notification message is as follows:
通知消息的编码如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Release , Label Withdraw, and Label Abort Request Messages are used as specified in [1]. These messages MAY also carry the LSPID TLV.
标签释放、标签撤回和标签中止请求消息按[1]中的规定使用。这些信息也可能携带LSPID TLV。
The Label Request Message defined in [1] MUST carry the LSPID TLV and MAY carry one or more of the optional Constraint-based Routing TLVs (CR-TLVs) defined in this section. If needed, other constraints can be supported later through the definition of new TLVs. In this specification, the following TLVs are defined:
[1]中定义的标签请求消息必须携带LSPID TLV，并且可以携带本节中定义的一个或多个可选的基于约束的路由TLV（CR TLV）。如果需要，以后可以通过定义新的TLV来支持其他约束。在本规范中，定义了以下TLV：
- Explicit Route TLV - Explicit Route Hop TLV - Traffic Parameters TLV - Preemption TLV - LSPID TLV - Route Pinning TLV - Resource Class TLV - CR-LSP FEC TLV
- 显式路由TLV-显式路由跃点TLV-流量参数TLV-抢占TLV-LSPID TLV-路由固定TLV-资源类TLV-CR-LSP FEC TLV
The ER-TLV is an object that specifies the path to be taken by the LSP being established. It is composed of one or more Explicit Route Hop TLVs (ER-Hop TLVs) defined in Section 4.2.
ER-TLV是一个对象，用于指定正在建立的LSP所采用的路径。它由第4.2节中定义的一个或多个显式路由跳TLV（ER跳TLV）组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0800 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ............ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0800 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ............ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-TLV Type = 0x0800.
键入一个携带ER-TLV Type=0x0800值的14位字段。
Length Specifies the length of the value field in bytes.
长度以字节为单位指定值字段的长度。
ER-Hop TLVs One or more ER-Hop TLVs defined in Section 4.2.
ER-Hop TLV第4.2节中定义的一个或多个ER-Hop TLV。
The contents of an ER-TLV are a series of variable length ER-Hop TLVs.
ER-TLV的内容是一系列可变长度的ER-Hop TLV。
A node receiving a label request message including an ER-Hop type that is not supported MUST not progress the label request message to the downstream LSR and MUST send back a "No Route" Notification Message.
接收到包含不受支持的ER-Hop类型的标签请求消息的节点不得将标签请求消息发送到下游LSR，并且必须发送回“无路由”通知消息。
Each ER-Hop TLV has the form:
每个ER-Hop TLV具有以下形式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Content // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Content // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ER-Hop Type A fourteen-bit field carrying the type of the ER-Hop contents. Currently defined values are:
ER-Hop类型一个14位字段，包含ER-Hop内容的类型。当前定义的值为：
Value Type
------ ------------------------
0x0801 IPv4 prefix
0x0802 IPv6 prefix
0x0803 Autonomous system number
0x0804 LSPID
Value Type
------ ------------------------
0x0801 IPv4 prefix
0x0802 IPv6 prefix
0x0803 Autonomous system number
0x0804 LSPID
Length Specifies the length of the value field in bytes.
长度以字节为单位指定值字段的长度。
L bit The L bit in the ER-Hop is a one-bit attribute. If the L bit is set, then the value of the attribute is "loose." Otherwise, the value of the attribute is "strict." For brevity, we say that if the value of the ER-Hop attribute is loose then it is a "loose ER-Hop." Otherwise, it's a "strict ER-Hop." Further, we say that the abstract node of a strict or loose ER-Hop is a strict or a loose node, respectively. Loose and strict nodes are always interpreted relative to their prior abstract nodes. The path between a strict node and its prior node MUST include only network nodes from the strict node and its prior abstract node.
L位ER Hop中的L位是一位属性。如果设置了L位，那么属性的值是“松散的”。否则，属性的值是“严格的”。为简洁起见，我们说如果ER Hop属性的值是松散的，那么它是“松散的ER Hop”。否则，它是“严格的ER Hop”。此外，我们说严格的或松散的ER Hop的抽象节点是严格的或松散的节点，分别地松散节点和严格节点总是相对于其先前的抽象节点进行解释。严格节点与其先前节点之间的路径必须仅包括严格节点与其先前抽象节点之间的网络节点。
The path between a loose node and its prior node MAY include other network nodes, which are not part of the strict node or its prior abstract node.
松散节点与其先前节点之间的路径可包括不属于严格节点或其先前抽象节点的其他网络节点。
Contents A variable length field containing a node or abstract node which is one of the consecutive nodes that make up the explicitly routed LSP.
内容一个可变长度字段，其中包含一个节点或抽象节点，该节点或抽象节点是构成显式路由LSP的连续节点之一。
The following sections describe the CR-LSP Traffic Parameters. The required characteristics of a CR-LSP are expressed by the Traffic Parameter values.
以下各节介绍CR-LSP流量参数。CR-LSP所需的特性由交通参数值表示。
A Traffic Parameters TLV, is used to signal the Traffic Parameter values. The Traffic Parameters are defined in the subsequent sections.
交通参数TLV用于向交通参数值发送信号。交通参数将在后续章节中定义。
The Traffic Parameters TLV contains a Flags field, a Frequency, a Weight, and the five Traffic Parameters PDR, PBS, CDR, CBS, EBS.
交通参数TLV包含标志字段、频率、权重和五个交通参数PDR、PBS、CDR、CBS、EBS。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0810 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Frequency | Reserved | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate (PDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Data Rate (CDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size (EBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0810 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Frequency | Reserved | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate (PDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Data Rate (CDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size (EBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the Traffic Parameters TLV Type = 0x0810.
键入一个14位字段，其中包含流量参数TLV Type=0x0810的值。
Length Specifies the length of the value field in bytes = 24.
长度指定值字段的长度，单位为字节=24。
Flags The Flags field is shown below:
标志标志标志字段如下所示：
+--+--+--+--+--+--+--+--+
| Res |F6|F5|F4|F3|F2|F1|
+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+
| Res |F6|F5|F4|F3|F2|F1|
+--+--+--+--+--+--+--+--+
Res - These bits are reserved. Zero on transmission. Ignored on receipt. F1 - Corresponds to the PDR. F2 - Corresponds to the PBS. F3 - Corresponds to the CDR. F4 - Corresponds to the CBS. F5 - Corresponds to the EBS. F6 - Corresponds to the Weight.
Res-这些位是保留的。传输为零。收到时忽略。F1-对应于PDR。F2-对应于PBS。F3-对应于CDR。F4-对应于CBS。F5-对应于EBS。F6-对应于重量。
Each flag Fi is a Negotiable Flag corresponding to a Traffic Parameter. The Negotiable Flag value zero denotes NotNegotiable and value one denotes Negotiable.
每个标志Fi是对应于业务参数的可协商标志。可转让标志值0表示不可转让，值1表示可转让。
Frequency The Frequency field is coded as an 8 bit unsigned integer with the following code points defined:
频率频率字段编码为8位无符号整数，定义了以下代码点：
0- Unspecified 1- Frequent 2- VeryFrequent 3-255 - Reserved Reserved - Zero on transmission. Ignored on receipt.
0-未指定1-频繁2-非常频繁3-255-保留-传输时为零。收到时忽略。
Weight An 8 bit unsigned integer indicating the weight of the CR-LSP. Valid weight values are from 1 to 255. The value 0 means that weight is not applicable for the CR-LSP.
权重一个8位无符号整数，指示CR-LSP的权重。有效的权重值介于1到255之间。值0表示重量不适用于CR-LSP。
Traffic Parameters Each Traffic Parameter is encoded as a 32-bit IEEE single-precision floating-point number. A value of positive infinity is represented as an IEEE single-precision floating-point number with an exponent of all ones (255) and a sign and mantissa of all zeros. The values PDR and CDR are in units of bytes per second. The values PBS, CBS and EBS are in units of bytes.
流量参数每个流量参数编码为32位IEEE单精度浮点数。正无穷大的值表示为IEEE单精度浮点数，其指数为全1（255），符号和尾数均为零。PDR和CDR的值以字节/秒为单位。值PBS、CBS和EBS以字节为单位。
The value of PDR MUST be greater than or equal to the value of CDR in a correctly encoded Traffic Parameters TLV.
PDR的值必须大于或等于正确编码的流量参数TLV中的CDR值。
The Frequency specifies at what granularity the CDR allocated to the CR-LSP is made available. The value VeryFrequent means that the available rate should average at least the CDR when measured over any time interval equal to or longer than the shortest packet time at the CDR. The value Frequent means that the available rate should average at least the CDR when measured over any time interval equal to or longer than a small number of shortest packet times at the CDR.
频率指定分配给CR-LSP的CDR可用的粒度。VeryFrequent值意味着，当在等于或长于CDR处最短分组时间的任何时间间隔上测量时，可用速率应至少平均CDR。值frequency意味着，当在等于或长于CDR处的少量最短分组时间的任何时间间隔上测量时，可用速率应至少平均CDR。
The value Unspecified means that the CDR MAY be provided at any granularity.
未指定的值意味着可以以任何粒度提供CDR。
The Peak Rate defines the maximum rate at which traffic SHOULD be sent to the CR-LSP. The Peak Rate is useful for the purpose of resource allocation. If resource allocation within the MPLS domain depends on the Peak Rate value then it should be enforced at the ingress to the MPLS domain.
峰值速率定义了应将流量发送到CR-LSP的最大速率。峰值速率对于资源分配非常有用。如果MPLS域内的资源分配取决于峰值速率值，则应在MPLS域的入口强制执行。
The Peak Rate is defined in terms of the two Traffic Parameters PDR and PBS, see section 4.3.1.5 below.
峰值速率根据两个交通参数PDR和PBS定义，见下文第4.3.1.5节。
The Committed Rate defines the rate that the MPLS domain commits to be available to the CR-LSP.
提交速率定义MPLS域提交给CR-LSP可用的速率。
The Committed Rate is defined in terms of the two Traffic Parameters CDR and CBS, see section 4.3.1.6 below.
提交速率根据两个流量参数CDR和CBS定义，见下文第4.3.1.6节。
The Excess Burst Size may be used at the edge of an MPLS domain for the purpose of traffic conditioning. The EBS MAY be used to measure the extent by which the traffic sent on a CR-LSP exceeds the committed rate.
为了流量调节的目的，可以在MPLS域的边缘处使用多余的突发大小。EBS可用于测量在CR-LSP上发送的业务超过提交速率的程度。
The possible traffic conditioning actions, such as passing, marking or dropping, are specific to the MPLS domain.
可能的流量调节操作（如通过、标记或丢弃）特定于MPLS域。
The Excess Burst Size is defined together with the Committed Rate, see section 4.3.1.6 below.
超额突发大小与提交速率一起定义，见下文第4.3.1.6节。
The Peak Rate of a CR-LSP is specified in terms of a token bucket P with token rate PDR and maximum token bucket size PBS.
CR-LSP的峰值速率根据具有令牌速率PDR和最大令牌桶大小PBS的令牌桶P来指定。
The token bucket P is initially (at time 0) full, i.e., the token count Tp(0) = PBS. Thereafter, the token count Tp, if less than PBS, is incremented by one PDR times per second. When a packet of size B bytes arrives at time t, the following happens:
令牌桶P最初（在时间0时）已满，即令牌计数Tp（0）=PBS。此后，令牌计数Tp（如果小于PBS）每秒增加一次PDR。当大小为B字节的数据包在时间t到达时，发生以下情况：
- If Tp(t)-B >= 0, the packet is not in excess of the peak rate and Tp is decremented by B down to the minimum value of 0, else
- 如果Tp（t）-B>=0，则分组不超过峰值速率，并且Tp由B递减至最小值0，否则
- the packet is in excess of the peak rate and Tp is not decremented.
- 数据包超过峰值速率，且Tp未递减。
Note that according to the above definition, a positive infinite value of either PDR or PBS implies that arriving packets are never in excess of the peak rate.
注意，根据上述定义，PDR或PBS的正无穷大值意味着到达的分组永远不会超过峰值速率。
The actual implementation of an LSR doesn't need to be modeled according to the above formal token bucket specification.
LSR的实际实现不需要根据上述正式的令牌桶规范进行建模。
The committed rate of a CR-LSP is specified in terms of a token bucket C with rate CDR. The extent by which the offered rate exceeds the committed rate MAY be measured in terms of another token bucket E, which also operates at rate CDR. The maximum size of the token bucket C is CBS and the maximum size of the token bucket E is EBS.
CR-LSP的提交速率根据具有速率CDR的令牌桶C来指定。提供的速率超过承诺速率的程度可以根据另一令牌桶E来测量，该令牌桶E也以速率CDR操作。令牌桶C的最大大小为CBS，令牌桶E的最大大小为EBS。
The token buckets C and E are initially (at time 0) full, i.e., the token count Tc(0) = CBS and the token count Te(0) = EBS.
令牌桶C和E最初（在时间0时）已满，即令牌计数Tc（0）=CBS和令牌计数Te（0）=EBS。
Thereafter, the token counts Tc and Te are updated CDR times per second as follows:
此后，令牌计数Tc和Te每秒更新CDR次，如下所示：
- If Tc is less than CBS, Tc is incremented by one, else - if Te is less then EBS, Te is incremented by one, else neither Tc nor Te is incremented.
- 如果Tc小于CBS，则Tc增加1，否则-如果Te小于EBS，则Te增加1，否则Tc和Te均不增加。
When a packet of size B bytes arrives at time t, the following happens:
当大小为B字节的数据包在时间t到达时，发生以下情况：
- If Tc(t)-B >= 0, the packet is not in excess of the Committed Rate and Tc is decremented by B down to the minimum value of 0, else
- 如果Tc（t）-B>=0，则数据包不超过提交速率，且Tc由B递减至最小值0，否则
- if Te(t)-B >= 0, the packet is in excess of the Committed rate but is not in excess of the EBS and Te is decremented by B down to the minimum value of 0, else
- 如果Te（t）-B>=0，则数据包超过提交速率，但不超过EBS，并且Te被B减小至最小值0，否则
- the packet is in excess of both the Committed Rate and the EBS and neither Tc nor Te is decremented.
- 数据包超过了提交速率和EBS，并且Tc和Te都没有减少。
Note that according to the above specification, a CDR value of positive infinity implies that arriving packets are never in excess of either the Committed Rate or EBS. A positive infinite value of either CBS or EBS implies that the respective limit cannot be exceeded.
注意，根据上述规范，CDR值为正无穷大意味着到达的分组永远不会超过提交速率或EBS。CBS或EBS的正无穷大值表示不能超过相应的限制。
The actual implementation of an LSR doesn't need to be modeled according to the above formal specification.
LSR的实际实现不需要根据上述形式规范进行建模。
The weight determines the CR-LSP's relative share of the possible excess bandwidth above its committed rate. The definition of "relative share" is MPLS domain specific.
权重确定CR-LSP在其承诺速率之上可能的额外带宽的相对份额。“相对共享”的定义是MPLS领域特有的。
If an LSR receives an incorrectly encoded Traffic Parameters TLV in which the value of PDR is less than the value of CDR then it MUST send a Notification Message including the Status code "Traffic Parameters Unavailable" to the upstream LSR from which it received the erroneous message.
如果LSR接收到错误编码的流量参数TLV，其中PDR的值小于CDR的值，则必须向接收到错误消息的上游LSR发送包含状态代码“Traffic Parameters Unavailable”（流量参数不可用）的通知消息。
If a Traffic Parameter is indicated as Negotiable in the Label Request Message by the corresponding Negotiable Flag then an LSR MAY replace the Traffic Parameter value with a smaller value.
如果在标签请求消息中通过相应的可协商标志将流量参数指示为可协商，则LSR可以用较小的值替换流量参数值。
If the Weight is indicated as Negotiable in the Label Request Message by the corresponding Negotiable Flag then an LSR may replace the Weight value with a lower value (down to 0).
如果重量在标签请求消息中由相应的可协商标志指示为可协商，则LSR可以用较低的值（低至0）替换重量值。
If, after possible Traffic Parameter negotiation, an LSR can support the CR-LSP Traffic Parameters then the LSR MUST reserve the corresponding resources for the CR-LSP.
如果在可能的业务参数协商之后，LSR可以支持CR-LSP业务参数，那么LSR必须为CR-LSP保留相应的资源。
If, after possible Traffic Parameter negotiation, an LSR cannot support the CR-LSP Traffic Parameters then the LSR MUST send a Notification Message that contains the "Resource Unavailable" status code.
如果在可能的流量参数协商后，LSR无法支持CR-LSP流量参数，则LSR必须发送包含“资源不可用”状态代码的通知消息。
If an LSR receives an incorrectly encoded Traffic Parameters TLV in which the value of PDR is less than the value of CDR then it MUST send a Label Release message containing the Status code "Traffic Parameters Unavailable" to the LSR from which it received the erroneous message. In addition, the LSP should send a Notification Message upstream with the status code 'Label Request Aborted'.
如果LSR接收到错误编码的交通参数TLV，其中PDR的值小于CDR的值，则必须向接收到错误消息的LSR发送包含状态代码“交通参数不可用”的标签释放消息。此外，LSP应向上游发送状态代码为“Label Request Aborted”的通知消息。
If the negotiation flag was set in the label request message, the egress LSR MUST include the (possibly negotiated) Traffic Parameters and Weight in the Label Mapping message.
如果在标签请求消息中设置了协商标志，则出口LSR必须在标签映射消息中包括（可能协商的）流量参数和权重。
The Traffic Parameters and the Weight in a Label Mapping message MUST be forwarded unchanged.
标签映射消息中的流量参数和权重必须不变地转发。
An LSR SHOULD adjust the resources that it reserved for a CR-LSP when it receives a Label Mapping Message if the Traffic Parameters differ from those in the corresponding Label Request Message.
如果流量参数与相应标签请求消息中的参数不同，则LSR在接收标签映射消息时应调整为CR-LSP保留的资源。
If an LSR receives a Notification Message for a CR-LSP, it SHOULD release any resources that it possibly had reserved for the CR-LSP. In addition, on receiving a Notification Message from a Downstream LSR that is associated with a Label Request from an upstream LSR, the local LSR MUST propagate the Notification message using the procedures in [1]. Further the F bit MUST be set.
如果LSR收到CR-LSP的通知消息，它应该释放它可能为CR-LSP保留的任何资源。此外，当从与来自上游LSR的标签请求相关联的下游LSR接收到通知消息时，本地LSR必须使用[1]中的过程传播通知消息。此外，必须设置F位。
The default value of the setup and holding priorities should be in the middle of the range (e.g., 4) so that this feature can be turned on gradually in an operational network by increasing or decreasing the priority starting at the middle of the range.
设置和保持优先级的默认值应该在范围（例如，4）的中间，从而通过增加或减少在该范围的中间开始的优先级，可以在操作网络中逐渐地开启该特征。
Since the Preemption TLV is an optional TLV, LSPs that are setup without an explicitly signaled preemption TLV SHOULD be treated as LSPs with the default setup and holding priorities (e.g., 4).
由于抢占TLV是可选的TLV，因此在没有明确信号抢占TLV的情况下设置的LSP应被视为具有默认设置和保持优先级（例如，4）的LSP。
When an established LSP is preempted, the LSR that initiates the preemption sends a Withdraw Message upstream and a Release Message downstream.
当已建立的LSP被抢占时，发起抢占的LSR向上游发送撤回消息，向下游发送释放消息。
When an LSP in the process of being established (outstanding Label Request without getting a Label Mapping back) is preempted, the LSR that initiates the preemption, sends a Notification Message upstream and an Abort Message downstream.
当建立过程中的LSP（未完成的标签请求，但未获得标签映射）被抢占时，启动抢占的LSR向上游发送通知消息，向下游发送中止消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0820 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SetPrio | HoldPrio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0820 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SetPrio | HoldPrio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the Preemption-TLV Type = 0x0820.
键入一个14位字段，其中包含抢占TLV Type=0x0820的值。
Length Specifies the length of the value field in bytes = 4.
长度指定值字段的长度（字节=4）。
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
SetPrio A SetupPriority of value zero (0) is the priority assigned to the most important path. It is referred to as the highest priority. Seven (7) is the priority for the least important path. The higher the setup priority, the more paths CR-LDP can bump to set up the path. The default value should be 4.
SetPrio值为零（0）的SetupPriority是分配给最重要路径的优先级。它被称为最高优先级。七（7）是最不重要路径的优先级。设置优先级越高，CR-LDP可以碰撞的路径越多，以设置路径。默认值应为4。
HoldPrio A HoldingPriority of value zero (0) is the priority assigned to the most important path. It is referred to as the highest priority. Seven (7) is the priority for the least important path. The default value should be 4. The higher the holding priority, the less likely it is for CR-LDP to reallocate its bandwidth to a new path.
HoldPrio值为零（0）的HoldingPriority是分配给最重要路径的优先级。它被称为最高优先级。七（7）是最不重要路径的优先级。默认值应为4。保持优先级越高，CR-LDP将其带宽重新分配到新路径的可能性越小。
LSPID is a unique identifier of a CR-LSP within an MPLS network.
LSPID是MPLS网络中CR-LSP的唯一标识符。
The LSPID is composed of the ingress LSR Router ID (or any of its own Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR.
LSPID由入口LSR路由器ID（或其自身的任何Ipv4地址）和该LSR的本地唯一CR-LSP ID组成。
The LSPID is useful in network management, in CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV.
LSPID在网络管理、CR-LSP修复以及在ER-TLV中将已经建立的CR-LSP用作跳时有用。
An "action indicator flag" is carried in the LSPID TLV. This "action indicator flag" indicates explicitly the action that should be taken if the LSP already exists on the LSR receiving the message.
LSPID TLV中带有“动作指示器标志”。此“操作指示器标志”明确指示如果接收消息的LSR上已存在LSP，则应采取的操作。
After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The "action indicator flag" is used indicate the need to modify the bandwidth and possibly other parameters of an established CR-LSP without service interruption. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved.
在建立CR-LSP之后，由于对该CR-LSP上承载的业务的新要求，网络运营商可能需要更改其带宽预留。“动作指示标志”用于指示需要在不中断服务的情况下修改已建立CR-LSP的带宽和可能的其他参数。此功能在涉及不同优先级和服务类别的流量的动态网络资源管理中有应用。
The procedure for the code point "modify" is defined in [8]. The procedures for other flags are FFS.
[8]中定义了代码点“修改”的程序。其他标志的程序为FFS。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0821 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ActFlg | Local CR-LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0821 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ActFlg | Local CR-LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the LSPID-TLV Type = 0x0821.
键入一个14位字段，其中包含LSPID-TLV Type=0x0821的值。
Length Specifies the length of the value field in bytes = 4.
长度指定值字段的长度（字节=4）。
ActFlg Action Indicator Flag: A 4-bit field that indicates explicitly the action that should be taken if the LSP already exists on the LSR receiving the message. A set of indicator code points is proposed as follows:
ActFlg Action Indicator Flag：一个4位字段，明确指示接收消息的LSR上已存在LSP时应采取的操作。建议一组指标代码点如下：
0000: indicates initial LSP setup 0001: indicates modify LSP
0000：表示初始LSP设置0001：表示修改LSP
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
Local CR-LSP ID The Local LSP ID is an identifier of the CR-LSP locally unique within the Ingress LSR originating the CR-LSP.
本地CR-LSP ID本地LSP ID是发起CR-LSP的入口LSR中本地唯一的CR-LSP标识符。
Ingress LSR Router ID An LSR may use any of its own IPv4 addresses in this field.
入口LSR路由器ID LSR可以在此字段中使用其自己的任何IPv4地址。
The Resource Class as defined in [3] is used to specify which links are acceptable by this CR-LSP. This information allows for the network's topology to be pruned.
[3]中定义的资源类用于指定该CR-LSP可接受的链路。此信息允许修剪网络拓扑。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0822 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RsCls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0822 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RsCls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ResCls-TLV Type = 0x0822.
键入一个14位字段，其中包含ResCls TLV Type=0x0822的值。
Length Specifies the length of the value field in bytes = 4.
长度指定值字段的长度（字节=4）。
RsCls The Resource Class bit mask indicating which of the 32 "administrative groups" or "colors" of links the CR-LSP can traverse.
RsCls资源类位掩码，指示CR-LSP可以遍历32个“管理组”或“颜色”链路中的哪一个。
The abstract node represented by this ER-Hop is the set of nodes, which have an IP address, which lies within this prefix. Note that a prefix length of 32 indicates a single IPv4 node.
由该ER-Hop表示的抽象节点是一组节点，这些节点具有一个IP地址，该地址位于该前缀内。请注意，前缀长度32表示单个IPv4节点。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0801 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0801 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 1, IPv4 Address, Type = 0x0801
键入一个14位字段，其中包含ER Hop 1的值，IPv4地址，类型=0x0801
Length Specifies the length of the value field in bytes = 8.
长度指定值字段的长度（字节=8）。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
L位设置为指示松散跃点。清除以指示严格的跃点。
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
PreLen Prefix Length 1-32
前置前缀长度1-32
IP Address A four-byte field indicating the IP Address.
IP地址指示IP地址的四字节字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0802 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0802 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 2, IPv6 Address, Type = 0x0802
键入一个14位字段，其中包含ER Hop 2的值，IPv6地址，Type=0x0802
Length Specifies the length of the value field in bytes = 20.
长度指定值字段的长度（字节=20）。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
L位设置为指示松散跃点。清除以指示严格的跃点。
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
PreLen Prefix Length 1-128
前置前缀长度1-128
IPv6 address A 128-bit unicast host address.
IPv6地址128位单播主机地址。
The abstract node represented by this ER-Hop is the set of nodes belonging to the autonomous system.
由该ER-Hop表示的抽象节点是属于自治系统的节点集。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0803 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0803 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 3, AS Number, Type = 0x0803
键入一个携带ER Hop 3值的14位字段，作为数字，类型=0x0803
Length Specifies the length of the value field in bytes = 4.
长度指定值字段的长度（字节=4）。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
L位设置为指示松散跃点。清除以指示严格的跃点。
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
AS Number Autonomous System number
AS编号自治系统编号
The LSPID is used to identify the tunnel ingress point as the next hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an already established CR-LSP. It also allows for splicing the CR-LSP being established with an existing CR-LSP.
LSPID用于将隧道入口点标识为ER中的下一跳。该ER跳允许在已经建立的CR-LSP内堆叠新的CR-LSP。它还允许将正在建立的CR-LSP与现有CR-LSP进行拼接。
If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may splice the CR-LSP of the incoming Label Request to the CR-LSP that currently exists with this LSPID. This is useful, for example, at the point at which a Label Request used for local repair arrives at the next ER-Hop after the loosely specified CR-LSP segment. Use of the LSPID Hop in this scenario eliminates the need for ER-Hops to keep the entire remaining ER-TLV at each LSR that is at either (upstream or downstream) end of a loosely specified CR-LSP segment as part of its state information. This is due to the fact that the
如果LSPID跃点是ER-TLV中的最后一个ER跃点，则LSR可以将传入标签请求的CR-LSP拼接到当前与此LSPID一起存在的CR-LSP。例如，当用于本地修复的标签请求到达松散指定的CR-LSP段之后的下一个ER跃点时，这是有用的。在这种情况下，使用LSPID跃点消除了ER跃点将整个剩余ER-TLV保持在每个LSR的需要，该LSR位于松散指定的CR-LSP段的任一端（上游或下游），作为其状态信息的一部分。这是因为
upstream LSR needs only to keep the next ER-Hop and the LSPID and the downstream LSR needs only to keep the LSPID in order for each end to be able to recognize that the same LSP is being identified.
上游LSR只需要保持下一个ER跃点和LSPID，下游LSR只需要保持LSPID，以便每个端能够识别相同的LSP。
If the LSPID Hop is not the last hop in an ER-TLV, the LSR must remove the LSP-ID Hop and forward the remaining ER-TLV in a Label Request message using an LDP session established with the LSR that is the specified CR-LSP's egress. That LSR will continue processing of the CR-LSP Label Request Message. The result is a tunneled, or stacked, CR-LSP.
如果LSPID跃点不是ER-TLV中的最后一个跃点，则LSR必须移除LSP-ID跃点，并使用与指定CR-LSP出口的LSR建立的LDP会话转发标签请求消息中剩余的ER-TLV。该LSR将继续处理CR-LSP标签请求消息。结果是隧道式或堆叠式CR-LSP。
To support labels negotiated for tunneled CR-LSP segments, an LDP session is required [1] between tunnel end points - possibly using the existing CR-LSP. Use of the existence of the CR-LSP in lieu of a session, or other possible session-less approaches, is FFS.
为了支持为隧道CR-LSP段协商的标签，需要在隧道端点之间[1]进行LDP会话-可能使用现有CR-LSP。使用CR-LSP的存在代替会话或其他可能的无会话方法是FFS。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0804 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | Local LSPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0804 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | Local LSPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 4, LSPID, Type = 0x0804
键入一个14位字段，其中包含ER Hop 4的值，LSPID，Type=0x0804
Length Specifies the length of the value field in bytes = 8.
长度指定值字段的长度（字节=8）。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
L位设置为指示松散跃点。清除以指示严格的跃点。
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
Local LSPID A 2 byte field indicating the LSPID which is unique with reference to its Ingress LSR.
本地LSPID一个2字节字段，指示相对于其入口LSR唯一的LSPID。
Ingress LSR Router ID An LSR may use any of its own IPv4 addresses in this field.
入口LSR路由器ID LSR可以在此字段中使用其自己的任何IPv4地址。
A Label Request Message containing an explicit route TLV must determine the next hop for this path. Selection of this next hop may involve a selection from a set of possible alternatives. The mechanism for making a selection from this set is implementation dependent and is outside of the scope of this specification. Selection of particular paths is also outside of the scope of this specification, but it is assumed that each node will make a best effort attempt to determine a loop-free path. Note that such best efforts may be overridden by local policy.
包含显式路由TLV的标签请求消息必须确定此路径的下一个跃点。选择下一跳可能涉及从一组可能的备选方案中进行选择。从该集合中进行选择的机制取决于实现，不在本规范的范围内。特定路径的选择也不在本规范的范围内，但假定每个节点将尽最大努力确定无循环路径。请注意，当地政策可能会凌驾于此类最佳努力之上。
To determine the next hop for the path, a node performs the following steps:
要确定路径的下一个跃点，节点将执行以下步骤：
1. The node receiving the Label Request Message must first evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop, it has received the message in error, and should return a "Bad Initial ER-Hop Error" status. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. If there is no first ER-Hop, the message is also in error and the system should return a "Bad Explicit Routing TLV Error" status using a Notification Message sent upstream.
1. 接收标签请求消息的节点必须首先计算第一个ER跃点。如果在第一个ER跃点中未设置L位，并且如果该节点不是第一个ER跃点所描述的抽象节点的一部分，则该节点已接收到错误消息，并且应返回“错误的初始ER跃点错误”状态。如果设置了L位并且本地节点不是由第一ER跳描述的抽象节点的一部分，则该节点选择沿着由第一ER跳描述的抽象节点的路径的下一跳。如果没有第一个ER跃点，消息也会出错，系统应使用向上游发送的通知消息返回“错误的显式路由TLV错误”状态。
2. If there is no second ER-Hop, this indicates the end of the explicit route. The explicit route TLV should be removed from the Label Request Message. This node may or may not be the end of the LSP. Processing continues with section 4.8.2, where a new explicit route TLV may be added to the Label Request Message.
2. 如果没有第二个ER跃点，则表示显式路由的结束。应从标签请求消息中删除显式路由TLV。该节点可能是也可能不是LSP的末端。继续处理第4.8.2节，其中可能会将新的显式路由TLV添加到标签请求消息中。
3. If the node is also a part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above. Note that this makes the second ER-Hop into the first ER-Hop of the next iteration.
3. 如果该节点也是由第二ER-Hop描述的抽象节点的一部分，则该节点删除第一ER-Hop并继续进行上述步骤2的处理。请注意，这会使第二个ER跃变为下一次迭代的第一个ER跃。
4. The node determines if it is topologically adjacent to the abstract node described by the second ER-Hop. If so, the node selects a particular next hop which is a member of the abstract node. The node then deletes the first ER-Hop and continues processing with section 4.8.2.
4. 该节点确定它是否在拓扑上与第二ER跃点描述的抽象节点相邻。如果是，则节点选择作为抽象节点成员的特定下一跳。然后，节点删除第一个ER跃点，并按照第4.8.2节继续处理。
5. Next, the node selects a next hop within the abstract node of the first ER-Hop that is along the path to the abstract node of the second ER-Hop. If no such path exists then there are two cases:
5. 接下来，该节点在第一ER跃点的抽象节点内选择沿着到第二ER跃点的抽象节点的路径的下一跳。如果不存在此类路径，则有两种情况：
5.a If the second ER-Hop is a strict ER-Hop, then there is an error and the node should return a "Bad Strict Node Error" status.
5.a如果第二个ER跃点是严格ER跃点，则存在错误，节点应返回“错误严格节点错误”状态。
5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then the node selects any next hop that is along the path to the next abstract node. If no path exists within the MPLS domain, then there is an error, and the node should return a "Bad Loose Node Error" status.
5.b否则，如果第二个ER跃点是松散的ER跃点，则节点选择沿着到下一个抽象节点的路径的任何下一个跃点。如果MPLS域中不存在路径，则存在错误，节点应返回“坏的松散节点错误”状态。
6. Finally, the node replaces the first ER-Hop with any ER-Hop that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted.
6. 最后，该节点用表示包含下一跳的抽象节点的任何ER-Hop替换第一个ER-Hop。这是必要的，以便在下一跳接收到显式路由时，它将被接受。
7. Progress the Label Request Message to the next hop.
7. 将标签请求消息前进到下一个跃点。
After selecting a next hop, the node may alter the explicit route in the following ways.
在选择下一跳之后，节点可以通过以下方式改变显式路由。
If, as part of executing the algorithm in section 4.8.1, the explicit route TLV is removed, the node may add a new explicit route TLV.
如果作为执行第4.8.1节中算法的一部分，删除了显式路由TLV，则节点可以添加新的显式路由TLV。
Otherwise, if the node is a member of the abstract node for the first ER-Hop, then a series of ER-Hops may be inserted before the first ER-Hop or may replace the first ER-Hop. Each ER-Hop in this series must denote an abstract node that is a subset of the current abstract node.
否则，如果该节点是第一ER-Hop的抽象节点的成员，则可以在第一ER-Hop之前插入一系列ER-Hop，或者可以替换第一ER-Hop。该系列中的每个ER跃点必须表示一个抽象节点，该节点是当前抽象节点的子集。
Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary series of ER-Hops may be inserted prior to the first ER-Hop.
或者，如果第一ER跳是松散的ER跳，则可以在第一ER跳之前插入任意系列的ER跳。
Section 2.4 describes the use of route pinning. The encoding of the Route Pinning TLV is as follows:
第2.4节描述了路线固定的使用。路由固定TLV的编码如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0823 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0823 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the Pinning-TLV Type = 0x0823
键入一个14位字段，其中包含固定TLV Type=0x0823的值
Length Specifies the length of the value field in bytes = 4.
长度指定值字段的长度（字节=4）。
P Bit The P bit is set to 1 to indicate that route pinning is requested. The P bit is set to 0 to indicate that route pinning is not requested
P位P位设置为1表示请求路由固定。P位设置为0，表示未请求路由固定
Reserved Zero on transmission. Ignored on receipt.
传输时保留零。收到时忽略。
A new FEC element is introduced in this specification to support CR-LSPs. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a CR-LSP FEC TLV. The CR-LSP FEC Element is an opaque FEC to be used only in Messages of CR-LSPs.
本规范中引入了一种新的FEC元件以支持CR LSP。包含元素类型为CR-LSP（0x04）的FEC的FEC TLV是CR-LSP FEC TLV。CR-LSP FEC元素是不透明的FEC，仅用于CR LSP的消息中。
A single FEC element MUST be included in the Label Request Message. The FEC Element SHOULD be the CR-LSP FEC Element. However, one of the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be in CR-LDP messages instead of the CR-LSP FEC Element for certain applications. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a CR-LSP FEC TLV.
标签请求消息中必须包含单个FEC元素。FEC元件应为CR-LSP FEC元件。然而，对于某些应用，在[1]中定义的其他FEC元素（类型=0x01、0x02、0x03）之一可以在CR-LDP消息中而不是CR-LSP FEC元素中。包含元素类型为CR-LSP（0x04）的FEC的FEC TLV是CR-LSP FEC TLV。
FEC Element Type Value Type name
FEC元素类型值类型名称
CR-LSP 0x04 No value; i.e., 0 value octets;
CR-LSP 0x04无值；i、 e，0值八位组；
The CR-LSP FEC TLV encoding is as follows:
CR-LSP FEC TLV编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0100 | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CR-LSP (4) |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0100 | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CR-LSP (4) |
+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the FEC TLV Type = 0x0100
键入一个14位字段，其中包含FEC TLV Type=0x0100的值
Length Specifies the length of the value field in bytes = 1.
长度指定值字段的长度，单位为字节=1。
CR-LSP FEC Element Type
CR-LSP FEC元件类型
0x04
0x04
CR-LDP defines the following name spaces, which require management:
CR-LDP定义了以下需要管理的名称空间：
- TLV types. - FEC types. - Status codes.
- TLV类型-FEC类型状态代码。
The following sections provide guidelines for managing these name spaces.
以下各节提供了管理这些名称空间的指导原则。
RFC 3036 [1] defines the LDP TLV name space. This document further subdivides the range of RFC 3036 from that TLV space for TLVs associated with the CR-LDP in the range 0x0800 - 0x08FF.
RFC 3036[1]定义LDP TLV名称空间。本文件进一步将RFC 3036的范围从与CR-LDP相关的TLV的该TLV空间细分为0x0800-0x08FF范围。
Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
按照[IANA]中概述的政策，通过IETF共识行动分配此范围内的TLV类型。
Initial values for this range are specified in the following table:
下表规定了该范围的初始值：
TLV Type
-------------------------------------- ----------
Explicit Route TLV 0x0800
Ipv4 Prefix ER-Hop TLV 0x0801
Ipv6 Prefix ER-Hop TLV 0x0802
Autonomous System Number ER-Hop TLV 0x0803
LSP-ID ER-Hop TLV 0x0804
Traffic Parameters TLV 0x0810
Preemption TLV 0x0820
LSPID TLV 0x0821
Resource Class TLV 0x0822
Route Pinning TLV 0x0823
TLV Type
-------------------------------------- ----------
Explicit Route TLV 0x0800
Ipv4 Prefix ER-Hop TLV 0x0801
Ipv6 Prefix ER-Hop TLV 0x0802
Autonomous System Number ER-Hop TLV 0x0803
LSP-ID ER-Hop TLV 0x0804
Traffic Parameters TLV 0x0810
Preemption TLV 0x0820
LSPID TLV 0x0821
Resource Class TLV 0x0822
Route Pinning TLV 0x0823
RFC 3036 defines the FEC Type name space. Further, RFC 3036 has assigned values 0x00 through 0x03. FEC types 0 through 127 are available for assignment through IETF consensus action. This specification makes the following additional assignment, using the policies outlined in [IANA]:
RFC 3036定义FEC类型名称空间。此外，RFC 3036已分配值0x00到0x03。FEC类型0到127可通过IETF共识行动进行分配。本规范使用[IANA]中概述的策略进行以下附加分配：
FEC Element Type
-------------------------------------- ----------
CR-LSP FEC Element 0x04
FEC Element Type
-------------------------------------- ----------
CR-LSP FEC Element 0x04
RFC 3036 defines the Status Code name space. This document further subdivides the range of RFC 3036 from that TLV space for TLVs associated with the CR-LDP in the range 0x04000000 - 0x040000FF.
RFC 3036定义状态代码名称空间。本文件进一步将RFC 3036的范围从与CR-LDP相关的TLV的TLV空间细分为0x04000000-0x04000FF范围。
Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
按照[IANA]中概述的政策，通过IETF共识行动分配此范围内的TLV类型。
Initial values for this range are specified in the following table:
下表规定了该范围的初始值：
Status Code Type
-------------------------------------- ----------
Status Code Type
-------------------------------------- ----------
Bad Explicit Routing TLV Error 0x04000001 Bad Strict Node Error 0x04000002 Bad Loose Node Error 0x04000003 Bad Initial ER-Hop Error 0x04000004 Resource Unavailable 0x04000005 Traffic Parameters Unavailable 0x04000006 LSP Preempted 0x04000007 Modify Request Not Supported 0x04000008
错误的显式路由TLV错误0x0400001错误的严格节点错误0x0400002错误的松散节点错误0x0400003错误的初始ER跃点错误0x0400004资源不可用0x0400005流量参数不可用0x0400006 LSP抢占0x0400007修改请求不支持0x0400008
CR-LDP inherits the same security mechanism described in Section 4.0 of [1] to protect against the introduction of spoofed TCP segments into LDP session connection streams.
CR-LDP继承了[1]第4.0节中描述的相同安全机制，以防止将伪造TCP段引入LDP会话连接流。
The messages used to signal the CR-LSP setup are based on the work done by the LDP [1] design team.
用于向CR-LSP设置发送信号的消息基于LDP[1]设计团队完成的工作。
The list of authors provided with this document is a reduction of the original list. Currently listed authors wish to acknowledge that a substantial amount was also contributed to this work by:
随本文件提供的作者列表是原始列表的缩减。目前列出的作者希望承认，这项工作也有很大一部分是由以下方面贡献的：
Osama Aboul-Magd, Peter Ashwood-Smith, Joel Halpern, Fiffi Hellstrand, Kenneth Sundell and Pasi Vaananen.
奥萨马·阿布·马格德、彼得·阿什伍德·史密斯、乔尔·哈尔潘、菲菲·赫尔斯特兰德、肯尼斯·桑德尔和帕西·瓦纳宁。
The authors would also like to acknowledge the careful review and comments of Ken Hayward, Greg Wright, Geetha Brown, Brian Williams, Paul Beaubien, Matthew Yuen, Liam Casey, Ankur Anand and Adrian Farrel.
作者还想感谢Ken Hayward、Greg Wright、Geetha Brown、Brian Williams、Paul Beaubien、Matthew Yuen、Liam Casey、Ankur Anand和Adrian Farrel的仔细审查和评论。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol Specification", RFC 3036, January 2001.
[1] Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“标签分发协议规范”，RFC 3036，2001年1月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2] Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[3] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[4] Gleeson, B., Lin, A., Heinanen, Armitage, G. and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[4] Gleeson，B.，Lin，A.，Heinanen，Armitage，G.和A.Malis，“基于IP的虚拟专用网络框架”，RFC 27642000年2月。
[5] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G. Wright, "Applicability Statement for CR-LDP", RFC 3213, January 2002.
[5] Ash，J.，Girish，M.，Gray，E.，Jamoussi，B.和G.Wright，“CR-LDP的适用性声明”，RFC 3213，2002年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Boscher, C., Cheval, P., Wu, L. and E. Gray, "LDP State Machine", RFC 3215, January 2002.
[7] Boscher，C.，Cheval，P.，Wu，L.和E.Gray，“自民党国家机器”，RFC 32152002年1月。
[8] Ash, J., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D., Skalecki, D. and L. Li, "LSP Modification Using CR-LDP", RFC 3214, January 2002.
[8] Ash，J.，Lee，Y.，Ashwood Smith，P.，Jamoussi，B.，Fedyk，D.，Skalecki，D.和L.Li，“使用CR-LDP对LSP进行改性”，RFC 32142002年1月。
Appendix A: CR-LSP Establishment Examples
附录A：CR-LSP建立示例
This appendix provides an example for the setup of a strictly routed CR-LSP. In this example, a specific node represents each abstract node.
本附录提供了严格路由CR-LSP的设置示例。在本例中，特定节点表示每个抽象节点。
The sample network used here is a four node network with two edge LSRs and two core LSRs as follows:
此处使用的示例网络是一个具有两个边缘LSR和两个核心LSR的四节点网络，如下所示：
abc
LSR1------LSR2------LSR3------LSR4
abc
LSR1------LSR2------LSR3------LSR4
LSR1 generates a Label Request Message as described in Section 3.1 of this document and sends it to LSR2. This message includes the CR-TLV.
LSR1生成本文件第3.1节所述的标签请求消息，并将其发送给LSR2。此消息包括CR-TLV。
A vector of three ER-Hop TLVs <a, b, c> composes the ER-TLV. The ER-Hop TLVs used in this example are of type 0x0801 (IPv4 prefix) with a prefix length of 32. Hence, each ER-Hop TLV identifies a specific node as opposed to a group of nodes. At LSR2, the following processing of the ER-TLV per Section 4.8.1 of this document takes place:
三个ER-Hop-TLV<A，b，c>的向量构成ER-TLV。本例中使用的ER-Hop TLV类型为0x0801（IPv4前缀），前缀长度为32。因此，每个ER-Hop TLV识别特定节点，而不是一组节点。在LSR2，根据本文件第4.8.1节对ER-TLV进行以下处理：
1. The node LSR2 is part of the abstract node described by the first hop <a>. Therefore, the first step passes the test. Go to step 2.
1. 节点LSR2是第一跳所描述的抽象节点的一部分。因此，第一步通过了测试。转至步骤2。
2. There is a second ER-Hop, <b>. Go to step 3.
2. 还有第二个ER跳跃，<b>。转至步骤3。
3. LSR2 is not part of the abstract node described by the second ER-Hop <b>. Go to Step 4.
3. LSR2不是第二个ER-Hop<b>描述的抽象节点的一部分。转至步骤4。
4. LSR2 determines that it is topologically adjacent to the abstract node described by the second ER-Hop <b>. LSR2 selects a next hop (LSR3) which is the abstract node. LSR2 deletes the first ER-Hop <a> from the ER-TLV, which now becomes <b, c>. Processing continues with Section 4.8.2.
4. LSR2确定它在拓扑上与第二个ER-Hop<b>描述的抽象节点相邻。LSR2选择下一个跃点（LSR3），它是抽象节点。LSR2从ER-TLV中删除第一个ER跃点<a>，该跃点现在变为<b，c>。按照第4.8.2节继续处理。
At LSR2, the following processing of Section 4.8.2 takes place: Executing algorithm 4.8.1 did not result in the removal of the ER-TLV.
在LSR2，第4.8.2节的以下处理发生：执行算法4.8.1没有导致ER-TLV的移除。
Also, LSR2 is not a member of the abstract node described by the first ER-Hop <b>.
此外，LSR2不是由第一ER-Hop<b>描述的抽象节点的成员。
Finally, the first ER-Hop <b> is a strict hop.
最后，第一个ER跃点<b>是严格的跃点。
Therefore, processing section 4.8.2 does not result in the insertion of new ER-Hops. The selection of the next hop has been already done is step 4 of Section 4.8.1 and the processing of the ER-TLV is completed at LSR2. In this case, the Label Request Message including the ER-TLV <b, c> is progressed by LSR2 to LSR3.
因此，处理第4.8.2节不会导致插入新的ER跳。下一跳的选择已经在第4.8.1节的步骤4中完成，ER-TLV的处理在LSR2处完成。在这种情况下，包括ER-TLV<b，c>的标签请求消息由LSR2前进到LSR3。
At LSR3, a similar processing to the ER-TLV takes place except that
the incoming ER-TLV = <b, c> and the outgoing ER-TLV is <c>.
At LSR3, a similar processing to the ER-TLV takes place except that
the incoming ER-TLV = <b, c> and the outgoing ER-TLV is <c>.
At LSR4, the following processing of section 4.8.1 takes place:
在LSR4，对第4.8.1节进行以下处理：
1. The node LSR4 is part of the abstract node described by the first hop <c>. Therefore, the first step passes the test. Go to step 2.
1. 节点LSR4是第一跳所描述的抽象节点的一部分。因此，第一步通过了测试。转至步骤2。
2. There is no second ER-Hop, this indicates the end of the CR-LSP. The ER-TLV is removed from the Label Request Message. Processing continues with Section 4.8.2.
2. 没有第二个ER跃点，这表示CR-LSP结束。ER-TLV将从标签请求消息中删除。按照第4.8.2节继续处理。
At LSR4, the following processing of Section 4.8.2 takes place: Executing algorithm 4.8.1 resulted in the removal of the ER-TLV. LSR4 does not add a new ER-TLV.
在LSR4，第4.8.2节的以下处理发生：执行算法4.8.1导致移除ER-TLV。LSR4没有添加新的ER-TLV。
Therefore, processing section 4.8.2 does not result in the insertion of new ER-Hops. This indicates the end of the CR-LSP and the processing of the ER-TLV is completed at LSR4.
因此，处理第4.8.2节不会导致插入新的ER跳。这表示CR-LSP结束，ER-TLV的处理在LSR4完成。
At LSR4, processing of Section 3.2 is invoked. The first condition is satisfied (LSR4 is the egress end of the CR-LSP and upstream mapping has been requested). Therefore, a Label Mapping Message is generated by LSR4 and sent to LSR3.
在LSR4，调用第3.2节的处理。满足第一个条件（LSR4是CR-LSP的出口端，已请求上游映射）。因此，标签映射消息由LSR4生成并发送到LSR3。
At LSR3, the processing of Section 3.2 is invoked. The second condition is satisfied (LSR3 received a mapping from its downstream next hop LSR4 for a CR-LSP for which an upstream request is still pending). Therefore, a Label Mapping Message is generated by LSR3 and sent to LSR2.
在LSR3，调用第3.2节的处理。满足第二个条件（LSR3从其下游下一跳LSR4接收到CR-LSP的映射，对于该CR-LSP，上游请求仍处于挂起状态）。因此，标签映射消息由LSR3生成并发送给LSR2。
At LSR2, a similar processing to LSR 3 takes place and a Label Mapping Message is sent back to LSR1, which completes the end-to-end CR-LSP setup.
在LSR2，发生与LSR 3类似的处理，并将标签映射消息发送回LSR1，从而完成端到端CR-LSP设置。
A request at ingress LSR to setup a CR-LSP might originate from a management system or an application, the details are implementation specific.
在ingress LSR处设置CR-LSP的请求可能来自管理系统或应用程序，详细信息是特定于实现的。
The ingress LSR uses information provided by the management system or the application and possibly also information from the routing database to calculate the explicit route and to create the Label Request Message.
入口LSR使用管理系统或应用程序提供的信息以及可能来自路由数据库的信息来计算显式路由并创建标签请求消息。
The Label request message carries together with other necessary information an ER-TLV defining the explicitly routed path. In our example the list of hops in the ER-Hop TLV is supposed to contain an abstract node representing a group of nodes, an abstract node representing a specific node, another abstract node representing a group of nodes, and an abstract node representing a specific egress point.
标签请求消息与其他必要信息一起携带定义显式路由路径的ER-TLV。在我们的示例中，ER-Hop TLV中的跳列表假定包含表示一组节点的抽象节点、表示特定节点的抽象节点、表示一组节点的另一抽象节点以及表示特定出口点的抽象节点。
In--{Group 1}--{Specific A}--{Group 2}--{Specific Out: B} The ER-TLV contains four ER-Hop TLVs:
在--{group1}--{Specific A}--{group2}--{Specific Out:B}中，ER-TLV包含四个ER-Hop TLV：
1. An ER-Hop TLV that specifies a group of LSR valid for the first abstract node representing a group of nodes (Group 1).
1. 一种ER-Hop TLV，指定对表示一组节点（组1）的第一个抽象节点有效的一组LSR。
2. An ER-Hop TLV that indicates the specific node (Node A).
2. 指示特定节点（节点A）的ER-Hop TLV。
3. An ER-Hop TLV that specifies a group of LSRs valid for the second abstract node representing a group of nodes (Group 2).
3. 一种ER-Hop TLV，指定对表示一组节点（组2）的第二个抽象节点有效的一组LSR。
4. An ER-Hop TLV that indicates the specific egress point for the CR-LSP (Node B).
4. 指示CR-LSP（节点B）的特定出口点的ER-Hop TLV。
All the ER-Hop TLVs are strictly routed nodes.
所有ER-Hop tlv都是严格路由的节点。
The setup procedure for this CR-LSP works as follows:
该CR-LSP的设置程序如下所示：
1. The ingress node sends the Label Request Message to a node that is a member the group of nodes indicated in the first ER-Hop TLV, following normal routing for the specific node (A).
1. 入口节点按照特定节点（a）的正常路由，将标签请求消息发送到作为第一ER-Hop TLV中指示的节点组的成员的节点。
2. The node that receives the message identifies itself as part of the group indicated in the first ER-Hop TLV, and that it is not the specific node (A) in the second. Further it realizes that the specific node (A) is not one of its next hops.
2. 接收消息的节点将自己标识为第一个ER-Hop TLV中指示的组的一部分，并且它不是第二个ER-Hop TLV中的特定节点（A）。此外，它认识到特定节点（A）不是其下一跳之一。
3. It keeps the ER-Hop TLVs intact and sends a Label Request Message to another node that is part of the group indicated in the first ER-Hop TLV (Group 1), following normal routing for the specific node (A).
3. 它保持ER-Hop TLV完好无损，并在特定节点（a）的正常路由之后，向属于第一ER-Hop TLV（组1）中指示的组的另一个节点发送标签请求消息。
4. The node that receives the message identifies itself as part of the group indicated in the first ER-Hop TLV, and that it is not the specific node (A) in the second ER-Hop TLV. Further it realizes that the specific node (A) is one of its next hops.
4. 接收消息的节点将自己标识为第一ER-Hop TLV中指示的组的一部分，并且它不是第二ER-Hop TLV中的特定节点（A）。此外，它认识到特定节点（A）是其下一跳之一。
5. It removes the first ER-Hop TLVs and sends a Label Request Message to the specific node (A).
5. 它删除第一个ER-Hop tlv，并向特定节点（a）发送标签请求消息。
6. The specific node (A) recognizes itself in the first ER-Hop TLV. Removes the specific ER-Hop TLV.
6. 特定节点（A）在第一ER-Hop TLV中识别自身。删除特定的ER Hop TLV。
7. It sends a Label Request Message to a node that is a member of the group (Group 2) indicated in the ER-Hop TLV.
7. 它向属于ER Hop TLV中指示的组（组2）成员的节点发送标签请求消息。
8. The node that receives the message identifies itself as part of the group indicated in the first ER-Hop TLV, further it realizes that the specific egress node (B) is one of its next hops.
8. 接收消息的节点将自己标识为在第一ER-Hop TLV中指示的组的一部分，进一步地，它认识到特定出口节点（B）是其下一跳之一。
9. It sends a Label Request Message to the specific egress node (B).
9. 它向特定出口节点（B）发送标签请求消息。
10. The specific egress node (B) recognizes itself as the egress for the CR-LSP, it returns a Label Mapping Message, that will traverse the same path as the Label Request Message in the opposite direction.
10. 特定出口节点（B）将自身识别为CR-LSP的出口，它返回标签映射消息，该消息将以相反方向穿过与标签请求消息相同的路径。
Construction of an end-to-end service is the result of the rules enforced at the edge and the treatment that packets receive at the network nodes. The rules define the traffic conditioning actions that are implemented at the edge and they include policing with pass, mark, and drop capabilities. The edge rules are expected to be defined by the mutual agreements between the service providers and their customers and they will constitute an essential part of the SLA. Therefore edge rules are not included in the signaling protocol.
端到端服务的构造是在边缘强制执行的规则和在网络节点接收的数据包的处理的结果。这些规则定义了在边缘实施的流量调节操作，包括使用通行、标记和下降功能进行监控。边缘规则预计由服务提供商及其客户之间的相互协议定义，它们将构成SLA的重要组成部分。因此，边缘规则不包括在信令协议中。
Packet treatment at a network node is usually referred to as the local behavior. Local behavior could be specified in many ways. One example for local behavior specification is the service frequency introduced in section 4.3.2.1, together with the resource reservation rules implemented at the nodes.
网络节点上的数据包处理通常称为本地行为。可以通过多种方式指定局部行为。本地行为规范的一个示例是第4.3.2.1节中介绍的服务频率，以及在节点上实现的资源保留规则。
Edge rules and local behaviors can be viewed as the main building blocks for the end-to-end service construction. The following table illustrates the applicability of the building block approach for constructing different services including those defined for ATM.
边缘规则和局部行为可以被视为端到端服务构造的主要构建块。下表说明了构建块方法在构建不同服务（包括为ATM定义的服务）时的适用性。
Service PDR PBS CDR CBS EBS Service Conditioning Examples Frequency Action
维修PDR PBS CDR CBS EBS维修条件示例频率动作
DS S S =PDR =PBS 0 Frequent drop>PDR
DS S S =PDR =PBS 0 Frequent drop>PDR
TS S S S S 0 Unspecified drop>PDR,PBS mark>CDR,CBS
TS 0未指定下降>PDR，PBS标记>CDR，CBS
BE inf inf inf inf 0 Unspecified -
BE inf 0未指定-
FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS
mark>CDR,CBS,EBS
FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS
mark>CDR,CBS,EBS
ATM-CBR PCR CDVT =PCR =CDVT 0 VeryFrequent drop>PCR
ATM-CBR PCR CDVT =PCR =CDVT 0 VeryFrequent drop>PCR
ATM-VBR.3(rt) PCR CDVT SCR MBS 0 Frequent drop>PCR mark>SCR,MBS
ATM-VBR.3（rt）PCR CDVT SCR MBS 0频繁下降>PCR标记>SCR，MBS
ATM-VBR.3(nrt) PCR CDVT SCR MBS 0 Unspecified drop>PCR mark>SCR,MBS
ATM-VBR.3（nrt）PCR CDVT SCR MBS 0未指定下降>PCR标记>SCR，MBS
ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR
ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR
ATM-GFR.1 PCR CDVT MCR MBS 0 Unspecified drop>PCR
ATM-GFR.1 PCR CDVT MCR MBS 0未指定滴落>PCR
ATM-GFR.2 PCR CDVT MCR MBS 0 Unspecified drop>PCR mark>MCR,MFS
ATM-GFR.2 PCR CDVT MCR MBS 0未指定下降>PCR标记>MCR，MFS
int-serv-CL p m r b 0 Frequent drop>p drop>r,b
int serv CL p m r b 0频繁下降>p下降>r，b
S= User specified
S=用户指定的
In the above table, the DS refers to a delay sensitive service where the network commits to deliver with high probability user datagrams at a rate of PDR with minimum delay and delay requirements. Datagrams in excess of PDR will be discarded.
在上表中，DS指的是延迟敏感服务，其中网络承诺以PDR速率以最小延迟和延迟要求交付高概率用户数据报。超过PDR的数据报将被丢弃。
The TS refers to a generic throughput sensitive service where the network commits to deliver with high probability user datagrams at a rate of at least CDR. The user may transmit at a rate higher than CDR but datagrams in excess of CDR would have a lower probability of being delivered.
TS指的是通用吞吐量敏感服务，其中网络承诺以至少CDR的速率交付高概率用户数据报。用户可以以高于CDR的速率进行传输，但是超过CDR的数据报将具有较低的交付概率。
The BE is the best effort service and it implies that there are no expected service guarantees from the network.
BE是尽力而为的服务，它意味着没有来自网络的预期服务保证。
In this scenario the customer needs to establish an LSP for supporting real-time applications such as voice and video. The Delay-sensitive (DS) service is requested in this case.
在这种情况下，客户需要建立一个LSP来支持实时应用程序，如语音和视频。在这种情况下，请求延迟敏感（DS）服务。
The first step is the specification of the traffic parameters in the signaling message. The two parameters of interest to the DS service are the PDR and the PBS and the user based on his requirements specifies their values. Since all the traffic parameters are included in the signaling message, appropriate values must be assigned to all of them. For DS service, the CDR and the CBS values are set equal to the PDR and the PBS respectively. An indication of whether the parameter values are subject to negotiation is flagged.
第一步是在信令消息中指定业务参数。DS服务感兴趣的两个参数是PDR和PBS，用户根据其需求指定其值。由于所有业务参数都包含在信令消息中，因此必须为所有这些参数分配适当的值。对于DS服务，CDR和CBS值分别设置为等于PDR和PBS。标记是否协商参数值的指示。
The transport characteristics of the DS service require Frequent frequency to be requested to reflect the real-time delay requirements of the service.
DS服务的传输特性要求频繁请求频率，以反映服务的实时延迟要求。
In addition to the transport characteristics, both the network provider and the customer need to agree on the actions enforced at the edge. The specification of those actions is expected to be a part of the service level agreement (SLA) negotiation and is not included in the signaling protocol. For DS service, the edge action is to drop packets that exceed the PDR and the PBS specifications. The signaling message will be sent in the direction of the ER path and the LSP is established following the normal LDP procedures. Each LSR applies its admission control rules. If sufficient resources are not available and the parameter values are subject to negotiation, then the LSR could negotiate down the PDR, the PBS, or both.
除了传输特性外，网络提供商和客户还需要就在边缘实施的操作达成一致。这些操作的规范预计是服务水平协议（SLA）协商的一部分，不包括在信令协议中。对于DS服务，边缘操作是丢弃超过PDR和PBS规范的数据包。信令消息将沿着ER路径的方向发送，并且按照正常LDP过程建立LSP。每个LSR应用其准入控制规则。如果没有足够的资源可用，并且参数值需要协商，那么LSR可以协商PDR、PBS或两者。
The new parameter values are echoed back in the Label Mapping Message. LSRs might need to re-adjust their resource reservations based on the new traffic parameter values.
新参数值将在标签映射消息中回显。LSR可能需要根据新的流量参数值重新调整其资源预留。
In this example we assume that a throughput sensitive (TS) service is requested. For resource allocation the user assigns values for PDR, PBS, CDR, and CBS. The negotiation flag is set if the traffic parameters are subject to negotiation. Since the service is delay insensitive by definition, the Unspecified frequency is signaled to indicate that the service frequency is not an issue.
在本例中，我们假设请求了吞吐量敏感（TS）服务。对于资源分配，用户为PDR、PBS、CDR和CBS分配值。如果要协商流量参数，则设置协商标志。由于服务定义为延迟不敏感，因此会发出未指定频率的信号，表明服务频率不是问题。
Similar to the previous example, the edge actions are not subject for signaling and are specified in the service level agreement between the user and the network provider.
与前面的示例类似，边缘动作不受信令约束，并且在用户和网络提供商之间的服务级别协议中指定。
For TS service, the edge rules might include marking to indicate high discard precedence values for all packets that exceed CDR and the CBS. The edge rules will also include dropping of packets that conform to neither PDR nor PBS.
对于TS服务，边缘规则可能包括标记，以指示超过CDR和CBS的所有数据包的高丢弃优先级值。边缘规则还包括丢弃既不符合PDR也不符合PBS的数据包。
Each LSR of the LSP is expected to run its admission control rules and negotiate traffic parameters down if sufficient resources do not exist. The new parameter values are echoed back in the Label Mapping Message. LSRs might need to re-adjust their resources based on the new traffic parameter values.
如果没有足够的资源，LSP的每个LSR都将运行其准入控制规则并向下协商流量参数。新参数值将在标签映射消息中回显。LSR可能需要根据新的流量参数值重新调整其资源。
Loa Andersson Utfors Bredband AB Rasundavagen 12 169 29 Solna Phone: +46 8 5270 50 38 EMail: loa.andersson@utfors.se
Loa Andersson Utfors Bredband AB Rasundavagen 12 169 29 Solna电话：+46 8 5270 50 38电子邮件：Loa。andersson@utfors.se
Ross Callon Juniper Networks 1194 North Mathilda Avenue, Sunnyvale, CA 94089 Phone: 978-692-6724 EMail: rcallon@juniper.net
Ross Callon Juniper Networks加利福尼亚州桑尼维尔北马蒂尔达大道1194号电话：978-692-6724电子邮件：rcallon@juniper.net
Ram Dantu Netrake Corporation 3000 Technology Drive, #100 Plano Texas, 75024 Phone: 214 291 1111 EMail: rdantu@netrake.com
Ram Dantu Netrake Corporation 3000 Technology Drive，德克萨斯州普莱诺100号，邮编75024电话：214 291 1111电子邮件：rdantu@netrake.com
Paul Doolan On The Beach Consulting Corp 34 Mill Pond Circle Milford MA 01757 Phone 617 513 852 EMail: pdoolan@acm.org
Paul Doolan On The Beach Consulting Corp 34 Mill Pond Circle Milford MA 01757电话617 513 852电子邮件：pdoolan@acm.org
Nancy Feldman IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 Phone: 914-784-3254 EMail: Nkf@us.ibm.com
Nancy Feldman IBM Research 30 Saw Mill River Road Howthorne，NY 10532电话：914-784-3254电子邮件：Nkf@us.ibm.com
Andre Fredette ANF Consulting 62 Duck Pond Dr. Groton, MA 01450 EMail: afredette@charter.net
Andre Fredette ANF Consulting 62 Duck Pond Groton博士，马萨诸塞州01450电子邮件：afredette@charter.net
Eric Gray 600 Federal Drive Andover, MA 01810 Phone: (978) 689-1610 EMail: eric.gray@sandburst.com
Eric Gray马萨诸塞州安多弗联邦大道600号电话：（978）689-1610电子邮件：Eric。gray@sandburst.com
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland EMail: jh@song.fi
Juha Heinanen Song Networks，Inc.Hallituskatu 16 33200芬兰坦佩雷电子邮件：jh@song.fi
Bilel Jamoussi Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288-4506 Mail: Jamoussi@nortelnetworks.com
Billel Jamoussi Nortel Networks 600美国马萨诸塞州比尔里卡科技园大道01821电话：+1 978 288-4506邮件：Jamoussi@nortelnetworks.com
Timothy E. Kilty Island Consulting Phone: (978) 462 7091 EMail: tim-kilty@mediaone.net
Timothy E.Kilty岛咨询电话：（978）462 7091电子邮件：tim-kilty@mediaone.net
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 EMail: Andy.Malis@vivacenetworks.com
Andrew G.Malis Vivace Networks 2730 Orchard Parkway San Jose，CA 95134电话：+1 408 383 7223电子邮件：Andy。Malis@vivacenetworks.com
Muckai K Girish Atoga Systems 49026 Milmont Drive Fremont, CA 94538 EMail: muckai@atoga.com
Muckai K Girish Atoga Systems 49026加利福尼亚州弗里蒙特市密尔蒙特大道94538电子邮件：muckai@atoga.com
Tom Worster Phone: 617 247 2624 EMail: fsb@thefsb.org
Tom Worster电话：617 247 2624电子邮件：fsb@thefsb.org
Liwen Wu Cisco Systems 250 Apollo Drive Chelmsford, MA. 01824 Phone: 978-244-3087 EMail: liwwu@cisco.com
吴立文思科系统公司，马萨诸塞州切姆斯福德阿波罗大道250号。01824电话：978-244-3087电子邮件：liwwu@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。