Network Working Group H. Ould-Brahim
Request for Comments: 5543 Nortel Networks
Category: Standards Track D. Fedyk
Alcatel-Lucent
Y. Rekhter
Juniper Networks
May 2009
BGP Traffic Engineering Attribute
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.
この文書では、トラフィックエンジニアリング情報を運ぶためにBGPを可能にする新しいBGP属性、トラフィックエンジニアリング属性を定義します。
The scope and applicability of this attribute currently excludes its use for non-VPN reachability information.
この属性の範囲および適用可能性は、現在、非VPN到達可能性情報については、その使用を排除します。
In certain cases (e.g., Layer-1 VPNs (L1VPNs) [RFC5195]), it may be useful to augment the VPN reachability information carried in BGP with Traffic Engineering information.
特定の場合（例えば、レイヤ1のVPN（L1VPNs）[RFC5195]）には、トラフィックエンジニアリング情報とBGPで運ばVPN到達可能性情報を増強するのに有用であり得ます。
This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP [RFC4271] to carry Traffic Engineering information.
この文書では、BGP [RFC4271]はトラフィックエンジニアリング情報を運ぶためにできる新しいBGP属性、トラフィックエンジニアリング属性を定義します。
Section 4 of [RFC5195] describes one possible usage of this attribute.
[RFC5195]のセクション4は、この属性の一つの可能な使用法を説明します。
The scope and applicability of this attribute currently excludes its use for non-VPN reachability information.
この属性の範囲および適用可能性は、現在、非VPN到達可能性情報については、その使用を排除します。
Procedures for modifying the Traffic Engineering attribute, when re-advertising a route that carries such an attribute, are outside the scope of this document.
そのような属性を運ぶルートを再アドバタイズするとき、トラフィックエンジニアリング属性を変更するための手順は、この文書の範囲外です。
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]に記載されているように解釈されます。
The Traffic Engineering attribute is an optional, non-transitive BGP attribute.
トラフィックエンジニアリング属性はオプションで、非推移BGP属性です。
The information carried in this attribute is identical to what is carried in the Interface Switching Capability Descriptor, as specified in [RFC4203] and [RFC5307].
[RFC4203]と[RFC5307]で指定されるこの属性で運ばれた情報は、能力記述子を切り替えるインタフェースで運ばれているものと同じです。
The attribute contains one or more of the following:
属性は、以下の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Switching Capability (Switching Cap) field contains one of the values specified in Section 3.1.1 of [RFC3471].
スイッチング能力（キャップをスイッチング）フィールドは、[RFC3471]のセクション3.1.1で指定された値のいずれかを含有します。
The Encoding field contains one of the values specified in Section 3.1.1 of [RFC3471].
Encodingフィールドは、[RFC3471]のセクション3.1.1で指定された値のいずれかを含有します。
The Reserved field SHOULD be set to 0 on transmit and MUST be ignored on receive.
予約フィールドは、送信時に0に設定する必要があり、受信時に無視しなければなりません。
Maximum LSP (Label Switched Path) Bandwidth is encoded as a list of eight 4-octet fields in the IEEE floating point format [IEEE], with priority 0 first and priority 7 last. The units are bytes (not bits!) per second.
最大LSP（ラベルスイッチパス）の帯域幅は、最後の優先順位0最初の優先7と、IEEE浮動小数点形式[IEEE]の8つの4オクテットフィールドのリストとしてエンコードされます。単位はバイト（ビットではない！）毎秒です。
The content of the Switching Capability specific information field depends on the value of the Switching Capability field.
スイッチング機能、特定の情報フィールドの内容は、スイッチング機能フィールドの値に依存します。
When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the Switching Capability specific information field includes Minimum LSP Bandwidth and Interface MTU.
スイッチング機能フィールドは、PSC-1、PSC-2、PSC-3、またはPSC-4である場合、スイッチング能力特定情報フィールドは、最小LSP帯域幅とインターフェイスMTUを含みます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE floating point format. The units are bytes (not bits!) per second. Interface MTU is encoded as a 2-octet integer.
最小のLSP帯域幅は、IEEE浮動小数点形式の4オクテットフィールドに符号化されます。単位はバイト（ビットではない！）毎秒です。インターフェイスMTUは、2オクテットの整数として符号化されます。
When the Switching Capability field is Layer-2 Switch Capable (L2SC), there is no Switching Capability specific information field present.
スイッチング機能フィールドは対応レイヤ2スイッチ（L2SC）のとき、スイッチング機能、特定の情報フィールドが存在しません。
When the Switching Capability field is Time-Division-Multiplex (TDM) capable, the Switching Capability specific information field includes Minimum LSP Bandwidth and an indication of whether the interface supports Standard or Arbitrary SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy).
スイッチング機能フィールドは、可能な時分割多重（TDM）である場合、スイッチング能力特定情報フィールドは、最小LSP帯域幅とインターフェイス標準または任意のSONET / SDH（同期光ネットワーク/同期デジタルハイアラーキ）をサポートしているかどうかの指示を含みます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indication |
+-+-+-+-+-+-+-+-+
Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE floating point format. The units are bytes (not bits!) per second. The indication of whether the interface supports Standard or Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the interface supports Standard SONET/SDH, and 1 if the interface supports Arbitrary SONET/SDH.
最小のLSP帯域幅は、IEEE浮動小数点形式の4オクテットフィールドに符号化されます。単位はバイト（ビットではない！）毎秒です。インターフェース標準または任意のSONET / SDHをサポートしているかどうかの表示は1つのオクテットとして符号化されます。インタフェースは、任意のSONET / SDHをサポートしている場合、インターフェースは、標準SONET / SDHをサポートしており、1場合は、このオクテットの値は0です。
When the Switching Capability field is Lambda Switch Capable (LSC), there is no Switching Capability specific information field present.
スイッチング機能フィールドは対応ラムダ・スイッチ（LSC）のとき、スイッチング機能、特定の情報フィールドが存在しません。
Routes that carry the Traffic Engineering attribute have additional semantics that could affect traffic-forwarding behavior. Therefore, such routes SHALL NOT be aggregated unless they share identical Traffic Engineering attributes.
トラフィックエンジニアリングを運ぶルートはトラフィックフォワーディングの動作に影響を与える可能性があり、追加のセマンティクスを持つ属性。彼らは同じトラフィックエンジニアリング属性を共有しない限り、したがって、このようなルートが集約されないものとします。
Constructing the Traffic Engineering attribute when aggregating routes with identical Traffic Engineering attributes follows the procedure of [RFC4201].
同じトラフィックエンジニアリングでルートを集約するとき属性トラフィックエンジニアリング属性を構築することは、[RFC4201]の手順に従います。
The use of the Traffic Engineering attribute does not increase the number of routes, but may increase the number of BGP Update messages required to distribute the routes, depending on whether or not these routes share the same BGP Traffic Engineering attribute (see below).
トラフィックエンジニアリング属性を使用すると、ルートの数を増加させないが、これらのルートは（下記参照）と同じBGPトラフィックエンジニアリング属性を共有しているか否かに応じて、ルートを配布するために必要なBGPアップデートメッセージの数を増大させることができます。
When the routes differ other than in the Traffic Engineering attribute (e.g., differ in the set of Route Targets and/or NEXT_HOP), use of the Traffic Engineering attribute has no impact on the number of BGP Update messages required to carry the routes. There is also no impact when routes share all other attribute information and have an aggregated or identical Traffic Engineering attribute. When routes share all other attribute information and have different Traffic Engineering attributes, routes must be distributed in per-route BGP Update messages, rather than in a single message.
ルートは、トラフィックエンジニアリング属性以外異なる場合、トラヒックエンジニアリングの使用は、ルートを運ぶために必要なBGPアップデートメッセージの数に影響を与えない属性（例えば、ルートターゲット及び/又はNEXT_HOPのセットが異なります）。ルートが他のすべての属性情報を共有し、集約または同一のトラフィックエンジニアリング属性を持っている何の影響もありません。ルートが他のすべての属性情報を共有し、異なるトラフィックエンジニアリング属性を持っている場合は、ルートがなく、1つのメッセージに比べ、単位のルートBGP更新メッセージに配布されなければなりません。
This document defines a new BGP attribute, Traffic Engineering. This attribute is optional and non-transitive.
この文書は、新しいBGP属性、トラフィックエンジニアリングを定義します。この属性はオプションであり、非推移です。
This extension to BGP does not change the underlying security issues currently inherent in BGP. BGP security considerations are discussed in RFC 4271.
BGPへのこの拡張は、BGPで現在固有の基本的なセキュリティ問題を変更しません。 BGPのセキュリティに関する考慮事項は、RFC 4271で説明されています。
The authors would like to thank John Scudder and Jeffrey Haas for their review and comments.
作者は彼らのレビューとコメントのためにジョン・スカダーとジェフリー・ハースに感謝したいと思います。
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
[IEEE] IEEE、 "2進浮動小数点演算のためのIEEE規格"、スタンダード754-1985、1985（ISBN 1-5593-7653-8）。
[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月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]ウルド - Brahimの、H.、Fedyk、D.、およびY. Rekhter、 "BGPベースの自動検出のためのレイヤ1のVPN"、RFC 5195、2008年6月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、エド。、およびY. Rekhter、エド。、 "IS-ISの拡張一般化マルチプロトコルラベルスイッチング（GMPLS）の支援で"、RFC 5307、2008年10月。
Authors' Addresses
著者のアドレス
Hamid Ould-Brahim Nortel Networks EMail: hbrahim@nortel.com
ハミド・ウルド・BrahimのNortel NetworksのEメール：hbrahim@nortel.com
Don Fedyk Alcatel-Lucent EMail: donald.fedyk@alcatel-lucent.com Phone: 978-467-5645
ドン・ルブランアルカテル・ルーセントEメール：donald.fedyk@alcatel-lucent.com電話番号：978-467-5645
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
ヤコフ・レックタージュニパーネットワークス、株式会社Eメール：yakov@juniper.net