doc: Add RFC documents

1 files changed, 3363 insertions, 0 deletions

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]
+