doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc2641.txt b/doc/rfc/rfc2641.txt
new file mode 100644
index 0000000..47bc87f
--- /dev/null
+++ b/doc/rfc/rfc2641.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                           D. Hamilton
+Request for Comments: 2641                                        D. Ruffen
+Category: Informational                      Cabletron Systems Incorporated
+                                                                August 1999
+
+
+              Cabletron's VlanHello Protocol Specification
+                               Version 4
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The VlanHello protocol is part of the InterSwitch Message Protocol
+   (ISMP) which provides interswitch communication between switches
+   running Cabletron's SecureFast VLAN (SFVLAN) product.  Switches use
+   the VlanHello protocol to discover their neighboring switches and
+   establish the topology of the switch fabric.
+
+Table of Contents
+
+   1. Introduction......................................  2
+      1.1 Data Conventions..............................  2
+   2. VlanHello Protocol Operational Overview...........  2
+      2.1 Neighbor Discovery............................  2
+      2.2 Port States...................................  3
+      2.3 Topology Events...............................  5
+      2.4 Timers........................................  9
+   3. InterSwitch Message Protocol......................  9
+      3.1 Frame Header.................................. 10
+      3.2 ISMP Packet Header............................ 11
+      3.3 ISMP Message Body............................. 12
+   4. Interswitch Keepalive Message..................... 13
+   5. Security Considerations........................... 16
+   6. References........................................ 16
+   7. Authors' Addresses................................ 16
+   8. Full Copyright Statement.......................... 17
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 1]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+1. Introduction
+
+   This memo is being distributed to members of the Internet community
+   in order to solicit reactions to the proposals contained herein.
+   While the specification discussed here may not be directly relevant
+   to the research problems of the Internet, it may be of interest to
+   researchers and implementers.
+
+1.1 Data Conventions
+
+   The methods used in this memo to describe and picture data adhere to
+   the standards of Internet Protocol documentation [RFC1700], in
+   particular:
+
+      The convention in the documentation of Internet Protocols is to
+      express numbers in decimal and to picture data in "big-endian"
+      order.  That is, fields are described left to right, with the most
+      significant octet on the left and the least significant octet on
+      the right.
+
+      The order of transmission of the header and data described in this
+      document is resolved to the octet level.  Whenever a diagram shows
+      a group of octets, the order of transmission of those octets is
+      the normal order in which they are read in English.
+
+      Whenever an octet represents a numeric quantity the left most bit
+      in the diagram is the high order or most significant bit.  That
+      is, the bit labeled 0 is the most significant bit.
+
+      Similarly, whenever a multi-octet field represents a numeric
+      quantity the left most bit of the whole field is the most
+      significant bit.  When a multi-octet quantity is transmitted the
+      most significant octet is transmitted first.
+
+2. VlanHello Protocol Operational Overview
+
+   Switches use the VlanHello protocol to detect their neighboring
+   switches and establish the topology of the switch fabric.
+
+2.1 Neighbor Discovery
+
+   At initialization, each switch sends an Interswitch Keepalive message
+   out all local ports except those which have been preconfigured such
+   that they cannot be Network ports (see Section 2.2).  Then, as each
+   switch discovers its neighboring switches via incoming Interswitch
+   Keepalive messages, it notifies its local topology services (see
+   Section 2.3), which then build the topology tables for the switching
+   fabric.
+
+
+
+Hamilton & Ruffen            Informational                      [Page 2]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Each switch continues to send Interswitch Keepalive messages at
+   regular intervals (currently 5 seconds).  If a switch has not heard
+   from one of its neighbors for some predetermined interval (see
+   Section 2.4), notification is sent to all interested services and the
+   neighboring switch is removed from the topology table.
+
+   Interswitch Keepalive messages are described in Section 4.
+
+2.2 Port States
+
+   Each port on a switch can be in one of several different states.
+   These states are listed below.  Figure 1 shows how the port state
+   changes within the VlanHello protocol.
+
+   o  Unknown.  This is the default state of all ports at
+      initialization.
+
+   o  Network.  A port is deemed a Network port when the switch has
+      received an Interswitch Keepalive message over the port from one
+      of its neighbor switches.  A transition to this state triggers a
+      Neighbor Found event, notifying the local topology servers that
+      the interface is functioning and a 2-way conversation has been
+      established with the neighbor.
+
+      When the last switch is lost on a Network port, the state of the
+      switch reverts to either Network Only (see next state) or to
+      Unknown, and a Neighbor Lost event is triggered, notifying the
+      local topology servers that the interface is no longer
+      operational.
+
+   o  Network Only.  Certain types of port interfaces are incapable of
+      accessing user endstations and can only be used to access other
+      switches.  Such ports are deemed Network Only ports.  If the last
+      switch is lost from a port that has already been deemed a Network
+      port, the VlanHello protocol checks the condition of the port
+      interface.  If it is the type of interface that can only be used
+      to access other switches, the state of the port is set to Network
+      Only.  Otherwise, it reverts to Unknown.
+
+   o  Standby.  A port is deemed a Standby port under the following
+      conditions:
+
+
+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 3]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+      o  The neighbor switch on the port has a higher level of
+         functionality and it has determined that the local switch is
+         incompatible with that functionality.  In this circumstance,
+         the MAC entry for the local switch in the Interswitch Keepalive
+         message received from the neighbor contains an assigned status
+         of Incompatible.
+
+      o  The list of MAC entries in the Interswitch Keepalive message
+         received from the neighbor switch does not contain an entry for
+         the local switch.  In this circumstance, the local switch
+         assumes that communication with its neighbor will be one-way
+         only.
+
+      The VlanHello protocol continues to listen for Interswitch
+      Keepalive messages on a Standby port, but does not transmit any
+      Interswitch Keepalive messages over the port.  If a message is
+      received that removes the condition under which the port state was
+      set to Standby, the state of the port is set to Network.
+
+   o  Going to Access.  When any packet other than an Interswitch
+      Keepalive message is received over an Unknown port, the state of
+      the port is changed to Going to Access and a timer is activated.
+      If the timer expires without an Interswitch Keepalive message
+      being received over the port, the port state changes to Access.
+
+   o  Access.  A port is deemed an Access port when any packet other
+      than an Interswitch Keepalive message has been received over the
+      port and the Going to Access timer has expired.  A port can also
+      be administratively designated an Access "control" port, meaning
+      the port is to remain an Access port, regardless of the type of
+      messages that are received on it.  Interswitch Keepalive messages
+      are not sent over Access control ports.
+
+   Three other types of ports are recognized:  the host management port,
+   host data port, and host control port. These ports are designated at
+   initialization and are used to access the host CPU.  Interswitch
+   Keepalive messages are not sent over these ports.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 4]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+                                 Packet in
+                                     |
+                                     V
+                                +---------+
+                Packet in       | Unknown |
+                    |           +---------+
+        G-A         V                |
+       Timer  +----------+   no      V
+        exp   | Going to |<------[KA msg?]           Packet in
+       <------|  Access  |           |                   |
+       |      +----------+       yes |                   V
+       V             |               V     yes      +---------+
+   +--------+        V            [1-way?]------+-->| Standby |
+   | Access |    [KA msg?]           |          ^   +---------+
+   +--------+        |               | no       |        |
+                     |               V       no |        V
+                 yes |         [compatible?]----+    [KA msg?]
+                     |               |                   |
+                     |               | yes               | yes
+                     |               V                   V
+                     V          +---------+           [1-way?]
+                     +--------->| Network |<--+          |
+                                +---------+   ^          | no
+                                     |        | yes      V
+                           lost last |        +<----[compatible?]
+                            neighbor |
+                                     V
+                                 [network]
+                                 [ only? ]
+                                     |
+         +--------------+     yes    |    no      +---------+
+         | Network Only |<-----------+----------->| Unknown |
+         +--------------+                         +---------+
+
+
+                     Figure 1:  Port State Machine
+
+2.3 Topology Events
+
+   When the VlanHello protocol discovers new information about the
+   status of one of its network ports, it notifies its local topology
+   service center so that the service center can build or modify the
+   topology tables for the switch fabric.  This notification takes the
+   form of a system event, described in a structure known as a topology
+   relay structure.  These structures are linked in a first-in/first-out
+   (FIFO) queue and processed by the topology servers in the order in
+   which they were received.
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 5]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   A topology relay structure typically contains information from
+   Interswitch Keepalive messages received on the specified port, 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 |                             Event                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   04 |                       Delta options mask                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   08 |                      Current options mask                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   12 |                          Port number                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   16 |                                                               |
+      +                Port neighbor switch identifier                +
+      |                                                               |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |  Port neighbor IP address ... |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   28 | ... Port neighbor IP address  |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Neighbor chassis MAC addr   +
+   32 |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   36 |                   Neighbor chassis IP address                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   40 |                    Neighbor functional level                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   44 |                         Topology agent                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   48 |                           Next event                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Event
+
+         This 4-octet field contains the number of the event.
+         Valid values are as follows:
+
+            1   A new neighbor switch was discovered on the
+                specified port.
+            2   The neighbor switch has gained the feature(s)
+                specified in the Delta options mask.
+            3   The neighbor switch has lost the feature(s)
+                specified in the Delta options mask.
+            4   The neighbor switch has timed out and is presumed
+                down.
+            5   The specified port is down.
+
+
+
+Hamilton & Ruffen            Informational                      [Page 6]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+            6   The neighbor switch has been previously seen on a
+                different port.  The specified port is the
+                previous port.
+            7   The specified port is being reassigned to another
+                topology agent.  Event is generated by the current
+                (old) agent.
+            8   The port is looped -- that is, the Keepalive
+                message was generated by the receiving switch.
+            9   The port is crossed -- that is, a Keepalive message
+                was received on a port not owned by this topology
+                agent.
+            10  The neighbor switch's functional level has changed.
+            11  The neighbor switch is running an incompatible
+                version of the protocol.
+            12  Two-way communication with the neighbor switch has
+                been lost.
+            13  The neighbor switch's Keepalive message sequence
+                number has been reset, indicating the switch
+                itself has been reset.
+
+   Delta options mask
+
+      This 4-octet field contains a bit map specifying the feature(s)
+      gained or lost by the neighbor switch (events 2 and 3 only).
+      Valid values are as specified for the next field, Current options
+      mask.
+
+   Current options mask
+
+      This 4-octet field contains a bit map specifying the features of
+      the neighbor switch.  Bit assignments are as follows:
+
+         1       (unused)
+         2       The switch is a VLAN switch.
+         4       The switch has link state capability.
+         8       The switch has loop-free flood path capability.
+         16      The switch has resolve capability.
+         32      (unused)
+         64      The switch has tag-based flood capability.
+         128     The switch has tap capability.
+         256     The switch has message connection capability.
+         512     The switch has redundant access capability.
+         1024    The switch is an isolated switch.
+         4096    The switch is an uplink. (SFVLAN V1.8 only)
+         8192    The switch is an uplink to core. (SFVLAN V1.8 only)
+         16384   The port is an uplink port. (SFVLAN V1.8 only)
+         32768   The port is an uplink flood port. (SFVLAN V1.8 only)
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 7]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Port number
+
+      This 4-octet field contains the logical number of the local port
+      for which the event was generated.
+
+   Port neighbor switch identifier
+
+      This 10-octet field contains the internal identifier of the
+      neighbor switch discovered on the port.  The identifier consists
+      of the 6-octet physical (MAC) address of the neighbor switch,
+      followed by the 4-octet logical port number (local to the neighbor
+      switch) on which the neighbor was discovered.
+
+   Port neighbor IP address
+
+      This 4-octet field contains the Internet Protocol (IP) address of
+      the neighbor switch.
+
+   Neighbor chassis MAC address
+
+      This 6-octet field contains the physical (MAC) address of the
+      chassis of the neighbor switch.
+
+   Neighbor chassis IP address
+
+      This 4-octet field contains the Internet Protocol (IP) address of
+      the chassis of the neighbor switch.
+
+   Neighbor functional level
+
+      This 4-octet field contains the functional level of the neighbor
+      switch, as determined by the version level of the SecureFast VLAN
+      software under which this switch is operating.  Valid values are
+      as follows:
+
+      1  The switch is running a version of SFVLAN prior to Version 1.8.
+      2  The switch is running SFVLAN Version 1.8 or greater.
+
+   Topology agent
+
+      This 4-octet field contains a pointer to the topology agent that
+      generated the event.  The pointer here can reference any of the
+      topology agents that send Interswitch Keepalive messages -- that
+      is, any agent running the VlanHello protocol.
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 8]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Next event
+
+      This 4-octet field contains a pointer to the next event relay
+      structure in the list.
+
+2.4 Timers
+
+   The VlanHello protocol uses three timers.
+
+   o  Send Hello timer.  The Send Hello timer is used to control the
+      interval at which Interswitch Keepalive messages are sent.
+
+   o  Aging timer.  The Aging Timer is used to detect when communication
+      with a neighboring switch has been lost.
+
+   o  Going to Access timer.  The Going to Access timer is used to
+      synchronize the transition of a port state to Access and prevent a
+      port from being prematurely designation as an Access port during
+      network initialization.  If an Unknown port receives any packet
+      other than an Interswitch Keepalive message, the port state is set
+      to Going To Access.  If the switch receives an Interswitch
+      Keepalive message over that port before the timer expires, the
+      port state is changed to Network. Otherwise, when the timer
+      expires, the port state is changed to Access.
+
+3. InterSwitch Message Protocol
+
+   The VlanHello protocol operates as part of the InterSwitch Message
+   Protocol (ISMP) -- part of Cabletron's SecureFast VLAN (SFVLAN)
+   product, as described in [IDsfvlan].  ISMP provides a consistent
+   method of encapsulating and transmitting network control messages
+   exchanged between SFVLAN switches.
+
+   ISMP message packets are of variable length and have the following
+   general structure:
+
+   o  Frame header
+   o  ISMP packet header
+   o  ISMP message body
+
+
+
+
+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                      [Page 9]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+3.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.  The destination address fields of all ISMP
+      packets contain a value of 01-00-1D-00-00-00.
+
+   Source address
+
+      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.  The type field of ISMP packets contains the value 0x81FD.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 10]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+3.2 ISMP Packet Header
+
+   The ISMP packet header 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 /////////////////////////////////////////:
+      +//////// (14 octets)  /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   12 |///////////////////////////////|         ISMP Version          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   16 |       ISMP message type       |        Sequence number        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   20 |  Code length  |                                               |
+      +-+-+-+-+-+-+-+-+                                               +
+      |                        Authentication code                    |
+      :                                                               :
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      :                                                               :
+
+
+   Frame header
+
+      This 14-octet field contains the frame header.
+
+   ISMP Version
+
+      This 2-octet field contains the version number of the InterSwitch
+      Message Protocol to which this ISMP packet adheres.  The VlanHello
+      protocol uses ISMP Version 3.0.
+
+   ISMP message type
+
+      This 2-octet field contains a value indicating which type of ISMP
+      message is contained within the message body. VlanHello
+      Interswitch Keepalive messages have a message type of 2.
+
+   Sequence number
+
+      This 2-octet field contains an internally generated sequence
+      number used by the various protocol handlers for internal
+      synchronization of messages.
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 11]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Code length
+
+      This 1-octet field contains the number of octets in the
+      Authentication code field of the message.
+
+   Authentication code
+
+      This variable-length field contains an encoded value used for
+      authentication of the ISMP message.
+
+3.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.
+
+   The format of the VlanHello Interswitch Keepalive message is
+   described in the next section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 12]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+4. Interswitch Keepalive Message
+
+   The VlanHello Interswitch Keepalive 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                      :
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     n |            Version            |      Switch IP address ...    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   n+4 |    ... Switch IP address      |                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   n+8 |                                                               |
+       +                           Switch ID                           +
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  n+16 |                                                               |
+       +      Chassis MAC address      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                               |      Chassis IP address ...   |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  n+24 |   ... Chassis IP address      |          Switch type          |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  n+28 |                        Functional level                       |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  n+32 |                            Options                            |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  n+36 |        Base MAC count         |                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+  n+40 |                                                               |
+       :                        Base MAC entries                       :
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          n = 21 + length of the authentication code of the packet
+
+
+   Frame header/ISMP packet header
+
+      This variable-length field contains the frame header and the ISMP
+      packet header.
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 13]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Version
+
+      This 2-octet field contains the version number of the VlanHello
+      protocol to which this message adheres.  This document describes
+      VlanHello Version 4.
+
+   Switch IP address
+
+      This 4-octet field contains the Internet Protocol (IP) address of
+      the sending switch.
+
+   Switch ID
+
+      This 10-octet field contains the internal ISMP identifier of the
+      sending switch.  The identifier is generated by the sending switch
+      and consists of the 6-octet physical (MAC) address of the switch,
+      followed by a 4-octet value containing the logical port number
+      over which the switch sent the packet.
+
+   Chassis MAC
+
+      This 6-octet field contains the physical (MAC) address of the
+      chassis of the sending switch.
+
+   Chassis IP address
+
+      This 4-octet field contains the Internet Protocol (IP) address of
+      the switch chassis.
+
+   Switch type
+
+      This 2-octet field contains the type of the switch. Currently, the
+      only value recognized here is as follows:
+
+         2   The switch is an SFVLAN switch.
+
+   Functional level
+
+      This 4-octet field contains the functional level of the sending
+      switch, as determined by the version level of the SecureFast VLAN
+      software under which this switch is operating.  Valid values are
+      as follows:
+
+         1  The switch is running a version of SFVLAN prior to Version
+            1.8.
+         2  The switch is running SFVLAN Version 1.8 or greater.
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 14]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Options
+
+      This 4-octet field contains a bit map specifying the features of
+      the switch.  Bit assignments are as follows:
+
+         1       (unused)
+         2       The switch is a VLAN switch.
+         4       The switch has link state capability.
+         8       The switch has loop-free flood path capability.
+         16      The switch has resolve capability.
+         32      (unused)
+         64      The switch has tag-based flood capability.
+         128     The switch has tap capability.
+         256     The switch has message connection capability.
+         512     The switch has redundant access capability.
+         1024    The switch is an isolated switch.
+         4096    The switch is an uplink. (SFVLAN V1.8 only)
+         8192    The switch is an uplink to core. (SFVLAN V1.8 only)
+         16384   The port is an uplink port. (SFVLAN V1.8 only)
+         32768   The port is an uplink flood port. (SFVLAN V1.8 only)
+
+   Base MAC count
+
+      This 2-octet field contains the number of entries in the list of
+      Base MAC entries.
+
+   Base MAC entries
+
+      This variable-length field contains a list of entries for all
+      neighboring switches that the sending switch has previously
+      discovered on the port over which the message was sent. The number
+      of entries is found in the Base MAC count field.
+
+      Each MAC entry is 10 octets long, structured as follows:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +      Switch MAC address       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |  Assigned neighbor state ...  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  ... Assigned neighbor state  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 15]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+   Switch MAC address
+
+      This 6-octet field contains the base MAC address of the
+      neighboring switch.
+
+   Assigned neighbor state
+
+      This 4-octet field contains the assigned state of the neighboring
+      switch as perceived by the sending switch. Currently, the only
+      value valid here is 3, indicating a state of Network
+
+5. Security Considerations
+
+   Security concerns are not addressed in this document.
+
+6. References
+
+   [RFC1700]   Reynolds, J. and  J. Postel, "Assigned Numbers", STD 2,
+               RFC 1700, October 1994.
+
+   [IDsfvlan]  Ruffen, D., Len, T. and J. Yanacek, "Cabletron's
+               SecureFast VLAN Operational Model", RFC 2643, August
+               1999.
+
+   [IDvlsp]    Kane, L., "Cabletron's VLS Protocol Specification", RFC
+               2642, August 1999.
+
+7. Authors' Addresses
+
+   Dave Hamilton
+   Cabletron Systems, Inc.
+   Post Office Box 5005
+   Rochester, NH  03866-5005
+
+   Phone:(603) 332-9400
+   EMail:  daveh@ctron.com
+
+
+   Dave Ruffen
+   Cabletron Systems, Inc.
+   Post Office Box 5005
+   Rochester, NH  03866-5005
+
+   Phone:(603) 332-9400
+   EMail:  ruffen@ctron.com
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 16]
+
+RFC 2641       Cabletron's VlanHello Protocol Version 4      August 1999
+
+
+17.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamilton & Ruffen            Informational                     [Page 17]
+