rfc2643.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,692 行 · 第 1/5 页

   -  Eight call processing service centers that provide the essential
      services required to process call connections.  The call
      processing service centers are described in Section 4.

   -  A Call Tap module that supports the monitoring of call
      connections.  The Call Tap module is described in Section 5.

   -  The InterSwitch Message Protocol (ISMP) that provides a consistent
      method of encapsulating and transmitting control messages
      exchanged between SFVLAN switches.  (Note that ISMP is not a
      discrete software module.  Instead, its functionality is
      distributed among those service centers and software modules that
      need to communicate with other switches in the fabric.) The
      Interswitch Message Protocol and the formats of the individual
      interswitch messages are described in Section 6.

3. Base Services

   The SFVLAN base services act as the interface between the switch
   hardware and the SFVLAN service centers running on the switch CPU.
   This relationship is shown in Figure 2.  This figure is a replication
   of the bottom portion of Figure 1.


            |    Directory       Resolve                   |
            |        ^              ^                      |
            |        |              |                      |
            |        |    +---------^-----------+          |
            |        +----<    Base Services    |          |
            |             +-----^---------------+          |
            +-------------------|--------------------------+
             Switch CPU         |
                                | Host control port
                          +-----O----------------+
                          |     ^ no cnx         |
                Layer 2   |     |                |
               ---------->O-----+--------------->O----------->
                SA/DA pr  |          known cnx   |
                          +----------------------+
                           Switch hardware


                        Figure 2:  Base Services








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


   During normal operation of the switch, data packets arriving at
   any one of the local switch ports are examined in the switch
   hardware.  If the packet's source and destination address (SA/DA)
   pair match a known connection, the hardware simply forwards the
   packet out the outport specified by the connection.

   If the SA/DA pair do not match any known connection, the hardware
   diverts the packet to the host control port where it is picked up
   by the SFVLAN base services.  The base services generate a
   structure known as a state box that tracks the progress of the
   call connection request as the request moves through the call
   processing service centers.

   After creating the call's state box, the base services check to
   determine if the call is a duplicate of a call already being
   processed.  If not, a request is issued to the Directory Service
   Center (Section 4.1) to add the call's source address to the local
   Node and Alias Tables.  The base services then hand the call off to
   the Resolve Service Center (Section 4.3) for further processing.

4. Call Processing

   Call connection processing is handled by a set of eight service
   centers, each with one or more servers.  The servers within a
   service center are called in a particular sequence.  Each server
   records the results of its processing in the call connection
   request state box and passes the state box to the next server in
   the sequence.

   In the sections that follow, servers are listed in the order in
   which they are called.

4.1 Directory Service Center

   The Directory Service Center is responsible for cataloging the MAC
   addresses and alias information for both local and remote
   endstations.  The information is stored in two tables -- the Node
   Table and the Alias Table.

   -  The Node Table contains the MAC addresses of endstations
      attached to the local switch.  It also contains a cache of
      remote endstations detected by the Resolve Service Center
      (Section 4.3).   Every entry in the Node Table has one or more
      corresponding entries in the Alias Table.







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


   -  The Alias Table contains protocol alias information for each
      endstation.  An endstation alias can be a network address (such
      as an IP or IPX address), a VLAN identifier, or any other
      protocol identifier.  Since every endstation is a member of at
      least one VLAN (the default VLAN for the port), there is always
      at least one entry in the Alias Table for each entry in the
      Node Table.

      Note:

         The Node and Alias Tables must remain synchronized.
         That is, when an endstation's final alias is removed
         from the Alias Table, the endstation entry is removed
         from the Node Table.

   Note that the total collection of all Node Tables and Alias Tables
   across all switches is known as the "virtual" directory of the
   switch fabric.  The virtual directory contains address mappings of
   all known endstations in the fabric.

4.1.1 Local Add Server

   The Directory Local Add server adds entries to the local Node or
   Alias Tables.  It is called by the base services (Section 3) to
   add a local endstation and by the Interswitch Resolve (Section
   4.3.4) server to add an endstation discovered on a remote switch.

