Network Working Group J. Parker, Ed.
Request for Comments: 3719 Axiowave Networks
Category: Informational February 2004
Recommendations for Interoperable 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 as described in ISO 10589 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. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic.
ISO 10589に記載されており、そのようなプロトコルが今日配備されているので、この文書では、中間システム（IS-IS）プロトコルへの中間システム間の相違点の数について説明します。これらの違いは、テストの実施、およびIS-ISプロトコルを展開し、それらへのサービスとして議論されています。それはIPトラフィックをルーティングするために、今日配備されるようコンパニオン文書は、RFC 1195に記載されているプロトコルとプロトコルの違いについて説明します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Constants That Are Variable . . . . . . . . . . . . . . . . . 2
3. Variables That Are Constant . . . . . . . . . . . . . . . . . 4
4. Alternative Metrics . . . . . . . . . . . . . . . . . . . . . 6
5. ReceiveLSPBufferSize. . . . . . . . . . . . . . . . . . . . . 6
6. Padding Hello PDUs. . . . . . . . . . . . . . . . . . . . . . 8
7. Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Purging Corrupted LSPs. . . . . . . . . . . . . . . . . . . . 10
9. Checking System ID in Received point-to-point IIH PDUs. . . . 10
10. Doppelganger LSPs . . . . . . . . . . . . . . . . . . . . . . 11
11. Generating a Complete Set of CSNPs. . . . . . . . . . . . . . 11
12. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
16. Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
17. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
In theory, there is no difference between theory and practice.
But in practice, there is.
Jan L.A. van de Snepscheut
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 addresses differences between the protocol described in ISO 10589 and the protocol that can be observed on the wire today. A companion document discusses differences between the protocol described in RFC 1195 [2] for routing IP traffic and current practice.
インテリアゲートウェイプロトコルなどのIS-ISは、ルーティングドメイン内の最適なルートに関するタイムリーな情報を提供するように設計されています。 ISO 10589に記載されているようにIS-ISの元の設計は、非常に耐久性であることが証明された[1]にしています。しかし、オリジナルデザインの選択肢の数が変更されています。この文書は、ISO 10589に記載されているプロトコル、今日のワイヤ上で観察することができるプロトコル間の違いに対応しています。仲間ドキュメントは、IPトラフィックと現在の実務をルーティングするためのRFC 1195に記載されているプロトコルの違い[2]を論じています。
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]。
Some parameters that were defined as constant in ISO 10589 are modified in practice. These include the following
ISO 10589の定数として定義されたいくつかのパラメータは、実際に変更されています。これらには以下のものが含まれます
(1) MaxAge - the lifetime of a Link State PDU (LSP)
（1）MaxAgeの - リンク状態PDU（LSP）の寿命
(2) ISISHoldingMultiplier - a parameter used to describe the generation of hello packets
（2）ISISHoldingMultiplier - ハローパケットの生成を説明するために使用されるパラメータ
(3) ReceiveLSPBufferSize - discussed in a later section
（3）ReceiveLSPBufferSize - 以降のセクションで説明
Each LSP contains a RemainingLifetime field which is initially set to the MaxAge value on the generating IS. The value stored in this field is decremented to mark the passage of time and the number of times it has been forwarded. When the value of a foreign LSP becomes 0, an IS initiates a purging process which will flush the LSP from the network. This ensures that corrupted or otherwise invalid LSPs do not remain in the network indefinitely. The rate at which LSPs are regenerated by the originating IS is determined by the value of maximumLSPGenerationInterval.
各LSPは、最初に発生上MaxAgeの値に設定されているIS RemainingLifetimeフィールドを含みます。このフィールドに格納された値は、時間の経過と、それが転送された回数をマークするために減らされます。外国のLSPの値が0になったとき、ISネットワークからLSPをフラッシュするパージ処理を開始します。これは、破損しているか、そうでない場合は、無効なのLSPが無期限にネットワークに残っていないことを保証します。 LSPを発信することによって再生される速度はmaximumLSPGenerationIntervalの値によって決定されます。
MaxAge is defined in ISO 10589 as an Architectural constant of 20 minutes, and it is recommended that maximumLSPGenerationInterval be set to 15 minutes. These times have proven to be too short in some networks, as they result in a steady flow of LSP updates even when nothing is changing. To reduce the rate of generation, some implementations allow these times to be set by the network operator.
MaxAgeの20分の建築定数としてISO 10589で定義され、maximumLSPGenerationIntervalを15分に設定することが推奨されます。これらの時間は、彼らがLSP更新の定常流の結果として何も変更されていない場合でも、一部のネットワークでは短すぎることが証明されています。発生率を減少させるために、いくつかの実装では、これらの時間は、ネットワークオペレータによって設定されることを可能にします。
The relation between MaxAge and maximumLSPGenerationInterval is discussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than maximumLSPGenerationInterval, then an LSP will expire before it is replaced. Further, as RemainingLifetime is decremented each time it is forwarded, an LSP far from its origin appears older and is removed sooner. To make sure that an LSP survives long enough to be replaced, MaxAge should exceed maximumLSPGenerationInterval by at least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first term, ZeroAgeLifetime, is an estimate of how long it takes to flood an LSP through the network. The second term, minimumLSPTransmissionInterval, takes into account how long a router might delay before sending an LSP. The original recommendation was that MaxAge be at least 5 minutes larger than maximumLSPGenerationInterval, and that recommendation is still valid today.
MaxAgeのとmaximumLSPGenerationIntervalとの関係はMaxAgeのがmaximumLSPGenerationIntervalよりも小さい場合は、それを交換する前に、そのLSPの有効期限が切れるISO 10589.のセクション7.3.21で説明されています。 RemainingLifetimeは、それが転送されるたびにデクリメントされてさらに、LSPははるかにその起源から古い表示され、すぐに削除されます。 LSPを交換するのに十分な長生き残ることを確認するために、MaxAgeのは、少なくともZeroAgeLifetime + minimumLSPTransmissionIntervalでmaximumLSPGenerationIntervalを超えている必要があります。第一項、ZeroAgeLifetimeは、それがネットワークを介して、LSPをあふれさせるにかかる時間の推定値です。第二項、minimumLSPTransmissionIntervalは、ルータがLSPを送信する前に遅れる可能性がどのくらい考慮されます。オリジナルの勧告はMaxAgeのがmaximumLSPGenerationIntervalより大きく、少なくとも5分であることだった、とその勧告は今日でも有効です。
An implementation MAY use a value of MaxAge that is greater than 1200 seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at least 300 seconds. An implementation SHOULD NOT use its value of MaxAge to discard LSPs from peers, as discussed below.
実装は1200秒以上であるMaxAgeの値を使用するかもしれません。 MaxAgeのは、少なくとも300秒でmaximumLSPGenerationIntervalを超えている必要があります。実装は、以下に説明するように、ピアからLSPを廃棄するMaxAgeのその値を使用しないでください。
An implementation is not required to coordinate the RemainingLifetime it assigns to LSPs to the RemainingLifetime values it accepts, and MUST ignore the following sentence from section 7.3.16.3. of ISO 10589.
実装はRemainingLifetimeへのLSPには割り当てRemainingLifetimeを調整するために必要とされないことが受け入れ値、およびセクション7.3.16.3から次の文を無視しなければなりません。 ISO 10589の。
"If the value of Remaining Lifetime [of the received LSP] is
greater than MaxAge, the LSP shall be processed as if there
were a checksum error."
An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic basis over active circuits, allowing other attached routers to monitor their aliveness. The IIH includes a two byte field called the Holding Time which defines the time to live of an adjacency. If an IS does not receive a hello from an adjacent IS within this holding time, the adjacent IS is assumed to be no longer operational, and the adjacency is removed.
ISが送信する他の接続されたルータは、自分の稼働状態を監視することができ、アクティブ回路、過定期的にIS Helloプロトコルデータユニット（IIHS）することです。 IIHは、隣接の生存時間を定義する保持時間と呼ばれる2バイトのフィールドを含みます。 ISは隣接からのhelloを受信しない場合、隣接はもはや動作可能でないと仮定されており、隣接関係が削除され、この保持時間以内です。
ISO 10589 defines ISISHoldingMultiplier to be 10, and states that the value of Holding Time should be ISISHoldingMultiplier multiplied by iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS. This implies that the neighbor must lose 10 IIHs before an adjacency times out.
ISO 10589は、10であることがISISHoldingMultiplierを定義し、保持時間の値はISISHoldingMultiplier通常システム用iSISHelloTimerを乗じなければならないと述べ、そしてDISためdRISISHelloTimer。これは、ネイバーが隣接関係がタイムアウトする前に10 IIHSが失われなければならないことを意味します。
In practice, a value of 10 for the ISISHoldingMultiplier has proven to be too large. DECnet PhaseV defined two related values. The variable holdingMultiplier, with a default value of 3, was used for point-to-point IIHs, while the variable ISISHoldingMultiplier, with a default value of 10, was used for LAN IIHs. Most implementations today set the default ISISHoldingMultiplier to 3 for both circuit types.
実際には、ISISHoldingMultiplierのための10の値が大きすぎることが証明されています。 DECnetのPhaseVは、二つの関連値を定義しました。 3のデフォルト値を持つ変数holdingMultiplierは、ポイントツーポイントIIHSのために使用された、可変ISISHoldingMultiplierながら、10のデフォルト値と、LAN IIHSのために使用しました。ほとんどの実装では、今日は、両方の回路タイプのために3にデフォルトISISHoldingMultiplierを設定します。
Note that adjacent systems may use different values for Holding Time and will form an adjacency with non-symmetric hold times.
隣接システムは、保持時間に異なる値を使用してもよいし、非対称保持時間との隣接関係を形成することに留意されたいです。
An implementation MAY allow ISISHoldingMultiplier to be configurable. Values lower than 3 are unstable, and may cause adjacencies to flap.
実装はISISHoldingMultiplierが構成されることを可能にします。 3より低い値は不安定であり、隣接関係がフラップすることがあります。
Some values that were defined as variables in ISO 10589 do not vary in practice. These include
ISO 10589の変数として定義されたいくつかの値は実際には変化しません。これらは、
(1) ID Length - the length of the SystemID
（1）IDの長さ - システムIDの長さ
(2) maximumAreaAddresses
（2）maximumAreaAddresses
(3) Protocol Version
（3）プロトコルバージョン
The ID Length is a field carried in all PDUs. The ID Length defines the length of the System ID, and is allowed to take values from 0 to 8. A value of 0 is interpreted to define a length of 6 bytes. As suggested in B.1.1.3 of [1], it is easy to use an Ethernet MAC address to generate a unique 6 byte System ID. Since the SystemID only has significance within the IGP Domain, 6 bytes has proved to be easy to use and ample in practice. There are also new IS-IS Traffic Engineering TLVs which assume a 6 byte System ID. Choices for the ID length other than 6 are difficult to support today. Implementations may interoperate without being able to deal with System IDs of any length other than 6.
IDの長さは、すべてのPDUで運ばれる分野です。 IDの長さは、システムIDの長さを定義し、0の値は6バイトの長さを定義するために解釈される0から8までの値を取ることが許されます。 [1]のB.1.1.3で示唆したように、ユニークな6バイトのシステムIDを生成するためのイーサネットMACアドレスを使用するように簡単です。システムIDが唯一のIGPドメイン内の意義を持っているので、6つのバイトが実際に使いやすく、十分な広さであることが判明しました。あり、新たなIS-IS 6バイトのシステムIDを想定トラフィックエンジニアリングのTLV。 6以外のIDの長さのための選択肢は、今日サポートするのは困難です。実装は6以外の任意の長さのシステムIDに対応できずに相互運用することができます。
An implementation MUST use an ID Length of 6, and MUST check the ID Length defined in the IS-IS PDUs it receives. If a router encounters a PDU with an ID Length different from 0 or 6, section 7.3.15.a.2
実装は6のID長を使用しなければならない、そしてそれが受信するIS-IS PDUの中で定義されたIDの長さをチェックしなければなりません。ルータは0または6とは異なるID長のPDUを検出した場合、セクション7.3.15.a.2
dictates that it MUST discard the PDU, and SHOULD generate an appropriate notification. ISO 10589 defines the notification iDFieldLengthMismatch, while the IS-IS MIB [7] defines the notification isisIDLenMismatch.
それはPDUを破棄しなければならないことを指示し、適切な通知を生成する必要があります。 IS-IS MIB [7]通知isisIDLenMismatchを定義しながら、ISO 10589は、通知iDFieldLengthMismatchを定義します。
The value of maximumAreaAddresses is defined to be an integer between 1 and 254, and defines the number of synonymous Area Addresses that can be in use in an L1 area. This value is advertised in the header of each IS-IS PDU.
maximumAreaAddressesの値は1と254の間の整数であると定義し、L1領域で使用中であることができる同義エリアアドレスの数を定義しています。この値は、各IS-IS PDUのヘッダでアドバタイズされます。
Most deployed networks use one Area Address for an L1 area. When merging or splitting areas, a second address is required for seamless transition. The third area address was originally required to support DECnet PhaseIV addresses as well as OSI addresses during a transition.
ほとんどのネットワークは、L1領域の1つの領域アドレスを使用して展開。マージまたは領域を分割する際に、第2のアドレスは、シームレスな遷移のために必要とされます。第3の領域のアドレスは、もともとのDECnet PhaseIVがアドレスならびにOSIは、移行中アドレスをサポートするために必要でした。
ISO 10589 requires that all Intermediate Systems in an area or domain use a consistent value for maximumAreaAddresses. Common practice is for an implementation to use the value 3. Therefore an implementation that only supports 3 can expect to interoperate successfully with other conformant systems.
ISO 10589は、地域やドメイン内のすべての中間システムがmaximumAreaAddressesための一貫した値を使用する必要があります。実装が値3よってのみ3は、他の準拠のシステムで正常に相互運用することを期待することができますサポートする実装を使用するのが一般的です。
ISO 10589 specifies that an advertised value of 0 is treated as equivalent to 3, and that checking the value for consistency may be omitted if an implementation only supports the value 3.
ISO 10589は、0のアドバタイズされた値は3に等しい、および実装が唯一の値3をサポートしている場合、整合性の値をチェックすることを省略することができるものとして扱われることを指定します。
An implementation SHOULD use the value 3, and it SHOULD check the value advertised in IS-IS PDUs it receives. If a router receives a PDU with maximumAreaAddresses that is not 0 or 3, it MUST discard the PDU, as described in section 7.3.15.a.3, and it SHOULD generate an appropriate notification. ISO 10589 defines the notification maximumAreaAddressMismatch, while the IS-IS MIB [7] defines the notification isisMaxAreaAddressesMismatch.
実装では、値3を使用する必要があり、それが受信IS-ISのPDUでアドバタイズ値をチェックする必要があります。ルータは0又は3でないmaximumAreaAddresses有するPDUを受信した場合、セクション7.3.15.a.3に記載されているように、それは、PDUを破棄しなければならず、適切な通知を生成する必要があります。 IS-IS MIB [7]通知isisMaxAreaAddressesMismatchを定義しながら、ISO 10589は、通知maximumAreaAddressMismatchを定義します。
IS-IS PDUs include two one-byte fields in the headers: "Version/Protocol ID Extension" and "Version".
IS-IS PDUは、ヘッダーで2つの1バイトのフィールドを含める：「バージョン/プロトコルID拡張子」と「バージョン」。
An implementation SHOULD set both fields to 1, and it SHOULD check the values of these fields in IS-IS PDUs it receives. If a router receives a PDU with a value other than 1 for either field, it MUST drop the packet, and SHOULD generate the isisVersionSkew notification.
実装は1に両方のフィールドを設定する必要があり、それが受信IS-IS PDUの中にこれらのフィールドの値をチェックする必要があります。ルータは、いずれかのフィールドのために1以外の値を持つPDUを受信すると、パケットをドロップする必要があり、そしてisisVersionSkew通知を生成する必要があります。
Section 7.2.2, ISO 10589 describes four metrics: Default Metric, Delay Metric, Expense Metric, and Error Metric. None but the Default Metric are used in deployed networks, and most implementations only consider the Default Metric. In ISO 10589, the most significant bit of the 8 bit metrics was the field S (Supported), used to define if the metric was meaningful.
デフォルトのメトリック、遅延メトリック、費用メトリック、およびエラーメトリック：7.2.2項では、ISO 10589は、4つのメトリックを説明しています。デフォルトのメトリックが、どれも展開されたネットワークで使用されていない、とほとんどの実装はデフォルトのメトリックを検討してください。 ISO 10589では、8ビットメトリックの最上位ビットは、メトリックが有意義であった場合に定義するために使用されるフィールドS（サポート）、でした。
If this IS does not support this metric it shall set bit S to 1
to indicate that the metric is unsupported.
The Supported bit was always 0 for the Default Metric, which must always be supported. However, RFC 2966 [5] uses this bit in the Default Metric to mark L1 routes that have been leaked from L1 to L2 and back down into L1 again.
サポートされているビットは常にサポートされている必要があり、デフォルトのメトリックのために常に0でした。しかし、RFC 2966 [5]再びダウンL1にL1からL2への漏洩とされているL1ルートをマークするために、デフォルトのメトリックは、このビットを使用します。
Implementations MUST generate the Default Metric when using narrow metrics, and SHOULD ignore the other three metrics when using narrow metrics. Implementations MUST assume that the Default Metric is supported, even if the S bit is set. RFC 2966 describes restrictions on leaking such routes learned from L1 into L2.
実装は狭いメトリックを使用した場合、デフォルトのメトリックを生成しなければならない、と狭いメトリックを使用した場合、他の3つの指標を無視します。実装は、Sビットがセットされている場合でも、デフォルトのメトリックがサポートされていると仮定しなければなりません。 RFC 2966は、L2にL1から学んだような経路をリークする上での制限事項について説明します。
Since IS-IS does not allow segmentation of protocol PDUs, Link State PDUs (LSPs) must be propagated without modification on all IS-IS enabled links throughout the area/domain. Thus it is essential to configure a maximum size that all routers can forward, receive, and store.
IS-ISプロトコルPDUのセグメント化を許可していないので、すべてのIS-ISエリア/ドメイン全体にリンクを有効に、リンク州のPDU（LSPは）変更せずに伝播する必要があります。したがって、すべてのルータが、転送受信、および格納できる最大サイズを設定することが不可欠です。
This affects three aspects, which we discuss in turn:
これは、私たちが順番に議論する三つの側面を、影響を与えます。
(1) The largest LSP we can receive (ReceiveLSPBufferSize)
（1）私たちが受け取ることができる最大のLSP（ReceiveLSPBufferSize）
(2) The size of the largest LSP we can generate (originatingL1LSPBufferSize and originatingL2LSPBufferSize)
（2）我々が生成することができる最大LSPのサイズ（originatingL1LSPBufferSizeとoriginatingL2LSPBufferSize）
(3) Available Link MTU for supported Circuits (MTU). Note this often differs from the MTU available to IP clients.
（3）サポート回路のために利用可能なリンクのMTU（MTU）。これは、多くの場合、IPクライアントが利用可能なMTUと異なって注意してください。
ISO 10589 defines the architectural constant ReceiveLSPBufferSize with value 1492 bytes, and two private management parameters, originatingL1LSPBufferSize for level 1 PDUs and originatingL2LSPBufferSize for level 2 PDUs. The originating buffer size parameters define the maximum size of an LSP that a router can generate. ISO 10589 directs the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error.
ISO 10589は、レベル2のPDUのためのレベル1のPDUとoriginatingL2LSPBufferSizeためoriginatingL1LSPBufferSize、値が1492バイトであり、2つのプライベート管理パラメータを建築定数ReceiveLSPBufferSizeを定義します。発信バッファサイズパラメータは、ルータが生成することができるLSPの最大サイズを定義します。 ISO 10589には、エラーとしてReceiveLSPBufferSizeより大きいPDUを治療するための実装を指示します。
It is crucial that originatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSize and that for all L1 links in the area originatingL1LSPBufferSize <= MTU and for all L2 links in the domain originatingL2LSPBufferSize <= MTU
それが重要であることoriginatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSizeエリアoriginatingL1LSPBufferSize内の全てのL1リンクのためのその<= MTUドメインoriginatingL2LSPBufferSize内のすべてのL2リンクの<= MTU
The original thought was that operators could decrease the originating Buffer size when dealing with smaller MTUs, but would not need to increase ReceiveLSPBufferSize beyond 1492.
独創的な考えは、小さいMTUで扱うときにオペレーターが元のバッファサイズを減少させることができたということでしたが、1492を超えてReceiveLSPBufferSizeを増やす必要はありません。
With the definition of new information to be advertised in LSPs, such as the Traffic Engineering TLVs, the limited space of the LSP database which may be generated by each router (256 * 1492 bytes at each level) has become an issue. Given that modern networks with MTUs larger than 1492 on all links are not uncommon, one method which can be used to expand the LSP database size is to allow values of ReceiveLSPBufferSize greater than 1492.
そのようなトラフィックエンジニアリングのTLVとしてのLSPにアドバタイズされる新しい情報の定義と、各ルータによって生成されてもよいLSPデータベース（各レベルで256 * 1492バイト）の限られた空間が問題となっています。すべてのリンク上の1492よりも大きなMTUを持つ近代的なネットワークは珍しくないことを考えると、LSPデータベースのサイズを拡張するために使用できる1つの方法は、1492年よりReceiveLSPBufferSizeの値が大きくなるようにすることです。
Allowing ReceiveLSPBUfferSize to become a configurable parameter rather than an architectural constant must be done with care: if any system in the network does not support values larger than 1492 or one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP which may be generated by any router, then full propagation of all LSPs may not be possible, resulting in routing loops and black holes.
ReceiveLSPBUfferSizeが設定可能なパラメータではなく、建築の定数になることを許可することは注意して行う必要があります：ネットワーク内の任意のシステムが値をサポートしていない場合はどこかの領域/ドメインでのIS-ISが使用するよりも大きい1492のまたは1つ以上のリンクのMTUが小さいです任意のルータによって生成され得る最大LSPよりも、すべてのLSPの完全な伝播は、ルーティングループとブラックホールをもたらす、可能ではないかもしれません。
The steps below are recommended when changing ReceiveLSPBufferSize.
ReceiveLSPBufferSizeを変更する場合、以下の手順が推奨されています。
(1) Set the ReceiveLSPBufferSize to a consistent value throughout the network.
（1）ネットワーク全体で一貫性のある値にReceiveLSPBufferSizeを設定します。
(2) The implementation MUST not enable IS-IS on circuits which do not support an MTU at least as large as the originating BufferSize at the appropriate level.
（2）実装が可能ではないしなければならない適切なレベルで発生たBufferSizeと少なくとも同じ大きMTUをサポートしていない回路上で、です。
(3) Include an originatingLSPBufferSize TLV when generating LSPs, introduced in section 9.8 of ISO 10589:2002 [1].
2002 [1]：（3）ISO 10589のセクション9.8に導入originatingLSPBufferSize TLV生成LSPを、含めます。
(4) When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifications and Alarms.
LSPを受信した場合（4）、originatingLSPBufferSize TLVを確認し、そして定義された通知とアラームを介しReceiveLSPBufferSizeの局所値より大きい値の受信を報告します。
(5) Report the receipt of a PDU larger than the local ReceiveLSPBufferSize through the defined Notifications and Alarms.
（5）定義通知およびアラームを介してローカルReceiveLSPBufferSizeより大きいPDUの受信を報告します。
(6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misconfigured network.
（6）デフォルトでは、大きなPDUを廃棄しないでください。通常のPDUとして、それらを保存して処理することは誤って設定、ネットワーク内の一貫性を維持するのを助けることができます。
Steps 1 and 2 are enough by themselves, but the consequences of mismatch are serious enough and difficult enough to detect, that steps 3-6 are recommended to help track down and correct problems.
ステップ1と2は、それ自体で十分ですが、不一致の結果が検出するのに十分深刻で、十分に困難であり、推奨されている3-6ステップこと、正しい問題を追跡するのに役立ちます。
To prevent the establishment of adjacencies between systems which may not be able to successfully receive and propagate IS-IS PDUs due to inconsistent settings for originatingLSPBufferSize and ReceiveLSPBufferSize, section 8.2.3 of [1] requires padding on point-to-point links.
[1]は、ポイントツーポイントリンク上のパディングが必要で起因originatingLSPBufferSizeとReceiveLSPBufferSize、セクション8.2.3のための一貫性のない設定に正常に受信し、IS-IS PDUを伝播することができないかもしれないシステム間の隣接関係の確立を防止することができます。
On point-to-point links, the initial IIH is to be padded to the maximum of
ポイントツーポイントリンク上で、初期IIHが最大にパディングされます
(1) Link MTU
（1）リンクMTU
(2) originatingL1LSPBufferSize if the link is to be used for L1 traffic
リンクL1のトラフィックに使用する場合（2）originatingL1LSPBufferSize
(3) originatingL2LSPBufferSize if the link is to be used for L2 traffic
リンクL2のトラフィックのために使用される場合（3）originatingL2LSPBufferSize
In section 6.7.2 e) ISO 10589 assumes
セクション6.7.2 e）においてISOの10589は想定してい
Provision that failure to deliver a specific subnetwork SDU
will result in the timely disconnection of the subnetwork
connection in both directions and that this failure will be
reported to both systems
With this service provided by the link layer, the requirement that only the initial IIH be padded was sufficient to check the consistency of the MTU on the two sides. If the PDU was too big to be received, the link would be reset. However, link layer protocols in use on point-to-point circuits today often lack this service, and the initial padded PDU might be silently dropped without resetting the circuit. Therefore, the requirement that only the initial IIH be padded does not provide the guarantees anticipated in ISO 10589.
リンク層が提供するこのサービスでは、唯一の初期IIHが埋められ要件は、両側にMTUの整合性をチェックするのに十分でした。 PDUが受信されるには余りにも大きかった場合は、リンクがリセットされます。しかし、ポイントツーポイント回線上で使用する今日では、リンク層プロトコルは、多くの場合、このサービスを欠いており、初期のパディングPDUは黙って回路をリセットせずに廃棄される可能性があります。したがって、唯一の初期IIHが埋められ要件は、ISO 10589に予想される保証するものではありません。
If an implementation is using padding to detect problems, point-to-point IIH PDUs SHOULD be padded until the sender declares an adjacency on the link to be in state Up. If the implementation implements RFC 3373 [4], "Three-Way Handshake for IS-IS Point-to-Point Adjacencies" then this is when the three-way state is Up: if the implementation use the "classic" algorithm described in ISO 10589, this is when adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be resumed whenever the adjacency is torn down, and SHOULD continue until the sender declares the adjacency to be in state Up again.
実装が問題を検出するためのパディングを使用している場合は、送信者が状態のアップになるように、リンク上の隣接関係を宣言するまで、ポイントツーポイントIIH PDUが水増しされるべきです。実装は、RFC 3373を実装している場合、三方状態がアップすると、[4]、「IS-ISポイントツーポイント隣接関係のためのスリーウェイハンドシェイクは、」これはです：実装がISOに記載された「古典的」アルゴリズムを使用している場合10589 adjacencyStateがアップすると、これはあります。パッド入りのIIH PDUの送信は、隣接関係が切断されるたびに再開されるべきであり、送信者がアップ再び状態にあると隣接関係を宣言するまで継続すべきです。
If an implementation is using padding, and originatingL1LSPBUfferSize or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be brought down and reestablished so the protection provided by padding IIH PDUs is performed consistent with the modified values.
実装はパディングを使用して、及びoriginatingL1LSPBUfferSize又はoriginatingL2LSPBUfferSizeが変更された場合、パディングIIHのPDUによって提供される保護が変更された値と一致して行われるので、隣接関係がダウンと再確立されるべきです。
Some implementations choose not to pad. Padding does not solve all problems of misconfigured systems. In particular, it does not provide a transitive relation. Assume that A, B, and C all pad IIH PDUs, that A and B can establish an adjacency, and that B and C can establish an adjacency. We still cannot conclude that A and C could establish an adjacency, if they were neighbors.
一部の実装では、パッドにないことを選択しました。パディングは、誤って設定システムのすべての問題を解決しません。特に、それは推移関係を提供していません。すべてのパッドIIHのPDUをA、B、及びCと仮定し、A及びBは、隣接関係を確立することができ、そのB及びCは、隣接関係を確立することができます。私たちは、まだ彼らは隣人だったらAとCは、隣接関係を確立することができると結論することはできません。
The presence or absence of padding TLVs MUST NOT be one of the acceptance tests applied to a received IIH regardless of the state of the adjacency.
パディングのTLVの有無が隣接の状態に関係なく受信されたIIHに適用される受け入れテストの一つであるはずがありません。
A checksum of 0 is impossible if the checksum is computed according to the rules of ISO 8473 [8].
0のチェックサムはチェックサムはISO 8473のルールに従って計算された場合には不可能である[8]。
ISO 10589, section 7.3.14.2(i), states:
ISO 10589、セクション7.3.14.2（I）、状態：
A Link State PDU received with a zero checksum shall be treated
as if the Remaining Lifetime were zero. The age, if not zero,
shall be overwritten with zero.
That is, ISO 10589 directs the receiver to purge the LSP. This has proved to be disruptive in practice. An implementation SHOULD treat all LSPs with a zero checksum and a non-zero remaining lifetime as if they had as checksum error. Such packets SHOULD be discarded.
それは、ISO 10589は、LSPをパージする受信機を指示し、です。これは、実際には破壊的であることが判明しました。実装はゼロチェックサムと彼らはチェックサムエラーが発生した場合など、非ゼロの残りの寿命を持つすべてのLSPを扱うべきです。このようなパケットが破棄されるべきです。
While ISO 10589 requires in section 7.3.14.2 e) that any LSP received with an invalid PDU checksum should be purged, this has been found to be disruptive. Most implementations today follow the revised specification, and simply drop the LSP.
ISO 10589は、任意のLSPがパージされなければならない無効なPDUチェックサムと受信したこと）セクション7.3.14.2 Eに必要ながら、これは破壊的であることが見出されています。ほとんどの実装では、今日は、改訂された仕様に従ってください、と単純にLSPをドロップします。
In ISO 10589:2002 [1], Section 7.3.14.2, it states:
ISO 10589では：2002 [1]、セクション7.3.14.2、それは述べて：
(e) An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax SHOULD
（e）に間違ったLSPチェックサムまたは無効なPDUの構文でリンクステートPDUを受信中級システムSHOULD
1) generate a corruptedLSPReceived circuit event,
1）、corruptedLSPReceived回路イベントを生成
2) discard the PDU.
2）PDUを廃棄します。
In section 8.2.4.2, ISO 10589 does not explicitly require comparison of the source ID of a received IIH with the neighbourSystemID associated with an existing adjacency on a point-to-point link.
セクション8.2.4.2では、ISO 10589は、明示的にポイントツーポイントリンク上の既存の隣接関係に関連したneighbourSystemIDと受信IIHのソースIDの比較を必要としません。
To address this omission, implementations receiving an IIH PDU on a point to point circuit with an established adjacency SHOULD check the Source ID field and compare that with the neighbourSystemID of the adjacency. If these differ, an implementation SHOULD delete the adjacency.
この漏れに対処するために、確立された隣接して回路をポイントツーポイントにIIH PDUを受信した実装は、Source IDフィールドを確認し、隣接のneighbourSystemIDとそれを比較する必要があります。これらが異なる場合、実装は、隣接関係を削除する必要があります。
Given that IIH PDUs as specified in ISO 10589 do not include a check-sum, it is possible that a corrupted IIH may falsely indicate a change in the neighbor's System ID. The required subnetwork guarantees for point-to-point links, as described in 6.7.2 g) 1) assume that undetected corrupted PDUs are very rare (one event per four years). A link with frequent errors that produce corrupted data could lead to flapping an adjacency. Inclusion of an optional checksum TLV as specified in "Optional Checksums in IS-IS" [6], may be used to detect such corruption. Hello packets carrying this TLV that are corrupted PDUs SHOULD be silently dropped, rather than dropping the adjacency.
ISO 10589で指定されたIIH PDUはチェックサムが含まれていないことを考えると、破損したIIHが誤って隣人のシステムIDの変化を示すことが可能です。 6.7.2 Gに記載されているように、ポイントツーポイントリンクのために必要なサブネットワーク保証は、1）））四年ごとに1つのイベント（未検出の破損PDUが非常に稀であると仮定する。破損したデータを生成頻繁にエラーが発生したリンクは、隣接羽ばたきにつながる可能性があります。 「IS-ISで任意チェックサム」で指定されるように、オプションのチェックサムTLVを含めることは、[6]、このような破損を検出するために使用することができます。こんにちは、破損したPDUです。このTLVを運ぶパケットは黙って、むしろ隣接関係を落とすよりも、廃棄されるべきです。
Some implementations have chosen to discard received IIHs where the source ID differs from the neighbourSystemID. This may prevent needless flapping caused by undetected PDU corruption. If an actual administrative change to the neighbor's system ID has occurred, using this strategy may require the existing adjacency to timeout before an adjacency with the new neighbor can be established. This is expedited if the neighbor resets the circuit as anticipated in 10589 after a System ID change, or resets the 3-way adjacency state, as anticipated in RFC 3373.
いくつかの実装では、ソースIDがneighbourSystemIDは異なる受信IIHSを破棄することを選択しました。これは検出されないPDUの破損に起因する不要なフラッピングを防ぐことができます。隣人のシステムIDへの実際の管理上の変更が発生した場合は、この戦略を使用すると、新しい隣人との隣接関係を確立することができる前にタイムアウトするために、既存の隣接関係が必要な場合があります。隣人が10589で予想通り、システムID変更後の回路をリセットする、またはRFC 3373に予想されるように、3ウェイ隣接状態をリセットする場合にこれが促進されます。
When an Intermediate System shuts down, it may leave old LSPs in the network. In the normal course of events, a rebooting system flushes out these old LSPs by reissuing those fragments with a higher sequence number, or by purging fragments that it is not currently generating.
中間システムがシャットダウンすると、それはネットワークに古いLSPを残すことができます。イベントの通常の過程では、再起動システムは、またはそれは、現在生成されていない断片をパージすることによって、より高いシーケンス番号を持つこれらの断片を再発行することにより、これらの古いLSPを洗い流します。
In the case where a received LSP or SNP entry and an LSP in the local database have the same LSP ID, same sequence number, non-zero remaining lifetimes, but different non-zero checksums, the rules defined in [1] cannot determine which of the two is "newer". In this case, an implementation may opt to perform an additional test as a tie breaker by comparing the checksums. Implementations that elect to use this method MUST consider the LSP/SNP entry with the higher checksum as newer. When comparing the checksums the checksum field is treated as a 16 bit unsigned integer in network byte order (i.e., most significant byte first).
ローカルデータベース内の受信LSPまたはSNPエントリとLSP場合に同じLSP ID、同一のシーケンス番号、非ゼロの残り寿命が、異なる非ゼロチェックサム、で定義された規則は、[1]を決定することができないました2の「新しい」です。この場合、実装は、チェックサムを比較することによって、タイ・ブレーカーのような追加のテストを実行することを選ぶことができます。この方法を使用することを選ぶ実装は、より新しい、より高いサムとLSP / SNPエントリを考慮する必要があります。チェックサムを比較した場合、チェックサムフィールドは、ネットワークバイト順（即ち、最上位バイトが最初）に16ビットの符号なし整数として扱われます。
The choice of higher checksum, rather than lower, while arbitrary, aligns with existing implementations and ensures compatibility.
いうよりも、チェックサムの選択は、より低い、任意ながら、既存の実装と整列し、互換性を保証します。
Note that a purged LSP (i.e., an LSP with remaining lifetime set to 0) is always considered newer than a non-purged copy of the same LSP.
パージされたLSP（0に設定し、残りの寿命と、すなわち、LSP）が常に同じLSPの非パージコピーよりも新しいとみなされることに留意されたいです。
There are a number of cases in which a complete set of CSNPs must be generated. The DIS on a LAN, two IS's peering over a P2P link, and an IS helping another IS perform graceful restart must generate a complete set of CSNPs to assure consistent LSP Databases throughout. Section 7.3.15.3 of [1] defines a complete set of CSNPs to be:
cSNPの完全なセットを生成する必要がある例がいくつかあります。 LAN上のDIS、P2Pリンク上の2つのISのピアリング、および他を支援しているが全体で一貫したLSPデータベースを確実にするためのcSNPの完全なセットを生成する必要があり、グレースフルリスタートを実行しています。 [1]のセクション7.3.15.3にすべきのcSNPの完全なセットを定義します。
"A complete set of CSNPs is a set whose Start LSPID and End
LSPID ranges cover the complete possible range of LSPIDs.
(i.e., there is no possible LSPID value which does not appear
within the range of one of the CSNPs in the set). "
Strict adherence to this definition is required to ensure the reliability of the update process. Deviation can lead to subtle and hard to detect defects. It is not sufficient to send a set of CSNPs which merely cover the range of LSPIDs which are in the local database. The set of CSNPs must cover the complete possible range of LSPIDs.
この定義の厳守は、更新プロセスの信頼性を確保するために必要とされます。偏差が微妙と検出が困難な欠陥につながることができます。単に、ローカルデータベースにあるLSPIDsの範囲をカバーするのcSNPのセットを送信するのに十分ではありません。 cSNPのセットはLSPIDsの完全な可能な範囲をカバーしなければなりません。
Consider the following example:
次の例を考えてみます。
If the current Level 1 LSP database on a router consists of the following non pseudo-node LSPs:
ルータの現在のレベル1 LSPデータベースは、以下の非擬似ノードLSPの構成されている場合：
From system 1111.1111.1111 LSPs numbered 0-89(59H) From system 2222.2222.2222 LSPs numbered 0-89(59H)
システムから1111.1111.1111 LSPはシステム2222.2222.2222のLSPから0から89（59H）は0から89（59H）を番号の番号
If the maximum size of a CSNP is 1492 bytes, then 90 CSNP entries can fit into a single CSNP PDU. The following set of CSNP start/end LSPIDs constitute a correctly formatted complete set:
CSNPの最大サイズは1492バイトである場合、次に90のCSNPエントリは単一CSNP PDUに収まることができます。 CSNP開始/終了LSPIDsの以下のセットが正しくフォーマットされた完全なセットを構成します：
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FF
LSPIDエンドLSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FFを開始
The following are examples of incomplete sets of CSNPS:
次のcSNPの不完全なセットの例は以下のとおりです。
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A 2222.2222.2222.00-59
開始LSPID終了LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A 2222.2222.2222.00-59
The sequence above has a gap after the second entry.
上記のシーケンスは、第2のエントリの後にギャップを有しています。
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.2222.00-00 FFFF.FFFF.FFFF.FF-FF
スタートLSPIDエンドLSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.2222.00-00 FFFF.FFFF.FFFF.FF-FF
The sequence above has a gap between the first and second entry.
配列は、前述の第1及び第2のエントリとの間に隙間を有しています。
Although it is legal to send a CSNP which contains no actual LSP entry TLVs, it should never be necessary to do so in order to conform to the specification.
それは実際のLSPエントリTLVを含まないCSNPを送信するために法的ですが、仕様に準拠するためにはそうする必要はありません。
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.
それが受け取るすべてのLSPを格納からISを防ぐ一時的な問題に対処するには、ISO 10589は、セクション7.3.19でのLSPデータベース過負荷状態を定義します。 ISデータベースの過負荷状態にあるときに、それが生成する非擬似のLSP番号ゼロに過負荷ビットと呼ばれるフラグをセットします。 ISO 10589のセクション7.2.8.1は、オーバーロードを使用していない他のシステムに指示するトランジットルータとしてです。オーバーロードされているが、完全な情報を持っていないので、正しいルートを計算することができないかもしれない、とルーティングループを開発することができ。
An overloaded router might become the DIS. An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored.
オーバーロードされたルータがDISになる可能性があります。実装は、それが生成する擬似のLSPに過負荷ビットを設定してはならず、擬似のLSPに見られる過負荷ビットは無視されるべきです。
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].
ISO 10589に記載しているプロトコルで変化がないとして、この文書の明確化は、新たなセキュリティ上の問題を提起していない[1]。
[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] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, September 2002.
[4]カッツ、D.とSaluja、R.、 "ポイントツーポイント隣接関係中間システムへの中間システム（IS-IS）のためのスリーウェイハンドシェイク"、RFC 3373、2002年9月。
[5] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[5]李、T.、Przygienda、T.とH.スミット、 "IS-IS二レベルでドメイン全体のプレフィックス配布"、RFC 2966、2000年10月。
[6] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate System to Intermediate System (ISIS)", RFC 3358, August 2002.
[6] Koodli、R.とR. Ravikanth、 "中間システムへの中間システム（ISIS）でオプションのチェックサム"、RFC 3358、2002年8月。
[7] Parker, J., "Management Information Base for IS-IS", Work in Progress, January 2004.
[7]パーカー、J.、 "IS-ISのための管理情報ベース"、進歩、2004年1月中に作業を。
[8] ITU, "Information technology - Protocol for providing the connectionless-mode network service", ISO/IEC 8473-1, 1998.
[8] ITU、 "情報技術 - プロトコル接続モード・ネットワーク・サービス提供のために"、ISO / IEC 8473から1、1998。
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. 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 Aravind Ravikumar, who pointed out that we should check Source ID on point-to-point IIH packets. 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、そしてデイブ・カッツのおかげで、。常に何かを説明する準備ができているラディア・パールマン、に感謝します。正しく書かれたものを見ることに粘り強いたサティシュDattatri、に感謝します。書き込み彼が触れたすべてのトピックの治療を改善ラスホワイト、に感謝します。細心の注意をいくつかの草稿を読んシャンカールVemulapalli、に感謝します。ドン・グッドスピードのおかげで、テキストの彼の近い読書のため。我々はポイントツーポイントIIHパケットにソースIDを確認する必要があることを指摘しAravind Ravikumar、に感謝します。ヤンL.A.バン・デ・Snepscheutからの引用を識別するためのマイケル・コイル氏に感謝します。舞台裏アレックスジニンのministrationsいただきありがとうございます。議論は雑草に方向転換としてトラック上で私たちを守っトニー・リーとトニーPrzygienda、に感謝します。そして貢献しますが、名前が、私はうっかりこのリストから、残っているしているすべての人に感謝します。
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機能のための基金は現在、インターネット協会によって提供されます。