INTERNET-DRAFT Dave Katz Expiration: October 1996 cisco Systems, Inc. File: draft-katz-isis-3way-00.txt April 1996 Three-Way Handshake for IS-IS Point-to-Point Adjacencies Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The IS-IS routing protocol (ISO 10589) [1] does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake, in order to provide a solution to certain types of failures that may otherwise occur. It is fully interoperable with systems that do not support the extension. This extension has been implemented in cisco routers; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. 1.0 Introduction The IS-IS protocol provides only a two-way handshake when establishing adjacencies on point-to-point links. 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 D. Katz Expires October 1996 [Page 1] INTERNET-DRAFT IS-IS Three-Way Handshake April 13, 1996 (CSNP) to trigger database synchronization. Two 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 (fifteen minutes). A second, more serious failure mode was recently discovered. If the link fails in only one direction, the failure will only be detected by one of the systems. Normally, this is not a serious issue; 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 or more parallel links between the systems and one of them fails in one direction, SPF will still calculate paths between the two systems, and the system that cannot detect the failure will attempt to pass traffic down the failed link (in the direction that does not work). 2.0 Overview of Extension The intent is to provide a three-way handshake for point-to-point adjacency establishment in an backward compatible fashion. This is done by providing an optional mechanism that allows each system to report its adjacency 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 mechanism is essentially the same as the one defined in the Netware Link Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX traffic. The only real difference between this mechanism and the one used in NLSP is the location where the information is carried; NLSP used two of the reserved bits in the IIH header, whereas this solution adds a separate option to the IIH. 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 compatibility 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. It is also worth noting that the encoding used in the NLSP solution does not lend itself to backward compatibility. 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. D. Katz Expires October 1996 [Page 2] INTERNET-DRAFT IS-IS Three-Way Handshake April 13, 1996 3.0 Details 3.1 Syntax A new IS-IS Option type, "Point-to-Point Adjacency State", is defined: Type = 0xF0 (decimal 240) Length = 1 Value = adjacency state: 0 = Up 1 = Initializing 2 = Down 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 will ignore it, and (of course) will not include it in its own IIH packets. Any system that is able to process this option shall follow the procedures below. 3.2 Elements of Procedure The new procedure is added to the IS-IS point-to-point IIH state machine after the basic validity checks have been made, and before the existing state table is used. The existing procedures are only executed if the neighbor is in the proper state for the adjacency to come up. Add a subsection 8.2.3 e): The IS shall include the Point-to-Point Adjacency State field in the transmitted Point-to-Point IIH PDU, including the current state of the adjacency with its neighbor on the link. If no adjacency exists, the state shall be reported as Down. Add a section 8.2.4.1a, Three-Way Handshake: A received Point-to-Point IIH PDU may or may not contain the Point-to-Point Adjacency State option. If it does not, the link is assumed to be functional in both directions, and the procedures described in section 8.2.4.2 are followed. If the option is present, the state table below is used to determine the next state, based on the current adjacency state and D. Katz Expires October 1996 [Page 3] INTERNET-DRAFT IS-IS Three-Way Handshake April 13, 1996 the received state value from the option. If the new state is "Down", an adjacencyStateChange(Down) event is generated with the reason "Neighbor restarted" and the adjacency shall be deleted. If the new state is "Initializing", the adjacency state shall be set to "Initializing" and no further action is taken. If the new state is "Up", the processing described in section 8.2.4.2 shall be performed. Received State Down Initializing Up ------------------------------------------------- Down | Initializing Initializing Down | Adj Initializing | Initializing Up Up State | Up | Initializing Up Up 4.0 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. [2] Novell, Inc., "Netware Link Services Protocol Specification, Version 1.0", February 1994. [3] Callon, R., "OSI ISIS for IP and Dual Environment," RFC 1195, December 1990. Author's Address Dave Katz cisco Systems 170 W. Tasman Dr. San Jose, CA 95134-1706 USA Phone: +1 408 526 8284 Email: dkatz@cisco.com D. Katz Expires October 1996 [Page 4]