Network Working Group H. Smit
Request for Comments: 3784 Procket Networks
Category: Informational T. Li
June 2004
Intermediate System to Intermediate System (IS-IS)
Extensions for Traffic Engineering (TE)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
この文書では、中間システムへの中間システムへの拡張機能について説明します（IS-IS）トラフィックエンジニアリング（TE）をサポートするためのプロトコル。この文書では、中間システム（ルータ）という新たな情報を指定することにより、IS-ISプロトコル拡張リンクステートプロトコル（LSP）データユニットに配置することができます。この情報は、トラフィックエンジニアリングの計算に役立つネットワークの状態に関する追加の詳細を説明します。
The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [3]. Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing information. Each LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format.
IS-ISプロトコルは、RFC 1195で指定されたIPv4をサポートするための拡張と、ISO [1] 10589で指定されている[3]。各中間システム（IS）（ルータ）は、ルーティング情報を持つ1つ以上のIS-ISリンクステートプロトコルデータユニット（LSPを）アドバタイズします。各LSPは、各々がタイプ、長さ、および値からなる、固定ヘッダとタプルの数で構成されています。そのようなタプルは、一般のTLVとして知られており、柔軟で拡張可能な形式で情報を符号化する良い方法であるれます。
This document contains the design of new TLVs to replace the existing IS Neighbor TLV, IP Reachability TLV, and to include additional information about the characteristics of a particular link to an IS-IS LSP. The characteristics described in this document are needed for Traffic Engineering [4] (TE). Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes.
この文書では、既存の近隣TLV、IP到達可能性TLVで、IS-IS LSPへの特定のリンクの特性に関する追加情報を含めるように代わる新しいのTLVの設計が含まれています。この文書中で説明されている特徴は、トラフィックエンジニアリング[4]（TE）のために必要とされます。二次目標はIS-ISメトリックのダイナミックレンジを増加させ、IPプレフィックスの符号化を改善することを含みます。
The router id is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router.
それは、常に特定のルータを参照するために使用することができ、単一のアドレスを記述しているので、ルータIDは、トラフィックエンジニアリングの目的のために有用です。
Mechanisms and procedures to migrate to the new TLVs are not discussed in this document.
メカニズムと新しいのTLVに移行するための手順は、このドキュメントで説明されていません。
This document introduces a new way to encode routing information in IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to regular TLVs. They use the same concepts as regular TLVs. The difference is that TLVs exist inside IS-IS packets, while sub-TLVs exist inside TLVs. TLVs are used to add extra information to IS-IS packets. Sub-TLVs are used to add extra information to particular TLVs. Each sub-TLV consists of three fields, a one-octet Type field, a one-octet Length field, and zero or more octets of Value. The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field in octets. Each sub-TLV can potentially hold multiple items. The number of items in a sub-TLV can be computed from the length of the whole sub-TLV, when the length of each item is known. Unknown sub-TLVs are to be ignored and skipped upon receipt.
この文書では、IS-ISでのルーティング情報をエンコードするための新しい方法を紹介します。新しいオブジェクトは、サブTLVと呼ばれています。サブTLVは、正規のTLVに似ています。彼らは定期的なのTLVと同じ概念を使用します。違いは、TLVのサブのTLVのTLVが内部に存在しながら、パケット-IS内部に存在することです。 TLVがIS-ISパケットに余分な情報を追加するために使用されています。サブTLVは、特定のTLVに余分な情報を追加するために使用されています。各サブTLVは、三つのフィールド、1オクテットのTypeフィールド、1オクテットの長さフィールド、および値のゼロ以上のオクテットで構成されています。 Typeフィールドは、Valueフィールド内の項目の種類を示します。 Lengthフィールドは、オクテットで値フィールドの長さを示します。各サブTLVは、潜在的に複数の項目を保持することができます。各項目の長さが既知である場合、サブTLV内の項目の数は、全体のサブTLVの長さから算出することができます。未知のサブTLVが無視され、受信時にスキップされるべきです。
The Sub-TLV type space is managed by the IETF IS-IS WG (http://www.ietf.org/html.charters/isis-charter.html). New type values are allocated following review on the IETF IS-IS mailing list. This will normally require publication of additional documentation describing how the new type is used. In the event that the IS-IS working group has disbanded the review shall be performed by a Designated Expert assigned by the responsible Area Director.
サブTLVのタイプのスペースは、IETFによって管理されているIS-IS WG（http://www.ietf.org/html.charters/isis-charter.html）。新しいタイプの値が割り当てられているIETFで次のレビューは、IS-ISメーリングリスト。これは通常、新しいタイプを使用する方法を説明する追加文書の発行が必要になります。 IS-ISワーキンググループの製品レビューを解散していた場合には責任エリアディレクターによって割り当てられた指定の専門家によって行われなければなりません。
The extended IS reachability TLV is TLV type 22.
拡張は、TLVは、TLVタイプ22で到達可能です。
The existing IS reachability (TLV type 2, defined in ISO 10589 [1]) contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate whether the metric is internal or external, and one bit that was originally unused, but which was later defined by RFC 2966 to be the up/down bit. The remaining 6 bits are used to store the actual metric, resulting in a possible metric range of 0- 63. This limitation is one of the restrictions that we would like to lift.
されている既存の到達可能性（ISO 10589で定義されたTLVタイプ2は、[1]）は、隣接の系列についての情報を含みます。各隣人のために、デフォルトのメトリック、遅延、金銭的コスト、信頼性、及び隣接する隣接の7オクテットIDを含む構造があります。この情報の、デフォルトのメトリックは、一般的に使用されます。デフォルトメトリックは、現在のメトリックは、内部または外部にあるかどうかを示すために使用される1ビットと1つのオクテット、および本来未使用であった1ビットであるが、後でアップ/ダウンビットであることがRFC 2966によって定義されました。残りの6ビットは、この制限は、我々が上昇したい制限の一つである0〜63の可能なメトリック範囲で、その結果、実際のメトリックを格納するために使用されます。
The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system ID, typically 6-octets, plus one octet indicating the pseudonode number. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors.
残りの3つの指標（遅延、金銭的コスト、および信頼性）は一般に実装され、TLVにおける未使用のオーバーヘッドを反映していません。ネイバーは、そのシステムID、典型的には6オクテットプラス擬似番号を示す1つのオクテットによって識別されます。したがって、既存のTLVは、メトリックの4つのオクテットと隣接識別7つのオクテットと、近隣あたり11個のオクテットを消費します。複数の隣接関係を示すために、この構造は、IS到達可能性TLV内で繰り返されます。 TLVはコンテンツの255オクテットに制限されているため、単一TLVは23人の隣人まで記述することができます。 IS到達可能性TLVはさらに隣人を記述するためにLSPフラグメント内で反復することができます。
The proposed extended IS reachability TLV contains a new data structure, consisting of:
提案された拡張TLVは、からなる、新しいデータ構造が含まれている到達可能です。
7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length of the value field of the sub-TLV 0-242 octets of value
7つのシステムIdのオクテット各サブTLVの長さのサブタイプの1オクテットの1つのオクテットの配列からなるサブのTLVのサブTLVの0から244オクテットの長さのデフォルトメトリック1オクテットの擬似番号3オクテット値のサブTLV 0から242オクテットの値フィールドの
Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged.
使用されていないサブTLVの場合はこのように、新しいエンコードが11個のオクテットを必要とし、23人の隣人まで含めることができます。エンコードは、サブのTLVの255個のオクテットを可能にしながら、最大値は全体的には、到達可能性TLV ISに収まることができないのでご注意ください。実用的な最大値は255オクテットマイナス上記11オクテット、又は244オクテットです。さらに、特定のネイバーのためのサブTLVの空間を拡張するための定義されたメカニズムは存在しません。このように、サブTLVのスペースを無駄にすることは推奨されません。
The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter-area route.
メトリックオクテットは24ビットの符号なし整数として符号化されます。新しい拡張IP到達可能性TLVにおけるメトリックフィールドは、32ビットの符号なし整数として符号化されることに留意されたいです。エリア内ルートのコストは、エリア間ルートのメトリックフィールドに収まるように切り落とさなければならないことはほとんどありませんように、これらの異なるサイズを選択しました。
To preclude overflow within a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
トラフィックエンジニアリングSPF実装内のオーバーフローを排除するには、以上MAX_PATH_METRICに等しいすべてのメトリックは、MAX_PATH_METRICのメトリックを持つように考慮しなければなりません。これはMAX_PATH_METRICプラス単一のリンク・メトリックは、内部メトリック計算のためのビット数をオーバーフローしないようMAX_PATH_METRICを選択するのが最も簡単です。私たちは、これが32ビットであることを前提としています。したがって、我々は4261412864（ - 2 ^ 25 0xFE000000、2 ^ 32）であることMAX_PATH_METRICを選択しました。
If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation. This will allow advertisement of a link for purposes other than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing.
リンクが最大リンクメトリック（2 ^ 24から1）でアドバタイズされている場合、このリンクは、通常のSPF計算時に考慮してはいけません。これは、通常の最短パスツリーを構築する以外の目的でのリンクの広告を許可します。例では、ホップバイホップルーティングのためのトラフィック・エンジニアリングのために利用可能ではなく、リンクです。
Certain sub-TLVs are proposed here:
特定のサブTLVのは、ここで提案されています：
Sub-TLV type Length (octets) Name 3 4 Administrative group (color) 6 4 IPv4 interface address 8 4 IPv4 neighbor address 9 4 Maximum link bandwidth 10 4 Reservable link bandwidth 11 32 Unreserved bandwidth 18 3 TE Default metric 250-254 Reserved for cisco specific extensions 255 Reserved for future expansion
サブTLVのタイプ長さ（オクテット）名前3 4管理グループ（色）6 4のIPv4インターフェイスアドレスは8 4のIPv4ネイバーアドレス9 4最大リンク帯域幅10 4予約可能リンク帯域11 32未予約帯域幅18 3 TEデフォルトメトリック250-254のために予約しますシスコ固有の拡張将来の拡張のために予約済み255
Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV.
これらのサブのTLVのそれぞれを以下に説明します。特に明記しない限り、情報の複数の発生は、サブTLVの複数の介在により支持されています。
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.
管理グループのサブ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」と呼ばれます。
This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはOPTIONALです。このサブTLVは、拡張ごとに最大で一度現れるべきで到達可能性TLVです。
This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times.
このサブTLVは、（メイン）TLVによって記述インターフェイスのための4オクテットのIPv4アドレスを含んでいます。このサブTLVは、複数回発生する可能性があります。
Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV.
このサブTLVをサポートしないシステムと相互作用する場合、これは、転送ループをもたらすことができるので、実装は、ルーティングまたは転送テーブルにインターフェイスアドレスの/ 32プレフィックスを注入してはいけません。
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV.
ルータは、この文書の基本的なTLV拡張を実装している場合、それは隣接の説明から、このサブTLVを追加したり、省略することができます。ルータがトラフィックエンジニアリングを実装している場合、それはこのサブTLVを含まなければなりません。
This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times.
このサブTLVは、このリンク上の隣接ルータのための単一のIPv4アドレスが含まれています。このサブTLVは、複数回発生する可能性があります。
Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV.
このサブTLVをサポートしないシステムと相互作用する場合、これは、転送ループをもたらすことができるので、実装は、ルーティングまたは転送テーブルに隣接アドレスの/ 32プレフィックスを注入してはいけません。
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV on point-to-point adjacencies.
ルータは、この文書の基本的なTLV拡張を実装している場合、それは隣接の説明から、このサブTLVを追加したり、省略することができます。ルータがトラフィックエンジニアリングを実装している場合、それは、ポイントツーポイント隣接にこのサブTLVを含まなければなりません。
This sub-TLV contains the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors). This is useful for traffic engineering.
このサブTLVは、（その近傍にLSPを発信システムから）この方向にこのリンク上で使用可能な最大帯域幅を含んでいます。これは、トラフィックエンジニアリングのために有用です。
The maximum link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second.
最大リンク帯域幅は、IEEE浮動小数点形式の32ビットで符号化されます。単位はバイト（ビットではない！）毎秒です。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張ごとに最大で一度現れるべきで到達可能性TLVです。
This sub-TLV contains the maximum amount of bandwidth that can be reserved in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.
このサブTLVは、このリンク上でこの方向に確保できる帯域幅の最大量を含有します。オーバーサブスクリプションの目的のために、これはリンクの帯域幅よりも大きくすることができることに注意してください。
The maximum reservable link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second.
最大予約リンク帯域幅は、IEEE浮動小数点形式の32ビットで符号化されます。単位はバイト（ビットではない！）毎秒です。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張ごとに最大で一度現れるべきで到達可能性TLVです。
This sub-TLV contains the amount of bandwidth reservable in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.
このサブTLVは、このリンク上でこの方向での帯域幅予約可能の量が含まれています。オーバーサブスクリプションの目的のために、これはリンクの帯域幅よりも大きくすることができることに注意してください。
Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. 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.
そのため、優先度およびプリエンプションの必要性を、各ヘッドエンドは、各優先度レベルで確保された帯域幅の量を知る必要があります。したがって、このサブTLVは、8つの32ビットIEEE浮動小数点数を含んでいます。単位はバイト（ビットではない！）毎秒です。値は、サブTLVの終わりにサブTLVの開始時に発生する優先順位0、及び優先順位7を昇順に配列された0〜7の設定優先的に確保できる帯域幅に対応します。
For stability reasons, rapid changes in the values in this sub-TLV SHOULD NOT cause rapid generation of LSPs.
安定性の理由から、このサブTLVの値の急激な変化は、LSPの迅速な生成を引き起こすことはありません。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張ごとに最大で一度現れるべきで到達可能性TLVです。
This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations.
このサブTLVは、24ビットの符号なし整数を含んでいます。このメトリックは、管理上割り当てられ、トラフィックエンジニアリングのSPF計算に異なった加重トポロジを提示するために使用することができます。
To preclude overflow within a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
トラフィックエンジニアリングSPF実装内のオーバーフローを排除するには、以上MAX_PATH_METRICに等しいすべてのメトリックは、MAX_PATH_METRICのメトリックを持つように考慮しなければなりません。これはMAX_PATH_METRICプラス単一のリンク・メトリックは、内部メトリック計算のためのビット数をオーバーフローしないようMAX_PATH_METRICを選択するのが最も簡単です。私たちは、これが32ビットであることを前提としています。したがって、我々は4261412864（ - 2 ^ 25 0xFE000000、2 ^ 32）であることMAX_PATH_METRICを選択しました。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV. If a link is advertised without this sub-TLV, traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張ごとに最大で一度現れるべきで到達可能性TLVです。リンクは、このサブTLVなしで宣伝されている場合は、トラフィックエンジニアリングSPF計算は延長の固定部分に宣伝され、このリンクの通常のデフォルトメトリックを使用しなければならない到達可能性TLVです。
The extended IP reachability TLV is TLV type 135.
拡張IP到達可能性TLVはTLVタイプ135です。
The existing IP reachability TLVs (TLV type 128 and TLV type 130, defined in RFC 1195 [3]) carry IP prefixes in a format that is analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four metrics, of which only the default metric is commonly used. The default metric has a possible range of 0-63. We would like to remove this restriction.
既存のIP到達可能性のTLV（RFC 1195で定義されたTLVタイプ128とTLVタイプ130、[3]）は、[1] ISO 10589からIS隣接TLVに類似している形式のIPプレフィックスを運びます。彼らは、デフォルトのメトリックが一般的に使用されている4つの指標を、運びます。デフォルトのメトリックは、0から63の可能な範囲を持っています。私たちは、この制限を削除したいと思います。
In addition, route redistribution (a.k.a. route leaking) has a key problem that was not fully addressed by the existing IP reachability TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in the level hierarchy. Unfortunately there were no mechanisms defined to advertise prefixes downwards in the level hierarchy.
また、ルート再配布（別称、ルートリークは）完全に既存のIP到達可能性のTLVによって対処されなかった重要な問題があります。 RFC 1195 [3]ルータは、階層内の上方にプレフィクスをアドバタイズすることを可能にします。残念ながら、レベルの階層に下向きにプレフィックスを通知するために定義されたメカニズムはありませんでした。
To address these two issues, the proposed extended IP reachability TLV provides for a 32 bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy.
これらの2つの問題に対処するために、提案されている拡張IP到達可能性TLVは、メトリック32ビットを提供し、プレフィックスが階層で「ダウン」の再配布されたことを示すために1ビットを追加します。
The proposed extended IP reachability TLV contains a new data structure, consisting of:
提案されている拡張IP到達可能性TLVは、以下からなる、新しいデータ構造が含まれています。
4 octets of metric information 1 octet of control information, consisting of 1 bit of up/down information 1 bit indicating the presence of sub-TLVs 6 bits of prefix length 0-4 octet of IPv4 prefix 0-250 optional octets of sub-TLVs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length of the value field of the sub-TLV 0-247 octets of value
IPv4のプレフィックスのサブTLVのプレフィックス長の6ビット0-4オクテットの存在を示すアップ/ダウン情報1ビットの1ビットからなる制御情報のメトリック情報1オクテットの4つのオクテット、サブのTLVの0-250任意オクテット、本発明は、サブのTLVの長さの1つのオクテットからなる場合、各サブTLVは、サブの値フィールドの長さのサブタイプの1オクテットの1つのオクテットの配列からなるサブTLVは、0から249個のまでのオクテットTLV値の0から247個のオクテット
This data structure can be replicated within the TLV, without exceeding the maximum length of the TLV.
このデータ構造は、TLVの長さの最大値を超えることなく、TLV内で複製することができます。
The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of octets for the given number of significant bits. This implies:
プレフィックス長の6ビット値0-32を有し、プレフィックスの有意ビットの数を示すことができます。プレフィックスは有効ビットの所定の数のオクテットの最小数で符号化されます。これが意味します：
Significant bits Octets
0 0
1-8 1
9-16 2
17-24 3
25-32 4
The remaining bits of prefix are transmitted as zero and ignored upon receipt.
接頭語の残りのビットはゼロとして送信され、受信時には無視されます。
If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table.
プレフィックスはMAX_PATH_METRIC（0xFE000000、段落3.0を参照）、その後メートルより大きいと宣伝されている場合は、このプレフィックスは、通常のSPF計算の際に考慮されてはなりません。これは、通常のIPルーティングテーブルを構築する以外の目的のために接頭語の広告を可能にします。
If routers were allowed to redistribute IP prefixes freely in both directions between level 1 and level 2 without any additional mechanisms, those routers would not be able to determine looping of routing information. A problem occurs when a router learns a prefix via level 2 routing and advertises that prefix down into a level 1 area, where another router might pick up the route and advertise the prefix back up into the level 2 backbone. If the original source withdraws the prefix, those two routers might end up having a routing loop between them, where part of the looped path is via level 1 routing and the other part of the looped path is via level 2 routing. The solution that RFC 1195 [3] poses is to allow only advertising prefixes upward in the level hierarchy, and to disallow the advertising of prefixes downward in the hierarchy.
ルータは、任意の付加的な機構なしにレベル1とレベル2の間で両方向に自由にIPプレフィクスを再配布を許可された場合、これらのルータは、ルーティング情報のループを決定することはできないであろう。ルータがレベル2ルーティングを経由してプレフィックスを学習し、別のルータがレベル2バックボーンにバックアッププレフィックスをルートをピックアップし、宣伝する可能性があるレベル1の領域、にダウンというプレフィックスをアドバタイズするときに問題が発生します。元のソースプレフィックスを撤回した場合、これらの2つのルータがループ経路の一部は、レベル1ルーティングを介してであり、ループ経路の他の部分は、レベル2ルーティングを介してであり、それらの間のルーティングループを有する終わるかもしれません。 RFC 1195 [3]ポーズ溶液は、階層内の上方にのみ広告プレフィックスを可能にするために、階層内の下方プレフィックスの広告を禁止することです。
To prevent this looping of prefixes between levels, a new bit of information is defined in the new extended IP reachability TLV. This bit is called the up/down bit. The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g. level 2 to level 1), the bit MUST be set to 1, indicating that the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e. to lower levels.
レベル間プレフィックスのこのループを防止するために、情報の新しいビットは、新しい拡張IP到達可能性TLVで定義されています。このビットは、アップ/ダウン・ビットと呼ばれています。プレフィックスが最初に注入されたときにアップ/ダウンビットが0に設定されなければならないIS-IS。プレフィックスが低いレベル（レベル1に例えばレベル2）の高いレベルからアドバタイズされた場合、ビットは、プレフィックス階層を下り走行したことを示す、1に設定しなければなりません。アップ/ダウンビット1に設定されているプレフィックスだけ低いレベルに階層、すなわちダウンアドバタイズされてもよいです。
These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring that there are no persistent forwarding loops.
IS-ISは、追加のレベルを有することが、将来的に拡張された場合でも、これらのセマンティクスが適用されます。プレフィックスが唯一IS-ISの階層に従うことを保証することによって、我々はそれによって、永続的な転送ループが存在しないことを保証すること、情報がループしないことを被保険者しています。
If a prefix is advertised from one area to another at the same level, then the up/down bit SHALL be set to 1. This situation can arise when a router implements multiple virtual routers at the same level, but in different areas.
プレフィックスが同じレベルで一つの領域から別のものに宣伝されている場合は、アップ/ダウンビットルータが同じレベルではなく、さまざまな分野で複数の仮想ルータを実装したときに、この状況が発生する可能性が1に設定されなければなりません。
The semantics of the up/down bit in the new extended IP reachability TLV are identical to the semantics of the up/down bit defined in RFC 2966 [2].
新しい拡張IP到達可能性TLVでアップ/ダウンビットの意味は、RFC 2966で定義されたアップ/ダウンビットの意味と同一である[2]。
The extended IP reachability TLV can hold sub-TLVs that apply to a particular prefix. This allows for easy future extensions. If there are no sub-TLVs associated with a prefix, the bit indicating the presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the first octet after the prefix will be interpreted as the length of all sub-TLVs associated with this IPv4 prefix. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets.
拡張IP到達可能性TLVは、特定のプレフィックスに適用されたサブTLVを保持することができます。これは、簡単に将来の拡張が可能になります。プレフィックスに関連付けられたサブのTLVが存在しない場合、このビットは1に設定されている場合、サブのTLVの存在を示すビットが0に設定される、接頭辞の後の最初のオクテットは全てのサブの長さとして解釈されこのIPv4の接頭辞に関連付けられている-TLVs。エンコードは、サブのTLVの255個のオクテットを可能にしながら、最大値は全体的な拡張IP到達可能性TLVに収まることができないのでご注意ください。実用的な最大値は255オクテットマイナス上記5-9オクテット、又は250オクテットです。
This document does not define any sub-TLVs for the extended IP reachability TLV.
この文書では、拡張IP到達可能性TLVのための任意のサブTLVを定義していません。
The Traffic Engineering router ID TLV is TLV type 134.
トラフィックエンジニアリングルータID TLVは、TLVタイプ134です。
The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards:
ルータID TLVは、LSPを発信するルータの4オクテットのルータIDを含んでいます。これは、いくつかの点で有用です。
For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces.
トラフィックエンジニアリングのために、それは我々が常にかかわらず、ノードのインタフェースの状態を、離れた複数のホップから到達可能になりますパスで参照することができ、単一の安定したアドレスを持っていることを保証します。
If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies.
OSPFドメインにもアクティブな場合、トラフィックエンジニアリングは、OSPFとトポロジ-ISとの間のマッピングを計算することができます。
If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements traffic engineering, it MUST include this TLV in its LSP. This TLV SHOULD not be included more than once in an LSP.
ルータがトラフィックエンジニアリングを実装していない場合は、トラフィックエンジニアリングルータID TLVを追加したり、省略することができます。ルータがトラフィックエンジニアリングを実装している場合、それはそのLSPにこのTLVを含まなければなりません。このTLVは、複数回LSPよりも含まれるべきではありません。
If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises prefixes via the Border Gateway Protocol (BGP) with the BGP next hop attribute set to the BGP router ID, the Traffic Engineering router ID SHOULD be the same as the BGP router ID.
ルータはそのLSPにおけるトラフィックエンジニアリングルータID TLVをアドバタイズし、それがBGPルータIDに設定BGPネクストホップ属性を持つボーダーゲートウェイプロトコル（BGP）を経由してプレフィックスを広告する場合は、トラフィックエンジニアリングルータIDは同じであるべきである場合BGPルータID。
Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table because this can lead to forwarding loops when interacting with systems that do not support this TLV.
このTLVをサポートしないシステムと対話するときに、これはフォワーディングループにつながる可能性があるため、実装は、その転送テーブルにルータIDの/ 32プレフィックスを注入してはなりません。
This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV code-point registry:
この文書では、ISIS TLVコードポイントレジストリに反映されている次の新しいISIS TLVタイプを定義します。
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
22 The extended IS reachability TLV n y n
134 The Traffic Engineering router ID TLV n y n
135 The extended IP reachability TLV n y n
IANA has created the following new registries.
IANAは、次の新しいレジストリを作成しました。
This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the proposed use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]).
このレジストリは、値の範囲が0〜255であるTLV 22のサブTLVのためのコードポイントを含んでいます。レジストリ内の割り当てはIESG（[5]参照）によって割り当てられた指定された専門家によって割り当てられた値と承認の提案された使用説明書を必要とします。
Taking into consideration allocations specified in this document, the registry has been initialized as follows:
次のようにこの文書で指定された対価の配分を考慮して、レジストリが初期化されています。
Type Description
---- -----------------------------------
0-2 unassigned
3 Administrative group (color)
4-5 unassigned
6 IPv4 interface address
7 unassigned
8 IPv4 neighbor address
9 Maximum link bandwidth
10 Reservable link bandwidth
11 Unreserved bandwidth
12-17 unassigned
18 TE Default metric
19-254 unassigned
255 Reserved for future expansion
This registry contains codepoints for Sub-TLVs of TLV 135. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]).
このレジストリは、値の範囲が0〜255であるTLV 135のサブTLVのためのコードポイントを含んでいます。レジストリ内の割り当ては、（[5]参照）IESGによって割り当てられた指定された専門家によって割り当てられた値と承認の使用説明書を必要とします。
No codepoints are defined in this document.
いかなるコードポイントは、この文書で定義されていません。
[1] ISO, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589:2002, Second Edition
[1] ISO、「中間システム中間システムドメイン内のRouteing交換プロトコルへ（ISO 8473）接続モード・ネットワーク・サービスを提供するための議定書と併せて使用する」、10589国際規格を：2002、第2版
[2] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[2]李、T.、Przygienda、T.とH.スミット、 "IS-IS二レベルでドメイン全体のプレフィックス配布"、RFC 2966、2000年10月。
[3] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990
[3] Callon、R.W.は、 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"、RFC 1195、1990年12月
[4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[4] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、 "トラフィック過剰性能MPLSのための要件"、RFC 2702、1999年9月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
This document raises no new security issues for IS-IS.
この文書では、IS-ISのための新しいセキュリティ上の問題を提起していません。
The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work.
作者はこの作品で彼らのコメントのためのヤコフ・レックターとデイブ・カッツに感謝したいと思います。
Henk Smit
ヘンクスミット
EMail: hhwsmit@xs4all.nl
メールアドレス：hhwsmit@xs4all.nl
Tony Li
トニー・リー
EMail: tony.li@tony.li
メールアドレス：tony.li@tony.li
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。