rfc3373.txt

RFC 的详细文档！

   Any system that does not understand this option SHALL ignore it, and
   (of course) SHALL 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.

   Any system that is able to process this option SHALL follow the
   procedures below.

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

   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.






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


   Add a clause e) to the end of section "Receiving ISH PDUs by an
   intermediate system" (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 "Sending point-to-point IIH
   PDUs" (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 introduced later in the document) 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 "IIH PDU Processing" (section 8.2.4.2 of [1]):

      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 and contains invalid Adjacency Three-Way
      State, the PDU SHALL be discarded and no further action is taken.

      If the option with a valid Adjacency Three-Way State 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.





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


      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 SHALL 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.)

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

                     Adjacency Three-Way State Table


         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", no event is generated and
         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.





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


5.  Security Considerations

   This document raises no new security issues for IS-IS.

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

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

8.  Authors' Addresses

   Dave Katz
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089

   Phone: [phone]
   EMail:  [e-mail]


   Rajesh Saluja
   Tenet Technologies
   30/31, 100 Feet Road, Madiwala
   Bangalore - 560 068  INDIA

   Phone: [phone]
   EMail: [e-mail]










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


9.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Katz & Saluja                Informational                      [Page 9]