home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-ruffen-00.txt < prev    next >
Text File  |  1997-04-16  |  19KB  |  471 lines

  1.  
  2.  
  3. INTERNET-DRAFT         EXPIRES: OCTOBER 1997       INTERNET-DRAFT
  4. Network Working Group                                    K. Dobbins
  5. INTERNET-DRAFT                                             T. Grant
  6. Category:  Informational                                  D. Ruffen
  7.                                      Cabletron Systems Incorporated
  8.                                                          April 1997
  9.  
  10.  
  11.                      SBCD Protocol Specification
  12.                  <draft-rfced-info-ruffen-00.txt>
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering task Force (IETF), its areas,
  18.    and its working groups.  Note that other groups may also distribute
  19.    working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six
  22.    months and may be updated, replaced, or obsoleted by other
  23.    documents at any time.  It is inappropriate to use Internet-Drafts
  24.    as reference material or to cite them other than as "work in
  25.    progress".
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33. Abstract
  34.  
  35.    The Switch Broadcast Control and Delivery (SBCD) protocol is 
  36.    part of the InterSwitch Message Protocol (ISMP).  ISMP was 
  37.    designed to facilitate interswitch communication within 
  38.    distributed connection-oriented switching networks.  The SBCD 
  39.    protocol is used to reduce the amount of broadcast traffic 
  40.    across the switch fabric by restricting unresolved broadcast 
  41.    packets to only those ports that belong to the same VLAN as the 
  42.    source.
  43.  
  44. Table of Contents
  45.  
  46.    Status of this Memo........................................1
  47.    Abstract...................................................1
  48.    1.  Introduction...........................................1
  49.        1.1  Data Conventions..................................1
  50.    2.  ISMP Overview..........................................2
  51.    3.  General ISMP Packet Format.............................3
  52.        3.1  Frame Header......................................3
  53.        3.2  ISMP Packet Header................................4
  54.        3.3  ISMP Message Body.................................5
  55.    4.  SBCD Protocol Operational Overview.....................5
  56.    5.  Tag-Based Flood Message................................6
  57.    References.................................................8
  58.    Security Considerations....................................8
  59.    Author's Addresses.........................................8
  60.  
  61. 1.  Introduction
  62.  
  63.    This Internet-Draft is being distributed to members of the Internet 
  64.    community in order to solicit reactions to the proposals 
  65.    contained herein.  While the specification discussed here 
  66.    may not be directly relevant to the research problems of the 
  67.    Internet, it may be of interest to researchers and implementers.
  68.  
  69. 1.1  Data Conventions
  70.  
  71.    The methods used in this memo to describe and picture data 
  72.    adhere to the standards of Internet Protocol documentation 
  73.  
  74. K. Dobbins, et. al.                                        [Page 1]
  75.  
  76. INTERNET-DRAFT       SBCD Protocol Specification          April 1997
  77.  
  78.    [RFC1700], in particular:
  79.  
  80.       The convention in the documentation of Internet Protocols
  81.       is to express numbers in decimal and to picture data in 
  82.       "big-endian" order.  That is, fields are described left 
  83.       to right, with the most significant octet on the left and 
  84.       the least significant octet on the right.
  85.  
  86.       The order of transmission of the header and data 
  87.       described in this document is resolved to the octet 
  88.       level.  Whenever a diagram shows a group of octets, the 
  89.       order of transmission of those octets is the normal order 
  90.       in which they are read in English. 
  91.  
  92.       Whenever an octet represents a numeric quantity the left 
  93.       most bit in the diagram is the high order or most 
  94.       significant bit.  That is, the bit labeled 0 is the most 
  95.       significant bit.
  96.  
  97.       Similarly, whenever a multi-octet field represents a 
  98.       numeric quantity the left most bit of the whole field is 
  99.       the most significant bit.  When a multi-octet quantity is 
  100.       transmitted the most significant octet is transmitted 
  101.       first.
  102.  
  103. 2.  ISMP Overview
  104.  
  105.    The InterSwitch Message Protocol (ISMP) is used for interswitch
  106.    communication within distributed connection-oriented switching 
  107.    networks.  ISMP provides the following services:
  108.  
  109.    -  Topology services.  Each switch maintains a distributed 
  110.       topology of the switch fabric by exchanging the following 
  111.       interswitch messages with other switches:
  112.  
  113.       -  Interswitch Keepalive messages (SNDM protocol) are sent by
  114.          each switch to announce its existence to its neighboring 
  115.          switches and to establish the topology of the switch 
  116.          fabric.
  117.  
  118.       -  Interswitch Spanning Tree BPDU messages and Interswitch 
  119.          Remote Blocking messages (LSMP protocol) are used to 
  120.          determine and maintain a loop-free flood path between all
  121.          network switches in the fabric.  This flood path is used 
  122.          for all undirected interswitch messages -- that is, 
  123.          messages of the ARLD, SBCD and SFCT protocols.
  124.  
  125.       -  Interswitch Link State messages (VLS Protocol) are used to
  126.          determine and maintain a fully connected mesh topology 
  127.          graph of the switch fabric.  Call-originating switches use
  128.          the topology graph to determine the path over which to 
  129.          route a call connection.
  130.  
  131.  
  132. K. Dobbins, et. al.                                        [Page 2]
  133.  
  134. INTERNET-DRAFT      SBCD Protocol Specification          April 1997
  135.  
  136.    -  Address resolution services.  Interswitch Resolve messages 
  137.       (ARLD protocol) are used to resolve a packet destination 
  138.       address when the packet source and destination pair does not 
  139.       match a known connection.  Interswitch New User messages (also
  140.       part of the ARLD protocol) are used to provide end-station 
  141.       address mobility between switches.
  142.  
  143.    -  Tag-based flooding.  A tag-based broadcast method (SBCD 
  144.       protocol) is used to restrict the broadcast of unresolved 
  145.       packets to only those ports within the fabric that belong to 
  146.       the same VLAN as the source.
  147.  
  148.    -  Call tapping services.  Interswitch Tap messages (SFCT 
  149.       protocol) are used to monitor traffic moving between two end 
  150.       stations.  Traffic can be monitored in one or both directions
  151.       along the connection path.
  152.  
  153.                                 NOTE
  154.  
  155.             This document describes the SBCD protocol.  
  156.             Other ISMP protocols are described in other 
  157.             RFCs.  See the References section for a list of 
  158.             these related RFCs.
  159.  
  160. 3.  General ISMP Packet Format
  161.  
  162.    ISMP packets are of variable length and have the following 
  163.    general structure:
  164.  
  165.    -  Frame header
  166.    -  ISMP packet header
  167.    -  ISMP message body
  168.  
  169. 3.1  Frame Header
  170.  
  171.    ISMP packets are encapsulated within an IEEE 802-compliant 
  172.    frame using a standard header as shown below:
  173.  
  174.  
  175.     0                   1                   2                   3
  176.     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
  177.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178. 00 |                                                               |
  179.    +      Destination address      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180. 04 |                               |                               |
  181.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        Source address         +
  182. 08 |                                                               |
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184. 12 |             Type              |                               |
  185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  186. 16 |                                                               |
  187.    +                                                               +
  188.    :                                                               :
  189.  
  190. K. Dobbins, et. al.                                        [Page 3]
  191.  
  192. INTERNET-DRAFT     SBCD Protocol Specification          April 1997
  193.  
  194.    Destination address
  195.  
  196.       This 6-octet field contains the Media Access Control (MAC) 
  197.       address of the multicast channel over which all switches in 
  198.       the fabric receive ISMP packets.  The destination address of 
  199.       all ISMP packets contain a value of 01-00-1D-00-00-00.
  200.  
  201.    Source address
  202.  
  203.       This 6-octet field contains the physical (MAC) address of the
  204.       switch originating the ISMP packet.
  205.  
  206.    Type
  207.  
  208.       This 2-octet field identifies the type of data carried within
  209.       the frame.  The type field of ISMP packets contains the value
  210.       0x81FD.
  211.  
  212. 3.2  ISMP Packet Header
  213.  
  214.    The ISMP packet header consists of 6 octets, as shown below: 
  215.  
  216.     0                   1                   2                   3
  217.     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
  218.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  219. 00 |///////////////////////////////////////////////////////////////|
  220.    ://////// Frame header /////////////////////////////////////////:
  221.    +//////// (14 octets)  /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  222. 12 |///////////////////////////////|            Version            |
  223.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  224. 16 |       ISMP message type       |        Sequence number        |
  225.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  226. 20 |                                                               |
  227.    +                                                               +
  228.    :                                                               :
  229.  
  230.  
  231.    Frame header
  232.  
  233.       This 14-octet field contains the frame header.
  234.  
  235.    Version
  236.  
  237.       This 2-octet field contains the version number of the 
  238.       InterSwitch Message Protocol to which this ISMP packet 
  239.       adheres.  This document describes ISMP Version 2.0.
  240.  
  241.    ISMP message type
  242.  
  243.       This 2-octet field contains a value indicating which type 
  244.       of ISMP message is contained within the message body.  Valid 
  245.       values are as follows:
  246.  
  247.  
  248. K. Dobbins, et. al.                                        [Page 4]
  249.  
  250. INTERNET-DRAFT      SBCD Protocol Specification          April 1997
  251.  
  252.          1  (reserved)
  253.          2  Interswitch Keepalive messages (SNDM protocol)
  254.          3  Interswitch Link State messages (VLS protocol)
  255.          4  Interswitch Spanning Tree BPDU messages and Remote 
  256.             Blocking messages (LSMP protocol)
  257.          5  Interswitch Resolve and New User messages (ARLD 
  258.             protocol)
  259.          6  (reserved)
  260.          7  Tag-Based Flood messages (SBCD protocol)
  261.          8  Interswitch Tap messages (SFCT protocol)
  262.  
  263.       SBCD protocol messages have a message type of 7.
  264.  
  265.    Sequence number
  266.  
  267.       This 2-octet field contains an internally generated sequence 
  268.       number used by the various protocol handlers for internal 
  269.       synchronization of messages.
  270.  
  271. 3.3  ISMP Message Body
  272.  
  273.    The ISMP message body is a variable-length field containing the 
  274.    actual data of the ISMP message.  The length and content of this 
  275.    field are determined by the value found in the message type 
  276.    field.
  277.  
  278. 4.  SBCD Protocol Operational Overview
  279.  
  280.    The SBCD protocol is used to reduce the amount of broadcast 
  281.    traffic across the switch fabric by restricting the broadcast 
  282.    of unresolved packets to only those ports that belong to the 
  283.    same VLAN as the source.
  284.  
  285.    When a switch is unable to resolve the destination address of a 
  286.    packet, it encapsulates the original packet with a tag-based 
  287.    flooding header.  This header contains a list of identifiers of 
  288.    the VLANs to which the packet source belongs.
  289.  
  290.    The encapsulated packet is then sent over the switch flood path.
  291.    The switch flood path is formed using a spanning tree algorithm 
  292.    that provides a single path through the switch fabric and 
  293.    guarantees loop-free delivery to every switch in the fabric.
  294.  
  295.    When a switch receives a tag-based flood packet, it examines 
  296.    the encapsulated header to determine the VLAN(s) to which the 
  297.    packet should be sent.  If any of the switch's local access 
  298.    ports belong to one or more of the specified VLANs, the switch 
  299.    strips off the tag-based header and forwards the original packet
  300.    out the appropriate access port(s).
  301.  
  302.    The switch also forwards the entire encapsulated packet along 
  303.    the flood path to its downstream neighboring switches, if any.
  304.  
  305.  
  306. K. Dobbins, et. al.                                        [Page 5]
  307.  
  308. INTERNET-DRAFT      SBCD Protocol Specification          April 1997
  309.  
  310. 5.  Tag-Based Flood Message
  311.  
  312.    The SBCD tag-based flood message consists of a variable number 
  313.    of octets, as shown below:
  314.  
  315.     0                   1                   2                   3
  316.     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
  317.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  318. 00 |                                                               |
  319.    +                         Frame header /                        +
  320.    :                       ISMP packet header                      :
  321.    |                                                               |
  322.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  323. 20 |         SBCD version          |            Opcode             |
  324.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  325. 24 |            Status             |           Call Tag            |
  326.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  327. 28 |                                                               |
  328.    +     Source MAC of packet      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  329. 32 |                               |                               |
  330.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Originating switch MAC    +
  331. 36 |                                                               |
  332.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  333. 40 |     Count     |                                               |
  334.    +-+-+-+-+-+-+-+-+                                               +
  335. 44 |                           VLAN list                           |
  336.    :                                                               :
  337.    |                                                               |
  338.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  339.  n |                                                               |
  340.    +                                                               +
  341.    :                        Original packet                        :
  342.    +                                                               +
  343.    |                                                               |
  344.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.  
  346.        n = 41 + length of VLAN list
  347.  
  348.    Frame header/ISMP packet header
  349.  
  350.       This 20-octet field contains the frame header and the ISMP 
  351.       packet header.
  352.  
  353.    SBCD version
  354.  
  355.       This 2-octet field contains the version number of the SBCD 
  356.       protocol to which this message adheres.  This document 
  357.       describes SBCD Version 1.  
  358.  
  359.    Opcode
  360.  
  361.       This 2-octet field contains the operation code of the message.
  362.  
  363.  
  364. K. Dobbins, et. al.                                        [Page 6]
  365.  
  366. INTERNET-DRAFT     SBCD Protocol Specification          April 1997
  367.  
  368.       The value here should be 1, indicating the message is a flood 
  369.       request.
  370.  
  371.    Status
  372.  
  373.       This 2-octet field is currently unused.  It is reserved for 
  374.       future use.
  375.  
  376.    Call tag
  377.  
  378.       This 2-octet field contains the call tag of the end station 
  379.       packet encapsulated within this tag-based flood message.  
  380.       The call tag is a 16-bit value (generated by the originating 
  381.       switch) that uniquely identifies the packet.
  382.  
  383.    Source MAC of packet
  384.  
  385.       This 6-octet field contains the physical (MAC) address of the
  386.       end station that originated the packet identified by the call
  387.       tag.
  388.  
  389.    Originating switch MAC
  390.  
  391.       This 6-octet field contains the physical (MAC) address of the
  392.       switch that issued the original tag-based flooded message.
  393.  
  394.    Count
  395.  
  396.       This 1-octet field contains the number of VLAN identifiers 
  397.       included in the VLAN list.  
  398.  
  399.    VLAN list
  400.  
  401.       This variable-length field contains a list of the VLAN 
  402.       identifiers of all VLANs to which the source end station 
  403.       belongs.  Each entry in this list has the following format:
  404.  
  405.     0                   1                   2                   3
  406.     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
  407.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  408.    | Value length  |                                               |
  409.    +-+-+-+-+-+-+-+-+                                               +
  410.    |                        VLAN identifier value                  |
  411.    :                                                               :
  412.    |                                                               |
  413.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414.  
  415.       The 1-octet value length field contains the length of the VLAN 
  416.       identifier.  VLAN identifiers can be from 1 to 16 characters 
  417.       long.
  418.  
  419.  
  420.  
  421.  
  422. K. Dobbins, et. al.                                        [Page 7]
  423.  
  424. INTERNET-DRAFT      SBCD Protocol Specification          April 1997
  425.  
  426.    Original packet
  427.  
  428.       This variable-length field contains the original packet as 
  429.       sent by the source end station.
  430.  
  431. References
  432.  
  433.    [RFC1700]    Reynolds, S.J., Postel, J.  Assigned Numbers.  
  434.                 October 1994.
  435.  
  436.    Dobbins, K., et. al.  ARLD Protocol Specification
  437.    Work in Progress.
  438.  
  439.    Dobbins, K., et. al.  ISM Protocol Specification
  440.    Work in Progress
  441.  
  442.    Dobbins, K., et. al.  LSMP Protocol Specification
  443.    Work in Progress.
  444.  
  445.    Dobbins, K., et. al.  SFCT Protocol Specification
  446.    Work in Progress.
  447.  
  448.    Dobbins, K., et. al.  SNDM Protocol Specification
  449.    Work in Progress.
  450.  
  451.   Dobbins, K., et. al.  VLS Protocol Specification
  452.   Work in Progress.
  453.  
  454. Security Considerations
  455.  
  456.    Security issues are not discussed in this document.
  457.  
  458. Authors' Addresses
  459.  
  460.    Cabletron Systems, Inc., is located at:
  461.  
  462.       Post Office Box 5005
  463.       Rochester, NH  03866-5005
  464.       (603) 332-9400
  465.  
  466.    Kurt Dobbins      Email:  dobbins@ctron.com
  467.    Tom Grant         Email:  tgrant@ctron.com
  468.    Dave Ruffen       Email:  ruffen@ctron.com
  469.  
  470. INTERNET-DRAFT          EXPIRES: OCTOBER 1997       INTERNET-DRAFT
  471.