Network Working Group S. Sivabalan, Ed.
Request for Comments: 5455 J. Parker
Category: Standards Track S. Boutros
Cisco Systems, Inc.
K. Kumaki
KDDI R&D Laboratories, Inc.
March 2009
Network Working Group S. Sivabalan, Ed.
Request for Comments: 5455 J. Parker
Category: Standards Track S. Boutros
Cisco Systems, Inc.
K. Kumaki
KDDI R&D Laboratories, Inc.
March 2009
Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol
路径计算元素通信协议的区分服务感知类类型对象
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE).
本文档指定一个类类型对象来支持区分服务感知流量工程（DS-TE），其中路径计算是在路径计算元素（PCE）的帮助下执行的。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Terminology .....................................................3
3. CLASSTYPE Object ................................................3
3.1. Object Definition ..........................................4
3.2. Path Computation Request Message with CLASSTYPE Object .....4
3.3. Processing CLASSTYPE Object ................................5
3.4. Determination of Traffic Engineering Class (TE-Class) ......6
3.5. Significance of Class-Type and TE-Class ....................6
3.6. Error Codes for CLASSTYPE Object ...........................6
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. Acknowledgments .................................................7
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Terminology .....................................................3
3. CLASSTYPE Object ................................................3
3.1. Object Definition ..........................................4
3.2. Path Computation Request Message with CLASSTYPE Object .....4
3.3. Processing CLASSTYPE Object ................................5
3.4. Determination of Traffic Engineering Class (TE-Class) ......6
3.5. Significance of Class-Type and TE-Class ....................6
3.6. Error Codes for CLASSTYPE Object ...........................6
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. Acknowledgments .................................................7
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
[RFC5440] specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs, in compliance with [RFC4657].
[RFC5440]指定路径计算元素通信协议（PCEP），用于路径计算客户端（PCC）和路径计算元素（PCE）之间或两个PCE之间的通信，符合[RFC4657]。
Diffserv-aware MPLS Traffic Engineering (DS-TE) addresses the fundamental requirement to be able to enforce different bandwidth constraints for different classes of traffic. It describes mechanisms to achieve per-class traffic engineering, rather than on an aggregate basis across all classes by enforcing Bandwidth Constraints (BCs) on different classes. Requirements for DS-TE and the associated protocol extensions are specified in [RFC3564] and [RFC4124], respectively.
区分服务感知MPLS流量工程（DS-TE）解决了能够对不同类别的流量实施不同带宽约束的基本要求。它描述了实现每类流量工程的机制，而不是通过在不同的类上强制实施带宽约束（BCs）来在所有类之间进行聚合。[RFC3564]和[RFC4124]分别规定了DS-TE和相关协议扩展的要求。
As per [RFC4657], PCEP must support traffic Class-Type as an MPLS-TE-specific constraint. However, in the present form, PCEP [RFC5440] does not have the capability to specify the Class-Type in the path computation request.
根据[RFC4657]，PCEP必须支持作为MPLS TE特定约束的流量类类型。然而，在当前形式中，PCEP[RFC5440]不具有在路径计算请求中指定类类型的能力。
In this document, we define a new PCEP object called CLASSTYPE, which carries the Class-Type of the TE LSP in the path computation request. During path computation, a PCE uses the Class-Type to identify the bandwidth constraint of the TE LSP.
在本文中，我们定义了一个名为CLASSTYPE的新PCEP对象，它在路径计算请求中携带TE LSP的类类型。在路径计算期间，PCE使用类类型来识别TE LSP的带宽约束。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
CT (Class-Type): A set of Traffic Trunks governed by a set of bandwidth constraints. Used for the purpose of link bandwidth allocation, constraint-based routing and admission control. A given Traffic Trunk belongs to the same CT on all links.
CT（类类型）：由一组带宽约束控制的一组交通干线。用于链路带宽分配、基于约束的路由和准入控制。给定的交通干线在所有链路上属于同一个CT。
DS-TE: Diffserv-Aware Traffic Engineering.
DS-TE：区分服务感知流量工程。
LSR: Label Switching Router.
标签交换路由器。
LSP: Label Switched Path.
标签交换路径。
PCC (Path Computation Client): any client application requesting a path computation to be performed by a Path Computation Element.
PCC（路径计算客户端）：任何请求路径计算元素执行路径计算的客户端应用程序。
PCE (Path Computation Element): an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE（路径计算元素）：能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCEP Peer: an element involved in a PCEP session (i.e., a PCC or the PCE).
PCEP对等方：参与PCEP会话的元素（即PCC或PCE）。
TE-Class: A pair consisting of a Class-Type and a preemption priority allowed for that Class-Type. An LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the setup priority, the holding priority, or both.
TE类：由类类型和该类类型允许的抢占优先级组成的一对。从该类类型传输业务中继的LSP可以使用该抢占优先级作为设置优先级、保留优先级或两者。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
Traffic Trunk: An aggregation of traffic flows of the same class (i.e., treated equivalently from the DS-TE perspective), which is placed inside a TE LSP.
交通干线：位于TE LSP内的同一类交通流的集合（即，从DS-TE角度等效处理）。
The CLASSTYPE object is optional and is used to specify the Class-Type of a TE LSP. This object is meaningful only within the path computation request, and is ignored in the path reply message. If the TE LSP for which the path is to be computed belongs to Class 0, the
CLASSTYPE对象是可选的，用于指定TE LSP的类类型。此对象仅在路径计算请求中有意义，在路径回复消息中被忽略。如果要为其计算路径的TE LSP属于类0，则
path computation request MUST NOT contain the CLASSTYPE object. This allows backward compatibility with a PCE that does not support the CLASSTYPE object.
路径计算请求不能包含CLASSTYPE对象。这允许向后兼容不支持CLASSTYPE对象的PCE。
The CLASSTYPE object contains a 32-bit word PCEP common object header defined in [RFC5440] followed by another 32-bit word object body as shown in Figure 1.
CLASSTYPE对象包含一个在[RFC5440]中定义的32位字PCEP公共对象头，后跟另一个32位字对象体，如图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP common header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP common header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: CLASSTYPE object format
图1：类类型对象格式
The fields in the common object header are processed as specified in [RFC5440]. The values of object class and object type are 22 and 1, respectively. If included, the CLASSTYPE object must be taken into account by the PCE. As such, the P flag MUST be set. The I flag is ignored.
公共对象标头中的字段按照[RFC5440]中的规定进行处理。对象类和对象类型的值分别为22和1。如果包含，PCE必须考虑CLASSTYPE对象。因此，必须设置P标志。I标志被忽略。
The CLASSTYPE object body contains the following fields:
CLASSTYPE对象主体包含以下字段：
CT: 3-bit field that indicates the Class-Type. Values allowed are 1, 2, ... , 7. The value of 0 is Reserved.
CT：表示类类型的3位字段。允许的值为1，2，7.0的值是保留的。
Reserved: 29-bit reserved field. It MUST be set to zero on transmission and MUST be ignored on receipt.
保留：29位保留字段。传输时必须将其设置为零，接收时必须忽略。
[RFC5440] specifies the order in which objects must be inserted in the PCEP messages. This document specifies that the CLASSTYPE object be inserted after the END-POINT objects as shown below:
[RFC5440]指定对象必须插入PCEP消息的顺序。本文档指定在端点对象之后插入CLASSTYPE对象，如下所示：
The format of a Path Computation Request (PCReq) message is as follows:
路径计算请求（PCReq）消息的格式如下：
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<CLASSTYPE>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<CLASSTYPE>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
Note that an implementation MUST form the PCEP messages using the object ordering rules specified using Backus-Naur Form. Please refer to [OBJ-ORD] for more details.
注意，实现必须使用使用Backus Naur form指定的对象排序规则来形成PCEP消息。有关更多详细信息，请参阅[OBJ-ORD]。
If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC originating the PCReq MUST include the CLASSTYPE object in the PCReq message with the Class-Type (CT) field set to N.
如果LSP与类别类型N（1<=N<=7）关联，则发起PCReq的PCC必须在PCReq消息中包含类别类型对象，类别类型（CT）字段设置为N。
If a path computation request contains multiple CLASSTYPE objects, only the first one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and MUST NOT be forwarded.
如果路径计算请求包含多个类类型对象，则只有第一个有意义；必须忽略后续类类型对象，并且不得转发。
If the CLASSTYPE object is not present in the path computation request message, the LSR MUST associate the Class-Type 0 to the LSP.
如果路径计算请求消息中不存在CLASSTYPE对象，则LSR必须将类类型0与LSP关联。
A path computation reply message MUST NOT include a CLASSTYPE object. If a PCE needs to forward a path computation request containing the CLASSTYPE object to another PCE, it MUST store the Class-Type of the TE LSP in order to complete the path computation when the path computation reply arrives.
路径计算回复消息不得包含类类型对象。如果一个PCE需要将包含CLASSTYPE对象的路径计算请求转发给另一个PCE，它必须存储TE LSP的类类型，以便在路径计算应答到达时完成路径计算。
A PCE that does not recognize the CLASSTYPE object MUST reject the entire PCEP message and MUST send a PCE error message with Error-Type="Unknown Object" or "Not supported object", defined in [RFC5440].
不识别CLASSTYPE对象的PCE必须拒绝整个PCEP消息，并且必须发送PCE错误消息，错误类型为[RFC5440]中定义的“未知对象”或“不支持对象”。
A PCE that recognizes the CLASSTYPE object, but finds that the P flag is not set in the CLASSTYPE object, MUST send PCE error message towards the sender with the error type and error value specified in [RFC5440].
识别CLASSTYPE对象但发现CLASSTYPE对象中未设置P标志的PCE必须向发送方发送PCE错误消息，错误类型和错误值在[RFC5440]中指定。
A PCE that recognizes the CLASSTYPE object, but does not support the particular Class-Type, MUST send a PCE error message towards the sender with the error type "Diffserv-aware TE error" and the error value of "Unsupported Class-Type" (Error-value 1).
识别CLASSTYPE对象但不支持特定类类型的PCE必须向发送方发送PCE错误消息，错误类型为“Diffserv aware TE error”，错误值为“Unsupported Class Type”（错误值1）。
A PCE that recognizes the CLASSTYPE object, but determines that the Class-Type value is not valid (i.e., Class-Type value 0), MUST send a PCE error towards the sender with the error type "Diffserv-aware TE error" and an error value of "Invalid Class-Type" (Error-value 2).
识别类类型对象但确定类类型值无效（即类类型值0）的PCE必须向发送方发送PCE错误，错误类型为“Diffserv aware TE error”，错误值为“Invalid Class Type”（错误值2）。
As specified in RFC 4124, a CT and a preemption priority map to a Traffic Engineering Class (TE-class), and there can be up to 8 TE-classes. The TE-class value is used to determine the unreserved bandwidth on the links during path computation. In the case of a PCE, the CT value carried in the CLASSTYPE object and the setup priority in the LSP Attribute (LSPA) object are used to determine the TE-class corresponding to the path computation request. If the LSPA object is absent, the setup priority is assumed to be 0.
按照RFC 4124的规定，CT和抢占优先级映射到流量工程类（TE类），最多可以有8个TE类。TE类值用于确定路径计算期间链路上的无保留带宽。在PCE的情况下，CLASSTYPE对象中携带的CT值和LSP属性（LSPA）对象中的设置优先级用于确定与路径计算请求相对应的TE类。如果缺少LSPA对象，则假定设置优先级为0。
To ensure coherent DS-TE operation, a PCE and a PCC should have a common understanding of a particular DS-TE Class-Type and TE-class. If a path computation request crosses an Autonomous System (AS) boundary, these should have global significance in all domains. Enforcement of this global significance is outside the scope of this document.
为了确保一致的DS-TE操作，PCE和PCC应该对特定的DS-TE类类型和TE类有共同的理解。如果路径计算请求跨越自治系统（AS）边界，则这些请求在所有域中都应具有全局意义。这一全球意义的实施不在本文件的范围之内。
This document defines the following error type and values:
本文档定义了以下错误类型和值：
Error-Type Meaning
错误类型含义
12 Diffserv-aware TE error Error-value=1: Unsupported Class-Type Error-value=2: Invalid Class-Type Error-value=3: Class-Type and setup priority do not form a configured TE-class
12区分服务感知TE错误值=1:不支持的类类型错误值=2:无效的类类型错误值=3:类类型和设置优先级不构成配置的TE类
This document does not introduce new security issues. The security considerations pertaining to PCEP [RFC5440] remain relevant.
本文档不会引入新的安全问题。与PCEP[RFC5440]相关的安全注意事项仍然相关。
IANA maintains a registry of parameters for PCEP. This contains a sub-registry for PCEP objects. IANA has made allocations from this registry as follows:
IANA维护PCEP的参数注册表。它包含PCEP对象的子注册表。IANA已从该注册中心进行了如下分配：
Object-Class Name Reference
对象类名引用
22 CLASSTYPE RFC 5455
22类类型RFC 5455
Object-Type
对象类型
1: Class-Type RFC 5455
1：类别类型RFC 5455
IANA has allocated error types and values as follows:
IANA已按如下方式分配错误类型和值：
Error-Type Meaning Reference
错误类型含义引用
12 Diffserv-aware TE error RFC 5455
12区分服务感知TE错误RFC 5455
Error-value = 1: RFC 5455
错误值=1:RFC 5455
Unsupported Class-Type
不支持的类类型
Error-value = 2: RFC 5455
错误值=2:RFC 5455
Invalid Class-Type
无效的类类型
Error-value = 3: RFC 5455
错误值=3:RFC 5455
Class-Type and setup priority do not form a configured TE-class
类类型和设置优先级不构成配置的TE类
The authors would like to thank Jean Philippe Vasseur, Adrian Farrel, and Zafar Ali for their valuable comments.
作者要感谢让·菲利普·瓦塞尔、阿德里安·法雷尔和扎法尔·阿里的宝贵评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 41242005年6月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC3564]Le Faucheur，F.和W.Lai，“支持区分服务的MPLS流量工程的要求”，RFC 3564，2003年7月。
[OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
[OBJ-ORD]Farrel，A.，“简化的巴科斯-诺尔形式（RBNF）一种用于各种协议规范的语法”，正在进行的工作，2008年11月。
Authors' Addresses
作者地址
Siva Sivabalan (editor) Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
Siva Sivabalan（编辑）Cisco Systems，Inc.2000创新大道加拿大安大略省卡纳塔市K2K 3E8
EMail: msiva@cisco.com
EMail: msiva@cisco.com
Jon Parker Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
Jon Parker Cisco Systems，Inc.加拿大安大略省卡纳塔市创新大道2000号，K2K 3E8
EMail: jdparker@cisco.com
EMail: jdparker@cisco.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134
EMail: sboutros@cisco.com
EMail: sboutros@cisco.com
Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN
Kenji Kumaki KDDI研发实验室有限公司2-1-15 Ohara Fujimino Saitama 356-8502，日本
EMail: ke-kumaki@kddi.com
EMail: ke-kumaki@kddi.com