RFC 2643
Cabletron's SecureFast VLAN Operational Model
Pages: 60
Informational
Informational
Part 2 of 2 – Pages 27 to 60
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.
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.
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
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
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.
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
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).
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].
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.
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.
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:
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.
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.
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.
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:
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
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.
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.
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.
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.
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.
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.
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
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:
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.
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.
- 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.
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.
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.
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.
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:
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.
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
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.