From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2643.txt | 3363 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3363 insertions(+) create mode 100644 doc/rfc/rfc2643.txt (limited to 'doc/rfc/rfc2643.txt') diff --git a/doc/rfc/rfc2643.txt b/doc/rfc/rfc2643.txt new file mode 100644 index 0000000..058abbe --- /dev/null +++ b/doc/rfc/rfc2643.txt @@ -0,0 +1,3363 @@ + + + + + + +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 flooded + messages. + +2.2.1 Default, Base and Inherited VLANs + + Each port is explicitly assigned to a default VLAN. At start-up, the + default VLAN to which all ports are assigned is the base VLAN -- a + permanent, non-deletable VLAN to which all ports belong at all times. + + The network administrator can change the default VLAN of a port from + the base VLAN to any other unique VLAN by using a management + application known here as the VLAN Manager. A port's default VLAN is + persistent -- that is, it is preserved across a switch reset. + + When an endstation attaches to a port for the first time, it inherits + the default VLAN of the port. Using the VLAN Manager, the network + administrator can reassign an endstation to another VLAN. + + Note: + + When all ports and all endstations belong to the base VLAN, the + switch fabric behaves like an 802.1D bridging system. + +2.2.2 VLAN Configuration Modes + + For both ports and endstations, there are a variety of VLAN + configuration types, or modes. + +2.2.2.1 Endstations + + For endstations, there are two VLAN configuration modes: inherited + and static. + + - Inherited + + An inherited endstation becomes a member of its port's default + VLAN. + + + + + +Ruffen, et al. Informational [Page 8] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - Static + + A static port becomes a member of the VLAN to which it has been + assigned by the VLAN Manager. + + The default configuration mode for an endstation is inherited. + +2.2.2.2 Ports + + For ports, there are two VLAN configuration modes: normal and + locked. + + - Normal + + All inherited endstations on a normal port become members of the + port's default VLAN. All static endstations are members of the + VLAN to which they were mapped by the VLAN Manager. + + If the VLAN Manager reassigns the default VLAN of a normal port, + the VLAN(s) for the attached endstations may or may not change, + depending on the VLAN configuration mode of each endstation. All + inherited endstations will become members of the new default VLAN. + All others will retain membership in their previously mapped + VLANs. + + - Locked + + All endstations attached to a locked port can be members only of + the port's default VLAN. + + If the VLAN Manager reconfigures a normal port to be a locked + port, all endstations attached to the port become members of the + port's default VLAN, regardless of any previous VLAN membership. + + The default configuration mode for ports is normal. + +2.2.2.3 Order of Precedence + + On a normal port, static VLAN membership prevails over inherited + membership. + + On a locked port, default VLAN membership prevails over any static + VLAN membership. + + If a statically assigned endstation moves from a locked port back to + a normal port, the endstation's static VLAN membership must be + preserved. + + + + +Ruffen, et al. Informational [Page 9] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +2.2.3 Ports with Multiple VLAN Membership + + A port can belong to multiple VLANs, based on the VLAN membership of + its attached endstations. + + For example, consider a port with three endstations, a default VLAN + of "blue" and the following endstation VLAN assignments: + + - One of the endstations is statically assigned to VLAN "red." + - Another endstation is statically assigned to VLAN "green." + - The third endstation inherits the default VLAN of "blue." + + In this instance, the port is explicitly a member of VLAN "blue." But + note that it is also implicitly a member of VLAN "red" and VLAN + "green." Any tag-based flooding (Section 4.8) directed to any one of + the three VLANs ("red," "green," or "blue") will be forwarded out the + port. + +2.3 Tag/Length/Value Method of Addressing + + Within most computer networks, the concept of "address" is somewhat + elusive because different protocols can (and do) use different + addressing schemes and formats. For example, Ethernet (physical + layer) addresses are six octets long, while IP (network layer) + addresses are only four octets long. + + To distinguish between the various protocol-specific forms of + addressing, many software modules within the SFVLAN product specify + addresses in a format known as Tag/Length/Value (TLV). This format + uses a variable-length construct 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value length | | + +-+-+-+-+-+-+-+-+ + + | Address value | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Tag + + This 4-octet field specifies the type of address contained in the + structure. The following address types are currently supported: + + + + +Ruffen, et al. Informational [Page 10] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Tag name Value Address type + + aoMacDx 1 DX ethernet dst/src/type + aoIpxSap 2 Sap + aoIpxRIP 3 RIP + aoInstYP 4 YP (YP name and version) + aoInstUDP 5 UDP (Port #) + aoIpxIpx 6 Ipx + aoInetIP 7 IP (Net address) + aoInetRPC 8 RPC (Program #) + aoInetRIP 9 INET RIP + aoMacDXMcast 10 Multicast unknown type + aoAtDDP 11 AppleTalk DDP + aoEmpty 12 (no address type specified) + aoVlan 13 VLAN identifier + aoHostName 14 Host name + aoNetBiosName 15 NetBIOS name + aoNBT 16 NetBIOS on TCP name + aoInetIPMask 17 IP Subnet Mask + aoIpxSap8022 18 Sap 8022 type service + aoIpxSapSnap 19 Sap Snap type service + aoIpxSapEnet 20 Sap Enet type service + aoDHCPXID 21 DHCP Transaction ID + aoIpMcastRx 22 IP class D receiver + aoIpMcastTx 23 IP class D sender + aoIpxRip8022 24 Ipx Rip 8022 type service + aoIpxRipSnap 25 Ipx Rip type service + aoIpxRipEnet 26 Ipx Rip Enet service + aoATM 27 ATM + aoATMELAN 28 ATM LAN Emulation Name + + Value length + + This 1-octet field contains the length of the value of the + address. The value here depends on the address type and actual + value. + + Address value + + This variable-length field contains the value of the address. The + length of this field is stored in the Value length field. + +2.4 Architectural Overview + + The SFVLAN software executes in the switch CPU and consists of the + following elements as shown in Figure 1: + + + + + +Ruffen, et al. Informational [Page 11] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - The SFVLAN base services that handles traffic intercepted by the + switch hardware. The base services are described in Section 3. + + +------------------------------------------------------+ + | +-----+ | + | +------------+ | I | | + | | CALL TAP <--(8)--> N | | + | +------------+ | T | | + | | E | | + | +-----------+ +------------+ | R | | + | | PATH | | TOPOLOGY | | S | | + | | | | | | W | | + | | Lnk state <------> Lnk state <--(3)--> I | | Flood path + | | | | | | T <----(5,7,8)--> + | | Span tree <------> Span tree <--(4)--> C | | + | +--^--------+ | | | H | | + | | | Discovery <--(2)--> | | + | | +------------+ | M | | + | | | E | | + | +------^--+ +--------+ | S | | + | | CONNECT >---------+--> FILTER | | S | | + | +--^------+ | +--------+ | A | | specific + | | | | G | | netwrk lnks + | | +--------^-+ +-------+ | E <----(2,3,4)--> + | +-------< POLICY | | FLOOD >--(7)--> | | + | +------^---+ +-^-----+ | P | | + | | | | R | | + | +-----------+ +-^-----------V-+ | O | | + | | DIRECTORY <----> RESOLVE <------(5)--> T | | + | +-----^-----+ +---^-----------+ | O | | + | | | | C | | + | | +---------^-----------+ | O | | + | +----< Base Services | | L | | + | +-----^---------------+ +-----+ | + +------------------|-----------------------------------+ + Switch CPU | + | Host control port + +-----O----------------+ + | ^ no cnx | + Layer 2 | | | + ---------->O-----+--------------->O-----------> + SA/DA pr | known cnx | + +----------------------+ + Switch hardware + + + Figure 1: SFVLAN Architectural Overview + + + + +Ruffen, et al. Informational [Page 12] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - Eight call processing service centers that provide the essential + services required to process call connections. The call + processing service centers are described in Section 4. + + - A Call Tap module that supports the monitoring of call + connections. The Call Tap module is described in Section 5. + + - The InterSwitch Message Protocol (ISMP) that provides a consistent + method of encapsulating and transmitting control messages + exchanged between SFVLAN switches. (Note that ISMP is not a + discrete software module. Instead, its functionality is + distributed among those service centers and software modules that + need to communicate with other switches in the fabric.) The + Interswitch Message Protocol and the formats of the individual + interswitch messages are described in Section 6. + +3. Base Services + + The SFVLAN base services act as the interface between the switch + hardware and the SFVLAN service centers running on the switch CPU. + This relationship is shown in Figure 2. This figure is a replication + of the bottom portion of Figure 1. + + + | Directory Resolve | + | ^ ^ | + | | | | + | | +---------^-----------+ | + | +----< Base Services | | + | +-----^---------------+ | + +-------------------|--------------------------+ + Switch CPU | + | Host control port + +-----O----------------+ + | ^ no cnx | + Layer 2 | | | + ---------->O-----+--------------->O-----------> + SA/DA pr | known cnx | + +----------------------+ + Switch hardware + + + Figure 2: Base Services + + + + + + + + +Ruffen, et al. Informational [Page 13] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + During normal operation of the switch, data packets arriving at + any one of the local switch ports are examined in the switch + hardware. If the packet's source and destination address (SA/DA) + pair match a known connection, the hardware simply forwards the + packet out the outport specified by the connection. + + If the SA/DA pair do not match any known connection, the hardware + diverts the packet to the host control port where it is picked up + by the SFVLAN base services. The base services generate a + structure known as a state box that tracks the progress of the + call connection request as the request moves through the call + processing service centers. + + After creating the call's state box, the base services check to + determine if the call is a duplicate of a call already being + processed. If not, a request is issued to the Directory Service + Center (Section 4.1) to add the call's source address to the local + Node and Alias Tables. The base services then hand the call off to + the Resolve Service Center (Section 4.3) for further processing. + +4. Call Processing + + Call connection processing is handled by a set of eight service + centers, each with one or more servers. The servers within a + service center are called in a particular sequence. Each server + records the results of its processing in the call connection + request state box and passes the state box to the next server in + the sequence. + + In the sections that follow, servers are listed in the order in + which they are called. + +4.1 Directory Service Center + + The Directory Service Center is responsible for cataloging the MAC + addresses and alias information for both local and remote + endstations. The information is stored in two tables -- the Node + Table and the Alias Table. + + - The Node Table contains the MAC addresses of endstations + attached to the local switch. It also contains a cache of + remote endstations detected by the Resolve Service Center + (Section 4.3). Every entry in the Node Table has one or more + corresponding entries in the Alias Table. + + + + + + + +Ruffen, et al. Informational [Page 14] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - The Alias Table contains protocol alias information for each + endstation. An endstation alias can be a network address (such + as an IP or IPX address), a VLAN identifier, or any other + protocol identifier. Since every endstation is a member of at + least one VLAN (the default VLAN for the port), there is always + at least one entry in the Alias Table for each entry in the + Node Table. + + Note: + + The Node and Alias Tables must remain synchronized. + That is, when an endstation's final alias is removed + from the Alias Table, the endstation entry is removed + from the Node Table. + + Note that the total collection of all Node Tables and Alias Tables + across all switches is known as the "virtual" directory of the + switch fabric. The virtual directory contains address mappings of + all known endstations in the fabric. + +4.1.1 Local Add Server + + The Directory Local Add server adds entries to the local Node or + Alias Tables. It is called by the base services (Section 3) to + add a local endstation and by the Interswitch Resolve (Section + 4.3.4) server to add an endstation discovered on a remote switch. + +4.1.2 Inverse Resolve Server + + The Directory Inverse Resolve server is invoked when a new + endstation has been discovered on the local switch (that is, when + the Local Add server was successful in adding the endstation). + The server provides two functions: + + - It populates the Node and Alias Tables with local entries + during switch initialization. + + - It processes a new endstation discovered after the fabric + topology has converged to a stable state. + + In both instances, the processing is identical. + + + + + + + + + + +Ruffen, et al. Informational [Page 15] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + When a new endstation is detected on one of the switch's local + ports, the Inverse Resolve server sends an Interswitch New User + request message (Section 6.5) over the switch flood path to all + other switches in the fabric. The purpose of the Interswitch New + User request is two-fold: + + - It informs the other switches of the new endstation address. + Any entries for that endstation in the local databases of other + switches should be dealt with appropriately. + + - It requests information about any static VLAN(s) to which the + endstation has been assigned. + + When a switch receives an Interswitch New User request message + from one of its upstream neighbors, it first forwards the message + to all its downstream neighbors. No actual processing or VLAN + resolution is attempted until the message reaches the end of the + switch flood path and begins its trip back along the return path. + This ensures that all switches in the fabric receive notification + of the new user and have synchronized their databases. + + If a switch receives an Interswitch New User request message but + has no downstream neighbors, it does the following: + + - If the endstation was previously connected to one of the + switch's local ports, the switch formulates an Interswitch New + User Response message by loading the VLAN identifier(s) of the + static VLAN(s) to which the endstation was assigned, along with + its own MAC address. (VLAN identifiers are stored in + Tag/Length/Value (TLV) format. See Section 2.3.) The switch + then sets the message status field to NewUserAck, and returns + the message to its upstream (requesting) neighbor. + + Otherwise, the switch sets the status field to NewUserUnknown + and returns the message to its upstream neighbor. + + - The switch then deletes the endstation from its local database, + as well as any entries associated with the endstation in its + connection table. + + When a switch forwards an Interswitch New User request message to + its downstream neighbors, it keeps track of the number of requests + it has sent out and does not respond back to its upstream neighbor + until all requests have been responded to. + + + + + + + +Ruffen, et al. Informational [Page 16] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - As each response is received, the switch checks the status + field of the message. If the status is NewUserAck, the switch + retains the information in that response. When all requests + have been responded to, the switch returns the NewUserAck + response to its upstream neighbor. + + - If all the Interswitch New User Request messages have been + responded to with a status of NewUserUnknown, the switch checks + to see if the endstation was previously connected to one of its + local ports. If so, the switch formulates an Interswitch New + User Response message by loading the VLAN identifier(s) of the + static VLAN(s) to which the endstation was assigned, along with + its own MAC address. The switch then sets the message status + field to NewUserAck, and returns the message to its upstream + (requesting) neighbor. + + Otherwise, the switch sets the status field to NewUserUnknown + and returns the message to its upstream neighbor. + + - The switch then deletes the endstation from its local database, + as well as any entries associated with the endstation in its + connection table. + + When the originating switch has received responses to all the + Interswitch New User Request messages it has sent, it does the + following: + + - If it has received a response message with a status of + NewUserAck, it loads the new VLAN information into its local + database. + + - If all responses have been received with a status of + NewUserUnknown, the originating switch assumes that the + endstation was not previously connected anywhere in the network + and assigns it to a VLAN according to the VLAN membership rules + and order of precedence. + + If any Interswitch New User Request message has not been responded + to within a certain predetermined time (currently 5 seconds), the + originating switch recalculates the switch flood path and resends + the Interswitch New User Request message. + + + + + + + + + + +Ruffen, et al. Informational [Page 17] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.1.3 Local Delete Server + + The Directory Local Delete server removes entries (both local and + remote) from the local Node and Alias Tables. It is invoked when + an endstation, previously known to be attached to one switch, has + been moved and discovered on another switch. + + Note also that remote entries are cached and are purged from the + tables on a first-in/first-out basis as space is needed in the + cache. + +4.2 Topology Service Center + + The Topology Service Center is responsible for maintaining three + databases relating to the topology of the switch fabric: + + - The topology table of SFVLAN switches that are physical + neighbors to the local switch. + + - The spanning tree that defines the loop-free switch flood path + used for transmitting undirected interswitch messages. + + - The directed graph that is used to calculate the best path(s) + for call connections. + +4.2.1 Neighbor Discovery Server + + The Topology Neighbor Discovery server uses Interswitch Keepalive + messages to detect the switch's neighbors and establish the + topology of the switching fabric. Interswitch Keepalive messages + are exchanged in accordance with Cabletron's VlanHello protocol, + described in detail in [IDhello]. + +4.2.2 Spanning Tree Server + + The Topology Spanning Tree server is invoked by the Topology + Neighbor Discovery server when a neighboring SFVLAN switch is + either discovered or lost -- that is, when the operational status + of a network link changes. + + The Spanning Tree server exchanges interswitch messages with + neighboring SFVLAN switches to calculate the switch flood path + over which undirected interswitch messages are sent. There are + two parts to this process: + + - Creating and maintaining the spanning tree + - Remote blocking + + + + +Ruffen, et al. Informational [Page 18] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.2.2.1 Creating and 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 networking 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. + + Within the SFVLAN product, 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 [IEEE] for more information. + + To implement the Spanning Tree Algorithm, SFVLAN switches exchange + Interswitch BPDU messages (Section 6.2) containing encapsulated + IEEE-compliant 802.2 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. They are used to create the initial the + spanning tree. + + - Topology Change Notification (TCN) BPDUs are exchanged when + changes in the network topology are detected. They are used to + redefine the spanning tree to reflect the current topology. + + See [IEEE] for detailed descriptions of these BPDUs. + +4.2.2.2 Remote Blocking + + After the spanning tree has been computed, each network port on an + SFVLAN switch will be in one of two states: + + - Forwarding. A port in the Forwarding state will be used to + transmit all ISMP messages. + + + + + + + + + + +Ruffen, et al. Informational [Page 19] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - Blocking. A port in the Blocking state will not be used to + forward undirected ISMP messages. Blocking the rebroadcast 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. + + Note: + + The IEEE 802.1d standard specifies other port states used + during the initial creation of the spanning tree. These states + are not relevant to the discussion here. + + Note that 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. + + To prevent the transmission of undirected messages to a port, the + port's owner switch can set remote blocking on the link by sending an + Interswitch Remote Blocking message (Section 6.3) out over the port. + This notifies the switch on the other end of the link that undirected + messages should not be sent over the link, regardless of the state of + the sending port. + + Each SFVLAN switch sends an Interswitch Remote Blocking message out + over all its blocked network ports every 5 seconds. A flag within + the message indicates whether remote blocking should be turned on or + off over the link. + +4.2.3 Link State Server + + The Topology Link State server is invoked by any process that detects + a change in the state of the network links of the local switch. + These changes include (but are not limited to) changes in operational + or administrative status of the link, path "cost" or bandwidth. + + The Link State server runs Cabletron's Virtual LAN Link State (VLS) + protocol which exchanges interswitch messages with neighboring SFVLAN + switches to calculate the set of best paths between the local switch + and all other switches in the fabric. (The VLS protocol is described + in detail in [IDvlsp].) + + The Link State server also notifies the Connect Service Center + (Section 4.5) of any remote links that have failed, thereby + necessitating potential tear-down of current connections. + + + + + + +Ruffen, et al. Informational [Page 20] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.3 Resolve Service Center + + The Resolve Service Center is responsible for resolving the + destination address of broadcast data packets (such as an IP ARP + packet) to a unicast MAC address to be used in mapping the call + connection. To do this, the Resolve Service Center attempts to + resolve such broadcast packets directly at the access port of the + ingress switch. + + Address resolution is accomplished as follows: + + 1) First, an attempt is made to resolve the address from the switch's + local databases by calling the following servers: + + - The Table server attempts to resolve the address from the + Resolve Table (Section 4.3.1). + + - Next, the Local server attempts to resolve the address from the + Node and Alias Tables (Section 4.3.2). + + - If the address is not found in these tables but is an IP + address, the Resolve Subnet server (Section 4.3.3) is also + called. + + 2) If the address cannot be resolved locally, the Interswitch Resolve + server (Section 4.3.4) is called to access the "virtual directory" + by sending an Interswitch Resolve request message out over the + switch flood path. + + 3) If the address cannot be resolved either locally or via an + Interswitch Resolve message -- that is, the destination endstation + is unknown to any switch, perhaps because it has never transmitted + a packet to its switch -- the following steps are taken: + + - The Unresolvable server (Section 4.3.5) is called to record the + unresolved packet. + + - The Block server (Section 4.3.6) is called to determine whether + the address should be added to the Block Table. + + - The Flood Service Center (Section 4.8) is called to broadcast + the packet to other SFVLAN switches using a tag-based flooding + mechanism. + + + + + + + + +Ruffen, et al. Informational [Page 21] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.3.1 Table Server + + The Resolve Table server maintains the Resolve Table which contains a + collection of addresses that might not be resolvable in the normal + fashion. This table typically contains such things as the addresses + of "quiet" devices that do not send data packets or special mappings + of IP addresses behind a router. Entries can be added to or deleted + from the Resolve Table via an external management application. + +4.3.2 Local Server + + The Resolve Local server checks the Node and Alias Tables maintained + by the Directory Service Center (Section 4.1) to determine if it can + resolve the address. + +4.3.3 Subnet Server + + If the address to be resolved is an IP address but cannot be resolved + via the standard processing described above, the Resolve Subnet + server applies the subnet mask to the IP address and then does a + lookup in the Resolve Table. + +4.3.4 Interswitch Resolve Server + + If the address cannot be resolved locally, the Interswitch Resolve + server accesses the "virtual directory" by sending an Interswitch + Resolve request message (Section 6.4) out over the switch flood path. + The Interswitch Resolve request message contains the destination + address as it was received within the packet, along with a list of + requested addressing information. + + When a switch receives an Interswitch Resolve request message from + one of its upstream neighbors, it checks to see if the destination + endstation is connected to one of its local access ports. If so, it + formulates an Interswitch Resolve response message by filling in the + requested address information, along with its own MAC address. It + then sets the message status field to ResolveAck, and returns the + message to its upstream (requesting) neighbor. + + If the receiving switch cannot resolve the address, it forwards the + Interswitch Resolve request message to its downstream neighbors. If + the switch has no downstream neighbors, it sets the message status + field to Unknown, and returns the message to its upstream + (requesting) neighbor. + + + + + + + +Ruffen, et al. Informational [Page 22] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + When a switch forwards an Interswitch Resolve request message to its + downstream neighbors, it keeps track of the number of requests it has + sent out and received back. It will only respond back to its + upstream (requesting) neighbor when one of the following conditions + occurs: + + - It receives any response with a status of ResolveAck + + - All downstream neighbors have responded with a status of Unknown + + Any Interswitch Resolve request message that is not responded to + within a certain predetermined time (currently 5 seconds) is assumed + to have a response status of Unknown. + + When the Interswitch Resolve server receives a successful Interswitch + Resolve response message, it records the resolved address information + in the remote cache of its local directory for use in resolving later + packets for the same endstation. Note that this process results in + each switch building its own unique copy of the virtual directory + containing only the endstation addresses in which it is interested. + +4.3.5 Unresolvable Server + + The Unresolvable server is called when a packet destination address + cannot be resolved. The server records the packet in a table that + can then be examined to determine which endstations are generating + unresolvable traffic. + + Also, if a particular destination is repeatedly seen to be + unresolvable, the server calls the Block server (Section 4.3.6) to + determine whether the address should be blocked. + +4.3.6 Block Server + + The Resolve Block server is called when a particular destination has + been repeatedly seen to be unresolvable. This typically happens + when, unknown to the packet source, the destination endstation is + either not currently available or no longer exists. + + If the Block server determines that the unresolved address has + exceeded a configurable request threshold, the address is added to + the server's Block Table. Interswitch Resolve request messages for + addresses listed in the Block Table are sent less frequently, thereby + reducing the amount of Interswitch Resolve traffic throughout the + fabric. + + + + + + +Ruffen, et al. Informational [Page 23] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + If an address listed in the Block Table is later successfully + resolved by and Interswitch Resolve request message, the address is + removed from the table. + +4.4 Policy Service Center + + Once the destination address of the call packet has been resolved, + the Policy Service Center is called to determine the validity of the + requested call connection based on the VLAN policy of the source and + destination VLANs. + +4.4.1 Unicast Rules Server + + The Policy Unicast Rules server recognizes two VLAN policy values: + Open or Secure. The default policy for all VLANs is Open. + + The policy value is used as follows when determining the validity of + a requested call connection: + + - If the VLAN policy of either the source or destination cannot be + determined, the Filter Service Center is called to establish a + filter (i.e., blocked) for the SA/DA pair. + + - If the source and destination endstations belong to the same VLAN, + then the connection is permitted regardless of the VLAN policy. + + - If the source and destination endstations belong to different + VLANs, but both VLANs are running with an Open policy, then the + connection is permitted, providing cut-through switching between + different VLAN(s). + + - If the source and destination endstations belong to different + VLANs and one or both of the VLANs are running with a Secure + policy, then the Flood Service Center (Section 4.8) is called to + broadcast the packet to other SFVLAN switches having ports or + endstations that belong to the same VLAN as the packet source. + + Note that if any of the VLANs to which the source or destination + belong has a Secure policy, then the policy used in the above + algorithm is Secure. + + + + + + + + + + + +Ruffen, et al. Informational [Page 24] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.5 Connect Service Center + + Once the Policy Service Center (Section 4.4) has determined that a + requested call connection is valid, the Connect Service Center is + called to set up the connection. Note that connectivity between two + endstations within the fabric is established on a switch-by-switch + basis as the call progresses through the fabric toward its + destination. No synchronization is needed between switches to + establish an end-to-end connection. + + The Connect Service Center maintains a Connection Table containing + information for all connections currently active on the switch's + local ports. + + Connections are removed from the Connection Table when one of the + endstations is moved to a new switch (Section 4.1.2) or when the + Topology Link State server (Section 4.2.3) notifies the Connect + Service Center that a network link has failed. Otherwise, + connections are not automatically aged out or removed from the + Connection Table until a certain percentage threshold (HiMark) of + table capacity is reached and resources are needed. At that point, + some number of connections (typically 100) are aged out and removed + at one time. + +4.5.1 Local Server + + If the destination endstation resides on the local switch, the + Connect Local server establishes a connection between the source and + destination ports. Note that if the source and destination both + reside on the same physical port, a filter connection is established + by calling the Filter Service Center (Section 4.6). + +4.5.2 Link State Server + + The Connect Link State server is called if the destination endstation + of the proposed connection does not reside on the local switch. + + The server executes a call to the Path Link State server (Section + 4.7.1) which returns up to three "best" paths of equal cost from the + local switch to the destination switch. If more than one path is + returned, the server chooses a path that provides the best load + balancing of user traffic across the fabric. + + + + + + + + + +Ruffen, et al. Informational [Page 25] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.5.3 Directory Server + + The Connect Directory server is called if the Connect Link State + server is unable to provide a path for some reason. + + The server examines the local directory to determine on which switch + the destination endstation resides. If the port of access to the + destination switch is known, then a connection is established using + that port as the outport of the connection. + +4.6 Filter Service Center + + The Filter Service Center is responsible for establishing filtered + connections. This service center is called by the Connect Local + server (Section 4.5.1) if the source and destination endstations + reside on the same physical port, and by the Policy Service Center + (Section 4.4) if the VLAN of either the source or destination is + indeterminate. + + A filter connection is programmed in the switch hardware with no + specified outport. That is, the connection is programmed to discard + any traffic for that SA/DA pair. + +4.7 Path Service Center + + The Path Service Center is responsible for determining the path from + a source to a destination. + +4.7.1 Link State Server + + The Path Link State server is called by the Connect Link State server + (Section 4.5.2) to return up to three best paths of equal cost + between a source and destination pair of endstations. These best + paths are calculated by the Topology Link State server (Section + 4.2.3). + + The Path Link State server is also called by the Connect Service + Center to return a complete source-to-destination path consisting of + a list of individual switch port names. A switch port name consists + of the switch base MAC address and a port instance relative to the + switch. + + + + + + + + + + +Ruffen, et al. Informational [Page 26] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +4.7.2 Spanning Tree Server + + The Path Spanning Tree server is called by any server needing to + forward an undirected message out over the switch flood path. The + server returns a port mask indicating which local ports are currently + enabled as outports of the switch flood path. The switch flood path + is calculated by the Topology Spanning Tree server (Section 4.2.2). + +4.8 Flood Service Center + + If the Resolve Service Center (Section 4.3) is unable to resolve the + destination address of a packet, it invokes the Flood Service Center + to broadcast the unresolved packet. + +4.8.1 Tag-Based Flood Server + + The Tag-Based Flood server encapsulates the unresolved packet into an + Interswitch Tag-Based Flood message (Section 6.6), along with a list + of Virtual LAN identifiers specifying those VLANs to which the source + endstation belongs. The message is then sent out over the switch + flood path to all other switches in the fabric. + + When a switch receives an Interswitch Tag-Based Flood message, it + examines the encapsulated header to determine the VLAN(s) to which + the packet should be sent. If any of the switch's local access ports + belong to one or more of the specified VLANs, the switch strips off + the tag-based header and forwards the original packet out the + appropriate access port(s). + + The switch also forwards the entire encapsulated packet along the + switch flood path to its downstream neighboring switches, if any. + +5. Monitoring Call Connections + + The SecureFast VLAN product permits monitoring of user traffic moving + between two endstations by establishing a call tap on the connection + between the two stations. Traffic can be monitored in one or both + directions along the connection path. + +5.1 Definitions + + In addition to the terms defined in Section 1.2, the following terms + are used in this description of the call tap process. + + + + + + + + +Ruffen, et al. Informational [Page 27] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Originating Switch + + The originating switch is the switch that requests the call tap. + Any switch along a call connection path may request a tap on that + call connection. + + Probe + + The tap probe is the device to receive a copy of the call + connection data. The probe is attached to a port on the probe + switch. + + Probe Switch + + The probe switch (also known as the terminating switch) is the + switch to which the probe is attached. The probe switch can be + anywhere in the topology. + +5.2 Tapping a Connection + + A request to tap a call connection between two endstations can + originate on any switch along the call connection path -- the ingress + switch, the egress switch, or any of the intermediate switches. The + call connection must have already been established before a call tap + request can be issued. The probe device can be attached to any + switch in the topology. + +5.2.1 Types of Tap Connections + + A call tap is enabled by setting up an auxiliary tap connection + associated with the call being monitored. Since the tap must + originate on a switch somewhere along the call connection path, the + tap connection path will pass through one or more of the switches + along the call path. However, since the probe switch can be anywhere + in the switch fabric, the tap path and the call path may diverge at + some point. + + Therefore, on each switch along the tap path, the tap connection is + established in one of three ways: + + - The existing call connection is used with no modification. + + When both the call path and tap path pass through the switch, + and the inport and outports of both connections are identical, + the switch uses the existing call connection to route the tap. + + - The existing call connection is modified. + + + + +Ruffen, et al. Informational [Page 28] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + When both the call path and tap path pass through the switch, + but the call path outport is different from the tap path + outport, the switch enables an extra outport in either one or + both directions of the call connection, depending on the + direction of the tap. This happens under two conditions. + + - If the switch is also the probe switch, an extra outport is + enabled to the probe. + + - If the switch is the point at which the call path and the tap path + diverge, an extra outport is enabled to the downstream neighbor + on that leg of the switch flood path on which the probe switch + is located. + + - A new connection is established. + + If the call path does not pass through the switch (because the + tap path has diverged from the call path), a completely new + connection is established for the tap. + +5.2.2 Locating the Probe and Establishing the Tap Connection + + To establish a call tap, the originating switch formats an + Interswitch Tap request message (Section 6.7) and sends it out over + the switch flood path to all other switches in the topology. + + Note: + + If the originating switch is also the probe switch, no + Interswitch Tap request message is necessary. + + As the Interswitch Tap request message travels out along the switch + flood path, each switch receiving the message checks to see if it is + the probe switch and does the following: + + - If the switch is the probe switch, it establishes the tap + connection by either setting up a new connection or modifying the + call connection, as appropriate (see Section 5.2.1). It then + reformats the Tap request message to be a Tap response message + with a status indicating that the probe has been found, and sends + the message back to its upstream neighbor. + + - If the switch is not the probe switch, it forwards the Tap request + message to all its downstream neighbors (if any). + + - If the switch is not the probe switch and has no downstream + neighbors, it reformats the Tap request message to be a Tap + response message with a status indicating that the probe is not + + + +Ruffen, et al. Informational [Page 29] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + located on that leg of the switch flood path. It then sends the + response message back to its upstream neighbor. + + When a switch forwards an Interswitch Tap request message to its + downstream neighbors, it keeps track of the number of requests it + has sent out. + + - If a response is received with a status indicating that the probe + switch is located somewhere downstream, the switch establishes the + appropriate type of tap connection (see Section 5.2.1). It then + formats a Tap response message with a status indicating that the + probe has been found and passes the message to its upstream + neighbor. + + - If no responses are received with a status indicating that the + probe switch is located downstream, the switch formats a Tap + response message with a status indicating that the probe has not + been found and passes the message to its upstream neighbor. + +5.2.3 Status Field + + The status field of the Interswitch Tap request/response message + contains information about the state of the tap. Some of these + status values are transient and are merely used to track the progress + of the tap request. Other status values are stored in the tap table + of each switch along the tap path for use when the tap is torn down. + The possible status values are as follows: + + - StatusUnassigned. This is the initial status of the Interswitch + Tap request message. + + - OutportDecisionUnknown. The tap request is still moving + downstream along the switch flood path. The probe switch had not + yet been found. + + - ProbeNotFound. The probe switch is not located on this leg of the + switch flood path. + + - DisableOutport. The probe switch is located on this leg of the + switch flood path, and the switch has had to either modify the + call connection or establish a new connection to implement the tap + (see Section 5.2.1). When the tap is torn down, the switch will + have to disable any additional outports that have been enabled for + the tap. + + - KeepOutport. The probe switch is located on this leg of the + switch flood path, and the switch was able to route the tap over + the existing call path (see Section 5.2.1). Any ports used for + + + +Ruffen, et al. Informational [Page 30] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + the tap will remain enabled when the tap is torn down. + +5.3 Untapping a Connection + + A request to untap a call connection must be issued on the tap + originating switch -- that is, the same switch that issued the tap + request. + + To untap a call connection, the originating switch sends an + Interswitch Untap request message (Section 6.7) out over the switch + flood path to all other switches in the topology. The message is + sent over the switch flood path, rather than the tap connection path, + to ensure that all switches that know of the tap are properly + notified, even if the switch topology has changed since the tap was + established. + + When a switch receives an Interswitch Untap request message, it + checks to see if it is handling a tap for the specified call + connection. If so, the switch disables the tap connection, as + follows: + + - If a new connection was added for the tap, the connection is + deleted from the connection table. + + - If additional outports were enabled on the call connection, they + are disabled. + + The switch then forwards the Interswitch Untap request message to its + downstream neighbor (if any). If the switch has no downstream + neighbors, it formats an untap response and sends the message back to + its upstream neighbor. + + When a switch forwards an Interswitch Untap request message to its + downstream neighbors, it keeps track of the number of requests it has + sent out and does not respond back to its upstream neighbor until all + untap requests have been responded to. Once all responses have been + received, the switch handles any final cleanup for the tap and then + sends a single Interswitch Untap response message to its upstream + neighbor. + + + + + + + + + + + + +Ruffen, et al. Informational [Page 31] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6. Interswitch Message Protocol (ISMP) + + The InterSwitch Message protocol (ISMP) provides a consistent method + of encapsulating and transmitting messages exchanged between switches + to create and maintain the databases and provide other control + services and functionality required by the SFVLAN product. + +6.1 General Packet Structure + + ISMP packets are of variable length and have the following general + structure: + + - Frame header + - ISMP packet header + - ISMP message body + + Each of these packet segments is discussed separately in the + following subsections. + +6.1.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 | | + + + + : : + + + 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. Except where otherwise noted, this field + + + + + + +Ruffen, et al. Informational [Page 32] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + contains the multicast address of the control channel over which + all switches in the fabric receive ISMP packets -- a value of 01- + 00-1D-00-00-00. + + Source address + + Except where otherwise noted, 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. Except where otherwise noted, the type field of ISMP + packets contains the value 0x81FD. + +6.1.2 ISMP Packet Header + + There are two versions of the ISMP packet header in use by the + SecureFast VLAN product. + +6.1.2.1 Version 2 + + The version 2 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 (Section 6.1.1). + + + + + + + + + +Ruffen, et al. Informational [Page 33] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + 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. The following table + lists each ISMP message, along with its message type and the + section within this document that describes the message in detail: + + Message Name Type Description + + Interswitch Link State message 3 See note below + Interswitch BPDU message 4 Section 6.2 + Interswitch Remote Blocking message 4 Section 6.3 + Interswitch Resolve message 5 Section 6.4 + Interswitch New User message 5 Section 6.5 + Interswitch Tag-Based Flood message 7 Section 6.6 + Interswitch Tap/Untap message 8 Section 6.7 + + Note: + + The Link State messages used by the VLS Protocol are not + described in this document. For a detailed description of + these messages, see [IDvlsp]. + + Sequence number + + This 2-octet field contains an internally generated sequence + number used by the various protocol handlers for internal + synchronization of messages. + +6.1.2.2 Version 3 + + The version 3 ISMP packet header is used only by the Interswitch + Keepalive message. That message is not described in this document. + For a detailed description of the version 3 ISMP packet header, see + [IDhello]. + + + + + + + + + + +Ruffen, et al. Informational [Page 34] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6.1.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. + + See the following sections for the exact format of each message type. + +6.2 Interswitch BPDU Message + + The Interswitch 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 (type 4) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Message flags | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 28 | | + : BPDU packet : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + Version + + This 2-octet field contains the version number of the message + type. This document describes ISMP message type 4, version 1. + + + + + + + + + + + +Ruffen, et al. Informational [Page 35] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Opcode + + This 2-octet field contains the operation type of the message. For + an Interswitch BPDU message, the value should be 1. + + 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 Bridge + Protocol Data Unit. See [IEEE] for a detailed description of the + contents of this field. + +6.3 Interswitch Remote Blocking Message + + The 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 (type 4) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 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. + + Version + + This 2-octet field contains the version number of the message + type. This document describes ISMP message type 4, version 1. + + + + + +Ruffen, et al. Informational [Page 36] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Opcode + + This 2-octet field contains the operation type of the message. + Valid values are as follows: + + 2 Enable/disable remote blocking + 3 Acknowledge previously received 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 should be sent over the link. A value + of 0 indicates remote blocking is off. This flag is irrelevant + if the operation type (Opcode) of the message has a value of 3. + +6.4 Interswitch Resolve Message + + There are two versions of the Interswitch Resolve message used by the + SecureFast VLAN product. + +6.4.1 Prior to Version 1.8 + + The Interswitch Resolve message used by SFVLAN prior to version 1.8 + consists of a variable number of octets, as shown below: + + + + + + + + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 37] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + 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 (type 5) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Status | Call Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | | + + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + + 36 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40 | | + + Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 44 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 48 | | + : Known destination address : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + n | Count | | + +-+-+-+-+-+-+-+-+ + + n+4 | Resolve list | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + n = 46 + length of known address TLV + + In the following description of the message fields, the term + "originating" switch refers to the switch that issued the original + Interswitch Resolve request. The term "owner" switch refers to that + switch to which the destination endstation is attached. And the term + "responding" switch refers to either the "owner" switch or to a + switch at the end of the switch flood path that does not own the + endstation but issues an Interswitch Resolve response because it has + no downstream neighbors. + + + + + + + + +Ruffen, et al. Informational [Page 38] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + With the exception of the resolve list (which has a different size + and format in a Resolve response message), all fields of an + Interswitch Resolve message are allocated by the originating switch, + and unless otherwise noted below, are written by the originating + switch. + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + Version + + This 2-octet field contains the version number of the message + type. This document describes ISMP message type 5, version 1. + + Opcode + + This 2-octet field contains the operation code of the message. + Valid values are as follows: + + 1 The message is a Resolve request. + 2 The message is a Resolve response. + 3 (unused in Resolve messages) + 4 (unused in Resolve messages) + + The originating switch writes a value of 1 to this field, while + the responding switch writes a value of 2. + + Status + + This 2-octet field contains the status of a Resolve response + message. Valid values are as follows: + + 0 The Resolve request succeeded (ResolveAck). + 1 (unused) + 2 The Resolve request failed (Unknown). + + This field is written by the responding switch. + + Call tag + + This 2-octet field contains the call tag of the endstation packet + for which this Resolve request is issued. The call tag is a 16- + bit value (generated by the originating switch) that uniquely + identifies the packet. + + + + + +Ruffen, et al. Informational [Page 39] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Source MAC of packet + + This 6-octet field contains the physical (MAC) address of the + endstation that originated the packet identified by the call tag. + + Originating switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch that issued the original Resolve request. + + Owner switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch to which the destination endstation is attached -- that is, + the switch that was able to resolve the requested addressing + information. This field is written by the owner switch. + + If the status of the response is Unknown, this field is + irrelevant. + + Known destination address + + This variable-length field contains the known attribute of the + destination endstation address. This address is stored in + Tag/Length/Value format. (See Section 2.3.) + + Count + + This 1-octet field contains the number of address attributes + requested or returned. This is the number of items in the resolve + list. + + Resolve list + + This variable-length field contains a list of the address + attributes either requested by the originating switch or returned + by the owner switch. Note that in a Resolve request message, this + list contains only the tags of the requested address attributes + (see Section 2.3). On the other hand, a Resolve response message + with a status of ResolveAck contains the full TLV of each resolved + address attribute. The number of entries in the list is specified + in the count field. + + In an Interswitch Resolve response message, this field is + irrelevant if the status of the response is Unknown. + + + + + + +Ruffen, et al. Informational [Page 40] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6.4.2 Version 1.8 + + The Interswitch Resolve message used by SFVLAN version 1.8 consists + of a variable number of octets, as shown below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 41] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + 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 (type 5) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Status | Call Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | | + + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + + 36 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40 | | + + Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 44 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 48 | | + : Known destination address : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + n | Count | | + +-+-+-+-+-+-+-+-+ + + n+4 | Resolve list | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + n1 | | + + Actual dest switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Downlink chassis MAC + + n1+8 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +n1+12 | | + + Actual chassis MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +n1+20 | | + + Domain name + + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + n = 46 + length of known address TLV + n1 = n + length of Resolve list + + + +Ruffen, et al. Informational [Page 42] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + In the following description of the message fields, the term + "originating" switch refers to the switch that issued the original + Interswitch Resolve request. The term "owner" switch refers to that + switch to which the destination endstation is attached. And the term + "responding" switch refers to either the "owner" switch or to a + switch at the end of the switch flood path that does not own the + endstation but issues an Interswitch Resolve response because it has + no downstream neighbors. + + With the exception of the resolve list (which has a different size + and format in a Resolve response message) and the four fields + following the resolve list, all fields of an Interswitch Resolve + message are allocated by the originating switch, and unless otherwise + noted below, are written by the originating switch. + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + Version + + This 2-octet field contains the version number of the message + type. This section describes version 3 of the Interswitch Resolve + message. + + Opcode + + This 2-octet field contains the operation code of the message. + Valid values are as follows: + + 1 The message is a Resolve request. + 2 The message is a Resolve response. + 3 (unused in Resolve messages) + 4 (unused in Resolve messages) + + The originating switch writes a value of 1 to this field, while + the responding switch writes a value of 2. + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 43] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Status + + This 2-octet field contains the status of a Resolve response + message. Valid values are as follows: + + 0 The Resolve request succeeded (ResolveAck). + 1 (unused) + 2 The Resolve request failed (Unknown). + + This field is written by the responding switch. + + Call tag + + This 2-octet field contains the call tag of the endstation packet + for which this Resolve request is issued. The call tag is a 16- + bit value (generated by the originating switch) that uniquely + identifies the packet. + + Source MAC of packet + + This 6-octet field contains the physical (MAC) address of the + endstation that originated the packet identified by the call tag. + + Originating switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch that issued the original Resolve request. + + Owner switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch to which the destination endstation is attached -- that is, + the switch that was able to resolve the requested addressing + information. This field is written by the owner switch. + + If the status of the response is Unknown, this field is + irrelevant. + + Known destination address + + This variable-length field contains the known attribute of the + destination endstation address. This address is stored in + Tag/Length/Value format. + + + + + + + + +Ruffen, et al. Informational [Page 44] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Count + + This 1-octet field contains the number of address attributes + requested or returned. This is the number of items in the resolve + list. + + Resolve list + + This variable-length field contains a list of the address + attributes either requested by the originating switch or returned + by the owner switch. Note that in a Resolve request message, this + list contains only the tags of the requested address attributes. + On the other hand, a Resolve response message with a status of + ResolveAck contains the full TLV of each resolved address + attribute. The number of entries in the list is specified in the + count field. + + In an Interswitch Resolve response message, this field is + irrelevant if the status of the response is Unknown. + + Actual destination switch MAC + + This 6-octet field contains the physical (MAC) address of the + actual switch within the chassis to which the endstation is + attached. If the status of the response is Unknown, this field is + irrelevant. + + Downlink chassis MAC + + This 6-octet field contains the physical (MAC) address of the + downlink chassis. If the status of the response is Unknown, this + field is irrelevant. + + Actual chassis MAC + + This 6-octet field contains the physical (MAC) address of the + uplink chassis. If the status of the response is Unknown, this + field is irrelevant. + + Domain name + + This 16-octet field contains the ASCII name of the domain. If the + status of the response is Unknown, this field is irrelevant. + + + + + + + + +Ruffen, et al. Informational [Page 45] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6.5 Interswitch New User Message + + The Interswitch New User 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 (type 5) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Status | Call Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | | + + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + + 36 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40 | | + + Previous owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 44 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 48 | : + : MAC address of new user + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 70 | Count | | + +-+-+-+-+-+-+-+-+ + + 74 | Resolve list | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + In the following description of the message fields, the term + "originating" switch refers to the switch that issued the original + Interswitch New User request. The term "previous owner" switch + refers to that switch to which the endstation was previously + attached. And the term "responding" switch refers to either the + "previous owner" switch or to a switch at the end of the switch flood + path that did not own the endstation but issues an Interswitch New + User response because it has no downstream neighbors. + + + + + +Ruffen, et al. Informational [Page 46] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + With the exception of the resolve list, all fields of an Interswitch + New User message are allocated by the originating switch, and unless + otherwise noted below, are written by the originating switch. + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + Version + + This 2-octet field contains the version number of the message + type. This document describes ISMP message type 5, version 1. + + Opcode + + This 2-octet field contains the operation code of the message. + Valid values are as follows: + + 1 (unused in a New User message) + 2 (unused in a New User message) + 3 The message is a New User request. + 4 The message is a New User response. + + The originating switch writes a value of 3 to this field, while + the responding switch writes a value of 4. + + Status + + This 2-octet field contains the status of a New User response + message. Valid values are as follows: + + 0 VLAN resolution successful (NewUserAck) + 1 (unused) + 2 VLAN resolution unsuccessful (NewUserUnknown) + + This field is written by the responding switch. + + Call tag + + This 2-octet field contains the call tag of the endstation packet + for which this New User request is issued. The call tag is a 16- + bit value (generated by the originating switch) that uniquely + identifies the packet that caused the switch to identify the + endstation as a new user. + + + + + + +Ruffen, et al. Informational [Page 47] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Source MAC of packet + + This 6-octet field contains the physical (MAC) address of the + endstation that originated the packet identified by the call tag. + + Originating switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch that issued the original New User request. + + Previous owner switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch to which the endstation was previously attached -- that is, + the switch that was able to resolve the VLAN information. This + field is written by the previous owner switch. + + If the status of the response is Unknown, this field is + irrelevant. + + MAC address of new user + + This 24-octet field contains the physical (MAC) address of the new + user endstation, stored in Tag/Length/Value format. + + Count + + This 1-octet field contains the number of VLAN identifiers + returned. This is the number of items in the resolve list. This + field is written by the previous owner switch. + + If the status of the response is Unknown, this field and the + resolve list are irrelevant. + + Resolve list + + This variable-length field contains a list of the VLAN identifiers + of all static VLANs to which the endstation belongs, stored in + Tag/Length/Value format (see Section 2.3). The number of entries + in the list is specified in the count field. This list is written + by the previous owner switch. + + If the status of the response is Unknown, this field is + irrelevant. + + + + + + + +Ruffen, et al. Informational [Page 48] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6.6 Interswitch Tag-Based Flood Message + + There are two versions of the Interswitch Tag-Based Flood message + used by the SecureFast VLAN product. + +6.6.1 Prior to Version 1.8 + + The Interswitch Tag-Based Flood message used by SFVLAN prior to + version 1.8 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 (type 7) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Status | Call Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | | + + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32 | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + + 36 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40 | Count | | + +-+-+-+-+-+-+-+-+ + + 44 | VLAN list | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + n | | + + + + : Original packet : + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + n = 41 + length of VLAN list + + + + + + + + + +Ruffen, et al. Informational [Page 49] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + Version + + This 2-octet field contains the version number of the message + type. This document describes ISMP message type 7, version 1. + + Opcode + + This 2-octet field contains the operation code of the message. The + value here should be 1, indicating the message is a flood request. + + Status + + This 2-octet field is currently unused. It is reserved for future + use. + + Call tag + + This 2-octet field contains the call tag of the endstation packet + encapsulated within this tag-based flood message. The call tag is + a 16-bit value (generated by the originating switch) that uniquely + identifies the packet. + + Source MAC of packet + + This 6-octet field contains the physical (MAC) address of the + endstation that originated the packet identified by the call tag. + + Originating switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch that issued the original tag-based flooded message. + + Count + + This 1-octet field contains the number of VLAN identifiers + included in the VLAN list. + + VLAN list + + This variable-length field contains a list of the VLAN identifiers + of all VLANs to which the source endstation belongs. Each entry + in this list has the following format: + + + + +Ruffen, et al. Informational [Page 50] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value length | | + +-+-+-+-+-+-+-+-+ + + | VLAN identifier value | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The 1-octet value length field contains the length of the VLAN + identifier. VLAN identifiers can be from 1 to 16 characters long. + + Original packet + + This variable-length field contains the original packet as sent by + the source endstation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 51] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6.6.2 Version 1.8 + + The Interswitch Tag-Based Flood message used by SFVLAN version 1.8 + consists of a variable number of octets, as shown below: + + Note: + + SFVLAN version 1.8 also recognizes the Interswitch Tag-Based + Flood message as described in Section 6.6.1. + + 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 (type 7) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | VLAN identifier | Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Opcode | Status | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | Call tag | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC of packet + + 32 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 36 | | + + Originating switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40 | | Count | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 44 | | + : VLAN list : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + n | | + + + + : Original packet : + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + n = 41 + length of VLAN list + + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + + +Ruffen, et al. Informational [Page 52] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + - The frame header source address contains a value of 02-00-1D- + 00-xx-yy, where xx-yy is a value set by the VLAN Manager + application to tag the frame header with the VLAN identifier. + This value ranges from 2 to 4095. For example, a value of 100 + would be set as 00-64. + + - The frame header type field contains a value of 0x81FF. Note + that this differs from all other ISMP messages. + + VLAN identifier + + This 2-octet field contains the VLAN identifier of the packet + source. + + Version + + This 2-octet field contains the version number of the message + type. This section describes version 2 of the Interswitch Tag- + Based Flood message. + + Opcode + + This 2-octet field contains the operation code of the message. + Valid values here are as follows: + + 1 The message is a flood request. The original packet is + complete within this message. + + 2 The message is a fragmented flood request. The first portion + of the original packet is contained in this message. + + 3 The message is a fragmented flood request. The second portion + of the original packet is contained in this message. + + Status + + This 2-octet field is currently unused. It is reserved for future + use. + + Call tag + + This 2-octet field contains the call tag of the endstation packet + encapsulated within this tag-based flood message. The call tag is + a 16-bit value (generated by the originating switch) that uniquely + identifies the packet. + + + + + + +Ruffen, et al. Informational [Page 53] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Source MAC of packet + + This 6-octet field contains the physical (MAC) address of the + endstation that originated the packet identified by the call tag. + + Originating switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch that issued the original tag-based flooded message. + + Count + + This 1-octet field contains the number of VLAN identifiers + included in the VLAN list. + + VLAN list + + This variable-length field contains a list of the VLAN identifiers + of all VLANs to which the source endstation belongs. Each entry + in this list has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value length | | + +-+-+-+-+-+-+-+-+ + + | VLAN identifier value | + : : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The 1-octet value length field contains the length of the VLAN + identifier. VLAN identifiers can be from 1 to 16 characters long. + + Original packet + + This variable-length field contains the original packet as sent by + the source endstation. + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 54] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +6.7 Interswitch Tap/Untap Message + + The Interswitch Tap/Untap 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 (type 8) : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20 | Version | Opcode | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24 | Status | Error code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28 | Header type | Header length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32 | Direction | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Probe switch MAC + + 36 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40 | Probe port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 44 | | + + + + 48 | (Reserved) | + + + + 52 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 56 | | + + + + | Header | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Frame header/ISMP packet header + + This 20-octet field contains the frame header and the ISMP packet + header. + + Version + + This 2-octet field contains the version number of the message + type. This document describes ISMP message type 8, version 1. + + + +Ruffen, et al. Informational [Page 55] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Opcode + + tet field contains the operation type of the message. ues are as + follows: + + 1 The message is a Tap request. + 2 The message is a Tap response. + 3 The message is an Untap request. + 4 The message is an Untap response. + + Status + + This 2-octet field contains the current status of the tap request. + Valid values are as follows: + + 1 Switch must disable outport on untap. (DisableOutport) + 2 Switch must keep outports on untap. (KeepOutport) + 3 Probe not found this leg of spanning tree. (ProbeNotFound) + 4 Still searching for probe switch. (OutportDecisionUnknown) + 5 Unassigned. (StatusUnassigned) + 6 (reserved) + 7 (reserved) + 8 (reserved) + 9 (reserved) + + See Section 5.2.3 for details on the use of this field. + + Error code + + This 2-octet field contains the response message error code of the + requested operation. Valid values are as follows: + + 1 Operation successful. (NoError) + 2 No response heard from downstream neighbor. (Timeout) + 3 Port does not exist on probe switch. (BadPort) + 4 Message invalid. (InvalidMessage) + 5 Version number invalid. (IncompatibleVersions) + + Header type + + This 2-octet field contains the type of information contained in + the header field. Currently, valid values are as follows: + + 1 (reserved) 2 Header contains destination and source endstation + MAC addresses. + + + + + + +Ruffen, et al. Informational [Page 56] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + Header length + + This 2-octet field contains the length of the header field. + Currently, this field always contains a value of 12. + + Direction + + This 2-octet field contains a value indicating the type of tap. + Valid values are as follows: + + 1 (reserved) + 2 Tap is bi-directional and data should be captured flowing in + either direction over the connection. + 3 Tap is uni-directional and data should be captured only when it + flows from the source to the destination. + + Probe switch MAC + + This 6-octet field contains the physical (MAC) address of the + switch to which the probe is attached. + + Probe port + + This 4-octet field contains the logical port number (on the probe + switch) to which the probe is attached. + + Reserved + + These 12 octets are reserved. + + Header + + This variable-length field contains the header that identifies the + connection being tapped. The length of the header is stored in + the length field. + + Currently, this field is 12 octets long and contains the 6-octet + physical address of the connection's destination endstation, + followed by the 6-octet physical address of the connection's + source endstation, as shown below: + + + + + + + + + + + +Ruffen, et al. Informational [Page 57] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Destination MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC address + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +7. Security Considerations + + Requested call connections are established or denied based on the + VLAN policy of the source and destination addresses specified within + the packet. Section 4.4.1 discusses this process in detail. + + +8. References + + [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, + RFC 1700, October 1994. + + [IEEE] "IEEE Standard 802.1d -- 1990" + + [IDvlsp] Kane, L., "Cabletron's VLS Protocol Specification", RFC + 2642, August 1999. + + [IDhello] Hamilton, D. and D. Ruffen, "Cabletron's VlanHello + Protocol Specification", RFC 2641, August 1999. + + + + + + + + + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 58] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +9. Authors' Addresses + + Dave Ruffen + Cabletron Systems, Inc. + Post Office Box 5005 + Rochester, NH 03866-5005 + + Phone: (603) 332-9400 + EMail: ruffen@ctron.com + + + Ted Len + Cabletron Systems, Inc. + Post Office Box 5005 + Rochester, NH 03866-5005 + + Phone: (603) 332-9400 + EMail: len@ctron.com + + + Judy Yanacek + Cabletron Systems, Inc. + Post Office Box 5005 + Rochester, NH 03866-5005 + + Phone: (603) 332-9400 + EMail: jyanacek@ctron.com + + + + + + + + + + + + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 59] + +RFC 2643 Cabletron's SecureFast VLAN Operational Model August 1999 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ruffen, et al. Informational [Page 60] + -- cgit v1.2.3