4.1.2 Inverse Resolve Server

   The Directory Inverse Resolve server is invoked when a new
   endstation has been discovered on the local switch (that is, when
   the Local Add server was successful in adding the endstation).
   The server provides two functions:

   -  It populates the Node and Alias Tables with local entries
      during switch initialization.

   -  It processes a new endstation discovered after the fabric
      topology has converged to a stable state.

   In both instances, the processing is identical.










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


   When a new endstation is detected on one of the switch's local
   ports, the Inverse Resolve server sends an Interswitch New User
   request message (Section 6.5) over the switch flood path to all
   other switches in the fabric.  The purpose of the Interswitch New
   User request is two-fold:

   -  It informs the other switches of the new endstation address.
      Any entries for that endstation in the local databases of other
      switches should be dealt with appropriately.

   -  It requests information about any static VLAN(s) to which the
      endstation has been assigned.

   When a switch receives an Interswitch New User request message
   from one of its upstream neighbors, it first forwards the message
   to all its downstream neighbors.  No actual processing or VLAN
   resolution is attempted until the message reaches the end of the
   switch flood path and begins its trip back along the return path.
   This ensures that all switches in the fabric receive notification
   of the new user and have synchronized their databases.

   If a switch receives an Interswitch New User request message but
   has no downstream neighbors, it does the following:

   -  If the endstation was previously connected to one of the
      switch's local ports, the switch formulates an Interswitch New
      User Response message by loading the VLAN identifier(s) of the
      static VLAN(s) to which the endstation was assigned, along with
      its own MAC address.  (VLAN identifiers are stored in
      Tag/Length/Value (TLV) format.  See Section 2.3.)  The switch
      then sets the message status field to NewUserAck, and returns
      the message to its upstream (requesting) neighbor.

      Otherwise, the switch sets the status field to NewUserUnknown
      and returns the message to its upstream neighbor.

   -  The switch then deletes the endstation from its local database,
      as well as any entries associated with the endstation in its
      connection table.

   When a switch forwards an Interswitch New User 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 requests have been responded to.







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


   -  As each response is received, the switch checks the status
      field of the message.  If the status is NewUserAck, the switch
      retains the information in that response.  When all requests
      have been responded to, the switch returns the NewUserAck
      response to its upstream neighbor.

   -  If all the Interswitch New User Request messages have been
      responded to with a status of NewUserUnknown, the switch checks
      to see if the endstation was previously connected to one of its
      local ports.  If so, the switch formulates an Interswitch New
      User Response message by loading the VLAN identifier(s) of the
      static VLAN(s) to which the endstation was assigned, along with
      its own MAC address.  The switch then sets the message status
      field to NewUserAck, and returns the message to its upstream
      (requesting) neighbor.

      Otherwise, the switch sets the status field to NewUserUnknown
      and returns the message to its upstream neighbor.

   -  The switch then deletes the endstation from its local database,
      as well as any entries associated with the endstation in its
      connection table.

   When the originating switch has received responses to all the
   Interswitch New User Request messages it has sent, it does the
   following:

   -  If it has received a response message with a status of
      NewUserAck, it loads the new VLAN information into its local
      database.

   -  If all responses have been received with a status of
      NewUserUnknown, the originating switch assumes that the
      endstation was not previously connected anywhere in the network
      and assigns it to a VLAN according to the VLAN membership rules
      and order of precedence.

   If any Interswitch New User Request message has not been responded
   to within a certain predetermined time (currently 5 seconds), the
   originating switch recalculates the switch flood path and resends
   the Interswitch New User Request message.










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


4.1.3 Local Delete Server

   The Directory Local Delete server removes entries (both local and
   remote) from the local Node and Alias Tables.  It is invoked when
   an endstation, previously known to be attached to one switch, has
   been moved and discovered on another switch.

   Note also that remote entries are cached and are purged from the
   tables on a first-in/first-out basis as space is needed in the
   cache.

4.2 Topology Service Center

   The Topology Service Center is responsible for maintaining three
   databases relating to the topology of the switch fabric:

   -  The topology table of SFVLAN switches that are physical
      neighbors to the local switch.

   -  The spanning tree that defines the loop-free switch flood path
      used for transmitting undirected interswitch messages.

   -  The directed graph that is used to calculate the best path(s)
      for call connections.

4.2.1 Neighbor Discovery Server

   The Topology Neighbor Discovery server uses Interswitch Keepalive
   messages to detect the switch's neighbors and establish the
   topology of the switching fabric.  Interswitch Keepalive messages
   are exchanged in accordance with Cabletron's VlanHello protocol,
   described in detail in [IDhello].

4.2.2 Spanning Tree Server

   The Topology Spanning Tree server is invoked by the Topology
   Neighbor Discovery server when a neighboring SFVLAN switch is
   either discovered or lost -- that is, when the operational status
   of a network link changes.

   The Spanning Tree server exchanges interswitch messages with
   neighboring SFVLAN switches to calculate the switch flood path
   over which undirected interswitch messages are sent.  There are
   two parts to this process:

   -  Creating and maintaining the spanning tree
   -  Remote blocking




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


4.2.2.1 Creating and Maintaining the Spanning Tree

   In a network with redundant network links, a packet traveling between