[要約] 要約: RFC 3786は、IS-ISリンクステートPDU(LSP)フラグメントの256の制限を超えて中間システム間(IS-IS)の数を拡張するための方法を提案しています。目的: このRFCの目的は、IS-ISプロトコルで使用されるLSPフラグメントの制限を拡張し、より大きなネットワーク環境での効率的な通信を可能にすることです。

Network Working Group                                        A. Hermelin
Request for Comments: 3786                                 Montilio Inc.
Category: Informational                                       S. Previdi
                                                                M. Shand
                                                           Cisco Systems
                                                                May 2004
        

Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit

中間システムの数を中間システム(IS-IS)リンク状態PDU(LSP)フラグメントに256制限を延長する

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004). All Rights Reserved.

著作権(c)The Internet Society(2004)。無断転載を禁じます。

Abstract

概要

This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers.

このドキュメントは、ISO/IEC 10589で説明されているように、システムが256リンク状態PDU(LSP)フラグメントを発信できるメカニズム、元の中間システム(IS-IS)ルーティングプロトコルに設定された制限です。メカニズムは、IPのみ、OSI-ONLY、およびデュアルルーターで使用できます。

Table of Contents

目次

   1.  Introduction .................................................  2
       1.1.  Keywords ...............................................  2
       1.2.  Definitions of Commonly Used Terms .....................  2
       1.3.  Operation Modes ........................................  3
       1.4.  Overview ...............................................  4
   2.  IS Alias ID TLV (IS-A) .......................................  5
   3.  Generating LSPs ..............................................  6
       3.1.  Both Operation Modes ...................................  6
       3.2.  Operation Mode 1 Additives .............................  8
   4.  Purging Extended LSP Fragments ............................... 10
   5.  Modifications to LSP handling in SPF ......................... 10
   6.  Forming Adjacencies .......................................... 11
   7.  Interoperating between extension-capable and non-capable ISs . 11
   8.  Security Considerations ...................................... 12
   9.  Acknowledgements ............................................. 12
      10. References ................................................... 12
   11. Authors' Addresses ........................................... 13
   12. Full Copyright Statement ..................................... 14
        
1. Introduction
1. はじめに

In the Intermediate System to Intermediate System (IS-IS) protocol, a system floods its link-state information in Link State PDU (LSP) Data Units, or LSPs for short. These logical LSPs can become quite large, therefore the protocol specifies a means of fragmenting this information into multiple LSP fragments. The number of fragments a system can generate is limited by ISO/IEC 10589 [ISIS-ISO] to 256 fragments, where each fragment's size is also limited. Hence, there is a limit on the amount of link-state information a system can generate.

中間システムから中間システム(IS-IS)プロトコルでは、システムはリンク状態PDU(LSP)データユニットのリンク状態情報、または略してLSPにあふれています。これらの論理LSPは非常に大きくなる可能性があるため、プロトコルはこの情報を複数のLSPフラグメントに断片化する手段を指定します。システムが生成できるフラグメントの数は、ISO/IEC 10589 [ISIS-ISO]によって制限され、各フラグメントのサイズも制限されています。したがって、システムが生成できるリンク状態情報の量には制限があります。

A number of factors can contribute to exceeding this limit:

多くの要因がこの制限を超えることに貢献することができます。

- Introduction of new TLVs and sub-TLVs to be included in LSPs. - The use of LSPs to propagate various types of information (such as traffic-engineering information). - The increasing number of destinations and AS topologies. - Finer granularity routing, and the ability to inject external routes into areas [DOMAIN-WIDE]. - Other emerging technologies, such as optical, IPv6, etc.

- LSPに含まれる新しいTLVとサブTLVの導入。 - さまざまな種類の情報(トラフィックエンジニアリング情報など)を伝播するためのLSPの使用。 - 宛先の増加とトポロジーとして。 - より細かい粒度ルーティング、および外部ルートをエリアに注入する機能[ドメイン全体]。 - 光学、IPv6などの他の新興技術。

This document describes mechanisms to relax the limit on the number of LSP fragments.

このドキュメントでは、LSPフラグメントの数の制限を緩和するメカニズムについて説明しています。

1.1. Keywords
1.1. キーワード

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 BCP 14, RFC 2119 [BCP14].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [BCP14]に記載されているように解釈される。

1.2. Definitions of Commonly Used Terms
1.2. 一般的に使用される用語の定義

This section provides definitions for terms that are used throughout the text.

このセクションでは、テキスト全体で使用される用語の定義を提供します。

Originating System A router physically running the IS-IS protocol. As this document describes methods allowing a single IS-IS process to advertise its LSPs as multiple "virtual" routers, the Originating System represents the single "physical" IS-IS process.

IS-ISプロトコルを物理的に実行するルーターの発信システム。このドキュメントでは、単一のIS-ISプロセスが複数の「仮想」ルーターとしてLSPを宣伝できるようにするメソッドを説明するため、発信元システムは単一の「物理」IS-ISプロセスを表します。

Normal system-id The system-id of an Originating System.

通常のシステム-ID原産地システムのシステムID。

Additional system-id An Additional system-id that is assigned by the network administrator. Each Additional system-id allows generation of 256 additional, or extended, LSP fragments. The Additional system-id, like the Normal system-id, must be unique throughout the routing domain.

追加のSystem-IDネットワーク管理者によって割り当てられる追加のシステムID。追加のSystem-IDそれぞれにより、256の追加、または拡張されたLSPフラグメントの生成が可能になります。追加のシステムIDは、通常のシステムIDと同様に、ルーティングドメイン全体で一意でなければなりません。

Virtual System The system, identified by an Additional system-id, advertised as originating the extended LSP fragments. These fragments specify the Additional system-id in their LSP IDs.

仮想システム追加のシステムIDによって識別されたシステムは、拡張されたLSPフラグメントを発信するものとして宣伝されています。これらのフラグメントは、LSP IDに追加のシステムIDを指定します。

Original LSP An LSP using the Normal system-id in its LSP ID.

LSP IDで通常のシステムIDを使用して、元のLSP an LSP。

Extended LSP An LSP using an Additional system-id in its LSP ID.

LSP IDに追加のシステムIDを使用してLSPを拡張しました。

LSP set Logical LSP. This term is used only to resolve the ambiguity between a logical LSP and an LSP fragment, both of which are sometimes termed "LSP".

LSP Set Logical LSP。この用語は、論理LSPとLSPフラグメントの間の曖昧さを解決するためにのみ使用されます。どちらも「LSP」と呼ばれることもあります。

Extended LSP set A group of LSP fragments using an Additional system-id, and originated by the Originating System.

拡張LSPは、追加のシステムIDを使用してLSPフラグメントのグループを設定し、発信システムによって発生しました。

Extension-capable IS An IS implementing the mechanisms described in this document.

拡張対応は、このドキュメントで説明されているメカニズムを実装するISです。

1.3. Operation Modes
1.3. 操作モード

Two administrative operation modes are provided:

2つの管理操作モードが提供されます。

- Operation Mode 1 provides behavior that allows implementations that don't support this extension, to correctly process the extended fragment information, without any modifications. This mode has some restrictions on what may be advertised in the extended LSP fragments. Namely, only leaf information may be advertised in the extended LSPs.

- 操作モード1は、この拡張機能をサポートしない実装を可能にする動作を提供し、変更なしで拡張フラグメント情報を正しく処理します。このモードには、拡張されたLSPフラグメントで宣伝される可能性のあるものにいくつかの制限があります。つまり、拡張されたLSPで葉の情報のみを宣伝できます。

- Operation Mode 2 extends the previous mode and relaxes its advertisement restrictions. Any link-state information may be advertised in the extended LSPs. However, it mandates a change to the way LSPs are considered during the SPF algorithm, in a way that is not compatible with previous implementations.

- 操作モード2は前のモードを拡張し、広告の制限をリラックスさせます。リンク状態情報は、拡張LSPで宣伝される場合があります。ただし、以前の実装と互換性がない方法で、SPFアルゴリズム中のLSPの検討方法に変更を義務付けています。

These modes are configured on a per-level and area basis. That is, all LSPs considered in the same SPF instance MUST use the same Mode. There is no restriction that an L1/L2 IS operates in the same mode, for both its L1 and L2 instances. It can use Mode 1 for its L1 LSPs, and Mode 2 for its L2 LSPs, or vice versa.

これらのモードは、レベルごととエリアベースで構成されています。つまり、同じSPFインスタンスで考慮されるすべてのLSPは、同じモードを使用する必要があります。L1/L2が同じモードで動作し、L1とL2の両方のインスタンスで動作するという制限はありません。L1 LSPにモード1、L2 LSPにモード2を使用するか、その逆も同様です。

Mode 1 has the only advantage of being backwards compatible with older implementations. It does have restrictions which are considered drawbacks. Therefore, routers should operate in Mode 1 only if backwards compatibility is desired. Otherwise, it is recommended to run in Mode 2.

モード1には、古い実装と逆方向に互換性があるという唯一の利点があります。欠点と見なされる制限があります。したがって、ルーターは、後方互換性が必要な場合にのみ、モード1で動作する必要があります。それ以外の場合は、モード2で実行することをお勧めします。

Routers MAY implement Operational Mode 2 without supporting running in Operational Mode 1. They will still interoperate correctly with routers that support both modes.

ルーターは、運用モード1での実行をサポートせずに運用モード2を実装できます。これらは、両方のモードをサポートするルーターと正しく相互運用します。

1.4. Overview
1.4. 概要

Using Additional system-ids assigned by the administrator, the Originating System can advertise the excess link-state information in extended LSPs under these Additional system-ids. It would do so as if other routers, or "Virtual Systems", were advertising this information. These extended LSPs will also have the specified limit on their LSP fragments; however, the Originating System may generate extended LSPs under numerous Virtual Systems.

管理者によって割り当てられた追加のシステムIDを使用して、発信元システムは、これらの追加のシステムIDの下で、拡張されたLSPの過剰なリンク状態情報を宣伝できます。他のルーター、または「仮想システム」がこの情報を宣伝しているかのようにそうします。これらの拡張LSPは、LSPフラグメントに指定された制限もあります。ただし、発信元システムは、多数の仮想システムの下で拡張されたLSPを生成する場合があります。

For Operation Mode 1, 0-cost adjacencies are advertised from the Originating System to its Virtual System(s). No adjacencies (other than back to the Originating System) are advertised in the extended LSPs. As a consequence, the Virtual Systems are 'stub', meaning they can only be reached through their Originating System. Therefore, older implementations do not need modifications in order to correctly process these extended LSPs.

操作モード1では、0コストの隣接が元のシステムから仮想システムに宣伝されます。拡張されたLSPで隣接する隣接は宣伝されていません。結果として、仮想システムは「スタブ」です。つまり、発信システムを介してのみ到達できることを意味します。したがって、これらの拡張されたLSPを正しく処理するために、古い実装では変更を必要としません。

For both modes, each LSP (set) created by a node will contain in its fragment-0 a new TLV (IS Alias ID TLV) that contains the Normal system-id and PN Number of the Original LSP created by the router. Extension-capable ISs can then use this information and store the original and extended LSPs as one logical LSP.

両方のモードについて、ノードによって作成された各LSP(セット)には、そのフラグメント-0に、ルーターによって作成された元のLSPの通常のシステムIDとPN番号が含まれる新しいTLV(ISエイリアスID TLV)が含まれます。拡張対応ISSは、この情報を使用して、元のLSPと拡張LSPを1つの論理LSPとして保存できます。

The only sections that deal only with Mode 1 additions are 3.2, 3.2.1, and 3.2.2. All other sections relate to both modes.

モード1の追加のみを扱う唯一のセクションは、3.2、3.2.1、および3.2.2です。他のすべてのセクションは、両方のモードに関連しています。

2. IS Alias ID TLV (IS-A)
2. エイリアスIDTLV(IS-A)

The proposed IS-A TLV allows extension-capable ISs to recognize all LSPs of an Originating System, and combine the original and extended LSPs for the purpose of SPF computation. It identifies the Normal system-id of the Originating System.

提案されているIS-A TLVは、拡張対応ISSが発信システムのすべてのLSPを認識し、SPF計算を目的として元のLSPと拡張LSPを組み合わせることを可能にします。発信システムの通常のシステムIDを識別します。

The proposed IS Alias ID TLV is type 24, and its format is as follows:

提案されているのはエイリアスID TLVがタイプ24であり、その形式は次のとおりです。

x CODE - 24.

Xコード-24。

x LENGTH - total length of the value field.

X長さ - 値フィールドの全長。

x VALUE -

X値 -

                            No. of Octets
      +-------------------+
      | Normal system-id  |      6
      +-------------------+
      | Pseudonode number |      1
      +-------------------+
      | Sub-TLVs length   |      1
      +-------------------+
      |                   |     0-247
      : Sub-TLVs          :
      :                   :
      |                   |
      +-------------------+
        

Normal system-id The Normal system-id of the LSP set, as described in section 1.2 of this document.

通常のシステムIDこのドキュメントのセクション1.2で説明されているように、LSPセットの通常のシステムID。

Pseudonode number The Pseudonode number of the LSP set. LSPs with the same Normal system-id and Pseudonode number are considered in SPF as one logical LSP, as described in section 5 of this document.

擬似ノード番号LSPセットの擬似ノード番号。このドキュメントのセクション5で説明されているように、同じ通常のシステムIDおよび擬似ノード数を持つLSPは、SPFで1つの論理LSPと見なされます。

Sub-TLVs length Total length of all sub-TLVs.

すべてのサブTLVのサブTLVの長さ。

Sub-TLVs A series of tuples with the following format:

次の形式を使用して、一連のタプルをサブTLVします。

                         No. of Octets
   +-------------------+
   | Sub-type          |      1
   +-------------------+
   | Length            |      1
   +-------------------+
   |                   |     0-245
   : Value             :
   :                   :
   |                   |
   +-------------------+
        

