Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2643

Cabletron's SecureFast VLAN Operational Model

Pages: 60
Informational
Part 2 of 2 – Pages 27 to 60
First   Prev   None

Top   ToC   RFC2643 - Page 27   prevText

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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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   ToC   RFC2643 - 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.