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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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).
この文書では、経路計算は、経路計算エレメント（PCE）の助けを借りて行われたDiffserv-Awareのトラフィックエンジニアリング（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）とパス計算要素（PCE）、又は二のPCE間の間の通信のためのパス計算エレメント通信プロトコル（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の対応の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.
この文書では、我々は、経路計算要求にTE 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のトラフィックエンジニアリング。
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（パス計算クライアント）：経路計算を要求するすべてのクライアントアプリケーションは、パス計算要素によって実行されます。
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 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のクラスタイプを指定するために使用されます。このオブジェクトは、経路計算要求内に有意義であり、経路応答メッセージでは無視されます。経路が計算されるべき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.
図1に示すようにするClassTypeオブジェクトは、別の32ビットワードオブジェクト本体続い[RFC5440]で定義された32ビットワードPCEP共通のオブジェクトヘッダーを含んでいます。
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:
[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>]
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.
実装はバッカス記法を使用して、指定したオブジェクトの順序付け規則を使用して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はNに設定さクラスタイプ（CT）フィールドとPCReqメッセージにするClassTypeオブジェクトを含まなければなりません
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オブジェクトが経路計算要求メッセージに存在しない場合、LSRは、LSPのクラスタイプ0を関連付ける必要があります。
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は、他のPCEにするClassTypeオブジェクトを含むパス計算要求を転送する必要がある場合は、経路計算応答が到着したときに経路計算を完了するために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].
全体PCEPメッセージを拒絶しなければなりませんするClassTypeオブジェクトを認識しないと、[RFC5440]で定義されたエラー・タイプ=「未知のオブジェクト」または「サポートされていませんオブジェクト」、とPCEのエラーメッセージを送らなければなりません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オブジェクトに設定されていないことを検出PCEは、[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を意識した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オブジェクトを認識しますが、クラス型の値が有効でないと判断したPCEは（すなわち、クラス-Type値0）は、エラーの種類「のDiffservを意識した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-クラス）への先取り優先順位マップは、8 TE-クラスまでがあることができます。 TEクラス値が経路計算の間のリンク上で予約されていない帯域幅を決定するために使用されます。 PCEの場合には、LSP属性（LSPA）対象にするClassTypeオブジェクトと設定優先で運ばCT値は、経路計算要求に対応する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対応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のClassTypeのRFC 5455
Object-Type
OBJECT-TYPE
1: Class-Type RFC 5455
クラス型RFC 5455：1
IANA has allocated error types and values as follows:
次のようにIANAは、エラーの種類と値を割り当てました。
Error-Type Meaning Reference
エラー・タイプ意味リファレンス
12 Diffserv-aware TE error RFC 5455
12のDiffserv対応の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.
作者は彼らの貴重なコメントのためにジャン・フィリップVasseur、エードリアンファレル、およびZafarアリに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ルFaucheur、F.、エド。、 "Diffservの認識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。、編、およびJL。ル・ルー、エド。、 "パス計算要素（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]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（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]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識した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]ファレル、A.、「削減バッカス記法（RBNF）各種プロトコル仕様書で使用される構文」、進歩、2008年11月の作業。
Authors' Addresses
著者のアドレス
Siva Sivabalan (editor) Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
シヴァシババラン（エディタ）は、シスコシステムズ、株式会社2000年イノベーションドライブカナタ、オンタリオ、K2K 3E8カナダ
EMail: msiva@cisco.com
メールアドレス：msiva@cisco.com
Jon Parker Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
ジョン・パーカーシスコシステムズ株式会社2000年イノベーションドライブカナタ、オンタリオ、K2K 3E8カナダ
EMail: jdparker@cisco.com
メールアドレス：jdparker@cisco.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA
サミBoutrosシスコシステムズ株式会社3750シスコウェイサンノゼ、カリフォルニア95134 USA
EMail: sboutros@cisco.com
メールアドレス：sboutros@cisco.com
Kenji Kumaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN
けんじ くまき Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ、 いんｃ。 ２ー１ー１５ おはら ふじみの さいたま ３５６ー８５０２、 じゃぱん
EMail: ke-kumaki@kddi.com
メールアドレス：ke-kumaki@kddi.com