[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 RFC 3373

Network Working Group                                          Dave Katz
INTERNET DRAFT                                    Juniper Networks, Inc.
Expiration Date: August 2002                               Rajesh Saluja
                                                   Nortel Networks, Inc.
                                                           February 2002



        Three-Way Handshake for IS-IS Point-to-Point Adjacencies

                      draft-ietf-isis-3way-05.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) 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.




D. Katz, R. Saluja        Expires August 2002                   [Page 1]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002


1.0  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
   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, 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).

   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 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



D. Katz, R. Saluja        Expires August 2002                   [Page 2]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002


   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.

   The adjacency three-way state that is reported by this mechanism is
   not equal or equivalent to the adjacency state that is described in
   ISO 10589 [1]. If this mechanism is supported then an adjacency may
   have two states, its state as defined in ISO 10589[1], and its
   three-way state. For example according to ISO 10589 [1] receipt of an
   ISH will cause an adjacency to go to Initializing state; however
   receipt of an ISH will have no effect on the three-way state of an
   adjacency, which remains firmly Down until it receives an IIH from a
   neighbor that contains the three-way handshaking option.

   In addition, the neighbor's system ID and (newly-defined) extended
   circuit ID are reported in order to detect 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



D. Katz, R. Saluja        Expires August 2002                   [Page 3]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002


   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.


3.0  Details

3.1  Syntax

   A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is
   defined [4]:

          Type = 0xF0 (decimal 240)
          Length = 1 to 17 octets
          Value:
            Adjacency Three-Way 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 if known (four octets)

   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 supports this mechanism MUST include Adjacency
   Three-Way State field in this option. The other fields in this option
   should be included as explained below in section 3.2.




D. Katz, R. Saluja        Expires August 2002                   [Page 4]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002


   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.2 of [1]:

     Set the state to be reported in the Adjacency Three-Way State field
     of the Point-to-Point Three-Way Adjacency option to Down.

   Add a clause e) to the end of section 8.2.3 of [1]:

     The IS shall include the Point-to-Point Three-Way Adjacency option
     in the transmitted Point-to-Point IIH PDU. The current three-way
     state of the adjacency with its neighbor on the link (as defined in
     new section 8.2.4.1.1) shall be reported in the Adjacency Three-Way
     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 adjacency three-way 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:




D. Katz, R. Saluja        Expires August 2002                   [Page 5]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002


     A received Point-to-Point IIH PDU may or may not contain the
     Point-to-Point Three-Way Adjacency 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 Neighbor System ID contained therein does
     not match the local system's ID, or the Neighbor Extended Local
     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 a new adjacency but the three-way
        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 adjacency three-way state table below, based on the
        current adjacency three-way state and the received Adjacency
        Three-Way 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 August 2002                   [Page 6]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002



                                   Received Adjacency Three-Way State
                               Down           Initializing          Up
                         -------------------------------------------------
           Down          |  Initialize            Up                Down
                         |
     adj   Initializing  |  Initialize            Up                Up
     three               |
     -way  Up            |  Initialize            Accept            Accept
     state               |
                         |


        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 three-way 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.

   [4] Tony Przygienda, "Reserved TLV Codepoints in ISIS", Work in
       Progress, January 2002







D. Katz, R. Saluja        Expires August 2002                   [Page 7]


Internet Draft        draft-ietf-isis-3way-05.txt          February 2002


Acknowledgements

   The authors would like to thank Tony Li, Henk Smit, Naiming Shen,
   Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their
   contributions to this document.


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 August 2002                   [Page 8]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/