Sub-type Type of the sub-TLV

サブTLVのサブタイプタイプ

Length Total length of the value field

値フィールドの長さの全長

Value Type-specific TLV payload.

値タイプ固有のTLVペイロード。

For an explanation on sub-TLV handling, see [ISIS-TE].

サブTLV処理に関する説明については、[ISIS-TE]を参照してください。

Without sub-TLVs, this structure consumes 8 octets per LSP set. This TLV MUST be included in fragment 0 of every LSP set belonging to an Originating System running in either Mode 1 or Mode 2. Currently, there are no sub-TLVs defined.

サブTLVがなければ、この構造はLSPセットごとに8オクテットを消費します。このTLVは、モード1またはモード2のいずれかで実行されている元のシステムに属するすべてのLSPセットのフラグメント0に含める必要があります。現在、サブTLVは定義されていません。

For a complete list of used IS-IS TLV numbers, see [ISIS-CODES].

使用されているIS-IS TLV番号の完全なリストについては、[ISIS-Codes]を参照してください。

3. Generating LSPs
3. LSPの生成
3.1. Both Operation Modes
3.1. 両方の操作モード

Under both modes, the Originating System MUST include information binding the Original LSP and the Extended ones. It can do this since it is trivially an extension-capable IS. This is to ensure other extension-capable routers correctly process the extra information in their SPF calculation. This binding is advertised via a new IS Alias ID TLV, which is advertised in all fragment 0 of Original and Extended LSPs.

両方のモードの下で、元のモードには、元のLSPと拡張されたLSPをバインドする情報を含める必要があります。これは、これを実現することができます。これは、他の拡張可能なルーターがSPF計算の追加情報を正しく処理できるようにするためです。このバインディングは、新しいISエイリアスID TLVを介して宣伝されています。これは、元のLSPおよび拡張LSPのすべてのフラグメント0で宣伝されています。

   +---------------------------------------------+
   |  Originating System                         |
   |  system-id   = S                            |
   |  is-alias-id = S                            |
   +---------------------------------------------+
        
   +-------------------+     +-------------------+
   |  Virtual System   |     |  Virtual System   |
   |  system-id   = S' |     |  system-id   = S''|
   |  is-alias-id = S  |     |  is-alias-id = S  |
   +-------------------+     +-------------------+
        

Figure 1. Advertising binding between all of a system's LSPs (both modes). S' and S'' are configured as Additional system-ids.

図1.システムのすべてのLSP(両方のモード)間の広告バインディング。S 'およびS' 'は、追加のシステムIDとして構成されています。

When new extended LSP fragments are generated, these fragments should be generated as specified in ISO/IEC 10589 [ISIS-ISO]. Furthermore, a system SHOULD treat its extended LSPs the same as it treats its original LSPs, with the exceptions noted in the following sections. Specifically, creating, flooding, renewing, purging and all other operations are similar for both Original and Extended LSPs, unless stated otherwise. The Extended LSPs will use one of the Additional system-ids configured for the router, in their LSP ID.

新しい拡張LSPフラグメントが生成される場合、これらのフラグメントは、ISO/IEC 10589 [ISIS-ISO]で指定されているように生成する必要があります。さらに、システムは、拡張されたLSPを元のLSPを扱うのと同じように扱う必要があります。具体的には、特に明記しない限り、作成、洪水、更新、パージ、およびその他のすべての操作は、元のLSPと拡張LSPの両方で類似しています。拡張されたLSPは、LSP IDでルーター用に構成された追加のシステムIDの1つを使用します。

Extended LSPs fragment zero should be regarded in the same special manner as specified in ISO/IEC 10589 for LSPs with number zero, and should include the same type of extra information as specified in ISO/IEC 10589 and RFC 1195 [ISIS-IP]. So, for example, when a system reissues its LSP fragment zero due to an area address change, it should reissue all extended LSPs fragment zero as well.

拡張されたLSPSフラグメントゼロは、数値ゼロのLSPについてISO/IEC 10589で指定されたのと同じ特別な方法で見なす必要があり、ISO/IEC 10589およびRFC 1195 [ISIS-IP]で指定された同じタイプの追加情報を含める必要があります。したがって、たとえば、エリアアドレスの変更によりシステムがLSPフラグメントゼロを再発行する場合、すべての拡張LSPフラグメントゼロも再発行する必要があります。

An extended LSP fragment zero MUST be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. See section 5 for details.

ルーターのSPF計算がそのセットのそれらのフラグメントを考慮するために、拡張されたLSPセットごとに拡張されたLSPフラグメントゼロを生成する必要があります。詳細については、セクション5を参照してください。

3.1.1. The Attached Bits
3.1.1. 取り付けられたビット

