Internet DRAFT - draft-katz-isis-3way
draft-katz-isis-3way
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:27:47 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 04 Jun 1996 16:45:37 GMT
ETag: "361d9f-2162-31b46831"
Accept-Ranges: bytes
Content-Length: 8546
Connection: close
Content-Type: text/plain
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]
