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
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.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
この文書では、不透明なリンクステートアドバタイズメントを使用して、エリア内トラフィックエンジニアリング（TE）をサポートするためにOSPFプロトコルバージョン2への拡張機能について説明します。
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.
この文書では、[1] OSPFバージョン2へのトラフィックエンジニアリング機能を追加する方法を指定します。トラフィックエンジニアリングのアーキテクチャは、[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（[3]参照）のようにTE LSAをフラッディングしなければなりません。
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は、宛先ノードBにソースノードAからのパスを計算することができます。典型的には、Aは、R自体であり、そしてBは「ルータアドレス」（下記参照）で指定されています。このパスは、パスが横断リンク及びノードの属性に様々な制約を受けることができる、例えば、少なくとも10Mbpsのの予約されていない帯域幅を有する緑色のリンクを使用します。この経路は、トラフィックエンジニアリングのシンプルだが効果的な手段を形成する、からBへのトラフィックのサブセットを運ぶために使用することができます。トラフィックのサブセットが決定され、そしてどのようにパスがインスタンス化された方法は、この文書の範囲外です。トラフィックのサブセットを定義する一つの手段は、とパスをインスタンス化の一つの手段は、MPLSトンネルを使用している「とは、そのIP送信先Bから学習されたこれらのパケット」であることを言えば十分。余談として、その制約ベースのルーティングは、属性と制約の性質に応じて、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.
最後に、「グローバル・トラフィック・エンジニアリング」のデバイスは、トラフィックエンジニアリングデータベース、入力トラフィック行列及び最適化機能を構築することができる情報にクランチ、したがってネットワーク全体の最適またはほぼ最適な経路を計算します。デバイスはその後、トラフィックエンジニアリングトポロジを監視し、最適なルートを再計算することにより、変化に対応することができます。
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つのデバイスがマルチアクセスサブネットワークに存在する特殊な場合を除いて、反映されないかもしれません。つ以上のデバイスとのマルチアクセスネットワーク上での動作は特に禁止されていません。マルチアクセスネットワークの予約状態のより正確な説明は、今後の検討課題です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
不透明LSAの3つのタイプが異なる氾濫範囲をそれぞれ有する、存在します。この提案は唯一のスコープを氾濫面積を持つ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.
一つの新しい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は、以下のように、残りの24ビットは、インスタンスのフィールドであるタイプ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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オクテット整列に埋め込まれます。パディングは、長さフィールド（SO 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ルータIDに設定BGPネクストホップ属性を持つ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との間のマッピングを計算するために使用することができます。例えば、ルータRは、IS-IS、およびOSPFトラフィックエンジニアリングLSAの両方をアドバタイズしていると仮定して、いくつかのルータSは、IS-IS、およびOSPF TE情報の両方に基づいて、単一のトラフィックエンジニアリングデータベース（TED）を構築して、さらにとします。 Rは、その後、SのTED内の2つの別個のノードとして表示されてもよいです。 Rによって生成されたIS-ISおよびOSPFのLSAの両方が同じルータアドレスを含む場合には、次にSはRからIS-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.
1つのリンクのみTLVは、トポロジ内の細かい粒度の変化を考慮して、各LSAに実施しなければなりません。
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.
このメモは、新しいサブタイプの割り当てのためのIANAの考慮事項のセクションを参照してください9を介してサブタイプ1を定義します。
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がすなわち、一度だけ表示される必要があり、必須です。ここで定義された他のすべてのサブTLVが最も一度に発生する可能性があります。これらの制限は、将来のサブの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)
（-1）**（S）* 2 **（指数-127）*（1つの+画分）
For more details, refer to [4].
詳細については、[4]を参照。
The Link Type sub-TLV defines the type of the link:
リンクタイプのサブ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サブ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アドレスのサブTLVは、このリンクに対応するインタフェースのIPアドレスを指定します。リンク上の複数のローカルアドレスがある場合、それらはすべてこのサブ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アドレスのサブTLVは、TLVタイプ3であり、そしてNはローカルアドレスの数であり、長さが4Nオクテットです。
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アドレスのサブTLVは、このリンクに対応するネイバーのインターフェイスのIPアドレスを指定します。これとローカルアドレスは、システム間の複数のパラレルリンクを識別するために使用されています。リンクのリンクタイプは、マルチアクセスがある場合は、リモート・インタフェースの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アドレスのサブTLVは、TLVタイプ4であり、Nは、隣接アドレスの数であり、長さが4Nオクテットです。
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は、IEEE浮動小数点形式で、（ネイバーにLSAを発信システムから）この方向に、このリンク上で使用可能な最大帯域幅を指定します。これは、真のリンク容量です。単位は秒あたりのバイト数です。
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浮動小数点形式で、この方向では、このリンク上で予約することができる最大帯域幅を指定します。これは、（リンクがオーバーサブスクライブすることができる場合には）最大帯域幅より大きくてもよいことに留意されたいです。これは、ユーザーが構成されるべきです。デフォルト値は、最大帯域幅でなければなりません。単位は秒あたりのバイト数です。
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つの優先レベルのそれぞれに予約されていない帯域幅の量を指定します。値は、サブTLVの終わりにサブTLVの開始時に発生する優先順位0、及び優先順位7を昇順に配列された0〜7の設定優先的に確保できる帯域幅に対応します。初期値は、（任意の帯域幅が予約される前に）すべての予約可能な最大帯域幅に設定されています。各値は以下の最大予約可能帯域幅に等しくなります。単位は秒あたりのバイト数です。
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.
管理グループのサブTLVは、ネットワーク管理者によって割り当てられた4オクテットのビットマスクを含んでいます。各設定ビットは、インタフェースに割り当てられた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リフレッシュ、）で必要とされるたびものとします。これは、すべての変更はすぐに浸水されなければならないことを意味しないことに注意してください。実装は、しきい値を設定してもよい（例えば、帯域幅変化しきい値）即時フラッディングをトリガし、短い時間間隔の後に他の変更のフラッディングを開始します。いずれにしても、トラフィックエンジニアリングLSAの発信は、レート制限最大1つのすべてのMinLSIntervalへ[1]であるべきです。
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に適用されることに留意されたいです。任意の将来のメカニズムは不透明LSAで使用されるのに十分一般なされるのOSPFv2 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.
各トップレベル・タイプのサブTLVのためのトップレベルのTE LSAでタイプ、ならびにタイプは、注目されている場合を除き、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.
範囲3から32767でOタイプは標準アクションを経由して割り当てられます。
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.
実験的な使用のためのものである32768から32777の範囲のOタイプ。これらは、IANAに登録されず、RFCで言及されてはなりません。
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.
範囲32778から65535でOタイプではありません。この時点で割り当てられます。すべての割り当ては、この範囲内で行うことができる前に、割り当てられている範囲をカバー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.
範囲10-32767におけるOタイプは標準アクションを経由して割り当てられます。
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.
実験的な使用のためのものである32768から32777の範囲のOタイプ。これらは、IANAに登録されず、RFCで言及されてはなりません。
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.
範囲32778から65535でOタイプではありません。この時点で割り当てられます。すべての割り当ては、この範囲内で行うことができる前に、割り当てられている範囲をカバー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]モイ、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[3] Coltun、R.、 "OSPFオペーク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、 "2進浮動小数点演算のための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.、マルコム、J.、Agogbua、J.、オデル、M.とJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering", work in progress.
[6]スミット、H.、およびT.李、「トラフィックエンジニアリングのための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（制約ルーティングラベル配布プロトコル）シグナリングアンナンバードリンク"、RFC 3480、2003年2月。
[9] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[9]マーフィー、S.、アナグマ、M.およびB.ウェリントン、 "デジタル署名とOSPF"、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.
、BCP 26、RFC 2434、1998年10月[10] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
デイブ・カッツジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089 USA
Phone: +1 408 745 2000 EMail: dkatz@juniper.net
電話：+1 408 745 2000 Eメール：dkatz@juniper.net
Derek M. Yeung Procket Networks, Inc. 1100 Cadillac Court Milpitas, CA 95035 USA
デレク・M.ヨンProcketネットワークス株式会社1100キャデラック裁判所ミルピタス、CA 95035 USA
Phone: +1 408 635-7900 EMail: myeung@procket.com
電話：+1 408 635-7900 Eメール：myeung@procket.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089 USA
Phone: +1 408 745 2000 EMail: kireeti@juniper.net
電話：+1 408 745 2000 Eメール：kireeti@juniper.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。