HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:40:25 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 23 Jun 1999 14:33:00 GMT ETag: "2e7d69-44fb-3770f01c" Accept-Ranges: bytes Content-Length: 17659 Connection: close Content-Type: text/plain Internet Engineering Task Force R.Balay INTERNET DRAFT D.Katz J.Parker Mon Jun 14 1999 IS-IS Mesh Groups 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. 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 changes to implementations, not to the protocol. These changes are backwards compatible with implementations that do not support this feature. Internet Engineering Task Force R. Balay INTERNET DRAFT D. Katz J. Parker Mon Jun 14 1999 IS-IS Mesh Groups 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 June 1999 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 changes to implementations, not to the protocol. These changes are backwards compatible with implementations that do not support this feature. 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............................. 5 6. Interoperation with Mesh Groups...................... 7 7. Acknowledgments...................................... 7 8. References........................................... 7 9. Security Considerations.............................. 7 10. Authors' Address..................................... 8 11. Full Copyright Statement............................. 9 3. Overview This document is provided to the IETF working group on IS-IS. 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 Expires December 1999 [Page 2] INTERNET DRAFT IS-IS Mesh Groups June 1999 flooding operation which is illustrated below. 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 Expires December 1999 [Page 3] INTERNET DRAFT IS-IS Mesh Groups June 1999 Systems, the standard protocol mechanism results in N-2 extra transmissions of each LSP, a waste of bandwidth and processing 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. 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 meshEnabled or meshBlocked. Section 7.3.15.3 clause b) of ISO 10589 [1] is modified as follows: Expires December 1999 [Page 4] INTERNET DRAFT IS-IS Mesh Groups June 1999 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 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 Expires December 1999 [Page 5] INTERNET DRAFT IS-IS Mesh Groups June 1999 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 December 1999 [Page 6] INTERNET DRAFT IS-IS Mesh Groups June 1999 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, and Henk Smit for helpful comments. 8. References [1] ISO 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)" [Also republished as RFC 1142] Expires December 1999 [Page 7] INTERNET DRAFT IS-IS Mesh Groups June 1999 9. Security Considerations This document raises no new security issues for IS-IS. 10. Authors' Address Rajesh Balay Torrent Networking Technologies (An Ericsson Company) 3000 Aerial Center Pkwy, Suite 140 Morrisville, NC 27560 email: balay@torrentnet.com Dave Katz Juniper Networks 385 Ravendale Drive Mountain View, CA 94043 email: dkatz@juniper.net Jeff Parker Nexabit Networks, Inc. 200 Nickerson Road, Marlborough, MA 01752 email: jparker@nexabit.com Expires December 1999 [Page 8] INTERNET DRAFT IS-IS Mesh Groups June 1999 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 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 December 1999 [Page 9]