The Attached (ATT) bits SHOULD be set to zero for all four metric types, on all Extended LSPs. This is due to the following: if a Virtual System is reachable, so is its Originating System. It is preferable, then, that an L1 IS chooses the Originating System and not the Virtual System as its nearest L2 exit point, as connectivity to the Virtual System has a higher probability of being lost (as a result of the extended LSP no longer being advertised). This could cause unnecessary computations on some implementations.

接続された(att)ビットは、すべての拡張されたLSPで、4つのメトリックタイプすべてでゼロに設定する必要があります。これは次のものです。仮想システムが到達可能な場合、その発信システムも到達可能です。したがって、仮想システムへの接続性は失われる可能性が高いため、L1が最寄りのL2出口ポイントとして仮想システムではなく、元のシステムを選択することが望ましいです(拡張されたLSPの結果としては、宣伝)。これにより、いくつかの実装で不必要な計算が発生する可能性があります。

3.1.2. The Partition Repair Bit
3.1.2. パーティションの修理ビット

The Partition Repair (P) bit SHOULD be set to zero on all extended LSPs. This is for the same reasons as for the Attached bits.

パーティション修理(P)ビットは、すべての拡張LSPでゼロに設定する必要があります。これは、添付のビットと同じ理由です。

3.1.3. ES Neighbors TLV
3.1.3. ES Neighbors TLV

ISO/IEC 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES Neighbor TLV in L1 LSPs, with the system ID of the router. RFC 1195 [ISIS-IP] relieves IP-only routers of this requirement. However, for routers that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI-capable), then in an extended LSP, the ESN TLV should include the relevant Additional system-id. Furthermore, OSI-capable routers should accept packets destined for this Additional system-id.

ISO/IEC 10589 [ISIS-ISO]セクション7.3.7は、ルーターのシステムIDを使用して、L1 LSPにES隣接TLVを挿入することを指定します。RFC 1195 [ISIS-IP]は、この要件のIPのみのルーターを解放します。ただし、このESN TLVをL1 LSP(IPのみまたはOSI対応)に挿入するルーターの場合、拡張されたLSPでは、ESN TLVに関連する追加のシステムIDを含める必要があります。さらに、OSI対応のルーターは、この追加のシステムIDに任命されたパケットを受け入れる必要があります。

3.1.4. Overload Bit
3.1.4. 過負荷ビット

The overload bit should be set consistently across all LSPs, original and extended, belonging to an Originating System, and should reflect the Originating System's overload state.

過負荷ビットは、すべてのLSPで一貫して設定し、元のシステムに属し、元のシステムに属し、発信元システムの過負荷状態を反映する必要があります。

3.1.5. Other Fields and TLVs
3.1.5. 他のフィールドとTLV

Other fields and TLVs not mentioned above remain the same, both for original and extended LSPs.

上記の他のフィールドとTLVは、元のLSPと拡張LSPの両方で同じままです。

3.2. Operation Mode 1 Additions
3.2. 操作モード1追加

The following additions apply only to routers generating LSPs in Mode 1. Routers, which are configured to operate in Operation Mode 2, SHOULD NOT apply these additions to their advertisements.

次の追加は、モード1でLSPを生成するルーターにのみ適用されます。これは、動作モード2で動作するように構成されているルーターで、これらの追加を広告に適用しないでください。

Under Operation Mode 1, adjacencies from the Originating System to its Virtual Systems are advertised using the standard neighbor TLVs. The metric for these connections MUST be zero, since the cost of reaching a Virtual System is the same as the cost of reaching its Originating System.

操作モード1では、発信元システムから仮想システムへの隣接は、標準の隣接TLVを使用して宣伝されています。仮想システムに到達するコストは、その発信システムに到達するコストと同じであるため、これらの接続のメトリックはゼロでなければなりません。

To older implementations, Virtual Systems would appear reachable only through their Originating System, hence loss of connectivity to the Originating System means loss of connectivity to all of its information, including that advertised in its extended LSPs. Furthermore, the cost of reaching information advertised in non-extended LSPs is the same as the cost of reaching information advertised in the new extended LSPs, with an additional hop.

古い実装では、仮想システムはその発信元システムを通じてのみ到達可能に見えるため、拡張されたLSPで宣伝されているものを含む、すべての情報への接続性が失われることを意味します。さらに、拡張されていないLSPで宣伝されている情報に到達するコストは、追加のホップを使用して、新しい拡張LSPで宣伝されている情報に到達するコストと同じです。

   +---------------------------------------------+
   |         Originating System                  |
   |         system-id = S                       |
   |         is-alias-id = S                     |
   +---------------------------------------------+
          |    /\                    |    /\
   cost=0 |    |cost=max-1    cost=0 |    |cost=max-1
          |    |                     |    |
          \/   |                     \/   |
   +-------------------+     +-------------------+
   |  Virtual System   |     |  Virtual System   |
   |  system-id   = S' |     |  system-id   = S''|
   |  is-alias-id = S  |     |  is-alias-id = S  |
   +-------------------+     +-------------------+
        

