RFC3719 日本語訳
3719 Recommendations for Interoperable Networks using IntermediateSystem to Intermediate System (IS-IS). J. Parker, Ed.. February 2004. (Format: TXT=33941 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Parker, Ed. Request for Comments: 3719 Axiowave Networks Category: Informational February 2004
ワーキンググループのJ.パーカー、エドをネットワークでつないでください。コメントのために以下を要求してください。 3719Axiowaveはカテゴリをネットワークでつなぎます: 情報の2004年2月
Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)
中間システムに中間システムを使用する共同利用できるネットワークのための推薦(IS-IS)
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントがIntermediate Systemの違いのa番号についてIntermediate Systemと議論する、(-、)、それが今日配備されるのでISO10589とプロトコルで説明されるように、議定書を作ってください。 これらの違いが実行していて、テストしていて、展開しているそれらに対するサービスとして議論されている、-、プロトコル それが今日ルーティングIP交通に配備されるとき、仲間ドキュメントはRFC1195で説明されたプロトコルとプロトコルの違いについて議論します。
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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 変数. . . . . . . . . . . . . . . . . 2 3である定数。 定数. . . . . . . . . . . . . . . . . 4 4である変数。 代替の測定基準. . . . . . . . . . . . . . . . . . . . . 6 5。 ReceiveLSPBufferSize。 . . . . . . . . . . . . . . . . . . . . 6 6. こんにちは、PDUsを水増しします。 . . . . . . . . . . . . . . . . . . . . . 8 7. チェックサム. . . . . . . . . . . . . . . . . . . . . . . . 9 8のゼロを合わせてください。 除くのはLSPsを崩壊させました。 . . . . . . . . . . . . . . . . . . . 10 9. Receivedの二地点間IIH PDUsでSystem IDをチェックします。 . . . 10 10. ドッペルゲンガーLSPs. . . . . . . . . . . . . . . . . . . . . . 11 11。 CSNPsの完全なセットを発生させます。 . . . . . . . . . . . . . 11 12. ビットを積みすぎてください。 . . . . . . . . . . . . . . . . . . . . . . . . 12 13. セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 14。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. 承認. . . . . . . . . . . . . . . . . . . . . . . 14 16。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 14 17。 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 15
Parker Informational [Page 1] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[1ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
1. Introduction
1. 序論
In theory, there is no difference between theory and practice. But in practice, there is. Jan L.A. van de Snepscheut
理論上、理論と習慣の間には、違いが全くありません。 しかし、実際には、あります。 ジャンL.A.バン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.
内部のゲートウェイプロトコル、-、経路ドメインで最も良いルートに関する時宜を得た情報を提供するために、設計されています。 当初の設計、-、ISOで説明されるように、10589[1]はかなり長持ちしていると判明しました。 しかしながら、多くの当初の設計選択が変更されました。 このドキュメントはISO10589で説明されたプロトコルと今日ワイヤの上に観測できるプロトコルの違いを記述します。 仲間ドキュメントはルーティングIP交通と現在の習慣のためのRFC1195[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"、「必須NOT」“SHOULD"、「」 「5月」はRFC2119[3]で説明されるように本書では解釈されることになっているべきです。
2. Constants That Are Variable
2. 可変である定数
Some parameters that were defined as constant in ISO 10589 are modified in practice. These include the following
ISO10589で同じくらい一定の状態で定義されたいくつかのパラメタが実際には変更されます。 これらは以下を含んでいます。
(1) MaxAge - the lifetime of a Link State PDU (LSP)
(1)MaxAge--Link州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--後のセクションで、議論します。
2.1. MaxAge
2.1. MaxAge
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値へのセットがあるということであるRemainingLifetime分野を含んでいます。 この分野に格納された値は、時間の経過とそれを送ってある回数をマークするために減少します。 外国LSPの値が0になると追放する、開始aはLSPを洗い流す過程からネットワークから追放していますか? これが、それが崩壊したのを確実にするか、またはそうでなければ、無効のLSPsはネットワークに無期限に残っていません。 LSPsによる作り直されて、由来があるということであるレートはmaximumLSPGenerationIntervalの値によって測定されます。
Parker Informational [Page 2] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[2ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
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はISO10589で20分のArchitectural定数と定義されます、そして、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.
.21セクション7.3ISO10589でMaxAgeとmaximumLSPGenerationIntervalとの関係について議論します。 MaxAgeがmaximumLSPGenerationIntervalより小さいなら、それを取り替える前にLSPは期限が切れるでしょう。 さらに、RemainingLifetimeがそれを進めるたびに減少するのに従って、起源から遠いLSPは、より古く見えて、より早く、取り外されます。 LSPが取り替えることができるくらいの長い間生き残るのを確実にするために、MaxAgeは少なくともZeroAgeLifetime+minimumLSPTransmissionIntervalでmaximumLSPGenerationIntervalを超えているはずです。 前期(ZeroAgeLifetime)はネットワークを通してLSPをあふれさせるにはどれくらいかかるかに関する見積りです。 2番目の用語(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 SHOULDは少なくとも300秒までにmaximumLSPGenerationIntervalを超えています。 SHOULD NOTがLSPsを捨てるのに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.
実現は、ISO10589についてそれが受け入れるRemainingLifetime値にそれがLSPsに割り当てるRemainingLifetimeを調整するのが必要でなく、.3にセクション7.3.16からの以下の文を無視しなければなりません。
"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."
「Remaining Lifetime[容認されたLSPの]の値がMaxAgeより大きいなら、まるでチェックサム誤りがあるかのようにLSPは処理されるものとします。」
2.2. ISISHoldingMultiplier
2.2. ISISHoldingMultiplier
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.
発信、アクティブなサーキットの上の周期的ベースのHelloプロトコルData Units(IIHs)であり、付属ルータがそれらの生きるのをモニターするのを別に許容しながら、あります。 IIHは隣接番組を住ませる時間を定義するHolding Timeと呼ばれる2バイトの分野を含んでいます。 こんにちはを受けない、隣接しているのが、この把持時間中に、隣接があるということである、想定される、もう操作上にならないでください、そして、隣接番組を取り除きます。
Parker Informational [Page 3] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[3ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
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.
ISO10589は、10になるようにISISHoldingMultiplierを定義して、Holding Timeの値が普通のシステムのためのiSISHelloTimer、およびDISのためのdRISISHelloTimerが掛けられたISISHoldingMultiplierであるべきであると述べます。 これは、隣人が隣接番組回のアウトの前の10IIHsをなくさなければならないのを含意します。
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は2つの関連する値を定義しました。 3のデフォルト値で、可変holdingMultiplierはポイントツーポイントIIHsに使用されました、10のデフォルト値で、可変ISISHoldingMultiplierがLAN IIHsに使用されましたが。 ほとんどの実現が今日、両方のサーキットタイプのためにデフォルトISISHoldingMultiplierを3に設定します。
Note that adjacent systems may use different values for Holding Time and will form an adjacency with non-symmetric hold times.
隣接しているシステムがHolding Timeに異価を使用するかもしれなくて、非左右対称の保持時間で隣接番組を形成することに注意してください。
An implementation MAY allow ISISHoldingMultiplier to be configurable. Values lower than 3 are unstable, and may cause adjacencies to flap.
実現は、ISISHoldingMultiplierが構成可能であることを許容するかもしれません。 3より低値で、不安定であり、隣接番組はばたつくかもしれません。
3. Variables That Are Constant
3. 一定の変数
Some values that were defined as variables in ISO 10589 do not vary in practice. These include
ISO10589の変数と定義されたいくつかの値は実際には異なりません。 これらのインクルード
(1) ID Length - the length of the SystemID
(1)ID Length--SystemIDの長さ
(2) maximumAreaAddresses
(2) maximumAreaAddresses
(3) Protocol Version
(3) プロトコルバージョン
3.1. ID Length
3.1. IDの長さ
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 LengthはすべてのPDUsで運ばれた野原です。 ID LengthはSystem IDの長さを定義して、0〜8まで値を取ることができます。 0の値は、6バイトの長さを定義するために解釈されます。 [1]のB.1.1.3に示されるように、6バイトのユニークなSystem IDを発生させるのにイーサネットMACアドレスを使用するのは簡単です。 SystemIDがIGP Domainの中に意味を持っているだけであるので、6バイトは使用しやすくて実際には十分であると判明しました。 新しくもある、-、6バイトがSystem IDであると仮定するTraffic Engineering TLVs。 6以外のIDの長さのための選択は今日支持するのが難しいです。 6以外のどんな長さのSystem 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 Lengthを使用しなければならなくて、Lengthが定義したIDを預けなければならない、-、それが受けるPDUs。 ルータが0か6と異なったID Length、セクション7.3.15.a.2とPDUに遭遇するなら
Parker Informational [Page 4] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[4ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年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を捨てなければならなくて、SHOULDが適切な通知を発生させると決めます。 ISO10589が通知iDFieldLengthMismatchを定義する、-、IS MIB、[7]は通知isisIDLenMismatchを定義します。
3.2. maximumAreaAddresses
3.2. maximumAreaAddresses
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領域で使用中である場合がある同義のArea Addressesの数を定義します。 それぞれのヘッダーにこの値の広告を出す、-、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領域に1Area Addressを使用します。 領域を合併するか、または分けるとき、2番目のアドレスがシームレスの変遷に必要です。 3番目の領域アドレスが、元々、変遷の間のOSIアドレスと同様にDECnet PhaseIVアドレスをサポートするのに必要でした。
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.
ISO10589は、領域かドメインのすべてのIntermediate SystemsがmaximumAreaAddressesに一貫した値を使用するのを必要とします。 一般的な習慣は値3を使用する実現のためのものです。 したがって、3しか支持しない実現は、他のconformantシステムで首尾よく共同利用すると予想できます。
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.
ISO10589は、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.
実現SHOULDが値3、およびそれを使用する、SHOULDが広告に掲載された値を預ける、-、それが受けるPDUs。 ルータが0歳でないmaximumAreaAddressesか3でPDUを受けるなら、PDUを捨てなければなりません、セクション7.3.15.a.3、およびそれでSHOULDについて説明するので。適切な通知を発生させてください。 ISO10589が通知maximumAreaAddressMismatchを定義する、-、IS MIB、[7]は通知isisMaxAreaAddressesMismatchを定義します。
3.3. Protocol Version
3.3. プロトコルバージョン
IS-IS PDUs include two one-byte fields in the headers: "Version/Protocol ID Extension" and "Version".
-、PDUsはヘッダーの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.
実現SHOULDが1、およびそれへのSHOULDがこれらの分野の値をチェックする両方の分野を設定した、-、それが受けるPDUs。 ルータがどちらかの分野への1以外の値でPDUを受けるなら、パケットを落とさなければなりません、そして、SHOULDはisisVersionSkew通知を発生させます。
Parker Informational [Page 5] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[5ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
4. Alternative Metrics
4. 代替の測定基準
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 ISO10589は4つの測定基準について説明します: メートル法の、そして、遅れメートル法の費用メートル法であって、誤りメートル法で、デフォルトとしてください。 Default Metricだけが配備されたネットワークに使用されます、そして、ほとんどの実現がDefault Metricを考えるだけです。 ISO10589では、8ビットの測定基準の最も重要なビットは分野Sでした(支持されます)、メートル法が重要であったかどうかを定義するのにおいて、使用されています。
If this IS does not support this metric it shall set bit S to 1 to indicate that the metric is unsupported.
メートル法でこれを支持してください。これがそう、それは、1へのビットSにメートル法がそうであることを示すようにサポートされない状態で設定するものとします。
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.
いつもSupportedビットはDefault Metricのための0でした。(いつもDefault Metricを支持しなければなりません)。 しかしながら、RFC2966[5]は、再びL1に行き帰りL1からL2まで漏らされたL1ルートをマークするのにDefault Metricでこのビットを使用します。
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.
狭い測定基準を使用するとき、実現はDefault Metricを発生させなければなりません、そして、狭い測定基準を使用するとき、SHOULDは他の3つの測定基準を無視します。 Sビットが設定されても、実現は、Default Metricが支持されると仮定しなければなりません。 RFC2966はL1からL2に学習されたそのようなルートを漏らすときの制限について説明します。
5. ReceiveLSPBufferSize
5. ReceiveLSPBufferSize
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.
以来、-、プロトコルPDUsの分割を許容してください、すべてで変更なしでLink州PDUs(LSPs)を伝播しなければならない、-、領域/ドメイン中でリンクを可能にしました。 したがって、すべてのルータが進めて、受けて、格納できる最大サイズを構成するのは不可欠です。
This affects three aspects, which we discuss in turn:
これは3つの局面に影響します:(私たちは順番に局面について議論します)。
(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) 支持されたCircuits(MTU)のための利用可能なLink 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
ISO10589はレベル2PDUsのためのレベル1のPDUsとoriginatingL2LSPBufferSizeのために値の1492バイト、および2つの自営業パラメタ、originatingL1LSPBufferSizeと建築一定のReceiveLSPBufferSizeを定義します。 由来しているバッファ
Parker Informational [Page 6] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[6ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
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.
サイズ・パラメータはルータが発生させることができるLSPの最大サイズを定義します。 ISO10589は、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<=MTUのすべてのL1リンクとドメイン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.
独創的な考えはオペレータが、より小さいMTUsに対処するとき、由来しているBufferサイズを減少させることができましたが、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.
Traffic Engineering TLVsなどのLSPsに広告を出すべき新情報の定義によると、各ルータ(各レベルにおける256*1492バイト)で発生するかもしれないLSPデータベースの限られたスペースは問題になりました。 MTUsがすべてのリンクの上の1492年より大きい現代のネットワークが珍しくないなら、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が建築定数よりむしろ構成可能なパラメタになるのを許容するのが慎重に完了していなければなりません: ネットワークにおけるどんなシステムも1492か1より大きい値を支持しないか、または以上が使用されていた状態でMTUsをリンクする、-、すべてのLSPsの当時の完全な伝播はどんなルータでも発生するかもしれない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].
(3) ISO10589のセクション9.8で導入されたLSPsを発生させるときにはoriginatingLSPBufferSize TLVを含めてください: 2002[1]。
(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) LSPsを受けるときには、originatingLSPBufferSize TLV、およびレポートがないかどうか定義されたNotificationsとAlarmsを通して、ReceiveLSPBufferSizeの地方の値より大きい値の領収書をチェックしてください。
Parker Informational [Page 7] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[7ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
(5) Report the receipt of a PDU larger than the local ReceiveLSPBufferSize through the defined Notifications and Alarms.
(5) 定義されたNotificationsとAlarmsを通して、PDUの領収書が地方のReceiveLSPBufferSizeより大きいと報告してください。
(6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misconfigured network.
(6) デフォルトで大きいPDUsを捨てないでください。 正常なPDUsが助けるかもしれないように、それらを格納して、処理すると、一貫性はmisconfiguredネットワークで維持されます。
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.
ミスマッチの結果が十分重大であって、検出できるくらい難しく、ステップ3-6が問題を捜し出して、修正するのを助けることが勧められていなかったなら、ステップ1と2は自分たちで十分です。
6. Padding Hello PDUs
6. こんにちは、PDUsを水増しします。
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に当然のPDUsは、ポイントツーポイント接続の上でそっと歩くのを必要とします。
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に使用されるつもりであるなら、originatingL1LSPBufferSizeは取引します。
(3) originatingL2LSPBufferSize if the link is to be used for L2 traffic
(3) リンクがL2に使用されるつもりであるなら、originatingL2LSPBufferSizeは取引します。
In section 6.7.2 e) ISO 10589 assumes
セクション6.7.2e)で ISO10589は仮定します。
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だけが水増しされるという要件は、2つの側の上のMTUの一貫性をチェックするために十分でした。 PDUが受け取ることができないくらい大きいなら、リンクはリセットされるでしょうに。 しかしながら、二地点間サーキットで使用中のリンクレイヤプロトコルは今日しばしばこのサービスを欠いています、そして、サーキットをリセットしないで、初期のそっと歩いているPDUは静かに落とされるかもしれません。 したがって、初期のIIHだけが水増しされるという要件はISO10589で予期された保証を提供しません。
Parker Informational [Page 8] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[8ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
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 PDUs SHOULDを検出するには、送付者が、リンクの上の隣接番組が州のUpにあると宣言するまで、水増しされてください。 実現がRFC3373[4]を実行するなら「3方向ハンドシェイク、-、ポイントからポイントへの3者間の状態がUpである隣接番組: 実現であるなら、ISO10589で説明された「古典的な」アルゴリズムを使用してください、そして、これはadjacencyStateがUpである時です。 トランスミッション、そっと歩いているIIH PDUs SHOULDでは、隣接番組を取りこわすときはいつも、再開されてください。そうすれば、送付者が、隣接番組が再び州のUpにあると宣言するまで、SHOULDは続きます。
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が変更されているなら、保護が提供されて、降ろされて、復職した隣接番組SHOULDは、IIH PDUsを水増しすることによって、変更された値と一致していた状態で実行されます。
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.
いくつかの実現が、そっと歩かないのを選びます。 詰め物はmisconfiguredシステムのすべての問題を解決するというわけではありません。特に、それは推移関係を提供しません。 A、B、およびCがIIH PDUsをすべて水増しして、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.
TLVsを水増しする存在か不在が隣接番組の状態にかかわらず容認されたIIHに適用された受取り検査の1つであるはずがありません。
7. Zero Checksum
7. チェックサムがありません。
A checksum of 0 is impossible if the checksum is computed according to the rules of ISO 8473 [8].
ISO8473[8]の規則に従ってチェックサムが計算されるなら、0のチェックサムは不可能です。
ISO 10589, section 7.3.14.2(i), states:
ISO10589(セクション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.
aゼロチェックサムで受け取られたLink州PDUはまるでRemaining Lifetimeがゼロであるかのように扱われるものとします。 時代(ゼロでなくても)はゼロで上書きされるものとします。
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.
すなわち、ISO10589は、LSPを掃除するよう受信機に指示します。 これは実際には破壊的であると判明しました。 実現SHOULDは、まるで彼らが残っていたかのようにチェックサム誤りとして生涯残りながら、チェックサムがなくて非ゼロですべてのLSPsを扱います。 そのようなパケットSHOULD、捨てられてください。
Parker Informational [Page 9] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[9ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
8. Purging Corrupted PDUs
8. 除くのはPDUsを崩壊させました。
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.
ISO10589が、セクション7.3.14.2e)で無効のPDUチェックサムで受け取られたどんなLSPも掃除されるべきであるのを必要としている間、これは破壊的であることがわかっています。 ほとんどの実現が、今日訂正明細書に従って、単にLSPを落とします。
In ISO 10589:2002 [1], Section 7.3.14.2, it states:
ISO10589: 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 Checksumか無効のPDU構文SHOULDでLink州PDUを受けるIntermediateシステム
1) generate a corruptedLSPReceived circuit event,
1) corruptedLSPReceivedサーキット出来事を発生させてください。
2) discard the PDU.
2) PDUを捨ててください。
9. Checking System ID in Received point-to-point IIH PDUs
9. Receivedの二地点間IIH PDUsでSystem IDをチェックします。
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、ISO10589は要求しません。ポイントツーポイント接続の上の既存の隣接番組に関連している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.
SHOULDは、この省略、確立した隣接番組でサーキットを指すためにポイントの上でIIH PDUを受ける実現を記述するために、Source ID分野をチェックして、隣接番組のneighbourSystemIDとそれを比べます。 これらが異なるなら、実現SHOULDは隣接番組を削除します。
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.
ISO10589の指定されるとしてのIIH PDUsがチェックサムを含んでいないなら、崩壊したIIHが間違って隣人のSystem IDの変化を示すのは、可能です。 ポイントツーポイント接続のための6.7で.2g説明されるような必要なサブネットワーク保証 1) 非検出された崩壊したPDUsが非常にまれであると(4年あたり1回の出来事)仮定してください。 崩壊したデータを作り出す頻繁な誤りとのリンクは、隣接番組をばたつかせるのに通じるかもしれません。 中で指定されるとしての任意のチェックサムTLVの包含、「中の任意のチェックサム、-、」 [6] そのような不正を検出するのに使用されるかもしれません。 こんにちは、隣接番組を落とすよりむしろ落とされて、崩壊したPDUs SHOULDであるこの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
いくつかの実現が、ソースIDがneighbourSystemIDと異なっている容認されたIIHsを捨てるのを選びました。 これはundetected PDU不正で引き起こされた不必要なばたつくことを防ぐかもしれません。 隣人のシステムIDへの実際の管理変化が起こったなら、新しい隣人がいる隣接番組を確立できる前にこの戦略を使用するのは既存の隣接番組をタイムアウトに必要とするかもしれません。 これはそうです。
Parker Informational [Page 10] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[10ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
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.
隣人がSystem ID変化の後の10589で予期されるようにサーキットをリセットするか、または3ウェイ隣接番組状態をリセットするなら、RFC3373で予期されるように、速められます。
10. Doppelganger LSPs
10. ドッペルゲンガーLSPs
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.
Intermediate Systemが停止すると、古いLSPsはネットワークで残っているかもしれません。 事の当然の成り行き上、リブートシステムは、より高い一連番号でそれらの断片を再発行するか、またはそれが現在発生させていない断片を掃除することによって、これらの古いLSPsを洗います。
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の噛み付いている符号のない整数として扱われる、(すなわち、最も重要なバイト、1番目)
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の非掃除されたコピーより新しいといつも考えられることに注意してください。
11. Generating a Complete Set of CSNPs
11. CSNPsの完全なセットを発生させます。
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:
CSNPsの完全なセットが発生しなければならない件数があります。 そして、LANのDIS、2がP2Pリンクの上にじっと見ている、別のものを助けるのは、必須があらゆる点で一貫したLSP Databasesを保証するためにCSNPsの完全なセットを発生させる優雅な再開を実行することです。 セクション7.3 .15 .3、[1]は、である:なるようにCSNPsの完全なセットを定義します。
"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). "
「CSNPsの完全なセットはStart LSPIDとEnd LSPID範囲がLSPIDsの完全な可能な範囲をカバーするセットです。」 (すなわち、CSNPsの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.
この定義への厳しい固守が、更新処理の信頼性を確実にするのに必要です。 逸脱は微妙、そして、欠陥を検出しにくいのに導くことができます。 単にローカルのデータベースにあるLSPIDsの範囲をカバーするCSNPsの1セットを送るのは十分ではありません。 CSNPsのセットはLSPIDsの完全な可能な範囲をカバーしなければなりません。
Parker Informational [Page 11] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[11ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
Consider the following example:
以下の例を考えてください:
If the current Level 1 LSP database on a router consists of the following non pseudo-node LSPs:
ルータに関する現在のLevel1LSPデータベースが以下から成る、非、疑似ノード、LSPs:
From system 1111.1111.1111 LSPs numbered 0-89(59H) From system 2222.2222.2222 LSPs numbered 0-89(59H)
0-89に付番されたシステム2222.2222.2222LSPsから0-89に付番された(59H)システム1111.1111.1111LSPsから(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に収まることができます。 LSPIDsが正しくフォーマットされた完全なセットを構成するCSNP始め/エンドの以下のセット:
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FF
FFFF.FFFF.FFFF.FF-ffあたりLSPID終わりのLSPID0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5を始めてください。
The following are examples of incomplete sets of CSNPS:
↓これはCSNPSの不完全なセットの例です:
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A 2222.2222.2222.00-59
1 2222.2222.2222.00-59あたりLSPID終わりのLSPID0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5を始めてください。
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終わりのLSPID0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.2222.00-00FFFF.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エントリーがないTLVsを含むCSNPを送るのが法的ですが、そうするのは、仕様に従うのに決して必要であるべきではありません。
12. Overload Bit
12. オーバーロードビット
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.
それが防ぐ過渡現象の問題に対処する、それが受けるすべてのLSPs、10589が定義するISOを格納するので、セクション7.3.19にはLSP Database Overload状態があります。 コネはDatabase Overloadです。いつ、状態、それは発生させる非pseudonode LSPの数のZeroにOverload Bitと呼ばれる旗をはめ込むか。 .1ISO10589が積みすぎを使用しないよう他のシステムを命令するセクション7.2.8はトランジットルータとしてそうです。 以来積みすぎがそう、完全な情報を持ってください、そして、正しいルートを計算できないかもしれなくて、ルーティング輪は展開できました。
Parker Informational [Page 12] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[12ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
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になるかもしれません。 実現SHOULDはそれが発生させるPseudoNode LSPs、およびPseudoNode LSPs SHOULDの見られるOverloadビットにOverloadビットをはめ込みませんでした。無視されます。
13. Security Considerations
13. セキュリティ問題
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].
明確化は本書ではどんな新しい安全上の配慮も上げません、ISO10589[1]で説明された基本的なプロトコルにおける変化が全くないとき。
14. References
14. 参照
14.1. Normative References
14.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、「Intermediateシステムへのプロトコルに関連したConnectionless-モードNetwork Service(ISO8473)を提供する使用のために情報交換プロトコルをrouteingする中間システム」、ISO/IEC、10589:2002
[2] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.
[2]Callon、R.、「OSI、-、IPと二元的な環境、」、RFC1195、12月1990日
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] キャッツ、D.とSaluja、R.、「中間システムへの中間システムのための3方向ハンドシェイク、(-、)、二地点間隣接番組、」、RFC3373(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.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
[6] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate System to Intermediate System (ISIS)", RFC 3358, August 2002.
[6]KoodliとR.とR.Ravikanth、「中間システム(イシス)への中間システムの任意のチェックサム」、RFC3358、2002年8月。
14.2. Informative References
14.2. 有益な参照
[7] Parker, J., "Management Information Base for IS-IS", Work in Progress, January 2004.
[7] パーカー、J.、「管理情報ベース、-、」、1月2004、進行中で、働いてください。
[8] ITU, "Information technology - Protocol for providing the connectionless-mode network service", ISO/IEC 8473-1, 1998.
[8] ITU、「情報技術--コネクションレスなモードを提供するために、ネットワーク・サービスについて議定書の中で述べる」ISO/IEC8473-1、1998。
Parker Informational [Page 13] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[13ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
15. Acknowledgments
15. 承認
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.
このドキュメントは、多くの人々の仕事であり、1,000以上のメール・メッセージの蒸留です。 Vishwas Manralをありがとうございます。(Vishwas Manralは、そのようなドキュメントを作成するために押しました)。 ダニーMcPherson、元のエディタにものを開始してくださってありがとうございます。 彼の仕事をプロトコル、およびすべてが何のためのものであったかを思い出す彼の不思議な能力を作成するのにおいてマイク・シャンドをありがとうございます。 ミカ・バーテルとフィリップクリスチャンをありがとうございます。(そのクリスチャンは、どのように不和を示さないで違いを記録するかを私たちに示しました)。 何時間もエディタを教育するのに費やしたレス・ギンズバーグ、ニールCastagnoli、ジェフLearman、およびデーヴ・キャッツをありがとうございます。 Radiaパールマンをありがとうございます。(パールマンは、いつも何でも説明する準備ができています)。 サティシュDattatriをありがとうございます。(ことが正しく詳しく書かれるのを見るのにおいてDattatriはしぶとかったです)。 ラス・ホワイトのおかげで、彼は触れました。ホワイトが書くことはあらゆる話題の処理を改良しました。 シャンカルVemulapalliをありがとうございます。(Vemulapalliは細心の注意を払っていくつかの草稿を読みます)。 彼のテキストの近い読書をドン・グッドスピードをありがとうございます。 Aravind Ravikumarをありがとうございます。(Aravind Ravikumarは、私たちが二地点間IIHパケットの上でSource IDをチェックするべきであると指摘しました)。 ジャンL.A.バンde Snepscheutからマイケル・コイルに引用を特定してくださってありがとうございます。 場面の後ろのアレックス・ジニンの奉仕をありがとうございます。 トニー・李とトニーPrzygiendaをありがとうございます。(議論が雑草に向きを変えたとき、Przygiendaは私たちを順調に保ちました)。 そして、貢献しましたが、私が不注意に名前を持っているすべてのそれらへの感謝をこのリストから外しました。
16. Author's Address
16. 作者のアドレス
Jeff Parker Axiowave Networks 200 Nickerson Road Marlborough, Mass 01752 USA
ジェフレプAxiowaveネットワーク200Nickerson Road大規模01752マールバラ(米国)
EMail: jparker@axiowave.com
メール: jparker@axiowave.com
Parker Informational [Page 14] RFC 3719 Interoperable Networks using IS-IS February 2004
共同利用できるレプ情報[14ページ]のRFC3719が使用をネットワークでつなぐ、-、2004年2月
17. Full Copyright Statement
17. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Parker Informational [Page 15]
パーカーInformationalです。[15ページ]
一覧
スポンサーリンク