[要約] RFC 5305は、IS-ISプロトコルにおけるトラフィックエンジニアリングの拡張に関する仕様です。このRFCの目的は、ネットワークのトラフィック制御と最適化を可能にするために、IS-ISプロトコルにトラフィックエンジニアリング機能を追加することです。
Network Working Group T. Li
Request for Comments: 5305 Redback Networks, Inc.
Obsoletes: 3784 H. Smit
Category: Standards Track October 2008
IS-IS Extensions for Traffic Engineering
トラフィックエンジニアリング用のIS-IS拡張機能
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）の現在のエディションを参照してください。このメモの配布は無制限です。
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 Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
このドキュメントでは、交通工学（TE）をサポートするための中間システムへの中間システム（IS-IS）プロトコルへの拡張について説明します。このドキュメントは、中間システム（ルーター）がLink State Protocol Dataユニット（LSP）に配置できる新しい情報を指定することにより、IS-ISプロトコルを拡張します。この情報は、トラフィックエンジニアリングの計算に役立つネットワークの状態に関する追加の詳細について説明しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Introducing Sub-TLVs ............................................3
3. The Extended IS Reachability TLV ................................3
3.1. Sub-TLV 3: Administrative Group (color, resource class) ....6
3.2. Sub-TLV 6: IPv4 Interface Address ..........................6
3.3. Sub-TLV 8: IPv4 Neighbor Address ...........................6
3.4. Sub-TLV 9: Maximum Link Bandwidth ..........................7
3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth ..............7
3.6. Sub-TLV 11: Unreserved Bandwidth ...........................7
3.7. Sub-TLV 18: Traffic Engineering Default Metric .............8
4. The Extended IP Reachability TLV ................................8
4.1. The up/down Bit ...........................................10
4.2. Expandability of the Extended IP Reachability TLV
with Sub-TLVs .............................................11
4.3. The Traffic Engineering Router ID TLV .....................11
5. IANA Considerations ............................................12
5.1. TLV Codepoint Allocations .................................12
5.2. New Registries ............................................13
5.2.1. Sub-TLVs for the Extended IS Reachability TLV ......13
5.2.2. Sub-TLVs for the Extended IP Reachability TLV ......15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
The IS-IS protocol is specified in ISO 10589 [ISO-10589], with extensions for supporting IPv4 specified in [RFC1195]. 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プロトコルはISO 10589 [ISO-10589]で指定されており、[RFC1195]で指定されたIPv4をサポートするための拡張機能があります。各中間システム（IS）（ルーター）は、ルーティング情報を持つ1つ以上のIS-ISリンク状態プロトコルデータユニット（LSP）を宣伝しています。各LSPは、固定ヘッダーと多数のタプルで構成されており、それぞれがタイプ、長さ、値で構成されています。このようなタプルは一般にTLVとして知られており、柔軟で拡張可能な形式で情報をエンコードする良い方法です。
This document contains the design of new TLVs to replace the existing IS Neighbor TLV and 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 [RFC2702]. Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes.
このドキュメントには、既存のIS Neighbor TLVおよびIP Reachability TLVを置き換え、IS-IS LSPへの特定のリンクの特性に関する追加情報を含めるための新しいTLVの設計が含まれています。このドキュメントで説明されている特性は、トラフィックエンジニアリングに必要です[RFC2702]。二次目標には、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に移行するメカニズムと手順については説明していません。
A prior version of this document was published as [RFC3784] with Informational status. This version is on the standards track.
このドキュメントの以前のバージョンは、情報ステータスを持つ[RFC3784]として公開されました。このバージョンは標準トラックにあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
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でルーティング情報をエンコードする新しい方法を紹介します。新しいオブジェクトはsub-tlvと呼ばれます。サブTLVは、通常のTLVに似ています。彼らは通常のTLVと同じ概念を使用します。違いは、TLVがIS-ISパケット内に存在し、サブTLVがTLV内に存在することです。TLVは、IS-ISパケットに追加の情報を追加するために使用されます。サブTLVは、特定のTLVに追加の情報を追加するために使用されます。各サブTLVは、3つのフィールド、1オクテット型フィールド、1オクテットの長さフィールド、および値のゼロ以上のオクテットで構成されています。タイプフィールドは、値フィールドのアイテムのタイプを示します。長さフィールドは、オクテットの値フィールドの長さを示します。各サブTLVは、複数のアイテムを潜在的に保持できます。サブTLVのアイテムの数は、各アイテムの長さがわかっている場合、Sub-TLV全体の長さから計算できます。未知のサブTLVは、無視され、受領時にスキップされます。
The Sub-TLV type space is managed by the IETF IS-IS WG [ISIS-WG]. 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.
Sub-TLVタイプスペースは、IETF IS WG [ISIS-WG]によって管理されます。新しいタイプの値は、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 [ISO-10589]) 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 [RFC5302] 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.
既存のIS Reachability（ISO 10589 [ISO-10589]で定義されているTLV Type 2）には、IS近隣のシリーズに関する情報が含まれています。各隣接には、デフォルトのメトリック、遅延、金銭的コスト、信頼性、および隣接する隣人の7オクテットIDを含む構造があります。この情報のうち、デフォルトのメトリックが一般的に使用されています。デフォルトのメトリックは現在1オクテットで、メトリックが内部または外部であるかどうかを示すためにビットを使用し、元々使用されていなかったが、後に[RFC5302]によって定義されたビットがアップ/ダウンビットであると定義されました。残りの6ビットは、実際のメトリックを保存するために使用され、0〜63のメートリック範囲が可能になります。この制限は、私たちが持ち上げたい制限の1つです。
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は、隣人ごとに11オクテットを消費し、メトリック用に4オクテット、隣接識別のために7オクテットを消費します。複数の隣接を示すために、この構造はISの到達可能性TLV内で繰り返されます。TLVは255オクテットのコンテンツに制限されているため、単一のTLVは最大23人の隣人を記述できます。IS IS RECHANIGE TLVは、LSPフラグメント内で繰り返して、さらなる隣接を記述できます。
The proposed extended IS reachability TLV contains a new data structure, consisting of:
提案されている拡張は、次のような新しいデータ構造が含まれています。
7 octets of system ID and pseudonode number
システムIDおよび擬似ノード番号の7オクテット
3 octets of default metric
デフォルトメトリックの3オクテット
1 octet of length of sub-TLVs
サブTLVの長さの1オクテット
0-244 octets of sub-TLVs, where each sub-TLV consists of a sequence of
0-244サブTLVのオクテット、各サブTLVはのシーケンスで構成されています
1 octet of sub-type
サブタイプの1オクテット
1 octet of length of the Value field of the sub-TLV
サブTLVの値フィールドの長さの1オクテット
0-242 octets of value
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. There is no defined mechanism for extending the sub-TLV space. Thus, wasting sub-TLV space is discouraged.
したがって、サブTLVが使用されない場合、新しいエンコードには11個のオクテットが必要であり、最大23人の隣人を含めることができます。エンコードでは255オクテットのサブTLVが許可されていますが、最大値は全体的なものでは到達可能性TLVではありません。実用的な最大値は、上記の11オクテット、または244オクテットを引いた255オクテットです。サブ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 Shortest Path First (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ビットであると仮定します。したがって、MAX_PATH_METRICを4,261,412,864（0xfe000000、2^32-2^25）に選択しました。
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 established here:
特定のサブTLVがここに確立されます：
+------------+----------------+-------------------------------------+
| Sub-TLV | Length | Name |
| type | (octets) | |
+------------+----------------+-------------------------------------+
| 3 | 4 | Administrative group (color) |
| | | |
| 6 | 4 | IPv4 interface address |
| | | |
| 8 | 4 | IPv4 neighbor address |
| | | |
| 9 | 4 | Maximum link bandwidth |
| | | |
| 10 | 4 | Maximum reservable link bandwidth |
| | | |
| 11 | 32 | Unreserved bandwidth |
| | | |
| 18 | 3 | TE Default metric |
| | | |
| 250-254 | | Reserved for Cisco specific |
| | | extensions |
| | | |
| 255 | | Reserved for future expansion |
+------------+----------------+-------------------------------------+
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.
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.
管理グループ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」と呼ばれます。
This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張性が拡張される各範囲で最大で1回表示されるはずです。
This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times.
このSub-TLVには、（メイン）TLVで説明されているインターフェイスの4-OCTET 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.
実装は、インターフェイスアドレスのA /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をサポートしていないシステムと対話する場合、これは転送ループにつながる可能性があるため、実装は近隣アドレスのA /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ビットでエンコードされます。ユニットは1秒あたりのバイト（ビットではありません！）です。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張性が拡張される各範囲で最大で1回表示されるはずです。
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ビットでエンコードされています。ユニットは1秒あたりのバイト（ビットではありません！）です。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはオプションです。このサブTLVは、拡張性が拡張される各範囲で最大で1回表示されるはずです。
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.
優先順位と先制が必要なため、各ヘッドエンドは、各優先レベルで予約された帯域幅の量を知る必要があります。したがって、このSub-TLVには、8つの32ビットIEEEフローティングポイント番号が含まれています。ユニットは1秒あたりのバイト（ビットではありません！）です。値は、0〜7のセットアップ優先度で予約できる帯域幅に対応し、サブTLVの開始時に発生する優先度0とサブTLVの終了時に優先度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は、拡張性が拡張される各範囲で最大で1回表示されるはずです。
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ビットであると仮定します。したがって、MAX_PATH_METRICを4,261,412,864（0xfe000000、2^32-2^25）に選択しました。
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は、拡張性が拡張される各範囲で最大で1回表示されるはずです。このサブTLVなしでリンクが宣伝されている場合、トラフィックエンジニアリングSPF計算は、拡張された部分の固定部分で宣伝されているこのリンクの通常のデフォルトメトリックを使用する必要があります。
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 [RFC1195]) carry IP prefixes in a format that is analogous to the IS neighbor TLV from ISO 10589 [ISO-10589]. 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（[RFC1195]で定義されているTLVタイプ128およびTLVタイプ130）は、ISO 10589 [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. [RFC1195] 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によって完全には対処されていない重要な問題があります。[RFC1195]は、ルーターがレベル階層で上向きにプレフィックスを宣伝できるようにすることができます。残念ながら、レベルの階層で前方にプレフィックスを宣伝するメカニズムはありませんでした。
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ビットメトリックを提供し、階層で接頭辞が「ダウン」されていることを示すために少し追加します。
The proposed extended IP reachability TLV contains a new data structure, consisting of:
提案されている拡張IPリーチビリティTLVには、以下で構成される新しいデータ構造が含まれています。
4 octets of metric information
メトリック情報の4オクテット
1 octet of control information, consisting of
1オクテットの制御情報
1 bit of up/down information
1ビットのアップ/ダウン情報
1 bit indicating the presence of sub-TLVs
サブTLVの存在を示す1ビット
6 bits of prefix length
6ビットのプレフィックス長
0-4 octets of IPv4 prefix
IPv4プレフィックスの0-4オクテット
0-250 optional octets of sub-TLVs, if present consisting of
0-250サブTLVのオプションのオクテット、で構成される場合は存在する場合
1 octet of length of sub-TLVs
サブTLVの長さの1オクテット
0-249 octets of sub-TLVs, where each sub-TLV consists of a sequence of
0-249サブTLVのオクテット、各サブTLVはのシーケンスで構成されています
1 octet of sub-type
サブタイプの1オクテット
1 octet of length of the Value field of the sub-TLV
サブTLVの値フィールドの長さの1オクテット
0-247 octets of value
0-247値のオクテット
This data structure can be replicated within the TLV, as long as the maximum length of the TLV is not exceeded.
このデータ構造は、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（0xfe00000000よりも大きいメトリックで宣伝されている場合、このプレフィックスは通常の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 [RFC1195] 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ルーティングを介してプレフィックスを学習し、そのプレフィックスをレベル1の領域に宣伝する場合に問題が発生し、別のルーターがルートをピックアップし、プレフィックスをレベル2バックボーンに宣伝する可能性があります。元のソースがプレフィックスを撤回した場合、それらの2つのルーターがそれらの間にルーティングループを持つことになります。ループパスの一部はレベル1ルーティングを介して、ループされたパスの他の部分はレベル2ルーティングを介して行われます。[RFC1195]がもたらすソリューションは、レベルの階層内の広告のプレフィックスのみを上方に許可し、階層でプレフィックスの広告を下に禁止することです。
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で新しい情報が定義されます。このビットは、アップ/ダウンビットと呼ばれます。プレフィックスが最初にIS-ISに注入された場合、アップ/ダウンビットは0に設定されます。プレフィックスがより高いレベルから低レベル（レベル2からレベル1など）に宣伝されている場合、ビットを1に設定する必要があります。プレフィックスが階層を下って移動したことを示します。アップ/ダウンビットが1に設定されているプレフィックスは、階層のみで宣伝される場合があります。つまり、より低いレベルになります。
These semantics apply even if IS-IS is extended in the future to have additional levels. By ensuring that prefixes follow only the IS-IS hierarchy, we have ensured that the information does not loop, thereby ensuring 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 [RFC5302].
新しい拡張IPリーチビリティTLVのアップ/ダウンビットのセマンティクスは、[RFC5302]で定義されているアップ/ダウンビットのセマンティクスと同じです。
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がない場合、サブTLVの存在を示すビットは0に設定されます。このIPv4プレフィックスに関連付けられているTLV。エンコードでは255オクテットのサブTLVが許可されていますが、最大値は全体的な拡張IPリーチビリティTLVに適合できないことに注意してください。実用的な最大値は、上記の5-9オクテット、または250オクテットを引いた255オクテットです。
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-OCTETルーター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-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を追加または省略する場合があります。ルーターがトラフィックエンジニアリングを実装する場合、このTLVをLSPに含める必要があります。この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の次のホップ属性をBGPルーターIDに設定したBorder Gateway Protocol（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のA /32プレフィックスを転送テーブルに挿入しないでください。
Prior IANA requests for this purpose were covered as part of [RFC3784]. The text of those requests is reproduced here for completeness and consistency.
この目的のための以前のIANAリクエストは、[RFC3784]の一部としてカバーされました。これらのリクエストのテキストは、完全性と一貫性のためにここで再現されています。
This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV codepoint registry:
このドキュメントでは、ISIS TLV CodePointレジストリに反映されている次の新しいIS-IS 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 [RFC5226]).
このレジストリには、TLV 22のサブTLVのコードポイントが含まれています。値の範囲は0-255です。レジストリ内の割り当てでは、IESGによって割り当てられた指定された専門家による割り当てられた値と承認の提案された使用の文書が必要です（[RFC5226]を参照）。
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 | Link Local/Remote Identifiers |
| | |
| 5 | unassigned |
| | |
| 6 | IPv4 interface address |
| | |
| 7 | unassigned |
| | |
| 8 | IPv4 neighbor address |
| | |
| 9 | Maximum link bandwidth |
| | |
| 10 | Maximum Reservable link bandwidth |
| | |
| 11 | Unreserved bandwidth |
| | |
| 12-17 | unassigned |
| | |
| 18 | TE Default metric |
| | |
| 19 | Link-attributes |
| | |
| 20 | Link Protection Type |
| | |
| 21 | Interface Switching Capability |
| | Descriptor |
| | |
| 22 | Bandwidth Constraints |
| | |
| 23-249 | unassigned |
| | |
| 250-254| Reserved for Cisco specific |
| | extensions |
| | |
| 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 [RFC5226]). No codepoints are defined in this document.
このレジストリには、TLV 135のサブTLVのコードポイントが含まれています。値の範囲は0-255です。レジストリ内の割り当てには、IESGによって割り当てられた指定された専門家による割り当てられた値と承認の使用に関するドキュメントが必要です（[RFC5226]を参照）。このドキュメントでは、コードポイントは定義されていません。
This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC5304].
このドキュメントは、IS-ISの新しいセキュリティの問題を提起しません。IS-ISの一般的なセキュリティに関する考慮事項については、[RFC5304]を参照してください。
The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work. This work was funded in part by Procket Networks and Juniper Networks.
著者は、Yakov RekhterとDave Katzがこの作品についてコメントしてくれたことに感謝したいと思います。この作業は、Procke NetworksとJuniper Networksによって部分的に資金提供されていました。
[ISO-10589] ISO, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589: 2002, Second Edition, 2002.
[ISO-10589] ISO、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するためのドメイン内のシステム内領域内領域内領域内領域内領域内領域内部ルーティング情報交換プロトコル」、International Standard 10589：2002、第2版、2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, October 2008.
[RFC5302] Li、T.、Smit、H。、およびT. Przygienda、「2レベルIS-ISを備えたドメイン全体の接頭分布」、RFC 5302、2008年10月。
[ISIS-WG] IS-IS for IP Internets (isis) <http://www.ietf.org/html.charters/isis-charter.html>
[ISIS-WG] IS-IS IS for-IS（ISIS）<http://www.ietf.org/html.charters/isis-charter.html>
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLS上のトラフィックエンジニアリングの要件」、RFC 2702、1999年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS暗号認証」、RFC 5304、2008年10月。
Authors' Addresses
著者のアドレス
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
Tony Li Redback Networks、Inc。300 Holger Way San Jose、CA 95134 USA
Phone: +1 408 750 5160
EMail: tony.li@tony.li
Henk Smit
ヘンクスミット
EMail: hhw.smit@xs4all.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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.
この文書は、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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。