[要約] RFC 3719は、IS-ISを使用した相互運用可能なネットワークのための推奨事項を提供しています。このRFCの目的は、IS-ISプロトコルを使用して異なるネットワーク間での通信を効果的に実現するためのガイドラインを提供することです。
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)
中間システムから中間システム（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）The Internet Society（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プロトコルを実装、テスト、展開する人へのサービスとして議論されています。コンパニオンドキュメントでは、RFC 1195に記載されているプロトコルと、IPトラフィックをルーティングするために今日展開されているプロトコルの違いについて説明します。
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
理論的には、理論と実践の間に違いはありません。しかし、実際にはあります。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 [1]に記載されているように、IS-ISの元の設計は非常に耐久性があることが証明されています。ただし、多くのオリジナルの設計の選択肢が変更されています。このドキュメントでは、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].
このドキュメントの「必須」、「そうでなければならない」、「そうでなければ」、「すべきではない」、「すべきではない」、「必要」は、RFC 2119 [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には、生成ISで最初に最大値に設定されている残りのフィールドが含まれています。このフィールドに保存されている値は、時間の経過と転送された回数をマークするために減少します。外国のLSPの値が0になると、ANはネットワークから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はISO 10589で20分のアーキテクチャ定数として定義されており、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の関係については、ISO 10589のセクション7.3.21で説明します。maxageがMaximumLSPGenerationIntervalよりも小さい場合、LSPは交換する前に期限切れになります。さらに、残りのlifeTimeは転送されるたびに減少すると、その起源から遠く離れたLSPが古く見え、より早く除去されます。LSPが交換するのに十分な長さで生き残ることを確認するために、Maxageは少なくともZeroAgeLifetime MinimutLSPTransitionIntervalによってMaximumLSPGenerationIntervalを超える必要があります。最初の用語であるZeroAgeLifetimeは、ネットワークを介してLSPを浸水させるのにどれくらいの時間がかかるかの推定値です。2番目の用語である最小限のlspTransmissionIntervalは、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は、MaximumLspGenerationIntervalを少なくとも300秒超えている必要があります。以下で説明するように、実装では、その価値の価値をピアから廃棄するためにその価値を使用してはなりません。
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.
LSPに割り当てた残りのlifeTimeを受け入れる残りの値に調整するために実装は必要ありません。また、セクション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."
「[受信したLSPの]残りの寿命の値が最大値よりも大きい場合、LSPはチェックサムエラーがあるかのように処理されます。」
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 Sendsは、IS Hello Protocol Data Units（IIHS）がアクティブな回路で定期的に定期的に、他の接続されたルーターがそれらの味を監視できるようにします。IIHには、隣接する時間を定義する保持時間と呼ばれる2バイトフィールドが含まれています。ISがこの保有時間内に隣接する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は、IsisholdingMultiplierを10であると定義し、保持時間の価値は通常のシステムにIsishellotimerを乗算し、DisishellotimerをDisishellotimerであると述べています。これは、隣人が隣接する時間の前に10 IIHを失わなければならないことを意味します。
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の値は大きすぎることが証明されています。Decnet Phasevは2つの関連する値を定義しました。デフォルト値が3の変数HoldingMultiPlierは、ポイントツーポイントIIHSに使用されましたが、デフォルト値が10の変数ISISHOLDINGMULTIPLIERがLAN IIHに使用されました。現在のほとんどの実装は、両方の回路タイプのデフォルトのisisholdingMultiplierを3に設定しています。
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の長さ - SystemIDの長さ
(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から8の値を取得することが許可されています。6バイトの長さを定義する値は解釈されます。[1]のb.1.1.3で示唆されているように、イーサネットMacアドレスを使用して、一意の6バイトシステムIDを生成するのは簡単です。SystemIDはIGPドメイン内でのみ重要であるため、6バイトは使いやすく、実際に十分であることが証明されています。また、6バイトシステムIDを想定する新しいISトラフィックエンジニアリング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 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.
実装は6のID長さを使用する必要があり、受信するIS PDUで定義されているIDの長さを確認する必要があります。ルーターが0または6とは異なるIDの長さでPDUに遭遇した場合、セクション7.3.15.a.2は、PDUを破棄する必要があることを決定し、適切な通知を生成する必要があります。ISO 10589は通知IDFieldLengthMismatchを定義し、IS-IS MIB [7]は通知ISISIDLENMISMATCHを定義します。
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 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では、エリアまたはドメイン内のすべての中間システムが最大アレアアドレスに対して一貫した値を使用することを要求しています。一般的な慣行は、実装が値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で宣伝されている値を確認する必要があります。セクション7.3.15.a.3で説明されているように、ルーターが最大値を備えたPDUを受信した場合、PDUを破棄する必要があり、適切な通知を生成する必要があります。ISO 10589は、通知の最大値を定義し、IS-IS MIB [7]は通知ISISMAXAREAADDRESSSMISMATCHを定義します。
IS-IS PDUs include two one-byte fields in the headers: "Version/Protocol ID Extension" and "Version".
IS-IS PDUには、ヘッダーに「バージョン/プロトコルID拡張機能」と「バージョン」という2つの1バイトフィールドが含まれています。
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.
これがこのメトリックをサポートしていない場合、メトリックがサポートされていないことを示すために、ビットSを1に設定するものとします。
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からL2にリークされ、L1に再び戻ってきた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は、L1からL2に学んだそのようなルートの漏れに関する制限について説明しています。
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のセグメンテーションを許可していないため、リンク状態PDU（LSP）は、エリア/ドメイン全体のすべてのIS有効なリンクに変更せずに伝播する必要があります。したがって、すべてのルーターが転送、受信、保存できる最大サイズを構成することが不可欠です。
This affects three aspects, which we discuss in turn:
これは3つの側面に影響します。これについては、次のように説明します。
(1) The largest LSP we can receive (ReceiveLSPBufferSize)
(1) 受け取ることができる最大のLSP（Receivelspbufferize）
(2) The size of the largest LSP we can generate (originatingL1LSPBufferSize and originatingL2LSPBufferSize)
(2) 生成できる最大のLSPのサイズ（OriginatingL1LSPBufferSizeおよびOrigingL2LSPBufferize）
(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は、値1492バイトと2つのプライベート管理パラメーターを持つアーキテクチャの定数receivelspbuffersizeを定義します。元のバッファサイズパラメーターは、ルーターが生成できるLSPの最大サイズを定義します。ISO 10589は、recevelspbufferizeよりも大きな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 ingiringl2lspbuffersize <= receivelspbuffersize、および領域のすべてのL1リンクについて、<= mtuおよびドメイン原産地のすべてのL2リンクについて、curivingl1lspbuffersize <= mtu <= mtu <= 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で宣伝される新しい情報の定義により、各ルーター（各レベルで256 * 1492バイト）によって生成されるLSPデータベースの限られたスペースが問題になりました。すべてのリンクで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.
ReceivelSpbufferizeがアーキテクチャの定数ではなく構成可能なパラメーターになることを許可する必要があります。ネットワーク内のシステムが1492を超える値をサポートしていない場合、またはIS-ISがエリア/ドメインで使用するIS-ISが使用する1つ以上のリンクMTUは小さくなります任意のルーターによって生成される可能性のある最大のLSPよりも、すべてのLSPの完全な伝播が不可能であるため、ルーティングループとブラックホールが得られます。
The steps below are recommended when changing ReceiveLSPBufferSize.
ReceivelSpbufferizeを変更する場合は、以下の手順をお勧めします。
(1) Set the ReceiveLSPBufferSize to a consistent value throughout the network.
(1) ReceivelSpbufferizeをネットワーク全体で一貫した値に設定します。
(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) この実装により、少なくとも適切なレベルで発生する緩衝液ほど大きいMTUをサポートしていない回路上のIS-ISを有効にしてはなりません。
(3) Include an originatingLSPBufferSize TLV when generating LSPs, introduced in section 9.8 of ISO 10589:2002 [1].
(3) ISO 10589：2002 [1]のセクション9.8で導入されたLSPSを生成するときに、TLVの発生型を含めます。
(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.
(4) LSPを受信するときは、TLVの発信元sspbuffersizeを確認し、定義された通知とアラームを介してReceivelspbufferizeのローカル値よりも大きい値の受領を報告します。
(5) Report the receipt of a PDU larger than the local ReceiveLSPBufferSize through the defined Notifications and Alarms.
(5) 定義された通知とアラームを介して、ローカルのReceivelspbufferizeよりも大きい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]のセクション8.2.3には、ポイントとポイントリンクのパディングが必要であるため、発信されたlspbuffersize and receivelspbuffersizeの一貫性のない設定のために、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
(2) リンクがL1トラフィックに使用される場合は、Originingl1lspbufferize
(3) originatingL2LSPBufferSize if the link is to be used for L2 traffic
(3) リンクがL2トラフィックに使用される場合は、Originingl2lspbufferize
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
特定のサブネットワークSDUの提供に失敗すると、両方向にサブネットワーク接続がタイムリーに切断され、この障害が両方のシステムに報告されるという提供
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ポイントツーポイント隣接の3方向の握手」は、これが3方向の状態が上がっているときです。実装がISOで説明されている「クラシック」アルゴリズムを使用する場合10589、これは隣接ステートが起きているときです。パッド入りの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が変更されている場合、隣接を倒して再確立する必要があります。
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.
一部の実装は、パッドしないことを選択します。パディングは、誤解されたシステムのすべての問題を解決しません。特に、推移的な関係は提供されません。a、b、およびcすべてのすべてのpad iih pdus、aとbが隣接性を確立できると仮定し、bとcが隣接性を確立できると仮定します。Aと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に適用される受け入れテストの1つであってはなりません。
A checksum of 0 is impossible if the checksum is computed according to the rules of ISO 8473 [8].
ISO 8473 [8]のルールに従ってチェックサムが計算される場合、0のチェックサムは不可能です。
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.
ゼロチェックサムで受け取ったリンク状態PDUは、残りの寿命がゼロであるかのように扱われるものとします。ゼロではないにしても、年齢はゼロで上書きされます。
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では、セクション7.3.14.2 e）では、無効なPDUチェックサムで受け取ったLSPをパージする必要がありますが、これは破壊的であることがわかっています。今日のほとんどの実装は、改訂された仕様に従い、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を受信する中間システム
1) generate a corruptedLSPReceived circuit event,
1) 腐敗した回路イベントを生成し、
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を受信する実装は、ソースIDフィールドを確認し、それを隣接のNeighbourSystemsyDと比較する必要があります。これらが異なる場合、実装は隣接を削除する必要があります。
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で説明されているように、ポイントツーポイントリンクに必要なサブネットワーク保証は、検出されない破損したPDUが非常にまれであると仮定します（4年に1回のイベント）。破損したデータを生成する頻繁なエラーを伴うリンクは、隣接を羽化することにつながる可能性があります。「IS-ISのオプションチェックサム」[6]で指定されているオプションのチェックサムTLVを含めることは、そのような腐敗を検出するために使用できます。破損した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がNeighbourSystemsIDと異なる場合に受信したIIHを破棄することを選択しています。これは、検出されないPDU腐敗によって引き起こされる不必要な羽ばたきを防ぐ可能性があります。近隣のシステムIDへの実際の管理変更が発生した場合、この戦略を使用すると、新しい隣人との隣接が確立される前に、既存の隣接がタイムアウトを必要とする場合があります。これは、RFC 3373で予想されるように、システムIDが変更された後、10589年に予想される10589で回路をリセットする場合、隣の回路をリセットする場合に迅速になります。
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をより高いシーケンス番号で再発行するか、現在生成していないフラグメントをパージすることにより、これらの古い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、2つはP2Pリンクを覗き込んでおり、ANは別のISを支援します。[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). "
「CSNPの完全なセットは、lspid範囲の開始範囲とend lspid範囲がlspidsの完全な範囲をカバーするセットです（つまり、セットのCSNPの1つの範囲内に表示されないLSPID値はありません）。「
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.
更新プロセスの信頼性を確保するには、この定義の厳密な順守が必要です。偏差は、欠陥を検出するのが微妙で困難につながる可能性があります。ローカルデータベースにあるLSPIDの範囲を単にカバーするCSNPのセットを送信するだけでは不十分です。CSNPのセットは、LSPIDの完全な範囲をカバーする必要があります。
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.111111111111からLSPSが番号0-89（59H）システム2222.2222.2222からLSPS番号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 Start/End LSPIDのセットは、正しくフォーマットされた完全なセットを構成します。
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 end 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 end lspid 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5a 2222.2222.22222.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 end lspid 0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.22222.00-00 ffff.ffff.ffff.ff-ff
The sequence above has a gap between the first and second entry.
上記のシーケンスには、最初のエントリと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.
ANが受信するすべてのLSPを保存するのを防ぐ一時的な問題に対処するために、ISO 10589はセクション7.3.19のLSPデータベース過負荷条件を定義します。ISがデータベースの過負荷状態にある場合、生成する非視中LSP番号ゼロにオーバーロードビットと呼ばれるフラグを設定します。ISO 10589のセクション7.2.8.1は、過負荷を使用しない他のシステムがトランジットルーターとして使用するよう指示しています。オーバーロードされたISには完全な情報がないため、適切なルートを計算できず、ルーティングループが発生する可能性があります。
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で過負荷ビットを設定しないでください。また、Pseudonode 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、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをルーティングする中間システム（ISO 8473）」、ISO/IEC 10589：2002。
[2] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.
[2] Callon、R。、「OSIはIPおよびデュアル環境のIS-IS」、RFC 1195、1990年12月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Katz、D。およびSaluja、R。、「中間システムの中間システム（IS-IS）ポイントツーポイント隣接の3方向の握手」、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] Li、T.、Przygienda、T。、およびH. Smit、「2レベル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、「情報技術 - Connectionless-Modeネットワークサービスを提供するためのプロトコル」、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.
このドキュメントは多くの人々の仕事であり、1000件以上のメールメッセージの蒸留です。そのようなドキュメントの作成を推し進めたVishwas Manralに感謝します。元の編集者であるDanny McPhersonに感謝します。マイク・シャンドのおかげで、プロトコルの作成において彼の仕事と、すべてが何のために何なのかを思い出す彼の不気味な能力です。ミカ・バルテルとフィリップ・クリスチャンに感謝します。フィリップ・クリスチャンは、不和を表示せずに違いを記録する方法を教えてくれました。Les Ginsberg、Neal Castagnoli、Jeff Learman、およびDave Katzに感謝します。常に何かを説明する準備ができているRadia Perlmanに感謝します。正しく書かれたものを見るのを粘り強くしたサティッシュ・ダッタトリに感謝します。ラス・ホワイトのおかげで、その執筆は彼が触れたすべてのトピックの扱いを改善しました。Shankar Vemulapalliに感謝します。ShankarVemulapalliは、いくつかのドラフトを読んだことがあります。テキストをよく読んでくれたドングッドスピードに感謝します。Aravind Ravikumarに感謝します。Ravikumarは、ポイントツーポイントIIHパケットでソースIDを確認する必要があることを指摘しました。Jan L.A. van de Snepscheutからの引用を特定してくれたMichael Coyleに感謝します。舞台裏でアレックス・ジニンのミニストレーションをありがとう。Tony LiとTony Przygiendaに感謝します。トニー・プリギエンダは、議論が雑草に向かっていたので、私たちを順調に進めています。そして、貢献したが、その名前がこのリストから不注意に残したすべての人に感謝します。
Jeff Parker Axiowave Networks 200 Nickerson Road Marlborough, Mass 01752 USA
ジェフパーカーアシオウェイブネットワーク200ニッカーソンロードマールボロ、マサチューセッツ州01752 USA
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。