Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies
RFC 3373

Document Type RFC - Informational (September 2002; No errata)
Obsoleted by RFC 5303
Authors Dave Katz  , Rajesh Saluja 
Last updated 2015-10-14
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
This information refers to IESG processing after the RFC was initially published:
IESG IESG state RFC 3373 (Informational)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Ross Callon
Send notices to (None)
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.

   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",
   document are to be interpreted as described in 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

Katz & Saluja                Informational                      [Page 1]
RFC 3373             Three-Way Handshake for IS-IS        September 2002

   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.

   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.

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.

Katz & Saluja                Informational                      [Page 2]
RFC 3373             Three-Way Handshake for IS-IS        September 2002

   The adjacency three-way state can be one of the following types:
Show full document text