Network Working Group Dave Katz
INTERNET DRAFT Juniper Networks, Inc.
Expiration Date: November 2000 Rajesh Saluja
Nortel Networks, Inc.
May 2000
Three-Way Handshake for IS-IS Point-to-Point Adjacencies
draft-ietf-isis-3way-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The IS-IS routing protocol (ISO 10589) 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. 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.
D. Katz, R. Saluja Expires November 2000 [Page 1]
Internet Draft draft-ietf-isis-3way-02.txt May 2000
1.0 Introduction
The IS-IS protocol [1] 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
(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, 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
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).
In addition, SONET links bring a third issue, which is that when
SONET protection is used, 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.
As part of the solution to the three-way handshaking issue, a method
is defined for supporting more than 256 point-to-point interfaces
which is more robust than the ad hoc methods currently in use.
2.0 Overview of Extensions
2.1 Handshaking
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. In addition, the neighbor's system ID and
(newly-defined) extended circuit ID are reported in order to detect
D. Katz, R. Saluja Expires November 2000 [Page 2]
Internet Draft draft-ietf-isis-3way-02.txt May 2000
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. 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.
2.2 More Than 256 Interfaces
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.
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.
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.
D. Katz, R. Saluja Expires November 2000 [Page 3]
Internet Draft draft-ietf-isis-3way-02.txt May 2000
3.0 Details
3.1 Syntax
A new IS-IS Option type, "Point-to-Point Adjacency State", is
defined:
Type = 0xF0 (decimal 240)
Length = 5 to 17 octets
Value:
Adjacency State (one octet):
0 = Up
1 = Initializing
2 = Down
Extended Local Circuit ID (four octets)
Neighbor System ID if known (zero to eight octets)
Neighbor Extended Local Circuit ID (four octets, if Neighbor
System ID is present)
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 handshake procedure is added to the IS-IS point-to-point IIH
state machine after the PDU acceptance tests have been performed.
The existing procedures are only executed if the neighbor is in the
proper state for the adjacency to come up.
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 8.2.3:
The IS shall include the Point-to-Point Adjacency State option in
the transmitted Point-to-Point IIH PDU. The current state of the
D. Katz, R. Saluja Expires November 2000 [Page 4]
Internet Draft draft-ietf-isis-3way-02.txt May 2000
adjacency with its neighbor on the link (as defined in section
8.2.4.1.1) shall be reported in the Adjacency State field. If no
adjacency exists, the state shall be reported as Down.
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.
If the system ID and Extended Local Circuit ID of the neighboring
system are known (in 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 8.2.4.1.1, Three-Way Handshake, immediately prior to
section 8.2.4.2:
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 Neighbor System ID and Neighbor
Extended Local Circuit ID fields, if present, shall be examined.
If they are present, and the system ID contained therein does not
match the local system's ID, or the extended 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 8.2.4.2 are followed with following
changes:
a) In section 8.2.4.2 a and b, the action "Up" from state tables
5, 6, 7 and 8 may create new adjacency but the state of the
adjacency will be Down.
b) If the action taken from section 8.2.4.2 a or b is "Up" or
"Accept", the IS shall perform the action indicated by the
new state table below, based on the current adjacency state
and the received 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.)
D. Katz, R. Saluja Expires November 2000 [Page 5]
Internet Draft draft-ietf-isis-3way-02.txt May 2000
Received State
Down Initializing Up
-------------------------------------------------
Down | Initialize Up Down
|
Adj Initializing | Initialize Up Up
State |
Up | Initialize Accept Accept
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", the adjacency state shall be set to
"Initializing".
If the new action is "Up", an adjacencyStateChange(Up) event is
generated.
c) Skip section 8.2.4.2 c and d.
d) If the new action is "Initialize", "Up" or "Accept", follow section
8.2.4.2 e.
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] "Netware Link Services Protocol Specification, Version 1.0",
Novell, Inc., February 1994.
[3] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
December 1990.
Acknowledgements
The authors would like to thank Tony Li, Henk Smit, Naiming Shen, and
Dave Ward for their contributions to this document.
D. Katz, R. Saluja Expires November 2000 [Page 6]
Internet Draft draft-ietf-isis-3way-02.txt May 2000
Author's Addresses:
Dave Katz
Juniper Networks
385 Ravendale Drive
Mountain View, CA 94043 USA
Phone: +1 650 526 8073
Email: dkatz@juniper.net
Rajesh Saluja
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Phone: +1 978 288 7791
Email: rsaluja@nortelnetworks.com
D. Katz, R. Saluja Expires November 2000 [Page 7]
