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
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.
著作権（C）インターネット協会（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プロトコルは、RFC 1195で指定されたIPv4（Internet Protocol）をサポートするための拡張と、ISO 10589で指定されている[2]。
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.
この文書では、レベル1とレベル2中間システム（IS）[ルータ]の両方で実行されているルーティングドメインは、レベル1とレベル2とその逆の間でIPプレフィックスを配布することができるように、RFC 1195に提示さセマンティクスを拡張します。この分布は、永続的なフォワーディングループが形成されないことを保証するために一定の制限が必要です。このドメイン全体の接頭語分配の目標は、ドメイン内のルーティング情報の精度を高めることです。
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ルータを手動でIPがそのL1領域に到達可能な接頭辞まとめプレフィクスのセットで構成されるべきです。これらの概要は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.
より多くのプレフィックス情報を配信するための一つの大きな理由は、得られたルートの品質を向上させることです。プレフィックス要約または任意の抽象化メカニズムのよく知っているプロパティは、それが必ずしも情報の損失をもたらすということです。しばしば最適ではない経路をもたらすであろう以下の情報に基づいて経路の計算におけるターン結果の情報のこの損失。
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ルータの1つまでの最短経路を計算しようとしています。 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が効果L1領域にメトリック情報がないデフォルトルートを注入されていることを、最も近いL1L2ルータを使用します。 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を介して外部の宛先への複数の可能な経路を学習するとき、それはそれらの経路の一方のみが転送テーブルにインストールされるように選択します。 BGPルート選択の要因の一つは、BGPネクストホップアドレスへの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.
第三のドライバは、BGPマルチ出口ディスクリミネータ（MED）の一部として、IGP（IS-IS）を使用して、メトリックの現在の慣行です。 MEDの値が他のドメインにアドバタイズされ、現在のドメインに最適なエントリポイントの他のドメインを通知するために使用されます。現在の練習は、IS-ISメトリックを取り、MED値としてそれを挿入することです。これは、外部トラフィックが出口ルータに最も近い地点でドメインを入力させる傾向があります。受信ドメインは、ポリシーに基づいて、広告されMEDを無視することを選択することがあります。しかしながら、現在の実施は可能な限りルーティングを最適化するために、このようにIGPメトリックを分配することです。これは、単一の領域であり、現在のネットワークでは可能であるが、階層がネットワークにインストールする場合に問題となります。エンド・ツー・エンドのメトリック情報の損失は、MED値は、広告ドメイン間で真の距離を反映していないことを意味しますので、これは再びです。それは正確に計算MEDに提示正確な値が得られ、ドメイン間のメトリックIS-ISができるようになると、ドメイン内のプレフィックス情報の完全な分布は、この問題を軽減するでしょう。
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のスケーラビリティに影響を与えることです。それのLSPでIS-ISのヘルプスケーラビリティ内の領域は、単一の領域内に含まれています。これは、次に、最短経路計算の複雑さを制限することは、リンク状態データベースのサイズを制限します。
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.
これはかなり強く、ドメイン全体での影響に関するプレフィックスの分布はのスケーラビリティ二点でIS-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ルート1 LSPを宣伝する方法の構文を定義します。エンコーディングは、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.
ある程度、2骨格が別の領域自体として見られるレベルはIS-IS。 RFC 1195 L1L2ルータがL2にL1ルーティングを介して学習された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-> L1エリア間のルートをアドバタイズしてはいけません。したがって、L1イントラ領域ルートからL2-> L1エリア間のルートを区別する方法がなければなりません。ドラフト-IETF-ISIS-トラフィック-01.txtは、この目的のために、「アップ/ダウンビット」を定義します。 RFC 1195のTLV 128および130は、IPルートを含むように定義します。 TVLs 128及び130は、4つのTOSメトリックから成るメトリックフィールドを有します。最初のメトリック、いわゆる「メトリックデフォルト」は、予約済み上位ビット（ビット8）を有しています。ルータは、送信時にこのビットを0に設定し、受信時にそれを無視しなければなりません。
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.
この文書では、アップ/ダウンビットであることをTLVの128と130で、デフォルトメトリックフィールドで、この上位ビットを再定義します。 L1L2ルータはL2ルーティング由来し、L1のLSPにアドバタイズされるプレフィクスのための1つに、このビットをセットしなければなりません。ビットは、L1又はL2のLSP内の他のすべてのIPプレフィクスのためにゼロに設定されなければなりません。 L1ルーティングで学習されているアップ/ダウンビットがセットされたプレフィックスは、バックL2にL1L2ルータによってアドバタイズされてはなりません。
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は、レベル2のLSPのためのTLVタイプ130を説明します。
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内部の可到達性情報」TLVでアドバタイズ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.
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.
ルータがIPプレフィックスに異なる優先順位を与えてはならないISは、ISながらダイクストラ計算を実行する際に、複数のIGPを実装するルータは、内部および外部ルート間のこの区別を自由に使用することが「IP内部の可到達性情報」および「IP外部到達可能性情報」を介して学習そのグローバルRIBに含めるために異なるの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を可能にし、L1にL2ルーティングを経由して学習されたルートの広告を可能にすること、上記のルールは、拡張を必要とします。
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ルートがL1L2ルータは、「IP外部到達可能性情報」内のL2 LSPでそのプレフィックスを通知する必要があること、「IP外部到達可能性情報」TLVでアドバタイズ接頭辞を介して学習されたL2、へのL1ルートをアドバタイズするときTLV。 「IP内部の可到達性情報」TLVを介して学習L1ルートはまだ「IP内部の可到達性情報」TLV内に通知しなければなりません。 L1に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つの以上のルータによってアドバタイズ同じ外部プレフィックスを見れば、それは自分自身に最も近いルータによってアドバタイズされるルートを選択しなければならないことを定義します。外部のルートは、そのLSP外部プレフィックスをアドバタイズルータが元々IS-ISドメインにこのプレフィックスを注入ルータではないかもしれないことを、L2にL1から広告、およびその逆のことができるという今注目すべきです。したがって、他のレベルに外部メトリックを持つ外部ルートをアドバタイズするためにはあまり有用です。
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のレベル。レベル1及びレベル2 2）プレフィックスがアドバタイズされたTLVのタイプに由来することができるルートタイプ、2つの可能な値が現在存在します。内部ルートは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でIP広告の8つの異なるタイプで私たちを残します。しかし、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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 128において、L1のLSPにアドバタイズされる、メトリック・タイプメトリック内部あります。これらの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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 130において、L1のLSPにアドバタイズされる、メトリック・タイプメトリック内部あります。これらの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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 128で、L2のLSPにアドバタイズされる、メトリック・タイプメトリック内部あります。これらの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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 128で、L2のLSPにアドバタイズされる、メトリック・タイプメトリック内部あります。これらのIPプレフィックスは、L1ルーティングを介して学習され、そしてこれらのプレフィックスは、L2エリア内ルートと区別できないTLV 128にL1のLSPにアドバタイズされたプレフィックスからL1 SPF計算中に誘導しました。
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ルーティングを介して学習され、そしてこれらのプレフィックスは、L2外部経路と区別することができないTLV 130にL1のLSPにアドバタイズされたプレフィックスからL1 SPF計算中に誘導しました。
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.
これらは、アップ/ダウンビットが1に設定されているTLV 128において、L1のLSPにアドバタイズされる、メトリック・タイプメトリック内部あります。これらの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.
これらは、アップ/ダウンビットが1に設定されているTLV 130において、L1のLSPにアドバタイズされる、メトリック・タイプメトリック内部あります。これらの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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 130において、L1のLSPにアドバタイズされる、メトリック型は外部の測定基準です。これらの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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 130で、L2のLSPにアドバタイズされる、メトリック型は外部の測定基準です。これらの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.
これらは、アップ/ダウンビットがゼロに設定されているTLV 130で、L2のLSPにアドバタイズされる、メトリック型は外部の測定基準です。これらの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.
これらは、アップ/ダウンビットが1に設定されているTLV 130において、L1のLSPにアドバタイズされる、メトリック型は外部の測定基準です。これらの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.
残念ながら、IS-ISは、ルート選択のためだけではメトリックに依存することはできません。ルートの種類によっては関係なく、常にダイクストラ計算で計算されたコストの、他のものよりも優先しなければなりません。この理由の一つは、（例えば、RIPが到達不能意味16のホップ数など）63のこの最大値は無限大を意味するものではないということであるエリア間のルートのみ63.もう一つの理由の最大メトリックでアドバタイズすることができることです。無限のコストの値を導入するエリア間のルートはネットワークの安定性に悪い影響を与えるであろう二つ以上の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-と内部メトリックL2外部経路との2）L2イントラ領域ルート>内部メトリックL1-とL2エリア間ルート> L2間の面積を有する内部メトリックL1外部経路とL1イントラ領域ルート内部メトリックと内部メトリック3）L2-> L1エリア間のルートと外部経路内部メトリック4とL2-> L1エリア間の外部ルート）外部メトリック5とL1の外部ルート）外部メトリック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ルートの種類を列挙します。これらの定義されたルートタイプの他に、使用される符号化は、さらにいくつかの潜在的な組み合わせを可能にします。そのうちの一つは、「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は、これまでの階層の二つ以上のレベルで拡張されるだろうしかし、もし、L2-のみ（またはL1L2）ルータは、アップ/ダウンビットがセットされたL2 IPルートを受け入れることができるようにする必要があります。したがって、実装がL2のLSPにアップ/ダウンビットを無視し、アップ/ダウンビットが設定されているかどうかにかかわらず、L2のLSPにプレフィックスを受け入れることをお勧めします。これはかつての階層の二つ以上のレベルが定義されている単純な移行が可能になります。
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.
実装者が知っておくべきことを別の詳細は、L1L2ルータが自分のL2 LSPに、彼らは自分自身を転送するために使用したものL1ルートを唯一宣伝すべきであるという事実です。彼らは無条件にL1データベース内のLSPからL2にすべてのプレフィックスを通知べきではありません。
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ルータのデフォルト設定では、L1にどんなL2ルートをアドバタイズしないことであることをお勧めします（また、段落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と完全に互換性がありません。これは、ルータが外部のL1ルートの新機能を使用しない場合は、RFC 1195の拡張機能で、また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ルートを理解し、そしてその先のために最も近い付属L1L2ルータを指し示すデフォルトルートを使用するL1専用ルーターん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エリア間のルートを受け入れることができるはずです。これらの古い実装は、L1、エリア内ルートとして新しいL2-> 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にL2-> L1エリア間のルートをアドバタイズしてはいけません。 L2ルートがL1領域にダウンアドバタイズされる場合、したがって、それは新たなアップ/ダウンビットを理解し、その領域の実行ソフトウェア内のすべてのL1L2ルータことが必要です。 RFC 1195に従い、アップ/ダウン新しいビットはL1、エリア内ルートなどの脅威L2-> L1エリア間のルートをし、彼らが戻っL2にこれらのルートをアドバタイズします理解していない古い実装。これは、ルーティングループ、サブ最適なルーティングや余分なルーティングの不安定性を引き起こす可能性があります。この理由は、デフォルトで実装がL1にどんなL2ルートをアドバタイズしないことをお勧めします。実装は、手動L1に任意L2ルートをアドバタイズする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、「中間システム中間にシステムのドメイン内ルーティング交換プロトコル（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.は、 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"、RFC 1195、1990年12月。
[3] Smit, H. and T. Li, "IS-IS Extensions for Traffic Engineering", Work in Progress.
[3]スミット、H.、およびT.李は、進行中で働いて "トラフィックエンジニアリングのための拡張機能-IS IS"。
Tony Li Procket Networks 1100 Cadillac Court Milpitas, CA 95035-3025
トニー・李Procket Networksの1100キャデラック裁判所ミルピタス、CA 95035から3025
EMail: tli@procket.com
メールアドレス：tli@procket.com
Tony Przygienda Redback 350 Holger Way San Jose, CA 95134
トニーPrzygiendaレッドバック350ホルガー・ウェイサンノゼ、CA 95134
EMail: prz@redback.com
メールアドレス：prz@redback.com
Henk Smit Procket Networks 1100 Cadillac Court Milpitas, CA 95035-3025
ヘンクスミットProcket Networksの1100キャデラック裁判所ミルピタス、CA 95035から3025
EMail: henk@procket.com
メールアドレス：henk@procket.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。