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-benoit-00.txt < prev    next >
Text File  |  1997-04-16  |  22KB  |  567 lines
  1.  
  2.  
  3.  
  4. INTERNET-DRAFT     EXPIRES: OCTOBER 1997             INTERNET-DRAFT
  5. Network Working Group                                    K. Dobbins
  6. DRAFT                                                     J. Benoit
  7. Category:  Informational                                   T. Grant
  8.                                                           D. Ruffen
  9.                                      Cabletron Systems Incorporated
  10.                                                          April 1997
  11.  
  12.        Loop-free Interswitch Message Path (LSMP) Protocol
  13.             <draft-rfced-info-benoit-00.txt>
  14.  
  15. Status of this Memo
  16.  
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six
  24.    months and may be updated, replaced, or obsoleted by other
  25.    documents at any time.  It is inappropriate to use Internet-Drafts
  26.    as reference material or to cite them other than as "work in
  27.    progress".
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  31.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.    ftp.isi.edu (US West Coast).
  34.  
  35. Abstract
  36.  
  37.    The Loop-Free Interswitch Message Path (LSMP) protocol is part 
  38.    of the InterSwitch Message Protocol (ISMP).  ISMP was designed 
  39.    to facilitate interswitch communication within distributed 
  40.    connection-oriented switching networks.  The LSMP protocol is 
  41.    used to create and maintain the flood path over which undirected 
  42.    ISMP messages are sent.
  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.  LSMP Protocol Operational Overview..................5
  56.        4.1  Maintaining the Spanning Tree..................5
  57.        4.2  Remote Blocking................................6
  58.    5.  Interswitch Spanning Tree BPDU Message..............7
  59.    6.  Interswitch Remote Blocking Message.................8
  60.    References..............................................9
  61.    Security Considerations.................................9
  62.    Author's Addresses.....................................10
  63.  
  64. 1.  Introduction
  65.  
  66.    This draft is being distributed to members of the Internet 
  67.    community in order to solicit reactions to the proposals 
  68.    contained herein.  While the specification discussed here 
  69.    may not be directly relevant to the research problems of the 
  70.    Internet, it may be of interest to researchers and implementers.
  71.  
  72. 1.1  Data Conventions
  73.  
  74.    The methods used in this memo to describe and picture data 
  75.    adhere to the standards of Internet Protocol documentation 
  76.  
  77. K. Dobbins, et. al.                                        [Page 1]
  78.  
  79. DRAFT           LSMP Protocol Specification           April 1997
  80.  
  81.    [RFC1700], in particular:
  82.  
  83.       The convention in the documentation of Internet Protocols 
  84.       is to express numbers in decimal and to picture data in 
  85.       "big-endian" order.  That is, fields are described left to 
  86.       right, with the most significant octet on the left and the 
  87.       least significant octet on the right.
  88.  
  89.       The order of transmission of the header and data described 
  90.       in this document is resolved to the octet level.  Whenever 
  91.       a diagram shows a group of octets, the order of transmission
  92.       of those octets is the normal order in which they are read 
  93.       in English. 
  94.  
  95.       Whenever an octet represents a numeric quantity the left 
  96.       most bit in the diagram is the high order or most 
  97.       significant bit.  That is, the bit labeled 0 is the most 
  98.       significant bit.
  99.  
  100.       Similarly, whenever a multi-octet field represents a 
  101.       numeric quantity the left most bit of the whole field is 
  102.       the most significant bit.  When a multi-octet quantity is 
  103.       transmitted the most significant octet is transmitted 
  104.       first.
  105.  
  106. 2.  ISMP Overview
  107.  
  108.    The InterSwitch Message Protocol (ISMP) is used for interswitch 
  109.    communication within distributed connection-oriented switching 
  110.    networks.  ISMP provides the following services:
  111.  
  112.    -  Topology services.  Each switch maintains a distributed 
  113.       topology of the switch fabric by exchanging the following 
  114.       interswitch messages with other switches:
  115.  
  116.       -  Interswitch Keepalive messages (SNDM protocol) are sent by 
  117.          each switch to announce its existence to its neighboring 
  118.          switches and to establish the topology of the switch 
  119.          fabric.
  120.  
  121.       -  Interswitch Spanning Tree BPDU messages and Interswitch 
  122.          Remote Blocking messages (LSMP protocol) are used to 
  123.          determine and maintain a loop-free flood path between all 
  124.          network switches in the fabric.  This flood path is used 
  125.          for all undirected interswitch messages -- that is, 
  126.          messages of the ARLD, SBCD and SFCT protocols.
  127.  
  128.       -  Interswitch Link State messages (VLS protocol) are used 
  129.          to determine and maintain a fully connected mesh topology 
  130.          graph of the switch fabric.  Call-originating switches use 
  131.          the topology graph to determine the path over which to 
  132.          route a call connection.
  133.  
  134.  
  135. K. Dobbins, et. al.                                        [Page 2]
  136.  
  137. DRAFT           LSMP Protocol Specification           April 1997
  138.  
  139.    -  Address resolution services.  Interswitch Resolve messages 
  140.       (ARLD protocol) are used to resolve a packet destination 
  141.       address when the packet source and destination pair does not 
  142.       match a known connection.  Interswitch New User messages 
  143.       (also part of the ARLD protocol) are used to provide end-
  144.       station address mobility between switches.
  145.  
  146.    -  Tag-based flooding.  A tag-based broadcast method (SBCD 
  147.       protocol) is used to restrict the broadcast of unresolved 
  148.       packets to only those ports within the fabric that belong to 
  149.       the same VLAN as the source.
  150.  
  151.    -  Call tapping services.  Interswitch Tap messages (SFCT 
  152.       protocol) are used to monitor traffic moving between two end 
  153.       stations.  Traffic can be monitored in one or both 
  154.       directions along the connection path.
  155.  
  156.                                 NOTE
  157.  
  158.              This document describes the LSMP protocol.
  159.              Other ISMP protocols are described in other 
  160.              RFCs.  See the References section for a list 
  161.              of these related RFCs.
  162.  
  163. 3.  General ISMP Packet Format
  164.  
  165.    ISMP packets are of variable length and have the following 
  166.    general structure:
  167.  
  168.    -  Frame header
  169.    -  ISMP packet header
  170.    -  ISMP message body
  171.  
  172. 3.1  Frame Header
  173.  
  174.    ISMP packets are encapsulated within an IEEE 802-compliant frame 
  175.    using a standard header as shown below:
  176.  
  177.     0                   1                   2                   3
  178.     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
  179.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180. 00 |                                                               |
  181.    +      Destination address      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182. 04 |                               |                               |
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        Source address         +
  184. 08 |                                                               |
  185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186. 12 |             Type              |                               |
  187.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  188. 16 |                                                               |
  189.    +                                                               +
  190.    :                                                               :
  191.  
  192.  
  193. K. Dobbins, et. al.                                         [Page 3]
  194.  
  195. DRAFT           LSMP Protocol Specification           April 1997
  196.  
  197.    Destination address
  198.  
  199.       This 6-octet field contains the Media Access Control (MAC) 
  200.       address of the multicast channel over which all switches in 
  201.       the fabric receive ISMP packets.  The destination address of 
  202.       all ISMP packets contain a value of 01-00-1D-00-00-00.
  203.  
  204.    Source address
  205.  
  206.       This 6-octet field contains the physical (MAC) address of 
  207.       the switch originating the ISMP packet.
  208.  
  209.    Type
  210.  
  211.       This 2-octet field identifies the type of data carried 
  212.       within the frame.  The type field of ISMP packets contains 
  213.       the value 0x81FD.
  214.  
  215. 3.2  ISMP Packet Header
  216.  
  217.    The ISMP packet header consists of 6 octets, as shown below: 
  218.  
  219.     0                   1                   2                   3
  220.     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
  221.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  222. 00 |///////////////////////////////////////////////////////////////|
  223.    ://////// Frame header /////////////////////////////////////////:
  224.    +//////// (14 octets)  /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  225. 12 |///////////////////////////////|            Version            |
  226.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  227. 16 |       ISMP message type       |        Sequence number        |
  228.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  229. 20 |                                                               |
  230.    +                                                               +
  231.    :                                                               :
  232.  
  233.  
  234.    Frame header
  235.  
  236.       This 14-octet field contains the frame header.
  237.  
  238.    Version
  239.  
  240.       This 2-octet field contains the version number of the 
  241.       InterSwitch Message Protocol to which this ISMP packet 
  242.       adheres.  This document describes ISMP Version 2.0.
  243.  
  244.    ISMP message type
  245.  
  246.       This 2-octet field contains a value indicating which type of 
  247.       ISMP message is contained within the message body.  Valid 
  248.       values are as follows:
  249.  
  250.  
  251. K. Dobbins, et. al.                                         [Page 4]
  252.  
  253. DRAFT           LSMP Protocol Specification           April 1997
  254.  
  255.          1    (reserved)
  256.          2    Interswitch Keepalive messages (SNDM protocol)
  257.          3    Interswitch Link State messages (VLS protocol)
  258.          4    Interswitch Spanning Tree BPDU messages and Remote 
  259.               Blocking messages (LSMP protocol)
  260.          5    Interswitch Resolve and New User messages (ARLD 
  261.               protocol)
  262.          6    (reserved)
  263.          7    Tag-Based Flood messages (SBCD protocol)
  264.          8    Interswitch Tap messages (SFCT protocol)
  265.  
  266.       LSMP protocol messages have a message type of 4.
  267.  
  268.    Sequence number
  269.  
  270.       This 2-octet field contains an internally generated sequence 
  271.       number used by the various protocol handlers for internal 
  272.       synchronization of messages.
  273.  
  274. 3.3  ISMP Message Body
  275.  
  276.    The ISMP message body is a variable-length field containing the 
  277.    actual data of the ISMP message.  The length and content of this 
  278.    field are determined by the value found in the message type 
  279.    field.
  280.  
  281. 4.  LSMP Protocol Operational Overview
  282.  
  283.    The LSMP protocol is used to create and maintain the flood 
  284.    control path over which undirected ISMP messages are sent.  
  285.    (Undirected messages are those of the ARLD, SBCD, and SFCT 
  286.    protocols.)  There are two parts to this process:
  287.  
  288.    -  Maintaining the spanning tree
  289.    -  Remote blocking
  290.  
  291. 4.1  Maintaining the Spanning Tree
  292.  
  293.    In a network with redundant network links, a packet traveling 
  294.    between switches can potentially be caught in an infinite loop --
  295.    an intolerable situation in a LAN environment.  However, it is 
  296.    possible to reduce a network topology to a single configuration 
  297.    (known as a spanning tree) such that there is, at most, one path 
  298.    between any two switches.
  299.  
  300.    The spanning tree is created and maintained using the Spanning 
  301.    Tree Algorithm defined by the IEEE 802.1d standard.
  302.  
  303.                                 NOTE
  304.  
  305.              A detailed discussion of this algorithm is 
  306.              beyond the scope of this document.  See 
  307.              [IEEE802] for more information.
  308.  
  309. K. Dobbins, et. al.                                         [Page 5]
  310.  
  311. DRAFT           LSMP Protocol Specification           April 1997
  312.  
  313.  
  314.    To implement the Spanning Tree Algorithm, switches exchange 
  315.    Interswitch Spanning Tree BPDU messages containing encapsulated 
  316.    IEEE 802.2-compliant Logical Link Control (LLC) frames that, in 
  317.    turn, contain Bridge Protocol Data Units (BPDUs).  There are two 
  318.    types of BPDUs:
  319.  
  320.    -  Configuration (CFG) BPDUs are exchanged during the switch 
  321.       discovery process, following the receipt of an Interswitch 
  322.       Keepalive message [Work in Progress].  They are used to initialize 
  323.       the spanning tree.  
  324.  
  325.    -  Topology Change Notification (TCN) BPDUs are exchanged when 
  326.       changes in the network topology are detected by the Spanning 
  327.       Tree Algorithm.  They are used to redefine the spanning tree 
  328.       to reflect the current topology.
  329.  
  330.    See [IEEE802] for detailed descriptions of these BPDUs.
  331.  
  332.    After the spanning tree has been computed, each network port on 
  333.    a switch will be in one of two states:
  334.  
  335.    -  Forwarding.  A port in the Forwarding state will be used to 
  336.       transmit all ISMP messages. 
  337.  
  338.    -  Blocking.  A port in the Blocking state will not be used to 
  339.       forward undirected ISMP messages -- those with a ISMP 
  340.       message type of 5 (ARLD protocol), 7 (SBCD protocol) or 8 
  341.       (SFCT protocol).  Blocking the transmission of these 
  342.       messages on selected ports prevents message duplication 
  343.       arising from multiple paths that exist in the network 
  344.       topology.  Note that all other types of ISMP message will be 
  345.       transmitted.
  346.  
  347. 4.2  Remote Blocking
  348.  
  349.    As mentioned in Maintaining the Spanning Tree, once the spanning 
  350.    tree has been computed, each network port on a switch will be in 
  351.    one of two states:  Forwarding or Blocking.
  352.  
  353.                                  NOTE
  354.  
  355.              The IEEE 802.1d standard specifies other port 
  356.              states used during the initialization of the 
  357.              spanning tree.  These states are not relevant 
  358.              to the discussion here.
  359.  
  360.    Although a port in the Blocking state will not forward undirected
  361.    ISMP messages, it may still receive them.  Any such message 
  362.    received will ultimately be discarded, but at the cost of CPU 
  363.    time necessary to process the packet.  
  364.  
  365.  
  366.  
  367. K. Dobbins, et. al.                                         [Page 6]
  368.  
  369. DRAFT           LSMP Protocol Specification           April 1997
  370.  
  371.    To prevent such unnecessary transmission of undirected messages 
  372.    to a port in the Blocking state, the port's owner switch can set 
  373.    remote blocking on the link by sending an Interswitch Remote 
  374.    Blocking message out over the port.  This notifies the switch on 
  375.    the other end of the link that ISMP messages of type 5, 7 or 8 
  376.    should not be sent over the link, regardless of the state of the 
  377.    sending port.
  378.  
  379.    Each switch sends an Interswitch Remote Blocking message out all 
  380.    its network ports at some predetermined interval (currently 5 
  381.    seconds).  A flag within the message indicates whether remote 
  382.    blocking should be turned on or off over the link.
  383.  
  384. 5.  Interswitch Spanning Tree BPDU Message
  385.  
  386.    The LSMP Interswitch Spanning Tree BPDU message consists of a 
  387.    variable number of octets, as shown below:
  388.  
  389.     0                   1                   2                   3
  390.     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
  391.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  392. 00 |                                                               |
  393.    +                         Frame header /                        +
  394.    :                       ISMP packet header                      :
  395.    |                                                               |
  396.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  397. 20 |          LSMP version         |         Message type          |
  398.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  399. 24 |          Message flags        |                               |
  400.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  401. 28 |                                                               :
  402.    :                          BPDU packet                          +
  403.    |                                                               |
  404.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  405.  
  406.  
  407.    Frame header/ISMP packet header
  408.  
  409.       This 20-octet field contains the frame header and the ISMP 
  410.       packet header.
  411.  
  412.    LSMP version
  413.  
  414.       This 2-octet field contains the version number of the LSMP 
  415.       protocol to which this message adheres.  This document 
  416.       describes LSMP Version 1.  
  417.  
  418.    Message type
  419.  
  420.       This 2-octet field contains the operation type of the 
  421.       message.  Valid values are as follows:
  422.  
  423.  
  424.  
  425. K. Dobbins, et. al.                                         [Page 7]
  426.  
  427. DRAFt           LSMP Protocol Specification           April 1997
  428.  
  429.          1    The message is an Interswitch Spanning Tree BPDU 
  430.               message.
  431.          2    The message is an Interswitch Remote Blocking 
  432.               message.
  433.  
  434.    Message flags
  435.  
  436.       This 2-octet field is currently unused.  It is reserved for 
  437.       future use. 
  438.  
  439.    BPDU packet
  440.  
  441.       This variable-length field contains an IEEE-compliant 802.2 
  442.       Logical Link Control (LLC) frame containing the Bridge 
  443.       Protocol Data Unit of the message.  See [IEEE802] for a 
  444.       detailed description of a BPDU.
  445.  
  446. 6.  Interswitch Remote Blocking Message
  447.  
  448.    The LSMP Interswitch Remote Blocking message consists of 30 
  449.    octets, as shown below:
  450.  
  451.     0                   1                   2                   3
  452.     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
  453.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  454. 00 |                                                               |
  455.    +                         Frame header /                        +
  456.    :                       ISMP packet header                      :
  457.    |                                                               |
  458.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  459. 20 |          LSMP version         |         Message type          |
  460.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  461. 24 |          Message flags        |        Blocking flag ...      |
  462.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  463. 28 |       ... Blocking flag       |
  464.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  465.  
  466.  
  467.    Frame header/ISMP packet header
  468.  
  469.       This 20-octet field contains the frame header and the ISMP 
  470.       packet header.
  471.  
  472.    LSMP version
  473.  
  474.       This 2-octet field contains the version number of the LSMP 
  475.       protocol to which this message adheres.  This document 
  476.       describes LSMP Version 1.  
  477.  
  478.    Message type
  479.  
  480.       This 2-octet field contains the operation type of the 
  481.       message.  Valid values are as follows:
  482.  
  483. K. Dobbins, et. al.                                         [Page 8]
  484.  
  485. DRAFT           LSMP Protocol Specification           April 1997
  486.  
  487.          1    The message is an Interswitch Spanning Tree BPDU 
  488.               message.
  489.          2    The message is an Interswitch Remote Blocking 
  490.               message.
  491.  
  492.    Message flags
  493.  
  494.       This 2-octet field is currently unused.  It is reserved for 
  495.       future use.
  496.  
  497.    Blocking flag
  498.  
  499.       This 4-octet field contains a flag indicating the state of 
  500.       remote blocking on the link over which the message was 
  501.       received.  A value of 1 indicates remote blocking is on and 
  502.       no undirected ISMP messages (those with a ISMP message type 
  503.       of 5, 7 or 8) should be sent over the link.  A value of 0 
  504.       indicates remote blocking is off.
  505.  
  506. References
  507.  
  508.    [RFC1700]    Reynolds, S.J., Postel, J.  Assigned Numbers.  
  509.                 October 1994.
  510.  
  511.    [IEEE802]    IEEE Standard 802.1d.  1990.
  512.  
  513.    Dobbins, K., et. al.  ARLD Protocol Specification
  514.    Work in Progress.
  515.  
  516.    Dobbins, K., et. al.  ISM Protocol Specification
  517.    Work in Progress.
  518.  
  519.    Dobbins, K., et. al.  SBCD Protocol Specification
  520.    Work in Progress.
  521.  
  522.    Dobbins, K., et. al.  SFCT Protocol Specification
  523.    Work in Progress.
  524.  
  525.    Dobbins, K., et. al.  SNDM Protocol Specification
  526.    Work in Progress.
  527.  
  528.    Dobbins, K., et. al.  VLS Protocol Specification
  529.    Work in Progress.
  530.  
  531. Security Considerations
  532.  
  533.    Security issues are not discussed in this document.
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547. K. Dobbins, et. al.                                         [Page 9]
  548. DRAFT           LSMP Protocol Specification           April 1997
  549.  
  550.  
  551. Authors' Addresses
  552.  
  553.    Cabletron Systems, Inc., is located at:
  554.  
  555.       Post Office Box 5005
  556.       Rochester, NH  03866-5005
  557.       (603) 332-9400
  558.  
  559.    Kurt Dobbins      Email:  dobbins@ctron.com
  560.    Joe Benoit        Email:  jbenoit@ctron.com
  561.    Tom Grant         Email:  tgrant@ctron.com
  562.    Dave Ruffen       Email:  ruffen@ctron.com
  563.  
  564. INTERNET-DRAFT          EXPIRES: OCTOBER 1997     INTERNET-DRAFT
  565.  
  566.  
  567.