[要約] RFC 5543は、BGPトラフィックエンジニアリング属性に関する標準化された仕様です。このRFCの目的は、BGPプロトコルを使用してネットワークトラフィックを効果的に制御するための属性を定義することです。
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
BGPトラフィックエンジニアリング属性
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の法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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では、この属性の1つの使用可能な使用法について説明します。
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で指定された値の1つが含まれています。
The Encoding field contains one of the values specified in Section 3.1.1 of [RFC3471].
エンコーディングフィールドには、[RFC3471]のセクション3.1.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（ラベルスイッチ付きパス）帯域幅は、IEEEフローティングポイントフォーマット[IEEE]の8つの4オクテットフィールドのリストとしてエンコードされ、優先度は最初に、優先度7が最後になります。ユニットは1秒あたりのバイト（ビットではありません！）です。
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オクテットフィールドにエンコードされています。ユニットは1秒あたりのバイト（ビットではありません！）です。インターフェイスMTUは、2-OCTET整数としてエンコードされています。
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オクテットフィールドにエンコードされています。ユニットは1秒あたりのバイト（ビットではありません！）です。インターフェイスが標準または任意のSONET/SDHをサポートするかどうかの指標は、1オクテットとしてエンコードされます。このオクテットの値は、インターフェイスが標準のSONET/SDHをサポートする場合は0、インターフェイスが任意のSONET/SDHをサポートする場合は1です。
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.
ルートがトラフィックエンジニアリング属性以外に異なる場合（たとえば、ルートターゲットおよび/またはnext_hopのセットが異なる）、トラフィックエンジニアリング属性の使用は、ルートを運ぶのに必要なBGP更新メッセージの数に影響を与えません。また、ルートが他のすべての属性情報を共有し、集約または同一のトラフィックエンジニアリング属性を持っている場合、影響はありません。ルートが他のすべての属性情報を共有し、異なるトラフィックエンジニアリング属性を持つ場合、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.
著者は、レビューとコメントをしてくれたJohn ScudderとJeffrey Haasに感謝したいと思います。
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
[IEEE] IEEE、「バイナリフローティングポイント算術の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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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. Berger、「MPLS Traffic Engineering（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.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195] Oould-Brahim、H.、Fedyk、D。、およびY. Rekhter、「Layer-1 VPNSのBGPベースの自動分類」、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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
Authors' Addresses
著者のアドレス
Hamid Ould-Brahim Nortel Networks EMail: hbrahim@nortel.com
Hamid Oould-Brahim Nortel Networksメール：hbrahim@nortel.com
Don Fedyk Alcatel-Lucent EMail: donald.fedyk@alcatel-lucent.com Phone: 978-467-5645
Don Fedyk Alcatel-Lucentメール：donald.fedyk@alcatel-lucent.com電話：978-467-5645
Yakov Rekhter Juniper Networks, Inc. EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks、Inc。電子メール：yakov@juniper.net