Date: Fri, 17 May 96 18:40:59 +0100 From: "Trevor Warwick INF-SP" Organization: Madge Networks To: p8021@hepnrc.hep.net, stds-802-5@mail.ieee.org Cc: rhaggar@madge.com, psealey@madge.com (Peter Sealey INF-SP), sbarber@madge.com (Simon Barber), abrought@madge.com (Andrew Brought), cdentyou@madge.com (Crispin Dent-Young P&T), eferguson@baynetworks.com, earlf@baynetworks.com, alam@cisco.com, wwong@cisco.com Subject: Spanning Tree protocol on 802.5 LANs The recent introduction into the market of many new 802.5 bridge/switch products is in danger of introducing a new set of interoperability problems. In this memo, I am proposing a "de facto" solution to these problems. This mail is addressed to anybody responsible for an implementation of the ISO 10038 (IEEE 802.1D) spanning tree protocol in a product that supports running this protocol over an 802.5 LAN interface. Would those recipients on the 802.5 working group reflector please forward this mail to the appropriate recipients within their company. I would welcome any comments on this. Please copy them to the 802.5 and 802.1 mail exploders (stds-802-5@mail.ieee.org, p8021@hepnrc.hep.net). -- Trevor Warwick email : twarwick@madge.com Madge Networks, voice : +44 (0)1753 661401 Sefton Park, Bells Hill, fax : +44 (0)1753 661011 Slough, England. --------------------------------------------------------------------------- Background ---------- The operation of the Spanning Tree protocol on 802.5, as with many other protocols, is burdened with several historical complications. ISO 10038 states in section 3.12.3 that all BPDUs shall be sent to the Bridge Group Address (0180C2000000 in canonical form). It does not contain a provision for running anything other than the standard Spanning Tree protocol on 802.5 LANs. Historically, however, 802.5 LANs were mainly interconnected using pure Source Routing (SR) bridges, as opposed to Source Route Transparent (SRT) bridges as defined by 10038. The original SR bridge from IBM did not use the Spanning Tree protocol as described in ISO 10038. Instead, a cut-down protocol was used, which differs from the ISO 10038 protocol as follows: 1) BPDUs are sent to the 802.5 Functional Address of the Lan Bridge Server (LBS). This address is C00000000100 in 802.5 wire order. 2) The protocol does not use Topology Change Notification (TCN) BPDUs. 3) The Port-ID field of the BPDU is contains the Segment Number in the most significant twelve bits and the Bridge Number in the least significant four bits. 4) Implementations tend to use fixed values of Bridge Max Age, Bridge Forward Delay and Bridge Hello Time, typically 6, 4 and 2 seconds respectively. 5) Implementations also tend to increment Message Age by one second or less, rather than the one second or more that is typical of an implementation using the "C" code from ISO 10038. Problems -------- Several other vendors of SR bridges have implemented a Spanning Tree protocol that is more or less compatible with the above. This was fine while Source Routing was the only bridging method in use on 802.5 LANs. With the advent of more SRT products, and even pure Transparent bridges on 802.5 LANs, this has lead to a number of real interoperability problems, as vendors have chosen various different methods for running the ISO 10038 Spanning Tree Protocol on 802.5 LANs. These problems include: 1) Some SR Bridge implementations ignore BPDUs that don't have the correct Segment Number in the Port ID field. 2) Some SR Bridge implementations ignore BPDUs with the TC or TCN flags set. 3) Some SRT implementations implement the ISO 10038 protocol using the Bridge Group Address as the DA, some use the LBS FA, some can be configured to use either. 4) Mixing ISO 10038-based implementations and more IBM-compatible SR implementations leads to problems with root timeouts. If an IBM-compatible implementation using fixed configuration values is the root bridge, any 10038-based bridge in the network will tend to increment Message Age by more than one second, leading to the possible network diameter being reduced from six or seven bridges to three. Proposal -------- When dealing with new PARs, the 802.5 working group spends a great deal of time ensuring that existing implementations are not disenfranchised by the new work. This has often entailed selecting a "lowest common denominator" approach, which is sometimes not the most technically desirable solution. I propose that the default Spanning Tree mode for all transparent-capable 802.5 bridges/switches should be to run the 10038 protocol, but using the LBS FA as the destination address of the BPDUs. At the very least, all products should have an option of selecting this mode of operation. The reason for selecting the LBS FA as opposed to the Bridge Group Address is that many 802.5 MAC chipsets do not fully support IEEE group addresses. There are possible workarounds for this, but these workarounds disenfranchise a whole class of possible transparent bridge implementations. Since all known 802.5 chipsets support Functional Addressing, this should be an acceptable "lowest common denominator" approach. With appropriate software modifications, it would be possible for a single spanning tree to contain SR-only and SRT bridges. This would require another mode in the SRT devices to make them more IBM-compatible (limited timer-based transmission of TCN BPDUs, different use of Port ID field). The relaxation of any pointless checking in SR implementations would help (i.e., "is this MBZ field zero ?"), as would the implementation of configurable parameters . The main problem is that SR bridges will neither acknowledge, nor propagate TCN BPDUs, but this is not fatal. Some might argue that it is simply not appropriate to subvert, or dilute, an existing 802 standard in this way. I simply restate what I said above: We in 802.5 have spent a long time making sure that our standards are "pre-subverted" so that they fit in with existing implementations. I don't see this issue as being any different. Survey ------ There follows an informal survey of 802.5 bridge implementations I've investigated. I'm not trying to point any fingers, spread FUD, or in any way trying to gain vendor advantage by this. I'm merely trying to show the wide range of options that have been selected. If any vendor would like to supply more information, or correct mistakes in this list, please let me know. The non-inclusion of a product on the list only means that I have not got one to try out. IBM PC Bridge Program: De facto IBM SR implementation. Madge Ringbridge: IBM SR-like behaviour, somewhat less strict frame checking than IBM PC Bridge. Olicom Wirespeed Bridge: IBM SR-like behaviour, frame checking is apparently stricter than IBM PC Bridge. Cisco 4000/7000 Router (IOS 10.2): Optional IBM SR-like behaviour or 10038 compatible protocol using the LBS FA. IBM 8272 (plus OEM derivatives): 10038 compatible using the Bridge Group Address. Bay Networks Centillion 100 (Release 1.2): Optional IBM SR-like behaviour or 10038 compatible protocol using the Bridge Group Address. Madge Ringswitch (plus OEM derivatives): Optional IBM SR-like behaviour, or 10038 compatible protocol using the LBS FA.