Figure 2. Advertising connections to Virtual Systems under Operation Mode 1. S' and S'' are configured as Additional system-ids.

図2.操作モード1の下での仮想システムへの広告接続1。S 'およびS' 'は、追加のシステムIDとして構成されています。

Under Operation Mode 1, only "leaf" information, i.e., information that serves only as leaves in a shortest path tree, can be advertised in extended LSPs.

操作モード1では、「葉」情報のみ、つまり最短のパスツリーの葉としてのみ機能する情報は、拡張LSPで宣伝できます。

When an Extended LSP belonging to Additional system-id S' is first created, the Original LSP MUST specify S' as a neighbor, with metric set to zero. This is in order to consider the cost of reaching the Virtual System S' the same as the cost of reaching its Originating System. Furthermore, the Extended LSP MUST specify the Normal system-id as a neighbor. The metric SHOULD be set to MaxLinkMetric - 1 (this is only for uniformity purpose, any metric greater than zero is acceptable). This in order to satisfy the two-way connectivity check on other routers. Where relevant, this adjacency SHOULD be considered as point-to-point.

追加のシステムID sに属する拡張LSPが最初に作成された場合、元のLSPはs 'を隣接として指定する必要があり、メトリックはゼロに設定されています。これは、仮想システムに到達するコストを検討するためであり、発信システムに到達するコストと同じです。さらに、拡張されたLSPは、通常のシステムIDを隣接として指定する必要があります。メトリックはmaxlinkmetric -1に設定する必要があります(これは均一な目的のみであり、ゼロより大きいメトリックは許容されます)。これは、他のルーターの双方向接続チェックを満たすためです。関連する場合、この隣接はポイントツーポイントと見なされるべきです。

Note, that the restriction specified in ISO/IEC 10589 section 7.2.5 holds: if an LSP Number zero of the Originating System is not present, none of that system's neighbor entries would be processed during SPF, hence none of its extended LSPs would be processed as well.

ISO/IEC 10589セクション7.2.5で指定された制限は保持されます。元のシステムのLSP番号ゼロが存在しない場合、そのシステムの近隣エントリはSPF中に処理されないため、拡張されたLSPはどれもありません。加工。

3.2.1. IS Neighbors TLV (Mode 1 Only)
3.2.1. 隣人tlvです(モード1のみ)

An Extended LSP must specify only the Originating System as a neighbor, with the metric set to (MaxLinkMetric - 1). Where relevant, this adjacency should be considered as point-to-point. Other neighbors MUST NOT be specified in an Extended LSP, because those other neighbors would only specify the Originating System and not the Virtual System, and hence would not satisfy the bi-directionality check in the SPF computation.

拡張されたLSPは、メトリックが(maxlinkmetric -1)に設定されている隣接としての元のシステムのみを指定する必要があります。関連する場合、この隣接はポイントツーポイントと見なされるべきです。他の隣接は、他の隣接者は仮想システムではなく発信元システムのみを指定し、したがってSPF計算での双方向性チェックを満たさないため、拡張されたLSPで指定してはなりません。

3.2.2. Originating System in the Overload State in (Mode 1 Only)
3.2.2. 過負荷状態の発信システム(モード1のみ)

If the Originating System is in the overload state, information in the extended LSPs will not be processed by other routers in their SPF computation. This is because in Mode 1, extended LSPs are reachable only through adjacencies from the Original LSP. If this LSP has set its OL bit, adjacencies will not be processed in the SPF computation.

元のシステムが過負荷状態にある場合、拡張されたLSPの情報は、SPF計算の他のルーターによって処理されません。これは、モード1では、拡張されたLSPが元のLSPからの隣接を通じてのみ到達できるためです。このLSPがOLビットを設定した場合、隣接はSPF計算で処理されません。

This side effect should be taken into consideration when operating in Mode 1.

この副作用は、モード1で動作するときに考慮する必要があります。

4. Purging Extended LSP Fragments
4. 拡張されたLSPフラグメントをパージします

ISO/IEC 10589 [ISIS-ISO] section 7.3.4.4 note 25 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 7.3.4.6 also recommends that an IS purge its empty LSPs to conserve resources. These recommendations hold for the extended LSP fragments as well. However, an extended LSP fragment zero should not be purged until all of the fragments in its set (i.e., belonging to a particular Additional system-id), are empty as well. This is to ensure implementations consider the fragments in their SPF computations, as specified in section 7.2.5.

