Network Working Group D. Ruffen Request for Comments: 2643 T. Len Category: Informational J. Yanacek Cabletron Systems Incorporated August 1999 Cabletron's SecureFast VLAN Operational Model Version 1.8 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. Table of Contents 1. Introduction............................................. 3 1.1 Data Conventions..................................... 3 1.2 Definitions of Commonly Used Terms................... 4 2. SFVLAN Overview.......................................... 6 2.1 Features............................................. 7 2.2 VLAN Principles...................................... 8 2.2.1 Default, Base and Inherited VLANs.............. 8 2.2.2 VLAN Configuration Modes....................... 8 2.2.2.1 Endstations............................ 8 2.2.2.2 Ports.................................. 9 2.2.2.3 Order of Precedence.................... 9 2.2.3 Ports with Multiple VLAN Membership............ 10 2.3 Tag/Length/Value Method of Addressing................ 10 2.4 Architectural Overview............................... 11 3. Base Services............................................ 13 4. Call Processing.......................................... 14 4.1 Directory Service Center............................. 14 4.1.1 Local Add Server............................... 15 Ruffen, et al. Informational [Page 1] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 4.1.2 Inverse Resolve Server......................... 15 4.1.3 Local Delete Server............................ 18 4.2 Topology Service Center.............................. 18 4.2.1 Neighbor Discovery Server...................... 18 4.2.2 Spanning Tree Server........................... 18 4.2.2.1 Creating and Maintaining the Spanning Tree........... 19 4.2.2.2 Remote Blocking........................ 19 4.2.3 Link State Server.............................. 20 4.3 Resolve Service Center............................... 21 4.3.1 Table Server................................... 22 4.3.2 Local Server................................... 22 4.3.3 Subnet Server.................................. 22 4.3.4 Interswitch Resolve Server..................... 22 4.3.5 Unresolvable Server............................ 23 4.3.6 Block Server................................... 23 4.4 Policy Service Center................................ 24 4.4.1 Unicast Rules Server........................... 24 4.5 Connect Service Center............................... 25 4.5.1 Local Server................................... 25 4.5.2 Link State Server.............................. 25 4.5.3 Directory Server............................... 26 4.6 Filter Service Center................................ 26 4.7 Path Service Center.................................. 26 4.7.1 Link State Server.............................. 26 4.7.2 Spanning Tree Server........................... 27 4.8 Flood Service Center................................. 27 4.8.1 Tag-Based Flood Server......................... 27 5. Monitoring Call Connections.............................. 27 5.1 Definitions.......................................... 27 5.2 Tapping a Connection................................. 28 5.2.1 Types of Tap Connections....................... 28 5.2.2 Locating the Probe and Establishing the Tap Connection.......... 29 5.2.3 Status Field................................... 30 5.3 Untapping a Connection............................... 31 6. Interswitch Message Protocol (ISMP)...................... 32 6.1 General Packet Structure............................. 32 6.1.1 Frame Header................................... 32 6.1.2 ISMP Packet Header............................. 33 6.1.2.1 Version 2.............................. 33 6.1.2.2 Version 3.............................. 34 6.1.3 ISMP Message Body.............................. 35 6.2 Interswitch BPDU Message............................. 35 6.3 Interswitch Remote Blocking Message.................. 36 6.4 Interswitch Resolve Message.......................... 37 6.4.1 Prior to Version 1.8........................... 37 6.4.2 Version 1.8.................................... 41 Ruffen, et al. Informational [Page 2] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 6.5 Interswitch New User Message......................... 46 6.6 Interswitch Tag-Based Flood Message.................. 49 6.6.1 Prior to Version 1.8........................... 49 6.6.2 Version 1.8.................................... 52 6.7 Interswitch Tap/Untap Message........................ 55 7. Security Considerations.................................. 58 8. References............................................... 58 9. Authors' Addresses....................................... 59 10. Full Copyright Statement................................ 60 1. Introduction This memo 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 [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. Ruffen, et al. Informational [Page 3] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 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. 1.2 Definitions of Commonly Used Terms This section contains a collection of definitions for terms that have a specific meaning for the SFVLAN product and that are used throughout the text. Switch ID A 10-octet value that uniquely identifies an SFVLAN switch within the switch fabric. The value consists of the 6-octet base MAC address of the switch, followed by 4 octets of zeroes. Network link The physical connection between two switches. A network link is associated with a network interface (or port) of a switch. Network port An interface on a switch that attaches to another switch. Access port An interface on a switch that attaches to a user endstation. Port ID A 10-octet value that uniquely identifies an interface of a switch. The value consists of the 6-octet base MAC address of the switch, followed by the 4-octet local port number of the interface. Neighboring switches Two switches attached to a common (network) link. Call connection A mapping of user traffic through a switch that correlates the source and destination address pair specified within the packet to an inport and outport pair on the switch. Ruffen, et al. Informational [Page 4] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 Call connection path A set of 0 to 7 network links over which user traffic travels between the source and destination endstations. Call connection paths are selected from a list of alternate equal cost paths calculated by the VLS protocol [IDvlsp], and are chosen to load balance traffic across the fabric. Ingress switch The owner switch of the source endstation of a call connection. That is, the source endstation is attached to one of the local access ports of the switch. Egress switch The owner switch of the destination endstation of a call connection. That is, the destination endstation is attached to one of the local access ports of the switch. Intermediate switches Any switch along the call connection path on which user traffic enters and leaves over network links. Note that the following types of connections have no intermediate switches: - Call connections between source and destination endstations that are attached to the same switch -- that is, the ingress switch is the same as the egress switch. Note also that the path for this type of connection consists of 0 network links. - Call connections where the ingress and egress switches are physical neighbors connected by a single network link. The path for this type of connection consists of a single network link. InterSwitch Message protocol (ISMP) The protocol used for interswitch communication between SFVLAN switches. Undirected messages Messages that are (potentially) sent to all SFVLAN switches in the switch fabric -- that is, they are not directed to any particular switch. ISMP messages with a message type of 5, 7 or 8 are undirected messages. Ruffen, et al. Informational [Page 5] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 Switch flood path The path used to send undirected messages throughout the switch fabric. The switch flood path is formed using a spanning tree algorithm that provides a single path through the switch fabric that guarantees loop-free delivery to every other SFVLAN switch in the fabric. Upstream Neighbor That switch attached to the inport of the switch flood path -- that is, the switch from which undirected messages are received. Note that each switch receiving an undirected message has, at most, one upstream neighbor, and the originator of any undirected ISMP message has no upstream neighbors. Downstream Neighbors Those switches attached to all outports of the switch flood path except the port on which the undirected message was received. Note that for each undirected message some number of switches have no downstream neighbors. Virtual LAN (VLAN) identifier A VLAN is a logical grouping of ports and endstations such that all ports and endstations in the VLAN appear to be on the same physical (or extended) LAN segment even though they may be geographically separated. A VLAN identifier consists of a variable-length string of octets. The first octet in the string contains the number of octets in the remainder of the string -- the actual VLAN identifier value. A VLAN identifier can be from 1 to 16 octets long. VLAN policy Each VLAN has an assigned policy value used to determine whether a particular call connection can be established. SFVLAN recognizes two policy values: Open and Secure. 2. SFVLAN Overview Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. Ruffen, et al. Informational [Page 6] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 2.1 Features Within a connection-oriented switching network, user traffic is routed through the switch fabric based on the source and destination address (SA/DA) pair found in the arriving packet. For each SA/DA pair encountered by a switch, a "connection" is programmed into the switch hardware. This connection maps the SA/DA pair and the port on which the packet was received to a specific outport over which the packet is to be forwarded. Thus, once a connection has been established, all packets with a particular SA/DA pair arriving on a particular inport are automatically forwarded by the switch hardware out the specified outport. A distributed switching environment requires that each switch be capable of processing all aspects of the call processing and switching functionality. Thus, each switch must synchronize its various databases with all other switches in the fabric or be capable of querying other switches for information it does not have locally. SFVLAN accomplishes the above objectives by providing the following features: - A virtual directory of the entire switch fabric. - Call processing for IP, IPX and MAC protocols. - Automatic call connection, based on VLAN policy. - Automatic call rerouting around failed switches and links. In addition, SFVLAN optimizes traffic flow across the switch fabric by providing the following features: - Broadcast interception and address resolution at the ingress port. - Broadcast scoping, restricting the flooding of broadcast packets to only those ports that belong to the same VLAN as the packet source. - A single loop-free path (spanning tree) used for the flooding of undirected interswitch control messages. Only switches running the SFVLAN switching protocol are included in this spanning tree calculation -- that is, traditional bridges or routers configured for bridging are not included. - Interception of both service and route advertisements with readvertisement sourced from the MAC address of the original advertiser. Ruffen, et al. Informational [Page 7] RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 2.2 VLAN Principles Each SFVLAN switch port, along with its attached endstations, belongs to one or more virtual LANs (VLANs). A VLAN is a logical grouping of ports and endstations such that all ports and endstations in the VLAN appear to be on the same physical (or extended) LAN segment even though they may be geographically separated. VLAN assignments are used to determine the validity of call connection requests and to scope the broadcast of certain