Network Working Group T. Przygienda
Request for Comments: 5120 Z2 Sagl
Category: Standards Track N. Shen
Cisco Systems
N. Sheth
Juniper Networks
February 2008
M-ISIS: Multi Topology (MT) Routing in
Intermediate System to Intermediate Systems (IS-ISs)
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 an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology.
この文書は、その雲の中IGPルーティングのための多くのISPが本日中間中間システムへのシステム（IS-ISは）使用中の任意のメカニズムを説明しています。この文書では、単一の内ドメイン、我々はマルチトポロジ（MTS）を呼び出す独立したIPトポロジのセットIS-IS、実行する方法について説明します。このMTの拡張は、主鎖内に、単離されたマルチキャストまたはIPv6島のための別個のIGPルーティングドメインを維持し、またはサブセットを強制的に、そのような元のIGPトポロジの「上」帯域内管理ネットワークなどの目的で、種々のために使用することができますアドレス空間は異なるトポロジに従ってください。
Maintaining multiple MTs for IS-IS [ISO10589] [RFC1195] in a backwards-compatible manner necessitates several extensions to the packet encoding and additional Shortest Path First (SPF) procedures. The problem can be partitioned into the forming of adjacencies and advertising of prefixes and reachable intermediate systems within each topology. Having put all the necessary additional information in place, it must be properly used by MT capable SPF computation. The following sections describe each of the problems separately. To simplify the text, "standard" IS-IS topology is defined to be MT ID #0 (zero).
下位互換性の方法でIS-IS [ISO10589] [RFC1195]のための複数のMTを維持することは、パケット符号化及び追加の最短パス優先（SPF）の手順にいくつかの拡張を必要とします。問題は、各トポロジ内の隣接関係及びプレフィックスの広告と到達可能な中間システムの形成に分割することができます。代わりにすべての必要な追加情報を入れた、それが適切にMTが可能なSPF計算で使用する必要があります。次のセクションでは、個別の問題のそれぞれについて説明します。テキストを簡単にするために、 "標準" トポロジはMT ID＃0（ゼロ）になるように定義されたIS-IS。
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]に記載されているように解釈されます。
CSNP Complete Sequence Number Packet. Used to describe all the contents of a link state database of IS-IS.
シーケンス番号のパケットを完了しCSNP。 IS-ISのリンクステートデータベースのすべての内容を記述するために使用されます。
DIS Designated Intermediate System. The intermediate system elected to advertise the pseudo-node for a broadcast network.
DISは、中間システムを指定します。中間システムは、放送ネットワーク用の擬似ノードを宣伝することを選択しました。
IIH IS-IS Hello. Packets that are used to discover adjacent intermediate systems.
IIHこんにちは-IS。隣接する中間システムを発見するために使用されるパケット。
LSP Link State Packet. Packet generated by an intermediate system and lists adjacent systems, prefixes, and other information.
LSPリンクステートパケット。中間システムとリスト隣接システム、プレフィックス、およびその他の情報により生成されたパケット。
PSNP Partial Sequence Number Packet. Used to request information from an adjacent intermediate system's link state database.
PSNP部分シーケンス番号パケット。隣接する中間システムのリンク状態データベースから情報を要求するために使用します。
SPF Shortest Path First. An algorithm that takes a database of nodes within a domain and builds a tree of connectivity along the shortest paths through the entire network.
SPF最短パスファースト。ドメイン内のノードのデータベースを取得し、ネットワーク全体を通る最短経路に沿った接続のツリーを構築するアルゴリズム。
Each adjacency formed MUST be classified as belonging to a set of MTs on the interface. This is achieved by adding a new TLV into IIH packets that advertises to which topologies the interface belongs. If MT #0 is the only MT on the interface, it is optional to advertise it in the new TLV. Thus, not including such a TLV in the IIH implies MT ID #0 capability only. Through this exchange of MT capabilities, a router is able to advertise the IS TLVs in LSPs with common MT set over those adjacencies.
形成された各隣接インターフェイス上のMTの組に属するものとして分類されなければなりません。これは、インターフェイスが属するトポロジーアドバタイズするIIHパケットに新しいTLVを追加することによって達成されます。 MT＃0は、インターフェイス上の唯一のMTである場合、新しいTLVでそれを宣伝するためにオプションです。したがって、IIHでそのようなTLVを含むのみMT ID＃0の能力を意味しません。 MT能力のこの交換により、ルータは、それらの隣接関係の上に共通のMTを設定したのLSPにIS TLVを宣伝することができます。
The case of adjacency contains multiple MTs on an interface, and if there exists an overlapping IP address space among the topologies, additional mechanisms MUST be used to resolve the topology identity of the incoming IP packets on the interface. See further discussion in Section 8.2.2 of this document.
隣接の場合は、インターフェイス上の複数のMTが含まれており、トポロジの間で重複するIPアドレス空間が存在する場合、追加の機構はインターフェイス上の着信IPパケットのトポロジーの同一性を解決するために使用されなければなりません。このドキュメントのセクション8.2.2でさらに議論を参照してください。
Adjacencies on point-to-point interfaces are formed as usual with IS-IS routers not implementing MT extensions. If a local router does not participate in certain MTs, it will not advertise those MT IDs in its IIHs and thus will not include that neighbor within its LSPs. On the other hand, if an MT ID is not detected in the remote side's IIHs, the local router MUST NOT include that neighbor within its LSPs. The local router SHOULD NOT form an adjacency if they don't have at least one common MT over the interface.
ポイントツーポイントインターフェイス上の隣接関係はMT拡張を実装していないIS-ISルータといつものように形成されています。ローカルルータは、特定のMTに参加していない場合は、そのLSPの内にそのネイバーは含まれませんので、そのIIHSのものMT IDをアドバタイズしません。 MT IDは、リモート側のIIHSに検出されない場合一方、ローカルルータはそのLSPの内にそのネイバーを含んではいけません。彼らはインタフェースを介して、少なくとも一つの共通のMTを持っていない場合、ローカルルータは、隣接関係を形成してはなりません。
On a LAN, all the routers on the LAN that implement the MT extension MAY advertise their MT capability TLV in their IIHs. If there is at least one adjacency on the LAN interface that belongs to this MT, the MT capable router MUST include the corresponding MT IS Reachable TLV in its LSP, otherwise it MAY include this MT IS Reachable TLV in its LSP if the LAN interface participates in this MT set.
LAN上で、MT拡張を実装し、LAN上のすべてのルータは彼らのIIHSで自分のMT機能TLVを広告するかもしれません。このMTに属しているLANインターフェイス上の少なくとも一つの隣接関係があれば、MTできるルータは、それ以外の場合は、LANインターフェイスが参加している場合、このMTはそのLSPに到達可能TLV IS含み、対応するMTは、そのLSPで到達可能TLV IS含まなければなりませんこのMTのセットインチ
Two routers on a LAN SHALL always establish adjacency, regardless of whether or not they have a common MT. This is to ensure all the routers on the LAN can correctly elect the same DIS. The IS SHOULD NOT include the MT IS TLV in its LSP if none of the adjacencies on the LAN contain this MT.
LAN上の2つのルータは関係なく、常に彼らが共通のMTを持っているかどうかの、隣接関係を確立しなければなりません。これは正確に同じDISを選出することができ、LAN上のすべてのルータを確保することです。 ISは、LAN上の隣接関係のどれもが、このMTが含まれていない場合はMTがそのLSPにTLV IS含めるべきではありません。
The DIS, CSNP, and PSNP functions are not changed by MT extension.
DIS、CSNP、およびPSNP機能は、MTの拡張によって変更されません。
A router MUST include within its LSPs in the Reachable Intermediate Systems TLV-only adjacent nodes that are participating in the corresponding topology and advertise such TLVs only if it participates itself in the corresponding topology. The Standard Reachable Intermediate Systems TLV is acting here as MT ID #0, the equivalent of the newly introduced MT Reachable Intermediate Systems TLV. A router MUST announce the MT IS TLV when there is at least one adjacency on the interface that belongs to this MT, otherwise it MAY announce the MT IS TLV of an adjacency for a given MT if this interface participates in the LAN.
ルータは、対応するトポロジーに参加している到達可能な中間システムTLVのみ隣接ノードにそののLSP内に含まれ、それは、対応するトポロジー自体に関与する場合にのみ、そのようなTLVを宣伝しなければなりません。標準届い中間システムTLVは、MT ID＃0として、ここで新たに導入されたMT到達可能な中間システムTLVと同等の機能しています。ルータはMTを発表しなければならない。このMTに所属するインターフェイス上の少なくとも一つの隣接関係があるとき、それ以外の場合は、このインタフェースは、LANに参加する場合はMTが与えられたMTの隣接のTLV IS発表するかもしれない、TLVです。
Since it is not possible to prevent a router that does not understand MT extensions from being responsible for the generation of the according pseudo-node, it is possible to neither introduce special TLVs in the pseudo-node LSPs, nor run distinct DIS elections per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain in its IS Reachable TLV all nodes on the LAN as usual, regardless of their MT capabilities. In other words, there is no change to the pseudo-node LSP construction.
それは応じて擬似ノードの世代の責任であることからMTの拡張を理解していないルータを防止することが可能ではないので、それは擬似ノードLSPの中で特別なTLVを導入していない、またMTごとに異なるDIS選挙を実行して、どちらもすることが可能です。したがって、DISによって生成された擬似ノードLSPは関係なくMT能力の、そのIS到達可能TLVにいつものようにLAN上のすべてのノードを含まなければなりません。換言すれば、擬似ノードLSPの構成に変化はありません。
For each of the MTs, a router could become potentially partitioned, overloaded, and attached independently. To prevent unnecessary complexity, MT extensions do not support MT based partition repair. The overload, partition, and attached bits in the LSP header only reflect the status of the default topology.
MTの各々に対して、ルータは、潜在的に、分配過負荷、および独立して付着する可能性があります。不必要な複雑さを回避するために、MTの拡張子はMTベースのパーティションの修復をサポートしていません。 LSPヘッダ内の過負荷、パーティション、および接続されているビットは、デフォルトのトポロジーの状態を反映します。
Attached bit and overload bit are part of the MT TLV being distributed within a node's LSP fragment zero. Since each adjacency can belong to different MTs, it is possible that some MTs are L2 attached, and others are not on the same router. The overload bit in the MT TLV can be used to signal the topology being overloaded. An MT-based system is considered overloaded if the overload bit in the MT is set.
添付ビット過負荷ビットMT TLVは、ノードのLSPフラグメントゼロ内に分散されているの一部です。各隣接関係が異なるMTに属することができるので、いくつかのMTがL2接続されている可能性があり、他は同じルータではありません。 MT TLVにおける過負荷ビットは、オーバーロードされたトポロジーを知らせるために使用することができます。 MTベースのシステムは、MTでの過負荷ビットが設定されている場合、過負荷状態と考えられています。
Route leaking between the levels SHOULD only be performed within the same MT.
レベル間のルートリークは、同じMT以内に行われるべきです。
Each of the MTs commands its own address space so a new TLV is necessary for prefixes stored in MTs other than MT ID #0. To make the encoding less confusing when same prefixes are present in multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV in Traffic Engineered (TE) extensions, a new TLV is introduced for that purpose that closely follows TE encoding [RFC3784].
新しいTLVは、MT ID＃0以外のMTに保存されているプレフィックスのために必要ですので、MTのそれぞれは、独自のアドレス空間を指令します。同じ接頭辞が複数のMTに存在していると、むしろ交通エンジニア（TE）の拡張機能で、サブTLVを追加するよりも、MTあたりのSPFを加速するときのエンコーディングが少ない混乱にするために、新しいTLVは密接TEエンコーディングを以下のような目的のために導入された[RFC3784 ]。
Each MT MUST run its own instance of the decision process. The pseudo-node LSPs are used by all topologies during computation. Each non-default topology MAY have its attached bit and overload bit set in the MT TLV. A reverse-connectivity check within SPF MUST follow the according MT to assure the bi-directional reachability within the same MT.
各MTは、意思決定プロセスの独自のインスタンスを実行する必要があります。疑似ノードLSPは、計算中にすべてのトポロジで使用されています。各デフォルト以外のトポロジーは、その添付ビットおよび過負荷ビットはMT TLVに設定されている可能性があります。 SPF内の逆接続性チェックは、同じMT内の双方向の到達性を確保するために応じてMTに従わなければなりません。
The results of each computation SHOULD be stored in a separate Routing Information Base (RIB), in normal cases, otherwise overlapping addresses in different topologies could lead to undesirable routing behavior, such as forwarding loops. The forwarding logic and configuration need to ensure the same MT is traversed from the source to the destination for packets. The nexthops derived from the MT SPF MUST belong to the adjacencies conforming to the same MT for correct forwarding. It is recommended for the administrators to ensure consistent configuration of all routers in the domain to prevent undesirable forwarding behavior.
各計算の結果は、転送ループとして、そうでなければ異なるトポロジで重複アドレスが望ましくないルーティング動作につながる可能性が、通常の場合には、別個のルーティング情報ベース（RIB）に保存されるべきです。転送ロジックと構成は同じMTは、パケットの送信元から宛先までトラバースされていることを確認する必要があります。 MT SPF由来nexthopsは正しい転送のために同じMTに準拠した隣接に属している必要があります。管理者は、望ましくない転送動作を防ぐために、ドメイン内のすべてのルータの一貫性のあるコンフィギュレーションを確保することが推奨されます。
No attempt is made in this document to allow one topology to calculate routes using the routing information from another topology inside SPF. Even though it is possible to redistribute and leak routes from another IS-IS topology or from external sources, the exact mechanism is beyond the scope of this document.
試みは、SPF内側別のトポロジーからのルーティング情報を使用してルートを計算するために、1つのトポロジを可能にするために、本書では行われません。それはトポロジーまたは外部ソースからのIS-IS別のルートを再配布し、漏洩することが可能であっても、正確なメカニズムはこの文書の範囲外です。
Four new TLVs are added to support MT extensions. One of them is common for the LSPs and IIHs. Encoding of Intermediate System TLV and IPv4 Reachable Prefixes is tied to traffic engineering extensions [RFC3784] to simplify the implementation effort. The main reasons we chose to use new TLVs instead of using sub-TLVs inside existing TLV type-22 and type-135 are:
四の新のTLVは、MTの拡張をサポートするために追加されます。そのうちの一つは、LSPをとIIHSのための共通です。中間システムTLVとIPv4到達可能なプレフィックスのエンコーディングは、実装作業を簡素化するためにトラフィックエンジニアリング拡張[RFC3784]に接続されています。主な理由は、我々は代わりにあるTLVのタイプ22とタイプ-135を、既存の内側のサブTLVを使用しての新しいTLVを使用することにしました：
1. In many cases, multi-topologies are non-congruent, using the sub-TLV approach will not save LSP space;
1.多くの場合、マルチトポロジはLSPスペースを節約しませんサブTLVのアプローチを使用して、非合同です。
2. Many sub-TLVs are already being used in TLV type-22, and many more are being proposed while there is a maximum limit on the TLV size, from the existing TLVs;
2.サブTLVの多くは、既存のTLVのTLVのサイズに上限があるながら、提案されているTLVタイプ-22、および多くで使用されています。
3. If traffic engineering or some other applications are being applied per topology level later, the new TLVs can automatically inherit the same attributes already defined for the "standard" topology without going through long standard process to redefine them per topology.
3.トラフィックエンジニアリングまたは他のアプリケーションは、トポロジーレベルごとに適用されている場合は、後に、新しいTLVが自動的にトポロジごとに、それらを再定義するために長い標準的なプロセスを経由せずに、すでに「標準」トポロジーのために定義された同じ属性を継承することができます。
The TLV number of this TLV is 229. It contains one or more MTs; the router is participating in the following structure:
このTLVのTLVの数は、それが1つのまたは複数のMTが含まれている229です。ルータは、次のような構造に参加しています。
x CODE - 229
x LENGTH - total length of the value field, it SHOULD be 2
times the number of MT components.
x VALUE - one or more 2-byte MT components, structured
as follows:
No. of Octets
+--------------------------------+
|O |A |R |R | MT ID | 2
+--------------------------------+
Bit O represents the OVERLOAD bit for the MT (only valid in LSP fragment zero for MTs other than ID #0, otherwise SHOULD be set to 0 on transmission and ignored on receipt).
ビットOは、（ID＃0以外のMTのためのLSPフラグメントゼロでのみ有効で、それ以外の場合は送信時に0に設定され、受信時に無視されるべき）MTのための過負荷ビットを表します。
Bit A represents the ATTACH bit for the MT (only valid in LSP fragment zero for MTs other than ID #0, otherwise SHOULD be set to 0 on transmission and ignored on receipt).
ビットAは、（ID＃0以外のMTのためのLSPフラグメントゼロでのみ有効で、それ以外の場合は送信時に0に設定され、受信時に無視されるべき）MTのためのATTACHビットを表します。
Bits R are reserved, SHOULD be set to 0 on transmission and ignored on receipt.
ビットRが予約され、送信時に0に設定され、受信時に無視されるべきです。
MT ID is a 12-bit field containing the ID of the topology being announced.
MT IDが発表されているトポロジのIDを含む12ビットのフィールドです。
This MT TLV can advertise up to 127 MTs. It is announced in IIHs and LSP fragment 0, and can occur multiple times. The resulting MT set SHOULD be the union of all the MT TLV occurrences in the packet. Any other IS-IS PDU occurrence of this TLV MUST be ignored. Lack of MT TLV in hellos and fragment zero LSPs MUST be interpreted as participation of the advertising interface or router in MT ID #0 only. If a router advertises MT TLV, it has to advertise all the MTs it participates in, specifically including topology ID #0 also.
このMT TLVは、127件のMTまで広告を掲載することができます。これは、IIHSとLSPフラグメント0に発表され、かつ複数回発生する可能性があります。結果のMTセットはパケット内のすべてのMT TLVの発生の労働組合であるべきです。その他は、IS-IS、このTLVのPDUの発生を無視しなければなりません。 MT TLVの欠如のhelloとフラグメントにゼロのLSPは、MT ID＃0に広告インタフェースまたはルータの参加として解釈されなければなりません。ルータはMT TLVをアドバタイズした場合、それは、具体的にも、トポロジID＃0を含むことが参加のすべてのMTを、宣伝しています。
The TLV number of this TLV is 222. It is aligned with extended IS reachability TLV type 22 beside an additional two bytes in front at the beginning of the TLV.
このTLVのTLVの数は、TLVの開始時前に、追加の2バイトの横にされた延長到達可能性TLVタイプ22と整列される222です。
x CODE - 222
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of extended IS
reachability TLV, structured as follows:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| extended IS TLV format | 11 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| extended IS TLV format | 11 - 253
+--------------------------------+
Bits R are reserved, SHOULD be set to 0 on transmission and ignored on receipt.
ビットRが予約され、送信時に0に設定され、受信時に無視されるべきです。
MT ID is a 12-bit field containing the non-zero MT ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the standard unicast topology.
MT IDは発表されているトポロジーの非ゼロMT IDを含む12ビットのフィールドです。 IDがゼロの場合TLVを無視しなければなりません。これは、標準のユニキャストトポロジの一貫したビューを確実にするためです。
After the 2-byte MT membership format, the MT IS content is in the same format as extended IS TLV, type 22 [RFC3784]. It can contain up to 23 neighbors of the same MT if no sub-TLVs are used.
2バイトMT会員形式後、MTは、拡張として、コンテンツは、同じ形式でTLV、タイプ22 [RFC3784]があります。何もサブのTLVが使用されていない場合は、同じMTの最大23人の隣人を含めることができます。
This TLV can occur multiple times.
このTLVは、複数回発生する可能性があります。
The TLV number of this TLV is 235. It is aligned with extended IP reachability TLV type 135 beside an additional two bytes in front.
このTLVのTLVの数は、それが前に付加的な2バイトの横拡張IP到達可能性TLVタイプ135と整列される235です。
x CODE - 235 x LENGTH - total length of the value field x VALUE - 2-byte MT membership plus the format of extended IP reachability TLV, structured as follows:
X CODE - 235×長さ - 値フィールドのX値の合計の長さ - 2バイトMTメンバーシッププラス拡張IP到達可能性TLVのフォーマット、次のように構成さ：
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| extended IP TLV format | 5 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| extended IP TLV format | 5 - 253
+--------------------------------+
Bits R are reserved, SHOULD be set to 0 on transmission and ignored on receipt.
ビットRが予約され、送信時に0に設定され、受信時に無視されるべきです。
MT ID is a 12-bit field containing the non-zero ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the standard unicast topology.
MT IDは発表されているトポロジーの非ゼロのIDを含む12ビットのフィールドです。 IDがゼロの場合TLVを無視しなければなりません。これは、標準のユニキャストトポロジの一貫したビューを確実にするためです。
After the 2-byte MT membership format, the MT IPv4 content is in the same format as extended IP reachability TLV, type 135 [RFC3784].
2バイトMT会員形式後、MTのIPv4コンテンツは、拡張IP到達可能性TLV、タイプ135 [RFC3784]と同じ形式です。
This TLV can occur multiple times.
このTLVは、複数回発生する可能性があります。
The TLV number of this TLV is 237. It is aligned with IPv6 Reachability TLV type 236 beside an additional two bytes in front.
このTLVのTLVの数は、それが前に付加的な2バイトの横のIPv6到達可能性TLVタイプ236と整列される237です。
x CODE - 237 x LENGTH - total length of the value field x VALUE - 2-byte MT membership plus the format of IPv6 Reachability TLV, structured as follows:
X CODE - 237×長さ - 値フィールドのX値の合計の長さ - 2バイトMTメンバーシップに加え、次のように構成されたIPv6到達可能性TLVのフォーマット：
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| IPv6 Reachability format | 6 - 253
+--------------------------------+
. .
+--------------------------------+
| IPv6 Reachability format | 6 - 253
+--------------------------------+
Bits R are reserved, SHOULD be set to 0 on transmission and ignored on receipt.
ビットRが予約され、送信時に0に設定され、受信時に無視されるべきです。
MT ID is a 12-bit field containing the ID of the topology being announced. The TLV MUST be ignored if the ID is zero.
MT IDが発表されているトポロジのIDを含む12ビットのフィールドです。 IDがゼロの場合TLVを無視しなければなりません。
After the 2-byte MT membership format, the MT IPv6 context is in the same format as IPv6 Reachability TLV, type 236 [H01].
2バイトMT会員形式後、MTのIPv6コンテキストは、IPv6到達可能性TLV、タイプ236 [H01]と同じ形式です。
This TLV can occur multiple times.
このTLVは、複数回発生する可能性があります。
Certain MT topologies are assigned to serve predetermined purposes:
一定のMTトポロジは、所定の目的を果たすために割り当てられています。
- MT ID #0: Equivalent to the "standard" topology. - MT ID #1: Reserved for IPv4 in-band management purposes. - MT ID #2: Reserved for IPv6 routing topology. - MT ID #3: Reserved for IPv4 multicast routing topology. - MT ID #4: Reserved for IPv6 multicast routing topology. - MT ID #5: Reserved for IPv6 in-band management purposes. - MT ID #6-#3995: Reserved for IETF consensus. - MT ID #3996-#4095: Reserved for development, experimental and proprietary features [RFC3692].
- MTのID＃0： "標準" トポロジと同じです。 - MTのID＃1：IPv4のインバンド管理目的のために予約されています。 - MTのID＃2：IPv6ルーティングトポロジのために予約されています。 - MTのID＃3：IPv4マルチキャストルーティングトポロジのために予約されています。 - MTのID＃4：IPv6マルチキャストルーティングトポロジのために予約されています。 - MTのID＃5：IPv6のインバンド管理目的のために予約されています。 - MTのID番号、6-＃3995：IETFコンセンサスのために予約されています。 - MTのID番号3996-＃4095：実験的な開発、および独自機能[RFC3692]のために予約されています。
Using MT extension for IS-IS routing can result in multiple RIBs on the system. In this section, we list some of the known considerations for IP forwarding in various MT scenarios. Certain deployment scenarios presented here imply different trade-offs in terms of deployment difficulties and advantages obtained.
IS-ISは、システム上で複数のRIBにつながることができますルーティングするためのMT拡張子を使用します。このセクションでは、さまざまなMTシナリオにおけるIPフォワーディングのために知られている注意事項のいくつかをリストアップ。ここで紹介するいくつかの展開シナリオは、取得した展開の難しさと利点の面でさまざまなトレードオフを意味します。
In this case, each MT related route is installed into a separate RIB. Multiple topologies can share the same IS-IS interface on detecting the incoming packet address family. As an example, IPv4 and IPv6 can share the same interface without any further considerations under MT ISIS.
この場合、各MTに関連するルートは、別のRIBにインストールされています。複数のトポロジが同じで-IS着信パケットのアドレスファミリを検出する上でのインターフェイス共有することができます。一例として、IPv4とIPv6がMT ISIS下さらなる考慮せずに同じインタフェースを共有することができます。
In this case, MTs can be used to forward packets from the same address family, even with overlapping addresses, since the MTs have their dedicated interfaces, and those interfaces can be associated with certain MT RIBs and FIBs.
MTSは、その専用のインターフェースを有しており、これらのインターフェイスは、特定のMTリブのFIBに関連付けることができるので、この場合には、MTが、あっても重複アドレスと同じアドレスファミリからのパケットを転送するために使用することができます。
Some additional mechanism is needed to select the correct RIBs for the incoming IP packets to determine the correct RIB to make a forwarding decision. For example, if the topologies are Quality of Service (QoS) partitioned, then the Differentiated Services Code Point (DSCP) bits in the IP packet header can be utilized to make the decision. Some IP headers, or even packet data information, MAY be checked to make the forwarding table selection, for example, the source IP address in the header can be used to determine the desired forwarding behavior.
いくつかの追加のメカニズムは、転送の決定を行うために、正しいRIBを決定するために、着信IPパケットの正しい肋骨を選択するために必要とされます。トポロジは、サービス品質（QoS）のパーティション化されている場合たとえば、その後、IPパケットのヘッダ内のDiffServコードポイント（DSCP）ビットが決定を行うために利用することができます。いくつかのIPヘッダー、あるいはパケットデータ情報は、例えば、ヘッダの送信元IPアドレスが所望の転送動作を決定するために使用することができ、転送テーブルの選択を行うためにチェックすることができます。
This topic is not unique to IS-IS or even to Multi-topology, it is a local policy and configuration decision to make sure the inbound traffic uses the correct forwarding tables. For example, preferred customer packets are sent through a Layer 2 Tunneling Protocol (L2TP) towards the high-bandwidth upstream provider, and other packets are sent through a different L2TP to a normal-bandwidth provider. Those mechanisms are not part of the L2TP protocol specifications.
このトピックでは、IS-ISに特有のものではない、あるいはマルチトポロジには、着信トラフィックが正しい転送テーブルを使用することを確認するために、ローカルポリシーおよび設定の決定です。例えば、好ましい顧客パケットは、高帯域幅の上流プロバイダに向かってレイヤ2トンネリングプロトコル（L2TP）を介して送信され、他のパケットは、通常、帯域幅プロバイダに異なるL2TPを介して送信されます。これらのメカニズムは、L2TPプロトコルの仕様の一部ではありません。
The generic approach of packet to multiple MT RIB mapping over the same inbound interface is outside the scope of this document.
同じ着信インターフェイス上で複数のMTのRIBへのマッピング、パケットの一般的なアプローチは、このドキュメントの範囲外です。
When there is no overlap in the address space among all the MTs, strictly speaking, the destination address space classifies the topology to which a packet belongs. It is possible to install routes from different MTs into a shared RIB. As an example of such a deployment, a special IS-IS topology can be set up for certain External Border Gateway Protocol (eBGP) nexthop addresses.
すべてのMTの間でアドレス空間の重複がない場合には、厳密に言えば、宛先アドレス空間は、パケットが属するトポロジーを分類します。共有RIBに異なるMTからのルートをインストールすることが可能です。こうした展開の一例として、特別にはIS-ISのトポロジーは、特定の外部ボーダーゲートウェイプロトコル（eBGPの）ネクストホップアドレスのために設定することができます。
MT in IS-IS MAY be used even if the resulting RIB is not used for forwarding purposes. As an example, multicast Reverse Path Forwarding (RPF) check can be performed on a different RIB than the standard unicast RIB, albeit an entirely different RIB is used for the multicast forwarding. However, an incoming packet MUST still be clearly identified as belonging to a unique topology.
その結果RIBは転送の目的で使用されていない場合でも、IS-ISでMTを使用することができます。一例として、パス転送（RPF）チェックが全く異なるリブがマルチキャスト転送のために使用されるにもかかわらず、標準的なユニキャストRIBは異なるRIBに行うことができる逆マルチキャスト。ただし、着信パケットは、まだはっきりとユニークなトポロジに属するものとして識別されなければなりません。
When multiple IS-IS topologies exist within a domain, some of the routers can be configured to participate in a subset of the MTs in the network. This section discusses some of the options we have to enable operations or the network management stations to access those routers.
複数のIS-ISトポロジは、ドメイン内に存在する場合、ルータの一部は、ネットワーク内のMTのサブセットに参加するように構成することができます。このセクションでは、我々はそれらのルータにアクセスするための操作やネットワーク管理ステーションを有効にする必要がありますいくつかのオプションについて説明します。
This approach is to set up a dedicated management topology or 'in-band' management topology. This 'mgmt' topology will include all the routers need to be managed. The computed routes in the topology will be installed into the 'mgmt' RIB. In the condition that the 'mgmt' topology uses a set of non-overlapping address space with the default topology, those 'mgmt' routes can also be optionally installed into the default RIB. The advantages of duplicate 'mgmt' routes in both RIBs include: the network management utilities on the system does not have to be modified to use a specific RIB other than the default RIB; the 'mgmt' topology can share the same link with the default topology if so designed.
このアプローチは、専用の管理トポロジや「インバンド」管理トポロジを設定することです。この「MGMT」トポロジーは、すべてのルータが管理する必要が含まれます。トポロジで計算されたルートは、「MGMT」RIBにインストールされます。 「MGMT」トポロジーがデフォルトのトポロジーを有する非重複アドレス空間のセットを使用した状態で、これらの「MGMT」経路はまた、必要に応じてデフォルトのRIBにインストールすることができます。肋骨の両方に重複「MGMT」ルートの利点としては、システム上のネットワーク管理ユーティリティは、デフォルトのRIB以外の特定のRIBを使用するように変更する必要がありません。そのように設計あれば「MGMT」トポロジーはデフォルトのトポロジと同じリンクを共有することができます。
Even in the case that default topology is not used on some of the nodes in the IP forwarding, we MAY want to extend the default topology to those nodes for the purpose of network management. Operators SHOULD set high costs on the links that belong to the extended portion of the default topology. This way, the IP data traffic will not be forwarded through those nodes during network topology changes.
でも、デフォルトのトポロジは、IPフォワーディング内のノードの一部に使用されていない場合には、我々は、ネットワーク管理の目的のためにこれらのノードにデフォルトのトポロジを拡張することもできます。オペレータは、デフォルトのトポロジーの延長部に属しているリンク上で高いコストを設定する必要があります。このように、IPデータトラフィックは、ネットワークトポロジの変更中にそれらのノードを介して転送されることはありません。
The authors would like to thank Andrew Partan, Dino Farinacci, Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, Pekka Savola, Mike Shand, Shankar Vemulapalli, and Les Ginsberg for the discussion, their review, comments, and contributions to this document.
著者は、議論のために彼らのレビュー、コメント、貢献をアンドリューPartan、ディノファリナッチ、デレク・ヨン、アレックスジニン、ステファノPrevidi、ハイジ王、スティーブ・ルオン、ペッカSavola、マイク・シャンド、シャンカルVemulapalli、およびレギンズバーグに感謝したいと思いますこのドキュメントへ。
IS-IS security applies to the work presented. No specific security issues with the proposed solutions are known. The authentication procedure for IS-IS PDUs is the same regardless of MT information inside the IS-IS PDUs.
IS-ISのセキュリティが提示仕事に適用されます。提案されたソリューションとは特定のセキュリティ問題が知られていません。 IS-IS PDUのための認証手続きは関係なく、IS-IS PDUの内部にMT情報と同じです。
Note that an authentication mechanism, such as the one defined in [RFC3567], SHOULD be applied if there is high risk resulting from modification of multi-topology information.
マルチトポロジ情報の変形に起因する高いリスクがある場合、このような[RFC3567]で定義されたもの、などの認証メカニズムは、適用されるべきであることに留意されたいです。
As described in Section 8.2.2, multiple topologies share an interface in the same address space, some mechanism beyond IS-IS needs to be used to select the right forwarding table for an inbound packet. A misconfiguration on the system or a packet with a spoofed source address, for example, can lead to packet loss or unauthorized use of premium network resource.
8.2.2項で述べたように、複数のトポロジは同じアドレス空間にインターフェースを共有する、IS-ISを超えたいくつかのメカニズムは、インバウンドパケットのための右の転送テーブルを選択するために使用する必要があります。システムまたは偽装された送信元アドレスを持つパケットの設定ミスは、例えば、パケットロスやプレミアムネットワークリソースの不正使用につながることができます。
This document defines the following new IS-IS TLV types, which have already been reflected in the IANA IS-IS TLV code-point registry:
この文書は、定義され、次の新しいIS-IS、すでにIANAに反映されているTLVタイプ、IS-IS TLVコードポイントレジストリ：
Name Value
名前値
MT-ISN 222 M-Topologies 229 MT IP. Reach 235 MT IPv6 IP. Reach 237
MT-ISN 222 M-トポロジ229 MT IP。 235 MT IPv6のIPに達します。 237に到達
IANA has created a new registry, "IS-IS Multi-Topology Parameters", with the assignments listed in Section 7.5 of this document and registration policies [RFC2434] for future assignments. The MT ID values range 6-3995 are allocated through Expert Review; values in the range of 3996-4095 are reserved for Private Use. In all cases, assigned values are to be registered with IANA.
IANAは将来の割り当てについては、この文書と登録ポリシーの7.5節に記載されている割り当てと、「IS-ISマルチトポロジパラメータ」[RFC2434]を新しいレジストリを作成しました。 ID値が6から3995の範囲でMTは、専門家レビューを通じて割り当てられています。 3996-4095の範囲内の値は、私的使用のために予約されています。すべての場合において、割り当てられた値は、IANAに登録されることになります。
[ISO10589] ISO. Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO 10589, 1992.
[ISO10589] ISO。コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する中間システムルーティング交換プロトコルへの中間システム。 ISO 10589、1992。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC3567]のLi、T.及びR.アトキンソン、 "中間システム（IS-IS）暗号化認証に中間システム"、RFC 3567、2003年7月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[H01] C. Hopps, "Routing IPv6 with IS-IS", Work in Progress.
[H01] C. Hoppsが、 "IS-ISとルーティングのIPv6"、進行中の作業。
Authors' Addresses
著者のアドレス
Tony Przygienda Z2 Sagl Via Rovello 32 CH-6942 Savosa EMail: prz@net4u.ch
トニーPrzygienda Z2 Sagl経由Rovello 32 CH-6942 Savosaメール：prz@net4u.ch
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA, 95134 USA EMail: naiming@cisco.com
Naimingシェンシスコシステムズ225西タスマン・ドライブサンノゼ、CA、95134 USA電子メール：naiming@cisco.com
Nischal Sheth Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: nsheth@juniper.net
Nischal Shethジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089 USA電子メール：nsheth@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。