Network Working Group F. Le Faucheur, Editor
Request for Comments: 3270 L. Wu
Category: Standards Track B. Davie
Cisco Systems
S. Davari
PMC-Sierra Inc.
P. Vaananen
Nokia
R. Krishnan
Axiowave Networks
P. Cheval
Alcatel
J. Heinanen
Song Networks
May 2002
Network Working Group F. Le Faucheur, Editor
Request for Comments: 3270 L. Wu
Category: Standards Track B. Davie
Cisco Systems
S. Davari
PMC-Sierra Inc.
P. Vaananen
Nokia
R. Krishnan
Axiowave Networks
P. Cheval
Alcatel
J. Heinanen
Song Networks
May 2002
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
对区分服务的多协议标签交换（MPLS）支持
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 defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks.
本文档定义了通过多协议标签交换（MPLS）网络支持区分服务（Diff-Serv）的灵活解决方案。
This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs.
此解决方案允许MPLS网络管理员选择如何将区分服务行为聚合（BAs）映射到标签交换路径（LSP），以便他/她能够最好地匹配其特定网络中的区分服务、流量工程和保护目标。例如，此解决方案允许网络管理员决定是将不同的BAs集映射到同一LSP上，还是映射到单独的LSP上。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.5 Encoding Diff-Serv information into Encapsulation Layer On
Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
4. Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
4.5 Encoding Diff-Serv Information into Encapsulation Layer on
Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.5 Encoding Diff-Serv information into Encapsulation Layer On
Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
4. Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
4.5 Encoding Diff-Serv Information into Encapsulation Layer on
Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a common path, a Label Switched Path (LSP) can be established using MPLS signaling protocols. At the ingress Label Switch Router (LSR), each packet is assigned a label and is transmitted downstream. At each LSR along the LSP, the label is used to forward the packet to the next hop.
在MPLS域[MPLS_ARCH]中，当数据流穿过公共路径时，可以使用MPLS信令协议建立标签交换路径（LSP）。在入口标签交换路由器（LSR）处，每个数据包被分配一个标签并向下游传输。在沿着LSP的每个LSR处，标签用于将数据包转发到下一跳。
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP packets crossing a link and requiring the same Diff-Serv behavior are said to constitute a Behavior Aggregate (BA). At the ingress node of the Diff-Serv domain, the packets are classified and marked with a Diff-Serv Code Point (DSCP) which corresponds to their Behavior Aggregate. At each transit node, the DSCP is used to select the Per Hop Behavior (PHB) that determines the scheduling treatment and, in some cases, drop probability for each packet.
在区分服务（Diff-Serv）域[Diff_ARCH]中，所有通过链路且需要相同区分服务行为的IP数据包被称为构成行为聚合（BA）。在Diff-Serv域的入口节点，分组被分类并用与其行为聚合相对应的Diff-Serv码点（DSCP）进行标记。在每个传输节点，DSCP用于选择每跳行为（PHB），该行为决定调度处理，在某些情况下，还决定每个数据包的丢弃概率。
This document specifies a solution for supporting the Diff-Serv Behavior Aggregates whose corresponding PHBs are currently defined (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This solution also offers flexibility for easy support of PHBs that may be defined in the future.
本文档指定了一种解决方案，用于支持在MPLS网络上当前定义了相应PHB（在[Diff_HEADER]、[Diff_AF]、[Diff_EF]中）的Diff-Serv行为聚合。此解决方案还提供了灵活性，可方便地支持将来可能定义的PHB。
This solution relies on the combined use of two types of LSPs:
此解决方案依赖于两种LSP的组合使用：
- LSPs which can transport multiple Ordered Aggregates, so that the EXP field of the MPLS Shim Header conveys to the LSR the PHB to be applied to the packet (covering both information about the packet's scheduling treatment and its drop precedence).
- 可以传输多个有序聚合的LSP，以便MPLS垫片报头的EXP字段将要应用于数据包的PHB传送给LSR（包括关于数据包的调度处理及其丢弃优先级的信息）。
- LSPs which only transport a single Ordered Aggregate, so that the packet's scheduling treatment is inferred by the LSR exclusively from the packet's label value while the packet's drop precedence is conveyed in the EXP field of the MPLS Shim Header or in the encapsulating link layer specific selective drop mechanism (ATM, Frame Relay, 802.1).
- 仅传输单个有序聚合的LSP，因此LSR仅从数据包的标签值推断数据包的调度处理，而数据包的丢弃优先级在MPLS垫片报头的EXP字段或封装链路层特定的选择性丢弃机制（ATM、帧中继、802.1）中传输。
As mentioned in [DIFF_HEADER], "Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". Thus, the solution defined in this document gives Service Providers flexibility in selecting how Diff-Serv classes of service are Routed or Traffic Engineered within their domain (e.g., separate classes of services supported via separate LSPs and Routed separately, all classes of service supported on the same LSP and Routed together).
如[DIFF_HEADER]所述，“服务提供商不需要使用相同的节点机制或配置来实现其网络内的服务差异化，并且可以自由地以适合其服务产品和流量工程目标的任何方式配置节点参数”。因此，本文档中定义的解决方案为服务提供商提供了选择如何在其域内路由区分服务类服务或流量工程的灵活性（例如，通过单独的LSP支持的单独服务类，单独路由，在同一LSP上支持的所有服务类，并一起路由）。
Because MPLS is path-oriented it can potentially provide faster and more predictable protection and restoration capabilities in the face of topology changes than conventional hop by hop routed IP systems. In this document we refer to such capabilities as "MPLS protection". Although such capabilities and associated mechanisms are outside the scope of this specification, we note that they may offer different levels of protection to different LSPs. Since the solution presented here allow Service Providers to choose how Diff-Serv classes of services are mapped onto LSPs, the solution also gives Service Providers flexibility in the level of protection provided to different Diff-Serv classes of service (e.g., some classes of service can be supported by LSPs which are protected while some other classes of service are supported by LSPs which are not protected).
由于MPLS是面向路径的，与传统的逐跳路由IP系统相比，它在面对拓扑变化时可能提供更快、更可预测的保护和恢复能力。在本文档中，我们将这些功能称为“MPLS保护”。尽管此类功能和相关机制不在本规范的范围内，但我们注意到它们可能为不同的LSP提供不同级别的保护。由于此处提供的解决方案允许服务提供商选择如何将区分服务类映射到LSP，因此该解决方案还使服务提供商能够灵活地为不同的区分服务类提供保护级别（例如，某些类别的服务可由受保护的LSP支持，而其他类别的服务则由不受保护的LSP支持）。
Furthermore, the solution specified in this document achieves label space conservation and reduces the volume of label set-up/tear-down signaling where possible by only resorting to multiple LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or required.
此外，本文件中规定的解决方案实现了标签空间节约，并尽可能通过在有用或需要时仅对给定转发等效类（FEC）[MPLS_ARCH]使用多个LSP来减少标签设置/拆除信令的数量。
This specification allows support of Differentiated Services for both IPv4 and IPv6 traffic transported over an MPLS network. This document only describes operations for unicast. Multicast support is for future study.
此规范允许对通过MPLS网络传输的IPv4和IPv6流量提供区分服务支持。本文档仅描述单播的操作。多播支持有待进一步研究。
The solution described in this document does not preclude the signaled or configured use of the EXP bits to support Explicit Congestion Notification [ECN] simultaneously with Diff-Serv over MPLS. However, techniques for supporting ECN in an MPLS environment are outside the scope of this document.
本文档中描述的解决方案并不排除通过信号或配置使用EXP位来支持显式拥塞通知[ECN]，同时通过MPLS实现区分服务。然而，在MPLS环境中支持ECN的技术不在本文档的范围之内。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
The reader is assumed to be familiar with the terminology of [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including the following:
假定读者熟悉[MPLS_ARCH]、[MPLS_ENCAPS]、[MPLS_ATM]、[MPLS_FR]的术语，包括以下内容：
FEC Forwarding Equivalency Class
转发等价类
FTN FEC-To-NHLFE Map
FTN FEC到NHLFE映射
ILM Incoming Label Map
ILM传入标签映射
LC-ATM Label Switching Controlled-ATM (interface)
LC-ATM标签交换控制ATM（接口）
LC-FR Label Switching Controlled-Frame Relay (interface)
LC-FR标签切换控制帧继电器（接口）
LSP Label Switched Path
标签交换路径
LSR Label Switch Router
标签交换路由器
MPLS Multi-Protocol Label Switching
多协议标签交换
NHLFE Next Hop Label Forwarding Entry
NHLFE下一跳标签转发条目
The reader is assumed to be familiar with the terminology of [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including the following:
假定读者熟悉[DIFF_ARCH]、[DIFF_HEADER]、[DIFF_AF]、[DIFF_EF]的术语，包括以下内容：
AF Assured Forwarding
自动对焦保证转发
BA Behavior Aggregate
BA行为集料
CS Class Selector
CS类选择器
DF Default Forwarding
默认转发
DSCP Differentiated Services Code Point
区分服务代码点
EF Expedited Forwarding
快速转发
PHB Per Hop Behavior
PHB每跳行为
The reader is assumed to be familiar with the terminology of [DIFF_NEW], including the following:
假定读者熟悉[DIFF_NEW]的术语，包括以下内容：
OA Ordered Aggregate. The set of Behavior Aggregates which share an ordering constraint.
有序聚合。共享排序约束的行为集合。
PSC PHB Scheduling Class. The set of one or more PHB(s) that are applied to the Behavior Aggregate(s) belonging to a given OA. For example, AF1x is a PSC comprising the AF11, AF12 and AF13 PHBs. EF is an example of PSC comprising a single PHB, the EF PHB.
PSC PHB调度类。应用于属于给定OA的行为聚合的一个或多个PHB的集合。例如，AF1x是包括AF11、AF12和AF13 phb的PSC。EF是包含单个PHB（EF PHB）的PSC的示例。
The following acronyms are also used:
还使用了以下首字母缩略词：
CLP Cell Loss Priority
CLP信元丢失优先级
DE Discard Eligibility
取消放弃资格
SNMP Simple Network Management Protocol
简单网络管理协议
Finally, the following acronyms are defined in this specification:
最后，本规范中定义了以下首字母缩略词：
E-LSP EXP-Inferred-PSC LSP
E-LSP EXP推断PSC LSP
L-LSP Label-Only-Inferred-PSC LSP
L-LSP标签仅推断PSC LSP
A single LSP can be used to support one or more OAs. Such LSPs can support up to eight BAs of a given FEC, regardless of how many OAs these BAs span. With such LSPs, the EXP field of the MPLS Shim Header is used by the LSR to determine the PHB to be applied to the packet. This includes both the PSC and the drop preference.
单个LSP可用于支持一个或多个OA。这种LSP最多可以支持给定FEC的八个BAs，而不管这些BAs跨越多少个OA。对于这种lsp，LSR使用MPLS垫片报头的EXP字段来确定要应用于分组的PHB。这包括PSC和drop首选项。
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the PSC of a packet transported on this LSP depends on the EXP field value for that packet.
我们将此类LSP称为“EXP推断的PSC LSP”（E-LSP），因为在此LSP上传输的数据包的PSC取决于该数据包的EXP字段值。
The mapping from the EXP field to the PHB (i.e., to PSC and drop precedence) for a given such LSP, is either explicitly signaled at label set-up or relies on a pre-configured mapping.
对于给定的此类LSP，从EXP字段到PHB（即到PSC和drop优先级）的映射要么在标签设置时显式发出信号，要么依赖于预配置的映射。
Detailed operations of E-LSPs are specified in section 3 below.
下文第3节规定了电子LSP的详细操作。
A separate LSP can be established for a single <FEC, OA> pair. With such LSPs, the PSC is explicitly signaled at the time of label establishment, so that after label establishment, the LSR can infer exclusively from the label value the PSC to be applied to a labeled packet. When the Shim Header is used, the Drop Precedence to be applied by the LSR to the labeled packet, is conveyed inside the labeled packet MPLS Shim Header using the EXP field. When the Shim Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be applied by the LSR to the labeled packet is conveyed inside the link layer header encapsulation using link layer specific drop precedence fields (e.g., ATM CLP).
可以为单个<FEC，OA>对建立单独的LSP。利用这样的lsp，在标签建立时显式地向PSC发信号，以便在标签建立之后，LSR可以从标签值独家地推断要应用于标签分组的PSC。当使用垫片报头时，LSR将应用于标记数据包的丢弃优先级将使用EXP字段在标记数据包MPLS垫片报头内传送。当不使用垫片报头（例如，ATM上的MPLS）时，LSR应用于标记分组的丢弃优先级使用链路层特定的丢弃优先级字段（例如，ATM CLP）在链路层报头封装内部传送。
We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since the PSC can be fully inferred from the label without any other information (e.g., regardless of the EXP field value). Detailed operations of L-LSPs are specified in section 4 below.
我们将此类LSP称为“仅标签推断的PSC LSP”（L-LSP），因为PSC可以完全从标签推断，而无需任何其他信息（例如，无论EXP字段值如何）。下文第4节规定了L-LSP的详细操作。
For a given FEC, and unless media specific restrictions apply as identified in the sections 7, 8 and 9 below, this specification allows any one of the following combinations within an MPLS Diff-Serv domain:
对于给定的FEC，除非适用下文第7、8和9节中确定的特定于媒体的限制，否则本规范允许MPLS区分服务域内的以下任意组合：
- zero or any number of E-LSPs, and
- 零个或任意数量的E-LSP，以及
- zero or any number of L-LSPs.
- 零或任意数量的L-LSP。
The network administrator selects the actual combination of LSPs from the set of allowed combinations and selects how the Behavior Aggregates are actually transported over this combination of LSPs, in order to best match his/her environment and objectives in terms of Diff-Serv support, Traffic Engineering and MPLS Protection. Criteria for selecting such a combination are outside the scope of this specification.
网络管理员从一组允许的组合中选择LSP的实际组合，并选择如何通过该LSP组合实际传输行为聚合，以便在区分服务支持、流量工程和MPLS保护方面最佳匹配其环境和目标。选择此类组合的标准不在本规范的范围内。
For a given FEC, there may be more than one LSP carrying the same OA, for example for purposes of load balancing of the OA; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) BAs of a given OA.
对于给定的FEC，可能有多个LSP承载相同的OA，例如为了OA的负载平衡；然而，为了遵守排序约束，给定微流的所有数据包（可能跨越给定有序聚合的多个BAs）必须通过同一LSP进行传输。相反，每个LSP必须能够支持给定OA的所有（活动）BAs。
Examples of deployment scenarios are provided for information in APPENDIX A.
附录A中提供了部署场景示例以供参考。
[MPLS_ARCH] states in section `2.1. Overview' that: `Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.'
[MPLS_ARCH]在第2.1节中说明。概述：`一些路由器分析数据包的网络层报头不仅是为了选择数据包的下一跳，而且是为了确定数据包的“优先级”或“服务类别”。然后，他们可以对不同的数据包应用不同的丢弃阈值或调度规程。MPLS允许（但不要求）从标签中完全或部分推断服务的优先级或类别。在这种情况下，可以说标签代表FEC和优先级或服务类别的组合。”
In line with this, we observe that:
有鉴于此，我们认为：
- With E-LSPs, the label represents the combination of a FEC and the set of BAs transported over the E-LSP. Where all the supported BAs are transported over an E-LSP, the label then represents the complete FEC.
- 对于E-LSP，标签表示FEC和通过E-LSP传输的BAs集的组合。如果所有受支持的BAs通过E-LSP传输，则标签表示完整的FEC。
- With L-LSPs, the label represents the combination of a FEC and an OA.
- 对于L-LSP，标签表示FEC和OA的组合。
Regardless of which label binding protocol is used, E-LSPs and L-LSPs may be established with or without bandwidth reservation.
无论使用哪种标签绑定协议，E-LSP和L-LSP都可以在有或没有带宽预留的情况下建立。
Establishing an E-LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signaled at LSP establishment time. Such signaled bandwidth requirements may be used by LSRs at establishment time to perform admission control of the signaled LSP over the Diff-Serv resources provisioned (e.g., via configuration, SNMP or policy protocols) for the relevant PSC(s). Such signaled bandwidth requirements may also be used by LSRs at establishment time to perform adjustment to the Diff-Serv resources associated with the relevant PSC(s) (e.g., adjust PSC scheduling weight).
建立具有带宽预留的E-LSP或L-LSP意味着在LSP建立时用信号通知LSP的带宽需求。lsr可以在建立时使用这种信号带宽需求，通过为相关PSC提供的区分服务资源（例如，通过配置、SNMP或策略协议）来执行信号LSP的接纳控制。lsr还可以在建立时使用这种信号带宽需求来执行对与相关PSC相关联的区分服务资源的调整（例如，调整PSC调度权重）。
Note that establishing an E-LSP or L-LSP with bandwidth reservation does not mean that per-LSP scheduling is required. Since E-LSPs and L-LSPs are specified in this document for support of Differentiated Services, the required forwarding treatment (scheduling and drop policy) is defined by the appropriate Diff-Serv PHB. This forwarding treatment MUST be applied by the LSR at the granularity of the BA and MUST be compliant with the relevant PHB specification.
注意，建立具有带宽保留的E-LSP或L-LSP并不意味着需要每个LSP调度。由于本文档中规定了E-LSP和L-LSP以支持区分服务，因此所需的转发处理（调度和丢弃策略）由相应的区分服务PHB定义。LSR必须在BA粒度上应用此转发处理，并且必须符合相关PHB规范。
When bandwidth requirements are signaled at the establishment of an L-LSP, the signaled bandwidth is obviously associated with the L-LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform admission control may perform admission control over Diff-Serv resources, which are dedicated to the PSC (e.g., over the bandwidth guaranteed to the PSC through its scheduling weight).
当在建立L-LSP时发送带宽需求信号时，发送的带宽显然与L-LSP的PSC相关。因此，使用信号带宽来执行接纳控制的lsr可以对专用于PSC的Diff-Serv资源执行接纳控制（例如，通过其调度权重对PSC保证的带宽）。
When bandwidth requirements are signaled at the establishment of an E-LSP, the signaled bandwidth is associated collectively with the whole LSP and therefore with the set of transported PSCs. Thus, LSRs which use the signaled bandwidth to perform admission control may perform admission control over global resources, which are shared by the set of PSCs (e.g., over the total bandwidth of the link).
当在建立E-LSP时用信号通知带宽需求时，用信号通知的带宽与整个LSP以及因此与所传送的psc的集合相关联。因此，使用信号带宽来执行许可控制的lsr可以对由psc组共享的全局资源（例如，在链路的总带宽上）执行许可控制。
Examples of scenarios where bandwidth reservation is not used and scenarios where bandwidth reservation is used are provided for information in APPENDIX B.
附录B中提供了未使用带宽预留和使用带宽预留的场景示例，以供参考。
Since different Ordered Aggregates of a given FEC may be transported over different LSPs, the label swapping decision of a Diff-Serv LSR clearly depends on the forwarded packet's Behavior Aggregate. Also, since the IP DS field of a forwarded packet may not be directly visible to an LSR, the way to determine the PHB to be applied to a received packet and to encode the PHB into a transmitted packet, is different than a non-MPLS Diff-Serv Router.
由于给定FEC的不同有序聚合可以通过不同的lsp传输，因此Diff-Serv LSR的标签交换决策显然取决于转发分组的行为聚合。此外，由于转发分组的IP-DS字段可能对LSR不直接可见，因此确定要应用于接收分组的PHB并将PHB编码为发送分组的方法不同于非MPLS区分服务路由器。
Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior, comprised of four stages:
因此，为了描述区分服务LSR的标签转发，我们对LSR区分服务标签切换行为进行了建模，包括四个阶段：
- Incoming PHB Determination (A)
- 进料PHB测定（A）
- Outgoing PHB Determination with Optional Traffic Conditioning(B)
- 具有可选流量调节（B）的输出PHB确定
- Label Forwarding (C)
- 标签转发（C）
- Encoding of Diff-Serv information into Encapsulation Layer (EXP, CLP, DE, User_Priority) (D)
- 将区分服务信息编码到封装层（EXP、CLP、DE、User_优先级）（D）
Each stage is described in more detail in the following sections.
以下各节将更详细地描述每个阶段。
Obviously, to enforce the Diff-Serv service differentiation the LSR MUST also apply the forwarding treatment corresponding to the Outgoing PHB.
显然，为了实施区分服务区分，LSR还必须应用对应于传出PHB的转发处理。
This model is illustrated below:
该模型如下图所示：
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+
\----Forwarding-->
Treatment
(PHB)
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+
\----Forwarding-->
Treatment
(PHB)
"Encaps" designates the Diff-Serv related information encoded in the MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE, 802.1 User_Priority)
“Encaps”指定编码在MPLS封装层中的区分服务相关信息（例如，EXP字段、ATM CLP、帧中继DE、802.1用户优先级）
(*) when the LSR behaves as an MPLS ingress node, the incoming packet may be received unlabelled.
（*）当LSR表现为MPLS入口节点时，可以未标记地接收传入分组。
(&) when the LSR behaves as an MPLS egress node, the outgoing packet may be transmitted unlabelled.
（&）当LSR表现为MPLS出口节点时，可以不标记地发送出站分组。
This model is presented here to describe the functional operations of Diff-Serv LSRs and does not constrain actual implementation.
该模型描述了区分服务LSR的功能操作，不限制实际实现。
This stage determines which Behavior Aggregate the received packet belongs to.
此阶段确定接收的数据包属于哪个行为聚合。
Sections 3.3 and 4.3 provide the details on how to perform incoming PHB Determination considering a given received label stack entry and/or received incoming MPLS encapsulation information depending on the incoming LSP type and depending on the incoming MPLS encapsulation.
第3.3节和第4.3节提供了有关如何根据给定的接收标签堆栈条目和/或接收的接收MPLS封装信息（取决于传入LSP类型和传入MPLS封装）执行传入PHB确定的详细信息。
Section 2.6 provides the details of which label stack entry to consider for the Incoming PHB Determination depending on the supported Diff-Serv tunneling mode.
第2.6节提供了根据所支持的Diff-Serv隧穿模式来考虑传入PHB确定的标签堆栈条目的细节。
Section 2.6 provides the details of when the IP Header is to be considered for incoming PHB determination, depending on the supported Diff-Serv tunneling model. In those cases where the IP header is to
第2.6节提供了根据支持的区分服务隧道模型，在确定传入PHB时考虑IP报头的详细信息。在这些情况下，IP报头将
be used, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and uses the DS field to determine the incoming PHB.
如果要使用，此阶段的操作与非MPLS IP Diff Serv路由器完全相同，并使用DS字段确定传入PHB。
The traffic conditioning stage is optional and may be used on an LSR to perform traffic conditioning including Behavior Aggregate demotion or promotion. It is outside the scope of this specification. For the purpose of specifying Diff-Serv over MPLS forwarding, we simply note that the PHB to be actually enforced and conveyed to downstream LSRs by an LSR (referred to as "outgoing PHB"), may be different to the PHB which had been associated with the packet by the previous LSR (referred to as "incoming PHB").
流量调节阶段是可选的，可在LSR上使用，以执行流量调节，包括行为聚合降级或升级。它不在本规范的范围内。为了在MPLS转发上指定Diff-Serv，我们简单地注意到，由LSR（称为“传出PHB”）实际实施并传送到下游LSR的PHB可能不同于由先前LSR（称为“传入PHB”）与分组相关联的PHB。
When the traffic conditioning stage is not present, the "outgoing PHB" is simply identical to the "incoming PHB".
当不存在流量调节阶段时，“输出PHB”与“输入PHB”完全相同。
[MPLS_ARCH] describes how label swapping is performed by LSRs on incoming labeled packets using an Incoming Label Map (ILM), where each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH] also describes how label imposition is performed by LSRs on incoming unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each incoming FEC is mapped to one or multiple NHLFEs.
[MPLS_ARCH]描述了LSR如何使用传入标签映射（ILM）对传入的标签数据包执行标签交换，其中每个传入标签映射到一个或多个NHLFE。[MPLS_ARCH]还描述了LSR如何使用FEC到NHLFE映射（FTN）对传入的未标记分组执行标签施加，其中每个传入FEC映射到一个或多个NHLFE。
A Diff-Serv Context for a label is comprised of:
标签的区分服务上下文包括：
- `LSP type (i.e., E-LSP or L-LSP)'
- `LSP类型（即e-LSP或L-LSP）'
- `supported PHBs'
- `支持的PHBs'
- `Encaps-->PHB mapping' for an incoming label
- `为传入标签封装-->PHB映射
- `Set of PHB-->Encaps mappings' for an outgoing label
- `传出标签的PHB-->封装映射集
The present specification defines that a Diff-Serv Context is stored in the ILM for each incoming label.
本规范定义了在ILM中为每个传入标签存储一个区分服务上下文。
[MPLS_ARCH] states that the `NHLFE may also contain any other information needed in order to properly dispose of the packet'. In accordance with this, the present specification defines that a Diff-Serv Context is stored in the NHLFE for each outgoing label that is swapped or pushed.
[MPLS_ARCH]指出，“NHLFE还可能包含正确处理该数据包所需的任何其他信息”。根据这一点，本规范定义在NHLFE中为交换或推送的每个传出标签存储区分服务上下文。
This Diff-Serv Context information is populated into the ILM and the FTN at label establishment time.
此区分服务上下文信息在标签建立时填充到ILM和FTN中。
If the label corresponds to an E-LSP for which no `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `supported PHBs' is populated with the set of PHBs of the preconfigured `EXP<-->PHB mapping', which is discussed below in section 3.2.1.
如果标签对应的E-LSP在LSP设置时未明确发出“EXP<-->PHB映射”信号，则“受支持的PHB”将填充预配置的“EXP<-->PHB映射”的PHB集，这将在下文第3.2.1节中讨论。
If the label corresponds to an E-LSP for which an `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `supported PHBs' is populated with the set of PHBs of the signaled `EXP<-->PHB mapping'.
如果标签对应于已在LSP设置中明确发出“EXP<-->PHB映射”信号的E-LSP，则“受支持的PHB”将用发出信号的“EXP<-->PHB映射”的PHB集填充。
If the label corresponds to an L-LSP, the `supported PHBs' is populated with the set of PHBs forming the PSC that is signaled at LSP set-up.
如果标签对应于L-LSP，“受支持的PHB”由形成PSC的PHB集填充，该PSC在LSP设置时发出信号。
The details of how the `Encaps-->PHB mapping' or `Set of PHB-->Encaps mappings' are populated are defined below in sections 3 and 4.
下文第3节和第4节详细介绍了如何填充“Encaps-->PHB映射”或“一组PHB-->Encaps映射”。
[MPLS_ARCH] also states that:
[MPLS_ARCH]还指出：
"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."
“如果ILM[分别，FTN]将特定标签映射到包含多个元素的一组NHLFE，则在转发数据包之前，必须选择该集合中的一个元素。从集合中选择元素的过程超出了本文档的范围。让ILM[分别，FTN]映射标签[分别，FEC]例如，如果希望在多个等成本路径上进行负载平衡，则对于包含多个NHLFE的集合可能很有用。”
In accordance with this, the present specification allows that an incoming label [respectively FEC] may be mapped, for Diff-Serv purposes, to multiple NHLFEs (for instance where different NHLFEs correspond to egress labels supporting different sets of PHBs). When a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST choose one of the NHLFEs whose Diff-Serv Context indicates that it supports the Outgoing PHB of the forwarded packet.
根据这一点，本说明书允许为了区分服务的目的，可以将传入标签[分别FEC]映射到多个nhlfe（例如，其中不同的nhlfe对应于支持不同phb组的出口标签）。当标签[分别为FEC]映射到多个NHLFE时，Diff-Serv LSR必须选择其Diff-Serv上下文指示其支持转发数据包的传出PHB的NHLFE之一。
When a label [respectively FEC] maps to multiple NHLFEs which support the Outgoing PHB, the procedure for choosing one among those is outside the scope of this document. This situation may be encountered where it is desired to do load balancing of a Behavior Aggregate over multiple LSPs. In such situations, in order to respect ordering constraints, all packets of a given microflow MUST be transported over the same LSP.
当标签[分别为FEC]映射到支持传出PHB的多个NHLFE时，从这些标签中选择一个的程序不在本文件的范围内。当需要在多个LSP上对行为聚合进行负载平衡时，可能会遇到这种情况。在这种情况下，为了遵守排序约束，给定微流的所有数据包必须通过同一LSP传输。
This stage determines how to encode the fields which convey Diff-Serv information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).
此阶段确定如何对传输分组中传输区分服务信息的字段进行编码（例如，MPLS Shim-EXP、ATM CLP、帧中继DE、802.1用户优先级）。
Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv information encoding into a given transmitted label stack entry and/or transmitted MPLS encapsulation information depending on the corresponding outgoing LSP type and depending on the MPLS encapsulation.
第3.5节和第4.5节详细介绍了如何根据相应的传出LSP类型和MPLS封装，将区分服务信息编码到给定的传输标签堆栈条目和/或传输的MPLS封装信息中。
Section 2.6 provides the details in which label stack entry to perform Diff-Serv information encoding into depending on the supported Diff-Serv tunneling mode.
第2.6节提供了根据支持的区分服务隧道模式执行区分服务信息编码的标签堆栈条目的详细信息。
To perform Diff-Serv Information Encoding into the transmitted packet IP header, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and encodes the DSCP of the Outgoing PHB into the DS field.
为了将区分服务信息编码到传输的分组IP报头中，此阶段的操作与非MPLS IP区分服务路由器完全相同，并将传出PHB的DSCP编码到DS字段中。
Section 2.6 provides the details of when Diff-Serv Information Encoding is to be performed into transmitted IP header depending on the supported Diff-Serv tunneling mode.
第2.6节提供了根据支持的区分服务隧道模式，何时将区分服务信息编码到传输的IP报头中的详细信息。
[DIFF_TUNNEL] considers the interaction of Differentiated Services with IP tunnels of various forms. MPLS LSPs are not a form of "IP tunnels" since the MPLS encapsulating header does not contain an IP header and thus MPLS LSPs are not considered in [DIFF_TUNNEL]. However, although not a form of "IP tunnel", MPLS LSPs are a form of "tunnel".
[DIFF_TUNNEL]考虑区分服务与各种形式的IP隧道的交互。MPLS LSP不是“IP隧道”的一种形式，因为MPLS封装报头不包含IP报头，因此在[DIFF_TUNNEL]中不考虑MPLS LSP。然而，尽管不是“IP隧道”的一种形式，但MPLS LSP是“隧道”的一种形式。
From the Diff-Serv standpoint, LSPs share a number of common characteristics with IP Tunnels:
从区分服务的角度来看，LSP与IP隧道有许多共同特征：
- Intermediate nodes (i.e., Nodes somewhere along the LSP span) only see and operate on the "outer" Diff-Serv information.
- 中间节点（即沿着LSP范围的某个位置的节点）仅查看“外部”区分服务信息并对其进行操作。
- LSPs are unidirectional.
- LSP是单向的。
- The "outer" Diff-Serv information can be modified at any of the intermediate nodes.
- 可以在任何中间节点修改“外部”区分服务信息。
However, from the Diff-Serv standpoint, LSPs also have a distinctive property compared to IP Tunnels:
然而，从区分服务的角度来看，LSP与IP隧道相比也有一个独特的特性：
- There is generally no behavior analogous to Penultimate Hop Popping (PHP) used with IP Tunnels. Furthermore, PHP results in the "outer" Diff-Serv information associated with the LSP not being visible to the LSP egress. In situations where this information is not meaningful at the LSP Egress, this is obviously not an issue at all. In situations where this information is meaningful at the LSP Egress, then it must somehow be carried in some other means.
- 通常没有类似于IP隧道使用的倒数第二跳弹出（PHP）的行为。此外，PHP导致与LSP相关联的“外部”区分服务信息对LSP出口不可见。在LSP出口处该信息没有意义的情况下，这显然根本不是问题。在该信息在LSP出口处有意义的情况下，则必须以某种方式以其他方式携带该信息。
The two conceptual models for Diff-Serv tunneling over IP Tunnels defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over MPLS but their respective detailed operations is somewhat different over MPLS. These two models are the Pipe Model and the Uniform Model. Their operations over MPLS are specified in the following sections. Discussion and definition of alternative tunneling models are outside the scope of this specification.
[Diff_TUNNEL]中定义的IP隧道上的区分服务的两个概念模型对于MPLS上的区分服务是适用和有用的，但它们各自的详细操作在MPLS上有所不同。这两种模型是管道模型和均匀模型。它们在MPLS上的操作将在以下部分中指定。替代隧道模型的讨论和定义不在本规范范围内。
With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the intermediate MPLS nodes between LSP Ingress and Egress from the Diff-Serv perspective.
在管道模型中，MPLS隧道（也称为LSP）用于从区分服务的角度隐藏LSP入口和出口之间的中间MPLS节点。
In this model, tunneled packets must convey two meaningful pieces of Diff-Serv information:
在此模型中，隧道数据包必须传递两条有意义的区分服务信息：
- the Diff-Serv information which is meaningful to intermediate nodes along the LSP span including the LSP Egress (which we refer to as the "LSP Diff-Serv Information"). This LSP Diff-Serv Information is not meaningful beyond the LSP Egress: Whether Traffic Conditioning at intermediate nodes on the LSP span affects the LSP Diff-Serv information or not, this updated Diff-Serv information is not considered meaningful beyond the LSP Egress and is ignored.
- Diff-Serv信息对LSP跨度上的中间节点有意义，包括LSP出口（我们称之为“LSP Diff-Serv信息”）。此LSP区分服务信息在LSP出口之外没有意义：无论LSP范围上中间节点处的流量调节是否影响LSP区分服务信息，此更新的区分服务信息在LSP出口之外没有意义，将被忽略。
- the Diff-Serv information which is meaningful beyond the LSP Egress (which we refer to as the "Tunneled Diff-Serv Information"). This information is to be conveyed by the LSP Ingress to the LSP Egress. This Diff-Serv information is not meaningful to the intermediate nodes on the LSP span.
- 除了LSP出口之外有意义的Diff-Serv信息（我们称之为“隧道Diff-Serv信息”）。该信息将由LSP入口传送到LSP出口。此区分服务信息对LSP范围上的中间节点没有意义。
Operation of the Pipe Model without PHP is illustrated below:
不使用PHP的管道模型的操作如下所示：
========== LSP =============================>
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The LSP Egress considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node E represents the LSP egress node
（M） 表示“LSP区分服务信息”（M）表示“隧道区分服务信息”（*），LSP出口考虑在外部报头（即，在pop之前）中接收的LSP区分服务信息，以便应用其区分服务转发处理（即，实际PHB），i表示LSP入口节点e表示LSP出口节点
With the Pipe Model, the "LSP Diff-Serv Information" needs to be conveyed to the LSP Egress so that it applies its forwarding treatment based on it. The "Tunneled Diff-Serv information" also needs to be conveyed to the LSP Egress so it can be conveyed further downstream.
在管道模型中，需要将“LSP Diff-Serv信息”传输到LSP出口，以便它基于该信息应用其转发处理。“隧道式区分服务信息”也需要传送到LSP出口，以便可以进一步向下游传送。
Since both require that Diff-Serv information be conveyed to the LSP Egress, the Pipe Model operates only without PHP.
由于两者都需要将Diff-Serv信息传输到LSP出口，因此管道模型仅在没有PHP的情况下运行。
The Pipe Model is particularly appropriate for environments in which:
管道模型特别适用于以下环境：
- the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
- LSP入口的传入接口的云上游和LSP出口的传出接口的云下游位于使用一组通用的区分服务提供策略和PHB定义的区分服务域中，而LSP跨越一个（或多个）使用一组不同的Diff Serv服务提供策略和PHB定义
- the outgoing interface of the LSP Egress is in the (last) Diff-Serv domain spanned by the LSP.
- LSP出口的传出接口位于LSP跨越的（最后一个）Diff Serv域中。
As an example, consider the case where a service provider is offering an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN architecture) including Diff-Serv differentiation. Say that a collection of sites is interconnected via such an MPLS VPN service. Now say that this collection of sites is managed under a common administration and is also supporting Diff-Serv service differentiation. If the VPN site administration and the Service
作为一个例子，考虑服务提供商正在提供MPLS VPN服务的情况（参见MPLSVPN），其中包括MPLS VPN体系结构，包括DiffServ区分。假设一组站点通过这样的MPLS VPN服务互连。现在，假设这个站点集合是在一个公共管理下管理的，并且还支持区分服务差异化。如果VPN站点管理和服务
Provider are not sharing the exact same Diff-Serv policy (for instance not supporting the same number of PHBs), then operation of Diff-Serv in the Pipe Model over the MPLS VPN service would allow the VPN Sites Diff-Serv policy to operate consistently throughout the ingress VPN Site and Egress VPN Site and transparently over the Service Provider Diff-Serv domain. It may be useful to view such LSPs as linking the Diff-Serv domains at their endpoints into a single Diff-Serv region by making these endpoints virtually contiguous even though they may be physically separated by intermediate network nodes.
提供商没有共享完全相同的区分服务策略（例如，不支持相同数量的PHB），然后，通过MPLS VPN服务在管道模型中操作Diff-Serv将允许VPN站点Diff-Serv策略在整个入口VPN站点和出口VPN站点上一致地运行，并在服务提供商Diff-Serv域上透明地运行。将此类lsp视为将其端点处的区分服务域链接到单个区分服务区域是有用的，方法是使这些端点实际上相邻，即使它们可能被中间网络节点物理上分开。
The Pipe Model MUST be supported.
必须支持管道模型。
For support of the Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the following manner:
为了在没有PHP的情况下支持给定LSP上的管道模型，LSR以以下方式执行传入PHB确定和区分服务信息编码：
- when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
- 当接收到未标记的分组时，LSR考虑接收到的IP报头执行传入PHB确定。
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
- 当接收到带标签的数据包时，LSR根据接收到的标签堆栈中的外部标签条目执行传入PHB确定。具体地，当要对所考虑的LSP执行pop操作时，LSR在pop之前执行传入PHB确定。
- when performing a push operation for the considered LSP, the LSR:
- 当对所考虑的LSP执行推送操作时，LSR：
o encodes Diff-Serv Information corresponding to the OUTGOING PHB in the transmitted label entry corresponding to the pushed label.
o 在与推送标签对应的传输标签条目中，编码与传出PHB对应的区分服务信息。
o encodes Diff-Serv Information corresponding to the INCOMING PHB in the encapsulated header (swapped label entry or IP header).
o 编码与封装报头（交换标签条目或IP报头）中的传入PHB相对应的区分服务信息。
- when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label
- 当对所考虑的LSP执行仅交换操作时，LSR在包含交换标签的传输标签条目中编码区分服务信息
- when performing a pop operation for the considered LSP, the LSR does not perform Encoding of Diff-Serv Information into the header exposed by the pop operation (i.e., the LSR leaves the exposed header "as is").
- 当对所考虑的LSP执行pop操作时，LSR不将区分服务信息编码到pop操作公开的报头中（即，LSR将公开的报头保持“原样”）。
The Short Pipe Model is an optional variation of the Pipe Model described above. The only difference is that, with the Short Pipe
短管模型是上述管道模型的可选变体。唯一的区别是，用短管
Model, the Diff-Serv forwarding treatment at the LSP Egress is applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-Serv information conveyed in the encapsulated header) rather than on the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed in the encapsulating header).
在该模型中，LSP出口处的区分服务转发处理基于“隧道式区分服务信息”（即，在封装报头中传输的区分服务信息）而不是“LSP区分服务信息”（即，在封装报头中传输的区分服务信息）。
Operation of the Short Pipe Model without PHP is illustrated below:
没有PHP的短管模型的操作如下所示：
========== LSP =============================>
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" I represents the LSP ingress node E represents the LSP egress node
（M） 表示“LSP区分服务信息”（M）表示“隧道区分服务信息”，I表示LSP入口节点E表示LSP出口节点
Since the LSP Egress applies its forwarding treatment based on the "Tunneled Diff-Serv Information", the "LSP Diff-Serv information" does not need to be conveyed by the penultimate node to the LSP Egress. Thus the Short Pipe Model can also operate with PHP.
由于LSP出口基于“隧道区分服务信息”应用其转发处理，“LSP区分服务信息”不需要由倒数第二个节点传送到LSP出口。因此，短管模型也可以使用PHP进行操作。
Operation of the Short Pipe Model with PHP is illustrated below:
使用PHP的短管模型的操作如下所示：
=========== LSP ============================>
=========== LSP ============================>
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The Penultimate LSR considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
（M） 表示“LSP区分服务信息”（M）表示“隧道区分服务信息”（*）。倒数第二个LSR考虑在外部报头（即，在pop之前）中接收的LSP区分服务信息，以便应用其区分服务转发处理（即，实际PHB）I表示LSP入口节点P表示LSP倒数第二个节点E表示LSP出口节点
The Short Pipe Model is particularly appropriate for environments in which:
短管模型特别适用于以下环境：
- the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
- LSP入口的传入接口的云上游和LSP出口的传出接口的云下游位于使用一组通用的区分服务提供策略和PHB定义的区分服务域中，而LSP跨越一个（或多个）使用一组不同的Diff Serv服务提供策略和PHB定义
- the outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it.
- LSP出口的传出接口与其下游的云位于同一个Diff-Serv域中。
Since each outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it, each outgoing interface may potentially be in a different Diff-Serv domain, and the LSP Egress needs to be configured with awareness of every corresponding Diff-Serv policy. This operational overhead is justified in some situations where the respective downstream Diff-Serv policies are better suited to offering service differentiation over each egress interface than the common Diff-Serv policy used on the LSP span. An example of such a situation is where a Service Provider offers an MPLS VPN service and where some VPN users request that their own VPN Diff-Serv policy be applied to control service differentiation on the dedicated link from the LSP Egress to the destination VPN site, rather than the Service Provider's Diff-Serv policy.
由于LSP出口的每个传出接口与其下游的云位于同一个区分服务域中，因此每个传出接口可能位于不同的区分服务域中，并且LSP出口需要配置为了解每个对应的区分服务策略。在某些情况下，这种操作开销是合理的，与LSP范围上使用的公共区分服务策略相比，相应的下游区分服务策略更适合在每个出口接口上提供服务差异。这种情况的一个示例是，服务提供商提供MPLS VPN服务，并且一些VPN用户请求应用他们自己的VPN区分服务策略来控制从LSP出口到目的VPN站点的专用链路上的服务差异，而不是服务提供商的区分服务策略。
The Short Pipe Model MAY be supported.
可以支持短管模型。
For support of the Short Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the same manner as with the Pipe Model with the following exception:
为了在没有PHP的情况下支持给定LSP上的短管模型，LSR以与管道模型相同的方式执行传入PHB确定和区分服务信息编码，但以下情况除外：
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the header (label entry or IP header) which is used to do the actual forwarding. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination AFTER the pop.
- 当接收到带标签的数据包时，LSR根据用于执行实际转发的报头（标签条目或IP报头）执行传入PHB确定。具体地，当要对所考虑的LSP执行pop操作时，LSR在pop之后执行传入PHB确定。
For support of the Short Pipe Model over a given LSP with PHP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the same manner as without PHP with the following exceptions:
为了支持使用PHP的给定LSP上的短管模型，LSR以与不使用PHP相同的方式执行传入PHB确定和区分服务信息编码，但以下情况除外：
- the Penultimate LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In other words, when a pop operation is to be performed for the considered LSP, the Penultimate LSR performs Incoming PHB Determination BEFORE the pop.
- 倒数第二个LSR根据接收到的标签堆栈中的外部标签条目执行传入PHB确定。换句话说，当要对所考虑的LSP执行pop操作时，倒数第二LSR在pop之前执行传入PHB确定。
Note that the behavior of the Penultimate LSR in the Short Pipe Mode with PHP, is identical to the behavior of the LSP Egress in the Pipe Mode (necessarily without PHP).
请注意，在使用PHP的短管模式中倒数第二个LSR的行为与管道模式中LSP出口的行为相同（必须不使用PHP）。
With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS Tunnels may be used for forwarding purposes but have no significant impact on Diff-Serv. In this model, any packet contains exactly one piece of Diff-Serv information which is meaningful and is always encoded in the outer most label entry (or in the IP DSCP where the IP packet is transmitted unlabelled for instance at the egress of the LSP). Any Diff-Serv information encoded somewhere else (e.g., in deeper label entries) is of no significance to intermediate nodes or to the tunnel egress and is ignored. If Traffic Conditioning at intermediate nodes on the LSP span affects the "outer" Diff-Serv information, the updated Diff-Serv information is the one considered meaningful at the egress of the LSP.
在统一模型中，MPLS隧道（也称为LSP）从区分服务的角度被视为端到端路径的工件。MPLS隧道可用于转发目的，但对区分服务没有显著影响。在该模型中，任何数据包都只包含一条有意义的区分服务信息，并且总是编码在最外层的标签条目中（或者在IP DSCP中，其中IP数据包在LSP出口处以未标记的方式传输）。在其他地方（例如，在更深的标签条目中）编码的任何Diff-Serv信息对于中间节点或隧道出口都没有意义，并且被忽略。如果LSP跨度上中间节点处的流量调节影响“外部”区分服务信息，则更新的区分服务信息被认为是LSP出口处有意义的信息。
Operation of the Uniform Model without PHP is illustrated below:
不使用PHP的统一模型的操作如下所示：
========== LSP =============================>
========== LSP =============================>
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E
(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node E represents the LSP egress node
（M） 表示编码在相应标头中的有意义的区分服务信息。（x） 表示无意义的区分服务信息。I表示LSP入口节点E表示LSP出口节点
Operation of the Uniform Model with PHP is illustrated below:
统一模型与PHP的操作如下所示：
========== LSP =========================>
========== LSP =========================>
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P
(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
（M） 表示编码在相应标头中的有意义的区分服务信息。（x） 表示无意义的区分服务信息。I表示LSP入口节点P表示LSP倒数第二个节点E表示LSP出口节点
The Uniform Model for Diff-Serv over MPLS is such that, from the Diff-Serv perspective, operations are exactly identical to the operations if MPLS was not used. In other words, MPLS is entirely transparent to the Diff-Serv operations.
MPLS上的区分服务的统一模型是这样的，从区分服务的角度来看，操作与不使用MPLS时的操作完全相同。换句话说，MPLS对Diff-Serv操作是完全透明的。
Use of the Uniform Model allows LSPs to span Diff-Serv domain boundaries without any other measure in place than an inter-domain Traffic Conditioning Agreement at the physical boundary between the Diff-Serv domains and operating exclusively on the "outer" header, since the meaningful Diff-Serv information is always visible and modifiable in the outmost label entry.
使用统一模型允许LSP跨越区分服务域边界，而无需采取任何其他措施，除了在区分服务域之间的物理边界处的域间流量调节协议，并且仅在“外部”报头上操作，因为有意义的区分服务信息在最外面的标签条目中总是可见和可修改的。
The Uniform Model MAY be supported.
可以支持统一模型。
For support of the Uniform Model over a given LSP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the following manner:
为了支持给定LSP上的统一模型，LSR以以下方式执行传入PHB确定和区分服务信息编码：
- when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
- 当接收到未标记的分组时，LSR考虑接收到的IP报头执行传入PHB确定。
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
- 当接收到带标签的数据包时，LSR根据接收到的标签堆栈中的外部标签条目执行传入PHB确定。具体地，当要对所考虑的LSP执行pop操作时，LSR在pop之前执行传入PHB确定。
- when performing a push operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry corresponding to the pushed label. The Diff-Serv Information encoded in the encapsulated header (swapped label entry or IP Header) is of no importance.
- 当对所考虑的LSP执行推送操作时，LSR在与推送标签相对应的发送标签条目中编码区分服务信息。封装的报头（交换标签条目或IP报头）中编码的区分服务信息并不重要。
- when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label.
- 当对所考虑的LSP执行仅交换操作时，LSR在包含交换标签的传输标签条目中编码区分服务信息。
- when PHP is used, the Penultimate LSR needs to be aware of the "Set of PHB-->Encaps mappings" for the label corresponding to the exposed header (or the `PHB-->DSCP mapping') in order to perform Diff-Serv Information Encoding. Methods for providing this mapping awareness are outside the scope of this specification. As an example, the "PHB-->DSCP mapping" may be locally configured. As another example, in some environments, it may be appropriate for the Penultimate LSR to assume that the "Set of PHB-->Encaps mappings" to be used for the outgoing label in the exposed header is the "Set of PHB-->Encaps mappings" that would be used by the LSR if the LSR was not doing PHP. Note also that this specification assumes that the Penultimate LSR does not perform label swapping over the label entry exposed by the pop operation (and in fact that it does not even look at the exposed label). Consequently, restrictions may apply to the Diff-Serv Information Encoding that can be performed by the Penultimate LSR. For example, this specification does not allow situations where the Penultimate LSR pops a label corresponding to an E-LSP supporting two PSCs, while the header exposed by the pop contains label values for two L-LSPs each supporting one PSC, since the Diff-Serv Information Encoding would require selecting one label or the other.
- 使用PHP时，倒数第二个LSR需要知道与公开标头（或“PHB-->DSCP映射”）对应的标签的“PHB-->封装映射集”，以便执行区分服务信息编码。提供这种映射意识的方法不在本规范的范围内。例如，“PHB-->DSCP映射”可以在本地配置。作为另一个示例，在某些环境中，倒数第二个LSR可能适合假设公开标头中用于传出标签的“PHB-->封装映射集”是LSR在LSR不执行PHP时将使用的“PHB-->封装映射集”。还要注意，本规范假定倒数第二个LSR不在pop操作公开的标签条目上执行标签交换（事实上，它甚至不查看公开的标签）。因此，限制可应用于可由倒数第二LSR执行的区分服务信息编码。例如，本规范不允许倒数第二个LSR弹出与支持两个PSC的E-LSP对应的标签，而由pop公开的报头包含两个L-LSP的标签值，每个L-LSP支持一个PSC，因为区分服务信息编码将需要选择一个或另一个标签。
Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform Model only differ when doing a push or a pop. Thus, Intermediate LSRs which perform swap only operations for an LSP, behave in exactly the same way, regardless of whether they are behaving in the Pipe, Short Pipe or the Uniform model. With a Diff-Serv implementation supporting multiple Tunneling Models, only LSRs behaving as LSP Ingress, Penultimate LSR or LSP Egress need to be configured to operate in a particular Model. Signaling to associate a Diff-Serv tunneling model on a per-LSP basis is not within the scope of this specification.
请注意，管道、短管和统一模型的LSR行为仅在执行推送或弹出时不同。因此，对LSP执行仅交换操作的中间LSR的行为方式完全相同，无论它们是在管道、短管还是统一模型中。由于Diff-Serv实现支持多个隧道模型，只有表现为LSP入口、倒数第二个LSR或LSP出口的LSR需要配置为在特定模型中运行。基于每LSP关联区分服务隧道模型的信令不在本规范的范围内。
Through the label stack mechanism, MPLS allows LSP tunneling to nest to any depth. We observe that with such nesting, the push of level N+1 takes place on a subsequent (or the same) LSR to the LSR doing the push for level N, while the pop of level N+1 takes place on a previous (or the same) LSR to the LSR doing the pop of level N. For a given level N LSP, the Ingress LSR doing the push and the LSR doing the pop (Penultimate LSR or LSP Egress) must operate in the same Tunneling Model (i.e., Pipe, Short Pipe or Uniform). However, there is no requirement for consistent tunneling models across levels so that LSPs at different levels may be operating in different Tunneling Models.
通过标签堆栈机制，MPLS允许LSP隧道嵌套到任何深度。我们观察到，通过这种嵌套，级别N+1的推送发生在对级别N进行推送的LSR的后续（或相同）LSR上，而级别N+1的pop发生在对级别N进行pop的LSR的先前（或相同）LSR上。对于给定的级别N LSP，入口LSR进行推送，LSR进行pop（倒数第二个LSR或LSP出口）必须在相同的隧道模型（即管道、短管或均匀）下运行。但是，不要求在不同水平上采用一致的隧道模型，以便不同水平的LSP可以在不同的隧道模型中运行。
Hierarchical operations are illustrated below in the case of two levels of tunnels:
在两层隧道的情况下，分层操作如下所示：
+--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)Pop
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header)
+--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)Pop
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header)
(1) Tunneling Model 1 (2) Tunneling Model 2
(1) 隧道模型1（2）隧道模型2
Tunneling Model 2 may be the same as or may be different from Tunneling Model 1.
隧道模型2可能与隧道模型1相同或不同。
For a given LSP of level N, the LSR must perform the Incoming PHB Determination and the Diff-Serv information Encoding as specified in section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of this level N LSP and independently of the Tunneling Model of other level LSPs.
对于给定的N级LSP，LSR必须按照第2.6.2、2.6.2.1和2.6.3节的规定，根据该N级LSP的隧道模型并独立于其他级别LSP的隧道模型，执行传入PHB确定和区分服务信息编码。
E-LSPs are defined in section 1.2.
第1.2节定义了E-LSP。
Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the pre-configured mapping are capable of transporting the same common set of 8, or fewer, BAs. Each of those E-LSPs may actually transport this full set of BAs or any arbitrary subset of it.
在给定的MPLS区分服务域中，所有依赖于预配置映射的E-lsp都能够传输相同的公共集，即8个或更少的BAs。这些E-LSP中的每一个都可能实际传输这一整套BAs或其任意子集。
For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates.
对于给定的FEC，两个使用信号“EXP<-->PHB映射”的给定E-LSP可以支持相同或不同的有序聚合集。
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated for an incoming E-LSP in order to allow Incoming PHB determination.
本节定义如何为传入的E-LSP填充Diff-Serv上下文的“Encaps-->PHB映射”，以允许传入的PHB确定。
The `Encaps-->PHB mapping' for an E-LSP is always of the form `EXP-->PHB mapping'.
E-LSP的“封装-->PHB映射”始终采用“EXP-->PHB映射”的形式。
If the label corresponds to an E-LSP for which no `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' is populated based on the Preconfigured `EXP<-->PHB mapping' which is discussed below in section 3.2.1.
如果标签对应的E-LSP在LSP设置时未明确发出“EXP<-->PHB映射”信号，则“EXP-->PHB映射”将基于预配置的“EXP<-->PHB映射”进行填充，这将在下文第3.2.1节中讨论。
If the label corresponds to an E-LSP for which an `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' is populated as per the signaled `EXP<-->PHB mapping'.
如果标签对应于已在LSP设置中明确发出“EXP<-->PHB映射”信号的E-LSP，则“EXP-->PHB映射”将按照发出信号的“EXP<-->PHB映射”进行填充。
LSRs supporting E-LSPs which use the preconfigured `EXP<-->PHB mapping' must allow local configuration of this `EXP<-->PHB mapping'. This mapping applies to all the E-LSPs established on this LSR without a mapping explicitly signaled at set-up time.
支持使用预配置“EXP<-->PHB映射”的E-LSP的LSR必须允许本地配置此“EXP<-->PHB映射”。此映射适用于在此LSR上建立的所有E-LSP，而无需在设置时显式发出映射信号。
The preconfigured `EXP<-->PHB mapping' must either be consistent at every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the LSP or appropriate remarking of the EXP field must be performed by the LSR whenever a different preconfigured mapping is used on the ingress and egress interfaces.
预配置的“EXP<-->PHB映射”必须在LSP跨越的MPLS Diff Serv域中的每个E-LSP跃点上保持一致，或者在入口和出口接口上使用不同的预配置映射时，LSR必须对EXP字段进行适当的重新标记。
In case, the preconfigured `EXP<-->PHB mapping' has not actually been configured by the Network Administrator, the LSR should use a default preconfigured `EXP<-->PHB mapping' which maps all EXP values to the Default PHB.
如果网络管理员未实际配置预配置的“EXP<-->PHB映射”，则LSR应使用默认预配置的“EXP<-->PHB映射”，将所有EXP值映射到默认PHB。
This section defines how Incoming PHB Determination is carried out when the considered label entry in the received label stack corresponds to an E-LSP. This requires that the `Encaps-->PHB mapping' is populated as defined in section 3.2.
本节定义了当接收到的标签堆栈中所考虑的标签条目对应于E-LSP时，如何执行传入PHB确定。这要求按照第3.2节中的定义填充“Encaps-->PHB映射”。
When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the LSR:
当考虑与传入E-LSP对应的标签条目以确定传入PHB时，LSR：
- determines the `EXP-->PHB mapping' by looking up the `Encaps-->PHB mapping' of the Diff-Serv Context associated in the ILM with the considered incoming E-LSP label.
- 通过查找ILM中与所考虑的传入E-LSP标签关联的Diff-Serv上下文的“Encaps-->PHB映射”，确定“EXP-->PHB映射”。
- determines the incoming PHB by looking up the EXP field of the considered label entry in the `EXP-->PHB mapping' table.
- 通过在“EXP-->PHB映射”表中查找所考虑标签项的EXP字段来确定传入PHB。
This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv Context is populated at label setup for an outgoing E-LSP in order to allow Encoding of Diff-Serv information in the Encapsulation Layer.
本节定义如何在传出E-LSP的标签设置中填充区分服务上下文的“PHB-->封装映射集”，以便在封装层中编码区分服务信息。
An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of the `Set of PHB-->Encaps mappings' of its Diff-Serv Context.
传出的E-LSP必须始终具有“PHB-->EXP映射”，作为其区分服务上下文的“PHB-->封装映射集”的一部分。
If the label corresponds to an E-LSP for which no `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, this `PHB-->EXP mapping' is populated based on the Preconfigured `EXP<-->PHB mapping' which is discussed above in section 3.2.1.
如果标签对应的E-LSP在LSP设置时未明确发出“EXP<-->PHB映射”信号，则此“PHB-->EXP映射”将根据上文第3.2.1节中讨论的预配置“EXP<-->PHB映射”进行填充。
If the label corresponds to an E-LSP for which an `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `PHB-->EXP mapping' is populated as per the signaled `EXP<-->PHB mapping'.
如果标签对应于已在LSP设置中明确发出“EXP<-->PHB映射”信号的E-LSP，“PHB-->EXP映射”将按照发出信号的“EXP<-->PHB映射”进行填充。
If the LSP is egressing over an ATM interface which is not label switching controlled, then one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->CLP mapping' is populated in the following way:
如果LSP通过不受标签交换控制的ATM接口出口，则会将一个“PHB-->CLP映射”添加到此输出LSP的“PHB-->封装映射集”。此“PHB-->CLP映射”以以下方式填充：
- it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default `PHB-->CLP mapping' defined in section 3.4.2.1. Mappings other than the one defined in section 3.4.2.1 may be used. In particular, if a mapping from PHBs to CLP is standardized in the future for operations of Diff-Serv over ATM, such a standardized mapping may then be used.
- 它是此LSP支持的PHB的一个功能，可以使用第3.4.2.1节中定义的默认“PHB-->CLP映射”中的这些PHB的相关映射条目。可以使用第3.4.2.1节中定义的映射以外的映射。特别地，如果将来为了通过ATM的Diff-Serv的操作而对从phb到CLP的映射进行标准化，则可以使用这样的标准化映射。
For example if the outgoing label corresponds to an LSP supporting the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:
例如，如果传出标签对应于支持AF1 PSC的LSP，则“PHB-->CLP映射”可以填充以下内容：
PHB CLP Field
PHB CLP字段
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
EF ----> 0
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
EF ----> 0
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.
请注意，在本例中，“PHB-->封装映射集”包含“PHB-->EXP映射”和“PHB-->CLP映射”。
PHB CLP Bit
PHB CLP位
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
If the LSP is egressing over a Frame Relay interface which is not label switching controlled, one `PHB-->DE mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP and is populated in the following way:
如果LSP通过不受标签切换控制的帧中继接口退出，则会将一个“PHB-->解映射”添加到此传出LSP的“PHB-->封装映射集”，并按以下方式填充：
- it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default `PHB-->DE mapping' defined in section 3.4.3.1. Mappings other than the one defined in section 3.4.3.1 may be used. In particular, if a mapping from PHBs to DE is standardized in the future for operations of Diff-Serv over Frame Relay, such a standardized mapping may then be used.
- 它是此LSP支持的PHB的一个功能，可以使用第3.4.3.1节中定义的默认“PHB-->解映射”中的这些PHB的相关映射条目。可以使用第3.4.3.1节中定义的映射以外的映射。特别地，如果将来为了帧中继上的区分服务的操作而标准化从PHBs到DE的映射，则可以使用这样的标准化映射。
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
请注意，在本例中，“PHB-->封装映射集”包含“PHB-->EXP映射”和“PHB-->反映射”。
PHB DE Bit
位元
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
If the LSP is egressing over a LAN interface on which multiple 802.1 Traffic Classes are supported as per [IEEE_802.1], then one `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->802.1 mapping' is populated in the following way:
如果LSP通过LAN接口出口，根据[IEEE_802.1]，在LAN接口上支持多个802.1通信量类别，则会将一个“PHB-->802.1映射”添加到此输出LSP的“PHB-->封装映射集”。此“PHB-->802.1映射”以以下方式填充：
- it is a function of the PHBs supported on this LSP, and uses the relevant mapping entries for these PHBs from the Preconfigured `PHB-->802.1 mapping' defined in section 3.4.4.1.
- 它是此LSP支持的PHB的一个功能，并使用第3.4.4.1节中定义的预配置“PHB-->802.1映射”中这些PHB的相关映射条目。
Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
请注意，“PHB-->封装映射集”随后同时包含“PHB-->EXP映射”和“PHB-->802.1映射”。
At the time of producing this specification, there are no standardized mapping from PHBs to 802.1 Traffic Classes. Consequently, an LSR supporting multiple 802.1 Traffic Classes over LAN interfaces must allow local configuration of a `PHB-->802.1 mapping'. This mapping applies to all the outgoing LSPs established by the LSR on such LAN interfaces.
在制定本规范时，没有从PHB到802.1流量类别的标准化映射。因此，通过LAN接口支持多个802.1通信类的LSR必须允许本地配置“PHB-->802.1映射”。此映射适用于LSR在此类LAN接口上建立的所有传出LSP。
3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP
3.5 将区分服务信息编码到传出E-LSP的封装层
This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a given transmitted label entry corresponding to an outgoing E-LSP. This requires that the `Set of PHB-->Encaps mappings' be populated as defined in section 3.4.
本节定义了如何将Diff-Serv信息编码到MPLS封装层中，用于对应于传出E-LSP的给定传输标签条目。这要求按照第3.4节中的定义填充“PHB-->封装映射集”。
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE.
LSR首先确定与NHLFE中相应标签关联的区分服务上下文的“PHB-->封装映射集”。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->EXP mapping', then the LSR:
如果“PHB-->封装映射集”包含形式为“PHB-->EXP映射”的映射，则LSR：
- determines the value to be written in the EXP field of the corresponding level label entry by looking up the "outgoing PHB" in this `PHB-->EXP mapping' table.
- 通过在此“PHB-->EXP映射”表中查找“传出PHB”，确定要写入相应级别标签项的EXP字段的值。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->CLP mapping', then the LSR:
如果“PHB-->封装映射集”包含形式为“PHB-->CLP映射”的映射，则LSR：
- determines the value to be written in the CLP field of the ATM encapsulation header, by looking up the "outgoing PHB" in this `PHB-->CLP mapping' table.
- 通过在此“PHB-->CLP映射”表中查找“传出PHB”，确定要写入ATM封装标头CLP字段的值。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->DE mapping', then the LSR:
如果“PHB-->封装映射集”包含形式为“PHB-->解映射”的映射，则LSR：
- determines the value to be written in the DE field of the Frame Relay encapsulation header, by looking up the "outgoing PHB" in this `PHB-->DE mapping' table.
- 通过在此“PHB-->解映射”表中查找“传出PHB”，确定要写入帧中继封装头的DE字段的值。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->802.1 mapping', then the LSR:
如果“PHB-->封装映射集”包含形式为“PHB-->802.1映射”的映射，则LSR：
- determines the value to be written in the User_Priority field of the Tag Control Information of the 802.1 encapsulation header [IEEE_802.1], by looking up the "outgoing PHB" in this 'PHB-- >802.1 mapping' table.
- 通过查找此“PHB-->802.1映射”表中的“传出PHB”，确定要写入802.1封装头[IEEE_802.1]的标记控制信息的用户_优先级字段中的值。
In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. E-LSPs are compatible with LSP Merging under the following condition:
在MPLS域中，可以在一个LSR上将两个或多个LSP合并为一个LSP。在以下条件下，E-LSP与LSP合并兼容：
E-LSPs can only be merged into one LSP if they support the exact same set of BAs.
如果E-LSP支持完全相同的BAs集，则它们只能合并为一个LSP。
For E-LSPs using a signaled `EXP<-->PHB mapping', the above merge condition MUST be enforced by LSRs through explicit checking at label setup that the exact same set of PHBs is supported on the merged LSPs.
对于使用信号“EXP<-->PHB映射”的E-LSP，LSR必须通过在标签设置时明确检查合并LSP上是否支持完全相同的PHB集来强制执行上述合并条件。
For E-LSPs using the preconfigured `EXP<-->PHB mapping', since the PHBs supported over an E-LSP is not signaled at establishment time, an LSR can not rely on signaling information to enforce the above merge. However all E-LSPs using the preconfigured `EXP<-->PHB mapping' are required to support the same set of Behavior Aggregates within a given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the preconfigured `EXP<-->PHB mapping' is allowed within a given MPLS Diff-Serv domain.
对于使用预配置的“EXP<-->PHB映射”的E-LSP，由于E-LSP上支持的PHB在建立时不发信号，因此LSR不能依赖信号信息来实施上述合并。但是，所有使用预配置“EXP<-->PHB映射”的E-LSP都需要在给定MPLS区分服务域内支持相同的行为聚合集。因此，允许在给定MPLS区分服务域内使用预配置的“EXP<-->PHB映射”合并E-LSP。
L-LSPs are defined in section 1.3.
L-LSP的定义见第1.3节。
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated at label setup for an incoming L-LSP in order to allow Incoming PHB determination.
本节定义了如何在传入L-LSP的标签设置中填充Diff-Serv上下文的“Encaps-->PHB映射”，以允许传入PHB确定。
If the LSR terminates the MPLS Shim Layer over this incoming L-LSP and the L-LSP ingresses on an interface which is not ATM nor Frame Relay, then the `Encaps-->PHB mapping' is populated in the following way:
如果LSR在此传入的L-LSP上终止MPLS垫片层，并且L-LSP在非ATM或帧中继的接口上进入，则“Encaps-->PHB映射”将按以下方式填充：
- it is actually a `EXP-->PHB mapping'
- 它实际上是一个“EXP-->PHB映射”
- this mapping is a function of the PSC which is carried on this LSP, and must use the relevant mapping entries for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
- 此映射是此LSP上执行的PSC的一个功能，必须使用第4.2.1.1节中定义的强制性“EXP/PSC-->PHB映射”中此PSC的相关映射条目。
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
例如，如果传入标签对应于支持AF1 PSC的L-LSP，则“Encaps-->PHB映射”将填充以下内容：
EXP Field PHB
EXP字段PHB
001 ----> AF11
010 ----> AF12
011 ----> AF13
001 ----> AF11
010 ----> AF12
011 ----> AF13
An LSR, supporting L-LSPs over PPP interfaces and LAN interfaces, is an example of an LSR terminating the Shim layer over ingress interfaces which are not ATM nor Frame Relay.
LSR支持PPP接口和LAN接口上的L-LSP，是LSR在非ATM或帧中继的入口接口上终止垫片层的示例。
If the LSR terminates the MPLS Shim Layer over this incoming L-LSP and the L-LSP ingresses on an ATM or Frame Relay interface, then the `Encaps-->PHB mapping' is populated in the following way:
如果LSR在此传入L-LSP上终止MPLS填充层，并且L-LSP在ATM或帧中继接口上进入，则“Encaps-->PHB映射”将按以下方式填充：
- it should actually be a `EXP-->PHB mapping'. Alternative optional ways of populating the `Encaps-->PHB mapping' might be defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or a 'DE/EXP-->PHB mapping') but are outside the scope of this document.
- 它实际上应该是一个“EXP-->PHB映射”。将来可能会定义填充“Encaps-->PHB映射”的可选方法（例如，使用“CLP/EXP-->PHB映射”或“DE/EXP-->PHB映射”），但不在本文档的范围内。
- when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this `EXP-->PHB mapping' mapping is a function of the PSC which is carried on the L-LSP, and must use the relevant mapping entries for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
- 当“Encaps-->PHB映射”是“EXP-->PHB映射”时，此“EXP-->PHB映射”映射是在L-LSP上进行的PSC的函数，并且必须使用第4.2.1.1节中定义的强制性“EXP/PSC-->PHB映射”中的此PSC的相关映射项。
An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an example of an LSR terminating the shim layer over an ingress ATM/FR interface.
ATM-MPLS域或FR-MPLS域的边缘LSR是通过入口ATM/FR接口终止垫片层的LSR的示例。
EXP Field PSC PHB
EXP字段PSC PHB
000 DF ----> DF
000 CSn ----> CSn
001 AFn ----> AFn1
010 AFn ----> AFn2
011 AFn ----> AFn3
000 EF ----> EF
000 DF ----> DF
000 CSn ----> CSn
001 AFn ----> AFn1
010 AFn ----> AFn2
011 AFn ----> AFn3
000 EF ----> EF
If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses ATM encapsulation (i.e., it is an ATM-LSR), then the `Encaps-->PHB mapping' for this incoming L-LSP is populated in the following way:
如果LSR未终止此传入标签上的MPLS垫片层，并使用ATM封装（即，它是ATM-LSR），则此传入L-LSP的“Encaps-->PHB映射”将按以下方式填充：
- it is actually a `CLP-->PHB mapping'
- 它实际上是一个“CLP-->PHB映射”
- the mapping is a function of the PSC, which is carried on this LSP, and should use the relevant mapping entries for this PSC from the Default `CLP/PSC-->PHB mapping' defined in Section 4.2.2.1.
- 映射是PSC的一项功能，该功能在此LSP上执行，并且应使用第4.2.2.1节中定义的默认“CLP/PSC-->PHB映射”中的此PSC的相关映射项。
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' should be populated with:
例如，如果传入标签对应于支持AF1 PSC的L-LSP，则“Encaps-->PHB映射”应填充以下内容：
CLP Field PHB
中电现场PHB
0 ----> AF11
1 ----> AF12
0 ----> AF11
1 ----> AF12
CLP Bit PSC PHB
CLP位PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses Frame Relay encapsulation (i.e., it is a FR-LSR), then the `Encaps-->PHB mapping' for this incoming L-LSP is populated in the following way:
如果LSR未终止此传入标签上的MPLS填充层，并使用帧中继封装（即，它是FR-LSR），则此传入L-LSP的“Encaps-->PHB映射”将按以下方式填充：
- it is actually a `DE-->PHB mapping'
- 它实际上是一个“DE-->PHB映射”
- the mapping is a function of the PSC which is carried on this LSP, and should use the relevant mapping entries for this PSC from the Default `DE/PSC-->PHB mapping' defined in Section 4.2.3.1.
- 映射是在该LSP上执行的PSC的一个功能，应使用第4.2.3.1节中定义的默认“DE/PSC-->PHB映射”中的该PSC的相关映射条目。
DE Bit PSC PHB
数据位PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
This section defines how Incoming PHB determination is carried out when the considered label entry in the received label stack corresponds to an L-LSP. This requires that the `Encaps-->PHB mapping' is populated as defined in section 4.2.
本节定义了当接收到的标签堆栈中所考虑的标签条目对应于L-LSP时，如何执行传入PHB确定。这要求按照第4.2节中的定义填充“Encaps-->PHB映射”。
When considering a label entry corresponding to an incoming L-LSP for Incoming PHB Determination, the LSR first determines the `Encaps-->PHB mapping' associated with the corresponding label.
当考虑与传入的L-LSP对应的标签条目以确定传入的PHB时，LSR首先确定与相应标签关联的“Encaps-->PHB映射”。
If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR:
如果“Encaps-->PHB映射”的形式为“EXP-->PHB映射”，则LSR：
- determines the incoming PHB by looking at the EXP field of the considered label entry and using the `EXP-->PHB mapping'.
- 通过查看所考虑标签项的EXP字段并使用“EXP-->PHB映射”来确定传入PHB。
If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', then the LSR:
如果“Encaps-->PHB映射”的形式为“CLP-->PHB映射”，则LSR：
- determines the incoming PHB by looking at the CLP field of the ATM Layer encapsulation and using the `CLP-->PHB mapping'.
- 通过查看ATM层封装的CLP字段并使用“CLP-->PHB映射”确定传入PHB。
If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR:
如果“Encaps-->PHB映射”的形式为“DE-->PHB映射”，则LSR：
- determines the incoming PHB by looking at the DE field of the Frame Relay encapsulation and by using the `DE-->PHB mapping'.
- 通过查看帧中继封装的DE字段并使用“DE-->PHB映射”确定传入PHB。
This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv Context is populated at label setup for an outgoing L-LSP in order to allow Encoding of Diff-Serv Information.
本节定义如何在传出L-LSP的标签设置中填充区分服务上下文的“PHB-->封装映射集”，以便对区分服务信息进行编码。
If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then one `PHB-->EXP mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing L-LSP. This `PHB-->EXP mapping' is populated in the following way:
如果LSR在此传出L-LSP上使用MPLS填充层，则会将一个“PHB-->EXP映射”添加到此传出L-LSP的“PHB-->封装映射集”。此“PHB-->EXP映射”按以下方式填充：
- it is a function of the PSC supported on this LSP, and must use the mapping entries relevant for this PSC from the Mandatory `PHB-->EXP mapping' defined in section 4.4.1.1.
- 它是此LSP支持的PSC的功能，必须使用第4.4.1.1节中定义的强制性“PHB-->EXP映射”中与此PSC相关的映射条目。
For example, if the outgoing label corresponds to an L-LSP supporting the AF1 PSC, then the following `PHB-->EXP mapping' is added into the `Set of PHB-->Encaps mappings':
例如，如果传出标签对应于支持AF1 PSC的L-LSP，则将以下“PHB-->EXP映射”添加到“PHB-->封装映射集”中：
PHB EXP Field
PHB EXP字段
AF11 ----> 001
AF12 ----> 010
AF13 ----> 011
AF11 ----> 001
AF12 ----> 010
AF13 ----> 011
PHB EXP Field
PHB EXP字段
DF ----> 000
CSn ----> 000
AFn1 ----> 001
AFn2 ----> 010
AFn3 ----> 011
EF ----> 000
DF ----> 000
CSn ----> 000
AFn1 ----> 001
AFn2 ----> 010
AFn3 ----> 011
EF ----> 000
If the L-LSP is egressing on an ATM interface (i.e., it is an ATM-LSR or it is a frame-based LSR sending packets on an LC-ATM interface or on an ATM interface which is not label switching controlled), then one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing L-LSP.
如果L-LSP在ATM接口上退出（即，它是一个ATM-LSR或它是一个基于帧的LSR，在LC-ATM接口上或在一个不受标签交换控制的ATM接口上发送数据包），则一个“PHB-->CLP映射”被添加到该出站L-LSP的“PHB-->封装映射集”。
If the L-LSP is egressing over an ATM interface which is not label-controlled, the `PHB-->CLP mapping' is populated as per section 3.4.2.
如果L-LSP通过不受标签控制的ATM接口出口，则按照第3.4.2节填充“PHB-->CLP映射”。
If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP mapping' is populated in the following way:
如果L-LSP通过LC-ATM接口退出，“PHB-->CLP映射”按以下方式填充：
- it is a function of the PSC supported on this LSP, and should use the relevant mapping entries for this PSC from the Default `PHB-->CLP mapping' defined in section 3.4.2.1.
- 它是此LSP支持的PSC的一个功能，应使用第3.4.2.1节中定义的默认“PHB-->CLP映射”中此PSC的相关映射项。
Notice that if the LSR is a frame-based LSR supporting an L-LSP egressing over an ATM interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'. If the LSR is an ATM-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'.
请注意，如果LSR是基于帧的LSR，支持通过ATM接口出口的L-LSP，则“PHB-->封装映射集”包含“PHB-->EXP映射”和“PHB-->CLP映射”。如果LSR是支持L-LSP的ATM-LSR，则“PHB-->封装映射集”仅包含“PHB-->CLP映射”。
If the L-LSP is egressing over a Frame Relay interface (i.e., it is an LSR sending packets on an LC-FR interface or on a Frame Relay interface which is not label switching controlled), one `PHB-->DE mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing L-LSP.
如果L-LSP通过帧中继接口（即，它是在LC-FR接口上或在不受标签交换控制的帧中继接口上发送数据包的LSR）退出，则会将一个“PHB-->解映射”添加到此出站L-LSP的“PHB-->封装映射集”。
If the L-LSP is egressing over a FR interface which is not label switching controlled, the `PHB-->DE mapping' is populated as per section 3.4.3.
如果L-LSP通过不受标签切换控制的FR接口退出，则按照第3.4.3节填充“PHB-->解映射”。
If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE mapping' is populated in the following way:
如果L-LSP通过LC-FR接口退出，“PHB-->解映射”按以下方式填充：
- it is a function of the PSC supported on this LSP, and should use the relevant mapping entries for this PSC from the Default `PHB-->DE mapping' defined in section 3.4.3.1.
- 它是此LSP上支持的PSC的一个功能，应使用第3.4.3.1节中定义的默认“PHB-->解映射”中此PSC的相关映射条目。
Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing over a LC-FR interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->DE mapping'.
请注意，如果LSR是支持通过LC-FR接口出口的L-LSP的边缘LSR，“PHB-->封装映射集”包含“PHB-->EXP映射”和“PHB-->反映射”。如果LSR是支持L-LSP的FR-LSR，则“PHB-->封装映射集”仅包含“PHB-->反映射”。
If the LSP is egressing over a LAN interface on which multiple 802.1 Traffic Classes are supported, as defined in [IEEE_802.1], then one `PHB-->802.1 mapping' is added as per section 3.4.4.
如[IEEE_802.1]中所定义，如果LSP通过支持多个802.1通信量类别的LAN接口退出，则根据第3.4.4节添加一个“PHB-->802.1映射”。
4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing L-LSP
4.5 在输出L-LSP上将区分服务信息编码到封装层
This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a transmitted label entry corresponding to an outgoing L-LSP. This requires that the `Set of PHB-->Encaps mappings' is populated as defined in section 4.4.
本节定义了如何将Diff Serv信息编码到MPLS封装层，以用于对应于传出L-LSP的已传输标签条目。这要求按照第4.4节中的定义填充“PHB-->封装映射集”。
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE and then performs corresponding encoding as specified in sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4.
LSR首先确定与NHLFE中相应标签相关联的区分服务上下文的“PHB-->封装映射集”，然后按照第3.5.1、3.5.2、3.5.3和3.5.4节的规定执行相应的编码。
In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. L-LSPs are compatible with LSP Merging under the following condition:
在MPLS域中，可以在一个LSR上将两个或多个LSP合并为一个LSP。在以下条件下，L-LSP与LSP合并兼容：
L-LSPs can only be merged into one L-LSP if they support the same PSC.
如果L-LSP支持相同的PSC，则它们只能合并为一个L-LSP。
The above merge condition MUST be enforced by LSRs, through explicit checking at label setup, that the same PSC is supported on the merged LSPs.
LSR必须通过标签设置时的显式检查强制执行上述合并条件，以确保合并的LSP上支持相同的PSC。
Note that when L-LSPs merge, the bandwidth that is available for the PSC downstream of the merge point must be sufficient to carry the sum of the merged traffic. This is particularly important in the case of EF traffic. This can be ensured in multiple ways (for instance via provisioning, or via bandwidth signaling and explicit admission control).
请注意，当L-LSP合并时，合并点下游PSC可用的带宽必须足以承载合并流量的总和。这在EF流量的情况下尤为重要。这可以通过多种方式确保（例如通过供应，或通过带宽信令和显式许可控制）。
The MPLS architecture does not assume a single label distribution protocol. [RSVP_MPLS_TE] defines the extension to RSVP for establishing LSPs in MPLS networks. This section specifies the extensions to RSVP, beyond those defined in [RSVP_MPLS_TE], to establish LSPs supporting Differentiated Services in MPLS networks.
MPLS体系结构不采用单标签分发协议。[RSVP_MPLS_TE]定义了RSVP的扩展，用于在MPLS网络中建立lsp。本节规定了RSVP的扩展，超出了[RSVP_MPLS_TE]中定义的扩展，以建立支持MPLS网络中差异化服务的LSP。
One new RSVP Object is defined in this document: the DIFFSERV Object. Detailed description of this Object is provided below. This new Object is applicable to Path messages. This specification only defines the use of the DIFFSERV Object in Path messages used to establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object.
本文定义了一个新的RSVP对象：DIFFSERV对象。下文提供了该对象的详细说明。此新对象适用于路径消息。本规范仅定义在用于根据[RSVP_MPLS_TE]建立LSP隧道的路径消息中使用DIFFSERV对象，从而包含一个C类型等于LSP_TUNNEL_IPv4并包含一个LABEL_请求对象的会话对象。
Restrictions defined in [RSVP_MPLS_TE] for support of the establishment of LSP Tunnels via RSVP are also applicable to the establishment of LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs are supported and Multicast LSPs are for further study.
[RSVP_MPLS_TE]中定义的用于支持通过RSVP建立LSP隧道的限制也适用于支持区分服务的LSP隧道的建立：例如，仅支持单播LSP，多播LSP有待进一步研究。
This new DIFFSERV object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP set up do not have to support this object.
这个新的DIFFSERV对象对于RSVP是可选的，因此与MPLS LSP设置无关的一般RSVP实现不必支持这个对象。
The DIFFSERV Object is optional for support of LSP Tunnels as defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs using the preconfigured `EXP<-->PHB mapping' in compliance with this specification MAY support the DIFFSERV Object. A Diff-Serv capable LSR supporting E-LSPs using a signaled `EXP<-->PHB mapping' in compliance with this specification MUST support the DIFFSERV Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the DIFFSERV Object.
DIFFSERV对象是可选的，用于支持[RSVP_MPLS_TE]中定义的LSP隧道。支持E-LSP的具有区分服务功能的LSR（使用符合本规范的预配置“EXP<-->PHB映射”）可能支持区分服务对象。支持使用符合本规范的信号“EXP<-->PHB映射”的E-LSP的具有区分服务功能的LSR必须支持区分服务对象。支持符合本规范的L-LSP的具有区分服务功能的LSR必须支持区分服务对象。
The format of the Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The DIFFSERV object formats are shown below. Currently there are two possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 is a DIFFSERV object for an L-LSP.
DIFFSERV对象格式如下所示。目前有两种可能的C_类型。类型1是E-LSP的DIFFSERV对象。类型2是L-LSP的DIFFSERV对象。
5.2.1. DIFFSERV object for an E-LSP:
5.2.1. E-LSP的DIFFSERV对象：
class = 65, C_Type = 1
等级=65，C_类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留：此字段保留28位。传输时必须将其设置为零，接收时必须忽略。
MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 8.
MAPnb:4位表示DIFFSERV对象中包含的映射项的数量。这可以设置为0到8之间的任何值。
MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format:
MAP:32位每个MAP条目定义一个EXP字段值和一个PHB之间的映射。地图条目具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留：13位此字段保留。传输时必须将其设置为零，接收时必须忽略。
EXP : 3 bits This field contains the value of the EXP field for the `EXP<-->PHB mapping' defined in this MAP entry.
EXP:3位此字段包含此映射项中定义的“EXP<-->PHB映射”的EXP字段的值。
PHBID : 16 bits This field contains the PHBID of the PHB for the `EXP<-->PHB mapping' defined in this MAP entry. The PHBID is encoded as specified in [PHBID].
PHBID：16位此字段包含此映射项中定义的“EXP<-->PHB映射”的PHB的PHBID。PHBID按照[PHBID]中的规定进行编码。
5.2.2 DIFFSERV object for an L-LSP:
5.2.2 L-LSP的DIFFSERV对象：
class = 65, C_Type = 2
等级=65，C_类型=2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 16 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留：16位此字段保留。传输时必须将其设置为零，接收时必须忽略。
PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in [PHBID].
PSC:16位PSC表示LSP支持的PHB调度类。PSC按照[PHBID]中的规定进行编码。
To establish an LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP_MPLS_TE].
要使用RSVP建立LSP隧道，发送方根据[RSVP_MPLS_TE]创建会话类型为LSP_tunnel_IPv4且带有标签_请求对象的路径消息。
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured `EXP<-->PHB mapping', the sender creates a Path message:
要使用RSVP建立E-LSP隧道，该隧道使用预配置的“EXP<-->PHB映射”，发送方将创建一条路径消息：
- with a session type of LSP_Tunnel_IPv4,
- 会话类型为LSP_Tunnel_IPv4，
- with the LABEL_REQUEST object, and
- 使用LABEL_请求对象，以及
- without the DIFFSERV object.
- 没有DIFFSERV对象。
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured `EXP<-->PHB mapping', the sender MAY alternatively create a Path message:
要使用RSVP建立E-LSP隧道，该隧道使用预配置的“EXP<-->PHB映射”，发送方也可以创建路径消息：
- with a session type of LSP_Tunnel_IPv4,
- 会话类型为LSP_Tunnel_IPv4，
- with the LABEL_REQUEST object, and
- 使用LABEL_请求对象，以及
- with the DIFFSERV object for an E-LSP containing no MAP entries.
- 不包含映射项的E-LSP的DIFFSERV对象。
To establish an E-LSP tunnel with RSVP, which uses a signaled `EXP<-->PHB mapping', the sender creates a Path message:
要使用RSVP建立E-LSP隧道，该隧道使用信号“EXP<-->PHB映射”，发送方创建路径消息：
- with a session type of LSP_Tunnel_IPv4,
- 会话类型为LSP_Tunnel_IPv4，
- with the LABEL_REQUEST object,
- 使用LABEL_REQUEST对象，
- with the DIFFSERV object for an E-LSP containing one MAP entry for each EXP value to be supported on this E-LSP.
- 使用E-LSP的DIFFSERV对象，该对象包含此E-LSP上支持的每个EXP值的一个映射条目。
To establish with RSVP an L-LSP tunnel, the sender creates a Path message:
要使用RSVP建立L-LSP隧道，发送方将创建路径消息：
- with a session type of LSP_Tunnel_IPv4,
- 会话类型为LSP_Tunnel_IPv4，
- with the LABEL_REQUEST object,
- 使用LABEL_REQUEST对象，
- with the DIFFSERV object for an L-LSP containing the PHB Scheduling Class (PSC) supported on this L-LSP.
- 使用包含此L-LSP支持的PHB调度类（PSC）的L-LSP的DIFFSERV对象。
If a path message contains multiple DIFFSERV objects, only the first one is meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded.
如果路径消息包含多个DIFFSERV对象，则只有第一个对象有意义；后续的DIFFSERV对象必须被忽略且不能转发。
Each LSR along the path records the DIFFSERV object, when present, in its path state block.
路径上的每个LSR在其路径状态块中记录DIFFSERV对象（如果存在）。
If a DIFFSERV object is not present in the Path message, the LSR SHOULD interpret this as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'. However, for backward compatibility purposes, with other non-Diff-Serv Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated Services Controlled Load or Guaranteed Services, the LSR MAY support a configurable "override option". When this "override option" is configured, the LSR interprets a path message without a Diff-Serv object as a request for an LSP with such non-Diff-Serv Quality of Service.
如果路径消息中不存在DIFFSERV对象，则LSR应使用预配置的“EXP<-->PHB映射”将其解释为对E-LSP的请求。然而，出于向后兼容性的目的，对于[RSVP_MPLS_TE]允许的其他非区分服务服务质量选项，例如集成服务控制负载或保证服务，LSR可以支持可配置的“覆盖选项”。配置此“覆盖选项”时，LSR将不带区分服务对象的路径消息解释为对具有此类非区分服务质量的LSP的请求。
If a DIFFSERV object for an E-LSP containing no MAP entry is present in the Path message, the LSR MUST interpret this as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'. In particular, this allows an LSR with the "override option" configured to support E-LSPs with Preconfigured `EXP<-->PHB mapping', simultaneously with LSPs with non-Diff-Serv Quality of Service.
如果路径消息中存在不包含映射项的E-LSP的DIFFSERV对象，则LSR必须使用预配置的“EXP<-->PHB映射”将其解释为对E-LSP的请求。特别是，这允许具有“覆盖选项”的LSR配置为支持具有预配置“EXP<-->PHB映射”的电子LSP，同时支持具有非区分服务质量的LSP。
If a DIFFSERV object for an E-LSP containing at least one MAP entry is present in the Path message, the LSR MUST interpret this as a request for an E-LSP with signaled `EXP<-->PHB mapping'.
如果路径消息中存在包含至少一个映射条目的E-LSP的DIFFSERV对象，则LSR必须将其解释为对带有信号“EXP<-->PHB mapping”的E-LSP的请求。
If a DIFFSERV object for an L-LSP is present in the Path message, the LSR MUST interpret this as a request for an L-LSP.
如果路径消息中存在L-LSP的DIFFSERV对象，则LSR必须将其解释为对L-LSP的请求。
The destination LSR of an E-LSP or L-LSP responds to the Path message containing the LABEL_REQUEST object by sending a Resv message:
E-LSP或L-LSP的目标LSR通过发送Resv消息来响应包含LABEL_请求对象的Path消息：
- with the LABEL object
- 使用标签对象
- without a DIFFSERV object.
- 没有区分服务对象。
Assuming the label request is accepted and a label is allocated, the Diff-Serv LSRs (sender, destination, intermediate nodes) must:
假设接受标签请求并分配标签，则区分服务LSR（发送方、目的地、中间节点）必须：
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- 按照前面章节（传入和传出标签）中的规定，更新与ILM/FTN中已建立的LSP关联的区分服务上下文，
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- 为此NHLFE（传出标签）安装所需的区分服务转发处理（调度和丢弃行为）。
An LSR that recognizes the DIFFSERV object and that receives a path message which contains the DIFFSERV object but which does not contain a LABEL_REQUEST object or which does not have a session type of LSP_Tunnel_IPv4, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unexpected DIFFSERV object'. Those are defined below in section 5.5.
识别DIFFSERV对象并接收包含DIFFSERV对象但不包含LABEL_请求对象或会话类型为LSP_Tunnel_IPv4的路径消息的LSR向发送方发送路径错误，错误代码为“DIFFSERV error”，错误值为“意外DIFFSERV object”。这些定义见下文第5.5节。
An LSR receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but does not support the particular PHB encoded in one, or more, of the MAP entries, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PHB'. Those are defined below in section 5.5.
LSR接收到带有用于E-LSP的DIFFSERV对象的路径消息，该消息识别DIFFSERV对象，但不支持在一个或多个映射条目中编码的特定PHB，向发送方发送路径错误，错误代码为“DIFFSERV error”，错误值为“Unsupported PHB”。这些定义见下文第5.5节。
An LSR receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but determines that the signaled `EXP<-->PHB mapping' is invalid, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of Invalid `EXP<-->PHB mapping'. Those are defined below in section 5.5. `The EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is invalid when:
LSR接收到带有用于E-LSP的DIFFSERV对象的路径消息，该消息识别DIFFSERV对象，但确定发信号的“EXP<-->PHB映射”无效，向发送方发送路径错误，错误代码为“DIFFSERV error”，错误值为无效的“EXP<-->PHB映射”。这些定义见下文第5.5节`在以下情况下，电子LSP的DIFFSERV对象中发出的EXP<-->PHB映射”无效：
- the MAPnb field is not within the range 0 to 8 or
- MAPnb字段不在0到8的范围内，或者
- a given EXP value appears in more than one MAP entry, or
- 给定的EXP值出现在多个映射条目中，或
- the PHBID encoding is invalid.
- PHBID编码无效。
An LSR receiving a Path message with the DIFFSERV object for L-LSP, which recognizes the DIFFSERV object but does not support the particular PSC encoded in the PSC field, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PSC'. Those are defined below in section 5.5.
LSR通过L-LSP的DIFFSERV对象接收路径消息，该消息识别DIFFSERV对象，但不支持PSC字段中编码的特定PSC，向发送方发送路径错误，错误代码为“DIFFSERV error”，错误值为“Unsupported PSC”。这些定义见下文第5.5节。
An LSR receiving a Path message with the DIFFSERV object, which recognizes the DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv context sends a PathErr with the error code "Diff-Serv Error" and the error value "Per-LSP context allocation failure". Those are defined below in section 5.5.
接收到带有DIFFSERV对象的路径消息的LSR（识别DIFFSERV对象，但无法分配所需的每LSP DIFFSERV上下文）将发送一个路径错误，错误代码为“DIFFSERV error”，错误值为“每LSP上下文分配失败”。这些定义见下文第5.5节。
A Diff-Serv LSR MUST handle the situations where the label request can not be accepted for reasons other than those already discussed in this section, in accordance with [RSVP_MPLS_TE] (e.g., reservation rejected by admission control, a label can not be associated).
Diff-Serv LSR必须根据[RSVP_MPLS_TE]（例如，接纳控制拒绝保留，标签无法关联）处理由于本节中已讨论原因以外的原因而无法接受标签请求的情况。
An LSR that does not recognize the DIFFSERV object Class-Num MUST behave in accordance with the procedures specified in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb i.e., it must send a PathErr with the error code `Unknown object class' toward the sender.
不识别DIFFSERV对象类Num的LSR必须按照[RSVP]中为格式为0bbb的未知类Num指定的过程进行操作，即它必须向发送方发送错误代码为“unknown object Class”的PathErr。
An LSR that recognize the DIFFSERV object Class-Num but does not recognize the DIFFSERV object C-Type, must behave in accordance with the procedures specified in [RSVP] for an unknown C-type i.e., it must send a PathErr with the error code `Unknown object C-Type' toward the sender.
识别DIFFSERV对象类Num但不识别DIFFSERV对象C-Type的LSR必须按照[RSVP]中为未知C-Type指定的过程进行操作，即，它必须向发送方发送错误代码为“unknown object C-Type”的PathErr。
In both situations, this causes the path set-up to fail. The sender should notify management that a L-LSP cannot be established and should possibly take action to retry LSP establishment without the DIFFSERV object (e.g., attempt to use E-LSPs with Preconfigured `EXP<-->PHB mapping' as a fall-back strategy).
在这两种情况下，这都会导致路径设置失败。发送方应通知管理层无法建立L-LSP，并可能采取措施在没有DIFFSERV对象的情况下重试LSP的建立（例如，尝试使用带有预配置的“EXP<-->PHB映射”的e-LSP作为回退策略）。
In the procedures described above, certain errors must be reported as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error code is 27.
在上述过程中，某些错误必须报告为“Diff Serv Error”。“Diff Serv Error”错误代码的值为27。
The following defines error values for the Diff-Serv Error:
以下定义了Diff Serv错误的错误值：
Value Error
值错误
1 Unexpected DIFFSERV object 2 Unsupported PHB 3 Invalid `EXP<-->PHB mapping' 4 Unsupported PSC 5 Per-LSP context allocation failure
1意外的DIFFSERV对象2不支持的PHB 3无效的'EXP<-->PHB映射'4不支持的PSC 5每LSP上下文分配失败
Both E-LSPs and L-LSPs can be established with or without bandwidth reservation.
E-LSP和L-LSP都可以在保留或不保留带宽的情况下建立。
As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP with bandwidth reservation, Int-Serv's Controlled Load service (or possibly Guaranteed Service) is used and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the path (respectively Resv) message.
如[RSVP_MPLS_TE]中所述，为了建立具有带宽保留的E-LSP或L-LSP，使用Int Serv的受控负载服务（或可能的保证服务），并在路径（分别为Resv）消息的发送方_TSPEC（分别为FLOWSPEC）中通知带宽。
As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP without bandwidth reservation, the Null Service specified in [NULL] is used.
如[RSVP_MPLS_TE]中所述，为了在没有带宽预留的情况下建立E-LSP或L-LSP，使用[Null]中指定的Null服务。
Note that this specification defines usage of E-LSPs and L-LSPs for support of the Diff-Serv service only. Regardless of the Intserv service (Controlled Load, Null Service, Guaranteed Service,...) and regardless of whether the reservation is with or without bandwidth reservation, E-LSPs and L-LSPs are defined here for support of Diff-Serv services. Support of Int-Serv services over an MPLS Diff-Serv backbone is outside the scope of this specification.
注意，本规范定义了E-LSP和L-LSP的用法，仅用于支持区分服务。无论Intserv服务（受控负载、空服务、保证服务等）如何，也不管保留是否带有带宽保留，此处定义了E-LSP和L-LSP以支持区分服务。通过MPLS Diff Serv主干网支持Int Serv服务不在本规范的范围内。
Note also that this specification does not concern itself with the DCLASS object defined in [DCLASS], since this object conveys information on DSCP values, which are not relevant inside the MPLS network.
还请注意，本规范与[DCLASS]中定义的DCLASS对象无关，因为该对象传递有关DSCP值的信息，而这些值在MPLS网络中并不相关。
The MPLS architecture does not assume a single label distribution protocol. [LDP] defines the Label Distribution Protocol and its usage for establishment of label switched paths (LSPs) in MPLS networks. This section specifies the extensions to LDP to establish LSPs supporting Differentiated Services in MPLS networks.
MPLS体系结构不采用单标签分发协议。[LDP]定义了标签分发协议及其在MPLS网络中建立标签交换路径（LSP）的用途。本节规定了LDP的扩展，以在MPLS网络中建立支持区分服务的LSP。
One new LDP TLV is defined in this document:
本文件中定义了一个新的LDP TLV：
- the Diff-Serv TLV
- 区分服务TLV
Detailed description of this TLV is provided below.
下文提供了该TLV的详细说明。
The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv capable LSR supporting E-LSPs which uses the Preconfigured `EXP<-- >PHB mapping' in compliance with this specification MAY support the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which uses the signaled `EXP<-->PHB mapping' in compliance with this specification MUST support the Diff-Serv TLV. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the Diff-Serv TLV.
新的Diff-Serv TLV对于LDP是可选的。支持E-LSP的具有区分服务功能的LSR（使用符合本规范的预配置“EXP<-->PHB映射”）可支持区分服务TLV。支持E-LSP的具有区分服务功能的LSR（使用符合本规范的信号“EXP<-->PHB映射”）必须支持区分服务TLV。支持符合本规范的L-LSP的具有区分服务功能的LSR必须支持区分服务TLV。
The Diff-Serv TLV has the following formats:
Diff-Serv TLV具有以下格式：
Diff-Serv TLV for an E-LSP:
E-LSP的区分服务TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Diff-Serv (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Diff-Serv (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit LSP Type. This is set to 0 for an E-LSP
T:1位LSP类型。这对于E-LSP设置为0
Reserved : 27 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留：27位此字段保留。传输时必须将其设置为零，接收时必须忽略。
MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8.
MAPnb:4位表示DIFFSERV对象中包含的映射项的数量。这可以设置为1到8之间的任何值。
MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format:
MAP:32位每个MAP条目定义一个EXP字段值和一个PHB之间的映射。地图条目具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留：13位此字段保留。传输时必须将其设置为零，接收时必须忽略。
EXP : 3 bits This field contains the value of the EXP field for the `EXP<-->PHB mapping' defined in this MAP entry.
EXP:3位此字段包含此映射项中定义的“EXP<-->PHB映射”的EXP字段的值。
PHBID : 16 bits This field contains the PHBID of the PHB for the `EXP<-->PHB mapping' defined in this MAP entry. The PHBID is encoded as specified in [PHBID].
PHBID：16位此字段包含此映射项中定义的“EXP<-->PHB映射”的PHB的PHBID。PHBID按照[PHBID]中的规定进行编码。
Diff-Serv TLV for an L-LSP:
L-LSP的区分服务TLV：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PSC (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PSC (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit LSP Type. This is set to 1 for an L-LSP
T:1位LSP类型。对于L-LSP，该值设置为1
Reserved : 15 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留：15位此字段保留。传输时必须将其设置为零，接收时必须忽略。
PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in [PHBID].
PSC:16位PSC表示LSP支持的PHB调度类。PSC按照[PHBID]中的规定进行编码。
The following values are defined for the Status Code field of the Status TLV:
为状态TLV的状态代码字段定义了以下值：
Status Code E Status Data
状态代码E状态数据
Unexpected Diff-Serv TLV 0 0x01000001 Unsupported PHB 0 0x01000002 Invalid `EXP<-->PHB mapping' 0 0x01000003 Unsupported PSC 0 0x01000004 Per-LSP context allocation failure 0 0x01000005
意外的区分服务TLV 0 0x01000001不支持的PHB 0 0x01000002无效的'EXP<-->PHB映射'0 0x01000003不支持的PSC 0 0x01000004每个LSP上下文分配失败0 0x01000005
The format of the Label Request message is extended as follows, to optionally include the Diff-Serv TLV:
标签请求消息的格式扩展如下，以可选地包括区分服务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| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Label Mapping message is extended as follows, to optionally include the Diff-Serv TLV:
标签映射消息的格式扩展如下，以可选地包括区分服务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| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Label Release message is extended as follows, to optionally include the Status TLV:
标签发布消息的格式扩展如下，可以选择包括状态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| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV (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 Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Notification message is extended as follows, to optionally include the Diff-Serv TLV:
通知消息的格式扩展如下，以可选地包括Diff-Serv 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| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (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| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section describes operations when the Downstream Unsolicited Mode is used.
本节描述使用下游非请求模式时的操作。
When allocating a label for an E-LSP which is to use the preconfigured `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label Mapping message without the Diff-Serv TLV.
为要使用预配置的“EXP<-->PHB映射”的E-LSP分配标签时，下游Diff-Serv LSR会发出标签映射消息，而不发送Diff-Serv TLV。
When allocating a label for an E-LSP which is to use a signaled `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP.
当为要使用信号“EXP<-->PHB映射”的E-LSP分配标签时，下游Diff-Serv LSR向E-LSP发出标签映射消息，其中包含该E-LSP上支持的每个EXP值的一个映射条目。
When allocating a label for an L-LSP, a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an L-LSP which contains the PHB Scheduling Class (PSC) to be supported on this L-LSP.
为L-LSP分配标签时，下游Diff-Serv LSR向L-LSP的Diff-Serv TLV发出标签映射消息，该L-LSP包含该L-LSP上支持的PHB调度类（PSC）。
Assuming the label set-up is successful, the downstream and upstream LSRs must:
假设标签设置成功，下游和上游LSR必须：
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- 按照前面章节（传入和传出标签）中的规定，更新与ILM/FTN中已建立的LSP关联的区分服务上下文，
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- 为此NHLFE（传出标签）安装所需的区分服务转发处理（调度和丢弃行为）。
An upstream Diff-Serv LSR receiving a Label Mapping message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
上游Diff-Serv LSR接收到带有多个Diff-Serv TLV的标签映射消息时，仅认为第一个有意义。LSR必须忽略且不转发后续的区分服务TLV。
An upstream Diff-Serv LSR which receives a Label Mapping message, with the Diff-Serv TLV for an E-LSP and does not support the particular PHB encoded in one or more of the MAP entries, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PHB'.
接收标签映射消息的上游Diff-Serv LSR，带有E-LSP的Diff-Serv TLV，并且不支持在一个或多个映射条目中编码的特定PHB，必须通过发送标签释放消息来拒绝映射，该消息包括标签TLV和状态代码为“Unsupported PHB”的状态TLV。
An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an E-LSP and determining that the signaled `EXP<-->PHB mapping' is invalid, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of Invalid `EXP<-->PHB mapping'. The `EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is invalid when:
上游Diff-Serv LSR接收到带有E-LSP的Diff-Serv TLV的标签映射消息，并确定发信号的“EXP<-->PHB映射”无效，必须通过发送标签释放消息来拒绝映射，该消息包括标签TLV和状态代码为“EXP<-->PHB映射”的状态TLV。在以下情况下，电子LSP的DIFFSERV对象中发出的“EXP<-->PHB映射”无效：
- the MAPnb field is not within the range 1 to 8, or
- MAPnb字段不在1到8的范围内，或
- a given EXP value appears in more than one MAP entry, or
- 给定的EXP值出现在多个映射条目中，或
- the PHBID encoding is invalid
- PHBID编码无效
An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PSC'.
上游Diff-Serv LSR接收到L-LSP的标签映射消息，其中Diff-Serv TLV包含不受支持的PSC值，必须通过发送标签释放消息拒绝映射，该消息包括标签TLV和状态代码为“不受支持的PSC”的状态TLV。
This section describes operations when the Downstream on Demand Mode is used.
本节描述了使用下游按需模式时的操作。
When requesting a label for an E-LSP which is to use the preconfigured `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a Label Request message without the Diff-Serv TLV.
当为要使用预配置的“EXP<-->PHB映射”的E-LSP请求标签时，上游Diff-Serv LSR发送标签请求消息，而不发送Diff-Serv TLV。
When requesting a label for an E-LSP which is to use a signaled `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP.
当为使用信号“EXP<-->PHB映射”的E-LSP请求标签时，上游Diff-Serv LSR为E-LSP发送带有Diff-Serv TLV的标签请求消息，其中包含该E-LSP上支持的每个EXP值的一个映射条目。
When requesting a label for an L-LSP, an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an L-LSP which contains the PSC to be supported on this L-LSP.
当请求L-LSP的标签时，上游Diff-Serv LSR通过Diff-Serv TLV发送L-LSP的标签请求消息，该L-LSP包含该L-LSP上支持的PSC。
A downstream Diff-Serv LSR sending a Label Mapping message in response to a Label Request message for an E-LSP or an L-LSP must not include a Diff-Serv TLV in this Label Mapping message. Assuming the label set-up is successful, the downstream and upstream LSRs must:
下游Diff-Serv LSR发送标签映射消息以响应E-LSP或L-LSP的标签请求消息时，不得在此标签映射消息中包含Diff-Serv TLV。假设标签设置成功，下游和上游LSR必须：
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- 按照前面章节（传入和传出标签）中的规定，更新与ILM/FTN中已建立的LSP关联的区分服务上下文，
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- 为此NHLFE（传出标签）安装所需的区分服务转发处理（调度和丢弃行为）。
An upstream Diff-Serv LSR receiving a Label Mapping message containing a Diff-Serv TLV in response to its Label Request message, must reject the label mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unexpected Diff-Serv TLV'.
上游Diff-Serv LSR接收到包含Diff-Serv TLV的标签映射消息以响应其标签请求消息时，必须通过发送包含标签TLV和状态TLV且状态代码为“意外Diff-Serv TLV”的标签释放消息来拒绝标签映射。
A downstream Diff-Serv LSR receiving a Label Request message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
下游Diff-Serv LSR接收到带有多个Diff-Serv TLV的标签请求消息时，仅认为第一个有意义。LSR必须忽略且不转发后续的区分服务TLV。
A downstream Diff-Serv LSR which receives a Label Request message with the Diff-Serv TLV for an E-LSP and does not support the particular PHB encoded in one (or more) of the MAP entries, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PHB'.
下游Diff-Serv LSR接收带有E-LSP的Diff-Serv TLV的标签请求消息，并且不支持在一个（或多个）映射条目中编码的特定PHB，必须通过发送包含状态代码为“Unsupported PHB”的状态TLV的通知消息来拒绝请求。
A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an E-LSP and determining that the signaled `EXP<-->PHB mapping' is invalid, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of Invalid `EXP<-->PHB mapping'. The `EXP<-->PHB mapping' signaled in the DIFFSERV TLV for an E-LSP is invalid when:
下游Diff-Serv LSR接收带有E-LSP的Diff-Serv TLV的标签请求消息，并确定发信号的“EXP<-->PHB映射”无效，必须通过发送包含状态代码为“EXP<-->PHB映射”的状态TLV的通知消息来拒绝该请求。在以下情况下，DIFFSERV TLV中针对E-LSP发出的“EXP<-->PHB映射”无效：
- the MAPnb field is not within the range 1 to 8, or
- MAPnb字段不在1到8的范围内，或
- a given EXP value appears in more than one MAP entry, or
- 给定的EXP值出现在多个映射条目中，或
- the PHBID encoding is invalid
- PHBID编码无效
A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PSC'.
下游Diff-Serv LSR接收到L-LSP的标签请求消息，其中Diff-Serv TLV包含不受支持的PSC值，必须通过发送通知消息拒绝该请求，该通知消息包括状态TLV，状态代码为“Unsupported PSC”。
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message but is unable to allocate the required per-LSP context information, must reject the request sending a Notification message which includes the Status TLV with a Status Code of `Per-LSP context allocation failure'.
识别标签请求消息中的Diff Serv TLV类型但无法分配所需的每LSP上下文信息的下游Diff Serv LSR必须拒绝发送通知消息的请求，该通知消息包括状态代码为“每LSP上下文分配失败”的状态TLV。
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message and supports the requested PSC but is not able to satisfy the label request for other reasons (e.g., no label available), must send a Notification message in accordance with existing LDP procedures [LDP] (e.g., with a `No Label Resource' Status Code). This Notification message must include the requested Diff-Serv TLV.
下游Diff-Serv LSR识别标签请求消息中的Diff-Serv TLV类型，并支持请求的PSC，但由于其他原因（例如，没有可用的标签）无法满足标签请求，必须根据现有LDP程序[LDP]发送通知消息（例如，“没有标签资源”状态代码）。此通知消息必须包括请求的Diff Serv TLV。
An LSR that does not recognize the Diff-Serv TLV Type, on receipt of a Label Request message or a Label Mapping message containing the Diff-Serv TLV, must behave in accordance with the procedures specified in [LDP] for an unknown TLV whose U Bit and F Bit are set to 0 i.e., it must ignore the message, return a Notification message with `Unknown TLV' Status.
在接收到标签请求消息或包含区分服务TLV的标签映射消息时，不识别区分服务TLV类型的LSR必须按照[LDP]中为U位和F位设置为0的未知TLV指定的程序进行操作，即它必须忽略该消息，返回状态为“未知TLV”的通知消息。
Bandwidth information may also be signaled at the establishment time of E-LSP and L-LSP, for instance for the purpose of Traffic Engineering, using the Traffic Parameters TLV as described in [MPLS CR LDP].
带宽信息也可以在E-LSP和L-LSP的建立时发信号通知，例如为了流量工程的目的，使用如MPLS-CR-LDP中所述的流量参数TLV。
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces
7. MPLS支持PPP、LAN、非LC ATM和非LC FR接口上的区分服务
The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations are specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces, ATM Interfaces which are not label controlled and Frame Relay interfaces which are not label controlled.
区分服务的MPLS支持的一般操作，包括标签转发和LSP设置操作，在前面的章节中有详细说明。本节描述了MPLS支持PPP上的区分服务接口、LAN接口、不受标签控制的ATM接口和不受标签控制的帧中继接口所需的具体操作。
On these interfaces, this specification allows any of the following LSP combinations per FEC:
在这些接口上，本规范允许每个FEC使用以下任一LSP组合：
- Zero or any number of E-LSP, and
- 零或任意数量的E-LSP，以及
- Zero or any number of L-LSPs.
- 零或任意数量的L-LSP。
A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured `EXP<-->PHB mapping' over these interfaces.
支持区分服务的LSR必须支持在这些接口上使用预配置的“EXP<-->PHB映射”的E-LSP。
A Diff-Serv capable LSR MAY support E-LSPs which use signaled `EXP<-->PHB mapping' and L-LSPs over these interfaces.
具有区分服务功能的LSR可支持通过这些接口使用信号“EXP<-->PHB映射”和L-LSP的E-LSP。
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled ATM (LC-ATM) interfaces.
本节描述了MPLS支持标签交换控制ATM（LC-ATM）接口上的区分服务所需的具体操作。
This document allows any number of L-LSPs per FEC within an MPLS ATM Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces.
本文件允许在MPLS ATM区分服务域内每个FEC有任意数量的L-LSP。LC-ATM接口不支持E-LSP。
The use of the "ATM service categories" specified by the ATM Forum, of the "ATM Transfer Capabilities" specified by the ITU-T or of vendor specific ATM traffic classes is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications.
使用ATM论坛指定的“ATM服务类别”、ITU-T指定的“ATM传输能力”或供应商特定的ATM业务类别不在本规范的范围内。兼容实现的唯一要求是，ATM LSR通过L-LSP转发的行为聚合所经历的转发行为必须符合相应的区分服务PHB规范。
Since there is only one bit (CLP) for encoding the PHB drop precedence value over ATM links, only two different drop precedence levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two ATM drop precedence levels. This mapping is in accordance with the requirements specified in [DIFF_AF] for the case when only two drop precedence levels are supported.
由于只有一位（CLP）用于编码ATM链路上的PHB丢弃优先级值，因此ATM LSR中只支持两种不同的丢弃优先级。第4.2.2节和第4.4.2节定义了AFn有序聚合的三个丢弃优先级如何映射到这两个ATM丢弃优先级。该映射符合[DIFF_AF]中针对仅支持两个丢弃优先级的情况规定的要求。
To avoid discarding parts of the packets, frame discard mechanisms, such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled in the ATM-LSRs for all PHBs described in this document.
为避免丢弃部分数据包，应在本文档中描述的所有PHB的ATM LSR中启用帧丢弃机制，如早期数据包丢弃（EPD）（参见[ATMF_TM]）。
A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces. This specification assumes that Edge-LSRs of the ATM-LSR domain use the "shim header" encapsulation method defined in [MPLS_ATM]. Operations without the "shim header" encapsulation are outside the scope of this specification.
具有区分服务功能的LSR必须支持LC-ATM接口上的L-LSP。本规范假设ATM-LSR域的边缘LSR使用[MPLS_ATM]中定义的“垫片头”封装方法。没有“垫片头”封装的操作不在本规范的范围内。
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled Frame Relay (LC-FR) interfaces.
本节描述了MPLS支持标签交换控制帧中继（LC-FR）接口上的区分服务所需的具体操作。
This document allows any number of L-LSPs per FEC within an MPLS Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR interfaces.
本文档允许在MPLS帧中继区分服务域内每个FEC有任意数量的L-LSP。LC-FR接口不支持E-LSP。
9.1 Use of Frame Relay Traffic parameters and Traffic Management mechanisms
9.1 帧中继流量参数和流量管理机制的使用
The use of the Frame Relay traffic parameters as specified by ITU-T and Frame Relay-Forum or of vendor specific Frame Relay traffic management mechanisms is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the Frame Relay LSR MUST be compliant with the corresponding Diff-Serv PHB specifications.
ITU-T和帧中继论坛规定的帧中继流量参数或特定于供应商的帧中继流量管理机制的使用不在本规范的范围内。兼容实现的唯一要求是，由帧中继LSR通过L-LSP转发的行为聚合所经历的转发行为必须符合相应的Diff-Serv PHB规范。
Since there is only one bit (DE) for encoding the PHB drop precedence value over Frame Relay links, only two different drop precedence levels are supported in Frame Relay LSRs. Sections 4.2.3 and 4.4.3 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two Frame Relay drop precedence levels. This mapping is in accordance with the requirements specified in [DIFF_AF] for the case when only two drop precedence levels are supported.
由于只有一位（DE）用于编码帧中继链路上的PHB丢弃优先级值，因此帧中继LSR中只支持两种不同的丢弃优先级。第4.2.3节和第4.4.3节定义了AFn有序聚合的三个丢弃优先级如何映射到这两个帧中继丢弃优先级。该映射符合[DIFF_AF]中针对仅支持两个丢弃优先级的情况规定的要求。
A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay interfaces.
具有区分服务功能的LSR必须支持LC帧中继接口上的L-LSP。
This specification assumes that Edge-LSRs of the FR-LSR domain use the "generic encapsulation" method as recommended in [MPLS_FR]. Operations without the "generic encapsulation" are outside the scope of this specification.
本规范假设FR-LSR域的边缘LSR使用[MPLS_FR]中建议的“通用封装”方法。没有“通用封装”的操作不在本规范的范围内。
This document defines a number of objects with implications for IANA.
本文档定义了许多对IANA有影响的对象。
This document defines in section 5.2 a new RSVP object, the DIFFSERV object. This object required a number from the space defined in [RSVP] for those objects which, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number. Within that space, this object required a number from the "IETF Consensus" space. "65" has been allocated by IANA for the DIFFSERV object.
本文档在第5.2节中定义了一个新的RSVP对象，即DIFFSERV对象。此对象需要[RSVP]中为这些对象定义的空格中的数字，如果不理解这些数字，将导致整个RSVP消息被拒绝，错误代码为“Unknown object Class”。此类对象由类编号最有效位的零标识。在该空间内，该物体需要来自“IETF共识”空间的数字。IANA已为DIFFSERV对象分配了“65”。
This document defines in section 5.5 a new RSVP error code, "Diffserv Error". Error code "27" has been assigned by IANA to the "Diffserv Error". This document defines values 1 through 5 of the value field to be used within the ERROR_SPEC object for this error code. Future allocations of values in this space should be handled by IANA using the First Come First Served policy defined in [IANA].
本文件在第5.5节中定义了一个新的RSVP错误代码“Diffserv error”。IANA已将错误代码“27”分配给“Diffserv错误”。本文档定义了要在此错误代码的ERROR_SPEC对象中使用的值字段的值1到5。IANA应使用[IANA]中定义的先到先得策略处理该空间中未来的值分配。
This document defines in section 6.1 a new LDP TLV, the Diffserv TLV. The number for this TLV has been assigned by working group consensus according to the policies defined in [LDP].
本文件在第6.1节中定义了一种新的LDP TLV，即Diffserv TLV。根据[LDP]中定义的政策，工作组一致同意分配该TLV的编号。
This document defines in section 6.2 five new LDP Status Code values for Diffserv-related error conditions. The values for the Status Code have been assigned by working group consensus according to the policies defined in [LDP].
本文件在第6.2节中定义了区分服务相关错误条件的五个新LDP状态码值。根据[LDP]中定义的政策，工作组一致同意分配状态代码的值。
This document does not introduce any new security issues beyond those inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms proposed for those technologies.
除了Diff-Serv、MPLS和RSVP中固有的安全问题外，本文档不会引入任何新的安全问题，并可能使用针对这些技术提出的相同机制。
This document has benefited from discussions with Eric Rosen, Angela Chiu and Carol Iturralde. It has also borrowed from the work done by D. Black regarding Diff-Serv and IP Tunnels interaction.
本文件得益于与Eric Rosen、Angela Chiu和Carol Iturralde的讨论。它还借鉴了D.Black在区分服务和IP隧道交互方面所做的工作。
APPENDIX A. Example Deployment Scenarios
附录A.部署场景示例
This section does not provide additional specification and is only here to provide examples of how this flexible approach for Diff-Serv support over MPLS may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document.
本节不提供其他规范，仅提供如何部署MPLS上区分服务支持的灵活方法的示例。针对特定环境的各种部署选项的优缺点超出了本文档的范围。
A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS Protection
A.1场景1:8（或更少）BAs，无流量工程，无MPLS保护
A Service Provider running 8 (or fewer) BAs over MPLS, not performing Traffic engineering, not using MPLS protection and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via LDP. Furthermore the Service Provider may elect to use the preconfigured `EXP<-->PHB mapping'.
通过MPLS运行8个（或更少）BAs、不执行流量工程、不使用MPLS保护和在其网络中使用MPLS垫片报头封装的服务提供商可以选择使用通过LDP建立的每个FEC的单个E-LSP通过MPLS运行区分服务。此外，服务提供商可以选择使用预配置的“EXP<-->PHB映射”。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR, the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- 服务提供商在每个LSR配置每个PHB和EXP字段值之间的双向映射（例如，000<-->AF11、001<-->AF12、010<-->AF13）
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- 服务提供商在每个LSR和每个接口上配置每个PSC的调度行为（例如，分配给AF1的带宽）和每个PHB的丢弃行为（例如，AF11、AF12、AF13的丢弃配置文件）
- LSRs signal establishment of a single E-LSP per FEC using LDP in accordance with the specification above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping)
- 根据上述规范，使用LDP为每个FEC建立单个E-LSP的LSRs信号（即，LDP标签请求/标签映射消息中没有Diff-Serv TLV，以隐式指示LSP是E-LSP且其使用预配置映射）
A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS Protection
A.2场景2：超过8个BAs，无流量工程，无MPLS保护
A Service Provider running more than 8 BAs over MPLS, not performing Traffic Engineering, not using MPLS protection and using MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS using for each FEC:
通过MPLS运行8个以上BAs、不执行流量工程、不使用MPLS保护以及在其网络中使用MPLS垫片封装的服务提供商可以选择通过MPLS为每个FEC运行区分服务：
- one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND
- 通过LDP建立一个E-LSP，并使用预配置映射来支持一组8个（或更少）BAs，以及
- one L-LSP per <FEC,OA> established via LDP for support of the other BAs.
- 通过LDP为每个<FEC，OA>建立一个L-LSP，以支持其他BAs。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs transported over the E-LSP
- 服务提供商在每个LSR配置每个PHB和通过E-LSP传输的BAs的EXP字段值之间的双向映射
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB
- 服务提供商在每个LSR和每个接口上配置E-LSP支持的每个PSC的调度行为以及每个对应PHB的丢弃行为
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB
- 服务提供商在每个LSR和每个接口上配置L-LSP支持的每个PSC的调度行为以及每个对应PHB的丢弃行为
- LSRs signal establishment of a single E-LSP per FEC for the set of E-LSP transported BAs using LDP as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping)
- LSRs信号为使用如上所述LDP传输的一组E-LSP BAs的每个FEC建立单个E-LSP（即，LDP标签请求/标签映射消息中没有Diff-Serv TLV，以隐式指示LSP是E-LSP并且它使用预配置的映射）
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other BAs using LDP as specified above (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages to indicate the L-LSP's PSC).
- 使用如上所述的LDP（即，LDP标签请求/标签映射消息中的Diff-Serv TLV，用于指示L-LSP的PSC）为另一个BAs的每个<FEC，OA>建立一个L-LSP的LSRs信号。
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, Aggregate MPLS Protection
A.3场景3:8（或更少）BAs、聚合流量工程、聚合MPLS保护
A Service Provider running 8 (or fewer) BAs over MPLS, performing aggregate Traffic Engineering (i.e., performing a single common path selection for all BAs), using aggregate MPLS protection (i.e., restoring service to all PSCs jointly) and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping.
通过MPLS运行8个（或更少）BAs的服务提供商，执行聚合流量工程（即，为所有BAs执行单个公共路径选择），使用聚合MPLS保护（即，联合将服务恢复到所有PSC），并在其网络中使用MPLS垫片头封装，可以选择使用通过RSVP[RSVP_MPLS_TE]或CR-LDP[CR-LDP_MPLS_TE]建立的每个FEC的单个E-LSP并使用预配置的映射在MPLS上运行区分服务。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- 服务提供商在每个LSR配置每个PHB和EXP字段值之间的双向映射（例如，000<-->AF11、001<-->AF12、010<-->AF13）
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13)
- 服务提供商在每个LSR和每个接口上配置每个PSC的调度行为（例如，分配给AF1的带宽）和每个PHB的丢弃行为（例如AF11、AF12、AF13的丢弃配置文件）
- LSRs signal establishment of a single E-LSP per FEC which will use the preconfigured mapping:
- 每个FEC的LSRs信号建立一个E-LSP，将使用预配置映射：
* using the RSVP protocol as specified above (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
* 使用上述指定的RSVP协议（即，包含LABEL_请求对象的路径消息中没有DIFFSERV RSVP对象），或
* using the CR-LDP protocol as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages).
* 使用如上所述的CR-LDP协议（即，LDP标签请求/标签映射消息中没有区分服务TLV）。
- protection is activated on all the E-LSPs in order to achieve MPLS protection via mechanisms outside the scope of this document.
- 在所有E-LSP上激活保护，以便通过本文档范围之外的机制实现MPLS保护。
A Service Provider running any number of BAs over MPLS, performing per-OA Traffic Engineering (i.e., performing a separate path selection for each OA) and performing per-OA MPLS protection (i.e., performing protection with potentially different levels of protection for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP.
服务提供商通过MPLS运行任意数量的BAs，在其网络中执行每个OA流量工程（即，为每个OA执行单独的路径选择）和执行每个OA MPLS保护（即，为不同OA执行具有潜在不同保护级别的保护），可以选择使用通过RSVP或CR-LDP建立的每个<FEC，OA>对的一个L-LSP在MPLS上运行区分服务。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- 服务提供商在每个LSR和每个接口上配置每个PSC的调度行为（例如，分配给AF1的带宽）和每个PHB的丢弃行为（例如，AF11、AF12、AF13的丢弃配置文件）
- LSRs signal establishment of one L-LSP per <FEC,OA>:
- 每个<FEC，OA>建立一个L-LSP的LSRs信号：
* using the RSVP as specified above to signal the L-LSP's PSC (i.e., DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR
* 使用上面指定的RSVP向L-LSP的PSC发送信号（即，包含标签请求的路径消息中的DIFFSERV RSVP对象），或
* using the CR-LDP protocol as specified above to signal the L-LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages).
* 使用如上所述的CR-LDP协议向L-LSP PSC发送信号（即LDP标签请求/标签映射消息中的Diff-Serv TLV）。
- the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection for each PSC) via mechanisms outside the scope of this document.
- 通过本文件范围外的机制，在不同的L-LSP上激活适当的保护级别（每个PSC可能具有不同的保护级别）。
A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS Protection
A.5场景5：每个OA流量工程/MPLS保护8个（或更少）BAs
A Service Provider running 8 (or fewer) BAs over MPLS, performing per-OA Traffic Engineering (i.e., performing a separate path selection for each OA) and performing per-OA MPLS protection (i.e., performing protection with potentially different levels of protection for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or CR-LDP. Furthermore, the Service Provider may elect to use the preconfigured mapping on all the E-LSPs.
通过MPLS运行8个（或更少）BAs的服务提供商，在其网络中执行每个OA流量工程（即，为每个OA执行单独的路径选择）和执行每个OA MPLS保护（即，为不同OA执行具有潜在不同保护级别的保护），可以选择使用通过RSVP或CR-LDP建立的每个<FEC，OA>对一个E-LSP在MPLS上运行区分服务。此外，服务提供商可以选择在所有E-lsp上使用预配置映射。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- 服务提供商在每个LSR配置每个PHB和EXP字段值之间的双向映射（例如，000<-->AF11、001<-->AF12、010<-->AF13）
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13)
- 服务提供商在每个LSR和每个接口上配置每个PSC的调度行为（例如，分配给AF1的带宽）和每个PHB的丢弃行为（例如AF11、AF12、AF13的丢弃配置文件）
- LSRs signal establishment of one E-LSP per <FEC,OA>:
- 每个<FEC，OA>建立一个E-LSP的LSRs信号：
* using the RSVP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR
* 使用如上所述的RSVP协议来表示LSP是使用预配置映射的E-LSP（即，在包含标签请求的路径消息中没有DIFFSERV RSVP对象），或者
* using the CR-LDP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages)
* 使用如上所述的CR-LDP协议来表示LSP是使用预配置映射的E-LSP（即，LDP标签请求/标签映射消息中没有Diff-Serv TLV）
- the Service Provider configures, for each E-LSP, at the head-end of that E-LSP, a filtering/forwarding criteria so that only the packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA.
- 服务提供商为每个E-LSP在该E-LSP的前端配置过滤/转发标准，以便在为相应FEC和相应OA建立的E-LSP上仅转发属于给定OA的分组。
- the appropriate level of protection is activated on the different E-LSPs (potentially with a different level of protection depending on the PSC actually transported over each E-LSP) via mechanisms outside the scope of this document.
- 通过本文件范围之外的机制，在不同的E-LSP上激活适当的保护级别（可能具有不同的保护级别，具体取决于每个E-LSP上实际传输的PSC）。
A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA Traffic Engineering/MPLS Protection on other BAs.
A.6场景6：8个BAs上没有流量工程/MPLS保护，其他BAs上每个OA流量工程/MPLS保护。
A Service Provider not performing Traffic Engineering/MPLS Protection on 8 (or fewer) BAs, performing per-OA Traffic Engineering/MPLS Protection on the other BAs (i.e., performing a separate path selection for each OA corresponding to the other BAs and performing MPLS Protection with a potentially different policy for each of these OA) and using the MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS, using for each FEC:
服务提供商不在8个（或更少）BAs上执行流量工程/MPLS保护，在另一个BAs上执行每个OA流量工程/MPLS保护（即，为对应于另一个BAs的每个OA执行单独的路径选择，并为这些OA中的每一个执行具有潜在不同策略的MPLS保护）并且在他/她的网络中使用MPLS垫片封装可以选择在MPLS上运行区分服务，对于每个FEC使用：
- one E-LSP using the preconfigured mapping established via LDP to support the set of 8 (or fewer) non-traffic-engineered/non-protected BAs, AND
- 一个E-LSP，使用通过LDP建立的预配置映射来支持8个（或更少）非流量工程/非保护BAs，以及
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for support of the other BAs.
- 通过RSVP或CR-LDP建立的每个<FEC，OA>对一个L-LSP，用于支持其他BAs。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs supported over the E-LSP
- 服务提供商在每个LSR配置每个PHB和E-LSP支持的BAs的EXP字段值之间的双向映射
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB
- 服务提供商在每个LSR和每个接口上配置E-LSP支持的每个PSC的调度行为以及每个对应PHB的丢弃行为
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB
- 服务提供商在每个LSR和每个接口上配置L-LSP支持的每个PSC的调度行为以及每个对应PHB的丢弃行为
- LSRs signal establishment of a single E-LSP per FEC for the non-traffic engineered BAs using LDP as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages)
- 使用如上所述的LDP（即，LDP标签请求/标签映射消息中没有区分服务TLV）为非流量工程BAs的每个FEC建立单个E-LSP的LSRs信号
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other BAs:
- 为另一个BAs的每个<FEC，OA>建立一个L-LSP的LSRs信号：
* using the RSVP protocol as specified above to signal the L-LSP PSC (i.e., DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
* 使用如上所述的RSVP协议向L-LSP PSC发送信号（即，包含LABEL_请求对象的路径消息中的DIFFSERV RSVP对象），或
* using the CR-LDP protocol as specified above to signal the L-LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages).
* 使用如上所述的CR-LDP协议向L-LSP PSC发送信号（即LDP标签请求/标签映射消息中的Diff-Serv TLV）。
- protection is not activated on the E-LSPs.
- E-LSP上的保护未激活。
- the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection depending on the L-LSP's PSC) via mechanisms outside the scope of this document.
- 通过本文件范围外的机制，在不同的L-LSP上激活适当的保护级别（可能具有不同的保护级别，具体取决于L-LSP的PSC）。
A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS Protection
A.7场景7：超过8个BAs，无流量工程，无MPLS保护
A Service Provider running more than 8 BAs over MPLS, not performing Traffic engineering, not performing MPLS protection and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using two E-LSPs per FEC established via LDP and using signaled `EXP<-->PHB mapping'.
通过MPLS运行8个以上BAs、不执行流量工程、不执行MPLS保护并在其网络中使用MPLS垫片头封装的服务提供商可以选择使用通过LDP建立的每个FEC的两个E-LSP并使用信号“EXP<-->PHB映射”在MPLS上运行区分服务。
Operations can be summarized as follows:
业务可总结如下：
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- 服务提供商在每个LSR和每个接口上配置每个PSC的调度行为（例如，分配给AF1的带宽）和每个PHB的丢弃行为（例如，AF11、AF12、AF13的丢弃配置文件）
- LSRs signal establishment of two E-LSPs per FEC using LDP in accordance with the specification above (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages to explicitly indicate that the LSP is an E-LSP and its `EXP<-->PHB mapping'). The signaled mapping will indicate the subset of 8 (or less) BAs to be transported on each E-LSP and what EXP values are mapped to each BA on each E-LSP.
- 根据上述规范，使用LDP为每个FEC建立两个E-LSP的LSRs信号（即，LDP标签请求/标签映射消息中的Diff-Serv TLV，明确指示LSP是E-LSP及其“EXP<-->PHB映射”）。信号映射将指示每个E-LSP上要传输的8个（或更少）BA的子集，以及每个E-LSP上映射到每个BA的EXP值。
APPENDIX B. Example Bandwidth Reservation Scenarios
附录B.带宽预留场景示例
Consider the case where a network administrator elects to:
考虑网络管理员选择的情况：
- have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...)
- 完全离线配置差异服务资源（例如，通过命令行界面、通过SNMP、通过COP等）
- have Shortest Path Routing used for all the Diff-Serv traffic.
- 将最短路径路由用于所有区分服务流量。
This is the closest model to provisioned Diff-Serv over non-MPLS IP. In that case, E-LSPs and/or L-LSPs would be established without signaled bandwidth.
这是最接近于通过非MPLS IP提供区分服务的模型。在这种情况下，将在没有信号带宽的情况下建立E-lsp和/或L-lsp。
Consider the case where a network administrator elects to:
考虑网络管理员选择的情况：
- have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...)
- 完全离线配置差异服务资源（例如，通过命令行界面、通过SNMP、通过COP等）
- use L-LSPs
- 使用L-LSP
- have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC.
- 为每个PSC单独执行基于约束的路由，其中一个约束是分配给相关PSC的带宽的带宽可用性。
In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to perform admission control at every hop to ensure that the constraint on availability of bandwidth for the relevant PSC is met.
在这种情况下，将使用信号带宽建立L-LSP。在L-LSP建立时发信号的带宽将被LSR用于在每个跃点执行接纳控制，以确保满足相关PSC的带宽可用性约束。
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and per-PSC Resource Adjustment
B.3场景3：每个PSC准入控制和每个PSC资源调整的带宽预留
Consider the case where a network administrator elects to:
考虑网络管理员选择的情况：
- use L-LSPs
- 使用L-LSP
- have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC.
- 为每个PSC单独执行基于约束的路由，其中一个约束是分配给相关PSC的带宽的带宽可用性。
- have Diff-Serv resources dynamically adjusted
- 动态调整区分服务资源
In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to attempt to adjust the resources allocated to the relevant PSC (e.g., scheduling weight) and then perform admission control to ensure that the constraint on availability of bandwidth for the relevant PSC is met after the adjustment.
在这种情况下，将使用信号带宽建立L-LSP。在L-LSP建立时发信号的带宽将被lsr用于尝试调整分配给相关PSC的资源（例如，调度权重），然后执行接纳控制，以确保在调整后满足对相关PSC的带宽可用性的约束。
References
工具书类
[ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e).
[ANSI/IEEE]ANSI/IEEE标准802.1D，1993年版，包括IEEE补充件P802.1p、802.1j-1996、802.6k-1992、802.11c-1998和P802.12e）。
[ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", March 1999.
[ATMF_TM]ATM论坛，“交通管理规范4.1版”，1999年3月。
[CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[CR-LDP_MPLS_TE]Jamoussi，B.，编辑，Andersson，L.，Callon，R.和R.Dantu，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[DCLASS]Bernet，Y.，“RSVP DCLASS对象的格式”，RFC 2996，2000年11月。
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[DIFF_AF]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DIFF_ARCH]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[DIFF_EF]Davie，B.，Charny，A.，Baker，F.，Bennet，J.，Benson，K.，Boudec，J.，Chiu，A.，Courtney，W.，Davari，S.，Firoiu，V.，Kalmanek，C.，Ramakrishnam，K.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[DIFF_HEADER] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[DIFF_HEADER]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[DIFF_NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[DIFF_NEW]Grossman，D.，“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[DIFF_TUNNEL]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[ECN]Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加明确拥塞通知（ECN）”，RFC 3168，2001年9月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98.
[IEEE_802.1]ISO/IEC 15802-3:1998 ANSI/IEEE Std 802.1D，1998版（ISO/IEC 10038:98的修订和重新命名）。
[LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，D.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS_ARCH]Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 3031，2001年1月。
[MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS_ATM]Davie，B.，Lawrence，J.，McCloghrie，K.，Rosen，E.，Swallow，G.，Rekhter，Y.和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[MPLS_ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS_ENCAPS]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[MPLS_FR] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS_FR]Conta，A.，Doolan，P.和A.Malis，“帧中继网络上标签切换的使用规范”，RFC 3034，2001年1月。
[MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
[MPLS_VPN]Rosen，E.，“BGP/MPLS VPN”，工作正在进行中。
[NULL] Bernet, Y., Smith, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[NULL]Bernet，Y.，Smith，A.和B.Davie，“NULL服务类型的规范”，RFC 2997，2000年11月。
[PHBID] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes" RFC 3140, June 2001.
[PHBID]Black，D.，Brim，S.，Carpenter，B.和F.Le Faucheur，“每跳行为识别码”RFC 31402001年6月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-第1版功能规范”，RFC 22052997年9月。
[RSVP_MPLS_TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP_MPLS_TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
Francois Le Faucheur Cisco Systems Village d'Enterprise Green Side-法国索菲亚安提波利斯大道06410号T3400巴蒂门特酒店
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA
吴立文思科系统美国加利福尼亚州圣何塞市思科路3550号，邮编95134
Phone: +1 (408) 853-4065
EMail: liwwu@cisco.com
Phone: +1 (408) 853-4065
EMail: liwwu@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA
布鲁斯·戴维斯思科系统美国马萨诸塞州切姆斯福德阿波罗大道250号01824
Phone: +1 (978) 244-8000
EMail: bsd@cisco.com
Phone: +1 (978) 244-8000
EMail: bsd@cisco.com
Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada
加拿大安大略省卡纳塔Legget Drive 411号Shahram Davari PMC Sierra Inc.K2K 3C9
Phone: +1 (613) 271-4018
EMail: davari@ieee.org
Phone: +1 (613) 271-4018
EMail: davari@ieee.org
Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA
Pasi VAANANANEN诺基亚3伯灵顿伍兹路，西服250伯灵顿，马萨诸塞州01803
Phone +1 (781) 993-4900 EMail: pasi.vaananen@nokia.com
电话+1（781）993-4900电子邮件：pasi。vaananen@nokia.com
Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro, MA 01752
马萨诸塞州万宝路尼克松路200号Ram Krishnan Axiowave Networks 01752
EMail: ram@axiowave.com
EMail: ram@axiowave.com
Pierrick Cheval Alcatel 5 rue Noel-Pons 92737 Nanterre Cedex France EMail: pierrick.cheval@space.alcatel.fr
Pierrick Cheval Alcatel 5 rue Noel Pons 92737 Nanterre Cedex France电子邮件：Pierrick。cheval@space.alcatel.fr
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
Juha Heinanen Song Networks，Inc.Hallituskatu 16 33200坦佩雷，芬兰
EMail: jh@song.fi
EMail: jh@song.fi
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编辑功能的资金目前由互联网协会提供。