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

Versions: 00 01 RFC 2973

     Internet Engineering Task Force                       R. Balay
     INTERNET DRAFT                                        Ericsson
     
                                                           D. Katz
                                                           Juniper Networks
     
                                                           J. Parker
                                                           Lucent Technology
     
                                                           July 7, 2000
     
                           IS-IS Mesh Groups
     
                 <draft-ietf-isis-wg-mesh-group-01.txt>
     
     1.  Status of this Memo
     
     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC 2026.
     
     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.
     
     
     
     Copyright Notice
     
     Copyright (C) The Internet Society (1997).  All Rights
     Reserved.
     
     
     
     
     
     
     
     
     
     
     
     
     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     2.  Abstract
     
     This document describes a mechanism to reduce redundant packet
     transmissions for the IS-IS Routing protocol, as described in
     ISO 10589 [1].  The described mechanism can be used to reduce
     the flooding of Link State PDUs (LSPs) in IS-IS topologies.
     The net effect is to engineer a flooding topology for LSPs
     which is a subset of the physical topology. This draft serves
     to document the existing behavior in deployed implementations.
     
     The draft describes behaviors that are backwards compatible
     with implementations that do not support this feature.
     
     This document is provided to the IETF working group on IS-IS.
     
     
     
     Table of Contents
     
     
        1.  Status of this Memo..................................   1
        2.  Abstract.............................................   2
        3.  Overview.............................................   2
        4.  Definitions of Mesh Groups...........................   4
        5.  Drawbacks of Mesh Groups.............................   6
        6.  Interoperation with Mesh Groups......................   7
        7.  Acknowledgments......................................   7
        8.  References...........................................   7
        9.  Security Considerations..............................   8
        10. Authors' Address.....................................   8
        11. Full Copyright Statement.............................   9
     
     
     
     
     3.  Overview
     
     In ATM or frame relay networks Intermediate Systems are
     inter-connected using virtual circuits (VCs) which are logical
     point-to-point links.  Some organizations attach multiple
     Intermediate Systems to form a full "mesh" topology, where
     every pair of Intermediate Systems are connected by a point-
     to-point link.  In such topologies, IS-IS protocol operation
     leads to redundant transmission of certain PDUs due to the
     flooding operation which is illustrated below.
     
     
     
     
     
     Expires January 2001                                  [Page 2]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     When an Intermediate System gets a new Link State Protocol
     Data Unit (LSP), it stores it, and prepares to flood it out
     every circuit except the source circuit.  This is done by
     setting SRM (Send Routing Message) bits held in the local copy
     of the LSP: there is an SRM for each circuit.
     
      +----------+                             +----------+
      |          | I12                     I21 |          |
      | System 1 | --------------------------- | System 2 |
      |          |                             |          |
      +----------+                             +----------+
       I13 |      \ I14                   I23 /     | I24
           |        \                       /       |
           |          \                   /         |
           |            \               /           |
           |              \           /             |
           |                \       /               |
           |                  \   /                 |
           |                    .                   |
           |                  /   \                 |
           |                /       \               |
           |              /           \             |
           |            /               \           |
           |          /                   \         |
           |        /                       \       |
       I31 |      / I32                   I41 \     | I42
      +----------+                             +----------+
      |          |                             |          |
      | System 3 | --------------------------- | System 4 |
      |          | I34                     I43 |          |
      +----------+                             +----------+
     
                 Figure 1. A four node full mesh topology
     
     When System1 regenerates an LSP, it will flood the LSP through
     the network by marking the SRM bits for circuits I12, I14, and
     I13. In due course, it will send out the LSP on each circuit.
     
     When System2 receives System1's LSP, it propagates the PDU
     according to section 7.2.14 of ISO 10589 [1]. It sets the SRM
     bits on circuits I23 and I24, to flood the LSP to System3 and
     System4.  However, these Intermediate Systems will get the LSP
     directly from System1.  In a full mesh of N Intermediate
     Systems, the standard protocol mechanism results in N-2 extra
     transmissions of each LSP, a waste of bandwidth and processing
     
     
     
     
     
     Expires January 2001                                  [Page 3]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     effort, with little gain in reliability.
     
     Mesh groups provide a mechanism to reduce the flooding of
     LSPs.
     
     
     
     
     4.  Definitions of Mesh Groups
     
     A mesh group is defined as a set of point-to-point circuits
     which provide full connectivity to a set of Intermediate
     Systems.  Each circuit has two new attributes:
     meshGroupEnabled, which is in state {meshInactive,
     meshBlocked, or meshSet} and an integer variable meshGroup,
     which is valid only if the value of meshGroupEnabled attribute
     is 'meshSet'. Circuits that are in state 'meshSet' and that
     have the same value of meshGroup are said to be in the same
     mesh group.
     
     LSPs are not flooded over circuits in 'meshBlocked' state, and
     an LSP received on a circuit C is not flooded out circuits
     that belong to C's mesh group.
     
     Section 7.3.15.1 clause e.1.ii) of ISO 10589 [1] is modified
     as follows:
     
     
     e.1.ii)
          if the meshGroupEnabled attribute is 'meshSet' for the
          circuit C, set the SRMflag for that LSP for all circuits
          other than C whose meshGroupEnabled attribute is
          'meshInactive'. Also set the SRMflag for all circuits in
          state 'meshSet' whose meshGroup attribute is not the same
          as C's.
     
          if the meshGroupEnabled attribute is 'meshInactive' for
          circuit C, set the SRMflag for that LSP for all circuits
          other than C whose meshGroupEnabled attribute is not
          'meshBlocked'.
     
     
     For robust database synchronization when using mesh groups,
     the Complete Sequence Number PDUs (CSNPs) are sent
     periodically on point-to-point links with a mesh group
     
     
     
     
     
     Expires January 2001                                  [Page 4]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     meshEnabled or meshBlocked. Section 7.3.15.3 clause b) of ISO
     10589 [1]  is modified as follows:
     
     
     b)   If C is a point-to-point circuit (including non-DA DED
          circuits and virtual links), then
     
     
     1)   If the circuit's attribute is 'meshSet' or 'meshBlocked',
          then for each valid level, the IS will send a complete
          set of CSNPs as described for a  Designated IS in section
          7.3.15.3 clause a).
     
     
     2)   CSNPs are transmitted only at initialization on point-
          to-point links whose state is 'meshInactive'.
     
     
     Use of mesh groups at an Intermediate System also modifies the
     behavior in transmission of generated LSPs. These LSPs are not
     required to be transmitted over circuits in state
     'meshBlocked' at system startup or when the LSP is
     regenerated. The second sentence of Section 7.3.12  is
     modified to read:
     
     
          "For all the circuits whose meshGroupEnabled attribute is
          not 'meshBlocked', the IS shall set the SRMflags for that
          Link State PDU to propagate it on all these circuits. The
          IS shall clear the SRMflags for circuits whose
          meshGroupEnabled attribute is 'meshBlocked'."
     
     
     Some of the transient transmission overhead can be reduced by
     having an Intermediate System not transmit its copies of the
     LSPs in database on a circuit start-up/restart if the circuit
     is 'meshBlocked'. The clause a) in the last part of Section
     7.3.17 of ISO 10589, which refers to the point-to-point
     circuits, is modified as follows:
     
     
     a)   set SRMflag for that circuit on all LSPs if the
          meshGroupEnabled attribute of the circuit is not
          'meshBlocked', and
     
     
     
     
     
     
     Expires January 2001                                  [Page 5]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     Numbering of mesh groups provides the ability to divide a
     large full mesh topology into a smaller group of full mesh
     sub-topologies (mesh groups). These mesh groups are connected
     by "transit" circuits which are 'meshInactive', while the
     remaining circuits between the mesh groups are configured as
     'meshBlocked' to reduce flooding redundancy. Use of numbering
     makes mesh groups more scalable.
     
     
     
     
     5.  Drawbacks of Mesh Groups
     
     The mesh group feature described in this document is a simple
     mechanism to reduce flooding of LSPs in some IS-IS topologies.
     It relies on a correct user configuration.  If a combination
     of user configuration and link failures result in a
     partitioned flooding topology, LSPs will not be sent in a
     timely fashion, which may lead to routing loops or black
     holes.
     
     The concept of using numbered mesh groups also suffers from
     the complexity and reliance on static configuration, making
     the topologies brittle. Loosing a transit link can partition
     LSP flooding in unpredictable ways, requiring the periodic
     flooding of CSNPs to synchronize databases. In large networks,
     CSNPs become large and also consume bandwidth.
     
     The authors are not aware of any networks that have deployed
     numbered mesh groups: instead, administrators set links to
     state 'meshBlocked' to prune the flooding topology (also known
     as "poor man's mesh groups").
     
     Some improvements to mesh groups which have been suggested
     include:
     
     
     a)   To negotiate or check the mesh group attributes during
          initialization of an adjacency to verify that the two
          ends of every circuit hold identical values of the mesh
          state and mesh number.
     
     
     b)   Dynamic election of active transit links so that a
          topology could recover from failure of transit circuits.
     
     
     
     
     
     Expires January 2001                                  [Page 6]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     c)   Reduce the flooding of CSNPs by sending them periodically
          on some meshGroup circuits rather than all circuits.
     
     
     d)   Reduce the size of PDUs required by flooding of CSNPs by
          sending CSNP summaries: checksums or sequence numbers.
     
     
     Any such improvements are outside the scope of this document,
     and may be the basis for future work.
     
     
     
     
     6.  Interoperation with Mesh Groups
     
     Since mesh groups do not alter the content of packets, an
     Intermediate System that does not implement mesh groups will
     not see any different packets or new TLVs. The only impact
     will be that additional CSNPs will be seen on some point-to-
     point links.  A conformant implementation can be expected to
     respond correctly to extra CSNPs.
     
     
     
     
     7.  Acknowledgments
     
     The original idea for mesh groups is due to Dave Katz.  Thanks
     to Tony Li, Tony Przygienda, Peter Livesey, and Henk Smit for
     helpful comments.
     
     
     
     
     8.  References
     
     [1]  ISO/IEC 10589, "Intermediate System to Intermediate
          System Intra- Domain Routeing Exchange Protocol for use
          in Conjunction with the Protocol for Providing the
          Connectionless-mode Network Service (ISO 8473)", June
          1992.
     
     
     
     
     
     
     
     
     Expires January 2001                                  [Page 7]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     9.  Security Considerations
     
     This document raises no new security issues for IS-IS.
     
     
     
     
     10.  Authors' Address
     
             Rajesh Balay
             CoSine Communications
             1200 Bridge Parkway
             Redwood City, CA 94065
             email: Rajesh.Balay@cosinecom.com
     
             Dave Katz
             Juniper Networks
             385 Ravendale Drive
             Mountain View, CA 94043
             email: dkatz@juniper.net
     
             Jeff Parker
             Lucent Technologies,
             200 Nickerson Road,
             Marlborough, MA 01752
             email: jparker@nexabit.com
     
     
     
     11.  Full Copyright Statement
     
     Copyright (C) The Internet Society (1997).  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
     
     
     
     
     
     Expires January 2001                                  [Page 8]


     INTERNET DRAFT        IS-IS Mesh Groups              July 2000
     
     
     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."
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Expires January 2001                                  [Page 9]

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