ISO/IEC 10589 [ISIS-ISO]セクション7.3.4.4注25は、実装により、必要なフラグメントの最適な(最小)数に基づいて、LSPフラグメントの数が特定の制限内にあることを示唆しています。セクション7.3.4.6は、リソースを節約するために空のLSPをパージすることも推奨しています。これらの推奨事項は、拡張されたLSPフラグメントにも当てはまります。ただし、拡張されたLSPフラグメントゼロは、セット内のすべてのフラグメント(つまり、特定の追加のシステムIDに属する)が空になるまでパージしないでください。これは、セクション7.2.5で指定されているように、実装がSPF計算のフラグメントを考慮するようにするためです。

In Operational Mode 1, when all the extended LSP fragments of a particular Additional system-id S' have been purged, the Originating System SHOULD remove the neighbor information to S' from its original LSPs.

動作モード1では、特定の追加のシステムID s 'のすべての拡張されたLSPフラグメントがパージされている場合、元のLSPから隣接システムをs'に削除する必要があります。

5. Modifications to LSP handling in SPF
5. SPFでのLSP処理の変更

This section describes modifications to the way extension-capable ISs handle LSPs for the SPF computation.

このセクションでは、SPF計算の拡張対応ISSハンドルLSPの変更について説明します。

When considering LSPs of an extension-capable IS (identified by the inclusion of the IS Alias ID TLV), the original and extended LSPs are combined to form one large logical LSP. If the LSP belongs to an IS running Operational Mode 1, there might be adjacencies between the original and extended LSPs. These are trivially ignored (since when processing them the large logical LSP is already on PATHS), and does not complicate the SPF. Furthermore, this check should already be implemented (this scenario could occur on error, without this extension).

拡張対応ISのLSPを考慮すると(ISエイリアスID TLVを含めることで識別)、元のLSPと拡張LSPを組み合わせて1つの大きな論理LSPを形成します。LSPがANに属している場合、動作モード1を実行している場合、元のLSPと拡張LSPの間に隣接がある可能性があります。これらは簡単に無視されます(それらを処理すると、大きな論理LSPはすでにパスにあるため)。SPFを複雑にしません。さらに、このチェックは既に実装されている必要があります(このシナリオは、この拡張機能なしでエラー時に発生する可能性があります)。

If LSP fragment 0 of the Original LSP set is missing or its RemainingLifetime is zero, all of the LSPs generated by that Originating System (Extended as well) MUST NOT be considered in the SPF. That is, the large logical LSP is not considered in the SPF. The original LSP fragments are identified when the is-alias-id value is the same as the system-id of those LSPs. If an LSP fragment 0 of an extended LSP set is missing or its RemainingLifetime is zero, only that LSP set MUST NOT be considered in the SPF. These rules are present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs.

元のLSPセットのLSPフラグメント0が欠落している場合、またはその残りのLifetimeがゼロの場合、その発信システムによって生成されたすべてのLSP(拡張)をSPFで考慮してはなりません。つまり、大規模な論理LSPはSPFでは考慮されていません。元のLSPフラグメントは、IS-Alias-ID値がこれらのLSPのシステムIDと同じである場合に識別されます。拡張されたLSPセットのLSPフラグメント0が欠落している場合、またはその残りのLIFETIMEがゼロの場合、LSPセットのみをSPFで考慮してはなりません。これらのルールは、モード1およびモード2 LSPで一貫したSPFの結果を確保するために存在します。

Note, that the above behavior is consistent with how previous implementations will interpret Mode 1 LSPs.

上記の動作は、以前の実装がモード1 LSPをどのように解釈するかと一致していることに注意してください。

6. Forming Adjacencies
6. 隣接を形成します

It should be noted, that an IS MUST use the system-id of the LSP that will include a neighbor, when forming an adjacency with that neighbor. That is, if a neighbor is to be included in extended LSP S', then S' should be used as the system-id in IS Hellos [3] and IS-IS Hellos when forming an adjacency with that neighbor. This is regardless of the Operational Mode. Of course, in Mode 1 this means that only the Normal system-id will be used when sending hellos.

ISは、その隣人と隣接する際に隣人を含むLSPのシステムIDを使用する必要があることに注意する必要があります。つまり、隣人が拡張されたLSP s 'に含まれる場合、S'は、その隣人との隣接を形成するときにIS Hellos [3]およびIS-IS HellosのシステムIDとして使用する必要があります。これは、動作モードに関係なくです。もちろん、モード1では、これは、Hellosを送信するときに通常のシステムIDのみが使用されることを意味します。

7. Interoperating between extension-capable and non-extension-capable ISs.

7. 拡張対応と非拡張対応のISSとの相互協力。

In order to correctly advertise link-state information under Operation Mode 2, all ISs in an area must be extension-capable. However, it is possible to not upgrade every router in the network, if the extended information is not routing information, but rather data that is of use to only a subset of routers (e.g., optical switches using IS-IS could carry optical-specific information in extended LSPs)

操作モード2でリンク状態情報を正しく宣伝するためには、エリア内のすべてのISSが拡張機能である必要があります。ただし、拡張情報が情報をルーティングしているのではなく、ルーターのサブセットのみに使用されるデータである場合、ネットワーク内のすべてのルーターをアップグレードしないことが可能です(例えば、IS-ISを使用した光スイッチは光学固有のものを運ぶ可能性があります。拡張されたLSPの情報)

If a live network contains routers exceeding the 256 fragment limit, and for some reason the upgrade has to be done incrementally, it is possible to transition the network, using the following steps:

ライブネットワークに256のフラグメント制限を超えるルーターが含まれており、何らかの理由でアップグレードを段階的に実行する必要がある場合、次の手順を使用してネットワークを移行することができます。

- Upgrade the routers, one-by-one, to run this extension in Operation Mode 1. The other non-extension-capable routers will interoperate correctly.

- ルーターを1つずつアップグレードして、操作モード1でこの拡張機能を実行します。他の非拡張対応ルーターは正しく相互運用します。

- When all routers are extension-capable, configure them one-by-one to run in Operation Mode 2. All extension-capable routers interoperate correctly, regardless of what mode they are run in.

- すべてのルーターが拡張機能の場合は、動作モード2で実行するように1つずつ構成します。すべての拡張対応ルーターは、実行されるモードに関係なく正しく相互運用します。

Implementations SHOULD support a configuration parameter controlling the LSP origination behavior. The default value of this parameter SHOULD correspond to the behavior described in [ISIS-ISO], i.e., neither of the two modes described in this document should be enabled without explicit configuration when the router software is upgraded with this extension.

実装は、LSPオリジネーション動作を制御する構成パラメーターをサポートする必要があります。このパラメーターのデフォルト値は、[ISIS-ISO]で説明されている動作に対応する必要があります。つまり、このドキュメントで説明されている2つのモードのいずれも、この拡張機能でルーターソフトウェアをアップグレードする場合、明示的な構成なしで有効にする必要はありません。

8. Security Considerations
8. セキュリティに関する考慮事項

This document raises no new security issues for IS-IS.

このドキュメントは、IS-ISの新しいセキュリティの問題を提起しません。

9. Acknowledgments
9. 謝辞

The authors would like to thank Tony Li and Radia Perlman for helpful comments and suggestions on the subject.

著者は、Tony LiとRadia Perlmanに有益なコメントとこのテーマに関する提案に感謝したいと思います。

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

[ISIS-ISO] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition.

[ISIS-ISO]「Connectionless-Mode Network Service(ISO 8473)を提供するためのプロトコルと併用するためのドメイン内のシステム内領域内領域内のルーティング交換プロトコル」、ISO/IEC 10589:2002、第2版。

[ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.

[ISIS-IP] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS ISの使用」、RFC 1195、1990年12月。

[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, May 2004.

[ISIS-TE] Smit、H。およびT. Li、「交通工学のための中間システム(IS-IS)拡張(TE)」、RFC 3784、2004年5月。

[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

10.2. Informative References
10.2. 参考引用

[DOMAIN-WIDE] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.

[ドメイン全体] Li、T.、Przygienda、T。、およびH. Smit、「2レベルのIS-ISを備えたドメイン全体の接頭分布」、RFC 2966、2000年10月。

[ISIS-CODES] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.

[ISIS-Codes] Przygienda、T。、「中間システムから中間システムへの予約型、長さ、および値(TLV)コードポイント」、RFC 3359、2002年8月。

11. Authors' Addresses
11. 著者のアドレス

Amir Hermelin Montilio Inc. 1 Maskit St. POB 12253 Herzelia, 46733 ISRAEL

Amir Hermelin Montilio Inc. 1 Maskit St. Pob 12253 Herzelia、46733イスラエル

   Phone: +972 9 9511944
   Fax: +972 9 9542430
   EMail: amir@montilio.com
        

Stefano Previdi Cisco Systems, Inc. Via Del Serafico 200 00142 Roma Italy

Stefano Previdi Cisco Systems、Inc。

   Phone: +39 06 5164 4491
   EMail: sprevidi@cisco.com
        

Mike Shand Cisco Systems 250, Longwater Avenue, Green Park, Reading, RG2 6GB, UK

マイクシャンドシスコシステム250、ロングウォーターアベニュー、グリーンパーク、レディング、RG2 6GB、英国

   Phone: +44 20 8824 8690
   EMail: mshand@cisco.com
        
12. 完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

著作権(c)The Internet Society(2004)。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。