[要約] RFC 5120は、IS-ISプロトコルにおけるマルチトポロジ（MT）ルーティングに関する仕様です。このRFCの目的は、IS-ISプロトコルを拡張して、複数のトポロジをサポートすることです。
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)
M-ISIS：中間システムへのマルチトポロジー（MT）ルーティング（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 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）内のオプションのメカニズムについて説明します。このドキュメントでは、単一のIS-ISドメイン内で、マルチトポロジー（MTS）と呼ばれる独立したIPトポロジのセットを実行する方法について説明します。このMT拡張は、元の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 [ISO10589] [RFC1195]の複数のMTSを後方互換的な方法で維持するには、パケットエンコーディングと追加の最短パス（SPF）手順にいくつかの拡張が必要です。この問題は、各トポロジ内の隣接およびプレフィックスの広告および到達可能な中間システムの形成に分割することができます。必要なすべての追加情報を導入した場合、MT対応のSPF計算で適切に使用する必要があります。次のセクションでは、それぞれの問題について個別に説明します。テキストを簡素化するために、「標準」IS-ISトポロジーは、MT ID＃0（ゼロ）と定義されています。
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はこんにちはです。隣接する中間システムを発見するために使用されるパケット。
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.
形成された各隣接は、インターフェイス上のMTSのセットに属するものとして分類する必要があります。これは、インターフェイスがどのトポロジーに属しているかを宣伝する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.
ポイントツーポイントインターフェイスの隣接は通常どおり形成され、IS-ISルーターはMT拡張機能を実装していません。ローカルルーターが特定のMTSに参加しない場合、IIHSでそれらのMT IDを宣伝せず、したがって、その隣人はLSPに含まれません。一方、MT IDがリモート側のIIHSで検出されない場合、ローカルルーターはその隣接をLSPに含めるべきではありません。インターフェイス上に少なくとも1つの一般的な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上のすべてのルーターがMT機能TLVをIIHSで宣伝する場合があります。このMTに属するLANインターフェイスに少なくとも1つの隣接がある場合、MT有能なルーターには、LSPに対応するMTが到達可能なTLVに到達可能なTLVを含める必要があります。この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を持っているかどうかに関係なく、常に隣接を確立するものとします。これは、LAN上のすべてのルーターが同じDISを正しく選択できるようにするためです。LANの隣接がこのMTを含んでいない場合、ISにはLSPにMTがTLVであることを含めてはなりません。
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に属するインターフェイスに少なくとも1つの隣接がある場合、MTがTLVであることを発表する必要があります。そうしないと、このインターフェイスがLANに参加した場合、MTのMTが特定のMTの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機能に関係なく、通常どおりLAN上のすべてのノードに到達可能なTLVに到達可能なTLVに到達する必要があります。言い換えれば、擬似ノード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.
各MTSについて、ルーターが潜在的に分割され、過負荷になり、独立して接続される可能性があります。不必要な複雑さを防ぐために、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.
添付ビットと過負荷ビットは、ノードのLSPフラグメントゼロ内で分布するMT TLVの一部です。各隣接は異なるMTSに属する可能性があるため、一部のMTがL2に接続されている可能性があり、他のMTは同じルーターにいない可能性があります。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].
各MTSは独自のアドレス空間をコマンドするため、MT ID＃0以外のMTSに保存されているプレフィックスには、新しいTLVが必要です。同じ接頭辞が複数のMTに存在し、MTごとにSPFを加速する場合、エンコードを少なくするために、トラフィックエンジニアリング（TE）拡張機能にサブTLVを追加するのではなく、新しい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に従って、同じ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内の別のトポロジからのルーティング情報を使用して、あるトポロジーがルートを計算できるようにする試みは行われません。別の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:
MT拡張機能をサポートするために、4つの新しいTLVが追加されます。そのうちの1つは、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. 多くの場合、マルチトポロジーは非次第であり、Sub-TLVアプローチを使用するとLSPスペースが節約されません。
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 Type-22で使用されており、既存のTLVからTLVサイズに最大の制限がある間、さらに多くが提案されています。
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:
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).
BIT Oは、MTのオーバーロードビットを表します（ID＃0以外のMTでLSPフラグメントゼロでのみ有効で、それ以外の場合は送信で0に設定し、受領で無視する必要があります）。
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).
BIT Aは、MTのアタッチビットを表します（ID＃0以外のMTでLSPフラグメントゼロでのみ有効で、それ以外の場合は送信時に0に設定し、受領時に無視する必要があります）。
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発生の結合である必要があります。このTLVの他のIS PDUの発生は無視する必要があります。HellosおよびFragmentゼロLSPのMT TLVの欠如は、MT ID＃0のみの広告インターフェイスまたはルーターの参加として解釈する必要があります。ルーターがMT TLVを宣伝する場合、特にトポロジID＃0を含む、参加するすべてのMTSを宣伝する必要があります。
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番号は222です。これは、TLVの先頭にある追加の2バイトの横にある拡張性TLVタイプ22の拡張性と並べられています。
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 ISコンテンツは、拡張IS 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.
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コード-235 x長さ - 値フィールドの全長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番号は237です。それは、前の追加の2バイトの横にあるIPv6 Reachability TLV Type 236と整合しています。
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コード-237 x長さ - 値フィールドの全長x値-2バイトMTメンバーシップと、次のように構成されたIPv6 Reachability 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 Reachability TLV、Type 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ルーティングに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-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には、MTSには専用のインターフェイスがあり、それらのインターフェイスは特定のMTリブとFIBに関連付けることができるため、MTSを同じアドレスファミリから転送するために使用できます。
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.
転送決定を下すために正しいリブを決定するために、着信するIPパケットの正しいrib骨を選択するには、いくつかの追加のメカニズムが必要です。たとえば、トポロジーがサービス品質（QOS）である場合、IPパケットヘッダーの差別化されたサービスコードポイント（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リブマッピングに対するパケットの一般的なアプローチは、このドキュメントの範囲外です。
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.
すべてのMTSの中でアドレス空間に重複がない場合、厳密に言えば、宛先アドレススペースは、パケットが属するトポロジを分類します。異なるMTのルートを共有リブに取り付けることができます。このような展開の例として、特定の外部ボーダーゲートウェイプロトコル（EBGP）Nexthopアドレス用に特別なIS-ISトポロジを設定できます。
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.
IS-IS-ISは、結果のrib骨が転送目的に使用されていない場合でも、使用できます。例として、マルチキャスト転送にはまったく異なるリブが使用されているにもかかわらず、マルチキャストリバースパス転送（RPF）チェックは、標準のユニキャストリブとは異なるリブで実行できます。ただし、着信パケットは、ユニークなトポロジーに属していると明確に識別する必要があります。
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トポロジーがドメイン内に存在する場合、一部のルーターは、ネットワーク内のMTSのサブセットに参加するように構成できます。このセクションでは、操作またはネットワーク管理ステーションがそれらのルーターにアクセスできるようにするために必要なオプションの一部について説明します。
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」リブにインストールされます。「MGMT」トポロジがデフォルトトポロジを備えた一連の重複するアドレス空間を使用する条件では、これらの「MGMT」ルートをオプションでデフォルトのリブにインストールすることもできます。両方のリブの重複「MGMT」ルートの利点には、次のものが含まれます。システム上のネットワーク管理ユーティリティは、デフォルトのリブ以外の特定のリブを使用するために変更する必要はありません。「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.
著者は、アンドリュー・パルタン、ディノ・ファリナッチ、デレク・ヨン、アレックス・ジニン、ステファノ・プレビディ、ハイジ・オウ、スティーブ・ルオン、ペッカ・サヴォーラ、マイク・シャンド、シャンカール・ヴェムラパリ、レ・ギンズバーグ、議論、レビュー、コメント、コメント、貢献に感謝したいと思います。この文書に。
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で説明されているように、複数のトポロジーは同じアドレス空間でインターフェイスを共有しています。ISISを超えるメカニズムを使用して、インバウンドパケットの正しい転送テーブルを選択する必要があります。たとえば、システム上の誤った構成またはスプーフィングされたソースアドレスを備えたパケットは、プレミアムネットワークリソースのパケットの損失や不正使用につながる可能性があります。
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 TLVタイプを定義します。これらは、IANA IS-IS TLVコードポイントレジストリにすでに反映されています。
Name Value
MT-ISN 222
M-Topologies 229
MT IP. Reach 235
MT IPv6 IP. Reach 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は、将来の割り当てのために、このドキュメントおよび登録ポリシー[RFC2434]のセクション7.5にリストされている課題がリストされている新しいレジストリ「IS-IS Multi-Topologyパラメーター」を作成しました。MT ID値の範囲6-3995は、専門家のレビューを通じて割り当てられます。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。Connectionless-Modeネットワークサービスを提供するためのプロトコルと組み合わせて使用するための中間システムの中間システムルーティング交換プロトコル。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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[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月。
[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. Atkinson、「中間システムから中間システム（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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、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
Tony Przygienda Z2 Sagl経由のRovello 32 CH-6942 Savosa Email：prz@net4u.ch
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA, 95134 USA EMail: naiming@cisco.com
Nischal Sheth Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: nsheth@juniper.net
Nischal Sheth Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089 USAメール：nsheth@juniper.net
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への情報をお問い合わせください。