[要約] RFC 3630は、OSPF Version 2におけるトラフィックエンジニアリング（TE）拡張の要約です。このRFCの目的は、OSPFを使用してネットワークのトラフィックを効果的に制御し、最適な経路を選択するための手法を提供することです。
Network Working Group D. Katz
Request for Comments: 3630 K. Kompella
Updates: 2370 Juniper Networks
Category: Standards Track D. Yeung
Procket Networks
September 2003
Traffic Engineering (TE) Extensions to OSPF Version 2
OSPFバージョン2へのトラフィックエンジニアリング（TE）拡張
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) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
このドキュメントでは、OSPFプロトコルバージョン2への拡張機能について説明して、不透明なリンク状態広告を使用して、エリア内交通工学（TE）をサポートしています。
This document specifies a method of adding traffic engineering capabilities to OSPF Version 2 [1]. The architecture of traffic engineering is described in [5]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS [6]. It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS.
このドキュメントは、OSPFバージョン2 [1]にトラフィックエンジニアリング機能を追加する方法を指定しています。交通工学のアーキテクチャは[5]で説明されています。拡張機能のセマンティックコンテンツは、IS-IS [6]の対応する拡張機能と本質的に同じです。OSPFへのトラフィックエンジニアリング拡張は、IS-ISのものを反映し続けることが期待されています。
The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Furthermore, no changes have been made to the operation of OSPFv2 flooding; in particular, if non-TE capable nodes exist in the topology, they MUST flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs (see [3]).
拡張機能は、トラフィックエンジニアリングトポロジ（帯域幅や管理上の制約を含む）を記述し、特定のOSPF領域内にこの情報を配布する方法を提供します。この提案は、マルチアクセスリンクを説明するためにネットワークLSAに依存していますが、このトポロジは必ずしも通常のルーティングトポロジと一致するわけではありません。このドキュメントでは、ここで説明するメカニズムが複数のOSPF領域のトラフィックエンジニアリングにどのように使用できるかを意図的に述べていません。そのタスクは将来の文書に任されています。さらに、OSPFV2洪水の操作には変更が加えられていません。特に、トポロジーに非TEの有能なノードが存在する場合、それらは他のタイプ10（エリアローカルスコープ）不透明LSAと同様にLSAをあふれなければなりません（[3]を参照）。
Many of the extensions specified in this document are in response to the requirements stated in [5], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements.
このドキュメントで指定されている拡張機能の多くは、[5]に記載されている要件に応じているため、「トラフィックエンジニアリング拡張」と呼ばれ、MPLSトラフィックエンジニアリングにも関連しています。提案は、OSPF広告のリンクにより多くの属性を追加することであるため、より正確な（当然のことではありますが）指定は「拡張リンク属性」です。
The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include:
これらの拡張機能によって利用可能な情報は、ルーターLSAが「通常の」リンク状態データベースを構築するために使用されるのと同じように、拡張リンク状態データベースの構築に使用できます。違いは、拡張リンク状態データベース（トラフィックエンジニアリングデータベースと呼ばれる）に追加のリンク属性があることです。トラフィックエンジニアリングデータベースの使用は次のとおりです。
o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering.
o 拡張リンク属性の監視。oローカル制約ベースのソースルーティング。oグローバルトラフィックエンジニアリング。
For example, an OSPF-speaking device can participate in an OSPF area, build a traffic engineering database, and thereby report on the reservation state of links in that area.
たとえば、OSPFを話すデバイスは、OSPFエリアに参加し、トラフィックエンジニアリングデータベースを構築し、それによってその領域のリンクの予約状態について報告できます。
In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated, is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP-hard, or even unsolvable, depending on the nature of the attributes and constraints, and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here.
「ローカル制約ベースのソースルーティング」では、ルーターRはソースノードAから宛先ノードBへのパスを計算できます。通常、AはR自体、Bは「ルーターアドレス」で指定されています（以下を参照）。このパスは、パスが通過するリンクとノードの属性、たとえば、少なくとも10mbpsの帯域幅のない緑色のリンクを使用するさまざまな制約の影響を受ける場合があります。このパスを使用して、AからBへのトラフィックのサブセットを運ぶことができ、交通工学の単純で効果的な手段を形成します。トラフィックのサブセットがどのように決定されるか、およびパスがどのようにインスタンス化されるかは、このドキュメントの範囲を超えています。トラフィックのサブセットを定義する手段の1つは、「IP宛先がBから学習されたパケット」であり、インスタンス化されたパスの1つの手段はMPLSトンネルを使用することであると言えば十分です。余談ですが、制約ベースのルーティングは、属性と制約の性質に応じて、NPハード、または解決不可能である可能性があることに注意してください。したがって、多くの実装はヒューリスティックを使用します。その結果、ここでアルゴリズムをスケッチしようとはしません。
Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes.
最後に、「Global Traffic Engineering」の場合、デバイスはトラフィックエンジニアリングデータベースを構築し、トラフィックマトリックスと最適化関数を入力し、情報をクランチし、ネットワーク全体の最適またはほぼ最適ルーティングを計算できます。その後、デバイスはトラフィックエンジニアリングトポロジを監視し、最適なルートを再計算することで変化に対応できます。
As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) distribution are not discussed here.
上記のように、このドキュメントは、交通工学情報のエリア内分布のための拡張と手順を指定しています。ここでは、エリア間およびAS間分布（自律システム）分布の方法については説明しません。
The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multi-access links may not be accurately reflected, except in the special case in which there are only two devices in the multi-access subnetwork. Operation over multi-access networks with more than two devices is not specifically prohibited. A more accurate description of the reservation state of multi-access networks is for further study.
このドキュメントで指定された拡張機能は、ポイントツーポイントリンクの予約状態をキャプチャします。マルチアクセスサブネットワークに2つのデバイスのみがある特別な場合を除き、マルチアクセスリンクの予約状態は正確に反映されない場合があります。3つ以上のデバイスを備えたマルチアクセスネットワークを介して動作することは、特に禁止されていません。マルチアクセスネットワークの予約状態のより正確な説明は、さらなる研究のためです。
This document also does not support unnumbered links. This deficiency will be addressed in future documents; see also [7] and [8].
このドキュメントでは、数え切れないほどのリンクもサポートしていません。この欠陥は、将来の文書で対処されます。[7]および[8]も参照してください。
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 BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
This extension makes use of the Opaque LSA [3].
この拡張は、不透明なLSA [3]を利用しています。
Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope.
3種類の不透明なLSAが存在し、それぞれに異なる洪水範囲があります。この提案では、領域の洪水範囲があるタイプ10 LSAのみを使用しています。
One new LSA is defined, the Traffic Engineering LSA. This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA is sufficient for describing multi-access links, so no additional LSA is defined for this purpose.
1つの新しいLSAが定義されています。トラフィックエンジニアリングLSAです。このLSAは、ルーター、ポイントツーポイントリンク、およびマルチアクセスネットワークへの接続について説明します（ルーターLSAに似ています）。トラフィックエンジニアリングのために、既存のネットワークLSAはマルチアクセスリンクを説明するのに十分であるため、この目的のために追加のLSAは定義されていません。
The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type-specific data. The Traffic Engineering LSA uses type 1. The remaining 24 bits are the Instance field, as follows:
不透明LSAのLSA IDは、8ビットのタイプデータと24ビットのタイプ固有のデータを持つと定義されています。トラフィックエンジニアリングLSAはタイプ1を使用します。残りの24ビットは、次のようにインスタンスフィールドです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance.
インスタンスフィールドは、複数のトラフィックエンジニアリングLSAを維持するために使用される任意の価値です。最大16777216トラフィックエンジニアリングLSAは、単一のシステムによって供給される場合があります。LSA IDにはトポロジカルな意味はありません。
The Traffic Engineering LSA starts with the standard LSA header:
トラフィックエンジニアリングLSAは、標準のLSAヘッダーから始まります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is:
LSAペイロードは、拡張性のための1つ以上のネストされたタイプ/長さ/値（TLV）トリプレットで構成されています。各TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored.
長さフィールドは、オクテットの値部分の長さを定義します（したがって、値部分のないTLVはゼロの長さになります）。TLVは、4オクテットのアライメントにパッドで埋められています。パディングは長さフィールドには含まれていません（したがって、3オクテットの値は3つの長さですが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも32ビットアライメントされています。認識されていないタイプは無視されます。
This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types.
このメモは、タイプ1と2を定義します。新しいタイプの割り当てについては、IANAの考慮事項セクションを参照してください。
An LSA contains one top-level TLV.
LSAには、1つのトップレベルTLVが含まれています。
There are two top-level TLVs defined:
定義された2つのトップレベルのTLVがあります。
1 - Router Address 2 - Link
1-ルーターアドレス2-リンク
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it; this is typically implemented as a "loopback address". The key attribute is that the address does not become unusable if an interface is down. In other protocols, this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID.
ルーターアドレスTLVは、広告ルーターの安定したIPアドレスを指定します。これは通常、「ループバックアドレス」として実装されます。重要な属性は、インターフェイスがダウンしている場合、アドレスが使用できないことです。他のプロトコルでは、これは「ルーターID」として知られていますが、明らかな理由でこの命名法はここで回避されます。ルーターがBGPの次のホップ属性をBGPルーターIDに設定してBGPルートを宣伝する場合、ルーターアドレスはBGPルーターIDと同じでなければなりません。
If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPF and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPF TE information. R may then appear as two separate nodes in S's TED. However, if both the IS-IS and OSPF LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single router.
IS-ISがドメインでもアクティブである場合、このアドレスを使用して、OSPFとIS-ISトポロジの間のマッピングを計算することもできます。たとえば、ルーターRがIS-ISとOSPFトラフィックエンジニアリングLSAの両方を宣伝していると仮定し、さらに一部のルーターSがIS-ISとOSPF情報の両方に基づいて単一のトラフィックエンジニアリングデータベース（TED）を構築していると仮定します。Rは、SのTEDに2つの別々のノードとして表示される場合があります。ただし、Rによって生成されたIS-ISとOSPF LSAの両方が同じルーターアドレスを含む場合、Sは、RのIS TE LSAとOSPF TE LSAが実際に単一のルーターからのものであると判断できます。
The router address TLV is type 1, has a length of 4, and a value that is the four octet IP address. It must appear in exactly one Traffic Engineering LSA originated by a router.
ルーターアドレスTLVはタイプ1で、長さは4で、値は4オクテットIPアドレスです。ルーターから発信される1つのトラフィックエンジニアリングLSAに表示される必要があります。
The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs.
リンクTLVは、単一のリンクを記述します。サブTLVのセットで構成されています。サブTLVの順序付け要件はありません。
Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology.
各LSAには1つのリンクTLVのみが運ばれ、トポロジーの細かい粒度の変化が可能になります。
The Link TLV is type 2, and the length is variable.
リンクTLVはタイプ2で、長さは可変です。
The following sub-TLVs of the Link TLV are defined:
リンクTLVの次のサブTLVが定義されています。
1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets)
1-リンクタイプ（1オクテット）2-リンクID（4オクテット）3-ローカルインターフェイスIPアドレス（4オクテット）4-リモートインターフェイスIPアドレス（4オクター）5-トラフィックエンジニアリングメトリック（4オクター）6-最大帯域幅（最大帯域幅（4オクテット）7-最大予約可能帯域幅（4オクテット）8-予約されていない帯域幅（32オクテット）9-管理グループ（4オクテット）
This memo defines sub-Types 1 through 9. See the IANA Considerations section for allocation of new sub-Types.
このメモは、サブタイプ1から9を定義します。新しいサブタイプの割り当てについては、IANAの考慮事項セクションを参照してください。
The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.
リンクタイプとリンクIDサブTLVは必須です。つまり、正確に1回表示する必要があります。ここで定義されている他のすべてのサブTLVは、せいぜい1回発生する場合があります。これらの制限は、将来のサブTLVに適用する必要はありません。認識されていないサブTLVは無視されます。
Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows:
以下のさまざまな値は、（32ビット）IEEEフローティングポイント形式を使用します。迅速な参照のために、この形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Exponent | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S is the sign, Exponent is the exponent base 2 in "excess 127" notation, and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus, the above represents the value:
Sは標識、指数は「過剰127」表記の指数ベース2であり、分数はマンティッサ-1であり、その前に暗黙のバイナリポイントがあります。したがって、上記は値を表します。
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction)
For more details, refer to [4].
詳細については、[4]を参照してください。
The Link Type sub-TLV defines the type of the link:
リンクタイプのsub-tlvは、リンクのタイプを定義します。
1 - Point-to-point 2 - Multi-access
1-ポイントツーポイント2-マルチアクセス
The Link Type sub-TLV is TLV type 1, and is one octet in length.
リンクタイプのサブTLVはTLVタイプ1であり、長さが1オクテットです。
The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the contents of the Link ID field in the Router LSA for these link types.
リンクID Sub-TLVは、リンクの反対側を識別します。ポイントツーポイントリンクの場合、これはネイバーのルーターIDです。マルチアクセスリンクの場合、これは指定されたルーターのインターフェイスアドレスです。リンクIDは、これらのリンクタイプのルーターLSAのリンクIDフィールドの内容と同一です。
The Link ID sub-TLV is TLV type 2, and is four octets in length.
リンクIDサブTLVはTLVタイプ2で、長さは4オクターです。
The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV.
ローカルインターフェイスIPアドレスSUB-TLVは、このリンクに対応するインターフェイスのIPアドレス（ES）を指定します。リンクに複数のローカルアドレスがある場合、これらはすべてこのサブTLVにリストされています。
The Local Interface IP Address sub-TLV is TLV type 3, and is 4N octets in length, where N is the number of local addresses.
ローカルインターフェイスIPアドレスSUB-TLVはTLVタイプ3であり、長さは4Nオクテットで、Nはローカルアドレスの数です。
The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multi-access, the Remote Interface IP Address is set to 0.0.0.0; alternatively, an implementation MAY choose not to send this sub-TLV.
リモートインターフェイスIPアドレスSUB-TLVは、このリンクに対応するNeighborのインターフェイスのIPアドレス（ES）を指定します。これとローカルアドレスは、システム間の複数の並列リンクを識別するために使用されます。リンクのリンクタイプがマルチアクセスの場合、リモートインターフェイスIPアドレスは0.0.0.0に設定されます。あるいは、実装がこのサブTLVを送信しないことを選択する場合があります。
The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N octets in length, where N is the number of neighbor addresses.
リモートインターフェイスIPアドレスSUB-TLVはTLVタイプ4であり、長さは4Nオクテットで、nは隣接アドレスの数です。
The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network administrator.
トラフィックエンジニアリングメトリックサブTLVは、トラフィックエンジニアリングの目的でリンクメトリックを指定します。このメトリックは、標準のOSPFリンクメトリックとは異なる場合があります。通常、このメトリックはネットワーク管理者によって割り当てられます。
The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length.
トラフィックエンジニアリングメトリックサブTLVはTLVタイプ5であり、長さは4オクターです。
The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link, in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second.
最大帯域幅サブTLVは、このリンクで使用できる最大帯域幅、この方向（LSAを隣接するシステムから）、IEEEフローティングポイント形式で指定します。これが真のリンク容量です。ユニットは1秒あたりのバイトです。
The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length.
最大帯域幅サブTLVはTLVタイプ6で、長さは4オクターです。
The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second.
最大予約可能な帯域幅サブTLVは、このリンクで予約されている最大帯域幅を、この方向に、IEEEフローティングポイント形式で指定します。これは、最大帯域幅よりも大きい場合があることに注意してください（この場合、リンクがオーバーサブスクライブされる場合があります）。これはユーザー構成である必要があります。デフォルト値は最大帯域幅である必要があります。ユニットは1秒あたりのバイトです。
The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length.
最大予約可能な帯域幅サブTLVはTLVタイプ7で、長さは4オクターです。
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second.
予約されていない帯域幅サブTLVは、IEEEフローティングポイント形式の8つの優先度レベルのそれぞれでまだ予約されていない帯域幅の量を指定します。値は、0〜7のセットアップ優先度で予約できる帯域幅に対応し、サブTLVの開始時に発生する優先度0とサブTLVの終了時に優先度7で順序を増やします。初期値（帯域幅が予約される前）はすべて、最大予約可能な帯域幅に設定されます。各値は、最大予約可能帯域幅以下になります。ユニットは1秒あたりのバイトです。
The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length.
予約されていない帯域幅サブTLVはTLVタイプ8であり、長さは32オクテットです。
The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups.
管理グループSub-TLVには、ネットワーク管理者によって割り当てられた4-OCTETビットマスクが含まれています。各セットビットは、インターフェイスに割り当てられた1つの管理グループに対応します。リンクは複数のグループに属する場合があります。
By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'.
慣習により、最も重要なビットは「グループ0」と呼ばれ、最も重要なビットは「グループ31」と呼ばれます。
The Administrative Group is also called Resource Class/Color [5].
管理グループは、リソースクラス/色とも呼ばれます[5]。
The Administrative Group sub-TLV is TLV type 9, and is four octets in length.
管理グループのサブTLVはTLVタイプ9であり、長さは4オクターです。
Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1].
ルーターは、LSAの内容が変化するたびにトラフィックエンジニアリングLSAを発信し、それ以外の場合はOSPF（たとえばLSAリフレッシュ）が必要とする場合はいつでも必要です。これは、すべての変更をすぐに浸水させる必要があるという意味ではないことに注意してください。実装は、即時の洪水を引き起こすしきい値（帯域幅の変更しきい値など）を設定し、短時間の間隔の後に他の変化の洪水を開始する場合があります。いずに
Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No Shortest Path First (SPF) or other route calculations are necessary.
変更されたトラフィックエンジニアリングLSAまたはネットワークLSAを受信すると（これらはトラフィックエンジニアリングの計算で使用されるため）、ルーターはトラフィックエンジニアリングデータベースを更新する必要があります。最初に最短パス（SPF）または他のルートの計算は必要ありません。
There should be no interoperability issues with routers that do not implement these extensions, as the Opaque LSAs will be silently ignored.
不透明なLSAは静かに無視されるため、これらの拡張機能を実装しないルーターに相互運用性の問題はないはずです。
The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces. However, if the topology is connected, TE paths can still be calculated and ought to work.
これらの拡張機能を実装していないルーターがある結果、トラフィックエンジニアリングのトポロジはピースが欠落しています。ただし、トポロジが接続されている場合、TEパスはまだ計算され、機能する必要があります。
This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. However, tampering with TE LSAs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal OSPF LSAs be applied equally to all Opaque LSAs, including the TE LSAs specified here.
このドキュメントは、OSPFv2の不透明LSAの内容を指定しています。不透明LSAはSPF計算または通常のルーティングに使用されていないため、ここで指定されている拡張機能はIPルーティングに影響を与えません。ただし、TE LSAの改ざんはトラフィックエンジニアリング計算に影響を与える可能性があり、通常のOSPF LSAの伝達を確保するために使用されるメカニズムは、ここで指定されたTE LSAを含むすべての不透明なLSAに等しく適用することが示唆されています。
Note that the mechanisms in [1] and [9] apply to Opaque LSAs. It is suggested that any future mechanisms proposed to secure/authenticate OSPFv2 LSA exchanges be made general enough to be used with Opaque LSAs.
[1]および[9]のメカニズムは不透明なLSAに適用されることに注意してください。OSPFV2 LSA交換を安全/認証するために提案された将来のメカニズムは、不透明なLSAで使用するのに十分な一般的なものにすることをお勧めします。
The top level Types in a TE LSA, as well as Types for sub-TLVs for each top level Type, have been registered with IANA, except as noted.
TE LSAのトップレベルタイプ、および各トップレベルタイプのサブTLVのタイプは、記載されている場合を除き、IANAに登録されています。
Here are the guidelines (using terms defined in [10]) for the assignment of top level Types in TE LSAs:
Te LSAのトップレベルタイプの割り当てのためのガイドライン（[10]で定義された用語を使用）を次に示します。
o Types in the range 3-32767 are to be assigned via Standards Action.
o 範囲3-32767のタイプは、標準アクションを介して割り当てられます。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.
o 範囲32768-32777のタイプは、実験用のものです。これらはIANAに登録されておらず、RFCSで言及してはなりません。
o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
o 範囲32778-65535のタイプは、現時点では割り当てられません。この範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定する標準トラックRFCが必要です。
The guidelines for the assignment of types for sub-TLVs in a TE LSA are as follows:
TE LSAでのサブTLVのタイプの割り当てのガイドラインは次のとおりです。
o Types in the range 10-32767 are to be assigned via Standards Action.
o 範囲10-32767のタイプは、標準アクションを介して割り当てられます。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.
o 範囲32768-32777のタイプは、実験用のものです。これらはIANAに登録されておらず、RFCSで言及してはなりません。
o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
o 範囲32778-65535のタイプは、現時点では割り当てられません。この範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定する標準トラックRFCが必要です。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[3] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2370、1998年7月。
[4] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
[4] IEEE、「バイナリフローティングポイント算術のIEEE標準」、標準754-1985、1985（ISBN 1-5593-7653-8）。
[5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[5] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering", work in progress.
[6] Smit、H。およびT. Li、「トラフィックエンジニアリングのためのISIS拡張」、進行中の作業。
[7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[7] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける非番号のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[8] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[8] Kompella、K.、Rekhter、Y。およびA. Kullberg、「CR-LDP（Constraint-routing Label Distribution Protocol）の数のリンクのシグナリング」、RFC 3480、2003年2月。
[9] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[9] Murphy、S.、Badger、M. and B. Wellington、「Digital Signatures with Digital Signatures」、RFC 2154、1997年6月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 USA
Phone: +1 408 745 2000
EMail: dkatz@juniper.net
Derek M. Yeung Procket Networks, Inc. 1100 Cadillac Court Milpitas, CA 95035 USA
Derek M. Yeung Procket Networks、Inc。1100 Cadillac Court Milpitas、CA 95035 USA
Phone: +1 408 635-7900
EMail: myeung@procket.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 USA
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。