Network Working Group                                            D. Katz
Request for Comments: 3373                        Juniper Networks, Inc.
Category: Informational                                        R. Saluja
                                                      Tenet Technologies
                                                          September 2002
                        Three-Way Handshake for
          Intermediate System to Intermediate System (IS-IS)
                      Point-to-Point Adjacencies

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 (2002). All Rights Reserved.




The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.

IS-ISルーティングプロトコル(ISO 10589)は、ポイントツーポイントリンクのためのリンク層で信頼性の高いプロトコルを必要とします。ポイントツーポイントメディア上の隣接関係を確立するときその結果、3ウェイハンドシェイクを使用していません。本稿では、スリーウェイハンドシェイクのために提供するプロトコルに後方互換性拡張を定義します。これは、拡張をサポートしないシステムとの完全な相互運用が可能です。

Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.


This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors.


1. Terms

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.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈されます。

2. Introduction

The IS-IS protocol [1] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it. Once this occurs, each side then sends a Complete Sequence Number PDU (CSNP) to trigger database synchronization.

プロトコルでは、[1]のポイントツーポイントリンクを介してIS-IS、従ってポイント - 上の隣接関係を確立する場合にのみ、双方向ハンドシェークを提供する動作のためにISO 10589に記載されている特定の要件(セクション6.7.2)を想定していますポイントツーポイントのリンク。ポイントツーポイントリンクのためのこれらのサブネットワークの要件が満たされていない場合、プロトコルが正しく動作しません。標準で定義された基本的なメカニズムは、それぞれの側は、Helloパケットはそれから聞いている場合、相手側が到達可能であることを宣言していることです。これが発生すると、各側は、データベースの同期をトリガするために完全なシーケンス番号PDU(CSNP)を送信します。

Three failure modes are known. First, if the link goes down and then comes back up, or one of the systems restarts, and the CSNP packet is lost, and the network has a cut set of one through the link, the link state databases on either side of the link will not synchronize for a full LSP refresh period (up to eighteen hours).


A second, more serious failure, is that if the link fails in only one direction, the failure will only be detected by one of the systems. Normally only one of the two systems will announce the adjacency in its link state packets, and the SPF algorithm will thus ignore the link. However, if there are two parallel links between systems and one of them fails in one direction, SPF will still calculate paths between the two systems, and the system that does not notice the failure will attempt to pass traffic down the failed link (in the direction that does not work).


The third issue is that on some physical layers, the interconnectivity between endpoints can change without causing a link-layer-down condition. In this case, a system may receive packets that are actually destined for a different system (or a different link on the same system). The receiving system may end up thinking that it has an adjacency with the remote system when in fact the remote system is adjacent with a third system.


The solution proposed here ensures correct operation of the protocol over unreliable point-to-point links. As part of the solution to the three-way handshaking issue, a method is defined to remove the limitation of 255 point-to-point interfaces imposed by IS-IS [1]. This method is more robust than the ad hoc methods currently in use.

ここで提案された解決策は、信頼できない、ポイントツーポイントリンク上でプロトコルの正しい動作を保証します。スリーウェイハンドシェイクの問題に対する解決策の一環として、この方法は、IS-IS [1]によって課された255ポイントツーポイントインターフェイスの制限を除去するために定義されています。この方法は、現在使用されているアドホックな方法よりも堅牢です。

3. Overview of Extensions
3.1 Handshaking

The intent is to provide a three-way handshake for point-to-point adjacency establishment in a backward compatible fashion. This is done by providing an optional mechanism that allows each system to report its adjacency three-way state; this allows a system to only declare an adjacency to be up if it knows that the other system is receiving its IS-IS Hello (IIH) packets.


The adjacency three-way state can be one of the following types:


Down This is the initial point-to-point adjacency three-way state. The system has not received any IIH packet containing the three-way handshake option on this point-to-point circuit.


Initializing The system has received IIH packet containing the three-way handshake option from a neighbor but does not know whether the neighbor is receiving its IIH packet.


Up The system knows that the neighbor is receiving its IIH packets.


The adjacency three-way state that is reported by this mechanism is not equal or equivalent to the adjacency state that is described in ISO 10589 [1]. If this mechanism is supported then an adjacency may have two states, its state as defined in ISO 10589 [1], and its three-way state. For example according to ISO 10589 [1] receipt of an ISH will cause an adjacency to go to Initializing state; however receipt of an ISH will have no effect on the three-way state of an adjacency, which remains firmly Down until it receives an IIH from a neighbor that contains the three-way handshaking option.

