Network Working Group J. Parker, Ed.
Request for Comments: 3787 Axiowave Networks
Category: Informational May 2004
Recommendations for Interoperable IP Networks
using Intermediate System to Intermediate System (IS-IS)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice.
この文書では、中間システムへの中間システム間の差の数を議論（IS-IS）RFC 1195に記述し、それのようにプロトコルが今日配備されると、ルートのIPトラフィックに使用されるプロトコル。これらの違いは、実装、テスト、およびルートIPトラフィックにIS-ISプロトコルを展開し、それらへのサービスとして議論されています。仲間ドキュメントは、ISO 10589および現在の実務慣行に記載されているプロトコルの違いについて説明します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2
3. Unused Features . . . . . . . . . . . . . . . . . . . . . . . 2
4. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Migration from Narrow Metrics to Wide . . . . . . . . . . . . 4
6. Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 6
7. Attached Bit. . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Default Route . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Non-homogeneous Protocol Networks . . . . . . . . . . . . . . 8
10. Adjacency Creation and IP Interface Addressing. . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References. . . . . . . . . . . . . . . . . . 10
12.2. Informative References. . . . . . . . . . . . . . . . . 10
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 10
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 11
Interior Gateway Protocols such as IS-IS are designed to provide timely information about the best routes in a routing domain. The original design of IS-IS, as described in ISO 10589 [1] has proved to be quite durable. However, a number of original design choices have been modified. This document describes some of the differences between the protocol as described in RFC 1195 [2] and the protocol that can be observed on the wire today. A companion document describes the differences between the protocol described in ISO 10589 and current practice [8].
インテリアゲートウェイプロトコルなどのIS-ISは、ルーティングドメイン内の最適なルートに関するタイムリーな情報を提供するように設計されています。 ISO 10589に記載されているようにIS-ISの元の設計は、非常に耐久性であることが証明された[1]にしています。しかし、オリジナルデザインの選択肢の数が変更されています。この文書は、RFC 1195に記載されているように、プロトコルの違いをいくつか説明し[2]、今日ワイヤ上で観察することができるプロトコル。コンパニオン文書はISO 10589に記載のプロトコルと現在の慣行の違いを説明し[8]。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [3].
キーワード "MUST"、 "MUST NOT"、 "SHOULD"、 "SHOULD NOT" と本書ではRFC 2119に記載されるように解釈されるべきである、 "MAY" [3]。
This document is the work of many people, and is the distillation of over a thousand mail messages. Thanks to Vishwas Manral, who pushed to create such a document. Thanks to Danny McPherson, the original editor, for kicking things off. Thanks to Mike Shand, for his work in creating the protocol, and his uncanny ability to remember what everything is for. Thanks to Micah Bartell and Philip Christian, who showed us how to document difference without displaying discord. Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, who spent many hours educating the editor. Thanks to Radia Perlman, who is always ready to explain anything. Thanks to Satish Dattatri, who was tenacious in seeing things written up correctly, and to Bryan Boulton for his work on the IP adjacency issue. Thanks to Russ White, whose writing improved the treatment of every topic he touched. Thanks to Shankar Vemulapalli, who read several drafts with close attention. Thanks to Don Goodspeed, for his close reading of the text. Thanks to Michael Coyle for identifying the quotation from Jan L.A. van de Snepscheut. Thanks for Alex Zinin's ministrations behind the scenes. Thanks to Tony Li and Tony Przygienda, who kept us on track as the discussions veered into the weeds. And thanks to all those who have contributed, but whose names I have carelessly left from this list.
この文書は、多くの人々の仕事であり、千を超えるメールメッセージの蒸留です。そのような文書を作成するためにプッシュVishwas Manral、に感謝します。ダニー・マクファーソン、物事をキックオフの元編集者のおかげ。マイク・シャンドのおかげで、プロトコルの作成に彼の仕事、そしてすべてのものが何のためにあるのか覚えて彼の不思議な能力のために。不和を表示せずに違いを文書化する方法を私たちに示したミカバーテルとフィリップ・キリストのおかげ。エディタを教育に多くの時間を費やしレスギンズバーグ、ニールCastagnoli、ジェフLearman、そしてデイブ・カッツのおかげで、。常に何かを説明する準備ができているラディア・パールマン、に感謝します。 IP隣接問題に関する彼の仕事のために正しく書かれたものを見に粘り強いたサティシュDattatri、へ、そしてブライアンボールトンに感謝します。書き込み彼が触れたすべてのトピックの治療を改善ラスホワイト、に感謝します。細心の注意をいくつかの草稿を読んシャンカールVemulapalli、に感謝します。ドン・グッドスピードのおかげで、テキストの彼の近い読書のため。ヤンL.A.バン・デ・Snepscheutからの引用を識別するためのマイケル・コイル氏に感謝します。舞台裏アレックスジニンのministrationsいただきありがとうございます。議論は雑草に方向転換としてトラック上で私たちを守っトニー・リーとトニーPrzygienda、に感謝します。そして貢献しますが、名前が、私はうっかりこのリストから、残っているしているすべての人に感謝します。
Some features defined in RFC 1195 are not in current use.
RFC 1195で定義されている一部の機能は、現在使用されていません。
RFC 1195 defines an Inter-Domain Routing Protocol Information TLV, with code 131, designed to convey information transparently between boundary routers. TLV 131 is not used, and MUST be ignored if received.
RFC 1195は、境界ルータとの間で透過的に情報を伝達するように設計されたコード131と、ドメイン間ルーティングプロトコル情報TLVを定義します。 TLV 131は使用されず、受信された場合は無視されなければなりません。
RFC 1195 defines an authentication TLV, code 133, which contains information used to authenticate the PDU. This TLV has been replaced by TLV 10, described in "IS-IS Cryptographic Authentication" [4]. TLV 133 is not used, and MUST be ignored.
RFC 1195 PDUを認証するために使用される情報が含まれている認証TLV、コード133を画定します。このTLVは「IS-IS暗号認証」[4]に記載のTLV 10で置換されています。 TLV 133は使用されず、無視しなければなりません。
To deal with transient problems that prevent an IS from storing all the LSPs it receives, ISO 10589 defines an LSP Database Overload condition in section 7.3.19. When an IS is in Database Overload condition, it sets a flag called the Overload Bit in the non-pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO 10589 instructs other systems not to use the overloaded IS as a transit router. Since the overloaded IS does not have complete information, it may not be able to compute the right routes, and routing loops could develop. However, an overloaded router may be used to reach End Systems directly attached to the router, as it may provide the only path to an End System.
それが受け取るすべてのLSPを格納からISを防ぐ一時的な問題に対処するには、ISO 10589は、セクション7.3.19でのLSPデータベース過負荷状態を定義します。 ISデータベースの過負荷状態にあるときに、それが生成する非擬似のLSP番号ゼロに過負荷ビットと呼ばれるフラグをセットします。 ISO 10589のセクション7.2.8.1は、オーバーロードを使用していない他のシステムに指示するトランジットルータとしてです。オーバーロードされているが、完全な情報を持っていないので、正しいルートを計算することができないかもしれない、とルーティングループを開発することができ。それはエンドシステムへのパスのみを提供することができるようしかし、オーバーロードされたルータは、エンドシステムが直接ルータに接続されている到達するために使用することができます。
The ability to signal reduced knowledge is so useful that the meaning of this flag has been overloaded. In a Service Provider's network, when a router running BGP and IS-IS reboots, BGP might take more time to converge than IS-IS. Thus the router may drop traffic for destinations not yet learned via BGP. It is convenient to set the Overload Bit until BGP has converged, as described in "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance" [6].
減少知識をシグナリングする能力は、このフラグの意味は、オーバーロードされているように有用です。サービスプロバイダーのネットワークでは、ルータはBGPを実行している場合、再起動IS-IS、BGPは-ISがISよりも収束に時間がかかる場合があります。したがって、ルータは、まだBGP経由で学習していない宛先にトラフィックをドロップすることがあります。それに記載されているように「中間システムへの中間システム（IS-IS）過渡ブラックホール回避」、BGPが収束するまで過負荷ビットを設定することが便利である[6]。
An implementation SHOULD use the Overload Bit to signal that it is not ready to accept transit traffic.
実装は、トランジットトラフィックを受け入れる準備ができていないことを知らせるために過負荷ビットを使用すべきです。
An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored. This is also discussed in the companion document on ISO interoperability [8].
実装は、それが生成する擬似のLSPに過負荷ビットを設定してはならず、擬似のLSPに見られる過負荷ビットは無視されるべきです。これは、ISOの相互運用[8]に仲間ドキュメントで説明されています。
RFC 1195 makes clear when describing the SPF algorithm for IP routers in section C.1.4 that directly connected IP subnetworks are reachable when an IS is overloaded.
セクションC.1.4にIPルータのSPFアルゴリズムを記述する際にRFC 1195は、ISがオーバーロードされたときに直接接続されたIPサブネットワークが到達可能であることを明確にしています。
Note that the End Systems neighbors of the system P includes IP reachable address entries included in the LSPs from system P.
システムPのエンドシステムのネイバーがシステムP.からのLSPに含まれるIP到達可能なアドレスのエントリが含まれていることに注意してください
When processing LSPs received from a router which has the Overload bit set in LSP number Zero, the receiving router SHOULD treat all IP reachability advertisements as directly connected and use them in its SPF computation.
処理のLSPは、LSP番号ゼロに設定されたビット過負荷を有するルータから受信した場合、受信ルータは、すべてのIP到達可能性広告などの直接接続を治療し、そのSPFの計算にそれらを使用するべきです。
Since the IP prefixes that an overloaded router announces will be treated as directly attached, an overloaded router SHOULD take care in selecting which routes to advertise in the LSPs it generates.
オーバーロードされたルータのアナウンスがとして扱われるIPプレフィックスが直接接続されているので、オーバーロードされたルータは、ルートが、それが発生したLSPに広告を掲載するかを選択するには注意が必要です。
The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6 bit metric for the default link metric to the listed neighbor. This metric has proved too limited. The Extended IS-Neighbors TLV (TLV 22) and the Extended IP Reachability TLV (TLV 135) are defined in "IS-IS extensions for Traffic Engineering" [5]. The Extended IS-Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks and Hosts.
IS-ネイバーTLV（TLV 2）RFC 1195で定義されているISO 10589およびIP到達可能性TLV（TLV 128 / TLV 130）で定義されるように記載されている隣接する、デフォルトのリンクメトリックの6ビットメトリックを提供します。このメトリックは、あまりにも限られた証明しています。拡張は、IS-隣人TLV（TLV 22）および拡張IP到達可能性TLV（TLV 135）は、 "トラフィックエンジニアリング用の拡張機能-IS" に定義されている[5]。拡張は、IS-ネイバーTLV（TLV 22）24ビットメトリックを定義し、拡張IP到達可能性TLV（TLV 135）は、IPネットワークとホストのための32ビットメトリックを定義します。
If not all devices in the IS-IS domain support wide metrics, narrow metrics MUST continue to be used. Once all devices in the network are able to support the new TLVs containing wide metrics, the network can be migrated to the new metric style, though care must be taken to avoid routing loops.
そうでない場合はIS-ISドメインサポートワイドメトリック内のすべてのデバイスは、狭いメトリックが使用され続けなければなりません。ネットワーク内のすべてのデバイスは、幅広い指標を含む新しいTLVをサポートすることができたら世話がルーティングループを避けるようにしなければならないものの、ネットワークは、新しいメトリックスタイルに移行することができます。
We make the following assumptions about the implementation:
私たちは、実装に関する以下の仮定を行います。
(1) Each system can generate and understand both narrow and wide metrics.
（1）各システムの両方狭く、広いメトリックを生成し、理解することができます。
(2) The implementation can run the SPF algorithm on an LSP DB with instances of both metric styles.
（2）実装では、両方のメトリックスタイルのインスタンスとLSP DBにSPFアルゴリズムを実行することができます。
(3) If there are two metric styles for a link or IP prefix, it will pick one of them as the true cost for the link.
リンクまたはIPプレフィックス用の2つのメトリックのスタイルがある場合（3）は、リンクのための真のコストとしてそれらのいずれかを選択します。
To compare the different variants of the narrow metric with wide metrics, we need an algorithm that translates External and Internal narrow metrics into a common integer range. Since we have different computations for the L1 and L2 routes, we only need to map metrics from a single level.
広いメトリクスと狭いメトリックの異なるバリエーションを比較するために、我々は一般的な整数範囲に外部および内部の狭いメトリックを変換するアルゴリズムを必要としています。我々は、L1とL2の経路に異なる計算を持っているので、我々は、単一のレベルからのメトリックをマップする必要があります。
In RFC 1195 section 3.10.2, item 2c) states that the IP prefixes located in "IP External Reachability" with internal-metric and IP prefixes located in "IP Internal Reachability" with internal-metric have the same preference. As defined in "Domain-wide Prefix Distribution with Two-Level IS-IS", the Most Significant Bit on an L1 metric tells us if the route has been leaked down, but does not change the distance. Thus we will ignore the MSBit.
RFC 1195のセクション3.10.2、項目2C）に内部メトリックと「IP内部到達可能性」に位置する内部メトリックとIPプレフィックスと「IP外部到達可能性」に位置するIPプレフィクスが同じ嗜好を持っていることを述べています。で定義されているようにルートがダウン漏洩してきた場合には、L1メトリックの最上位ビットを教えてくれる「2レベルのドメイン全体のプレフィックス配布-ISはIS」が、距離は変更されません。したがって、私たちはMSBitからは無視されます。
We interpret the default metric as an 7 bit quantity. Metrics with the external bit set are interpreted as metrics in the range [64..127]. Metrics with the external bit clear are interpreted as metrics in the range [0..63].
私たちは、7ビットの量として、デフォルトのメトリックを解釈します。外部ビットが設定されたメトリックは、範囲[64..127]のメトリックとして解釈されます。外部ビットクリアとメトリックは[0 63]の範囲のメトリックとして解釈されます。
To facilitate a smooth transition between the use of narrow metrics exclusively to the use of wide metrics exclusively, the following steps must be taken, in the order below.
排他的に排他的に広いメトリクスの使用に狭いメトリックの使用との間のスムーズな移行を容易にするために、次の手順は以下の順序で、注意しなければなりません。
(1) All routers advertise Narrow Metrics as defined in ISO 10589, and consider narrow metrics only in their SPF computation.
（1）すべてのルータは、ISO 10589で定義された狭いメトリックを広告し、そして唯一の彼らのSPF計算に狭い指標を検討してください。
(2) Each system is configured in turn to send wide metrics as well as narrow metrics. The two metrics for the same link or IP prefix SHOULD agree.
（2）各システムは、ワイドメトリックならびに狭いメトリックを送信するように順番に構成されています。同じリンクまたはIPプレフィックスのための2つのメトリックが合意すべきです。
(3) When all systems are advertising wide metrics, make any changes necessary on each system to consider Wide Metrics during the SPF, and change MaxPathMetric to 0xFE000000.
（3）すべてのシステムが広い指標を宣伝している場合は、SPFの間、ワイドメトリックを検討するために、各システム上で必要な変更を行い、0xFE000000にMaxPathMetricを変更します。
(4) Each system is configured in turn to stop advertising narrow metrics.
（4）各システムは狭いメトリックをアドバタイズを停止する順番に設定されています。
(5) When the network is only using wide metrics, metrics on individual links may be rescaled to take advantage of the larger metric.
ネットワークだけ広いメトリックを使用している場合（5）、個々のリンク上のメトリクスは、より大きなメトリックを利用するために再スケーリングされてもよいです。
The algorithm above assumes that the metrics are equal, and thus needs to make no assumption about which metric the SPF algorithm uses. This section describes the changes that should be made to the SPF algorithm when both Narrow and Wide metric styles should be considered. Using a common algorithm allows different implementations to compute the same distances independently, even if the wide and narrow metrics do not agree.
このアルゴリズムは、上記のメトリックが等しいことを前提とし、したがって、SPFアルゴリズムが使用するメトリックに関する一切の仮定をしないする必要があります。このセクションでは、狭いとワイドの両方のメトリックのスタイルを考慮しなければならないとき、SPFアルゴリズムになされるべき変更について説明します。一般的なアルゴリズムを使用することで広いと狭いメトリックが同意しない場合でも、異なる実装が独立して同じ距離を計算することができます。
The standard SPF algorithm proceeds by comparing sums of link costs to obtain a minimal cost path. During transition, there will be more than one description of the same links. We resolve this by selecting the minimum metric for each link. This may give us a path with some links chosen due to a wide metric and some links chosen due to a narrow metric.
最小限のコストのパスを取得するためのリンクコストの合計を比較することにより、標準のSPFアルゴリズムが進行します。移行時には、同じリンクの複数の記述があるでしょう。私たちは、各リンクの最小メトリックを選択することで、この問題を解決します。これは、広いメートルと狭いメトリックに起因して選ばれたいくつかのリンクを私たちに選ばれたいくつかのリンクを持つパスを与える可能性があります。
The description below is more complex than the implementation needs to be: the implementation may simply select the minimal cost neighbor in TENT, discarding paths to destinations we have already reached, as described in ISO 10589.
実装は単にISO 10589で説明したように、我々はすでに、達している目的地へのパスを破棄し、テントの中で最小のコストの隣人を選択することがあります。以下の説明は、実装が必要以上に複雑です。
The variables MaxPathMetric and MaxLinkMetric SHOULD retain the values defined in Table 2 of section 8 of ISO 10589.
変数はMaxPathMetricとMaxLinkMetricは、ISO 10589のセクション8の表2で定義された値を保持すべきです。
In C.2.5 Step 0 of the description of the SPF algorithm, section b)
SPFアルゴリズムの説明のC.2.5ステップ0、セクションb）における
d(N) = cost of the parent circuit of the adjacency N
D（N）=隣接Nの親回路のコスト
If multiple styles of metric for the link are defined, the cost will be the minimum available cost for the circuit.
リンクのメトリックの複数のスタイルが定義されている場合、コストは回路の最小可能なコストになります。
In C.2.5 Step 0 of the description of the SPF algorithm, section i)
SPFアルゴリズムの記述のC.2.5ステップ0において、I部）
d(N) = metric of the circuit
D（N）回路のメトリック=
If multiple styles of metric for the link are defined, the cost will be the minimum available cost for the circuit.
リンクのメトリックの複数のスタイルが定義されている場合、コストは回路の最小可能なコストになります。
In C.2.6 Step 1 of the description of the SPF algorithm, section a)
SPFアルゴリズムの説明のC.2.6ステップ1、区間a）における
dist(P,N) = d(P) + metric(P,N)
DIST（P、N）= D（P）+メトリック（P、N）
If multiple styles of metric for the neighbor are defined, the cost will be the minimum available cost for the circuit.
隣人のメトリックの複数のスタイルが定義されている場合、コストは回路の最小可能なコストになります。
The original intent of RFC 1195 was to provide a routing protocol capable of handling both CLNS and IPv4 reachability information. To allow CLNS Endstations (ES) to know that they are attached to a router, Intermediate Systems are required to send Intermediate System Hello PDUs (ISH) for End Stations when a point-to-point circuit comes up. Furthermore, an IS is not allowed to send Intermediate System to Intermediate System Hello PDUs (IIH) before receiving an ISH from a peer. This reduces routing protocol traffic on links with a single IS.
RFC 1195の当初の目的は、CLNSとIPv4到達可能性情報の両方を扱うことが可能なルーティングプロトコルを提供することでした。 CLNSのエンドステーション（ES）は、彼らがルータに接続されていることを知ることができるようにするには、中間システムは、ポイントツーポイント回路が起動したとき、エンドステーションのための中間システムHello PDUは（ISH）を送信するために必要とされています。さらに、ISは、ピアからのISHを受信する前に中間システムHello PDUは（IIH）に中間システムの送信を許可されていません。これは、単一のISとのリンク上のルーティングプロトコルのトラフィックを軽減します。
For this reason section 5.1 RFC 1195 states:
この理由のセクション5.1 RFC 1195個の状態の場合：
"On point-to-point links, the exchange of ISO 9542 ISHs
(intermediate system Hellos) is used to initialize the link,
and to allow each router to know if there is a router on the
other end of the link, before IS-IS Hellos are exchanged. All
routers implementing IS-IS (whether IP-only, OSI-only, or
dual), if they have any interfaces on point-to-point links,
must therefore be able to transmit ISO 9542 ISHs on their
point-to-point links."
Section 5.1 RFC 1195 reinforces the need to comply with section 8.2.4 of ISO 10589. However, in an IP Only environment, the original need for the ISH PDU is not present.
セクション5.1 RFC 1195は、IPのみの環境では、しかし、ISO 10589.のセクション8.2.4に準拠する必要性を強調し、ISH PDUの元の必要性は存在しません。
A multi-protocol IS that supports the attachment of CLNS ESs over Point to Point circuits must act in accordance with section 8.2.2 ISO 10589 when CLNS functionality is enabled.
マルチプロトコルはそれがCLNS機能が有効になっているときの回路はセクション8.2.2 ISO 10589に基づいて行動しなければならないポイントツーポイント以上CLNS ESの添付ファイルをサポートしています。
An IP only implementation SHOULD issue an ISH PDU as described in section 8.2.3 of ISO 10589. This is to inter-operate with implementations which require an ISH to initiate the formation of an IS-IS adjacency.
ISO 10589.のセクション8.2.3に記載したようにIPのみ実装これは、IS-IS隣接の形成を開始するISHを必要とする実装と相互運用にあるISH PDUを発行すべきです。
An IP Only implementation may issue an IIH PDU when a point to point circuit transitions into an "Up" state to initiate the formation of an IS-IS adjacency, without sending an ISH PDU. However, this may not inter-operate with implementations which require an ISH for adjacency formation.
ポイントは、IS-IS隣接関係の形成を開始するために「UP」状態に回路の遷移を指すようにする際IPのみの実装は、ISH PDUを送信せず、IIH PDUを発行することができます。しかし、これはない隣接関係形成のためISHを必要とする実装と相互動作することができます。
An IS may issue an IIH PDU in response to the receipt of an IIH PDU in accordance with section 8.2.5.2 ISO 10589, even though it has not received an ISH PDU.
ISは、ISH PDUを受信していないにもかかわらず、セクション8.2.5.2 ISO 10589に従い、IIH PDUの受信に応答してIIH PDUを発行することができます。
In section 7.2.9.2 of ISO 10589, an algorithm is described to determining when the attachedFlag should be set on an intermediate system. Some implementations also allow the attachedFlag to be set on Intermediate Systems routing IP traffic when there is a default route in the local routing table, or when some other state is reached that implies a connection to the rest of the network.
ISO 10589のセクション7.2.9.2において、アルゴリズムはattachedFlag中間システム上に設定されるべきときを決定するまでに記載されています。いくつかの実装もattachedFlagがそこにローカルルーティングテーブルにデフォルトルートがある、またはいくつかの他の状態に達したときに残りのネットワークへの接続を意味している時にIPトラフィックをルーティングする中間システムに設定することができます。
RFC 1195 states in section 1.3:
RFC 1195のセクション1.3で述べています：
Default routes are permitted only at level 2 as external routes
(i.e., included in the "IP External Reachability Information"
field, as explained in sections 3 and 5). Default routes are
not permitted at level 1.
Because of the utility of the default route when dealing with other routing protocols and the ability to influence the exit point from an area, an implementation MAY generate default routes in Level 1.
なぜなら他のルーティングプロトコルおよび領域から出口点に影響を与える能力を扱うデフォルトルートの有用性、実装は、レベル1のデフォルトルートを生成してもよいです。
RFC 1195 assumes that every deployment of IS-IS routers will support a homogeneous set of protocols. It anticipates OSI only, IP only, or dual OSI and IP routers. While it allows mixed areas with, for example, both pure IP and Dual IP and OSI routers, it allows only IP traffic in such domains, and OSI traffic only when pure OSI and Dual IP and OSI routers are present. Thus it provides only lowest common denominator routing.
RFC 1195は、IS-ISルータのすべての展開は、プロトコルの均質なセットをサポートすることを前提としています。それはOSIだけで、IPのみ、またはデュアルOSIとIPルータを見込んでいます。それと混合領域を可能にするが、例えば、純粋なIPデュアルIP及びOSIルータの両方が、それは純粋なOSIおよびデュアルIP及びOSIルータが存在する場合にのみ、そのようなドメイン内のIPトラフィックだけを許可し、OSIトラフィック。したがって、唯一の最小公分母ルーティングを提供します。
RFC 1195 also requires the inclusion of the Protocol Supported TLV with code 129 in IIH and ISH PDUs and in LSP number Zero. IP capable routers MUST generate a Protocol Supported TLV, and MUST include the IP protocol as a supported protocol. A router that does not include the Protocols Supported TLV may be assumed to be a pure OSI router and can be interpreted as implicitly "advertising" support for the OSI protocol.
RFC 1195はまた、IIHとISHのPDUおよびLSP番号ゼロのコード129とTLVサポートするプロトコルを含めることを必要とします。 IP対応ルータは、TLVサポートするプロトコルを生成しなければならない、およびサポートされているプロトコルとしてIPプロトコルを含まなければなりません。 TLVサポートされているプロトコルが含まれていないルータは、純粋なOSIルータであると仮定することができるとOSIプロトコルのサポートを「宣伝」として暗黙的に解釈することができます。
The requirements of RFC 1195 are ample if networks adhere to this restriction. However, the behavior of mixed networks that do not follow these guidelines is not well defined.
ネットワークがこの制限に準拠している場合、RFC 1195の要件は十分です。しかし、これらのガイドラインに従わない混合ネットワークの動作は明確に定義されていません。
The ITU-T requires that SONET/SDH equipment running the IS-IS protocol must not form an adjacency with a neighbour unless they share at least one network layer protocol in common. Unless this feature is present in every IS in the SONET or SDH DCN network the network may not function correctly. Implementors MAY include this feature if they wish to ensure interoperability with SONET and SDH DCN networks.
ITU-Tは、それらが少なくとも1つの共通のネットワーク層プロトコルを共有しない限り、SONET / SDH装置はネイバーとの隣接関係を形成してはならないIS-ISプロトコルを実行することを必要とします。この機能は、すべての中に存在しない限り、SONETまたはSDH DCNネットワークにあるネットワークが正常に機能しない場合があります。彼らはSONETとSDH DCNネットワークとの相互運用性を確保したい場合は、実装者は、この機能を含むかもしれません。
Definition of an interoperable strategy for resolving the problems that arise in non-homogeneous protocol networks remains incomplete. Members of the ITU are actively working on a proposal: see "Architecture and Specification of Data Communication Network", [7].
不均質なプロトコルのネットワークで発生する問題を解決するための相互運用可能な戦略の定義が不完全なまま。 ITUのメンバーが積極的に提案に取り組んでいる：[7]、「データ通信ネットワークのアーキテクチャと仕様」を参照してください。
RFC 1195 states that adjacencies are formed without regard to IP interface addressing. However, many current implementations refuse adjacencies based on interface addresses and related issues.
RFC 1195は、隣接関係は、IPインタフェースのアドレス指定に関係なく形成されていると述べています。しかし、多くの現在の実装では、インターフェイスアドレスと関連する問題に基づいて隣接関係を拒否します。
In section 4.2, RFC 1195 requires routers with IP interface addresses to advertise the addresses in an IP Interface Address TLV (132) carried in IIH PDUs. Some implementations will not interoperate with a neighbor router that does not include the IP Interface Address TLV. Further, some implementations will not form an adjacency on broadcast interfaces with a peer who does not share an interface address in some common IP subnetwork.
セクション4.2で、RFC 1195 IIHのPDUで運ばれるIPインターフェイスアドレスTLV（132）のアドレスをアドバタイズするIPインターフェイスアドレスでルータを必要とします。一部の実装では、IPインタフェースアドレスTLVが含まれていない隣接ルータと相互運用しません。さらに、いくつかの実装は、いくつかの一般的なIPサブネットワークにインタフェースアドレスを共有しないピアにブロードキャストインターフェース上で隣接関係を形成しません。
If a LAN contains a mixture of implementations, some that form adjacencies with all neighbors and some that do not, care must be taken when assigning IP addresses. If not all routers in a LAN are on the same IP subnet, it is possible that DIS election may fail, leading to the election of multiple DISs on a LAN, or no DIS at all. Even if DIS election succeeds, black holes can result because the IS-IS LAN transitivity requirements of section 6.7.3 ISO 10589 are not met.
LANは、実装の混合物が含まれている場合はIPアドレスを割り当てるときに、すべてのネイバーとそうでないいくつかとの隣接関係を形成しているいくつかは、注意が必要です。 LAN内ではないすべてのルータが同じIPサブネット上にある場合、LAN上の複数のDISSの選挙、またはまったくDISにつながる、DISの選挙が失敗する可能性があります。 DISの選挙が成功した場合でも、セクション6.7.3 ISO 10589のIS-IS LANの推移要件が満たされていないので、ブラックホールが発生することができます。
Unnumbered point to point links do not have IP interface addresses, though they may have other IP addresses assigned to the routers. The IP address assigned to two routers that are neighbors on an unnumbered point to point link do not need to be related. However, some implementations will not form an adjacency on numbered point to point links if the interface addresses of each endpoint are not in the same IP subnetwork. This means that care must be taken in assigning IP interface addresses in all networks.
彼らは、ルータに割り当てられた他のIPアドレスを持っているかもしれませんが、リンクをポイントするアンナンバードのポイントは、IPインタフェースのアドレスを持っていません。ポイントリンクに番号なしポイントに隣接している2つのルータに割り当てられたIPアドレスは、関連する必要はありません。各エンドポイントのインターフェイスアドレスは同じIPサブネットにない場合は、いくつかの実装は、リンクを指すように番号が付けポイントに隣接関係を形成しないであろう。これは、ケアは、すべてのネットワークでIPインタフェースアドレスを割り当てるに取らなければならないことを意味します。
For an implementation to interoperate in a such mixed environment, it MUST include an IP Interface address (TLV 132) in its IIH PDUs. The network administrator should ensure that there is a common IP subnet assigned to links with numbered interfaces, and that all routers on each link have a IP Interface Addresses belonging to the assigned subnet.
実装は、このような混合環境で相互運用するためには、そのIIHのPDUにIPインタフェースアドレス（TLV 132）を含まなければなりません。ネットワーク管理者は、番号のインタフェースとのリンクに割り当てられた共通のIPサブネットがあることを確認すべきであること、および各リンク上のすべてのルータは、割り当てられたサブネットに属するIPインターフェイスアドレスを持っています。
The clarifications in this document do not raise any new security concerns, as there is no change in the underlying protocol described in ISO 10589 [1] and RFC 1195 [2].
ISO 10589に記載しているプロトコルで変化がないとして、この文書の明確化は、新たなセキュリティ上の問題を提起していない[1]およびRFC 1195 [2]。
The document does make clear that TLV 133 has been deprecated and replaced with TLV 10.
文書は、TLV 133は非推奨とTLV 10に置き換えられていることを明らかにしません。
[1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002.
[1] ISO、「コネクションレス型ネットワークサービス（ISO 8473）を提供するためのプロトコルと一緒に使用するための情報交換プロトコルをrouteingする中間システムへの中間システム、」ISO / IEC 10589：2002。
[2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990.
[2] Callon、R.、RFC 1195、1990年12月 "OSIは、IPおよびデュアル環境のためにIS-IS"。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 3567, July 2003.
[4]のLi、T.及びR.アトキンソンは、 "IS-IS暗号認証"、RFC 3567、2003年7月。
[5] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, May 2004.
[5]スミット、H.および "中間システムへの中間システム（IS-IS）トラフィックエンジニアリング（TE）のための拡張機能" T.李、RFC 3784、2004年5月。
[6] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002.
[6]マクファーソン、D.、 "中間システムへの中間システム（IS-IS）過渡ブラックホールの回避"、RFC 3277、2002年4月。
[7] ITU, "Architecture and Specification of Data Communication Network", ITU-T Recommendation G.7712/Y.1703, November 2001
[7] ITU、 "アーキテクチャとデータ通信ネットワークの仕様"、ITU-T勧告G.7712 / Y.1703、2001年11月
[8] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, February 2004.
[8]パーカー、J.、エド。、RFC 3719、2004年2月 "中間システム（IS-IS）への中間システムを使用して相互運用ネットワークへの提言"。
Jeff Parker Axiowave Networks 200 Nickerson Road Marlborough, Mass 01752 USA
ジェフ・パーカーAxiowaveネットワーク200ニッカーソン道路マールボロ、マサチューセッツ01752 USA
EMail: jparker@axiowave.com
メールアドレス：jparker@axiowave.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。