Network Working Group D. Katz
Request for Comments: 3373 Juniper Networks, Inc.
Category: Informational R. Saluja
Three-Way Handshake for
Intermediate System to Intermediate System (IS-IS)
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 (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.
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.
The IS-IS protocol  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 .
This method is more robust than the ad hoc methods currently in use.
3. Overview of Extensions3.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