[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02                                                      
Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                                                 Bell Labs
                                                              1 Nov 1998


             Maintaining more than 255 adjacencies in IS-IS
                  <draft-ietf-isis-wg-255adj-00.txt>


Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-ietf-isis-255adj-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.


Abstract
   This draft describes an optional implementation technique within
   IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
   within their clouds.  IS-IS is an interior gateway routing protocol
   developed originally by OSI and used with IP extensions as IGP.
   This draft describes how to effectively bypass the problem of 255
   circuits that IS-IS allows to maintain with minor violations of the
   specification that however does not prevent interoperability with
   existing implementations.


1. Introduction
   IS-IS reserves within its packets only one byte for a circuit ID
   and the specification requests it to be unique.  This ID is used in
   broadcast networks to identify a PNode.  They don't seem to serve any







Przygienda et al.              Expires 1 May 1999               [Page 1]


Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998


   particular purpose on p2p networks except for some checking in hellos
   and tie-breaking in removal of excess adjacencies.


2. More than 255 adjacencies on p2p links
   For all p2p links within an Intermediate System, the same circuit ID
   can be chosen safely to interact with other Intermediate Systems.
   Even when two such systems are brought up on two ends of the link
   and both pick the same value, IS-IS specification does not preclude
   such a configuration.  In case of multiple parallel links between the
   systems the only obvious problem is the impact on tie-breaking in
   case of excessive adjacencies.  However, such a configuration cannot
   generate forwarding loops.


3. More than 255 adjacencies on broadcast links
   More trickier a case is the one in which an intermediate system has
   to form adjacencies on a broadcast medium.  The decisive insight
   is the fact that unique circuit ID on a broadcast medium is only
   needed in the case where the given intermediate system is assuming
   the role of the DIS for the LAN. As long as the intermediate system
   has not elected itself DIS, it can use a non-unique circuit ID (1).
   Therefore, it is enough to change circuit ID in all the packets
   transmitted to a unique one as soon as DIS election ran and the
   system must become DIS. Such behavior is basically indistinguishable
   from a node crashing and coming immediately back with a different
   circuit ID than the one used before the crash.  Implementation
   experience shows that it is unwise to tear down the adjacencies
   before changing circuit IDs since this can lead to ``ripple''-down
   behavior in DIS property on the broadcast media in case of all
   routers having the same preference.


3.1. Modification of the Behavior on Broadcast Media
   The exact modification of the behavior for broadcast links is
   given here.  It is a modification of chapter 8.4.5 of the original
   specification that states:

___________________________________________
1. it is important to realize that circuit ID is not a part of
   tie-breaking rules on DIS election





Przygienda et al.              Expires 1 May 1999               [Page 2]


Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998


   When the broadcast circuit is enabled on an Intermediate system the
   IS shall perform the following actions.

    a) Commence sending IIH PDUs with the LAN ID field set to the
       concatenation of its own SystemID and its locally assigned one
       octet Local Circuit ID.

    b) ...  <omitted for clarity>

    c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
       acquire adjacencies as appropriate.  Do not run the Designated
       Intermediate System election process.

    d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or
       the Level 2 Designated Intermediate System election process,
       depending on the Intermediate system type.  This shall be run
       subsequently whenever an IIH PDU is received or transmitted as
       described in 8.4.3.  (For these purposes, the transmission of the
       system's own IIH PDU is equivalent to receiving it).  If there
       has been no change to the information on which the election is
       performed since the last time it was run, the previous result can
       be assumed.  The relevant information is

        1) the set of Intermediate system adjacency states,

        2) the set of Intermediate System priorities (including this
           system's) and

        3) the existence (or otherwise) of at least one "Up" End system
           (not including Manual Adjacencies) or Intermediate system
           adjacency on the circuit.


   An Intermediate system shall not declare itself to be a LAN
   Designated Intermediate system of any type until it has at least one
   "Up" End system (not including Manual Adjacencies) or Intermediate
   system adjacency on the circuit.  (This prevents an Intermediate
   System which has a defective receiver and is incapable of receiving
   any PDUs from erroneously electing itself LAN Designated Intermediate
   System.)  The LAN ID field in the LAN IIH PDUs transmitted by this
   system shall be set to the value of the LAN ID reported in the LAN
   IIH PDU (for the appropriate level) received from the system which
   this system considers to be the Designated Intermediate System.  This
   value shall also be passed to the Update Process, as the pseudonode


Przygienda et al.              Expires 1 May 1999               [Page 3]


Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998


   ID, to enable Link State PDUs to be issued for this system claiming
   connectivity to the pseudonode.  If this system, as a result of the
   Designated Intermediate System election process, considers itself to
   be designated Intermediate System, the LAN ID field shall be set to
   the concatenation of this system's own ID and the locally assigned
   one octet Local Circuit ID.


   One additional point has to be introduced:

    a) Commence sending IIH PDUs with the LAN ID field set to the
       concatenation of its own SystemID and a local non-zero, not
       necessarily unique circuit ID.

    b) ...  <omitted for clarity>

    c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
       acquire adjacencies as appropriate.  Do not run the Designated
       Intermediate System election process.

    d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and
       or the Level 2 Designated Intermediate System election process
       depending on the Intermediate system type.  If in any point in
       time the decision process determines the node to be DIS for this
       LAN:

        1) Commence sending IIH PDUs with the LAN ID field set to the
           concatenation of its own SystemID and a local unique circuit
           ID.

        2) go to step b.

       otherwise exhibit standard behavior.


4. Acknowledgments
   Some smart people probably thought about most of these things before
   and the p2p case may be documented in the best current practices for
   IS-IS in the Internet.


5. Security Consideration
   ISIS security applies to the work presented.  No specific security
   issues with the proposed solutions are known.


Przygienda et al.              Expires 1 May 1999               [Page 4]


Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998


6. Intellectual Property Considerations

   Lucent may seek patent or other intellectual property protection
   for some or all of the technologies disclosed in this document.  If
   any standards arising from this document are or become protected
   by one or more patents assigned to Lucent, Lucent intends to
   disclose those patents and license them under openly specified and
   non-discriminatory terms.


References

   [Cal90a] R. Callon.  OSI ISIS Intradomain Routing Protocol.
            INTERNET-RFC, Internet Engineering Task Force, February
            1990.

   [Cal90b] R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
            Environments.  INTERNET-RFC, Internet Engineering Task
            Force, December 1990.

   [ISO90]  ISO.  Information Technology - Telecommunications and
            Information Exchange between Systems - Intermediate System
            to Intermediate System Routing Exchange Protocol for
            Use in Conjunction with the Protocol for Providing the
            Connectionless-Mode Network Service.  ISO, 1990.

Authors' Addresses


Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
prz@dnrc.bell-labs.com












Przygienda et al.              Expires 1 May 1999               [Page 5]