tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2643

 
 
 

Cabletron's SecureFast VLAN Operational Model

Part 2 of 2, p. 27 to 60
Prev RFC Part

 


prevText      Top      Up      ToC       Page 27 
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.

Top      Up      ToC       Page 28 
   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.

Top      Up      ToC       Page 29 
         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

Top      Up      ToC       Page 30 
      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

Top      Up      ToC       Page 31 
      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.

Top      Up      ToC       Page 32 
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

Top      Up      ToC       Page 33 
      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).

Top      Up      ToC       Page 34 
   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].

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
   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:

Top      Up      ToC       Page 38 
        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.

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
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:

Top      Up      ToC       Page 42 
       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

Top      Up      ToC       Page 43 
   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.

Top      Up      ToC       Page 44 
   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.

Top      Up      ToC       Page 45 
   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.

Top      Up      ToC       Page 46 
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.

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
   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.

Top      Up      ToC       Page 49 
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

Top      Up      ToC       Page 50 
   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:

Top      Up      ToC       Page 51 
       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.

Top      Up      ToC       Page 52 
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.

Top      Up      ToC       Page 53 
      -  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.

Top      Up      ToC       Page 54 
   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.

Top      Up      ToC       Page 55 
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.

Top      Up      ToC       Page 56 
   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.

Top      Up      ToC       Page 57 
   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:

Top      Up      ToC       Page 58 
       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.

Top      Up      ToC       Page 59 
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

Top      Up      ToC       Page 60 
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.