[要約] RFC 5455は、パス計算要素通信プロトコルのためのDiffserv-Aware Class-Typeオブジェクトに関する仕様です。このRFCの目的は、ネットワークの品質サービス（QoS）を考慮した経路計算を可能にするためのオブジェクトの定義と使用方法を提供することです。
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
パス計算要素通信プロトコル用のdiffserv-awareクラスタイプオブジェクト
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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).
このドキュメントは、PATH計算要素（PCE）を使用してパス計算が実行されるDiffServ-Aware Traffic Engineering（DS-TE）をサポートするClasStypeオブジェクトを指定します。
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
[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]は、[RFC4657]に準拠して、パス計算クライアント（PCC）とパス計算要素（PCC）、または2つのPCES間の通信のパス計算要素通信プロトコル（PCEP）を指定します。
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.
Diffserv-aware MPLSトラフィックエンジニアリング（DS-TE）は、さまざまなクラスのトラフィックのさまざまな帯域幅の制約を実施できるようにするための基本的な要件に対処します。さまざまなクラスで帯域幅の制約（BCS）を実施することにより、すべてのクラスで総合的なベースではなく、クラスごとの交通工学を達成するメカニズムを説明しています。DS-TEおよび関連するプロトコル拡張の要件は、それぞれ[RFC3564]および[RFC4124]で指定されています。
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.
このドキュメントでは、Path LSPのクラスタイプをパス計算リクエストに搭載したClasStypeと呼ばれる新しいPCEPオブジェクトを定義します。パス計算中、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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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：Diffserv-Aware Traffic Engineering。
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
LSP: Label Switched Path.
LSP：ラベルスイッチ付きパス。
PCC (Path Computation Client): any client application requesting a path computation to be performed by a Path Computation Element.
PCC（Path Computation Client）：パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
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（PATH計算要素）：ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
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-Class：クラスタイプとそのクラスタイプに許可される先制の優先度で構成されるペア。そのクラスタイプからトラフィックトランクを輸送する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.
トラフィックトランク：同じクラスのトラフィックフローの集約（つまり、DS-TEの観点から同等に扱われます）。これは、TE LSP内に配置されます。
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 path computation request MUST NOT contain the CLASSTYPE object. This allows backward compatibility with a PCE that does not support the CLASSTYPE object.
ClasStypeオブジェクトはオプションであり、TE LSPのクラスタイプを指定するために使用されます。このオブジェクトは、Path Computation Request内でのみ意味があり、Path Replyメッセージで無視されます。パスが計算されるTE LSPがクラス0に属している場合、パス計算要求には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オブジェクトには、図1に示すように、[RFC5440]で定義された32ビットWord PCEP共通オブジェクトヘッダーが含まれ、さらに32ビットの単語オブジェクト本体が含まれます。
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：Classtypeオブジェクト形式
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です。含まれている場合、ClasStypeオブジェクトをPCEによって考慮する必要があります。そのため、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: The format of a Path Computation Request (PCReq) message is as follows:
[RFC5440]は、PCEPメッセージにオブジェクトを挿入する必要がある順序を指定します。このドキュメントは、以下に示すように、endopintオブジェクトの後にclasstypeオブジェクトを挿入することを指定します。パス計算要求（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>]
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フォームを使用して指定されたオブジェクト順序ルールを使用して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には、clasStypeオブジェクトをPCREQメッセージにclasStypeオブジェクトに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.
パス計算要求に複数のClasStypeオブジェクトが含まれている場合、最初のオブジェクトのみが意味があります。後続のclasstypeオブジェクトは無視する必要があり、転送しないでください。
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オブジェクトがPATH計算要求メッセージに存在しない場合、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.
パス計算応答メッセージには、ClasStypeオブジェクトを含めてはなりません。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メッセージ全体を拒否し、[RFC5440]で定義されているエラー型= "不明オブジェクト"または「サポートされていないオブジェクト」を使用してPCEエラーメッセージを送信する必要があります。
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オブジェクトを認識しますが、PフラグがClasStypeオブジェクトに設定されていないことがわかります。[RFC5440]で指定されたエラータイプとエラー値を使用して、送信者にPCEエラーメッセージを送信する必要があります。
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は、エラータイプ「Diffserv-Aware TEエラー」と「サポートされていないクラスタイプ」のエラー値を持つPCEエラーメッセージを送信者に送信する必要があります（サポートされていないクラスタイプ」（エラー値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).
clasStypeオブジェクトを認識しますが、クラスタイプの値が有効でないこと（つまり、クラスタイプの値0）を決定するPCEは、エラータイプ「diffserv-aware teエラー」とエラータイプで送信者にPCEエラーを送信する必要があります。「無効なクラスタイプ」のエラー値（エラー値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-Class）への先制優先マップマップがあり、最大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 diffserv-aware TEエラーエラー値= 1：サポートされていないクラスタイプエラー値= 2：無効なクラスタイプエラー値= 3：クラスタイプとセットアップの優先順位
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
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 Diffserv-Aware 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.
著者は、Jean Philippe Vasseur、Adrian Farrel、およびZafar Aliの貴重なコメントに感謝したいと思います。
[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.、ed。、「Diffserv-Aware MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張」、RFC 4124、2005年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 5440、2009年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。、「Path Computation Element（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）の縮小バックナウルフォーム（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
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
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA
Sami Boutros Cisco Systems、Inc。3750 Cisco Way San Jose、California 95134 USA
EMail: sboutros@cisco.com
Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN
Kenji Kumaki Kddi R＆D Laboratories、Inc。2-1-15 Ohara Fujimino Saitama 356-8502、日本
EMail: ke-kumaki@kddi.com