[要約] RFC 7356は、IS-ISプロトコルにおけるフラッディングスコープリンクステートPDU（LSP）の仕様を定義しています。このRFCの目的は、IS-ISネットワークでのLSPのフラッディング動作を改善し、ネットワークの効率と信頼性を向上させることです。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7356 S. Previdi
Category: Standards Track Y. Yang
ISSN: 2070-1721 Cisco Systems
September 2014
IS-IS Flooding Scope Link State PDUs (LSPs)
IS-ISフラッディングスコープのリンク状態PDU（LSP）
Abstract
概要
Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.
Intermediate System to Intermediate System（IS-IS）は、ピアに効率的で信頼性の高い情報のフラッディングを提供します。ただし、現在のフラッディングスコープは、エリアスコープまたはドメインスコープに制限されています。他のフラッディングスコープのサポートが望ましい既存の使用例があります。このドキュメントでは、新しいフラッディングスコープをサポートする新しいプロトコルデータユニット（PDU）と、現在サポートされているフラッディングスコープをターゲットとする情報をアドバタイズするための追加スペースを定義します。このドキュメントでは、TypeとLengthに16ビットフィールドを使用してエンコードされた拡張Type-Length-Value（TLV）とサブTLVも定義しています。
The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.
このドキュメントで定義されているプロトコル拡張は、既存の実装との下位互換性がないため、慎重に展開する必要があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7356.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7356で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Extended TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Use of Extended TLVs and Extended Sub-TLVs . . . . . . . 5
2.2. Use of Standard Code Points in Extended TLVs and Extended
Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definition of New PDUs . . . . . . . . . . . . . . . . . . . 6
3.1. Flooding Scoped LSP Format . . . . . . . . . . . . . . . 7
3.2. Flooding Scoped CSNP Format . . . . . . . . . . . . . . . 10
3.3. Flooding Scope PSNP Format . . . . . . . . . . . . . . . 12
4. Flooding Scope Update Process Operation . . . . . . . . . . . 13
4.1. Scope Types . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Operation on Point-to-Point Circuits . . . . . . . . . . 14
4.3. Operation on Broadcast Circuits . . . . . . . . . . . . . 14
4.4. Use of Authentication . . . . . . . . . . . . . . . . . . 15
4.5. Priority Flooding . . . . . . . . . . . . . . . . . . . . 15
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
6. Graceful Restart Interactions . . . . . . . . . . . . . . . . 16
7. Multi-instance Interactions . . . . . . . . . . . . . . . . . 16
8. Circuit Scope Flooding . . . . . . . . . . . . . . . . . . . 16
9. Extending LSP Set Capacity . . . . . . . . . . . . . . . . . 17
10. Domain Scope Flooding . . . . . . . . . . . . . . . . . . . . 18
11. Announcing Support for Flooding Scopes . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . 22
The Update Process, as defined by [IS-IS], provides reliable and efficient flooding of information to all routers in a given flooding scope. Currently, the protocol supports two flooding scopes and associated PDUs. Level 1 (L1) Link State PDUs (LSPs) are flooded to all routers in an area. Level 2 (L2) LSPs are flooded to all routers in the Level 2 subdomain. The basic operation of the Update Process can be applied to any subset of the routers in a given topology so long as that topology is not partitioned. It is, therefore, possible to introduce new PDUs in support of other flooding scopes and utilize the same Update Process machinery to provide the same reliability and efficiency that the Update Process currently provides for L1 and L2 scopes. This document defines these new PDUs and the modified Update Process rules that are to be used in supporting new flooding scopes.
[IS-IS]で定義されている更新プロセスは、特定のフラッディングスコープ内のすべてのルーターに、信頼性が高く効率的な情報のフラッディングを提供します。現在、プロトコルは2つのフラッディングスコープと関連するPDUをサポートしています。レベル1（L1）のリンク状態PDU（LSP）は、エリア内のすべてのルーターにフラッディングされます。レベル2（L2）LSPは、レベル2サブドメイン内のすべてのルーターにフラッディングされます。トポロジが分割されていない限り、更新プロセスの基本操作は、特定のトポロジ内のルーターのサブセットに適用できます。したがって、他のフラッディングスコープをサポートする新しいPDUを導入し、同じ更新プロセスメカニズムを利用して、更新プロセスが現在L1およびL2スコープに提供するのと同じ信頼性と効率を提供することが可能です。このドキュメントでは、新しいフラッディングスコープのサポートに使用される、これらの新しいPDUと変更された更新プロセスルールを定義します。
New deployment cases have introduced the need for reliable and efficient circuit scope flooding. For example, Appointed Forwarder information, as defined in [RFC7176], needs to be flooded reliably and efficiently to all Routing Bridges (RBridges) on a broadcast circuit. Currently, only IS-IS Hellos (IIHs) have the matching scope -- but IIHs are unreliable, i.e., individual IIHs may be lost without affecting correct operation of the protocol. To provide reliability in cases where the set of information to be flooded exceeds the carrying capacity of a single PDU requires sending the information periodically even when no changes in the content have occurred. When the information content is large, this is inefficient and still does not provide a guarantee of reliability. This document defines circuit scope flooding in order to provide a solution for such cases.
新しい導入事例では、信頼性が高く効率的な回線スコープフラッディングの必要性が生じています。たとえば、[RFC7176]で定義されているAppointed Forwarder情報は、ブロードキャスト回線上のすべてのルーティングブリッジ（RBridge）に確実かつ効率的にフラッディングする必要があります。現在、一致するスコープを持つのはIS-IS Hello（IIH）のみですが、IIHは信頼できません。つまり、個々のIIHはプロトコルの正しい動作に影響を与えずに失われる可能性があります。フラッディングされる一連の情報が単一のPDUの伝送容量を超える場合に信頼性を提供するには、コンテンツに変更が発生していない場合でも、情報を定期的に送信する必要があります。情報量が多い場合、これは非効率的であり、信頼性を保証するものではありません。このドキュメントでは、このような場合のソリューションを提供するために、回路スコープフラッディングを定義しています。
Another existing limitation of [IS-IS] is the carrying capacity of an LSP set. It has been noted in [RFC5311] that the set of LSPs that may be originated by a system at each level is limited to 256 LSPs, and the maximum size of each LSP is limited by the minimum Maximum Transmission Unit (MTU) of any link used to flood LSPs. [RFC5311] has defined a backwards-compatible protocol extension that can be used to overcome this limitation if needed. While the [RFC5311] solution is viable, in order to be interoperable with routers that do not support the extension, it imposes some restrictions on what can/ cannot be advertised in the Extended LSPs and requires allocation of multiple unique system IDs to a given router. A more flexible and less constraining solution is possible if interoperability with legacy routers is not a requirement. By definition, the introduction of new PDUs required to support new flooding scopes is not interoperable with legacy routers. It is, therefore, possible to simultaneously introduce an alternative solution to the limited LSP set carrying capacity of Level 1 and Level 2 LSPs as part of the extensions defined in this document. This capability is also defined in this document.
[IS-IS]のもう1つの既存の制限は、LSPセットの収容能力です。 [RFC5311]で、システムによって各レベルで発信される可能性のあるLSPのセットは256 LSPに制限され、各LSPの最大サイズは任意のリンクの最小最大伝送ユニット（MTU）によって制限されることが指摘されていますLSPをフラッディングするために使用されます。 [RFC5311]は、必要に応じてこの制限を克服するために使用できる下位互換性のあるプロトコル拡張を定義しています。 [RFC5311]ソリューションは実行可能ですが、拡張機能をサポートしないルーターと相互運用できるようにするために、拡張LSPでアドバタイズできる/できないものにいくつかの制限を課し、特定のルーターに複数の一意のシステムIDを割り当てる必要があります。レガシールータとの相互運用性が必要ない場合は、より柔軟で制約の少ないソリューションが可能です。定義により、新しいフラッディングスコープをサポートするために必要な新しいPDUの導入は、レガシールータと相互運用できません。したがって、このドキュメントで定義されている拡張機能の一部として、レベル1およびレベル2 LSPのキャパシティが制限されたLSPセットの代替ソリューションを同時に導入することが可能です。この機能は、このドキュメントでも定義されています。
Standard IS-IS TLVs are encoded using an 8-bit type and an 8-bit length. In cases where the set of information about a single object exceeds 255 octets, multiple TLVs are required to encode all of the relevant information. This document introduces extended TLVs and extended sub-TLVs that use a 16-bit Type field and a 16-bit Length field.
標準のIS-IS TLVは、8ビットタイプと8ビット長を使用してエンコードされます。 1つのオブジェクトに関する情報のセットが255オクテットを超える場合、関連するすべての情報をエンコードするには、複数のTLVが必要です。このドキュメントでは、16ビットのTypeフィールドと16ビットの長さフィールドを使用する拡張TLVと拡張サブTLVを紹介します。
The PDU Type field in the common header for all IS-IS PDUs is a 5-bit field. Therefore, possible PDU types supported by the protocol are limited to a maximum of 32. In order to minimize the need to introduce additional PDU types in the future, the new PDUs introduced in this document are defined so as to allow multiple flooding scopes to be associated with the same PDU type. This means if new flooding scopes are required in the future, the same PDU type can be used.
すべてのIS-IS PDUの共通ヘッダーのPDUタイプフィールドは、5ビットのフィールドです。したがって、プロトコルでサポートされる可能なPDUタイプは最大32に制限されています。将来的に追加のPDUタイプを導入する必要性を最小限に抑えるために、このドキュメントで紹介されている新しいPDUは、複数のフラッディングスコープを許可できるように定義されています。同じPDUタイプに関連付けられています。つまり、将来新しいフラッディングスコープが必要になった場合でも、同じPDUタイプを使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Standard TLVs as defined in [IS-IS] as well as standard sub-TLVs (first introduced in [RFC5305]) have an 8-bit Type field and an eight-bit Length field. This constrains the information included in a single TLV or sub-TLV to 255 octets. With the increasing use of sub-TLVs, it becomes more likely that the amount of information about a single object that needs to be advertised may exceed 255 octets. In such cases, the information is encoded in multiple TLVs. This leads to less efficient encoding since the information that uniquely identifies the object must be repeated in each TLV and requires additional implementation complexity when receiving the information to ensure that all information about the object is correctly collected from the multiple TLVs.
[IS-IS]で定義されている標準TLVと標準サブTLV（[RFC5305]で最初に導入された）には、8ビットのTypeフィールドと8ビットの長さフィールドがあります。これにより、単一のTLVまたはサブTLVに含まれる情報が255オクテットに制限されます。サブTLVの使用の増加に伴い、アドバタイズする必要がある単一のオブジェクトに関する情報の量が255オクテットを超える可能性が高くなります。このような場合、情報は複数のTLVにエンコードされます。オブジェクトを一意に識別する情報は各TLVで繰り返す必要があり、オブジェクトに関するすべての情報が複数のTLVから正しく収集されるようにするには、情報を受信するときに追加の実装の複雑さが必要になるため、これは効率の悪いエンコーディングにつながります。
This document introduces extended TLVs and extended sub-TLVs. These are encoded using a 16-bit Type field and a 16-bit Length field.
このドキュメントでは、拡張TLVと拡張サブTLVを紹介します。これらは、16ビットのTypeフィールドと16ビットの長さフィールドを使用してエンコードされます。
The following restrictions apply to the use of extended TLVs and extended sub-TLVs:
拡張TLVと拡張サブTLVの使用には、次の制限が適用されます。
o Extended TLVs and extended sub-TLVs are permitted only in Flooding Scope PDUs that have a flooding scope designated for their use (defined later in this document)
o 拡張TLVと拡張サブTLVは、フラッディングスコープPDUでのみ使用できます。フラッディングスコープは、使用するように指定されています（このドキュメントで後ほど定義します）
o A given flooding scope supports either the use of standard TLVs and standard sub-TLVs or the use of extended TLVs and extended sub-TLVs, but not both
o 特定のフラッディングスコープは、標準TLVと標準サブTLVの使用、または拡張TLVと拡張サブTLVの使用のいずれかをサポートしますが、両方はサポートしません
o Extended TLVs and extended sub-TLVs MUST be used together, i.e., using Standard sub-TLVs within an Extended TLV or using Extended sub-TLVs within a Standard TLV is invalid
o 拡張TLVと拡張サブTLVは一緒に使用する必要があります。つまり、拡張TLV内で標準サブTLVを使用するか、標準TLV内で拡張サブTLVを使用することは無効です。
o If additional levels of TLVs (e.g., sub-sub-TLVs) are introduced in the future, then the size of the Type and Length fields in these new sub-types MUST match the size used in the parent
o TLVの追加レベル（サブsub-TLVなど）が将来導入される場合、これらの新しいサブタイプのタイプフィールドと長さフィールドのサイズは、親で使用されるサイズと一致する必要があります
o The 16-bit Type and Length fields are encoded in network byte order
o 16ビットのTypeおよびLengthフィールドは、ネットワークバイトオーダーでエンコードされます。
o Use of extended TLVs and extended sub-TLVs does not alter in any way the maximum size of PDUs that may sent or received
o 拡張TLVと拡張サブTLVを使用しても、送受信されるPDUの最大サイズは変更されません。
Standard TLV and standard sub-TLV code points as defined in the IANA "IS-IS TLV Codepoints" registry MAY be used in extended TLVs and extended sub-TLVs. Encoding is as specified for each of the standard TLVs and standard sub-TLVs with the following differences:
IANA「IS-IS TLVコードポイント」レジストリで定義されている標準TLVおよび標準サブTLVコードポイントは、拡張TLVおよび拡張サブTLVで使用できます。エンコーディングは、標準TLVと標準サブTLVのそれぞれについて指定されているとおりですが、次の違いがあります。
o The 8-bit Type field is encoded as an unsigned 16-bit integer where the 8 most significant bits (MSBs) are all 0
o 8ビットのTypeフィールドは、8つの最上位ビット（MSB）がすべて0である符号なし16ビット整数としてエンコードされます
o The 8-bit Length field is replaced by the 16-bit Length field
o 8ビットの長さフィールドは、16ビットの長さフィールドに置き換えられます
o The length MAY take on values greater than 255
o 長さは255より大きい値を取る場合があります
In support of new flooding scopes, the following new PDUs are required:
新しいフラッディングスコープをサポートするには、次の新しいPDUが必要です。
o Flooding Scope LSPs (FS-LSPs)
o フラッディングスコープLSP（FS-LSP）
o Flooding Scope Complete Sequence Number PDUs (FS-CSNPs)
o フラッディングスコープの完全なシーケンス番号PDU（FS-CSNP）
o Flooding Scope Partial Sequence Number PDUs (FS-PSNPs)
o フラッディングスコープの部分シーケンス番号PDU（FS-PSNP）
Each of these PDUs is intentionally defined with a header as similar in format as possible to the corresponding PDU types currently defined in [IS-IS]. Although it might have been possible to eliminate or redefine PDU header fields in a new way, the existing formats are retained in order to allow maximum reuse of existing PDU processing logic in an implementation.
これらの各PDUは、[IS-IS]で現在定義されている対応するPDUタイプと可能な限り同じ形式のヘッダーで意図的に定義されています。新しい方法でPDUヘッダーフィールドを削除または再定義することは可能かもしれませんが、実装で既存のPDU処理ロジックを最大限に再利用できるようにするために、既存のフォーマットが保持されます。
Note that in the case of all FS PDUs, the Maximum Area Addresses field in the header of the corresponding standard PDU has been replaced with a Scope field. Therefore, maximum area addresses checks specified in [IS-IS] are not performed on FS PDUs.
すべてのFS PDUの場合、対応する標準PDUのヘッダーの最大領域アドレスフィールドは、スコープフィールドに置き換えられていることに注意してください。したがって、[IS-IS]で指定された最大エリアアドレスチェックは、FS PDUでは実行されません。
An FS-LSP has the following format:
FS-LSPの形式は次のとおりです。
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|P| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Remaining Lifetime | 2
+-------------------------+
| FS LSP ID | ID Length + 2
+-------------------------+
| Sequence Number | 4
+-------------------------+
| Checksum | 2
+-------------------------+
|Reserved|LSPDBOL|IS Type | 1
+-------------------------+
: Variable-Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator: 0x83 (as defined in [IS-IS]).
ドメイン内ルーティングプロトコル識別子：0x83（[IS-IS]で定義）。
Length Indicator: Length of the fixed header in octets.
長さインジケータ：オクテット単位の固定ヘッダーの長さ。
Version/Protocol ID Extension: 1
バージョン/プロトコルID拡張子：1
ID Length: As defined in [IS-IS].
IDの長さ：[IS-IS]で定義されています。
PDU Type: 10 - Format as defined in [IS-IS].
PDUタイプ：10-[IS-IS]で定義されているフォーマット。
Version: 1
バージョン：1
Reserved: Transmitted as zero, ignored on receipt.
予約済み：ゼロとして送信され、受信時に無視されます。
Scope: Bits 1-7 define the flooding scope.
スコープ：ビット1〜7は、フラッディングスコープを定義します。
The value 0 is reserved and MUST NOT be used. Received FS-LSPs with a scope of 0 MUST be ignored and MUST NOT be flooded.
値0は予約されており、使用してはなりません。スコープが0の受信されたFS-LSPは無視する必要があり、フラッディングしてはいけません。
P: Bit 8 - Priority Bit. If set to 1, this LSP SHOULD be flooded at high priority.
P：ビット8-優先ビット。 1に設定されている場合、このLSPは高い優先度でフラッディングされる必要があります。
Scopes (1 - 63) are reserved for use with standard TLVs and standard sub-TLVs.
スコープ（1〜63）は、標準TLVおよび標準サブTLVで使用するために予約されています。
Scopes (64 - 127) are reserved for use with extended TLVs and extended sub-TLVs.
スコープ（64〜127）は、拡張TLVおよび拡張サブTLVで使用するために予約されています。
PDU Length: Entire length of this PDU, in octets, including the header.
PDU長：ヘッダーを含む、このPDUの全長（オクテット単位）。
Remaining Lifetime: Number of seconds before this FS-LSP is considered expired.
残りのライフタイム：このFS-LSPが期限切れと見なされるまでの秒数。
FS LSP ID: The system ID of the source of the FS-LSP. One of the following two formats is used:
FS LSP ID：FS-LSPのソースのシステムID。次の2つの形式のいずれかが使用されます。
FS LSP ID Standard Format
FS LSP ID標準フォーマット
+-------------------------+
| Source ID | ID Length
+-------------------------+
| Pseudonode ID | 1
+-------------------------+
| FS LSP Number | 1
+-------------------------+
FS LSP ID Extended Format
FS LSP ID拡張フォーマット
+-------------------------+
| Source ID | ID Length
+-------------------------+
| Extended FS LSP Number | 2
+-------------------------+
Which format is used is specific to the scope and MUST be defined when the specific flooding scope is defined.
使用される形式はスコープに固有であり、特定のフラッディングスコープを定義するときに定義する必要があります。
Sequence Number: Sequence number of this FS-LSP.
シーケンス番号：このFS-LSPのシーケンス番号。
Checksum: Checksum of contents of FS-LSP from the Source ID to the end. Checksum is computed as defined in [IS-IS].
チェックサム：ソースIDから最後までのFS-LSPの内容のチェックサム。チェックサムは、[IS-IS]の定義に従って計算されます。
Reserved/LSPDBOL/IS Type
予約済み/ LSPDBOL / ISタイプ
Bits 4-8 are reserved, which means they are transmitted as 0 and ignored on receipt.
ビット4〜8は予約されています。つまり、ビットは0として送信され、受信時に無視されます。
LSPDBOL: Bit 3 - A value of 0 indicates no FS-LSP Database Overload and a value of 1 indicates that the FS-LSP Database is overloaded. The overload condition is specific to FS-LSPs with the scope specified in the Scope field.
LSPDBOL：ビット3-値0はFS-LSPデータベースの過負荷がないことを示し、値1はFS-LSPデータベースが過負荷であることを示します。過負荷状態は、Scopeフィールドでスコープが指定されたFS-LSPに固有です。
IS Type: Bits 1 and 2. The type of Intermediate System as defined in [IS-IS].
ISタイプ：ビット1および2。[IS-IS]で定義されている中間システムのタイプ。
Variable-length fields that are allowed in an FS-LSP are specific to the defined scope.
FS-LSPで許可される可変長フィールドは、定義されたスコープに固有です。
An FS-CSNP has the following format:
FS-CSNPの形式は次のとおりです。
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|R| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Source ID | ID Length + 1
+-------------------------+
| Start FS-LSP ID | ID Length + 2
+-------------------------+
| End FS-LSP ID | ID Length + 2
+-------------------------+
: Variable-Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator: 0x83 (as defined in [IS-IS]).
ドメイン内ルーティングプロトコル識別子：0x83（[IS-IS]で定義）。
Length Indicator: Length of the fixed header in octets.
長さインジケータ：オクテット単位の固定ヘッダーの長さ。
Version/Protocol ID Extension: 1
バージョン/プロトコルID拡張子：1
ID Length: As defined in [IS-IS].
IDの長さ：[IS-IS]で定義されています。
PDU Type: 11 - Format as defined in [IS-IS].
PDUタイプ：11-[IS-IS]で定義されているフォーマット。
Version: 1 Reserved: Transmitted as zero, ignored on receipt.
バージョン：1予約済み：ゼロとして送信され、受信時に無視されます。
Scope: Bits 1-7 define the flooding scope.
スコープ：ビット1〜7は、フラッディングスコープを定義します。
The value 0 is reserved and MUST NOT be used. Received FS-CSNPs with a scope of 0 MUST be ignored.
値0は予約されており、使用してはなりません。スコープが0の受信したFS-CSNPは無視する必要があります。
Bit 8 is Reserved, which means it is transmitted as 0 and ignored on receipt.
ビット8は予約済みです。つまり、0として送信され、受信時に無視されます。
Scopes (1 - 63) are reserved for use with standard TLVs and standard sub-TLVs.
スコープ（1〜63）は、標準TLVおよび標準サブTLVで使用するために予約されています。
Scopes (64 - 127) are reserved for use with extended TLV and extended sub-TLVs.
スコープ（64〜127）は、拡張TLVおよび拡張サブTLVで使用するために予約されています。
PDU Length: Entire length of this PDU, in octets, including the header.
PDU長：ヘッダーを含む、このPDUの全長（オクテット単位）。
Source ID: The system ID of the Intermediate System (with zero Circuit ID) generating this Sequence Number's PDU.
ソースID：このシーケンス番号のPDUを生成する中間システム（ゼロの回路ID）のシステムID。
Start FS-LSP ID: The FS-LSP ID of the first FS-LSP with the specified scope in the range covered by this FS-CSNP.
開始FS-LSP ID：このFS-CSNPがカバーする範囲内で指定されたスコープを持つ最初のFS-LSPのFS-LSP ID。
End FS-LSP ID: The FS-LSP ID of the last FS-LSP with the specified scope in the range covered by this FS-CSNP.
終了FS-LSP ID：このFS-CSNPがカバーする範囲内で指定されたスコープを持つ最後のFS-LSPのFS-LSP ID。
Variable-length fields that are allowed in an FS-CSNP are limited to those TLVs that are supported by standard CSNP.
FS-CSNPで許可される可変長フィールドは、標準のCSNPでサポートされるTLVに制限されます。
An FS-PSNP has the following format:
FS-PSNPの形式は次のとおりです。
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|U| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Source ID | ID Length + 1
+-------------------------+
: Variable-Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator: 0x83 (as defined in [IS-IS]).
ドメイン内ルーティングプロトコル識別子：0x83（[IS-IS]で定義）。
Length Indicator: Length of the fixed header in octets.
長さインジケータ：オクテット単位の固定ヘッダーの長さ。
Version/Protocol ID Extension: 1
バージョン/プロトコルID拡張子：1
ID Length: As defined in [IS-IS].
IDの長さ：[IS-IS]で定義されています。
PDU Type: 12 - Format as defined in [IS-IS].
PDUタイプ：12-[IS-IS]で定義されているフォーマット。
Version: 1
バージョン：1
Reserved: Transmitted as zero, ignored on receipt.
予約済み：ゼロとして送信され、受信時に無視されます。
Scope: Bits 1-7 define the flooding scope.
スコープ：ビット1〜7は、フラッディングスコープを定義します。
The value 0 is reserved and MUST NOT be used. Received FS-PSNPs with a scope of 0 MUST be ignored.
値0は予約されており、使用してはなりません。スコープが0の受信FS-PSNPは無視する必要があります。
U: Bit 8 - A value of 0 indicates that the specified flooding scope is supported. A value of 1 indicates that the specified flooding scope is unsupported. When U = 1, variable-length fields other than authentication MUST NOT be included in the PDU.
U：ビット8-値0は、指定されたフラッディングスコープがサポートされていることを示します。値1は、指定されたフラッディングスコープがサポートされていないことを示します。 U = 1の場合、認証以外の可変長フィールドをPDUに含めることはできません。
Scopes (1 - 63) are reserved for use with standard TLVs and standard sub-TLVs.
スコープ（1〜63）は、標準TLVおよび標準サブTLVで使用するために予約されています。
Scopes (64 - 127) are reserved for use with extended TLVs and extended sub-TLVs.
スコープ（64〜127）は、拡張TLVおよび拡張サブTLVで使用するために予約されています。
PDU Length: Entire length of this PDU, in octets, including the header.
PDU長：ヘッダーを含む、このPDUの全長（オクテット単位）。
Source ID: The system ID of the Intermediate System (with zero Circuit ID) generating this Sequence Number's PDU.
ソースID：このシーケンス番号のPDUを生成する中間システム（ゼロの回路ID）のシステムID。
Variable-length fields that are allowed in an FS-PSNP are limited to those TLVs that are supported by standard PSNPs.
FS-PSNPで許可される可変長フィールドは、標準PSNPでサポートされるTLVに制限されます。
The Update Process, as defined in [IS-IS], maintains a Link State Database (LSDB) for each level supported. Each level-specific LSDB contains the full set of LSPs generated by all routers operating in that level-specific scope. The introduction of FS-LSPs creates additional LSDBs (FS-LSDBs) for each additional scope supported. The set of FS-LSPs in each FS-LSDB consists of all FS-LSPs generated by all routers operating in that scope. Therefore, there is an additional instance of the Update Process for each supported flooding scope.
[IS-IS]で定義されている更新プロセスは、サポートされている各レベルのリンク状態データベース（LSDB）を維持します。各レベル固有のLSDBには、そのレベル固有のスコープで動作しているすべてのルーターによって生成されたLSPの完全なセットが含まれています。 FS-LSPの導入により、サポートされる追加のスコープごとに追加のLSDB（FS-LSDB）が作成されます。各FS-LSDBのFS-LSPのセットは、そのスコープで動作するすべてのルーターによって生成されたすべてのFS-LSPで構成されます。したがって、サポートされているフラッディングスコープごとに、更新プロセスの追加インスタンスがあります。
Operation of the scope-specific Update Process follows the Update Process specification in [IS-IS]. The circuit(s) on which FS-LSPs are flooded is limited to those circuits that are participating in the given scope. Similarly, the sending/receiving of FS-CSNPs and FS-PSNPs is limited to the circuits participating in the given scope.
スコープ固有の更新プロセスの操作は、[IS-IS]の更新プロセス仕様に従います。 FS-LSPがフラッディングされる回線は、指定されたスコープに参加している回線に限定されます。同様に、FS-CSNPおよびFS-PSNPの送信/受信は、特定のスコープに参加している回線に限定されます。
Consistent support of a given flooding scope on a circuit by all routers operating on that circuit is required.
その回線で動作するすべてのルーターによる、回線上の特定のフラッディングスコープの一貫したサポートが必要です。
A flooding scope may be limited to a single circuit (circuit scope). Circuit scopes may be further limited by level (L1 Circuit Scope / L2 Circuit Scope).
フラッディングスコープは、単一の回路（回路スコープ）に制限できます。回路スコープは、レベル（L1回路スコープ/ L2回路スコープ）によってさらに制限される場合があります。
A flooding scope may be limited to all circuits enabled for L1 routing (area scope).
フラッディングスコープは、L1ルーティングが有効なすべての回線に限定される場合があります（エリアスコープ）。
A flooding scope may be limited to all circuits enabled for L2 routing (L2 subdomain scope).
フラッディングスコープは、L2ルーティングが有効になっているすべての回線に制限できます（L2サブドメインスコープ）。
Additional scopes may be defined that include all circuits enabled for either L1 or L2 routing (domain scope).
L1またはL2ルーティング（ドメインスコープ）のいずれかに対して有効になっているすべての回路を含む追加のスコープを定義できます。
When a new adjacency is formed, synchronization of all FS-LSDBs supported on that circuit is required; therefore, FS-CSNPs for all supported scopes MUST be sent when a new adjacency reaches the UP state. The Send Receive Message (SRM) bit MUST be set for all FS-LSPs associated with the scopes supported on that circuit. Receipt of an FS-PSNP with the U bit equal to 1 indicates that the neighbor does not support that scope (although it does support FS PDUs). This MUST cause the SRM bit to be cleared for all FS-LSPs with the matching scope, which are currently marked for flooding on that circuit.
新しい隣接関係が形成されると、その回線でサポートされるすべてのFS-LSDBの同期が必要になります。したがって、新しい隣接がUP状態に達したときに、サポートされているすべてのスコープのFS-CSNPを送信する必要があります。その回線でサポートされるスコープに関連付けられたすべてのFS-LSPに対して、Send Receive Message（SRM）ビットを設定する必要があります。 Uビットが1のFS-PSNPを受信すると、ネイバーはそのスコープをサポートしていません（FS PDUはサポートしています）。これにより、一致するスコープを持つすべてのFS-LSPのSRMビットがクリアされなければならず、現在、その回路でのフラッディングのマークが付けられています。
FS PDUs are sent to the same destination address(es) as standard PDUs for the given protocol instance. For specification of the defined destination addresses, consult [IS-IS], [IEEEaq], [RFC6822], and [RFC6325].
FS PDUは、指定されたプロトコルインスタンスの標準PDUと同じ宛先アドレスに送信されます。定義された宛先アドレスの仕様については、[IS-IS]、[IEEEaq]、[RFC6822]、および[RFC6325]を参照してください。
The Designated Intermediate System (DIS) for a broadcast circuit has the responsibility to generate periodic scope-specific FS-CSNPs for all supported scopes. A scope-specific DIS is NOT elected as all routers on a circuit MUST support a consistent set of flooding scopes.
ブロードキャスト回線用の指定中間システム（DIS）は、サポートされているすべてのスコープについて、スコープ固有のFS-CSNPを定期的に生成する責任があります。回路上のすべてのルーターが一貫したフラッディングスコープのセットをサポートする必要があるため、スコープ固有のDISは選択されません。
It is possible that a scope may be defined that is not level specific. In such a case, the DIS for each level enabled on a broadcast circuit MUST independently send FS PDUs for that scope to the appropriate level-specific destination address. This may result in redundant flooding of FS-LSPs for that scope.
レベル固有ではないスコープが定義される可能性があります。このような場合、ブロードキャスト回線で有効になっている各レベルのDISは、そのスコープのFS PDUを独立して適切なレベル固有の宛先アドレスに送信する必要があります。これにより、そのスコープのFS-LSPの冗長フラッディングが発生する可能性があります。
Authentication TLVs MAY be included in FS PDUs. When authentication is in use, the scope is first used to select the authentication configuration that is applicable. The authentication check is then performed as normal. Although scope-specific authentication MAY be used, sharing of authentication among multiple scopes and/or with the standard LSPs/CSNPs/PSNPs is considered sufficient.
認証TLVはFS PDUに含まれる場合があります。認証が使用されている場合、スコープは最初に適用可能な認証構成を選択するために使用されます。その後、認証チェックが通常どおり実行されます。スコープ固有の認証を使用できますが、複数のスコープ間および/または標準のLSP / CSNP / PSNPとの認証の共有で十分と見なされます。
When the FS LSP ID Extended format is used, the set of LSPs generated by an IS may be quite large. It may be useful to identify those LSPs in the set that contain information of higher priority. Such LSPs will have the P bit set to 1 in the Scope field in the LSP header. Such LSPs SHOULD be flooded at a higher priority than LSPs with the P bit set to 0. This is a suggested behavior on the part of the originator of the LSP. When an LSP is purged, the original state of the P bit MUST be preserved.
FS LSP ID拡張フォーマットを使用すると、ISによって生成されるLSPのセットが非常に大きくなる可能性があります。より高い優先度の情報を含むセット内のLSPを識別すると役立つ場合があります。このようなLSPは、LSPヘッダーのScopeフィールドでPビットが1に設定されます。このようなLSPは、Pビットが0に設定されているLSPよりも高い優先度でフラッディングされる必要があります。これは、LSPの発信者側で推奨される動作です。 LSPが削除されるとき、Pビットの元の状態は保持されなければなりません（MUST）。
Introduction of new PDU types is incompatible with legacy implementations. Legacy implementations do not support the FS-specific Update process(es) and, therefore, flooding of the FS-LSPs throughout the defined scope is unreliable when not all routers in the defined scope support FS PDUs. Further, legacy implementations will likely treat the reception of an FS PDU as an error. Even when all routers in a given scope support FS PDUs, if not all routers in the flooding domain for a given scope support that scope, then flooding of the FS-LSPs may be compromised. When deploying a new flooding scope, correct operation therefore requires that both FS PDUs and the new scope be supported by all routers in the flooding domain of the new scope.
新しいPDUタイプの導入は、従来の実装と互換性がありません。レガシー実装はFS固有の更新プロセスをサポートしていないため、定義されたスコープ内のすべてのルーターがFS PDUをサポートしていない場合、定義されたスコープ全体でのFS-LSPのフラッディングは信頼できません。さらに、レガシー実装では、FS PDUの受信をエラーとして扱う可能性があります。特定のスコープ内のすべてのルーターがFS PDUをサポートしている場合でも、特定のスコープのフラッディングドメイン内のすべてのルーターがそのスコープをサポートしているわけではない場合、FS-LSPのフラッディングが危険にさらされる可能性があります。したがって、新しいフラッディングスコープを展開する場合、正しい操作には、FS PDUと新しいスコープの両方が、新しいスコープのフラッディングドメイン内のすべてのルーターでサポートされている必要があります。
The U bit in FS-PSNPs provides a means to suppress retransmissions of unsupported scopes. Routers that support FS PDUs SHOULD support the sending of PSNPs with the U bit equal to 1 when an FS-LSP is received with a scope that is unsupported. Routers that support FS PDUs SHOULD trigger management notifications when FS PDUs are received for unsupported scopes and when PSNPs with the U bit equal to 1 are received.
FS-PSNPのUビットは、サポートされていないスコープの再送信を抑制する手段を提供します。 FS PDUをサポートするルーターは、サポートされていないスコープでFS-LSPを受信したときに、Uビットが1のPSNPの送信をサポートする必要があります（SHOULD）。 FS PDUをサポートするルーターは、サポートされていないスコープのFS PDUを受信したとき、およびUビットが1のPSNPを受信したときに、管理通知をトリガーする必要があります（SHOULD）。
[RFC5306] defines protocol extensions in support of graceful restart of a routing instance. Synchronization of all supported FS-LSDBs is required in order for database synchronization to be complete. This involves the use of additional T2 timers. Receipt of a PSNP with the U bit equal to 1 will cause FS-LSDB synchronization with that neighbor to be considered complete for that scope. See [RFC5306] for further details.
[RFC5306]は、ルーティングインスタンスのグレースフルリスタートをサポートするプロトコル拡張を定義しています。データベースの同期を完了するには、サポートされているすべてのFS-LSDBの同期が必要です。これには、追加のT2タイマーの使用が含まれます。 Uビットが1のPSNPを受信すると、そのネイバーとのFS-LSDB同期は、そのスコープに対して完全であると見なされます。詳細については、[RFC5306]を参照してください。
In cases where FS-PDUs are associated with a non-zero instance, the use of Instance Identifier TLVs (IID-TLVs) in FS-PDUs follows the rules for use in LSPs, CSNPs, and PSNPs as defined in [RFC6822].
FS-PDUがゼロ以外のインスタンスに関連付けられている場合、FS-PDUでのインスタンス識別子TLV（IID-TLV）の使用は、[RFC6822]で定義されているLSP、CSNP、およびPSNPでの使用規則に従います。
This document defines four circuit scope flooding identifiers:
このドキュメントでは、4つの回線スコープフラッディング識別子を定義しています。
o Level 1 Circuit Scope (L1CS) -- this uses standard TLVs and standard sub-TLVs
o レベル1サーキットスコープ（L1CS）-標準のTLVと標準のサブTLVを使用します
o Level 2 Circuit Scope (L2CS) -- this uses standard TLVs and standard sub-TLVs
o レベル2サーキットスコープ（L2CS）-標準のTLVと標準のサブTLVを使用します
o Extended Level 1 Circuit Scope (E-L1CS) -- this uses extended TLVs and extended sub-TLVs
o 拡張レベル1サーキットスコープ（E-L1CS）-これは拡張TLVと拡張サブTLVを使用します
o Extended Level 2 Circuit Scope (E-L2CS) -- this uses extended TLVs and extended sub-TLVs
o 拡張レベル2サーキットスコープ（E-L2CS）-拡張TLVと拡張サブTLVを使用します
FS-LSPs with the Scope field set to one of these values contain information specific to the circuit on which they are flooded. When received, such FS-LSPs MUST NOT be flooded on any other circuit. The FS LSP ID Extended format is used in these PDUs. The FS-LSDB associated with circuit scope FS-LSPs consists of the set of FS-LSPs that both have matching circuit scopes and are transmitted (locally generated) or received on a specific circuit.
Scopeフィールドがこれらの値のいずれかに設定されたFS-LSPには、フラッディング先の回線に固有の情報が含まれています。このようなFS-LSPを受信した場合、他の回線でフラッディングしてはいけません。これらのPDUでは、FS LSP ID拡張形式が使用されます。サーキットスコープFS-LSPに関連付けられたFS-LSDBは、一致するサーキットスコープを持ち、特定のサーキットで送信（ローカルで生成）または受信されるFS-LSPのセットで構成されます。
The set of TLVs that may be included in such FS-LSPs is specific to the given use case and is outside the scope of this document.
このようなFS-LSPに含まれる可能性のあるTLVのセットは、特定のユースケースに固有であり、このドキュメントの範囲外です。
The need for additional space in the set of LSPs generated by a single IS has been articulated in [RFC5311]. When legacy interoperability is not a requirement, the use of FS-LSPs meets that need without requiring the assignment of alias system-ids to a single IS. Four flooding scopes are defined for this purpose:
単一のISによって生成されるLSPのセットに追加のスペースが必要であることは、[RFC5311]に明記されています。レガシー相互運用性が要件ではない場合、FS-LSPを使用すると、単一のISにエイリアスシステムIDを割り当てる必要なく、そのニーズを満たします。この目的で4つのフラッディングスコープが定義されています。
o Level 1 Flooding Scope (L1FS) -- this uses standard TLVs and standard sub-TLVs
o レベル1フラッディングスコープ（L1FS）-標準のTLVと標準のサブTLVを使用します
o Level 2 Flooding Scope (L2FS) -- this uses standard TLVs and standard sub-TLVs
o レベル2フラッディングスコープ（L2FS）-標準のTLVと標準のサブTLVを使用します
o Extended Level 1 Flooding Scope (E-L1FS) -- this uses extended TLVs and extended sub-TLVs
o 拡張レベル1フラッディングスコープ（E-L1FS）-これは、拡張TLVと拡張サブTLVを使用します
o Extended Level 2 Flooding Scope (E-L2FS) -- this uses extended TLVs and extended sub-TLVs
o 拡張レベル2フラッディングスコープ（E-L2FS）-これは拡張TLVと拡張サブTLVを使用します
L1FS and E-L1FS LSPs are flooded on all L1 circuits. L2FS and E-L2FS LSPs are flooded on all L2 circuits.
L1FSおよびE-L1FS LSPは、すべてのL1回線でフラッディングされます。 L2FSおよびE-L2FS LSPは、すべてのL2回線でフラッディングされます。
The FS LSP ID Extended format is used in these PDUs. This provides 64 K of additional LSPs that may be generated by a single system at each level.
これらのPDUでは、FS LSP ID拡張形式が使用されます。これにより、各レベルで単一のシステムによって生成される可能性のある64 Kの追加LSPが提供されます。
LxFS and E-LxFS LSPs are used by the level-specific Decision Process (defined in [IS-IS]) in the same manner as standard LSPs (i.e., as additional information sourced by the same IS) subject to the following restrictions:
LxFSおよびE-LxFS LSPは、標準のLSPと同じように（[IS-IS]で定義されている）レベル固有の決定プロセスによって使用されます（つまり、同じISから供給される追加情報として）。
o A valid version of standard LSP #0 from the same IS at the corresponding level MUST be present in the LSDB in order for the LxFS/E-LxFS set to be usable.
o LxFS / E-LxFSセットを使用するには、対応するレベルの同じISの標準LSP＃0の有効なバージョンがLSDBに存在している必要があります。
o Information in an LxFS of E-LxFS LSP (e.g., IS-Neighbor information) that supports using the originating IS as a transit node MUST NOT be used when the Overload bit is set in the corresponding standard LSP #0.
o E-LxFS LSPのLxFS内の情報（IS-Neighbor情報など）は、対応する標準LSP＃0で過負荷ビットが設定されている場合は、発信ノードのISをトランジットノードとして使用することをサポートする必要があります。
o TLVs that are restricted to standard LSP #0 MUST NOT appear in LxFS LSPs.
o 標準LSP＃0に制限されているTLVは、LxFS LSPに現れてはなりません（MUST NOT）。
There are no further restrictions as to what TLVs may be advertised in FS-LSPs.
FS-LSPでアドバタイズできるTLVについては、それ以上の制限はありません。
Existing support for flooding information throughout a domain (i.e., to L1 routers in all areas as well as to routers in the Level 2 subdomain) requires the use of leaking procedures between levels. For further details, see [RFC4971]. This is sufficient when the data being flooded throughout the domain consists of individual TLVs. If it is desired to retain the identity of the originating IS for the complete contents of a PDU, then support for flooding the unchanged PDU is desirable. This document, therefore, defines two flooding scopes in support of domain flooding. FS-LSPs with this scope MUST be flooded on all circuits regardless of what level(s) is supported on that circuit.
ドメイン全体（つまり、すべてのエリアのL1ルーターおよびレベル2サブドメインのルーター）に情報をフラッディングするための既存のサポートでは、レベル間のリーク手順を使用する必要があります。詳細については、[RFC4971]を参照してください。ドメイン全体にフラッディングされるデータが個々のTLVで構成される場合、これで十分です。 PDUの完全なコンテンツに対して発信元のISのIDを保持することが望ましい場合は、変更されていないPDUのフラッディングのサポートが望ましいです。したがって、このドキュメントでは、ドメインフラッディングをサポートする2つのフラッディングスコープを定義しています。このスコープを持つFS-LSPは、その回線でサポートされているレベルに関係なく、すべての回線でフラッディングする必要があります。
o Domain Flooding Scope (DFS) -- this uses standard TLVs and standard sub-TLVs
o ドメインフラッディングスコープ（DFS）-標準のTLVと標準のサブTLVを使用します
o Extended Domain Flooding Scope (E-DFS) -- this uses extended TLVs and extended sub-TLVs
o 拡張ドメインフラッディングスコープ（E-DFS）-拡張TLVと拡張サブTLVを使用します
The FS LSP ID Extended format is used in these PDUs.
これらのPDUでは、FS LSP ID拡張形式が使用されます。
Use of information in FS-LSPs for a given scope depends on determining the reachability to the IS originating the FS-LSP. This presents challenges for FS-LSPs with domain scopes because no single IS has the full view of the topology across all areas. It is, therefore, necessary for the originator of domain scope DSFS and E-DSFS LSPs to advertise an identifier that will allow an IS who receives such an FS-LSP to determine whether the source of the FS-LSP is currently reachable. The identifier required depends on what "address-families" are being advertised.
特定のスコープのFS-LSPでの情報の使用は、FS-LSPを発信するISへの到達可能性を決定することに依存します。これは、ドメインスコープを持つFS-LSPに課題を提示します。これは、単一のISがすべての領域にわたるトポロジの完全なビューを持つことができないためです。したがって、ドメインスコープDSFSおよびE-DSFS LSPの発信者は、そのようなFS-LSPを受信したISがFS-LSPのソースに現在到達可能かどうかを判断できるようにする識別子を通知する必要があります。必要な識別子は、アドバタイズされている「アドレスファミリ」によって異なります。
When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or IPv6, then FS-LSP #0 with domain scope MUST include at least one of the following TLVs:
IS-ISがIPv4やIPv6のレイヤ3ルーティングをサポートするように展開されている場合、ドメインスコープを持つFS-LSP＃0には、次のTLVの少なくとも1つが含まれている必要があります。
o IPv4 Traffic Engineering Router ID (TLV 134)
o IPv4トラフィックエンジニアリングルーターID（TLV 134）
o IPv6 Traffic Engineering Router ID (TLV 140)
o IPv6トラフィックエンジニアリングルーターID（TLV 140）
When IS-IS is deployed in support of Layer 2 routing, current standards (e.g., [RFC6325]) only support a single area. Therefore, domain scope is not yet applicable. When the Layer 2 standards are updated to include multi-area support, the identifiers that can be used to support inter-area reachability will be defined -- at which point the use of domain scope for Layer 2 can be fully defined.
IS-ISがレイヤー2ルーティングをサポートするように展開されている場合、現在の標準（[RFC6325]など）は単一のエリアのみをサポートします。したがって、ドメインスコープはまだ適用されていません。レイヤー2標準が更新されてマルチエリアサポートが含まれるようになると、エリア間の到達可能性をサポートするために使用できる識別子が定義されます。この時点で、レイヤー2のドメインスコープの使用を完全に定義できます。
Announcements of support for flooding scope may be useful in validating that full support has been deployed and/or in isolating the reasons for incomplete flooding of FS-LSPs for a given scope.
フラッディングスコープのサポートのアナウンスは、フルサポートが展開されていることを検証したり、特定のスコープのFS-LSPの不完全なフラッディングの理由を特定したりするのに役立ちます。
ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To do so, a new TLV is defined.
FS-PDUをサポートするISは、IIH PDUでサポートされるスコープを発表してもよい（MAY）。そのために、新しいTLVが定義されます。
Scope Flooding Support
Type: 243
Length: 1 - 127
Value
No. of octets
+----------------------+
|R| Supported Scope | 1
+----------------------+
: :
+----------------------+
|R| Supported Scope | 1
+----------------------+
A list of the circuit scopes supported on this circuit and other non-circuit-flooding scopes supported.
この回線でサポートされている回線スコープと、サポートされているその他の非回線フラッディングスコープのリスト。
R bit MUST be 0 and is ignored on receipt.
Rビットは0でなければならず、受信時に無視されます。
In a Point-to-Point IIH, L1, L2, domain, and all circuit scopes MAY be advertised.
ポイントツーポイントIIHでは、L1、L2、ドメイン、およびすべての回線スコープがアドバタイズされる場合があります。
In Level 1 LAN IIHs, L1, domain, and L1 Circuit Scopes MAY be advertised. L2 Scopes and L2 Circuit Scopes MUST NOT be advertised.
レベル1のLAN IIHでは、L1、ドメイン、およびL1サーキットスコープを通知できます（MAY）。 L2スコープとL2回路スコープはアドバタイズしてはなりません。
In Level 2 LAN IIHs, L2, domain, and L2 Circuit Scopes MAY be advertised. L1 Scopes and L1 Circuit Scopes MUST NOT be advertised.
レベル2のLAN IIHでは、L2、ドメイン、およびL2サーキットスコープを通知できます（MAY）。 L1スコープとL1回路スコープはアドバタイズしてはなりません。
Information in this TLV MUST NOT be considered in adjacency formation.
このTLVの情報は、隣接関係の形成で考慮してはなりません。
Whether information in this TLV is used to determine when FS-LSPs associated with a locally supported scope are flooded is an implementation choice.
このTLVの情報を使用して、ローカルでサポートされているスコープに関連付けられているFS-LSPがフラッディングするタイミングを判断するかどうかは、実装の選択です。
This document includes the definition of three new PDU types that are reflected in the "IS-IS PDU Registry".
このドキュメントには、「IS-IS PDUレジストリ」に反映されている3つの新しいPDUタイプの定義が含まれています。
Value Description
---- ---------------------
10 FS-LSP
11 FS-CSNP
12 FS-PSNP
A new IANA registry has been created to control the assignment of scope identifiers in FS-PDUs. The registration procedure is "Expert Review" as defined in [RFC5226]. The registry name is "LSP Flooding Scope Identifier Registry". A scope identifier is a number from 1-127, inclusive. Values 1 - 63 are reserved for PDUs that use standard TLVs and standard sub-TLVs. Values 64 - 127 are reserved for PDUs that use extended TLVs and extended sub-TLVs. The list of Hello PDUs in which support for a given scope MAY be announced (using Scope Flooding Support TLV) is specified for each defined scope.
FS-PDU内のスコープ識別子の割り当てを制御するために、新しいIANAレジストリが作成されました。登録手順は、[RFC5226]で定義されている「エキスパートレビュー」です。レジストリ名は「LSP Flooding Scope Identifier Registry」です。スコープ識別子は、1〜127の数値です。値1〜63は、標準TLVと標準サブTLVを使用するPDU用に予約されています。値64〜127は、拡張TLVと拡張サブTLVを使用するPDU用に予約されています。特定のスコープのサポートが（スコープフラッディングサポートTLVを使用して）通知される可能性があるHello PDUのリストは、定義されたスコープごとに指定されます。
The following scope identifiers are defined by this document.
このドキュメントでは、次のスコープ識別子が定義されています。
FS LSP ID Format/ IIH Announce
Value Description TLV Format P2P L1LAN L2LAN
----- ------------------------------ ----------------- ---------------
1 Level 1 Circuit Flooding Scope Extended/Standard Y Y N
2 Level 2 Circuit Flooding Scope Extended/Standard Y N Y
3 Level 1 Flooding Scope Extended/Standard Y Y N
4 Level 2 Flooding Scope Extended/Standard Y N Y
5 Domain Flooding Scope Extended/Standard Y Y Y
(6-63)Unassigned
64 Level 1 Circuit Flooding Scope Extended/Extended Y Y N 65 Level 2 Circuit Flooding Scope Extended/Extended Y N Y 66 Level 1 Flooding Scope Extended/Extended Y Y N 67 Level 2 Flooding Scope Extended/Extended Y N Y 68 Domain Flooding Scope Extended/Extended Y Y Y (69-127) Unassigned
64レベル1のフラッディングスコープの拡張/拡張YYN 65レベル1のフラッディングスコープの拡張/拡張YYN 66レベル1のフラッディングスコープの拡張/拡張YYN 67レベル2のフラッディングスコープの拡張/拡張YNY 68ドメインのフラッディングスコープの拡張/拡張YYY（69-127 ）未割り当て
The definition of a new IS-IS TLV is reflected in the "IS-IS TLV Codepoints" registry:
新しいIS-IS TLVの定義は、「IS-IS TLVコードポイント」レジストリに反映されます。
Value Name IIH LSP SNP Purge
---- ------------ --- --- --- -----
243 Scope Flooding Support Y N N N
The IANA "IS-IS TLV Codepoints" registry has been extended to allow
definition of codepoints less than or equal to 65535. Codepoints
greater than 255 can only be used in PDUs designated to support
extended TLVs. This registry has also been updated to point to this
document as a reference (in addition to [RFC3563] and [RFC6233]).
Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and [RFC5310].
IS-ISのセキュリティ問題は、[IS-IS]、[RFC5304]、および[RFC5310]で対処されています。
The new PDUs introduced are subject to the same security issues associated with their standard LSP/CSNP/PSNP counterparts. To the extent that additional PDUs represent additional load for routers in the network, this increases the opportunity for denial-of-service attacks.
導入された新しいPDUは、標準のLSP / CSNP / PSNPに対応するものと同じセキュリティ問題の影響を受けます。追加のPDUがネットワーク内のルーターの追加の負荷を表す限り、これにより、サービス拒否攻撃の機会が増加します。
The authors wish to thank Ayan Banerjee, Donald Eastlake, Hannes Gredler, and Mike Shand for their comments.
著者は、コメントを提供してくれたAyan Banerjee、Donald Eastlake、Hannes Gredler、およびMike Shandに感謝します。
[IEEEaq] IEEE, "Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE Std 802.1aq-2012, June 2012.
[IEEEaq] IEEE、「Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks-Amendment 20：Shortest Path Bridging」、IEEE Std 802.1aq-2012、2012年6月。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", 2002.
[IS-IS] ISO / IEC 10589：2002、Second Edition、 "Information technology-Telecommunications and information exchange between systems-Intermediate System to Intermediate System intradomain routing routeing information exchange protocol with used with with the protocol with with the connectionless-モードネットワークサービス（ISO 8473）」、2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007.
[RFC4971] Vasseur、JP。、Shen、N.、and R. Aggarwal、 "Intermediate System to Intermediate System（IS-IS）Extensions for Advertising Router Information"、RFC 4971、2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[RFC5306] Shand、M。、およびL. Ginsberg、「Restart Signaling for IS-IS」、RFC 5306、2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
[RFC6822] Previdi、S.、Ginsberg、L.、Shand、M.、Roy、A。、およびD. Ward、「IS-IS Multi-Instance」、RFC 6822、2012年12月。
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC 3563, July 2003.
[RFC3563] Zinin、A。、「IS-ISルーティングプロトコル開発に関するISOC / IETFとISO / IECジョイントテクニカルコミッティ1 /サブコミッティ6（JTC1 / SC6）の間の協力協定」、RFC 3563、2003年7月。
[RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, February 2009.
[RFC5311]マクファーソン、D。、ギンズバーグ、L。、プレビディ、S。、およびM.シャンド、「IS-ISのリンク状態PDU（LSP）スペースの簡易拡張」、RFC 5311、2009年2月。
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for Purges", RFC 6233, May 2011.
[RFC6233] Li、T。およびL. Ginsberg、「IS-IS Registry Extension for Purges」、RFC 6233、2011年5月。
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176] Eastlake、D.、Senevirathne、T.、Gwanwani、A.、Dutt、D。、およびA. Banerjee、「リンクの透過的な相互接続（TRILL）IS-ISの使用」、RFC 7176、2014年5月。
Authors' Addresses
著者のアドレス
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA
Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、カリフォルニア州95035米国
EMail: ginsberg@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144イタリア
EMail: sprevidi@cisco.com
Yi Yang Cisco Systems 7100-9 Kit Creek Road Research Triangle Park, NC 27709-4987 USA
Yi Yang Cisco Systems 7100-9 Kit Creek Road Research Triangle Park、NC 27709-4987 USA
EMail: yiya@cisco.com