このメカニズムによって報告される隣接三方状態は、ISO 10589に記載されている隣接状態に等しいかまたは等しくない[1]。このメカニズムがサポートされている場合、隣接は、ISO 10589で定義されている[1]二つの状態、その状態を有し、その三元状態よいです。例えば、ISO 10589 [1]に記載のISHの領収書は、隣接関係が状態を初期化するに行くことになります。しかし、ISHの領収書は、3ウェイハンドシェイクオプションが含まれている隣人からIIHを受信するまでしっかりと下に残っている隣接の3ウェイ状態には影響を与えません。

In addition, the neighbor's system ID and (newly-defined) extended circuit ID are reported in order to detect the case where the same stream is being received by multiple systems (only one of which can talk back).


The mechanism is quite similar to the one defined in the Netware Link Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX traffic. The difference between this mechanism and the one used in NLSP is the location where the information is carried (NLSP uses two of the reserved bits in the IIH header, whereas this solution adds a separate option to the IIH), and the presence of the neighbor's system ID and circuit ID. In theory, using the reserved header bits should be backward compatible, since systems are supposed to ignore them. However, it was felt that this was risky, as the use of untested mechanisms such as this have led to problems in the past in other protocols. New option codes, on the other hand, have been demonstrated to work properly, as the deployment of Integrated IS-IS for IP [3] has done exactly this.

機構は、Netwareのリンクサービスプロトコル(NLSP)[2]、IS-IS IPXトラフィックをルーティングするために使用されるの変異体で定義されたものと非常に類似しています。このメカニズムとNLSPで使用したものとの差分情報が搬送される場所である(この溶液は、IIHに別のオプションを追加し、一方NLSPは、IIHヘッダ内の予約ビットのうちの2つを使用して)、そして隣人の存在システムIDおよび回路ID。システムはそれらを無視するようになっているので、理論的には、予約済みヘッダ・ビットを使用して、下位互換性があるべきです。しかし、このようなテストされていないメカニズムの使用は他のプロトコルでは、過去の問題につながっているとして、これは、危険なだったと感じられました。 IPは、[3]まさにこれを行っているため、統合の展開は、IS-ISなどの新しいオプションコードは、他の一方で、正常に動作することが実証されています。

The new mechanism only comes into play when the remote system includes the new option in its IIH packet; if the option is not present, it is assumed that the system does not support the new mechanism, and so the old procedures are used.


3.2 More Than 256 Interfaces
3.2 256の以上のインターフェイス

The IS-IS specification has an implicit limit of 256 interfaces, as constrained by the eight bit Circuit ID field carried in various packets. Moderately clever implementors have realized that the only true constraint is that of 256 LAN interfaces, and for that matter only 256 LAN interfaces for which a system is the Designated IS. This is because the only place that the circuit ID is advertised in LSPs is in the pseudonode LSP ID.

様々なパケットで運ば8ビット回線IDフィールドによって制約として仕様は、256のインターフェイスの暗黙の限界を有しているが、です。適度に巧妙な実装では唯一の真の制約が256のLANインタフェースのことであり、そのことについては、システムが指定されているだけで256 LANインターフェイスがあることを実現しています。回路IDは、LSPの中に広告を出している唯一の場所は、擬似ノードLSPのIDであるためです。

Implementors have treated the point-to-point Circuit ID number space as being independent from that of the LAN interfaces, since these Circuit IDs appear only in IIH PDUs and are only used for detection of a change in identity at the other end of a link. More than 256 point-to-point interfaces have been supported by sending the same circuit ID on multiple interfaces. This reduces the robustness of the ID change detection algorithm, since it would then be possible to switch links between interfaces on a system without detecting the change.

これらの回路IDはIIHのPDUにのみ表示され、唯一のリンクの他端に同一の変化を検出するために使用されるので、実装は、LANインタフェースとは独立しているように、ポイント・ツー・ポイント回線ID番号空間を処理しています。 256以上のポイント・ツー・ポイント・インタフェースは、複数のインターフェイス上で同じ回路IDを送信することによってサポートされています。その後の変化を検出することなく、システム上のインターフェース間のリンクを切り替えることが可能であろうので、これは、ID変化検出アルゴリズムのロバスト性を低下させます。

Since the Circuit ID is an integral part of the new handshaking mechanism, a backward compatible mechanism for expanding the circuit ID number space is included in this specification.


