HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:05:38 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 18 Apr 1997 08:10:19 GMT ETag: "2e6bbb-54c8-33572c6b" Accept-Ranges: bytes Content-Length: 21704 Connection: close Content-Type: text/plain INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT Network Working Group K. Dobbins DRAFT J. Benoit Category: Informational T. Grant D. Ruffen Cabletron Systems Incorporated April 1997 Loop-free Interswitch Message Path (LSMP) Protocol Status of this Memo This document is an Internet-Draft. 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". To learn the current status of any Internet-Draft, please check the "1id-abstract.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Loop-Free Interswitch Message Path (LSMP) protocol is part of the InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate interswitch communication within distributed connection-oriented switching networks. The LSMP protocol is used to create and maintain the flood path over which undirected ISMP messages are sent. Table of Contents Status of this Memo.....................................1 Abstract................................................1 1. Introduction........................................1 1.1 Data Conventions...............................1 2. ISMP Overview.......................................2 3. General ISMP Packet Format..........................3 3.1 Frame Header...................................3 3.2 ISMP Packet Header.............................4 3.3 ISMP Message Body..............................5 4. LSMP Protocol Operational Overview..................5 4.1 Maintaining the Spanning Tree..................5 4.2 Remote Blocking................................6 5. Interswitch Spanning Tree BPDU Message..............7 6. Interswitch Remote Blocking Message.................8 References..............................................9 Security Considerations.................................9 Author's Addresses.....................................10 1. Introduction This draft is being distributed to members of the Internet community in order to solicit reactions to the proposals contained herein. While the specification discussed here may not be directly relevant to the research problems of the Internet, it may be of interest to researchers and implementers. 1.1 Data Conventions The methods used in this memo to describe and picture data adhere to the standards of Internet Protocol documentation K. Dobbins, et. al. [Page 1] DRAFT LSMP Protocol Specification April 1997 [RFC1700], in particular: The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data in "big-endian" order. That is, fields are described left to right, with the most significant octet on the left and the least significant octet on the right. The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. 2. ISMP Overview The InterSwitch Message Protocol (ISMP) is used for interswitch communication within distributed connection-oriented switching networks. ISMP provides the following services: - Topology services. Each switch maintains a distributed topology of the switch fabric by exchanging the following interswitch messages with other switches: - Interswitch Keepalive messages (SNDM protocol) are sent by each switch to announce its existence to its neighboring switches and to establish the topology of the switch fabric. - Interswitch Spanning Tree BPDU messages and Interswitch Remote Blocking messages (LSMP protocol) are used to determine and maintain a loop-free flood path between all network switches in the fabric. This flood path is used for all undirected interswitch messages -- that is, messages of the ARLD, SBCD and SFCT protocols. - Interswitch Link State messages (VLS protocol) are used to determine and maintain a fully connected mesh topology graph of the switch fabric. Call-originating switches use the topology graph to determine the path over which to route a call connection. K. Dobbins, et. al. [Page 2] DRAFT LSMP Protocol Specification April 1997 - Address resolution services. Interswitch Resolve messages (ARLD protocol) are used to resolve a packet destination address when the packet source and destination pair does not match a known connection. Interswitch New User messages (also part of the ARLD protocol) are used to provide end- station address mobility between switches. - Tag-based flooding. A tag-based broadcast method (SBCD protocol) is used to restrict the broadcast of unresolved packets to only those ports within the fabric that belong to the same VLAN as the source. - Call tapping services. Interswitch Tap messages (SFCT protocol) are used to monitor traffic moving between two end stations. Traffic can be monitored in one or both directions along the connection path. NOTE This document describes the LSMP protocol. Other ISMP protocols are described in other RFCs. See the References section for a list of these related RFCs. 3. General ISMP Packet Format ISMP packets are of variable length and have the following general structure: - Frame header - ISMP packet header - ISMP message body 3.1 Frame Header ISMP packets are encapsulated within an IEEE 802-compliant frame using a standard header as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 04 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address + 08 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16 | | + + : : K. Dobbins, et. al. [Page 3] DRAFT LSMP Protocol Specification April 1997 Destination address This 6-octet field contains the Media Access Control (MAC) address of the multicast channel over which all switches in the fabric receive ISMP packets. The destination address of all ISMP packets contain a value of 01-00-1D-00-00-00. Source address This 6-octet field contains the physical (MAC) address of the switch originating the ISMP packet. Type This 2-octet field identifies the type of data carried within the frame. The type field of ISMP packets contains the value 0x81FD. 3.2 ISMP Packet Header The ISMP packet header consists of 6 octets, as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 |///////////////////////////////////////////////////////////////| ://////// Frame header /////////////////////////////////////////: +//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 |///////////////////////////////| Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | ISMP message type | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | | + + : : Frame header This 14-octet field contains the frame header. Version This 2-octet field contains the version number of the InterSwitch Message Protocol to which this ISMP packet adheres. This document describes ISMP Version 2.0. ISMP message type This 2-octet field contains a value indicating which type of ISMP message is contained within the message body. Valid values are as follows: K. Dobbins, et. al. [Page 4] DRAFT LSMP Protocol Specification April 1997 1 (reserved) 2 Interswitch Keepalive messages (SNDM protocol) 3 Interswitch Link State messages (VLS protocol) 4 Interswitch Spanning Tree BPDU messages and Remote Blocking messages (LSMP protocol) 5 Interswitch Resolve and New User messages (ARLD protocol) 6 (reserved) 7 Tag-Based Flood messages (SBCD protocol) 8 Interswitch Tap messages (SFCT protocol) LSMP protocol messages have a message type of 4. Sequence number This 2-octet field contains an internally generated sequence number used by the various protocol handlers for internal synchronization of messages. 3.3 ISMP Message Body The ISMP message body is a variable-length field containing the actual data of the ISMP message. The length and content of this field are determined by the value found in the message type field. 4. LSMP Protocol Operational Overview The LSMP protocol is used to create and maintain the flood control path over which undirected ISMP messages are sent. (Undirected messages are those of the ARLD, SBCD, and SFCT protocols.) There are two parts to this process: - Maintaining the spanning tree - Remote blocking 4.1 Maintaining the Spanning Tree In a network with redundant network links, a packet traveling between switches can potentially be caught in an infinite loop -- an intolerable situation in a LAN environment. However, it is possible to reduce a network topology to a single configuration (known as a spanning tree) such that there is, at most, one path between any two switches. The spanning tree is created and maintained using the Spanning Tree Algorithm defined by the IEEE 802.1d standard. NOTE A detailed discussion of this algorithm is beyond the scope of this document. See [IEEE802] for more information. K. Dobbins, et. al. [Page 5] DRAFT LSMP Protocol Specification April 1997 To implement the Spanning Tree Algorithm, switches exchange Interswitch Spanning Tree BPDU messages containing encapsulated IEEE 802.2-compliant Logical Link Control (LLC) frames that, in turn, contain Bridge Protocol Data Units (BPDUs). There are two types of BPDUs: - Configuration (CFG) BPDUs are exchanged during the switch discovery process, following the receipt of an Interswitch Keepalive message [Work in Progress]. They are used to initialize the spanning tree. - Topology Change Notification (TCN) BPDUs are exchanged when changes in the network topology are detected by the Spanning Tree Algorithm. They are used to redefine the spanning tree to reflect the current topology. See [IEEE802] for detailed descriptions of these BPDUs. After the spanning tree has been computed, each network port on a switch will be in one of two states: - Forwarding. A port in the Forwarding state will be used to transmit all ISMP messages. - Blocking. A port in the Blocking state will not be used to forward undirected ISMP messages -- those with a ISMP message type of 5 (ARLD protocol), 7 (SBCD protocol) or 8 (SFCT protocol). Blocking the transmission of these messages on selected ports prevents message duplication arising from multiple paths that exist in the network topology. Note that all other types of ISMP message will be transmitted. 4.2 Remote Blocking As mentioned in Maintaining the Spanning Tree, once the spanning tree has been computed, each network port on a switch will be in one of two states: Forwarding or Blocking. NOTE The IEEE 802.1d standard specifies other port states used during the initialization of the spanning tree. These states are not relevant to the discussion here. Although a port in the Blocking state will not forward undirected ISMP messages, it may still receive them. Any such message received will ultimately be discarded, but at the cost of CPU time necessary to process the packet. K. Dobbins, et. al. [Page 6] DRAFT LSMP Protocol Specification April 1997 To prevent such unnecessary transmission of undirected messages to a port in the Blocking state, the port's owner switch can set remote blocking on the link by sending an Interswitch Remote Blocking message out over the port. This notifies the switch on the other end of the link that ISMP messages of type 5, 7 or 8 should not be sent over the link, regardless of the state of the sending port. Each switch sends an Interswitch Remote Blocking message out all its network ports at some predetermined interval (currently 5 seconds). A flag within the message indicates whether remote blocking should be turned on or off over the link. 5. Interswitch Spanning Tree BPDU Message The LSMP Interswitch Spanning Tree BPDU message consists of a variable number of octets, as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + Frame header / + : ISMP packet header : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | LSMP version | Message type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Message flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | : : BPDU packet + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame header/ISMP packet header This 20-octet field contains the frame header and the ISMP packet header. LSMP version This 2-octet field contains the version number of the LSMP protocol to which this message adheres. This document describes LSMP Version 1. Message type This 2-octet field contains the operation type of the message. Valid values are as follows: K. Dobbins, et. al. [Page 7] DRAFt LSMP Protocol Specification April 1997 1 The message is an Interswitch Spanning Tree BPDU message. 2 The message is an Interswitch Remote Blocking message. Message flags This 2-octet field is currently unused. It is reserved for future use. BPDU packet This variable-length field contains an IEEE-compliant 802.2 Logical Link Control (LLC) frame containing the Bridge Protocol Data Unit of the message. See [IEEE802] for a detailed description of a BPDU. 6. Interswitch Remote Blocking Message The LSMP Interswitch Remote Blocking message consists of 30 octets, as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + Frame header / + : ISMP packet header : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | LSMP version | Message type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Message flags | Blocking flag ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | ... Blocking flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame header/ISMP packet header This 20-octet field contains the frame header and the ISMP packet header. LSMP version This 2-octet field contains the version number of the LSMP protocol to which this message adheres. This document describes LSMP Version 1. Message type This 2-octet field contains the operation type of the message. Valid values are as follows: K. Dobbins, et. al. [Page 8] DRAFT LSMP Protocol Specification April 1997 1 The message is an Interswitch Spanning Tree BPDU message. 2 The message is an Interswitch Remote Blocking message. Message flags This 2-octet field is currently unused. It is reserved for future use. Blocking flag This 4-octet field contains a flag indicating the state of remote blocking on the link over which the message was received. A value of 1 indicates remote blocking is on and no undirected ISMP messages (those with a ISMP message type of 5, 7 or 8) should be sent over the link. A value of 0 indicates remote blocking is off. References [RFC1700] Reynolds, S.J., Postel, J. Assigned Numbers. October 1994. [IEEE802] IEEE Standard 802.1d. 1990. Dobbins, K., et. al. ARLD Protocol Specification Work in Progress. Dobbins, K., et. al. ISM Protocol Specification Work in Progress. Dobbins, K., et. al. SBCD Protocol Specification Work in Progress. Dobbins, K., et. al. SFCT Protocol Specification Work in Progress. Dobbins, K., et. al. SNDM Protocol Specification Work in Progress. Dobbins, K., et. al. VLS Protocol Specification Work in Progress. Security Considerations Security issues are not discussed in this document. K. Dobbins, et. al. [Page 9] DRAFT LSMP Protocol Specification April 1997 Authors' Addresses Cabletron Systems, Inc., is located at: Post Office Box 5005 Rochester, NH 03866-5005 (603) 332-9400 Kurt Dobbins Email: dobbins@ctron.com Joe Benoit Email: jbenoit@ctron.com Tom Grant Email: tgrant@ctron.com Dave Ruffen Email: ruffen@ctron.com INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT