rfc2643.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   switches can potentially be caught in an infinite loop -- an
   intolerable situation in a networking environment.  However, it is
   possible to reduce a network topology to a single configuration
   (known as a spanning tree) such that there is, at most, one path
   between any two switches.

   Within the SFVLAN product, the spanning tree is created and
   maintained using the Spanning Tree Algorithm defined by the IEEE
   802.1d standard.

      Note:

         A detailed discussion of this algorithm is beyond the scope of
         this document.  See [IEEE] for more information.

   To implement the Spanning Tree Algorithm, SFVLAN switches exchange
   Interswitch BPDU messages (Section 6.2) containing encapsulated
   IEEE-compliant 802.2 Bridge Protocol Data Units (BPDUs).  There are
   two types of BPDUs:

   -  Configuration (CFG) BPDUs are exchanged during the switch
      discovery process, following the receipt of an Interswitch
      Keepalive message.  They are used to create the initial the
      spanning tree.

   -  Topology Change Notification (TCN) BPDUs are exchanged when
      changes in the network topology are detected.  They are used to
      redefine the spanning tree to reflect the current topology.

   See [IEEE] for detailed descriptions of these BPDUs.

4.2.2.2 Remote Blocking

   After the spanning tree has been computed, each network port on an
   SFVLAN switch will be in one of two states:

   -  Forwarding.  A port in the Forwarding state will be used to
      transmit all ISMP messages.










Ruffen, et al.               Informational                     [Page 19]

RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999


   -  Blocking.  A port in the Blocking state will not be used to
      forward undirected ISMP messages.  Blocking the rebroadcast of
      these messages on selected ports prevents message duplication
      arising from multiple paths that exist in the network topology.
      Note that all other types of ISMP message will be transmitted.

      Note:

         The IEEE 802.1d standard specifies other port states used
         during the initial creation of the spanning tree. These states
         are not relevant to the discussion here.

   Note that although a port in the Blocking state will not forward
   undirected ISMP messages, it may still receive them.  Any such
   message received will ultimately be discarded, but at the cost of CPU
   time necessary to process the packet.

   To prevent the transmission of undirected messages to a port, the
   port's owner switch can set remote blocking on the link by sending an
   Interswitch Remote Blocking message (Section 6.3) out over the port.
   This notifies the switch on the other end of the link that undirected
   messages should not be sent over the link, regardless of the state of
   the sending port.

   Each SFVLAN switch sends an Interswitch Remote Blocking message out
   over all its blocked network ports every 5 seconds.  A flag within
   the message indicates whether remote blocking should be turned on or
   off over the link.

4.2.3 Link State Server

   The Topology Link State server is invoked by any process that detects
   a change in the state of the network links of the local switch.
   These changes include (but are not limited to) changes in operational
   or administrative status of the link, path "cost" or bandwidth.

   The Link State server runs Cabletron's Virtual LAN Link State (VLS)
   protocol which exchanges interswitch messages with neighboring SFVLAN
   switches to calculate the set of best paths between the local switch
   and all other switches in the fabric. (The VLS protocol is described
   in detail in [IDvlsp].)

   The Link State server also notifies the Connect Service Center
   (Section 4.5) of any remote links that have failed, thereby
   necessitating potential tear-down of current connections.






Ruffen, et al.               Informational                     [Page 20]

RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999


4.3 Resolve Service Center

   The Resolve Service Center is responsible for resolving the
   destination address of broadcast data packets (such as an IP ARP
   packet) to a unicast MAC address to be used in mapping the call
   connection.  To do this, the Resolve Service Center attempts to
   resolve such broadcast packets directly at the access port of the
   ingress switch.

   Address resolution is accomplished as follows:

   1) First, an attempt is made to resolve the address from the switch's
      local databases by calling the following servers:

      -  The Table server attempts to resolve the address from the
         Resolve Table (Section 4.3.1).

      -  Next, the Local server attempts to resolve the address from the
         Node and Alias Tables (Section 4.3.2).

      -  If the address is not found in these tables but is an IP
         address, the Resolve Subnet server (Section 4.3.3) is also
         called.

   2) If the address cannot be resolved locally, the Interswitch Resolve
      server (Section 4.3.4) is called to access the "virtual directory"
      by sending an Interswitch Resolve request message out over the
      switch flood path.

   3) If the address cannot be resolved either locally or via an
      Interswitch Resolve message -- that is, the destination endstation
      is unknown to any switch, perhaps because it has never transmitted
      a packet to its switch -- the following steps are taken:

      -  The Unresolvable server (Section 4.3.5) is called to record the
         unresolved packet.

      -  The Block server (Section 4.3.6) is called to determine whether
         the address should be added to the Block Table.

      -  The Flood Service Center (Section 4.8) is called to broadcast
         the packet to other SFVLAN switches using a tag-based flooding
         mechanism.








Ruffen, et al.               Informational                     [Page 21]

RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999


4.3.1 Table Server

   The Resolve Table server maintains the Resolve Table which contains a
   collection of addresses that might not be resolvable in the normal
   fashion.  This table typically contains such things as the addresses
   of "quiet" devices that do not send data packets or special mappings
   of IP addresses behind a router.  Entries can be added to or deleted
   from the Resolve Table via an external management application.

4.3.2 Local Server

   The Resolve Local server checks the Node and Alias Tables maintained
   by the Directory Service Center (Section 4.1) to determine if it can
   resolve the address.

4.3.3 Subnet Server

   If the address to be resolved is an IP address but cannot be resolved
   via the standard processing described above, the Resolve Subnet
   server applies the subnet mask to the IP address and then does a
   lookup in the Resolve Table.

4.3.4 Interswitch Resolve Server

   If the address cannot be resolved locally, the Interswitch Resolve
   server accesses the "virtual directory" by sending an Interswitch
   Resolve request message (Section 6.4) out over the switch flood path.
   The Interswitch Resolve request message contains the destination
   address as it was received within the packet, along with a list of
   requested addressing information.

   When a switch receives an Interswitch Resolve request message from
   one of its upstream neighbors, it checks to see if the destination
   endstation is connected to one of its local access ports.  If so, it
   formulates an Interswitch Resolve response message by filling in the
   requested address information, along with its own MAC address.  It
   then sets the message status field to ResolveAck, and returns the
   message to its upstream (requesting) neighbor.

   If the receiving switch cannot resolve the address, it forwards the
   Interswitch Resolve request message to its downstream neighbors.  If
   the switch has no downstream neighbors, it sets the message status
   field to Unknown, and returns the message to its upstream
   (requesting) neighbor.







Ruffen, et al.               Informational                     [Page 22]

RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999


   When a switch forwards an Interswitch Resolve request message to its
   downstream neighbors, it keeps track of the number of requests it has
   sent out and received back.  It will only respond back to its
   upstream (requesting) neighbor when one of the following conditions
   occurs:

   -  It receives any response with a status of ResolveAck

   -  All downstream neighbors have responded with a status of Unknown

   Any Interswitch Resolve request message that is not responded to
   within a certain predetermined time (currently 5 seconds) is assumed
   to have a response status of Unknown.

   When the Interswitch Resolve server receives a successful Interswitch
   Resolve response message, it records the resolved address information
   in the remote cache of its local directory for use in resolving later
   packets for the same endstation.  Note that this process results in
   each switch building its own unique copy of the virtual directory
   containing only the endstation addresses in which it is interested.

4.3.5 Unresolvable Server

   The Unresolvable server is called when a packet destination address
   cannot be resolved.  The server records the packet in a table that
   can then be examined to determine which endstations are generating
   unresolvable traffic.

   Also, if a particular destination is repeatedly seen to be
   unresolvable, the server calls the Block server (Section 4.3.6) to
   determine whether the address should be blocked.

4.3.6 Block Server

   The Resolve Block server is called when a particular destination has
   been repeatedly seen to be unresolvable.  This typically happens
   when, unknown to the packet source, the destination endstation is
   either not currently available or no longer exists.

   If the Block server determines that the unresolved address has
   exceeded a configurable request threshold, the address is added to
   the server's Block Table.  Interswitch Resolve request messages for
   addresses listed in the Block Table are sent less frequently, thereby
   reducing the amount of Interswitch Resolve traffic throughout the
   fabric.






Ruffen, et al.               Informational                     [Page 23]

RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999


   If an address listed in the Block Table is later successfully
   resolved by and Interswitch Resolve request message, the address is
   removed from the table.

4.4 Policy Service Center

   Once the destination address of the call packet has been resolved,
   the Policy Service Center is called to determine the validity of the
   requested call connection based on the VLAN policy of the source and
   destination VLANs.

4.4.1 Unicast Rules Server

   The Policy Unicast Rules server recognizes two VLAN policy values:
   Open or Secure.  The default policy for all VLANs is Open.

   The policy value is used as follows when determining the validity of
   a requested call connection:

   -  If the VLAN policy of either the source or destination cannot be
      determined, the Filter Service Center is called to establish a
      filter (i.e., blocked) for the SA/DA pair.

   -  If the source and destination endstations belong to the same VLAN,
      then the connection is permitted regardless of the VLAN policy.

   -  If the source and destination endstations belong to different
      VLANs, but both VLANs are running with an Open policy, then the
      connection is permitted, providing cut-through switching between
      different VLAN(s).

   -  If the source and destination endstations belong to different
      VLANs and one or both of the VLANs are running with a Secure
      policy, then the Flood Service Center (Section 4.8) is called to
      broadcast the packet to other SFVLAN switches having ports or
      endstations that belong to the same VLAN as the packet source.

      Note that if any of the VLANs to which the source or destination
      belong has a Secure policy, then the policy used in the above
      algorithm is Secure.











Ruffen, et al.               Informational                     [Page 24]

RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999


4.5 Connect Service Center

   Once the Policy Service Center (Section 4.4) has determined that a
   requested call connection is valid, the Connect Service Center is
   called to set up the connection.  Note that connectivity between two
   endstations within the fabric is established on a switch-by-switch