4. Details
4.1 Syntax

A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is defined:


   x Type - 0xF0 (decimal 240)
   x Length - total length of the value field (1 to 17 octets)
   x Value -
                                                       No. of Octets
                 | Adjacency Three-Way State         |      1
                 | Extended Local Circuit ID         |      4
                 | Neighbor System ID                |      ID Length
                 | Neighbor Extended Local Circuit ID|      4

Adjacency Three-Way State The adjacency three-way state of the point-to-point adjacency. The following values are defined:


         0  - Up
         1 -  Initializing
         2 -  Down

Extended Local Circuit ID Unique ID assigned to this circuit when it is created by this Intermediate system.


Neighbor System ID System ID of neighbor Intermediate system if known. The length of this field is equal to "ID Length" of IIH PDU described in section "Point-to-point IS to IS hello PDU" (section 9.7 of [1]).

隣の中間システムのネイバーのシステムIDシステムIDが分かっている場合。このフィールドの長さは、セクションにIIH PDUの「IDの長さ」に等しい記述されている「ポイントツーポイントであるハローPDU IS」([1]のセクション9.7)。

Neighbor Extended Local Circuit ID Extended Local Circuit ID of the other end of the point-to-point adjacency if known.


Any system that supports this mechanism SHALL include this option in its Point-to-Point IIH packets.


Any system that does not understand this option SHALL ignore it, and (of course) SHALL NOT include it in its own IIH packets.


Any system that supports this mechanism MUST include Adjacency Three-Way State field in this option. The other fields in this option SHOULD be included as explained below in section 3.2.

このメカニズムをサポートする任意のシステムは、このオプションに隣接スリーウェイStateフィールドを含まなければなりません。 3.2節で以下に説明するように、このオプションの他のフィールドが含まれるべきです。

Any system that is able to process this option SHALL follow the procedures below.


4.2 Elements of Procedure

The new handshake procedure is added to the IS-IS point-to-point IIH state machine after the PDU acceptance tests have been performed.


Although the extended circuit ID is only used in the context of the three-way handshake, it is worth noting that it effectively protects against the unlikely event where a link is moved to another interface on a system that has the same local circuit ID, as the received PDUs will be ignored (via the checks defined below) and the existing adjacency will fail.


Add a clause e) to the end of section "Receiving ISH PDUs by an intermediate system" (section 8.2.2 of [1]):

セクション8.2.2(「中間システムによってISH PDUを受信」セクションの端部に節e)を追加[1])。

Set the state to be reported in the Adjacency Three-Way State field of the Point-to-Point Three-Way Adjacency option to Down.


Add a clause e) to the end of section "Sending point-to-point IIH PDUs" (section 8.2.3 of [1]):

[1]の(セクション8.2.3)、「ポイントツーポイントIIH PDUを送信」セクションの末尾に)句eを追加します。

The IS SHALL include the Point-to-Point Three-Way Adjacency option in the transmitted Point-to-Point IIH PDU. The current three-way state of the adjacency with its neighbor on the link (as defined in new section introduced later in the document) SHALL be reported in the Adjacency Three-Way State field. If no adjacency exists, the state SHALL be reported as Down.

ISは、送信されたポイントツーポイントIIH PDUにおけるポイントツーポイントスリーウェイ隣接オプションを含まなければなりません。 (文書の後半で導入された新しいセクション8.で定義される)リンク上でその隣人との隣接関係の現在の3ウェイ状態は隣接スリーウェイStateフィールドに報告しなければなりません。隣接関係が存在しない場合、状態はダウンとして報告しなければなりません。

The Extended Local Circuit ID field SHALL contain a value assigned by this IS when the circuit is created. This value SHALL be unique among all the circuits of this Intermediate System. The value is not necessarily related to that carried in the Local Circuit ID field of the IIH PDU.

拡張ローカル回線IDフィールドは、このことにより、割り当てられた値を含まなければならない回路が作成されたときです。この値は、この中間システムのすべての回路の中でユニークなものでなければなりません。値は必ずしもIIH PDUのローカル回線IDフィールドで運ばれたものに関連していません。

If the system ID and Extended Local Circuit ID of the neighboring system are known (in adjacency three-way state Initializing or Up), the neighbor's system ID SHALL be reported in the Neighbor System ID field, and the neighbor's Extended Local Circuit ID SHALL be reported in the Neighbor Extended Local Circuit ID field.


Add a section, "Three-Way Handshake", immediately prior to section "IIH PDU Processing" (section of [1]):

直前のセクションに、([1]のセクション8.2.4.2)「をIIH PDU処理」セクション8.、「スリーウェイハンドシェイク」を追加します。

A received Point-to-Point IIH PDU may or may not contain the Point-to-Point Three-Way Adjacency option. If it does not, the link is assumed to be functional in both directions, and the procedures described in section are followed.

受け取ったポイントツーポイントIIH PDUは、またはポイントツーポイントスリーウェイ隣接オプションを含んでも含まなくてもよいです。そうでない場合、リンクは両方向に機能することが想定され、セクション8.2.4.2に記載された手順に従います。

If the option is present and contains invalid Adjacency Three-Way State, the PDU SHALL be discarded and no further action is taken.


If the option with a valid Adjacency Three-Way State is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, SHALL be examined. If they are present, and the Neighbor System ID contained therein does not match the local system's ID, or the Neighbor Extended Local Circuit ID does not match the local system's extended circuit ID, the PDU SHALL be discarded and no further action is taken.


If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present, the procedures described in section are followed with following changes:


a) In section a and b, the action "Up" from state tables 5, 6, 7 and 8 may create a new adjacency but the three-way state of the adjacency SHALL be Down.

A)セクション8.2.4.2 a及びbは、状態テーブル5、6、7及び8からのアクション「アップ」は、新しい隣接関係を作成してもよいが、隣接の三元状態がダウンしなければなりません。

b) If the action taken from section a or b is "Up" or "Accept", the IS SHALL perform the action indicated by the new adjacency three-way state table below, based on the current adjacency three-way state and the received Adjacency Three-Way State value from the option. (Note that the procedure works properly if neither field is ever included. This provides backward compatibility to an earlier version of this option.)

b)のセクション8.2.4.2 AまたはBから取られた行動は、「アップ」である場合、または「同意する」、ISは、現在の隣接3ウェイ状態に基づいて、以下の新しい隣接関係の三方状態表で示されたアクションを実行しなければなりません。そしてオプションから受け取っ隣接スリーウェイステート値。 (どちらのフィールドは、これまで含まれている場合の手順が正しく動作していることに注意してください。これは、このオプションの以前のバージョンとの下位互換性を提供します。)

                          Received Adjacency Three-Way State
                            Down           Initializing          Up
         Down          |  Initialize            Up                Down
   adj   Initializing  |  Initialize            Up                Up
   three               |
   -way  Up            |  Initialize            Accept            Accept
   state               |

Adjacency Three-Way State Table


If the new action is "Down", an adjacencyStateChange(Down) event is generated with the reason "Neighbor restarted" and the adjacency SHALL be deleted.


If the new action is "Initialize", no event is generated and the adjacency three-way state SHALL be set to "Initializing".


If the new action is "Up", an adjacencyStateChange(Up) event is generated.


c) Skip section c and d.

C)セクション8.2.4.2 c及びdをスキップ。

d) If the new action is "Initialize", "Up" or "Accept", follow section e.


5. Security Considerations

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


6. References

[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:1992.

「コネクションレス型ネットワークサービスを提供するためのプロトコルと一緒に使用するための情報交換プロトコルをrouteingする中間システムへの中間システム(ISO 8473)」[1] ISO、ISO / IEC 10589:1992。

[2] "Netware Link Services Protocol Specification, Version 1.0", Novell, Inc., February 1994.

[2]の "NetWareリンクサービスプロトコル仕様、バージョン1.0" は、Novell、Inc.の、1994年2月。

[3] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.

[3] Callon、R.は、RFC 1195、1990年12月 "OSIは、IPおよびデュアル環境のためにIS-IS"。

7. Acknowledgements

The authors would like to thank Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their contributions to this document.


8. Authors' Addresses

Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089

デイブ・カッツジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089

Phone: (408) 745-2073 EMail:

電話:(408)745-2073 Eメール

Rajesh Saluja Tenet Technologies 30/31, 100 Feet Road, Madiwala Bangalore - 560 068 INDIA

ラジェッシュSalujaテネット・テクノロジーズ30/31、100フィートロード、Madiwalaバンガロール - 560 068 INDIA

Phone: +91 80 552 2215 EMail:

電話:+91 80 552 2215 Eメール

9. Full Copyright Statement

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


This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.






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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。