rfc3373.txt

RFC 的详细文档！

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.

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.

1.  Terms

   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.

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:

   Down
      This is the initial point-to-point adjacency three-way state.  The
      system has not received any IIH packet containing the three-way
      handshake option on this point-to-point circuit.

   Initializing
      The system has received IIH packet containing the three-way
      handshake option from a neighbor but does not know whether the
      neighbor is receiving its IIH packet.

   Up
      The system knows that the neighbor is receiving its 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.

   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.



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


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

4.  Details

4.1  Syntax

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

   x Type - 0xF0 (decimal 240)
   x Length - total length of the value field (1 to 17 octets)
   x Value -
                                                       No. of Octets
                 +-----------------------------------+
                 | Adjacency Three-Way State         |      1
                 +-----------------------------------+
                 | Extended Local Circuit ID         |      4
                 +-----------------------------------+
                 | Neighbor System ID                |      ID Length
                 +-----------------------------------+
                 | Neighbor Extended Local Circuit ID|      4
                 +-----------------------------------+







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


   Adjacency Three-Way State
      The adjacency three-way state of the point-to-point adjacency. The
      following values are defined:

         0  - Up
         1 -  Initializing
         2 -  Down

   Extended Local Circuit ID
      Unique ID assigned to this circuit when it is created by this
      Intermediate system.

   Neighbor System ID
      System ID of neighbor Intermediate system if known.  The length of
      this field is equal to "ID Length" of IIH PDU described in section
      "Point-to-point IS to IS hello PDU" (section 9.7 of [1]).

   Neighbor Extended Local Circuit ID
      Extended Local Circuit ID of the other end of the point-to-point
      adjacency if known.

   Any system that supports this mechanism SHALL include this option in
   its Point-to-Point IIH packets.