GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2641

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2641.txt · Last modified: 1999/07/30 18:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki