Internet DRAFT - draft-rfced-grant

draft-rfced-grant



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 11:05:17 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 16 Apr 1997 22:15:00 GMT
ETag: "361f8f-7e5d-33554f64"
Accept-Ranges: bytes
Content-Length: 32349
Connection: close
Content-Type: text/plain


INTERNET-DRAFT          EXPIRES: OCTOBER 1997   INTERNET-DRAFT

Network Working Group                                    K. Dobbins
Request for Comments:  xxxx                                T. Grant
Category:  Informational                                J. Liessner
                                                          D. Ruffen
                                     Cabletron Systems Incorporated
                                                         April 1997

            Switched Fabric Connection Tap (SFCT) Protocol
            <draft-rfced-info-grant-00.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   The Switched Fabric Connection Tap (SFCT) protocol is part of 
   the InterSwitch Message Protocol (ISMP).  ISMP was designed to 
   facilitate interswitch communication within distributed 
   connection-oriented switching networks.  The SFCT protocol is 
   used to monitor communication between two end stations.

Table of Contents

   Status of this Memo.....................................1
   Abstract................................................1
   1.  Introduction........................................2
       1.1  Data Conventions...............................2
   2.  ISMP Overview.......................................2
   3.  General ISMP Packet Format..........................3
       3.1  Frame Header...................................3
       3.2  ISMP Packet Header.............................4
       3.3  ISMP Message Body..............................5
   4.  SFCT Protocol Operational Overview..................5
       4.1  Definitions....................................5
            4.1.1  Ingress Switch..........................6
            4.1.2  Egress Switch...........................6
            4.1.3  Intermediate Switch.....................6
            4.1.4  Call Connection Path....................6
            4.1.5  Originating Switch......................6
            4.1.6  Probe...................................6
            4.1.7  Probe Switch............................6
            4.1.8  Undirected Messages.....................7
            4.1.9  Switch Flood Path.......................7
            4.1.10  Upstream Neighbor......................7
            4.1.11  Downstream Neighbor....................7
       4.2  Tapping a Connection...........................7
            4.2.1  Types of Tap Connections................7
            4.2.2  Locating the Probe and 
                     Establishing the Tap Connection.......8
            4.2.3  Status Field............................9
       4.3  Untapping a Connection........................10
   5.  Interswitch Tap/Untap  Message.....................11


K. Dobbins, et. al.                                        [Page 1]

DRAFT           SFCT Protocol Specification           April 1997

   References.............................................14
   Security Considerations................................14
   Author's Addresses.....................................14

1.  Introduction

   This draft is being distributed to members of the Internet 
   community in order to solicit reactions to the proposals 
   contained herein.  While the specification discussed here may 
   not be directly relevant to the research problems of the 
   Internet, it may be of interest to researchers and implementers.

1.1  Data Conventions

   The methods used in this memo to describe and picture data 
   adhere to the standards of Internet Protocol documentation 
   [RFC1700], in particular:

      The convention in the documentation of Internet Protocols 
      is to express numbers in decimal and to picture data in 
      "big-endian" order.  That is, fields are described left 
      to right, with the most significant octet on the left and 
      the least significant octet on the right.

      The order of transmission of the header and data described 
      in this document is resolved to the octet level.  Whenever 
      a diagram shows a group of octets, the order of transmission
      of those octets is the normal order in which they are read 
      in English. 

      Whenever an octet represents a numeric quantity the left 
      most bit in the diagram is the high order or most 
      significant bit.  That is, the bit labeled 0 is the most 
      significant bit.

      Similarly, whenever a multi-octet field represents a 
      numeric quantity the left most bit of the whole field is 
      the most significant bit.  When a multi-octet quantity is 
      transmitted the most significant octet is transmitted first.

2.  ISMP Overview

   The InterSwitch Message Protocol (ISMP) is used for interswitch 
   communication within distributed connection-oriented switching 
   networks.  ISMP provides the following services:

   -  Topology services.  Each switch maintains a distributed 
      topology of the switch fabric by exchanging the following 
      interswitch messages with other switches:

      -  Interswitch Keepalive messages (SNDM protocol) are sent by 
         each switch to announce its existence to its neighboring 


K. Dobbins, et. al.                                        [Page 2]

DRAFT           SFCT Protocol Specification           April 1997

         switches and to establish the topology of the switch 
         fabric.

      -  Interswitch Spanning Tree BPDU messages and Interswitch 
         Remote Blocking messages (LSMP protocol) are used to 
         determine and maintain a loop-free flood path between all 
         network switches in the fabric.  This flood path is used 
         for all undirected interswitch messages -- that is, 
         messages of the ARLD, SBCD and SFCT protocols.

      -  Interswitch Link State messages (VLS protocol) are used to 
         determine and maintain a fully connected mesh topology 
         graph of the switch fabric.  Call-originating switches use 
         the topology graph to determine the path over which to 
         route a call connection.

   -  Address resolution services.  Interswitch Resolve messages 
      (ARLD protocol) are used to resolve a packet destination 
      address when the packet source and destination pair does not 
      match a known connection.  Interswitch New User messages 
      (also part of the ARLD protocol) are used to provide end-
      station address mobility between switches.

   -  Tag-based flooding.  A tag-based broadcast method (SBCD 
      protocol) is used to restrict the broadcast of unresolved 
      packets to only those ports within the fabric that belong to 
      the same VLAN as the source.

   -  Call tapping services.  Interswitch Tap messages (SFCT 
      protocol) are used to monitor traffic moving between two end 
      stations.  Traffic can be monitored in one or both 
      directions along the connection path.

                                NOTE

             This document describes the SFCT protocol.
             Other ISMP protocols are described in other 
             RFCs.  See the References section for a list 
             of these related RFCs.

3.  General ISMP Packet Format

   ISMP packets are of variable length and have the following 
   general structure:

   -  Frame header
   -  ISMP packet header
   -  ISMP message body

3.1  Frame Header

   ISMP packets are encapsulated within an IEEE 802-compliant 
   frame using a standard header as shown below:

K. Dobbins, et. al.                                        [Page 3]

DRAFT           SFCT Protocol Specification           April 1997


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |                                                               |
   +      Destination address      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        Source address         +
08 |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |             Type              |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
16 |                                                               |
   +                                                               +
   :                                                               :

   Destination address

      This 6-octet field contains the Media Access Control (MAC) 
      address of the multicast channel over which all switches in 
      the fabric receive ISMP packets.  The destination address of 
      all ISMP packets contain a value of 01-00-1D-00-00-00.

   Source address

      This 6-octet field contains the physical (MAC) address of 
      the switch originating the ISMP packet.

   Type

      This 2-octet field identifies the type of data carried 
      within the frame.  The type field of ISMP packets contains 
      the value 0x81FD.

3.2  ISMP Packet Header

   The ISMP packet header consists of 6 octets, as shown below: 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |///////////////////////////////////////////////////////////////|
   ://////// Frame header /////////////////////////////////////////:
   +//////// (14 octets)  /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |///////////////////////////////|            Version            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 |       ISMP message type       |        Sequence number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 |                                                               |
   +                                                               +
   :                                                               :



K. Dobbins, et. al.                                        [Page 4]

DRAFT           SFCT Protocol Specification           April 1997

   Frame header

      This 14-octet field contains the frame header.

   Version

      This 2-octet field contains the version number of the 
      InterSwitch Message Protocol to which this ISMP packet 
      adheres.  This document describes ISMP Version 2.0.

   ISMP message type

      This 2-octet field contains a value indicating which type of 
      ISMP message is contained within the message body.  Valid 
      values are as follows:

         1    (reserved)
         2    Interswitch Keepalive messages (SNDM protocol)
         3    Interswitch Link State messages (VLS protocol)
         4    Interswitch Spanning Tree BPDU messages and Remote 
              Blocking messages (LSMP protocol)
         5    Interswitch Resolve and New User messages (ARLD 
              protocol)
         6    (reserved)
         7    Tag-Based Flood messages (SBCD protocol)
         8    Interswitch Tap messages (SFCT protocol)

      SFCT protocol messages have a message type of 8.

   Sequence number

      This 2-octet field contains an internally generated sequence 
      number used by the various protocol handlers for internal 
      synchronization of messages.

3.3  ISMP Message Body

   The ISMP message body is a variable-length field containing the 
   actual data of the ISMP message.  The length and content of 
   this field are determined by the value found in the message 
   type field.

4.  SFCT Protocol Operational Overview

   The SFCT protocol is used to monitor traffic moving along a 
   connection between two end stations.  Traffic can be monitored 
   in one or both directions along the connection path.

4.1  Definitions

   The following terms are used in this description of the SFCT 
   protocol.


K. Dobbins, et. al.                                        [Page 5]

DRAFT           SFCT Protocol Specification           April 1997

4.1.1  Ingress Switch

   The ingress switch is the owner switch of the source end 
   station of the call connection.  That is, the source end 
   station is attached to one of the local access ports of the 
   switch.

4.1.2  Egress Switch

   The egress switch is the owner switch of the destination end 
   station of the call connection.  That is, the destination end 
   station is attached to one of the local access ports of the 
   switch.

4.1.3  Intermediate Switch

   An intermediate switch is any switch along the call connection 
   path on which the connection packets enter and leave over 
   network links.  Note that the following types of connections 
   have no intermediate switches:

   -  Call connections between source and destination end stations 
      that are attached to the same switch -- that is the ingress 
      switch is the same as the egress switch

   -  Call connections where the ingress and egress switches are 
      physical neighbors connected by a single network link

4.1.4  Call Connection Path

   A call connection path consists of 0 to 7 links between 
   switches.  It is selected from a list of alternate equal cost 
   paths provided by the Path Service, and is chosen to load 
   balance traffic across the fabric. 

4.1.5  Originating Switch

   The originating switch is the switch that requests the call 
   tap.  Any switch along a call connection path may request a tap 
   on that call connection.

4.1.6  Probe

   The tap probe is the device to receive a copy of the call 
   connection data.  The probe is attached to a port on the probe 
   switch.

4.1.7  Probe Switch

   The probe switch (also known as the terminating switch) is the 
   switch to which the probe is attached.  The probe switch can be 
   anywhere in the topology.


K. Dobbins, et. al.                                        [Page 6]

DRAFT           SFCT Protocol Specification           April 1997

4.1.8  Undirected Messages

   Undirected messages are those messages that are (potentially) 
   sent to all switches in the switch fabric -- that is, they are 
   not directed to any particular switch.  ISMP messages of the 
   SBCD, ARLD, and SFCT protocols are undirected messages.

4.1.9  Switch Flood Path

   The switch flood path is used to send undirected ISMP messages 
   throughout the switch fabric.  The flood path is formed using a 
   spanning tree algorithm that provides a single path through the 
   switch fabric and guarantees loop-free delivery to every other 
   switch in the fabric.

4.1.10  Upstream Neighbor

   A switch's upstream neighbor is that switch attached to the in 
   port of the switch flood path -- that is, the switch from which 
   the undirected message was received.  Note that each switch 
   receiving an undirected message has, at most, one upstream 
   neighbor, and  the originator of any undirected ISMP message 
   has no upstream neighbors.

4.1.11  Downstream Neighbor

   A switch's downstream neighbors are those switches attached to 
   all out ports of the flood path except the port on which the 
   undirected message was received.  Note that for each undirected 
   message some number of switches have no downstream neighbors.

4.2  Tapping a Connection

   A request to tap a call connection between two end stations can 
   originate on any switch along the call connection path -- the 
   ingress switch, the egress switch, or any of the intermediate 
   switches.  The call connection must have already been 
   established before a call tap request can be issued.  The probe 
   device can be attached to any switch in the topology.

4.2.1  Types of Tap Connections

   A call tap is enabled by setting up an auxiliary tap connection 
   associated with the call being monitored.  Since the tap must 
   originate on a switch somewhere along the call connection path, 
   the tap connection path will pass through one or more of the 
   switches along the call path.  However, since the probe switch 
   can be anywhere in the switch fabric, the tap path and the call 
   path may diverge at some point.

   Therefore, on each switch along the tap path, the tap 
   connection is established in one of three ways:


K. Dobbins, et. al.                                        [Page 7]

DRAFT           SFCT Protocol Specification           April 1997

   -  The existing call connection is used with no modification.

      When both the call path and tap path pass through the 
      switch, and the in and out ports of both connections are 
      identical, the switch uses the existing call connection to 
      route the tap.

   -  The existing call connection is modified.

      When both the call path and tap path pass through the 
      switch, but the call path out port is different from the tap 
      path out port, the switch enables an extra out port in 
      either one or both directions of the call connection, 
      depending on the direction of the tap.  This happens under 
      two conditions.

      -  If the switch is also the probe switch, an extra out port 
         is enabled to the probe.

      -  If the switch is the point at which the call path and the 
         tap path diverge, an extra out port is enabled to the 
         downstream neighbor on that leg of the flood path on which 
         the probe switch is located.

   -  A new connection is established.

      If the call path does not pass through the switch (because 
      the tap path has diverged from the call path), a completely 
      new connection is established for the tap.

4.2.2  Locating the Probe and Establishing the Tap Connection

   To establish a call tap, the originating switch formats an 
   Interswitch Tap request message and sends it out over the flood 
   path to all other switches in the topology.  

                              NOTE

            If the originating switch is also the probe 
            switch, no Interswitch Tap request message is 
            necessary.

   As the Interswitch Tap request message travels out along the 
   flood path, each switch receiving the message checks to see if 
   it is the probe switch and does the following:  

   -  If the switch is the probe switch, it establishes the tap 
      connection by either setting up a new connection or 
      modifying the call connection, as appropriate (see section 
      Types of Tap Connections).  It then reformats the Tap 
      request message to be a Tap response message with a status 
      indicating that the probe has been found, and sends the 
      message back to its upstream neighbor.  

K. Dobbins, et. al.                                        [Page 8]

DRAFT           SFCT Protocol Specification           April 1997


   -  If the switch is not the probe switch, it forwards the Tap 
      request message to all its downstream neighbors (if any).

   -  If the switch is not the probe switch and has no downstream 
      neighbors, it reformats the Tap request message to be a Tap 
      response message with a status indicating that the probe is 
      not located on that leg of the spanning tree.   It then 
      sends the response message back to its upstream neighbor.

   When a switch forwards an Interswitch Tap request message to 
   its downstream neighbors, it keeps track of the number of 
   requests it has sent out.

   -  If a response is received with a status indicating that the 
      probe switch is located somewhere downstream, the switch 
      establishes the appropriate type of tap connection (see 
      section Types of Tap Connections).  It then formats a Tap 
      response message with a status indicating that the probe has 
      been found and passes the message to its upstream neighbor.

   -  If no responses are received with a status indicating that 
      the probe switch is located downstream, the switch formats a 
      Tap response message with a status indicating that the probe 
      has not been found and passes the message to its upstream 
      neighbor.

4.2.3  Status Field

   The status field of the Tap request/response message contains 
   information about the state of the tap.  Some of these status 
   values are transient and are merely used to track the progress 
   of the Tap request.  Other status values are stored in the tap 
   table of each switch along the tap path for use when the tap is 
   torn down.  The possible status values are as follows:

   -  StatusUnassigned.  This is the initial status of the Tap 
      request message.

   -  OutportDecisionUnknown.  The Tap request is still moving 
      downstream along the flood path.  The probe switch had not 
      yet been found.

   -  ProbeNotFound.  The probe switch is not located on this leg 
      of the spanning tree.

   -  DisableOutport.  The probe switch is located on this leg of 
      the spanning tree, and the switch has had to either modify 
      the call connection or establish a new connection to 
      implement the tap (see section Types of Tap Connections).  
      When the tap is torn down, the switch will have to disable 
      any additional outports that have been enabled for the tap.


K. Dobbins, et. al.                                        [Page 9]

DRAFT           SFCT Protocol Specification           April 1997


   -  KeepOutport.  The probe switch is located on this leg of the 
      spanning tree, and the switch was able to route the tap over 
      the existing call path (see section Types of Tap 
      Connections).  Any ports used for the tap will remain 
      enabled when the tap is torn down.

4.3  Untapping a Connection

   A request to untap a call connection must be issued on the tap 
   originating switch -- that is, the same switch that issued the 
   tap request.

   To untap a call connection, the originating switch sends an 
   Interswitch Untap request message out over the switch flood 
   path to all other switches in the topology.  The message is 
   sent over the flood path, rather than the tap connection path, 
   to ensure that all switches that know of the tap are properly 
   notified, even if the switch topology has changed since the tap 
   was established.

   When a switch receives an Interswitch Untap request message, it 
   checks to see if it is handling a tap for the specified call 
   connection.  If so, the switch disables the tap connection, as 
   follows:

   -  If a new connection was added for the tap, the connection is 
      deleted from the connection table.

   -  If additional outports were enabled on the call connection, 
      they are disabled.

   The switch then forwards the Untap request message to its 
   downstream neighbor (if any).  If the switch has no downstream 
   neighbors, it formats an Untap response and sends the message 
   back to its upstream neighbor.  

   When a switch forwards an Untap request message to its 
   downstream neighbors, it keeps track of the number of requests 
   it has sent out and does not respond back to its upstream 
   neighbor until all Untap requests have been responded to.  Once 
   all responses have been received, the switch handles any final 
   cleanup for the tap and then sends a single Untap response 
   message to its upstream neighbor.










K. Dobbins, et. al.                                       [Page 10]

DRAFT           SFCT Protocol Specification           April 1997

5.  Interswitch Tap/Untap Message

   The SFCT Interswitch Tap message consists of a variable number 
   of octets, as shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |                                                               |
   +                         Frame header /                        +
   :                       ISMP packet header                      :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 |          SFCT version         |         Message type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 |             Status            |          Error code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 |           Header type         |         Header length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 |            Direction          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Probe switch MAC        +
