home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2643.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  122.2 KB  |  3,364 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Ruffen
  8. Request for Comments: 2643                                        T. Len
  9. Category: Informational                                       J. Yanacek
  10.                                           Cabletron Systems Incorporated
  11.                                                              August 1999
  12.  
  13.  
  14.              Cabletron's SecureFast VLAN Operational Model
  15.                               Version 1.8
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  It does
  20.    not specify an Internet standard of any kind.  Distribution of this
  21.    memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  26.  
  27. Abstract
  28.  
  29.    Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed
  30.    connection-oriented switching protocol that provides fast forwarding
  31.    of data packets at the MAC layer.  The product uses the concept of
  32.    virtual LANs (VLANs) to determine the validity of call connection
  33.    requests and to scope the broadcast of certain flooded messages.
  34.  
  35. Table of Contents
  36.  
  37.    1. Introduction.............................................  3
  38.       1.1 Data Conventions.....................................  3
  39.       1.2 Definitions of Commonly Used Terms...................  4
  40.    2. SFVLAN Overview..........................................  6
  41.       2.1 Features.............................................  7
  42.       2.2 VLAN Principles......................................  8
  43.           2.2.1 Default, Base and Inherited VLANs..............  8
  44.           2.2.2 VLAN Configuration Modes.......................  8
  45.                 2.2.2.1 Endstations............................  8
  46.                 2.2.2.2 Ports..................................  9
  47.                 2.2.2.3 Order of Precedence....................  9
  48.           2.2.3 Ports with Multiple VLAN Membership............ 10
  49.       2.3 Tag/Length/Value Method of Addressing................ 10
  50.       2.4 Architectural Overview............................... 11
  51.    3. Base Services............................................ 13
  52.    4. Call Processing.......................................... 14
  53.       4.1 Directory Service Center............................. 14
  54.           4.1.1 Local Add Server............................... 15
  55.  
  56.  
  57.  
  58. Ruffen, et al.               Informational                      [Page 1]
  59.  
  60. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  61.  
  62.  
  63.           4.1.2 Inverse Resolve Server......................... 15
  64.           4.1.3 Local Delete Server............................ 18
  65.       4.2 Topology Service Center.............................. 18
  66.           4.2.1 Neighbor Discovery Server...................... 18
  67.           4.2.2 Spanning Tree Server........................... 18
  68.                 4.2.2.1 Creating and Maintaining
  69.                                    the Spanning Tree........... 19
  70.                 4.2.2.2 Remote Blocking........................ 19
  71.           4.2.3 Link State Server.............................. 20
  72.       4.3 Resolve Service Center............................... 21
  73.           4.3.1 Table Server................................... 22
  74.           4.3.2 Local Server................................... 22
  75.           4.3.3 Subnet Server.................................. 22
  76.           4.3.4 Interswitch Resolve Server..................... 22
  77.           4.3.5 Unresolvable Server............................ 23
  78.           4.3.6 Block Server................................... 23
  79.       4.4 Policy Service Center................................ 24
  80.           4.4.1 Unicast Rules Server........................... 24
  81.       4.5 Connect Service Center............................... 25
  82.           4.5.1 Local Server................................... 25
  83.           4.5.2 Link State Server.............................. 25
  84.           4.5.3 Directory Server............................... 26
  85.       4.6 Filter Service Center................................ 26
  86.       4.7 Path Service Center.................................. 26
  87.           4.7.1 Link State Server.............................. 26
  88.           4.7.2 Spanning Tree Server........................... 27
  89.       4.8 Flood Service Center................................. 27
  90.           4.8.1 Tag-Based Flood Server......................... 27
  91.    5. Monitoring Call Connections.............................. 27
  92.       5.1 Definitions.......................................... 27
  93.       5.2 Tapping a Connection................................. 28
  94.           5.2.1 Types of Tap Connections....................... 28
  95.           5.2.2 Locating the Probe and Establishing
  96.                                    the Tap Connection.......... 29
  97.           5.2.3 Status Field................................... 30
  98.       5.3 Untapping a Connection............................... 31
  99.    6. Interswitch Message Protocol (ISMP)...................... 32
  100.       6.1 General Packet Structure............................. 32
  101.           6.1.1 Frame Header................................... 32
  102.           6.1.2 ISMP Packet Header............................. 33
  103.                 6.1.2.1 Version 2.............................. 33
  104.                 6.1.2.2 Version 3.............................. 34
  105.           6.1.3 ISMP Message Body.............................. 35
  106.       6.2 Interswitch BPDU Message............................. 35
  107.       6.3 Interswitch Remote Blocking Message.................. 36
  108.       6.4 Interswitch Resolve Message.......................... 37
  109.           6.4.1 Prior to Version 1.8........................... 37
  110.           6.4.2 Version 1.8.................................... 41
  111.  
  112.  
  113.  
  114. Ruffen, et al.               Informational                      [Page 2]
  115.  
  116. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  117.  
  118.  
  119.       6.5 Interswitch New User Message......................... 46
  120.       6.6 Interswitch Tag-Based Flood Message.................. 49
  121.           6.6.1 Prior to Version 1.8........................... 49
  122.           6.6.2 Version 1.8.................................... 52
  123.       6.7 Interswitch Tap/Untap Message........................ 55
  124.    7. Security Considerations.................................. 58
  125.    8. References............................................... 58
  126.    9. Authors' Addresses....................................... 59
  127.    10. Full Copyright Statement................................ 60
  128.  
  129. 1. Introduction
  130.  
  131.    This memo is being distributed to members of the Internet community
  132.    in order to solicit reactions to the proposals contained herein.
  133.    While the specification discussed here may not be directly relevant
  134.    to the research problems of the Internet, it may be of interest to
  135.    researchers and implementers.
  136.  
  137. 1.1 Data Conventions
  138.  
  139.    The methods used in this memo to describe and picture data adhere to
  140.    the standards of Internet Protocol documentation [RFC1700].  In
  141.    particular:
  142.  
  143.       The convention in the documentation of Internet Protocols is to
  144.       express numbers in decimal and to picture data in "big-endian"
  145.       order.  That is, fields are described left to right, with the most
  146.       significant octet on the left and the least significant octet on
  147.       the right.
  148.  
  149.       The order of transmission of the header and data described in this
  150.       document is resolved to the octet level.  Whenever a diagram shows
  151.       a group of octets, the order of transmission of those octets is
  152.       the normal order in which they are read in English.
  153.  
  154.       Whenever an octet represents a numeric quantity the left most bit
  155.       in the diagram is the high order or most significant bit.  That
  156.       is, the bit labeled 0 is the most significant bit.
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Ruffen, et al.               Informational                      [Page 3]
  171.  
  172. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  173.  
  174.  
  175.       Similarly, whenever a multi-octet field represents a numeric
  176.       quantity the left most bit of the whole field is the most
  177.       significant bit.  When a multi-octet quantity is transmitted the
  178.       most significant octet is transmitted first.
  179.  
  180. 1.2 Definitions of Commonly Used Terms
  181.  
  182.    This section contains a collection of definitions for terms that have
  183.    a specific meaning for the SFVLAN product and that are used
  184.    throughout the text.
  185.  
  186.    Switch ID
  187.  
  188.       A 10-octet value that uniquely identifies an SFVLAN switch within
  189.       the switch fabric.  The value consists of the 6-octet base MAC
  190.       address of the switch, followed by 4 octets of zeroes.
  191.  
  192.    Network link
  193.  
  194.       The physical connection between two switches.  A network link is
  195.       associated with a network interface (or port) of a switch.
  196.  
  197.    Network port
  198.  
  199.       An interface on a switch that attaches to another switch.
  200.  
  201.    Access port
  202.  
  203.       An interface on a switch that attaches to a user endstation.
  204.  
  205.    Port ID
  206.  
  207.       A 10-octet value that uniquely identifies an interface of a
  208.       switch.  The value consists of the 6-octet base MAC address of the
  209.       switch, followed by the 4-octet local port number of the
  210.       interface.
  211.  
  212.    Neighboring switches
  213.  
  214.       Two switches attached to a common (network) link.
  215.  
  216.    Call connection
  217.  
  218.       A mapping of user traffic through a switch that correlates the
  219.       source and destination address pair specified within the packet to
  220.       an inport and outport pair on the switch.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Ruffen, et al.               Informational                      [Page 4]
  227.  
  228. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  229.  
  230.  
  231.    Call connection path
  232.  
  233.       A set of 0 to 7 network links over which user traffic travels
  234.       between the source and destination endstations.  Call connection
  235.       paths are selected from a list of alternate equal cost paths
  236.       calculated by the VLS protocol [IDvlsp], and are chosen to load
  237.       balance traffic across the fabric.
  238.  
  239.    Ingress switch
  240.  
  241.       The owner switch of the source endstation of a call connection.
  242.       That is, the source endstation is attached to one of the local
  243.       access ports of the switch.
  244.  
  245.    Egress switch
  246.  
  247.       The owner switch of the destination endstation of a call
  248.       connection.  That is, the destination endstation is attached to
  249.       one of the local access ports of the switch.
  250.  
  251.    Intermediate switches
  252.  
  253.       Any switch along the call connection path on which user traffic
  254.       enters and leaves over network links.  Note that the following
  255.       types of connections have no intermediate switches:
  256.  
  257.       -  Call connections between source and destination endstations
  258.          that are attached to the same switch -- that is, the ingress
  259.          switch is the same as the egress switch.  Note also that the
  260.          path for this type of connection consists of 0 network links.
  261.  
  262.       -  Call connections where the ingress and egress switches are
  263.          physical neighbors connected by a single network link.  The
  264.          path for this type of connection consists of a single network
  265.          link.
  266.  
  267.    InterSwitch Message protocol (ISMP)
  268.  
  269.       The protocol used for interswitch communication between SFVLAN
  270.       switches.
  271.  
  272.    Undirected messages
  273.  
  274.       Messages that are (potentially) sent to all SFVLAN switches in the
  275.       switch fabric -- that is, they are not directed to any particular
  276.       switch.  ISMP messages with a message type of 5, 7 or 8 are
  277.       undirected messages.
  278.  
  279.  
  280.  
  281.  
  282. Ruffen, et al.               Informational                      [Page 5]
  283.  
  284. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  285.  
  286.  
  287.    Switch flood path
  288.  
  289.       The path used to send undirected messages throughout the switch
  290.       fabric.  The switch flood path is formed using a spanning tree
  291.       algorithm that provides a single path through the switch fabric
  292.       that guarantees loop-free delivery to every other SFVLAN switch in
  293.       the fabric.
  294.  
  295.    Upstream Neighbor
  296.  
  297.       That switch attached to the inport of the switch flood path --
  298.       that is, the switch from which undirected messages are received.
  299.       Note that each switch receiving an undirected message has, at
  300.       most, one upstream neighbor, and the originator of any undirected
  301.       ISMP message has no upstream neighbors.
  302.  
  303.    Downstream Neighbors
  304.  
  305.       Those switches attached to all outports of the switch flood path
  306.       except the port on which the undirected message was received.
  307.       Note that for each undirected message some number of switches have
  308.       no downstream neighbors.
  309.  
  310.    Virtual LAN (VLAN) identifier
  311.  
  312.       A VLAN is a logical grouping of ports and endstations such that
  313.       all ports and endstations in the VLAN appear to be on the same
  314.       physical (or extended) LAN segment even though they may be
  315.       geographically separated.
  316.  
  317.       A VLAN identifier consists of a variable-length string of octets.
  318.       The first octet in the string contains the number of octets in the
  319.       remainder of the string -- the actual VLAN identifier value.  A
  320.       VLAN identifier can be from 1 to 16 octets long.
  321.  
  322.    VLAN policy
  323.  
  324.       Each VLAN has an assigned policy value used to determine whether a
  325.       particular call connection can be established. SFVLAN recognizes
  326.       two policy values:  Open and Secure.
  327.  
  328. 2. SFVLAN Overview
  329.  
  330.    Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed
  331.    connection-oriented switching protocol that provides fast forwarding
  332.    of data packets at the MAC layer.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Ruffen, et al.               Informational                      [Page 6]
  339.  
  340. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  341.  
  342.  
  343. 2.1 Features
  344.  
  345.    Within a connection-oriented switching network, user traffic is
  346.    routed through the switch fabric based on the source and destination
  347.    address (SA/DA) pair found in the arriving packet. For each SA/DA
  348.    pair encountered by a switch, a "connection" is programmed into the
  349.    switch hardware.  This connection maps the SA/DA pair and the port on
  350.    which the packet was received to a specific outport over which the
  351.    packet is to be forwarded.  Thus, once a connection has been
  352.    established, all packets with a particular SA/DA pair arriving on a
  353.    particular inport are automatically forwarded by the switch hardware
  354.    out the specified outport.
  355.  
  356.    A distributed switching environment requires that each switch be
  357.    capable of processing all aspects of the call processing and
  358.    switching functionality.  Thus, each switch must synchronize its
  359.    various databases with all other switches in the fabric or be capable
  360.    of querying other switches for information it does not have locally.
  361.  
  362.    SFVLAN accomplishes the above objectives by providing the following
  363.    features:
  364.  
  365.    -  A virtual directory of the entire switch fabric.
  366.  
  367.    -  Call processing for IP, IPX and MAC protocols.
  368.  
  369.    -  Automatic call connection, based on VLAN policy.
  370.  
  371.    -  Automatic call rerouting around failed switches and links.
  372.  
  373.    In addition, SFVLAN optimizes traffic flow across the switch fabric
  374.    by providing the following features:
  375.  
  376.    -  Broadcast interception and address resolution at the ingress port.
  377.  
  378.    -  Broadcast scoping, restricting the flooding of broadcast packets
  379.       to only those ports that belong to the same VLAN as the packet
  380.       source.
  381.  
  382.    -  A single loop-free path (spanning tree) used for the flooding of
  383.       undirected interswitch control messages.  Only switches running
  384.       the SFVLAN switching protocol are included in this spanning tree
  385.       calculation -- that is, traditional bridges or routers configured
  386.       for bridging are not included.
  387.  
  388.    -  Interception of both service and route advertisements with
  389.       readvertisement sourced from the MAC address of the original
  390.       advertiser.
  391.  
  392.  
  393.  
  394. Ruffen, et al.               Informational                      [Page 7]
  395.  
  396. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  397.  
  398.  
  399. 2.2 VLAN Principles
  400.  
  401.    Each SFVLAN switch port, along with its attached endstations, belongs
  402.    to one or more virtual LANs (VLANs).  A VLAN is a logical grouping of
  403.    ports and endstations such that all ports and endstations in the VLAN
  404.    appear to be on the same physical (or extended) LAN segment even
  405.    though they may be geographically separated.
  406.  
  407.    VLAN assignments are used to determine the validity of call
  408.    connection requests and to scope the broadcast of certain flooded
  409.    messages.
  410.  
  411. 2.2.1 Default, Base and Inherited VLANs
  412.  
  413.    Each port is explicitly assigned to a default VLAN.  At start-up, the
  414.    default VLAN to which all ports are assigned is the base VLAN -- a
  415.    permanent, non-deletable VLAN to which all ports belong at all times.
  416.  
  417.    The network administrator can change the default VLAN of a port from
  418.    the base VLAN to any other unique VLAN by using a management
  419.    application known here as the VLAN Manager.  A port's default VLAN is
  420.    persistent -- that is, it is preserved across a switch reset.
  421.  
  422.    When an endstation attaches to a port for the first time, it inherits
  423.    the default VLAN of the port.  Using the VLAN Manager, the network
  424.    administrator can reassign an endstation to another VLAN.
  425.  
  426.       Note:
  427.  
  428.          When all ports and all endstations belong to the base VLAN, the
  429.          switch fabric behaves like an 802.1D bridging system.
  430.  
  431. 2.2.2 VLAN Configuration Modes
  432.  
  433.    For both ports and endstations, there are a variety of VLAN
  434.    configuration types, or modes.
  435.  
  436. 2.2.2.1 Endstations
  437.  
  438.    For endstations, there are two VLAN configuration modes: inherited
  439.    and static.
  440.  
  441.    -  Inherited
  442.  
  443.       An inherited endstation becomes a member of its port's default
  444.       VLAN.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Ruffen, et al.               Informational                      [Page 8]
  451.  
  452. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  453.  
  454.  
  455.    -  Static
  456.  
  457.       A static port becomes a member of the VLAN to which it has been
  458.       assigned by the VLAN Manager.
  459.  
  460.    The default configuration mode for an endstation is inherited.
  461.  
  462. 2.2.2.2 Ports
  463.  
  464.    For ports, there are two VLAN configuration modes:  normal and
  465.    locked.
  466.  
  467.    -  Normal
  468.  
  469.       All inherited endstations on a normal port become members of the
  470.       port's default VLAN.  All static endstations are members of the
  471.       VLAN to which they were mapped by the VLAN Manager.
  472.  
  473.       If the VLAN Manager reassigns the default VLAN of a normal port,
  474.       the VLAN(s) for the attached endstations may or may not change,
  475.       depending on the VLAN configuration mode of each endstation.  All
  476.       inherited endstations will become members of the new default VLAN.
  477.       All others will retain membership in their previously mapped
  478.       VLANs.
  479.  
  480.    -  Locked
  481.  
  482.       All endstations attached to a locked port can be members only of
  483.       the port's default VLAN.
  484.  
  485.       If the VLAN Manager reconfigures a normal port to be a locked
  486.       port, all endstations attached to the port become members of the
  487.       port's default VLAN, regardless of any previous VLAN membership.
  488.  
  489.    The default configuration mode for ports is normal.
  490.  
  491. 2.2.2.3 Order of Precedence
  492.  
  493.    On a normal port, static VLAN membership prevails over inherited
  494.    membership.
  495.  
  496.    On a locked port, default VLAN membership prevails over any static
  497.    VLAN membership.
  498.  
  499.    If a statically assigned endstation moves from a locked port back to
  500.    a normal port, the endstation's static VLAN membership must be
  501.    preserved.
  502.  
  503.  
  504.  
  505.  
  506. Ruffen, et al.               Informational                      [Page 9]
  507.  
  508. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  509.  
  510.  
  511. 2.2.3 Ports with Multiple VLAN Membership
  512.  
  513.    A port can belong to multiple VLANs, based on the VLAN membership of
  514.    its attached endstations.
  515.  
  516.    For example, consider a port with three endstations, a default VLAN
  517.    of "blue" and the following endstation VLAN assignments:
  518.  
  519.    -  One of the endstations is statically assigned to VLAN "red."
  520.    -  Another endstation is statically assigned to VLAN "green."
  521.    -  The third endstation inherits the default VLAN of "blue."
  522.  
  523.    In this instance, the port is explicitly a member of VLAN "blue." But
  524.    note that it is also implicitly a member of VLAN "red" and VLAN
  525.    "green."  Any tag-based flooding (Section 4.8) directed to any one of
  526.    the three VLANs ("red," "green," or "blue") will be forwarded out the
  527.    port.
  528.  
  529. 2.3 Tag/Length/Value Method of Addressing
  530.  
  531.    Within most computer networks, the concept of "address" is somewhat
  532.    elusive because different protocols can (and do) use different
  533.    addressing schemes and formats.  For example, Ethernet (physical
  534.    layer) addresses are six octets long, while IP (network layer)
  535.    addresses are only four octets long.
  536.  
  537.    To distinguish between the various protocol-specific forms of
  538.    addressing, many software modules within the SFVLAN product specify
  539.    addresses in a format known as Tag/Length/Value (TLV). This format
  540.    uses a variable-length construct as shown below:
  541.  
  542.     0                   1                   2                   3
  543.     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
  544.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  545.    |                              Tag                              |
  546.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  547.    | Value length  |                                               |
  548.    +-+-+-+-+-+-+-+-+                                               +
  549.    |                          Address value                        |
  550.    :                                                               :
  551.    |                                                               |
  552.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  553.  
  554.    Tag
  555.  
  556.       This 4-octet field specifies the type of address contained in the
  557.       structure.  The following address types are currently supported:
  558.  
  559.  
  560.  
  561.  
  562. Ruffen, et al.               Informational                     [Page 10]
  563.  
  564. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  565.  
  566.  
  567.          Tag name        Value    Address type
  568.  
  569.          aoMacDx         1        DX ethernet dst/src/type
  570.          aoIpxSap        2        Sap
  571.          aoIpxRIP        3        RIP
  572.          aoInstYP        4        YP (YP name and version)
  573.          aoInstUDP       5        UDP (Port #)
  574.          aoIpxIpx        6        Ipx
  575.          aoInetIP        7        IP (Net address)
  576.          aoInetRPC       8        RPC (Program #)
  577.          aoInetRIP       9        INET RIP
  578.          aoMacDXMcast    10       Multicast unknown type
  579.          aoAtDDP         11       AppleTalk DDP
  580.          aoEmpty         12       (no address type specified)
  581.          aoVlan          13       VLAN identifier
  582.          aoHostName      14       Host name
  583.          aoNetBiosName   15       NetBIOS name
  584.          aoNBT           16       NetBIOS on TCP name
  585.          aoInetIPMask    17       IP Subnet Mask
  586.          aoIpxSap8022    18       Sap 8022 type service
  587.          aoIpxSapSnap    19       Sap Snap type service
  588.          aoIpxSapEnet    20       Sap Enet type service
  589.          aoDHCPXID       21       DHCP Transaction ID
  590.          aoIpMcastRx     22       IP class D receiver
  591.          aoIpMcastTx     23       IP class D sender
  592.          aoIpxRip8022    24       Ipx Rip 8022 type service
  593.          aoIpxRipSnap    25       Ipx Rip type service
  594.          aoIpxRipEnet    26       Ipx Rip Enet service
  595.          aoATM           27       ATM
  596.          aoATMELAN       28       ATM LAN Emulation Name
  597.  
  598.    Value length
  599.  
  600.       This 1-octet field contains the length of the value of the
  601.       address.  The value here depends on the address type and actual
  602.       value.
  603.  
  604.    Address value
  605.  
  606.       This variable-length field contains the value of the address. The
  607.       length of this field is stored in the Value length field.
  608.  
  609. 2.4 Architectural Overview
  610.  
  611.    The SFVLAN software executes in the switch CPU and consists of the
  612.    following elements as shown in Figure 1:
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Ruffen, et al.               Informational                     [Page 11]
  619.  
  620. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  621.  
  622.  
  623.    -  The SFVLAN base services that handles traffic intercepted by the
  624.       switch hardware.  The base services are described in Section 3.
  625.  
  626.    +------------------------------------------------------+
  627.    |                                              +-----+ |
  628.    |                         +------------+       |  I  | |
  629.    |                         |  CALL TAP  <--(8)-->  N  | |
  630.    |                         +------------+       |  T  | |
  631.    |                                              |  E  | |
  632.    |      +-----------+      +------------+       |  R  | |
  633.    |      |   PATH    |      |  TOPOLOGY  |       |  S  | |
  634.    |      |           |      |            |       |  W  | |
  635.    |      | Lnk state <------>  Lnk state <--(3)-->  I  | | Flood path
  636.    |      |           |      |            |       |  T  <----(5,7,8)-->
  637.    |      | Span tree <------>  Span tree <--(4)-->  C  | |
  638.    |      +--^--------+      |            |       |  H  | |
  639.    |         |               |  Discovery <--(2)-->     | |
  640.    |         |               +------------+       |  M  | |
  641.    |         |                                    |  E  | |
  642.    |  +------^--+            +--------+           |  S  | |
  643.    |  | CONNECT >---------+--> FILTER |           |  S  | |
  644.    |  +--^------+         |  +--------+           |  A  | |  specific
  645.    |     |                |                       |  G  | | netwrk lnks
  646.    |     |       +--------^-+     +-------+       |  E  <----(2,3,4)-->
  647.    |     +-------<  POLICY  |     | FLOOD >--(7)-->     | |
  648.    |             +------^---+     +-^-----+       |  P  | |
  649.    |                    |           |             |  R  | |
  650.    | +-----------+    +-^-----------V-+           |  O  | |
  651.    | | DIRECTORY <---->    RESOLVE    <------(5)-->  T  | |
  652.    | +-----^-----+    +---^-----------+           |  O  | |
  653.    |       |              |                       |  C  | |
  654.    |       |    +---------^-----------+           |  O  | |
  655.    |       +----<    Base Services    |           |  L  | |
  656.    |            +-----^---------------+           +-----+ |
  657.    +------------------|-----------------------------------+
  658.     Switch CPU        |
  659.                       | Host control port
  660.                 +-----O----------------+
  661.                 |     ^ no cnx         |
  662.       Layer 2   |     |                |
  663.      ---------->O-----+--------------->O----------->
  664.       SA/DA pr  |          known cnx   |
  665.                 +----------------------+
  666.                  Switch hardware
  667.  
  668.  
  669.                    Figure 1:  SFVLAN Architectural Overview
  670.  
  671.  
  672.  
  673.  
  674. Ruffen, et al.               Informational                     [Page 12]
  675.  
  676. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  677.  
  678.  
  679.    -  Eight call processing service centers that provide the essential
  680.       services required to process call connections.  The call
  681.       processing service centers are described in Section 4.
  682.  
  683.    -  A Call Tap module that supports the monitoring of call
  684.       connections.  The Call Tap module is described in Section 5.
  685.  
  686.    -  The InterSwitch Message Protocol (ISMP) that provides a consistent
  687.       method of encapsulating and transmitting control messages
  688.       exchanged between SFVLAN switches.  (Note that ISMP is not a
  689.       discrete software module.  Instead, its functionality is
  690.       distributed among those service centers and software modules that
  691.       need to communicate with other switches in the fabric.) The
  692.       Interswitch Message Protocol and the formats of the individual
  693.       interswitch messages are described in Section 6.
  694.  
  695. 3. Base Services
  696.  
  697.    The SFVLAN base services act as the interface between the switch
  698.    hardware and the SFVLAN service centers running on the switch CPU.
  699.    This relationship is shown in Figure 2.  This figure is a replication
  700.    of the bottom portion of Figure 1.
  701.  
  702.  
  703.             |    Directory       Resolve                   |
  704.             |        ^              ^                      |
  705.             |        |              |                      |
  706.             |        |    +---------^-----------+          |
  707.             |        +----<    Base Services    |          |
  708.             |             +-----^---------------+          |
  709.             +-------------------|--------------------------+
  710.              Switch CPU         |
  711.                                 | Host control port
  712.                           +-----O----------------+
  713.                           |     ^ no cnx         |
  714.                 Layer 2   |     |                |
  715.                ---------->O-----+--------------->O----------->
  716.                 SA/DA pr  |          known cnx   |
  717.                           +----------------------+
  718.                            Switch hardware
  719.  
  720.  
  721.                         Figure 2:  Base Services
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Ruffen, et al.               Informational                     [Page 13]
  731.  
  732. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  733.  
  734.  
  735.    During normal operation of the switch, data packets arriving at
  736.    any one of the local switch ports are examined in the switch
  737.    hardware.  If the packet's source and destination address (SA/DA)
  738.    pair match a known connection, the hardware simply forwards the
  739.    packet out the outport specified by the connection.
  740.  
  741.    If the SA/DA pair do not match any known connection, the hardware
  742.    diverts the packet to the host control port where it is picked up
  743.    by the SFVLAN base services.  The base services generate a
  744.    structure known as a state box that tracks the progress of the
  745.    call connection request as the request moves through the call
  746.    processing service centers.
  747.  
  748.    After creating the call's state box, the base services check to
  749.    determine if the call is a duplicate of a call already being
  750.    processed.  If not, a request is issued to the Directory Service
  751.    Center (Section 4.1) to add the call's source address to the local
  752.    Node and Alias Tables.  The base services then hand the call off to
  753.    the Resolve Service Center (Section 4.3) for further processing.
  754.  
  755. 4. Call Processing
  756.  
  757.    Call connection processing is handled by a set of eight service
  758.    centers, each with one or more servers.  The servers within a
  759.    service center are called in a particular sequence.  Each server
  760.    records the results of its processing in the call connection
  761.    request state box and passes the state box to the next server in
  762.    the sequence.
  763.  
  764.    In the sections that follow, servers are listed in the order in
  765.    which they are called.
  766.  
  767. 4.1 Directory Service Center
  768.  
  769.    The Directory Service Center is responsible for cataloging the MAC
  770.    addresses and alias information for both local and remote
  771.    endstations.  The information is stored in two tables -- the Node
  772.    Table and the Alias Table.
  773.  
  774.    -  The Node Table contains the MAC addresses of endstations
  775.       attached to the local switch.  It also contains a cache of
  776.       remote endstations detected by the Resolve Service Center
  777.       (Section 4.3).   Every entry in the Node Table has one or more
  778.       corresponding entries in the Alias Table.
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Ruffen, et al.               Informational                     [Page 14]
  787.  
  788. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  789.  
  790.  
  791.    -  The Alias Table contains protocol alias information for each
  792.       endstation.  An endstation alias can be a network address (such
  793.       as an IP or IPX address), a VLAN identifier, or any other
  794.       protocol identifier.  Since every endstation is a member of at
  795.       least one VLAN (the default VLAN for the port), there is always
  796.       at least one entry in the Alias Table for each entry in the
  797.       Node Table.
  798.  
  799.       Note:
  800.  
  801.          The Node and Alias Tables must remain synchronized.
  802.          That is, when an endstation's final alias is removed
  803.          from the Alias Table, the endstation entry is removed
  804.          from the Node Table.
  805.  
  806.    Note that the total collection of all Node Tables and Alias Tables
  807.    across all switches is known as the "virtual" directory of the
  808.    switch fabric.  The virtual directory contains address mappings of
  809.    all known endstations in the fabric.
  810.  
  811. 4.1.1 Local Add Server
  812.  
  813.    The Directory Local Add server adds entries to the local Node or
  814.    Alias Tables.  It is called by the base services (Section 3) to
  815.    add a local endstation and by the Interswitch Resolve (Section
  816.    4.3.4) server to add an endstation discovered on a remote switch.
  817.  
  818. 4.1.2 Inverse Resolve Server
  819.  
  820.    The Directory Inverse Resolve server is invoked when a new
  821.    endstation has been discovered on the local switch (that is, when
  822.    the Local Add server was successful in adding the endstation).
  823.    The server provides two functions:
  824.  
  825.    -  It populates the Node and Alias Tables with local entries
  826.       during switch initialization.
  827.  
  828.    -  It processes a new endstation discovered after the fabric
  829.       topology has converged to a stable state.
  830.  
  831.    In both instances, the processing is identical.
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Ruffen, et al.               Informational                     [Page 15]
  843.  
  844. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  845.  
  846.  
  847.    When a new endstation is detected on one of the switch's local
  848.    ports, the Inverse Resolve server sends an Interswitch New User
  849.    request message (Section 6.5) over the switch flood path to all
  850.    other switches in the fabric.  The purpose of the Interswitch New
  851.    User request is two-fold:
  852.  
  853.    -  It informs the other switches of the new endstation address.
  854.       Any entries for that endstation in the local databases of other
  855.       switches should be dealt with appropriately.
  856.  
  857.    -  It requests information about any static VLAN(s) to which the
  858.       endstation has been assigned.
  859.  
  860.    When a switch receives an Interswitch New User request message
  861.    from one of its upstream neighbors, it first forwards the message
  862.    to all its downstream neighbors.  No actual processing or VLAN
  863.    resolution is attempted until the message reaches the end of the
  864.    switch flood path and begins its trip back along the return path.
  865.    This ensures that all switches in the fabric receive notification
  866.    of the new user and have synchronized their databases.
  867.  
  868.    If a switch receives an Interswitch New User request message but
  869.    has no downstream neighbors, it does the following:
  870.  
  871.    -  If the endstation was previously connected to one of the
  872.       switch's local ports, the switch formulates an Interswitch New
  873.       User Response message by loading the VLAN identifier(s) of the
  874.       static VLAN(s) to which the endstation was assigned, along with
  875.       its own MAC address.  (VLAN identifiers are stored in
  876.       Tag/Length/Value (TLV) format.  See Section 2.3.)  The switch
  877.       then sets the message status field to NewUserAck, and returns
  878.       the message to its upstream (requesting) neighbor.
  879.  
  880.       Otherwise, the switch sets the status field to NewUserUnknown
  881.       and returns the message to its upstream neighbor.
  882.  
  883.    -  The switch then deletes the endstation from its local database,
  884.       as well as any entries associated with the endstation in its
  885.       connection table.
  886.  
  887.    When a switch forwards an Interswitch New User request message to
  888.    its downstream neighbors, it keeps track of the number of requests
  889.    it has sent out and does not respond back to its upstream neighbor
  890.    until all requests have been responded to.
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Ruffen, et al.               Informational                     [Page 16]
  899.  
  900. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  901.  
  902.  
  903.    -  As each response is received, the switch checks the status
  904.       field of the message.  If the status is NewUserAck, the switch
  905.       retains the information in that response.  When all requests
  906.       have been responded to, the switch returns the NewUserAck
  907.       response to its upstream neighbor.
  908.  
  909.    -  If all the Interswitch New User Request messages have been
  910.       responded to with a status of NewUserUnknown, the switch checks
  911.       to see if the endstation was previously connected to one of its
  912.       local ports.  If so, the switch formulates an Interswitch New
  913.       User Response message by loading the VLAN identifier(s) of the
  914.       static VLAN(s) to which the endstation was assigned, along with
  915.       its own MAC address.  The switch then sets the message status
  916.       field to NewUserAck, and returns the message to its upstream
  917.       (requesting) neighbor.
  918.  
  919.       Otherwise, the switch sets the status field to NewUserUnknown
  920.       and returns the message to its upstream neighbor.
  921.  
  922.    -  The switch then deletes the endstation from its local database,
  923.       as well as any entries associated with the endstation in its
  924.       connection table.
  925.  
  926.    When the originating switch has received responses to all the
  927.    Interswitch New User Request messages it has sent, it does the
  928.    following:
  929.  
  930.    -  If it has received a response message with a status of
  931.       NewUserAck, it loads the new VLAN information into its local
  932.       database.
  933.  
  934.    -  If all responses have been received with a status of
  935.       NewUserUnknown, the originating switch assumes that the
  936.       endstation was not previously connected anywhere in the network
  937.       and assigns it to a VLAN according to the VLAN membership rules
  938.       and order of precedence.
  939.  
  940.    If any Interswitch New User Request message has not been responded
  941.    to within a certain predetermined time (currently 5 seconds), the
  942.    originating switch recalculates the switch flood path and resends
  943.    the Interswitch New User Request message.
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Ruffen, et al.               Informational                     [Page 17]
  955.  
  956. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  957.  
  958.  
  959. 4.1.3 Local Delete Server
  960.  
  961.    The Directory Local Delete server removes entries (both local and
  962.    remote) from the local Node and Alias Tables.  It is invoked when
  963.    an endstation, previously known to be attached to one switch, has
  964.    been moved and discovered on another switch.
  965.  
  966.    Note also that remote entries are cached and are purged from the
  967.    tables on a first-in/first-out basis as space is needed in the
  968.    cache.
  969.  
  970. 4.2 Topology Service Center
  971.  
  972.    The Topology Service Center is responsible for maintaining three
  973.    databases relating to the topology of the switch fabric:
  974.  
  975.    -  The topology table of SFVLAN switches that are physical
  976.       neighbors to the local switch.
  977.  
  978.    -  The spanning tree that defines the loop-free switch flood path
  979.       used for transmitting undirected interswitch messages.
  980.  
  981.    -  The directed graph that is used to calculate the best path(s)
  982.       for call connections.
  983.  
  984. 4.2.1 Neighbor Discovery Server
  985.  
  986.    The Topology Neighbor Discovery server uses Interswitch Keepalive
  987.    messages to detect the switch's neighbors and establish the
  988.    topology of the switching fabric.  Interswitch Keepalive messages
  989.    are exchanged in accordance with Cabletron's VlanHello protocol,
  990.    described in detail in [IDhello].
  991.  
  992. 4.2.2 Spanning Tree Server
  993.  
  994.    The Topology Spanning Tree server is invoked by the Topology
  995.    Neighbor Discovery server when a neighboring SFVLAN switch is
  996.    either discovered or lost -- that is, when the operational status
  997.    of a network link changes.
  998.  
  999.    The Spanning Tree server exchanges interswitch messages with
  1000.    neighboring SFVLAN switches to calculate the switch flood path
  1001.    over which undirected interswitch messages are sent.  There are
  1002.    two parts to this process:
  1003.  
  1004.    -  Creating and maintaining the spanning tree
  1005.    -  Remote blocking
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Ruffen, et al.               Informational                     [Page 18]
  1011.  
  1012. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1013.  
  1014.  
  1015. 4.2.2.1 Creating and Maintaining the Spanning Tree
  1016.  
  1017.    In a network with redundant network links, a packet traveling between
  1018.    switches can potentially be caught in an infinite loop -- an
  1019.    intolerable situation in a networking environment.  However, it is
  1020.    possible to reduce a network topology to a single configuration
  1021.    (known as a spanning tree) such that there is, at most, one path
  1022.    between any two switches.
  1023.  
  1024.    Within the SFVLAN product, the spanning tree is created and
  1025.    maintained using the Spanning Tree Algorithm defined by the IEEE
  1026.    802.1d standard.
  1027.  
  1028.       Note:
  1029.  
  1030.          A detailed discussion of this algorithm is beyond the scope of
  1031.          this document.  See [IEEE] for more information.
  1032.  
  1033.    To implement the Spanning Tree Algorithm, SFVLAN switches exchange
  1034.    Interswitch BPDU messages (Section 6.2) containing encapsulated
  1035.    IEEE-compliant 802.2 Bridge Protocol Data Units (BPDUs).  There are
  1036.    two types of BPDUs:
  1037.  
  1038.    -  Configuration (CFG) BPDUs are exchanged during the switch
  1039.       discovery process, following the receipt of an Interswitch
  1040.       Keepalive message.  They are used to create the initial the
  1041.       spanning tree.
  1042.  
  1043.    -  Topology Change Notification (TCN) BPDUs are exchanged when
  1044.       changes in the network topology are detected.  They are used to
  1045.       redefine the spanning tree to reflect the current topology.
  1046.  
  1047.    See [IEEE] for detailed descriptions of these BPDUs.
  1048.  
  1049. 4.2.2.2 Remote Blocking
  1050.  
  1051.    After the spanning tree has been computed, each network port on an
  1052.    SFVLAN switch will be in one of two states:
  1053.  
  1054.    -  Forwarding.  A port in the Forwarding state will be used to
  1055.       transmit all ISMP messages.
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Ruffen, et al.               Informational                     [Page 19]
  1067.  
  1068. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1069.  
  1070.  
  1071.    -  Blocking.  A port in the Blocking state will not be used to
  1072.       forward undirected ISMP messages.  Blocking the rebroadcast of
  1073.       these messages on selected ports prevents message duplication
  1074.       arising from multiple paths that exist in the network topology.
  1075.       Note that all other types of ISMP message will be transmitted.
  1076.  
  1077.       Note:
  1078.  
  1079.          The IEEE 802.1d standard specifies other port states used
  1080.          during the initial creation of the spanning tree. These states
  1081.          are not relevant to the discussion here.
  1082.  
  1083.    Note that although a port in the Blocking state will not forward
  1084.    undirected ISMP messages, it may still receive them.  Any such
  1085.    message received will ultimately be discarded, but at the cost of CPU
  1086.    time necessary to process the packet.
  1087.  
  1088.    To prevent the transmission of undirected messages to a port, the
  1089.    port's owner switch can set remote blocking on the link by sending an
  1090.    Interswitch Remote Blocking message (Section 6.3) out over the port.
  1091.    This notifies the switch on the other end of the link that undirected
  1092.    messages should not be sent over the link, regardless of the state of
  1093.    the sending port.
  1094.  
  1095.    Each SFVLAN switch sends an Interswitch Remote Blocking message out
  1096.    over all its blocked network ports every 5 seconds.  A flag within
  1097.    the message indicates whether remote blocking should be turned on or
  1098.    off over the link.
  1099.  
  1100. 4.2.3 Link State Server
  1101.  
  1102.    The Topology Link State server is invoked by any process that detects
  1103.    a change in the state of the network links of the local switch.
  1104.    These changes include (but are not limited to) changes in operational
  1105.    or administrative status of the link, path "cost" or bandwidth.
  1106.  
  1107.    The Link State server runs Cabletron's Virtual LAN Link State (VLS)
  1108.    protocol which exchanges interswitch messages with neighboring SFVLAN
  1109.    switches to calculate the set of best paths between the local switch
  1110.    and all other switches in the fabric. (The VLS protocol is described
  1111.    in detail in [IDvlsp].)
  1112.  
  1113.    The Link State server also notifies the Connect Service Center
  1114.    (Section 4.5) of any remote links that have failed, thereby
  1115.    necessitating potential tear-down of current connections.
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Ruffen, et al.               Informational                     [Page 20]
  1123.  
  1124. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1125.  
  1126.  
  1127. 4.3 Resolve Service Center
  1128.  
  1129.    The Resolve Service Center is responsible for resolving the
  1130.    destination address of broadcast data packets (such as an IP ARP
  1131.    packet) to a unicast MAC address to be used in mapping the call
  1132.    connection.  To do this, the Resolve Service Center attempts to
  1133.    resolve such broadcast packets directly at the access port of the
  1134.    ingress switch.
  1135.  
  1136.    Address resolution is accomplished as follows:
  1137.  
  1138.    1) First, an attempt is made to resolve the address from the switch's
  1139.       local databases by calling the following servers:
  1140.  
  1141.       -  The Table server attempts to resolve the address from the
  1142.          Resolve Table (Section 4.3.1).
  1143.  
  1144.       -  Next, the Local server attempts to resolve the address from the
  1145.          Node and Alias Tables (Section 4.3.2).
  1146.  
  1147.       -  If the address is not found in these tables but is an IP
  1148.          address, the Resolve Subnet server (Section 4.3.3) is also
  1149.          called.
  1150.  
  1151.    2) If the address cannot be resolved locally, the Interswitch Resolve
  1152.       server (Section 4.3.4) is called to access the "virtual directory"
  1153.       by sending an Interswitch Resolve request message out over the
  1154.       switch flood path.
  1155.  
  1156.    3) If the address cannot be resolved either locally or via an
  1157.       Interswitch Resolve message -- that is, the destination endstation
  1158.       is unknown to any switch, perhaps because it has never transmitted
  1159.       a packet to its switch -- the following steps are taken:
  1160.  
  1161.       -  The Unresolvable server (Section 4.3.5) is called to record the
  1162.          unresolved packet.
  1163.  
  1164.       -  The Block server (Section 4.3.6) is called to determine whether
  1165.          the address should be added to the Block Table.
  1166.  
  1167.       -  The Flood Service Center (Section 4.8) is called to broadcast
  1168.          the packet to other SFVLAN switches using a tag-based flooding
  1169.          mechanism.
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Ruffen, et al.               Informational                     [Page 21]
  1179.  
  1180. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1181.  
  1182.  
  1183. 4.3.1 Table Server
  1184.  
  1185.    The Resolve Table server maintains the Resolve Table which contains a
  1186.    collection of addresses that might not be resolvable in the normal
  1187.    fashion.  This table typically contains such things as the addresses
  1188.    of "quiet" devices that do not send data packets or special mappings
  1189.    of IP addresses behind a router.  Entries can be added to or deleted
  1190.    from the Resolve Table via an external management application.
  1191.  
  1192. 4.3.2 Local Server
  1193.  
  1194.    The Resolve Local server checks the Node and Alias Tables maintained
  1195.    by the Directory Service Center (Section 4.1) to determine if it can
  1196.    resolve the address.
  1197.  
  1198. 4.3.3 Subnet Server
  1199.  
  1200.    If the address to be resolved is an IP address but cannot be resolved
  1201.    via the standard processing described above, the Resolve Subnet
  1202.    server applies the subnet mask to the IP address and then does a
  1203.    lookup in the Resolve Table.
  1204.  
  1205. 4.3.4 Interswitch Resolve Server
  1206.  
  1207.    If the address cannot be resolved locally, the Interswitch Resolve
  1208.    server accesses the "virtual directory" by sending an Interswitch
  1209.    Resolve request message (Section 6.4) out over the switch flood path.
  1210.    The Interswitch Resolve request message contains the destination
  1211.    address as it was received within the packet, along with a list of
  1212.    requested addressing information.
  1213.  
  1214.    When a switch receives an Interswitch Resolve request message from
  1215.    one of its upstream neighbors, it checks to see if the destination
  1216.    endstation is connected to one of its local access ports.  If so, it
  1217.    formulates an Interswitch Resolve response message by filling in the
  1218.    requested address information, along with its own MAC address.  It
  1219.    then sets the message status field to ResolveAck, and returns the
  1220.    message to its upstream (requesting) neighbor.
  1221.  
  1222.    If the receiving switch cannot resolve the address, it forwards the
  1223.    Interswitch Resolve request message to its downstream neighbors.  If
  1224.    the switch has no downstream neighbors, it sets the message status
  1225.    field to Unknown, and returns the message to its upstream
  1226.    (requesting) neighbor.
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Ruffen, et al.               Informational                     [Page 22]
  1235.  
  1236. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1237.  
  1238.  
  1239.    When a switch forwards an Interswitch Resolve request message to its
  1240.    downstream neighbors, it keeps track of the number of requests it has
  1241.    sent out and received back.  It will only respond back to its
  1242.    upstream (requesting) neighbor when one of the following conditions
  1243.    occurs:
  1244.  
  1245.    -  It receives any response with a status of ResolveAck
  1246.  
  1247.    -  All downstream neighbors have responded with a status of Unknown
  1248.  
  1249.    Any Interswitch Resolve request message that is not responded to
  1250.    within a certain predetermined time (currently 5 seconds) is assumed
  1251.    to have a response status of Unknown.
  1252.  
  1253.    When the Interswitch Resolve server receives a successful Interswitch
  1254.    Resolve response message, it records the resolved address information
  1255.    in the remote cache of its local directory for use in resolving later
  1256.    packets for the same endstation.  Note that this process results in
  1257.    each switch building its own unique copy of the virtual directory
  1258.    containing only the endstation addresses in which it is interested.
  1259.  
  1260. 4.3.5 Unresolvable Server
  1261.  
  1262.    The Unresolvable server is called when a packet destination address
  1263.    cannot be resolved.  The server records the packet in a table that
  1264.    can then be examined to determine which endstations are generating
  1265.    unresolvable traffic.
  1266.  
  1267.    Also, if a particular destination is repeatedly seen to be
  1268.    unresolvable, the server calls the Block server (Section 4.3.6) to
  1269.    determine whether the address should be blocked.
  1270.  
  1271. 4.3.6 Block Server
  1272.  
  1273.    The Resolve Block server is called when a particular destination has
  1274.    been repeatedly seen to be unresolvable.  This typically happens
  1275.    when, unknown to the packet source, the destination endstation is
  1276.    either not currently available or no longer exists.
  1277.  
  1278.    If the Block server determines that the unresolved address has
  1279.    exceeded a configurable request threshold, the address is added to
  1280.    the server's Block Table.  Interswitch Resolve request messages for
  1281.    addresses listed in the Block Table are sent less frequently, thereby
  1282.    reducing the amount of Interswitch Resolve traffic throughout the
  1283.    fabric.
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Ruffen, et al.               Informational                     [Page 23]
  1291.  
  1292. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1293.  
  1294.  
  1295.    If an address listed in the Block Table is later successfully
  1296.    resolved by and Interswitch Resolve request message, the address is
  1297.    removed from the table.
  1298.  
  1299. 4.4 Policy Service Center
  1300.  
  1301.    Once the destination address of the call packet has been resolved,
  1302.    the Policy Service Center is called to determine the validity of the
  1303.    requested call connection based on the VLAN policy of the source and
  1304.    destination VLANs.
  1305.  
  1306. 4.4.1 Unicast Rules Server
  1307.  
  1308.    The Policy Unicast Rules server recognizes two VLAN policy values:
  1309.    Open or Secure.  The default policy for all VLANs is Open.
  1310.  
  1311.    The policy value is used as follows when determining the validity of
  1312.    a requested call connection:
  1313.  
  1314.    -  If the VLAN policy of either the source or destination cannot be
  1315.       determined, the Filter Service Center is called to establish a
  1316.       filter (i.e., blocked) for the SA/DA pair.
  1317.  
  1318.    -  If the source and destination endstations belong to the same VLAN,
  1319.       then the connection is permitted regardless of the VLAN policy.
  1320.  
  1321.    -  If the source and destination endstations belong to different
  1322.       VLANs, but both VLANs are running with an Open policy, then the
  1323.       connection is permitted, providing cut-through switching between
  1324.       different VLAN(s).
  1325.  
  1326.    -  If the source and destination endstations belong to different
  1327.       VLANs and one or both of the VLANs are running with a Secure
  1328.       policy, then the Flood Service Center (Section 4.8) is called to
  1329.       broadcast the packet to other SFVLAN switches having ports or
  1330.       endstations that belong to the same VLAN as the packet source.
  1331.  
  1332.       Note that if any of the VLANs to which the source or destination
  1333.       belong has a Secure policy, then the policy used in the above
  1334.       algorithm is Secure.
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Ruffen, et al.               Informational                     [Page 24]
  1347.  
  1348. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1349.  
  1350.  
  1351. 4.5 Connect Service Center
  1352.  
  1353.    Once the Policy Service Center (Section 4.4) has determined that a
  1354.    requested call connection is valid, the Connect Service Center is
  1355.    called to set up the connection.  Note that connectivity between two
  1356.    endstations within the fabric is established on a switch-by-switch
  1357.    basis as the call progresses through the fabric toward its
  1358.    destination.  No synchronization is needed between switches to
  1359.    establish an end-to-end connection.
  1360.  
  1361.    The Connect Service Center maintains a Connection Table containing
  1362.    information for all connections currently active on the switch's
  1363.    local ports.
  1364.  
  1365.    Connections are removed from the Connection Table when one of the
  1366.    endstations is moved to a new switch (Section 4.1.2) or when the
  1367.    Topology Link State server (Section 4.2.3) notifies the Connect
  1368.    Service Center that a network link has failed.  Otherwise,
  1369.    connections are not automatically aged out or removed from the
  1370.    Connection Table until a certain percentage threshold (HiMark) of
  1371.    table capacity is reached and resources are needed.  At that point,
  1372.    some number of connections (typically 100) are aged out and removed
  1373.    at one time.
  1374.  
  1375. 4.5.1 Local Server
  1376.  
  1377.    If the destination endstation resides on the local switch, the
  1378.    Connect Local server establishes a connection between the source and
  1379.    destination ports.  Note that if the source and destination both
  1380.    reside on the same physical port, a filter connection is established
  1381.    by calling the Filter Service Center (Section 4.6).
  1382.  
  1383. 4.5.2 Link State Server
  1384.  
  1385.    The Connect Link State server is called if the destination endstation
  1386.    of the proposed connection does not reside on the local switch.
  1387.  
  1388.    The server executes a call to the Path Link State server (Section
  1389.    4.7.1) which returns up to three "best" paths of equal cost from the
  1390.    local switch to the destination switch.  If more than one path is
  1391.    returned, the server chooses a path that provides the best load
  1392.    balancing of user traffic across the fabric.
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Ruffen, et al.               Informational                     [Page 25]
  1403.  
  1404. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1405.  
  1406.  
  1407. 4.5.3 Directory Server
  1408.  
  1409.    The Connect Directory server is called if the Connect Link State
  1410.    server is unable to provide a path for some reason.
  1411.  
  1412.    The server examines the local directory to determine on which switch
  1413.    the destination endstation resides.  If the port of access to the
  1414.    destination switch is known, then a connection is established using
  1415.    that port as the outport of the connection.
  1416.  
  1417. 4.6 Filter Service Center
  1418.  
  1419.    The Filter Service Center is responsible for establishing filtered
  1420.    connections.  This service center is called by the Connect Local
  1421.    server (Section 4.5.1) if the source and destination endstations
  1422.    reside on the same physical port, and by the Policy Service Center
  1423.    (Section 4.4) if the VLAN of either the source or destination is
  1424.    indeterminate.
  1425.  
  1426.    A filter connection is programmed in the switch hardware with no
  1427.    specified outport.  That is, the connection is programmed to discard
  1428.    any traffic for that SA/DA pair.
  1429.  
  1430. 4.7 Path Service Center
  1431.  
  1432.    The Path Service Center is responsible for determining the path from
  1433.    a source to a destination.
  1434.  
  1435. 4.7.1 Link State Server
  1436.  
  1437.    The Path Link State server is called by the Connect Link State server
  1438.    (Section 4.5.2) to return up to three best paths of equal cost
  1439.    between a source and destination pair of endstations.  These best
  1440.    paths are calculated by the Topology Link State server (Section
  1441.    4.2.3).
  1442.  
  1443.    The Path Link State server is also called by the Connect Service
  1444.    Center to return a complete source-to-destination path consisting of
  1445.    a list of individual switch port names.  A switch port name consists
  1446.    of the switch base MAC address and a port instance relative to the
  1447.    switch.
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Ruffen, et al.               Informational                     [Page 26]
  1459.  
  1460. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1461.  
  1462.  
  1463. 4.7.2 Spanning Tree Server
  1464.  
  1465.    The Path Spanning Tree server is called by any server needing to
  1466.    forward an undirected message out over the switch flood path.  The
  1467.    server returns a port mask indicating which local ports are currently
  1468.    enabled as outports of the switch flood path.  The switch flood path
  1469.    is calculated by the Topology Spanning Tree server (Section 4.2.2).
  1470.  
  1471. 4.8 Flood Service Center
  1472.  
  1473.    If the Resolve Service Center (Section 4.3) is unable to resolve the
  1474.    destination address of a packet, it invokes the Flood Service Center
  1475.    to broadcast the unresolved packet.
  1476.  
  1477. 4.8.1 Tag-Based Flood Server
  1478.  
  1479.    The Tag-Based Flood server encapsulates the unresolved packet into an
  1480.    Interswitch Tag-Based Flood message (Section 6.6), along with a list
  1481.    of Virtual LAN identifiers specifying those VLANs to which the source
  1482.    endstation belongs.  The message is then sent out over the switch
  1483.    flood path to all other switches in the fabric.
  1484.  
  1485.    When a switch receives an Interswitch Tag-Based Flood message, it
  1486.    examines the encapsulated header to determine the VLAN(s) to which
  1487.    the packet should be sent.  If any of the switch's local access ports
  1488.    belong to one or more of the specified VLANs, the switch strips off
  1489.    the tag-based header and forwards the original packet out the
  1490.    appropriate access port(s).
  1491.  
  1492.    The switch also forwards the entire encapsulated packet along the
  1493.    switch flood path to its downstream neighboring switches, if any.
  1494.  
  1495. 5. Monitoring Call Connections
  1496.  
  1497.    The SecureFast VLAN product permits monitoring of user traffic moving
  1498.    between two endstations by establishing a call tap on the connection
  1499.    between the two stations.  Traffic can be monitored in one or both
  1500.    directions along the connection path.
  1501.  
  1502. 5.1 Definitions
  1503.  
  1504.    In addition to the terms defined in Section 1.2, the following terms
  1505.    are used in this description of the call tap process.
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Ruffen, et al.               Informational                     [Page 27]
  1515.  
  1516. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1517.  
  1518.  
  1519.    Originating Switch
  1520.  
  1521.       The originating switch is the switch that requests the call tap.
  1522.       Any switch along a call connection path may request a tap on that
  1523.       call connection.
  1524.  
  1525.    Probe
  1526.  
  1527.       The tap probe is the device to receive a copy of the call
  1528.       connection data.  The probe is attached to a port on the probe
  1529.       switch.
  1530.  
  1531.    Probe Switch
  1532.  
  1533.       The probe switch (also known as the terminating switch) is the
  1534.       switch to which the probe is attached.  The probe switch can be
  1535.       anywhere in the topology.
  1536.  
  1537. 5.2 Tapping a Connection
  1538.  
  1539.    A request to tap a call connection between two endstations can
  1540.    originate on any switch along the call connection path -- the ingress
  1541.    switch, the egress switch, or any of the intermediate switches.  The
  1542.    call connection must have already been established before a call tap
  1543.    request can be issued.  The probe device can be attached to any
  1544.    switch in the topology.
  1545.  
  1546. 5.2.1 Types of Tap Connections
  1547.  
  1548.    A call tap is enabled by setting up an auxiliary tap connection
  1549.    associated with the call being monitored.  Since the tap must
  1550.    originate on a switch somewhere along the call connection path, the
  1551.    tap connection path will pass through one or more of the switches
  1552.    along the call path.  However, since the probe switch can be anywhere
  1553.    in the switch fabric, the tap path and the call path may diverge at
  1554.    some point.
  1555.  
  1556.    Therefore, on each switch along the tap path, the tap connection is
  1557.    established in one of three ways:
  1558.  
  1559.    -  The existing call connection is used with no modification.
  1560.  
  1561.          When both the call path and tap path pass through the switch,
  1562.          and the inport and outports of both connections are identical,
  1563.          the switch uses the existing call connection to route the tap.
  1564.  
  1565.    -  The existing call connection is modified.
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Ruffen, et al.               Informational                     [Page 28]
  1571.  
  1572. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1573.  
  1574.  
  1575.          When both the call path and tap path pass through the switch,
  1576.          but the call path outport is different from the tap path
  1577.          outport, the switch enables an extra outport in either one or
  1578.          both directions of the call connection, depending on the
  1579.          direction of the tap.  This happens under two conditions.
  1580.  
  1581.    -  If the switch is also the probe switch, an extra outport is
  1582.          enabled to the probe.
  1583.  
  1584.    -  If the switch is the point at which the call path and the tap path
  1585.          diverge, an extra outport is enabled to the downstream neighbor
  1586.          on that leg of the switch flood path on which the probe switch
  1587.          is located.
  1588.  
  1589.    -  A new connection is established.
  1590.  
  1591.          If the call path does not pass through the switch (because the
  1592.          tap path has diverged from the call path), a completely new
  1593.          connection is established for the tap.
  1594.  
  1595. 5.2.2 Locating the Probe and Establishing the Tap Connection
  1596.  
  1597.    To establish a call tap, the originating switch formats an
  1598.    Interswitch Tap request message (Section 6.7) and sends it out over
  1599.    the switch flood path to all other switches in the topology.
  1600.  
  1601.       Note:
  1602.  
  1603.          If the originating switch is also the probe switch, no
  1604.          Interswitch Tap request message is necessary.
  1605.  
  1606.    As the Interswitch Tap request message travels out along the switch
  1607.    flood path, each switch receiving the message checks to see if it is
  1608.    the probe switch and does the following:
  1609.  
  1610.    -  If the switch is the probe switch, it establishes the tap
  1611.       connection by either setting up a new connection or modifying the
  1612.       call connection, as appropriate (see Section 5.2.1).  It then
  1613.       reformats the Tap request message to be a Tap response message
  1614.       with a status indicating that the probe has been found, and sends
  1615.       the message back to its upstream neighbor.
  1616.  
  1617.    -  If the switch is not the probe switch, it forwards the Tap request
  1618.       message to all its downstream neighbors (if any).
  1619.  
  1620.    -  If the switch is not the probe switch and has no downstream
  1621.       neighbors, it reformats the Tap request message to be a Tap
  1622.       response message with a status indicating that the probe is not
  1623.  
  1624.  
  1625.  
  1626. Ruffen, et al.               Informational                     [Page 29]
  1627.  
  1628. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1629.  
  1630.  
  1631.       located on that leg of the switch flood path.   It then sends the
  1632.       response message back to its upstream neighbor.
  1633.  
  1634.       When a switch forwards an Interswitch Tap request message to its
  1635.       downstream neighbors, it keeps track of the number of requests it
  1636.       has sent out.
  1637.  
  1638.    -  If a response is received with a status indicating that the probe
  1639.       switch is located somewhere downstream, the switch establishes the
  1640.       appropriate type of tap connection (see Section 5.2.1).  It then
  1641.       formats a Tap response message with a status indicating that the
  1642.       probe has been found and passes the message to its upstream
  1643.       neighbor.
  1644.  
  1645.    -  If no responses are received with a status indicating that the
  1646.       probe switch is located downstream, the switch formats a Tap
  1647.       response message with a status indicating that the probe has not
  1648.       been found and passes the message to its upstream neighbor.
  1649.  
  1650. 5.2.3 Status Field
  1651.  
  1652.    The status field of the Interswitch Tap request/response message
  1653.    contains information about the state of the tap.  Some of these
  1654.    status values are transient and are merely used to track the progress
  1655.    of the tap request.  Other status values are stored in the tap table
  1656.    of each switch along the tap path for use when the tap is torn down.
  1657.    The possible status values are as follows:
  1658.  
  1659.    -  StatusUnassigned.  This is the initial status of the Interswitch
  1660.       Tap request message.
  1661.  
  1662.    -  OutportDecisionUnknown.  The tap request is still moving
  1663.       downstream along the switch flood path.  The probe switch had not
  1664.       yet been found.
  1665.  
  1666.    -  ProbeNotFound.  The probe switch is not located on this leg of the
  1667.       switch flood path.
  1668.  
  1669.    -  DisableOutport.  The probe switch is located on this leg of the
  1670.       switch flood path, and the switch has had to either modify the
  1671.       call connection or establish a new connection to implement the tap
  1672.       (see Section 5.2.1).  When the tap is torn down, the switch will
  1673.       have to disable any additional outports that have been enabled for
  1674.       the tap.
  1675.  
  1676.    -  KeepOutport.  The probe switch is located on this leg of the
  1677.       switch flood path, and the switch was able to route the tap over
  1678.       the existing call path (see Section 5.2.1).  Any ports used for
  1679.  
  1680.  
  1681.  
  1682. Ruffen, et al.               Informational                     [Page 30]
  1683.  
  1684. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1685.  
  1686.  
  1687.       the tap will remain enabled when the tap is torn down.
  1688.  
  1689. 5.3 Untapping a Connection
  1690.  
  1691.    A request to untap a call connection must be issued on the tap
  1692.    originating switch -- that is, the same switch that issued the tap
  1693.    request.
  1694.  
  1695.    To untap a call connection, the originating switch sends an
  1696.    Interswitch Untap request message (Section 6.7) out over the switch
  1697.    flood path to all other switches in the topology.  The message is
  1698.    sent over the switch flood path, rather than the tap connection path,
  1699.    to ensure that all switches that know of the tap are properly
  1700.    notified, even if the switch topology has changed since the tap was
  1701.    established.
  1702.  
  1703.    When a switch receives an Interswitch Untap request message, it
  1704.    checks to see if it is handling a tap for the specified call
  1705.    connection.  If so, the switch disables the tap connection, as
  1706.    follows:
  1707.  
  1708.    -  If a new connection was added for the tap, the connection is
  1709.       deleted from the connection table.
  1710.  
  1711.    -  If additional outports were enabled on the call connection, they
  1712.       are disabled.
  1713.  
  1714.    The switch then forwards the Interswitch Untap request message to its
  1715.    downstream neighbor (if any).  If the switch has no downstream
  1716.    neighbors, it formats an untap response and sends the message back to
  1717.    its upstream neighbor.
  1718.  
  1719.    When a switch forwards an Interswitch Untap request message to its
  1720.    downstream neighbors, it keeps track of the number of requests it has
  1721.    sent out and does not respond back to its upstream neighbor until all
  1722.    untap requests have been responded to.  Once all responses have been
  1723.    received, the switch handles any final cleanup for the tap and then
  1724.    sends a single Interswitch Untap response message to its upstream
  1725.    neighbor.
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Ruffen, et al.               Informational                     [Page 31]
  1739.  
  1740. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1741.  
  1742.  
  1743. 6. Interswitch Message Protocol (ISMP)
  1744.  
  1745.    The InterSwitch Message protocol (ISMP) provides a consistent method
  1746.    of encapsulating and transmitting messages exchanged between switches
  1747.    to create and maintain the databases and provide other control
  1748.    services and functionality required by the SFVLAN product.
  1749.  
  1750. 6.1 General Packet Structure
  1751.  
  1752.    ISMP packets are of variable length and have the following general
  1753.    structure:
  1754.  
  1755.    -  Frame header
  1756.    -  ISMP packet header
  1757.    -  ISMP message body
  1758.  
  1759.    Each of these packet segments is discussed separately in the
  1760.    following subsections.
  1761.  
  1762. 6.1.1 Frame Header
  1763.  
  1764.    ISMP packets are encapsulated within an IEEE 802-compliant frame
  1765.    using a standard header as shown below:
  1766.  
  1767.        0                   1                   2                   3
  1768.        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
  1769.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1770.    00 |                                                               |
  1771.       +      Destination address      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1772.    04 |                               |                               |
  1773.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        Source address         +
  1774.    08 |                                                               |
  1775.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1776.    12 |             Type              |                               |
  1777.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  1778.    16 |                                                               |
  1779.       +                                                               +
  1780.       :                                                               :
  1781.  
  1782.  
  1783.    Destination address
  1784.  
  1785.       This 6-octet field contains the Media Access Control (MAC) address
  1786.       of the multicast channel over which all switches in the fabric
  1787.       receive ISMP packets.  Except where otherwise noted, this field
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Ruffen, et al.               Informational                     [Page 32]
  1795.  
  1796. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1797.  
  1798.  
  1799.       contains the multicast address of the control channel over which
  1800.       all switches in the fabric receive ISMP packets -- a value of 01-
  1801.       00-1D-00-00-00.
  1802.  
  1803.    Source address
  1804.  
  1805.       Except where otherwise noted, this 6-octet field contains the
  1806.       physical (MAC) address of the switch originating the ISMP packet.
  1807.  
  1808.    Type
  1809.  
  1810.       This 2-octet field identifies the type of data carried within the
  1811.       frame.  Except where otherwise noted, the type field of ISMP
  1812.       packets contains the value 0x81FD.
  1813.  
  1814. 6.1.2 ISMP Packet Header
  1815.  
  1816.    There are two versions of the ISMP packet header in use by the
  1817.    SecureFast VLAN product.
  1818.  
  1819. 6.1.2.1 Version 2
  1820.  
  1821.    The version 2 ISMP packet header consists of 6 octets, as shown
  1822.    below:
  1823.  
  1824.        0                   1                   2                   3
  1825.        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
  1826.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1827.    00 |///////////////////////////////////////////////////////////////|
  1828.       ://////// Frame header /////////////////////////////////////////:
  1829.       +//////// (14 octets)  /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1830.    12 |///////////////////////////////|            Version            |
  1831.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1832.    16 |       ISMP message type       |        Sequence number        |
  1833.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1834.    20 |                                                               |
  1835.       +                                                               +
  1836.       :                                                               :
  1837.  
  1838.    Frame header
  1839.  
  1840.       This 14-octet field contains the frame header (Section 6.1.1).
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Ruffen, et al.               Informational                     [Page 33]
  1851.  
  1852. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1853.  
  1854.  
  1855.    Version
  1856.  
  1857.       This 2-octet field contains the version number of the InterSwitch
  1858.       Message Protocol to which this ISMP packet adheres. This document
  1859.       describes ISMP Version 2.0.
  1860.  
  1861.    ISMP message type
  1862.  
  1863.       This 2-octet field contains a value indicating which type of ISMP
  1864.       message is contained within the message body.  The following table
  1865.       lists each ISMP message, along with its message type and the
  1866.       section within this document that describes the message in detail:
  1867.  
  1868.          Message Name                       Type    Description
  1869.  
  1870.          Interswitch Link State message        3    See note below
  1871.          Interswitch BPDU message              4    Section 6.2
  1872.          Interswitch Remote Blocking message   4    Section 6.3
  1873.          Interswitch Resolve message           5    Section 6.4
  1874.          Interswitch New User message          5    Section 6.5
  1875.          Interswitch Tag-Based Flood message   7    Section 6.6
  1876.          Interswitch Tap/Untap message         8    Section 6.7
  1877.  
  1878.       Note:
  1879.  
  1880.          The Link State messages used by the VLS Protocol are not
  1881.          described in this document.  For a detailed description of
  1882.          these messages, see [IDvlsp].
  1883.  
  1884.    Sequence number
  1885.  
  1886.       This 2-octet field contains an internally generated sequence
  1887.       number used by the various protocol handlers for internal
  1888.       synchronization of messages.
  1889.  
  1890. 6.1.2.2 Version 3
  1891.  
  1892.    The version 3 ISMP packet header is used only by the Interswitch
  1893.    Keepalive message.  That message is not described in this document.
  1894.    For a detailed description of the version 3 ISMP packet header, see
  1895.    [IDhello].
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Ruffen, et al.               Informational                     [Page 34]
  1907.  
  1908. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1909.  
  1910.  
  1911. 6.1.3 ISMP Message Body
  1912.  
  1913.    The ISMP message body is a variable-length field containing the
  1914.    actual data of the ISMP message.  The length and content of this
  1915.    field are determined by the value found in the message type field.
  1916.  
  1917.    See the following sections for the exact format of each message type.
  1918.  
  1919. 6.2 Interswitch BPDU Message
  1920.  
  1921.    The Interswitch BPDU message consists of a variable number of octets,
  1922.    as shown below:
  1923.  
  1924.        0                   1                   2                   3
  1925.        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
  1926.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1927.    00 |                                                               |
  1928.       +                         Frame header /                        +
  1929.       :                   ISMP packet header (type 4)                 :
  1930.       |                                                               |
  1931.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1932.    20 |            Version            |            Opcode             |
  1933.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1934.    24 |          Message flags        |                               |
  1935.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  1936.    28 |                                                               |
  1937.       :                          BPDU packet                          :
  1938.       |                                                               |
  1939.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1940.  
  1941.  
  1942.    Frame header/ISMP packet header
  1943.  
  1944.       This 20-octet field contains the frame header and the ISMP packet
  1945.       header.
  1946.  
  1947.    Version
  1948.  
  1949.       This 2-octet field contains the version number of the message
  1950.       type.  This document describes ISMP message type 4, version 1.
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Ruffen, et al.               Informational                     [Page 35]
  1963.  
  1964. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  1965.  
  1966.  
  1967.    Opcode
  1968.  
  1969.       This 2-octet field contains the operation type of the message. For
  1970.       an Interswitch BPDU message, the value should be 1.
  1971.  
  1972.    Message flags
  1973.  
  1974.       This 2-octet field is currently unused.  It is reserved for future
  1975.       use.
  1976.  
  1977.    BPDU packet
  1978.  
  1979.       This variable-length field contains an IEEE-compliant 802.2 Bridge
  1980.       Protocol Data Unit.  See [IEEE] for a detailed description of the
  1981.       contents of this field.
  1982.  
  1983. 6.3 Interswitch Remote Blocking Message
  1984.  
  1985.    The Interswitch Remote Blocking message consists of 30 octets, as
  1986.    shown below:
  1987.  
  1988.        0                   1                   2                   3
  1989.        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
  1990.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1991.    00 |                                                               |
  1992.       +                         Frame header /                        +
  1993.       :                   ISMP packet header (type 4)                 :
  1994.       |                                                               |
  1995.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1996.    20 |            Version            |           Opcode              |
  1997.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1998.    24 |          Message flags        |        Blocking flag ...      |
  1999.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2000.    28 |       ... Blocking flag       |
  2001.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2002.  
  2003.  
  2004.    Frame header/ISMP packet header
  2005.  
  2006.       This 20-octet field contains the frame header and the ISMP packet
  2007.       header.
  2008.  
  2009.    Version
  2010.  
  2011.       This 2-octet field contains the version number of the message
  2012.       type.  This document describes ISMP message type 4, version 1.
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Ruffen, et al.               Informational                     [Page 36]
  2019.  
  2020. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2021.  
  2022.  
  2023.    Opcode
  2024.  
  2025.       This 2-octet field contains the operation type of the message.
  2026.       Valid values are as follows:
  2027.  
  2028.          2   Enable/disable remote blocking
  2029.          3   Acknowledge previously received Remote Blocking message
  2030.  
  2031.    Message flags
  2032.  
  2033.          This 2-octet field is currently unused.  It is reserved for
  2034.          future use.
  2035.  
  2036.    Blocking flag
  2037.  
  2038.          This 4-octet field contains a flag indicating the state of
  2039.          remote blocking on the link over which the message was
  2040.          received.  A value of 1 indicates remote blocking is on and no
  2041.          undirected ISMP messages should be sent over the link.  A value
  2042.          of 0 indicates remote blocking is off.  This flag is irrelevant
  2043.          if the operation type (Opcode) of the message has a value of 3.
  2044.  
  2045. 6.4 Interswitch Resolve Message
  2046.  
  2047.    There are two versions of the Interswitch Resolve message used by the
  2048.    SecureFast VLAN product.
  2049.  
  2050. 6.4.1 Prior to Version 1.8
  2051.  
  2052.    The Interswitch Resolve message used by SFVLAN prior to version 1.8
  2053.    consists of a variable number of octets, as shown below:
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Ruffen, et al.               Informational                     [Page 37]
  2075.  
  2076. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2077.  
  2078.  
  2079.         0                   1                   2                   3
  2080.         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
  2081.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2082.     00 |                                                               |
  2083.        +                         Frame header /                        +
  2084.        :                   ISMP packet header (type 5)                 :
  2085.        |                                                               |
  2086.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2087.     20 |           Version             |            Opcode             |
  2088.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2089.     24 |            Status             |           Call Tag            |
  2090.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2091.     28 |                                                               |
  2092.        +     Source MAC of packet      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2093.     32 |                               |                               |
  2094.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Originating switch MAC    +
  2095.     36 |                                                               |
  2096.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2097.     40 |                                                               |
  2098.        +       Owner switch MAC        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2099.     44 |                               |                               |
  2100.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  2101.     48 |                                                               |
  2102.        :                   Known destination address                   :
  2103.        |                                                               |
  2104.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2105.      n |     Count     |                                               |
  2106.        +-+-+-+-+-+-+-+-+                                               +
  2107.    n+4 |                         Resolve list                          |
  2108.        :                                                               :
  2109.        |                                                               |
  2110.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2111.  
  2112.           n = 46 + length of known address TLV
  2113.  
  2114.    In the following description of the message fields, the term
  2115.    "originating" switch refers to the switch that issued the original
  2116.    Interswitch Resolve request.  The term "owner" switch refers to that
  2117.    switch to which the destination endstation is attached.  And the term
  2118.    "responding" switch refers to either the "owner" switch or to a
  2119.    switch at the end of the switch flood path that does not own the
  2120.    endstation but issues an Interswitch Resolve response because it has
  2121.    no downstream neighbors.
  2122.  
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Ruffen, et al.               Informational                     [Page 38]
  2131.  
  2132. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2133.  
  2134.  
  2135.    With the exception of the resolve list (which has a different size
  2136.    and format in a Resolve response message), all fields of an
  2137.    Interswitch Resolve message are allocated by the originating switch,
  2138.    and unless otherwise noted below, are written by the originating
  2139.    switch.
  2140.  
  2141.    Frame header/ISMP packet header
  2142.  
  2143.       This 20-octet field contains the frame header and the ISMP packet
  2144.       header.
  2145.  
  2146.    Version
  2147.  
  2148.       This 2-octet field contains the version number of the message
  2149.       type.  This document describes ISMP message type 5, version 1.
  2150.  
  2151.    Opcode
  2152.  
  2153.       This 2-octet field contains the operation code of the message.
  2154.       Valid values are as follows:
  2155.  
  2156.          1    The message is a Resolve request.
  2157.          2    The message is a Resolve response.
  2158.          3    (unused in Resolve messages)
  2159.          4    (unused in Resolve messages)
  2160.  
  2161.       The originating switch writes a value of 1 to this field, while
  2162.       the responding switch writes a value of 2.
  2163.  
  2164.    Status
  2165.  
  2166.       This 2-octet field contains the status of a Resolve response
  2167.       message.  Valid values are as follows:
  2168.  
  2169.          0    The Resolve request succeeded (ResolveAck).
  2170.          1    (unused)
  2171.          2    The Resolve request failed (Unknown).
  2172.  
  2173.       This field is written by the responding switch.
  2174.  
  2175.    Call tag
  2176.  
  2177.       This 2-octet field contains the call tag of the endstation packet
  2178.       for which this Resolve request is issued.  The call tag is a 16-
  2179.       bit value (generated by the originating switch) that uniquely
  2180.       identifies the packet.
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Ruffen, et al.               Informational                     [Page 39]
  2187.  
  2188. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2189.  
  2190.  
  2191.    Source MAC of packet
  2192.  
  2193.       This 6-octet field contains the physical (MAC) address of the
  2194.       endstation that originated the packet identified by the call tag.
  2195.  
  2196.    Originating switch MAC
  2197.  
  2198.       This 6-octet field contains the physical (MAC) address of the
  2199.       switch that issued the original Resolve request.
  2200.  
  2201.    Owner switch MAC
  2202.  
  2203.       This 6-octet field contains the physical (MAC) address of the
  2204.       switch to which the destination endstation is attached -- that is,
  2205.       the switch that was able to resolve the requested addressing
  2206.       information.  This field is written by the owner switch.
  2207.  
  2208.       If the status of the response is Unknown, this field is
  2209.       irrelevant.
  2210.  
  2211.    Known destination address
  2212.  
  2213.       This variable-length field contains the known attribute of the
  2214.       destination endstation address.  This address is stored in
  2215.       Tag/Length/Value format.  (See Section 2.3.)
  2216.  
  2217.    Count
  2218.  
  2219.       This 1-octet field contains the number of address attributes
  2220.       requested or returned.  This is the number of items in the resolve
  2221.       list.
  2222.  
  2223.    Resolve list
  2224.  
  2225.       This variable-length field contains a list of the address
  2226.       attributes either requested by the originating switch or returned
  2227.       by the owner switch.  Note that in a Resolve request message, this
  2228.       list contains only the tags of the requested address attributes
  2229.       (see Section 2.3).  On the other hand, a Resolve response message
  2230.       with a status of ResolveAck contains the full TLV of each resolved
  2231.       address attribute.  The number of entries in the list is specified
  2232.       in the count field.
  2233.  
  2234.       In an Interswitch Resolve response message, this field is
  2235.       irrelevant if the status of the response is Unknown.
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Ruffen, et al.               Informational                     [Page 40]
  2243.  
  2244. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2245.  
  2246.  
  2247. 6.4.2 Version 1.8
  2248.  
  2249.    The Interswitch Resolve message used by SFVLAN version 1.8 consists
  2250.    of a variable number of octets, as shown below:
  2251.  
  2252.  
  2253.  
  2254.  
  2255.  
  2256.  
  2257.  
  2258.  
  2259.  
  2260.  
  2261.  
  2262.  
  2263.  
  2264.  
  2265.  
  2266.  
  2267.  
  2268.  
  2269.  
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275.  
  2276.  
  2277.  
  2278.  
  2279.  
  2280.  
  2281.  
  2282.  
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Ruffen, et al.               Informational                     [Page 41]
  2299.  
  2300. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2301.  
  2302.  
  2303.        0                   1                   2                   3
  2304.        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
  2305.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2306.    00 |                                                               |
  2307.       +                         Frame header /                        +
  2308.       :                   ISMP packet header (type 5)                 :
  2309.       |                                                               |
  2310.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2311.    20 |           Version             |            Opcode             |
  2312.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2313.    24 |            Status             |           Call Tag            |
  2314.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2315.    28 |                                                               |
  2316.       +     Source MAC of packet      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2317.    32 |                               |                               |
  2318.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Originating switch MAC    +
  2319.    36 |                                                               |
  2320.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2321.    40 |                                                               |
  2322.       +       Owner switch MAC        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2323.    44 |                               |                               |
  2324.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  2325.    48 |                                                               |
  2326.       :                   Known destination address                   :
  2327.       |                                                               |
  2328.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2329.     n |     Count     |                                               |
  2330.       +-+-+-+-+-+-+-+-+                                               +
  2331.   n+4 |                         Resolve list                          |
  2332.       :                                                               :
  2333.       |                                                               |
  2334.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2335.    n1 |                                                               |
  2336.       +    Actual dest switch MAC     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2337.       |                               |                               |
  2338.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Downlink chassis MAC      +
  2339.  n1+8 |                                                               |
  2340.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2341. n1+12 |                                                               |
  2342.       +      Actual chassis MAC       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2343.       |                               |                               |
  2344.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  2345. n1+20 |                                                               |
  2346.       +                          Domain name                          +
  2347.       :                                                               :
  2348.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2349.            n = 46 + length of known address TLV
  2350.            n1 = n + length of Resolve list
  2351.  
  2352.  
  2353.  
  2354. Ruffen, et al.               Informational                     [Page 42]
  2355.  
  2356. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2357.  
  2358.  
  2359.    In the following description of the message fields, the term
  2360.    "originating" switch refers to the switch that issued the original
  2361.    Interswitch Resolve request.  The term "owner" switch refers to that
  2362.    switch to which the destination endstation is attached.  And the term
  2363.    "responding" switch refers to either the "owner" switch or to a
  2364.    switch at the end of the switch flood path that does not own the
  2365.    endstation but issues an Interswitch Resolve response because it has
  2366.    no downstream neighbors.
  2367.  
  2368.    With the exception of the resolve list (which has a different size
  2369.    and format in a Resolve response message) and the four fields
  2370.    following the resolve list, all fields of an Interswitch Resolve
  2371.    message are allocated by the originating switch, and unless otherwise
  2372.    noted below, are written by the originating switch.
  2373.  
  2374.    Frame header/ISMP packet header
  2375.  
  2376.       This 20-octet field contains the frame header and the ISMP packet
  2377.       header.
  2378.  
  2379.    Version
  2380.  
  2381.       This 2-octet field contains the version number of the message
  2382.       type.  This section describes version 3 of the Interswitch Resolve
  2383.       message.
  2384.  
  2385.    Opcode
  2386.  
  2387.       This 2-octet field contains the operation code of the message.
  2388.       Valid values are as follows:
  2389.  
  2390.          1    The message is a Resolve request.
  2391.          2    The message is a Resolve response.
  2392.          3    (unused in Resolve messages)
  2393.          4    (unused in Resolve messages)
  2394.  
  2395.       The originating switch writes a value of 1 to this field, while
  2396.       the responding switch writes a value of 2.
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Ruffen, et al.               Informational                     [Page 43]
  2411.  
  2412. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2413.  
  2414.  
  2415.    Status
  2416.  
  2417.       This 2-octet field contains the status of a Resolve response
  2418.       message.  Valid values are as follows:
  2419.  
  2420.          0    The Resolve request succeeded (ResolveAck).
  2421.          1    (unused)
  2422.          2    The Resolve request failed (Unknown).
  2423.  
  2424.       This field is written by the responding switch.
  2425.  
  2426.    Call tag
  2427.  
  2428.       This 2-octet field contains the call tag of the endstation packet
  2429.       for which this Resolve request is issued.  The call tag is a 16-
  2430.       bit value (generated by the originating switch) that uniquely
  2431.       identifies the packet.
  2432.  
  2433.    Source MAC of packet
  2434.  
  2435.       This 6-octet field contains the physical (MAC) address of the
  2436.       endstation that originated the packet identified by the call tag.
  2437.  
  2438.    Originating switch MAC
  2439.  
  2440.       This 6-octet field contains the physical (MAC) address of the
  2441.       switch that issued the original Resolve request.
  2442.  
  2443.    Owner switch MAC
  2444.  
  2445.       This 6-octet field contains the physical (MAC) address of the
  2446.       switch to which the destination endstation is attached -- that is,
  2447.       the switch that was able to resolve the requested addressing
  2448.       information.  This field is written by the owner switch.
  2449.  
  2450.       If the status of the response is Unknown, this field is
  2451.       irrelevant.
  2452.  
  2453.    Known destination address
  2454.  
  2455.       This variable-length field contains the known attribute of the
  2456.       destination endstation address.  This address is stored in
  2457.       Tag/Length/Value format.
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Ruffen, et al.               Informational                     [Page 44]
  2467.  
  2468. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2469.  
  2470.  
  2471.    Count
  2472.  
  2473.       This 1-octet field contains the number of address attributes
  2474.       requested or returned.  This is the number of items in the resolve
  2475.       list.
  2476.  
  2477.    Resolve list
  2478.  
  2479.       This variable-length field contains a list of the address
  2480.       attributes either requested by the originating switch or returned
  2481.       by the owner switch.  Note that in a Resolve request message, this
  2482.       list contains only the tags of the requested address attributes.
  2483.       On the other hand, a Resolve response message with a status of
  2484.       ResolveAck contains the full TLV of each resolved address
  2485.       attribute.  The number of entries in the list is specified in the
  2486.       count field.
  2487.  
  2488.       In an Interswitch Resolve response message, this field is
  2489.       irrelevant if the status of the response is Unknown.
  2490.  
  2491.    Actual destination switch MAC
  2492.  
  2493.       This 6-octet field contains the physical (MAC) address of the
  2494.       actual switch within the chassis to which the endstation is
  2495.       attached.  If the status of the response is Unknown, this field is
  2496.       irrelevant.
  2497.  
  2498.    Downlink chassis MAC
  2499.  
  2500.       This 6-octet field contains the physical (MAC) address of the
  2501.       downlink chassis.  If the status of the response is Unknown, this
  2502.       field is irrelevant.
  2503.  
  2504.    Actual chassis MAC
  2505.  
  2506.       This 6-octet field contains the physical (MAC) address of the
  2507.       uplink chassis.  If the status of the response is Unknown, this
  2508.       field is irrelevant.
  2509.  
  2510.    Domain name
  2511.  
  2512.       This 16-octet field contains the ASCII name of the domain.  If the
  2513.       status of the response is Unknown, this field is irrelevant.
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Ruffen, et al.               Informational                     [Page 45]
  2523.  
  2524. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2525.  
  2526.  
  2527. 6.5 Interswitch New User Message
  2528.  
  2529.    The Interswitch New User message consists of a variable number of
  2530.    octets, as shown below:
  2531.  
  2532.        0                   1                   2                   3
  2533.        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
  2534.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2535.    00 |                                                               |
  2536.       +                         Frame header /                        +
  2537.       :                   ISMP packet header (type 5)                 :
  2538.       |                                                               |
  2539.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2540.    20 |           Version             |            Opcode             |
  2541.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2542.    24 |            Status             |           Call Tag            |
  2543.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2544.    28 |                                                               |
  2545.       +     Source MAC of packet      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2546.    32 |                               |                               |
  2547.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Originating switch MAC    +
  2548.    36 |                                                               |
  2549.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2550.    40 |                                                               |
  2551.       +   Previous owner switch MAC   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2552.    44 |                               |                               |
  2553.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  2554.    48 |                                                               :
  2555.       :                    MAC address of new user                    +
  2556.       |                                                               |
  2557.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2558.    70 |     Count     |                                               |
  2559.       +-+-+-+-+-+-+-+-+                                               +
  2560.    74 |                          Resolve list                         |
  2561.       :                                                               :
  2562.       |                                                               |
  2563.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2564.  
  2565.    In the following description of the message fields, the term
  2566.    "originating" switch refers to the switch that issued the original
  2567.    Interswitch New User request.  The term "previous owner" switch
  2568.    refers to that switch to which the endstation was previously
  2569.    attached.  And the term "responding" switch refers to either the
  2570.    "previous owner" switch or to a switch at the end of the switch flood
  2571.    path that did not own the endstation but issues an Interswitch New
  2572.    User response because it has no downstream neighbors.
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578. Ruffen, et al.               Informational                     [Page 46]
  2579.  
  2580. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2581.  
  2582.  
  2583.    With the exception of the resolve list, all fields of an Interswitch
  2584.    New User message are allocated by the originating switch, and unless
  2585.    otherwise noted below, are written by the originating switch.
  2586.  
  2587.    Frame header/ISMP packet header
  2588.  
  2589.       This 20-octet field contains the frame header and the ISMP packet
  2590.       header.
  2591.  
  2592.    Version
  2593.  
  2594.       This 2-octet field contains the version number of the message
  2595.       type.  This document describes ISMP message type 5, version 1.
  2596.  
  2597.    Opcode
  2598.  
  2599.       This 2-octet field contains the operation code of the message.
  2600.       Valid values are as follows:
  2601.  
  2602.          1    (unused in a New User message)
  2603.          2    (unused in a New User message)
  2604.          3    The message is a New User request.
  2605.          4    The message is a New User response.
  2606.  
  2607.       The originating switch writes a value of 3 to this field, while
  2608.       the responding switch writes a value of 4.
  2609.  
  2610.    Status
  2611.  
  2612.       This 2-octet field contains the status of a New User response
  2613.       message.  Valid values are as follows:
  2614.  
  2615.          0    VLAN resolution successful (NewUserAck)
  2616.          1    (unused)
  2617.          2    VLAN resolution unsuccessful (NewUserUnknown)
  2618.  
  2619.       This field is written by the responding switch.
  2620.  
  2621.    Call tag
  2622.  
  2623.       This 2-octet field contains the call tag of the endstation packet
  2624.       for which this New User request is issued.  The call tag is a 16-
  2625.       bit value (generated by the originating switch) that uniquely
  2626.       identifies the packet that caused the switch to identify the
  2627.       endstation as a new user.
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634. Ruffen, et al.               Informational                     [Page 47]
  2635.  
  2636. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2637.  
  2638.  
  2639.    Source MAC of packet
  2640.  
  2641.       This 6-octet field contains the physical (MAC) address of the
  2642.       endstation that originated the packet identified by the call tag.
  2643.  
  2644.    Originating switch MAC
  2645.  
  2646.       This 6-octet field contains the physical (MAC) address of the
  2647.       switch that issued the original New User request.
  2648.  
  2649.    Previous owner switch MAC
  2650.  
  2651.       This 6-octet field contains the physical (MAC) address of the
  2652.       switch to which the endstation was previously attached -- that is,
  2653.       the switch that was able to resolve the VLAN information. This
  2654.       field is written by the previous owner switch.
  2655.  
  2656.       If the status of the response is Unknown, this field is
  2657.       irrelevant.
  2658.  
  2659.    MAC address of new user
  2660.  
  2661.       This 24-octet field contains the physical (MAC) address of the new
  2662.       user endstation, stored in Tag/Length/Value format.
  2663.  
  2664.    Count
  2665.  
  2666.       This 1-octet field contains the number of VLAN identifiers
  2667.       returned.  This is the number of items in the resolve list. This
  2668.       field is written by the previous owner switch.
  2669.  
  2670.       If the status of the response is Unknown, this field and the
  2671.       resolve list are irrelevant.
  2672.  
  2673.    Resolve list
  2674.  
  2675.       This variable-length field contains a list of the VLAN identifiers
  2676.       of all static VLANs to which the endstation belongs, stored in
  2677.       Tag/Length/Value format (see Section 2.3). The number of entries
  2678.       in the list is specified in the count field.  This list is written
  2679.       by the previous owner switch.
  2680.  
  2681.       If the status of the response is Unknown, this field is
  2682.       irrelevant.
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688.  
  2689.  
  2690. Ruffen, et al.               Informational                     [Page 48]
  2691.  
  2692. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2693.  
  2694.  
  2695. 6.6 Interswitch Tag-Based Flood Message
  2696.  
  2697.    There are two versions of the Interswitch Tag-Based Flood message
  2698.    used by the SecureFast VLAN product.
  2699.  
  2700. 6.6.1 Prior to Version 1.8
  2701.  
  2702.    The Interswitch Tag-Based Flood message used by SFVLAN prior to
  2703.    version 1.8 consists of a variable number of octets, as shown below:
  2704.  
  2705.        0                   1                   2                   3
  2706.        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
  2707.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2708.    00 |                                                               |
  2709.       +                         Frame header /                        +
  2710.       :                   ISMP packet header (type 7)                 :
  2711.       |                                                               |
  2712.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2713.    20 |           Version             |            Opcode             |
  2714.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2715.    24 |            Status             |           Call Tag            |
  2716.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2717.    28 |                                                               |
  2718.       +     Source MAC of packet      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2719.    32 |                               |                               |
  2720.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Originating switch MAC    +
  2721.    36 |                                                               |
  2722.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2723.    40 |     Count     |                                               |
  2724.       +-+-+-+-+-+-+-+-+                                               +
  2725.    44 |                           VLAN list                           |
  2726.       :                                                               :
  2727.       |                                                               |
  2728.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2729.     n |                                                               |
  2730.       +                                                               +
  2731.       :                        Original packet                        :
  2732.       +                                                               +
  2733.       |                                                               |
  2734.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2735.  
  2736.          n = 41 + length of VLAN list
  2737.  
  2738.  
  2739.  
  2740.  
  2741.  
  2742.  
  2743.  
  2744.  
  2745.  
  2746. Ruffen, et al.               Informational                     [Page 49]
  2747.  
  2748. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2749.  
  2750.  
  2751.    Frame header/ISMP packet header
  2752.  
  2753.       This 20-octet field contains the frame header and the ISMP packet
  2754.       header.
  2755.  
  2756.    Version
  2757.  
  2758.       This 2-octet field contains the version number of the message
  2759.       type.  This document describes ISMP message type 7, version 1.
  2760.  
  2761.    Opcode
  2762.  
  2763.       This 2-octet field contains the operation code of the message. The
  2764.       value here should be 1, indicating the message is a flood request.
  2765.  
  2766.    Status
  2767.  
  2768.       This 2-octet field is currently unused.  It is reserved for future
  2769.       use.
  2770.  
  2771.    Call tag
  2772.  
  2773.       This 2-octet field contains the call tag of the endstation packet
  2774.       encapsulated within this tag-based flood message.  The call tag is
  2775.       a 16-bit value (generated by the originating switch) that uniquely
  2776.       identifies the packet.
  2777.  
  2778.    Source MAC of packet
  2779.  
  2780.       This 6-octet field contains the physical (MAC) address of the
  2781.       endstation that originated the packet identified by the call tag.
  2782.  
  2783.    Originating switch MAC
  2784.  
  2785.       This 6-octet field contains the physical (MAC) address of the
  2786.       switch that issued the original tag-based flooded message.
  2787.  
  2788.    Count
  2789.  
  2790.       This 1-octet field contains the number of VLAN identifiers
  2791.       included in the VLAN list.
  2792.  
  2793.    VLAN list
  2794.  
  2795.       This variable-length field contains a list of the VLAN identifiers
  2796.       of all VLANs to which the source endstation belongs.  Each entry
  2797.       in this list has the following format:
  2798.  
  2799.  
  2800.  
  2801.  
  2802. Ruffen, et al.               Informational                     [Page 50]
  2803.  
  2804. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2805.  
  2806.  
  2807.        0                   1                   2                   3
  2808.        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
  2809.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2810.       | Value length  |                                               |
  2811.       +-+-+-+-+-+-+-+-+                                               +
  2812.       |                        VLAN identifier value                  |
  2813.       :                                                               :
  2814.       |                                                               |
  2815.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2816.  
  2817.       The 1-octet value length field contains the length of the VLAN
  2818.       identifier.  VLAN identifiers can be from 1 to 16 characters long.
  2819.  
  2820.    Original packet
  2821.  
  2822.       This variable-length field contains the original packet as sent by
  2823.       the source endstation.
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856.  
  2857.  
  2858. Ruffen, et al.               Informational                     [Page 51]
  2859.  
  2860. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2861.  
  2862.  
  2863. 6.6.2 Version 1.8
  2864.  
  2865.    The Interswitch Tag-Based Flood message used by SFVLAN version 1.8
  2866.    consists of a variable number of octets, as shown below:
  2867.  
  2868.       Note:
  2869.  
  2870.          SFVLAN version 1.8 also recognizes the Interswitch Tag-Based
  2871.          Flood message as described in Section 6.6.1.
  2872.  
  2873.        0                   1                   2                   3
  2874.        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
  2875.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2876.    00 |                                                               |
  2877.       +                         Frame header /                        +
  2878.       :                   ISMP packet header (type 7)                 :
  2879.       |                                                               |
  2880.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2881.    20 |       VLAN identifier         |           Version             |
  2882.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2883.    24 |           Opcode              |            Status             |
  2884.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2885.    28 |          Call tag             |                               |
  2886.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Source MAC of packet      +
  2887.    32 |                                                               |
  2888.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2889.    36 |                                                               |
  2890.       +    Originating switch MAC     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2891.    40 |                               |     Count     |               |
  2892.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
  2893.    44 |                                                               |
  2894.       :                           VLAN list                           :
  2895.       |                                                               |
  2896.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2897.     n |                                                               |
  2898.       +                                                               +
  2899.       :                        Original packet                        :
  2900.       +                                                               +
  2901.       |                                                               |
  2902.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2903.  
  2904.             n = 41 + length of VLAN list
  2905.  
  2906.  
  2907.    Frame header/ISMP packet header
  2908.  
  2909.       This 20-octet field contains the frame header and the ISMP packet
  2910.       header.
  2911.  
  2912.  
  2913.  
  2914. Ruffen, et al.               Informational                     [Page 52]
  2915.  
  2916. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2917.  
  2918.  
  2919.       -  The frame header source address contains a value of 02-00-1D-
  2920.          00-xx-yy, where xx-yy is a value set by the VLAN Manager
  2921.          application to tag the frame header with the VLAN identifier.
  2922.          This value ranges from 2 to 4095.  For example, a value of 100
  2923.          would be set as 00-64.
  2924.  
  2925.       -  The frame header type field contains a value of 0x81FF.  Note
  2926.          that this differs from all other ISMP messages.
  2927.  
  2928.    VLAN identifier
  2929.  
  2930.       This 2-octet field contains the VLAN identifier of the packet
  2931.       source.
  2932.  
  2933.    Version
  2934.  
  2935.       This 2-octet field contains the version number of the message
  2936.       type.  This section describes version 2 of the Interswitch Tag-
  2937.       Based Flood message.
  2938.  
  2939.    Opcode
  2940.  
  2941.       This 2-octet field contains the operation code of the message.
  2942.       Valid values here are as follows:
  2943.  
  2944.       1  The message is a flood request.  The original packet is
  2945.          complete within this message.
  2946.  
  2947.       2  The message is a fragmented flood request.  The first portion
  2948.          of the original packet is contained in this message.
  2949.  
  2950.       3  The message is a fragmented flood request.  The second portion
  2951.          of the original packet is contained in this message.
  2952.  
  2953.    Status
  2954.  
  2955.       This 2-octet field is currently unused.  It is reserved for future
  2956.       use.
  2957.  
  2958.    Call tag
  2959.  
  2960.       This 2-octet field contains the call tag of the endstation packet
  2961.       encapsulated within this tag-based flood message.  The call tag is
  2962.       a 16-bit value (generated by the originating switch) that uniquely
  2963.       identifies the packet.
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970. Ruffen, et al.               Informational                     [Page 53]
  2971.  
  2972. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  2973.  
  2974.  
  2975.    Source MAC of packet
  2976.  
  2977.       This 6-octet field contains the physical (MAC) address of the
  2978.       endstation that originated the packet identified by the call tag.
  2979.  
  2980.    Originating switch MAC
  2981.  
  2982.       This 6-octet field contains the physical (MAC) address of the
  2983.       switch that issued the original tag-based flooded message.
  2984.  
  2985.    Count
  2986.  
  2987.       This 1-octet field contains the number of VLAN identifiers
  2988.       included in the VLAN list.
  2989.  
  2990.    VLAN list
  2991.  
  2992.       This variable-length field contains a list of the VLAN identifiers
  2993.       of all VLANs to which the source endstation belongs.  Each entry
  2994.       in this list has the following format:
  2995.  
  2996.        0                   1                   2                   3
  2997.        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
  2998.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2999.       | Value length  |                                               |
  3000.       +-+-+-+-+-+-+-+-+                                               +
  3001.       |                        VLAN identifier value                  |
  3002.       :                                                               :
  3003.       |                                                               |
  3004.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3005.  
  3006.       The 1-octet value length field contains the length of the VLAN
  3007.       identifier.  VLAN identifiers can be from 1 to 16 characters long.
  3008.  
  3009.    Original packet
  3010.  
  3011.       This variable-length field contains the original packet as sent by
  3012.       the source endstation.
  3013.  
  3014.  
  3015.  
  3016.  
  3017.  
  3018.  
  3019.  
  3020.  
  3021.  
  3022.  
  3023.  
  3024.  
  3025.  
  3026. Ruffen, et al.               Informational                     [Page 54]
  3027.  
  3028. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  3029.  
  3030.  
  3031. 6.7 Interswitch Tap/Untap Message
  3032.  
  3033.    The Interswitch Tap/Untap message consists of a variable number of
  3034.    octets, as shown below:
  3035.  
  3036.        0                   1                   2                   3
  3037.        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
  3038.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3039.    00 |                                                               |
  3040.       +                         Frame header /                        +
  3041.       :                   ISMP packet header (type 8)                 :
  3042.       |                                                               |
  3043.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3044.    20 |            Version            |            Opcode             |
  3045.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3046.    24 |             Status            |          Error code           |
  3047.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3048.    28 |           Header type         |         Header length         |
  3049.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3050.    32 |            Direction          |                               |
  3051.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Probe switch MAC        +
  3052.    36 |                                                               |
  3053.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3054.    40 |                           Probe port                          |
  3055.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3056.    44 |                                                               |
  3057.       +                                                               +
  3058.    48 |                           (Reserved)                          |
  3059.       +                                                               +
  3060.    52 |                                                               |
  3061.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3062.    56 |                                                               |
  3063.       +                                                               +
  3064.       |                             Header                            |
  3065.       +                                                               +
  3066.       |                                                               |
  3067.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3068.  
  3069.  
  3070.    Frame header/ISMP packet header
  3071.  
  3072.       This 20-octet field contains the frame header and the ISMP packet
  3073.       header.
  3074.  
  3075.    Version
  3076.  
  3077.       This 2-octet field contains the version number of the message
  3078.       type.  This document describes ISMP message type 8, version 1.
  3079.  
  3080.  
  3081.  
  3082. Ruffen, et al.               Informational                     [Page 55]
  3083.  
  3084. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  3085.  
  3086.  
  3087.    Opcode
  3088.  
  3089.       tet field contains the operation type of the message. ues are as
  3090.       follows:
  3091.  
  3092.          1  The message is a Tap request.
  3093.          2  The message is a Tap response.
  3094.          3  The message is an Untap request.
  3095.          4  The message is an Untap response.
  3096.  
  3097.    Status
  3098.  
  3099.       This 2-octet field contains the current status of the tap request.
  3100.       Valid values are as follows:
  3101.  
  3102.          1  Switch must disable outport on untap. (DisableOutport)
  3103.          2  Switch must keep outports on untap. (KeepOutport)
  3104.          3  Probe not found this leg of spanning tree. (ProbeNotFound)
  3105.          4  Still searching for probe switch. (OutportDecisionUnknown)
  3106.          5  Unassigned. (StatusUnassigned)
  3107.          6  (reserved)
  3108.          7  (reserved)
  3109.          8  (reserved)
  3110.          9  (reserved)
  3111.  
  3112.       See Section 5.2.3 for details on the use of this field.
  3113.  
  3114.    Error code
  3115.  
  3116.       This 2-octet field contains the response message error code of the
  3117.       requested operation.  Valid values are as follows:
  3118.  
  3119.          1  Operation successful. (NoError)
  3120.          2  No response heard from downstream neighbor. (Timeout)
  3121.          3  Port does not exist on probe switch. (BadPort)
  3122.          4  Message invalid. (InvalidMessage)
  3123.          5  Version number invalid. (IncompatibleVersions)
  3124.  
  3125.    Header type
  3126.  
  3127.       This 2-octet field contains the type of information contained in
  3128.       the header field.  Currently, valid values are as follows:
  3129.  
  3130.       1  (reserved) 2  Header contains destination and source endstation
  3131.          MAC addresses.
  3132.  
  3133.  
  3134.  
  3135.  
  3136.  
  3137.  
  3138. Ruffen, et al.               Informational                     [Page 56]
  3139.  
  3140. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  3141.  
  3142.  
  3143.    Header length
  3144.  
  3145.       This 2-octet field contains the length of the header field.
  3146.       Currently, this field always contains a value of 12.
  3147.  
  3148.    Direction
  3149.  
  3150.       This 2-octet field contains a value indicating the type of tap.
  3151.       Valid values are as follows:
  3152.  
  3153.       1  (reserved)
  3154.       2  Tap is bi-directional and data should be captured flowing in
  3155.          either direction over the connection.
  3156.       3  Tap is uni-directional and data should be captured only when it
  3157.          flows from the source to the destination.
  3158.  
  3159.    Probe switch MAC
  3160.  
  3161.       This 6-octet field contains the physical (MAC) address of the
  3162.       switch to which the probe is attached.
  3163.  
  3164.    Probe port
  3165.  
  3166.       This 4-octet field contains the logical port number (on the probe
  3167.       switch) to which the probe is attached.
  3168.  
  3169.    Reserved
  3170.  
  3171.       These 12 octets are reserved.
  3172.  
  3173.    Header
  3174.  
  3175.       This variable-length field contains the header that identifies the
  3176.       connection being tapped.  The length of the header is stored in
  3177.       the length field.
  3178.  
  3179.       Currently, this field is 12 octets long and contains the 6-octet
  3180.       physical address of the connection's destination endstation,
  3181.       followed by the 6-octet physical address of the connection's
  3182.       source endstation, as shown below:
  3183.  
  3184.  
  3185.  
  3186.  
  3187.  
  3188.  
  3189.  
  3190.  
  3191.  
  3192.  
  3193.  
  3194. Ruffen, et al.               Informational                     [Page 57]
  3195.  
  3196. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  3197.  
  3198.  
  3199.        0                   1                   2                   3
  3200.        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
  3201.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3202.       |                                                               |
  3203.       +    Destination MAC address    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3204.       |                               |                               |
  3205.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Source MAC address       +
  3206.       |                                                               |
  3207.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3208.  
  3209.  
  3210. 7. Security Considerations
  3211.  
  3212.    Requested call connections are established or denied based on the
  3213.    VLAN policy of the source and destination addresses specified within
  3214.    the packet.  Section 4.4.1 discusses this process in detail.
  3215.  
  3216.  
  3217. 8. References
  3218.  
  3219.    [RFC1700]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
  3220.                RFC 1700, October 1994.
  3221.  
  3222.    [IEEE]      "IEEE Standard 802.1d -- 1990"
  3223.  
  3224.    [IDvlsp]    Kane, L., "Cabletron's VLS Protocol Specification", RFC
  3225.                2642, August 1999.
  3226.  
  3227.    [IDhello]   Hamilton, D. and D. Ruffen, "Cabletron's VlanHello
  3228.                Protocol Specification", RFC 2641, August 1999.
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244.  
  3245.  
  3246.  
  3247.  
  3248.  
  3249.  
  3250. Ruffen, et al.               Informational                     [Page 58]
  3251.  
  3252. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  3253.  
  3254.  
  3255. 9. Authors' Addresses
  3256.  
  3257.    Dave Ruffen
  3258.    Cabletron Systems, Inc.
  3259.    Post Office Box 5005
  3260.    Rochester, NH  03866-5005
  3261.  
  3262.    Phone: (603) 332-9400
  3263.    EMail: ruffen@ctron.com
  3264.  
  3265.  
  3266.    Ted Len
  3267.    Cabletron Systems, Inc.
  3268.    Post Office Box 5005
  3269.    Rochester, NH  03866-5005
  3270.  
  3271.    Phone: (603) 332-9400
  3272.    EMail:  len@ctron.com
  3273.  
  3274.  
  3275.    Judy Yanacek
  3276.    Cabletron Systems, Inc.
  3277.    Post Office Box 5005
  3278.    Rochester, NH  03866-5005
  3279.  
  3280.    Phone: (603) 332-9400
  3281.    EMail:  jyanacek@ctron.com
  3282.  
  3283.  
  3284.  
  3285.  
  3286.  
  3287.  
  3288.  
  3289.  
  3290.  
  3291.  
  3292.  
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.  
  3305.  
  3306. Ruffen, et al.               Informational                     [Page 59]
  3307.  
  3308. RFC 2643     Cabletron's SecureFast VLAN Operational Model   August 1999
  3309.  
  3310.  
  3311. 10.  Full Copyright Statement
  3312.  
  3313.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  3314.  
  3315.    This document and translations of it may be copied and furnished to
  3316.    others, and derivative works that comment on or otherwise explain it
  3317.    or assist in its implementation may be prepared, copied, published
  3318.    and distributed, in whole or in part, without restriction of any
  3319.    kind, provided that the above copyright notice and this paragraph are
  3320.    included on all such copies and derivative works.  However, this
  3321.    document itself may not be modified in any way, such as by removing
  3322.    the copyright notice or references to the Internet Society or other
  3323.    Internet organizations, except as needed for the purpose of
  3324.    developing Internet standards in which case the procedures for
  3325.    copyrights defined in the Internet Standards process must be
  3326.    followed, or as required to translate it into languages other than
  3327.    English.
  3328.  
  3329.    The limited permissions granted above are perpetual and will not be
  3330.    revoked by the Internet Society or its successors or assigns.
  3331.  
  3332.    This document and the information contained herein is provided on an
  3333.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  3334.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  3335.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  3336.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  3337.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  3338.  
  3339. Acknowledgement
  3340.  
  3341.    Funding for the RFC Editor function is currently provided by the
  3342.    Internet Society.
  3343.  
  3344.  
  3345.  
  3346.  
  3347.  
  3348.  
  3349.  
  3350.  
  3351.  
  3352.  
  3353.  
  3354.  
  3355.  
  3356.  
  3357.  
  3358.  
  3359.  
  3360.  
  3361.  
  3362. Ruffen, et al.               Informational                     [Page 60]
  3363.  
  3364.