[要約] RFC 2966は、二段階のIS-ISを使用したドメイン全体のプレフィックス配布に関する規格であり、大規模なネットワークでの効率的なルーティングを実現することを目的としています。
Network Working Group T. Li
Request for Comments: 2966 Procket Networks
Category: Informational T. Przygienda
Redback
H. Smit
Procket Networks
October 2000
Domain-wide Prefix Distribution with Two-Level IS-IS
2レベルの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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2].
このドキュメントでは、2レベルドメイン内の最適なルーティングをサポートするための中間システムへの中間システム（IS-IS）プロトコルへの拡張について説明します。IS-ISプロトコルはISO 10589で指定されており、RFC 1195 [2]で指定されたIPv4（インターネットプロトコル）をサポートするための拡張機能を備えています。
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.
このドキュメントは、RFC 1195で提示されたセマンティクスを拡張して、レベル1とレベル2およびレベル2の中間システム（IS）[ルーター]の両方で実行されるルーティングドメインが、レベル1とレベル2の間にIPプレフィックスを配布し、その逆を拡張します。この分布には、永続的な転送ループが形成されないことを保証するために、特定の制限が必要です。このドメイン全体のプレフィックス分布の目標は、ドメイン内のルーティング情報の粒度を高めることです。
An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) can be partitioned into multiple level 1 (L1) areas, and a level 2 (L2) connected subset of the topology that interconnects all of the L1 areas. Within each L1 area, all routers exchange link state information. L2 routers also exchange L2 link state information to compute routes between areas.
IS-ISルーティングドメイン（別名IS-ISを実行する自律システム）は、複数のレベル1（L1）領域に分割され、すべてのL1領域を相互接続するトポロジのレベル2（L2）接続サブセットに分割できます。各L1領域内で、すべてのルーターがリンク状態情報を交換します。L2ルーターは、L2リンク状態情報を交換して、エリア間のルートを計算します。
RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are used to transport IPv4 routing information in IS-IS. RFC 1195 also specifies the semantics and procedures for interactions between levels. Specifically, routers in a L1 area will exchange information within the L1 area. For IP destinations not found in the prefixes in the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (i.e., an L1L2 router) with the "attached bit" set in its L1 Link State Protocol Data Unit (LSP).
RFC 1195 [2]は、IS-ISでIPv4ルーティング情報を輸送するために使用されるタイプ、長さ、および値（TLV）タプルを定義します。RFC 1195は、レベル間の相互作用のセマンティクスと手順も指定しています。具体的には、L1エリアのルーターはL1エリア内の情報を交換します。L1データベースのプレフィックスにないIP宛先の場合、L1ルーターは、L1リンク状態プロトコルに「接続ビット」が設定されたL1とL2（つまり、L1L2ルーター）の両方にある最も近いルーターに転送する必要があります。データユニット（LSP）。
Also per RFC 1195, an L1L2 router should be manually configured with a set of prefixes that summarizes the IP prefixes reachable in that L1 area. These summaries are injected into L2. RFC 1195 specifies no further interactions between L1 and L2 for IPv4 prefixes.
また、RFC 1195ごとに、L1L2ルーターは、そのL1領域で到達可能なIPプレフィックスを要約するプレフィックスのセットで手動で構成する必要があります。これらの要約はL2に注入されます。RFC 1195は、IPv4プレフィックスについてL1とL2の間にそれ以上の相互作用を指定しません。
The mechanisms specified in RFC 1195 are appropriate in many situations, and lead to excellent scalability properties. However, in certain circumstances, the domain administrator may wish to sacrifice some amount of scalability and distribute more specific information than is described by RFC 1195. This section discusses the various reasons why the domain administrator may wish to make such a tradeoff.
RFC 1195で指定されたメカニズムは、多くの状況で適切であり、優れたスケーラビリティ特性につながります。ただし、特定の状況では、ドメイン管理者は、RFC 1195で説明されているよりもある程度のスケーラビリティを犠牲にし、より具体的な情報を配布したい場合があります。このセクションでは、ドメイン管理者がそのようなトレードオフを行うことを望むさまざまな理由について説明します。
One major reason for distributing more prefix information is to improve the quality of the resulting routes. A well know property of prefix summarization or any abstraction mechanism is that it necessarily results in a loss of information. This loss of information in turn results in the computation of a route based upon less information, which will frequently result in routes that are not optimal.
より多くのプレフィックス情報を配布する主な理由の1つは、結果のルートの品質を改善することです。接頭辞の要約または抽象化メカニズムのよく知られている特性は、必然的に情報の損失をもたらすということです。この情報の損失は、より少ない情報に基づいてルートの計算をもたらします。これにより、最適ではないルートが頻繁に行われます。
A simple example can serve to demonstrate this adequately. Suppose that a L1 area has two L1L2 routers that both advertise a single summary of all prefixes within the L1 area. To reach a destination inside the L1 area, any other L2 router is going to compute the shortest path to one of the two L1L2 routers for that area. Suppose, for example, that both of the L1L2 routers are equidistant from the L2 source, and that the L2 source arbitrarily selects one L1L2 router. This router may not be the optimal router when viewed from the L1 topology. In fact, it may be the case that the path from the selected L1L2 router to the destination router may traverse the L1L2 router that was not selected. If more detailed topological information or more detailed metric information was available to the L2 source router, it could make a more optimal route computation.
簡単な例は、これを適切に実証するのに役立ちます。L1領域には、L1領域内のすべてのプレフィックスの単一の要約を宣伝する2つのL1L2ルーターがあると仮定します。L1エリア内の目的地に到達するために、他のL2ルーターは、その領域の2つのL1L2ルーターのいずれかに最短のパスを計算します。たとえば、両方のL1L2ルーターがL2ソースから等距離であり、L2ソースが1つのL1L2ルーターを任意に選択するとします。このルーターは、L1トポロジから表示された場合、最適なルーターではない場合があります。実際、選択したL1L2ルーターから宛先ルーターへのパスが、選択されていないL1L2ルーターを通過する場合があります。L2ソースルーターでより詳細なトポロジ情報またはより詳細なメトリック情報が利用可能である場合、より最適なルート計算を作成する可能性があります。
This situation is symmetric in that an L1 router has no information about prefixes in L2 or within a different L1 area. In using the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation that the L1 router performs is similarly suboptimal.
この状況は、L1ルーターがL2または異なるL1領域内の接頭辞に関する情報がないという点で対称的です。最寄りのL1L2ルーターを使用すると、そのL1L2はメトリック情報なしでデフォルトルートをL1領域に効果的に注入しています。L1ルーターが実行するルート計算も同様に最適です。
Besides the optimality of the routes computed, there are two other significant drivers for the domain wide distribution of prefix information.
計算されたルートの最適性に加えて、プレフィックス情報のドメイン広い分布には他に2つの重要なドライバーがあります。
When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing.
ルーターがBGPを介して外部宛先への複数の可能なパスを学習すると、転送テーブルにインストールされるルートの1つのみが選択されます。BGPルート選択の要因の1つは、BGP Next HopアドレスのIGPコストです。多くのISPネットワークは、「最短の出口ルーティング」として知られているこの手法に依存しています。L1ルーターが他のL1領域のすべてのBGPスピーカーの正確なIGPメトリックを知らない場合、効果的な最短の出口ルーティングを行うことはできません。
The third driver is the current practice of using the IGP (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). The value in the MED is advertised to other domains and is used to inform other domains of the optimal entry point into the current domain. Current practice is to take the IS-IS metric and insert it as the MED value. This tends to cause external traffic to enter the domain at the point closest to the exit router. Note that the receiving domain may, based upon policy, choose to ignore the MED that is advertised. However, current practice is to distribute the IGP metric in this way in order to optimize routing wherever possible. This is possible in current networks that only are a single area, but becomes problematic if hierarchy is to be installed into the network. This is again because the loss of end-to-end metric information means that the MED value will not reflect the true distance across the advertising domain. Full distribution of prefix information within the domain would alleviate this problem as it would allow accurate computation of the IS-IS metric across the domain, resulting in an accurate value presented in the MED.
3番目のドライバーは、BGPマルチエキシット識別子（MED）の一部としてIGP（IS-IS）メトリックを使用する現在の慣行です。MEDの値は他のドメインに宣伝され、現在のドメインへの最適なエントリポイントを他のドメインに通知するために使用されます。現在の実践は、IS-ISメトリックを取得し、それをMED値として挿入することです。これにより、外部トラフィックが出口ルーターに最も近いポイントでドメインに入る傾向があります。受信ドメインは、ポリシーに基づいて、宣伝されている薬を無視することを選択する場合があることに注意してください。ただし、現在の慣行は、可能な限りルーティングを最適化するために、この方法でIGPメトリックを配布することです。これは、単一の領域のみである現在のネットワークで可能ですが、階層をネットワークにインストールする場合に問題が発生します。これは、エンドツーエンドのメトリック情報の損失が、MED値が広告ドメイン全体の真の距離を反映しないことを意味するためです。ドメイン内のプレフィックス情報の完全な配布は、ドメイン全体でIS-Iメトリックの正確な計算を可能にし、MEDで提示される正確な値をもたらすため、この問題を軽減します。
The disadvantage to performing the domain-wide prefix distribution described above is that it has an impact to the scalability of IS-IS. Areas within IS-IS help scalability in that LSPs are contained within a single area. This limits the size of the link state database, that in turn limits the complexity of the shortest path computation.
上記のドメイン全体のプレフィックス分布を実行することの欠点は、IS-ISのスケーラビリティに影響を与えることです。IS-IS-IS内の領域は、LSPが単一の領域内に含まれているという点でのスケーラビリティに役立ちます。これにより、リンク状態データベースのサイズが制限され、最短パス計算の複雑さが制限されます。
Further, the summarization of the prefix information aids scalability in that the abstraction of the prefix information removes the sheer number of data items to be transported and the number of routes to be computed.
さらに、プレフィックス情報の抽象化により、輸送されるデータ項目の膨大な数と計算されるルートの数が削除されるという点で、プレフィックス情報支援のスケーラビリティの要約があります。
It should be noted quite strongly that the distribution of prefixes on a domain wide basis impacts the scalability of IS-IS in the second respect. It will increase the number of prefixes throughout the domain. This will result in increased memory consumption, transmission requirements and computation requirements throughout the domain.
ドメインの広い基準での接頭辞の分布が、2番目の点でISのスケーラビリティに影響を与えることに非常に強く注意すべきです。ドメイン全体のプレフィックス数が増加します。これにより、ドメイン全体でメモリ消費、伝送要件、および計算要件が増加します。
It must also be noted that the domain-wide distribution of prefixes has no effect whatsoever on the first aspect of scalability, namely the existence of areas and the limitation of the distribution of the link state database.
また、プレフィックスのドメイン全体の分布は、スケーラビリティの最初の側面、つまり領域の存在とリンク状態データベースの分布の制限にまったく効果がないことに注意する必要があります。
Thus, the net result is that the introduction of domain-wide prefix distribution into a formerly flat, single area network is a clear benefit to the scalability of that network. However, it is a compromise and does not provide the maximum scalability available with IS-IS. Domains that choose to make use of this facility should be aware of the tradeoff that they are making between scalability and optimality and provision and monitor their networks accordingly. Normal provisioning guidelines that would apply to a fully hierarchical deployment of IS-IS will not apply to this type of configuration.
したがって、最終的な結果は、以前にフラットで単一のエリアネットワークにドメイン全体のプレフィックス分布を導入することが、そのネットワークのスケーラビリティにとって明確な利点であることです。ただし、それは妥協であり、IS-ISで利用可能な最大のスケーラビリティを提供しません。この施設を使用することを選択したドメインは、スケーラビリティと最適性の間で作成しているトレードオフを認識し、それに応じてネットワークを提供し、監視する必要があります。IS-ISの完全な階層展開に適用される通常のプロビジョニングガイドラインは、このタイプの構成には適用されません。
This document defines the syntax of how to advertise level 2 routes in level 1 LSPs. The encoding is an extension of the encoding in RFC 1195.
このドキュメントでは、レベル2のLSPでレベル2ルートを宣伝する方法の構文を定義しています。エンコーディングは、RFC 1195でのエンコードの拡張です。
To some extent, in IS-IS the level 2 backbone can be seen as a separate area itself. RFC 1195 defines that L1L2 routers can advertise IP routes that were learned via L1 routing into L2. These routes can be regarded as inter-area routes. RFC 1195 defines that these L1->L2 inter-area routes must be advertised in L2 LSPs in the "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 routes are also advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Therefore, L1->L2 inter-area routes are indistinguishable from L2 intra-area routes.
ある程度、IS-ISでは、レベル2のバックボーンは別の領域自体と見なすことができます。RFC 1195は、L1L2ルーターがL1ルーティングを介してL2へのルーティングを介して学習したIPルートを宣伝できることを定義しています。これらのルートは、エリア間ルートと見なすことができます。RFC 1195は、これらのL1-> L2エリア間ルートを「IP内部リーチビリティ情報」TLV（TLV 128）のL2 LSPで宣伝する必要があることを定義しています。エリア内L2ルートは、「IP内部リーチビリティ情報」TLVでL2 LSPで宣伝されています。したがって、L1-> L2エリア間ルートは、L2エリア内ルートと区別できません。
RFC 1195 does not define L2->L1 inter-area routes. A simple extension would be to allow a L1L2 router to advertise routes learned via L2 routing in its L1 LSP. However, to prevent routing-loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. Therefore, there must be a way to distinguish L2->L1 inter-area routes from L1 intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. TVLs 128 and 130 have a metric field that consists of 4 TOS metrics. The first metric, the so-called "default metric", has the high-order bit reserved (bit 8). Routers must set this bit to zero on transmission, and ignore it on receipt.
RFC 1195は、L2-> L1エリア間ルートを定義しません。簡単な拡張機能は、L1L2ルーターがL1 LSPのL2ルーティングを介して学習したルートを宣伝できるようにすることです。ただし、ルーティングループを防ぐために、L1L2ルーターは、L2-> L1ルーティングを介してL2に戻るL2-> L1エリア間ルートを宣伝しないでください。したがって、L2-> L1エリア間ルートをL1エリア内ルートと区別する方法がなければなりません。Draft-ITETF-ISIS-TRAFFIC-01.TXTは、この目的のために「アップ/ダウンビット」を定義します。RFC 1195は、IPルートを含むTLVS 128および130を定義します。TVLS 128および130には、4つのTOSメトリックで構成されるメトリックフィールドがあります。最初のメトリックであるいわゆる「デフォルトメトリック」には、高次ビットが予約されています（ビット8）。ルーターは、このビットを送信時にゼロに設定し、受領時に無視する必要があります。
This document redefines this high-order bit in the default metric field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit set that are learned via L1 routing, must never be advertised by L1L2 routers back into L2.
このドキュメントは、TLVS 128および130のデフォルトメトリックフィールドのこの高次ビットを、アップ/ダウンビットに再定義します。L1L2ルーターは、L2ルーティングに由来し、L1 LSPに宣伝されるプレフィックスに対してこのビットを1に設定する必要があります。L1またはL2 LSPの他のすべてのIPプレフィックスについて、ビットをゼロに設定する必要があります。L1ルーティングを介して学習されているアップ/ダウンビットセットを備えたプレフィックスは、L1L2ルーターによってL2に戻って宣伝されてはいけません。
RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is defined as "IP Internal Reachability Information", and should be used to carry IP prefixes that are directly connected to IS-IS routers. TLV 130 is defined as "IP External Reachability Information", and should be used to carry routes learned from outside the IS-IS domain. RFC 1195 documents TLV type 130 only for level 2 LSPs.
RFC 1195は、IPプレフィックスを運ぶために2つのTLVを定義します。TLV 128は「IP内部リーチビリティ情報」として定義されており、IS-ISルーターに直接接続されたIPプレフィックスを携帯するために使用する必要があります。TLV 130は「IP外部リーチビリティ情報」として定義されており、IS-ISドメインの外部から学習したルートを運ぶために使用する必要があります。RFC 1195ドキュメントTLVタイプ130レベル2 LSPのみ。
RFC 1195 also defines two types of metrics. Metrics of the internal metric-type should be used when the metric is comparable to metrics used to weigh links inside the ISIS domain. Metrics of the external metric-type should be used if the metric of an IP prefix cannot be directly compared to internal metrics. External metric-type can only be used for external IP prefixes. A direct result is that metrics of external metric-type should never be seen in TLV 128.
RFC 1195は、2種類のメトリックも定義しています。メトリックがISISドメイン内のリンクを比較検討するために使用されるメトリックに匹敵する場合、内部メトリックタイプのメトリックを使用する必要があります。IPプレフィックスのメトリックを内部メトリックと直接比較できない場合は、外部メトリックタイプのメトリックを使用する必要があります。外部メトリックタイプは、外部IPプレフィックスにのみ使用できます。直接的な結果は、TLV 128では、外部メトリックタイプのメトリックを決して見ないでください。
To prevent confusion, this document states again that when a router computes IP routes, it must give the same preference to IP routes advertised in an "IP Internal Reachability Information" TLV and IP routes advertised in an "IP External Reachability Information" TLV. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference.
混乱を防ぐために、このドキュメントは、ルーターがIPルートを計算する場合、「IP内部リーチビリティ情報」TLVおよび「IP外部リーチビリティ情報」で宣伝されているIPルートで宣伝されているIPルートを同じようにする必要があることを再度述べています。RFC 1195は、これを3.10.2項、アイテム2cのノートに非常に明確に述べています。このドキュメントは、この好みのルールを変更しません。
NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation.
注：内部ルート（「IP内部リーチビリティ情報」フィールドで発表された目的地へのルート）、および内部メトリックを使用した外部ルート（「IP外部リーチビリティ情報」フィールドで発表された宛先へのルート、「内部」タイプのメトリック）））ルートの好みの順序とディクストラ計算の目的で同様に扱われます。
However, IP routes advertised in "IP External Reachability Information" with external metric-type must be given less preference than the same IP routes advertised with internal-metric type, regardless of the value of the metrics.
ただし、メトリックの値に関係なく、外部メトリックタイプを使用して「IP外部リーチビリティ情報」で宣伝されているIPルートは、内部計測タイプで宣伝されている同じIPルートよりも優先度が低くなる必要があります。
While IS-IS routers must not give different preference to IP prefixes learned via "IP Internal Reachability Information" and "IP External Reachability Information" when executing the Dijkstra calculation, routers that implement multiple IGPs are free to use this distinction between internal and external routes when comparing routes derived from different IGPs for inclusion in their global RIB.
IS-ISルーターは、「IP内部リーチビリティ情報」と「IP外部リーチビリティ情報」を介して学習したIPプレフィックスを異なる優先順位を与えてはなりません。ダイクストラ計算を実行すると、複数のIGPSを実装するルーターは内部ルートと外部ルートの間でこの区別を自由に使用できます。グローバルリブに含めるために異なるIGPから派生したルートを比較する場合。
RFC 1195 does not define the "IP External Reachability Information" TLV for L1 LSPs. However, there is no reason why an IS-IS implementation could not allow for redistribution of external routes into L1. Some IS-IS implementations already allow network administrators to do this. This document loosens the restrictions in RFC 1195, and allows for the inclusion of the "IP External Reachability Information" TLV in L1 LSPs.
RFC 1195は、L1 LSPの「IP外部リーチビリティ情報」TLVを定義しません。ただし、IS-ISの実装が外部ルートのL1への再分配を許可できない理由はありません。いくつかのIS-IS実装により、ネットワーク管理者はすでにこれを行うことができます。このドキュメントは、RFC 1195の制限を緩め、L1 LSPに「IP外部リーチビリティ情報」TLVを含めることができます。
RFC 1195 defines that IP routes learned via L1 routing must always be advertised in L2 LSPs in a "IP Internal Reachability Information" TLV. Now that this document allows "IP External Reachability Information" TLVs in L1 LSPs, and allows for the advertisement of routes learned via L2 routing into L1, the above rule needs a extensions.
RFC 1195は、L1ルーティングを介して学習したIPルートは、「IP内部リーチビリティ情報」TLVで常にL2 LSPで宣伝する必要があることを定義しています。このドキュメントにより、L1 LSPで「IP外部リーチビリティ情報」TLVが許可され、L2ルーティングを介して学習したルートの広告をL1に許可するようになりました。上記のルールには拡張機能が必要です。
When a L1L2 router advertises a L1 route into L2, where that L1 route was learned via a prefix advertised in a "IP External Reachability Information" TLV, that L1L2 router should advertise that prefix in its L2 LSP within an "IP External Reachability Information" TLV. L1 routes learned via an "IP Internal Reachability Information" TLV should still be advertised within a "IP Internal Reachability Information" TLV. These rules should also be applied when advertising IP routes derived from L2 routing into L1. Of course in this case also the up/down bit must be set.
L1L2ルーターがL1ルートをL2に宣伝する場合、そのL1ルートは「IP外部リーチビリティ情報」TLVで宣伝されているプレフィックスを介して学習されました。L1L2ルーターは、「IP外部リーチビリティ情報」内のL2 LSPのプレフィックスを宣伝する必要があります。TLV。「IP内部リーチビリティ情報」TLVを介して学習したL1ルートは、「IP内部リーチビリティ情報」TLV内で引き続き宣伝する必要があります。これらのルールは、L2へのルーティングから派生したIPルートを広告する場合にも適用する必要があります。もちろん、この場合、アップ/ダウンビットも設定する必要があります。
RFC 1195 defines that if a router sees the same external prefix advertised by two or more routers with the same external metric, it must select the route that is advertised by the router that is closest to itself. It should be noted that now that external routes can be advertised from L1 into L2, and vice versa, that the router that advertises an external prefix in its LSP might not be the router that originally injected this prefix into the IS-IS domain. Therefore, it is less useful to advertise external routes with external metrics into other levels.
RFC 1195は、ルーターが同じ外部メトリックを持つ2つ以上のルーターによって宣伝されている同じ外部プレフィックスを表示する場合、それ自体に最も近いルーターによって宣伝されるルートを選択する必要があることを定義します。外部ルートはL1からL2に宣伝できるようになったことに注意する必要があります。その逆も同様です。LSPの外部プレフィックスを宣伝するルーターは、このプレフィックスをIS-ISドメインに元々注入したルーターではない可能性があります。したがって、外部メトリックを備えた外部ルートを他のレベルに宣伝することはあまり有用ではありません。
RFC 1195 and this document defines several ways of advertising IP routes in IS-IS. There are four variables involved.
RFC 1195およびこのドキュメントでは、IS-ISでIPルートを広告するいくつかの方法を定義しています。関与する4つの変数があります。
1) The level of the LSP in which the route is advertised. There are currently two possible values: level 1 and level 2 2) The route-type, which can be derived from the type of TLV in which the prefix is advertised. Internal routes are advertised in IP Internal Reachability Information TLVs (TLV 128), and external routes are advertised in IP External Reachability Information TLVs (TLV 130). 3) The metric-type: Internal or External. The metric-type is derived from the Internal/External metric-type bit in the metric field (bit 7). 4) The fact whether this route is leaked down in the hierarchy, and thus can not be advertised back up. This information can be derived from the newly defined up/down bit in the default metric field.
1) ルートが宣伝されているLSPのレベル。現在、2つの可能な値があります。レベル1とレベル2 2）ルートタイプ。これは、プレフィックスが宣伝されているTLVのタイプから導出できます。内部ルートは、IP内部到達可能性情報TLV（TLV 128）で宣伝され、外部ルートはIP外部リーチビリティ情報TLV（TLV 130）で宣伝されています。3）メトリックタイプ：内部または外部。メトリックタイプは、メトリックフィールドの内部/外部メトリックタイプビットから導出されます（ビット7）。4）このルートが階層に漏れているため、バックアップすることができないかどうか。この情報は、デフォルトのメトリックフィールドの新しく定義されたアップ/ダウンビットから導き出すことができます。
The combination IP Internal Reachability Information and external metric-type is not allowed. Also the up/down bit is never set in L2 LSPs. This leaves us with 8 different types of IP advertisements in IS-IS. However, there are more than 8 reasons for IP prefixes to be advertised in IS-IS. The following tables describe the types of IP prefixes and how they are encoded.
IP内部リーチビリティ情報と外部メトリックタイプの組み合わせは許可されていません。また、アップ/ダウンビットはL2 LSPで設定されません。これにより、IS-ISには8種類のIP広告が残ります。ただし、IS-ISでIPプレフィックスを宣伝する理由は8つ以上あります。次の表は、IPプレフィックスの種類とエンコードの方法について説明します。
1) L1 intra-area routes
1) L1エリア内ルート
These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router.
これらはL1 LSP、TLV 128で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは、広告ルーターに直接接続されています。
2) L1 external routes
2) L1外部ルート
These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.
これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。
3) L2 intra-area routes
3) L2エリア内ルート
These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area routes.
これらはL2 LSP、TLV 128で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは、広告ルーターに直接接続されています。これらの接頭辞は、L1-> L2エリア間ルートと区別することはできません。
4) L2 external routes
4) L2外部ルート
These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes.
これらは、TLV 130のL2 LSPで宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。これらの接頭辞は、L1-> L2エリア間外部ルートと区別することはできません。
5) L1->L2 inter-area routes
5) L1-> L2エリア間ルート
These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 128. These prefixes can not be distinguished from L2 intra-area routes.
これらはL2 LSP、TLV 128で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL1ルーティングを介して学習され、TLV 128のL1 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。これらのプレフィックスは、L2エリア内ルートと区別できません。
6) L1->L2 inter-area external routes
6) L1-> L2エリア間外部ルート
These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130. These prefixes can not be distinguished from L2 external routes.
これらは、TLV 130のL2 LSPで宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL1ルーティングを介して学習され、TLV 130のL1 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。これらのプレフィックスは、L2外部ルートと区別できません。
7) L2->L1 inter-area routes
7) L2-> L1エリア間ルート
These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in TLV 128.
これらはL1 LSP、TLV 128で宣伝されています。アップ/ダウンビットは1に設定され、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL2ルーティングを介して学習され、TLV 128で宣伝されているプレフィックスからのL2 SPF計算中に導出されました。
8) L2->L1 inter-area external routes
8) L2-> L1エリア間外部ルート
These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in L2 LSPs in TLV 130.
これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットは1に設定され、メトリックタイプは内部メトリックです。これらのIPプレフィックスはL2ルーティングを介して学習され、TLV 130のL2 LSPで宣伝されているプレフィックスからのL2 SPF計算中に導出されました。
9) L1 external routes with external metric
9) L1外部メトリックを備えた外部ルート
These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.
これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは外部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。
10) L2 external routes with external metric
10）外部メトリックを備えたL2外部ルート
These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes with external metric.
これらはL2 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは外部メトリックです。これらのIPプレフィックスは他のIGPから学習され、通常は広告ルーターに直接接続されていません。これらの接頭辞は、外部メトリックを備えたL1-> L2エリア間外部ルートと区別することはできません。
11) L1->L2 inter-area external routes with external metric
11）L1-> L2外部メトリックを備えたエリア間外部ルート
These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130 with external metrics. These prefixes can not be distinguished from L2 external routes with external metric.
これらはL2 LSP、TLV 130で宣伝されています。アップ/ダウンビットはゼロに設定されており、メトリックタイプは外部メトリックです。これらのIPプレフィックスはL1ルーティングを介して学習され、外部メトリックを使用してTLV 130のL1 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。これらのプレフィックスは、外部メトリックを備えたL2外部ルートと区別することはできません。
12) L2->L1 inter-area external routes with external metric
12）L2-> L1外部メトリックを備えたエリア間外部ルート
These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is external metric. These IP prefixes are learned via L2 routing, and were derived during the L1 SPF computation from prefixes advertised in L2 LSPs in TLV 130 with external metrics.
これらはL1 LSP、TLV 130で宣伝されています。アップ/ダウンビットは1に設定され、メトリックタイプは外部メトリックです。これらのIPプレフィックスはL2ルーティングを介して学習され、外部メトリックを使用してTLV 130のL2 LSPで宣伝されているプレフィックスからのL1 SPF計算中に導出されました。
Unfortunately IS-IS cannot depend on metrics alone for route selection. Some types of routes must always preferred over others, regardless of the costs that were computed in the Dijkstra calculation. One of the reasons for this is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that this maximum value of 63 does not mean infinity (e.g. like a hop count of 16 in RIP denotes unreachable). Introducing a value for infinity cost in IS-IS inter-area routes would introduce counting-to-infinity behavior via two or more L1L2 routers, which would have a bad impact on network stability.
残念ながら、ルート選択のためにメトリックだけに依存することはできません。Dijkstraの計算で計算されたコストに関係なく、一部のタイプのルートは常に他のルートよりも常に好まなければなりません。これの理由の1つは、エリア間ルートの最大メトリックで63のみで宣伝できることです。もう1つの理由は、この最大値63が無限を意味しないことです（たとえば、RIPの16のホップカウントのように、到達不可能です）。IS-ISエリア間ルートに無限コストの値を導入すると、2つ以上のL1L2ルーターを介してカウントインフィニティへの動作が導入され、ネットワークの安定性に悪影響を及ぼします。
The order of preference of IP routes in IS-IS is based on a few assumptions.
IS-ISのIPルートの好みの順序は、いくつかの仮定に基づいています。
- RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing. - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference. - RFC 1195 defines that external routes with internal metric-type are preferred over external routes with external metric type. - Routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing.
- RFC 1195は、L1ルーティングから派生したルートがL2ルーティングから派生したルートよりも好ましいことを定義しています。-RFC 1195パラグラフ3.10.2、アイテム2c）のメモは、内部メトリックタイプの内部ルートと内部メトリックタイプの外部プレフィックスを持つ内部ルートが同じ好みを持っていることを定義しています。-RFC 1195は、外部メートル型の外部ルートよりも内部メトリックタイプの外部ルートが好まれることを定義しています。 - L2ルーティングから派生したルートは、L1ルーティングから派生したL2-> L1ルートよりも推奨されます。
Based on these assumptions, this document defines the following route preferences.
これらの仮定に基づいて、このドキュメントは次のルート設定を定義します。
1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric
1) 内部メトリックL1内部メトリックを備えたL1外部ルート2）内部メトリックL1-> L2内部メトリックL1-> L2とA-AREA間外部ルートを持つL2内部メトリックL2外部ルートを持つL1エリア内ルート内部メトリック3）L2-> L1内部メトリックL2-> L1内部メトリックを備えたエリア間外部ルート4）外部メトリック付きL1外部ルート5）外部メトリックL1-> L2インター - > L2外部ルート外部メトリックを備えたエリア外部ルート6）L2-> L1外部メトリック付き外部外部ルート
Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS. Besides these defined route types, the encoding used would allow for a few more potential combinations. One of them is the combination of "IP Internal Reachability Information" and external metric type. This combination should never be used when building an LSP. Upon receipt of an IP prefix with this combination, routers must ignore this prefix.
パラグラフ4.1および4.2は、IS-ISで使用されているすべてのIPルートタイプを列挙します。これらの定義されたルートタイプに加えて、使用されるエンコードにより、さらにいくつかの潜在的な組み合わせが可能になります。そのうちの1つは、「IP内部リーチビリティ情報」と外部メトリックタイプの組み合わせです。この組み合わせは、LSPを構築するときに使用しないでください。この組み合わせでIPプレフィックスを受け取ると、ルーターはこのプレフィックスを無視する必要があります。
Another issue would be the usage of the up/down bit in L2 LSPs. Because IS-IS is currently defined with two levels of hierarchy, there should never be a need to set the up/down bit in L2 LSPs. However, if IS-IS would ever be extended with more than two levels of hierarchy, L2-only (or L1L2) routers will need to be able to accept L2 IP routes with the up/down bit set. Therefore, it is recommended that implementations ignore the up/down bit in L2 LSPs, and accept the prefixes in L2 LSPs regardless whether the up/down bit is set. This will allow for simpler migration once more than two levels of hierarchy are defined.
別の問題は、L2 LSPでのアップ/ダウンビットの使用です。IS-ISは現在、2つのレベルの階層で定義されているため、L2 LSPでアップ/ダウンビットを設定する必要は決してないはずです。ただし、IS-ISが3つ以上の階層で拡張される場合、L2のみ（またはL1L2）ルーターは、アップ/ダウンビットセットでL2 IPルートを受け入れる必要があります。したがって、実装はL2 LSPのアップ/ダウンビットを無視し、アップ/ダウンビットが設定されているかどうかに関係なくL2 LSPのプレフィックスを受け入れることをお勧めします。これにより、2つ以上のレベルの階層が定義されています。
Another detail that implementors should be aware of is the fact that L1L2 routers should only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They should not unconditionally advertise into L2 all prefixes from LSPs in the L1 database.
実装者が知っておくべきもう1つの詳細は、L1L2ルーターが自分自身を転送するために使用するL2 LSPでのみ宣伝する必要があるという事実です。L1データベースのLSPからのすべてのプレフィックスを無条件に宣伝するべきではありません。
Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs. It is also recommended that the default configuration of L1L2 routers is to not advertise any L2 routes into L1 (see also paragraph 5.0).
すべての接頭辞を階層の上または下に宣伝する必要はありません。実装により、追加の手動でのフィルタリングまたは要約が可能になると、LSPで宣伝するエリア間の接頭辞の数をさらに減らすことができます。また、L1L2ルーターのデフォルト構成は、L2ルートをL1に宣伝しないこともお勧めします（パラグラフ5.0も参照）。
The solution in this document is not fully compatible with RFC 1195. It is an extension to RFC 1195. If routers do not use the new functionality of external L1 routes, nor L2->L1 inter-area routes, older implementations that strictly follow RFC 1195 will be compatible with newer implementations that follow this document.
このドキュメントのソリューションは、RFC 1195と完全に互換性がありません。これはRFC 1195の拡張です。ルーターが外部L1ルートの新しい機能を使用しない場合、L2-> L1エリア間ルート、RFCに厳密に従う古い実装を使用しない場合1195は、このドキュメントに従う新しい実装と互換性があります。
Implementations that do not accept the "IP External Reachability Information" TLV in L1 LSPs will not be able to compute external L1 routes. This could cause routing loops between L1-only routers that do understand external L1 routes for a particular destination, and L1-only routers that use the default route pointing the closest attached L1L2 router for that destination.
L1 LSPの「IP外部リーチビリティ情報」TLVを受け入れない実装は、外部L1ルートを計算できません。これにより、特定の宛先の外部L1ルートを理解するL1専用ルーター間のルーティングループ、およびその目的地に最も近い付属のL1L2ルーターを指すデフォルトルートを使用するL1のみのルーターが発生する可能性があります。
Implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. Therefore, even older implementations that do not know of the up/down bit should be able to accept the new L2->L1 inter-area routes. These older implementations will install the new L2->L1 inter-area routes as L1 intra-area routes, but that in itself does not cause routing loops among L1-only routers.
RFC 1195に続く実装は、ルートを計算するときにデフォルトのメトリックフィールドのビット8を無視する必要があります。したがって、アップ/ダウンビットを知らない古い実装でさえ、新しいL2-> L1エリア間ルートを受け入れることができるはずです。これらの古い実装では、新しいL2-> L1エリア間ルートをL1エリア内ルートとしてインストールしますが、それ自体はL1のみのルーター間でルーティングループを引き起こしません。
However, it is vital that the up/down bit is recognized by L1L2 routers. As has been stated before, L1L2 routers must never advertise L2->L1 inter-area routes back into L2. Therefore, if L2 routes are advertised down into L1 area, it is required that all L1L2 routers in that area run software that understands the new up/down bit. Older implementations that follow RFC 1195 and do not understand the new up/down bit will threat the L2->L1 inter-area routes as L1 intra-area routes, and they will advertise these routes back into L2. This can cause routing loops, sub-optimal routing or extra routing instability. For this reason it is recommended that implementations by default do not advertise any L2 routes into L1. Implementations should force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1.
ただし、アップ/ダウンビットがL1L2ルーターによって認識されることが重要です。以前に述べたように、L1L2ルーターはL2-> L1エリア間ルートをL2に戻さないでください。したがって、L2ルートがL1エリアに宣伝されている場合、そのエリアのすべてのL1L2ルーターが新しいアップ/ダウンビットを理解するソフトウェアを実行することが必要です。RFC 1195に続き、新しいアップ/ダウンビットを理解していない古い実装は、L2-> L1エリア間ルートをL1エリア内ルートとして脅かし、これらのルートをL2に宣伝します。これにより、ルーティングループ、準最適なルーティング、または追加のルーティング不安定性が発生する可能性があります。このため、デフォルトの実装ではL2ルートをL1に宣伝しないことをお勧めします。実装は、ネットワーク管理者にL1L2ルーターを手動で構成するように強制する必要があります。
In [3], a new TLV is defined to transport IP prefix information. This TLV format also defines an up/down bit to allow for L2->L1 inter-area routes. [3] also defines a new TLV to describe links. Both TLVs have wider metric space, and have the possibility to define sub-TLVs to advertise extra information belonging to the link or prefix. The wider metric space in IP prefix TLVs allows for more granular metric information about inter-area path costs. To make full use of the wider metric space, network administrators must deploy both new TLVs at the same time.
[3]では、新しいTLVがIPプレフィックス情報を輸送するために定義されています。このTLV形式は、L2-> L1エリア間ルートを可能にするアップ/ダウンビットも定義します。[3]は、リンクを説明する新しいTLVも定義します。両方のTLVにはより広いメトリック空間があり、リンクまたはプレフィックスに属する追加の情報を宣伝するためにサブTLVを定義する可能性があります。IPプレフィックスTLVのより広いメトリック空間により、エリア間パスコストに関するより詳細なメトリック情報が可能になります。より広いメトリックスペースを最大限に活用するには、ネットワーク管理者は両方の新しいTLVを同時に展開する必要があります。
Deployment of [3] requires an upgrade of all routers in the network and a transition to the new TLVs. Such a network-wide upgrade and transition might not be an easy task. In this case, the solution defined in this document, which requires only an upgrade of L1L2 routers in selected areas, might be a good alternative to the solution defined in [3].
[3]の展開には、ネットワーク内のすべてのルーターのアップグレードと新しいTLVへの移行が必要です。このようなネットワーク全体のアップグレードと移行は簡単な作業ではないかもしれません。この場合、選択した領域のL1L2ルーターのアップグレードのみを必要とするこのドキュメントで定義されているソリューションは、[3]で定義されているソリューションに代わる適切な代替手段かもしれません。
This document raises no new security issues for IS-IS.
このドキュメントは、IS-ISの新しいセキュリティの問題を提起しません。
[1] ISO 10589, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)". [Also republished as RFC 1142.]
[1] ISO 10589、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための中間システムへの中間システムイントラドメインルーティング交換プロトコル」。[RFC 1142としても再発行されました。]
[2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[2] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[3] Smit, H. and T. Li, "IS-IS Extensions for Traffic Engineering", Work in Progress.
[3] Smit、H。、およびT. Li、「IS-IS Traffic Engineering for Traffic Engineering」、進行中の作業。
Tony Li Procket Networks 1100 Cadillac Court Milpitas, CA 95035-3025
Tony Li Procket Networks 1100 Cadillac Court Milpitas、CA 95035-3025
EMail: tli@procket.com
Tony Przygienda Redback 350 Holger Way San Jose, CA 95134
Tony Przygienda Redback 350 Holger Way San Jose、CA 95134
EMail: prz@redback.com
Henk Smit Procket Networks 1100 Cadillac Court Milpitas, CA 95035-3025
Henk Smit Procket Networks 1100 Cadillac Court Milpitas、CA 95035-3025
EMail: henk@procket.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。