36 |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 |                           Probe port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 |                                                               |
   +                                                               +
48 |                           (Reserved)                          |
   +                                                               +
52 |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 |                                                               |
   +                                                               +
   |                             Header                            |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Frame header/ISMP packet header

      This 20-octet field contains the frame header and the ISMP 
      packet header.

   SFCT version

      This 2-octet field contains the version number of the SFCT 
      protocol to which this message adheres.  This document 
      describes SFCT Version 1.

   Message type

      This 2-octet field contains the operation type of the 
      message.  Valid values are as follows:

K. Dobbins, et. al.                                       [Page 11]

DRAFT           SFCT Protocol Specification           April 1997

         1    The message is a Tap request.
         2    The message is a Tap response.
         3    The message is an Untap request.
         4    The message is an Untap response.

   Status

      This 2-octet field contains the current status of the tap 
      request.  Valid values are as follows:

         1    Switch must disable an outport on an untap.  
              (DisableOutport)
         2    Switch must keep its outports on an untap.  
              (KeepOutport)
         3    Probe has not been found on this leg of the spanning
              tree.  (ProbeNotFound)
         4    Still searching for the probe switch.  
              (OutportDecisionUnknown)
         5    Unassigned.  (StatusUnassigned)  This is the initial 
              switch status.
         6    (reserved)
         7    (reserved)
         8    (reserved)
         9    (reserved)

      See section Status Field for details on the use of this 
      field.

   Error code

      This 2-octet field contains the response message error code 
      of the requested operation.  Valid values are as follows:

         1    Operation was successful.  (NoError)
         2    No response was heard from a downstream neighbor.  
              (Timeout)
         3    Port does not exist on the probe switch.  (BadPort)
         4    Message was invalid.  (InvalidMessage)
         5    Version number was invalid.  (IncompatibleVersions)

   Header type

      This 2-octet field contains the type of information 
      contained in the header field.  In the current version of 
      the SFCT protocol, valid values are as follows:

         1    (reserved)
         2    Header contains destination and source end station 
              MAC addresses.  





K. Dobbins, et. al.                                       [Page 12]

DRAFT           SFCT Protocol Specification           April 1997

   Header length

      This 2-octet field contains the length of the header field.
      In the current version of the SFCT protocol, this field 
      always contains a value of 12.

   Direction

      This 2-octet field contains a value indicating the type of 
      tap.  Valid values are as follows:

         1    (reserved)
         2    Tap is bi-directional and data should be captured 
              flowing in either direction over the connection.  
         3    Tap is uni-directional and data should be captured 
              only when it flows from the source to the 
              destination.

   Probe switch MAC

      This 6-octet field contains the physical (MAC) address of 
      the switch to which the probe is attached.

   Probe port

      This 4-octet field contains the logical port number (on the 
      probe switch) to which the probe is attached.

   Reserved

      These 12 octets are reserved.

   Header

      This variable-length field contains the header that 
      identifies the connection being tapped.  The length of the 
      header is stored in the length field.

      In the current version of the SFCT protocol, this field is 
      12 octets long and contains the 6-octet physical address of 
      the connection's destination end station, followed by the 6-
      octet physical address of the connection's source end 
      station, as shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +    Destination MAC address    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Source MAC address       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

K. Dobbins, et. al.                                       [Page 13]

DRAFT           SFCT Protocol Specification           April 1997


References

   [RFC1700]    Reynolds, S.J., Postel, J.  Assigned Numbers.  
                October 1994.

   Dobbins, K., et. al.  ARLD Protocol Specification
   Work in Progress.

   Dobbins, K., et. al.  ISM Protocol Specification
   Work in Progress.

   Dobbins, K., et. al.  LSMP Protocol Specification
   Work in Progress.

   Dobbins, K., et. al.  SBCD Protocol Specification
   Work in Progress.

   Dobbins, K., et. al.  SNDM Protocol Specification
   Work in Progress.

   Dobbins, K., et. al.  VLS Protocol Specification
   Work in Progress.

Security Considerations

   Security issues are not discussed in this document.

Authors' Addresses

   Cabletron Systems, Inc., is located at:

      Post Office Box 5005
      Rochester, NH  03866-5005
      (603) 332-9400

   Kurt Dobbins     Email:  dobbins@ctron.com
   Tom Grant        Email:  tgrant@ctron.com
   Judy Liessner    Email:  liessner@ctron.com
   Dave Ruffen      Email:  ruffen@ctron.com

INTERNET-DRAFT      EXPIRES: OCTOBER 1997    INTERNET-DRAFT