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-livingston-00.txt < prev    next >
Text File  |  1997-04-29  |  20KB  |  506 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                              J. Livingston
  7.                                                           D. Ruffen
  8.                                      Cabletron Systems Incorporated
  9.                                                          April 1997
  10.  
  11.  
  12.                     SNDM Protocol Specification
  13.                    <draft-rfced-info-livingston-00.txt>
  14.  
  15. Status of this Memo
  16.  
  17.    This document is an Internet-Draft.  Internet-Drafts are working
  18.    documents of the Internet Engineering task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six
  23.    months and may be updated, replaced, or obsoleted by other
  24.    documents at any time.  It is inappropriate to use Internet-Drafts
  25.    as reference material or to cite them other than as "work in
  26.    progress".
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  30.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  31.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32.    ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. Abstract
  36.  
  37.    The Switch Neighbor Discovery and Maintenance (SNDM) protocol 
  38.    is part of the InterSwitch Message Protocol (ISMP).  ISMP was 
  39.    designed to facilitate interswitch communication within 
  40.    distributed connection-oriented switching networks.  Switches 
  41.    use the SNDM protocol to discover their neighboring switches 
  42.    and establish the topology of the switch fabric.
  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.  SNDM Protocol Operational Overview ....................5
  56.    5.  Interswitch Keepalive Message..........................6
  57.    6.  Port States............................................7
  58.    7.  Timers.................................................8
  59.    References.................................................8
  60.    Security Considerations....................................9
  61.    Author's Addresses.........................................9
  62.  
  63. 1.  Introduction
  64.  
  65.    This memo is being distributed to members of the Internet 
  66.    community in order to solicit reactions to the proposals 
  67.    contained herein.  While the specification discussed here 
  68.    may not be directly relevant to the research problems of the 
  69.    Internet, it may be of interest to researchers and implementers.
  70.  
  71. 1.1  Data Conventions
  72.  
  73.    The methods used in this memo to describe and picture data 
  74.  
  75. K. Dobbins, et. al.                                        [Page 1]
  76.  
  77. I/D             SNDM Protocol Specification           April 1997
  78.  
  79.    adhere to the standards of Internet Protocol documentation 
  80.    [RFC1700], in particular:
  81.  
  82.       The convention in the documentation of Internet Protocols 
  83.       is to express numbers in decimal and to picture data in 
  84.       "big-endian" order.  That is, fields are described left to 
  85.       right, with the most significant octet on the left and the 
  86.       least significant octet on the right.
  87.  
  88.       The order of transmission of the header and data described 
  89.       in this document is resolved to the octet level.  Whenever 
  90.       a diagram shows a group of octets, the order of transmission 
  91.       of those octets is the normal order in which they are read 
  92.       in English. 
  93.  
  94.       Whenever an octet represents a numeric quantity the leftmost 
  95.       bit in the diagram is the high order or most significant bit.
  96.       That is, the bit labeled 0 is the most significant bit.
  97.  
  98.       Similarly, whenever a multi-octet field represents a numeric 
  99.       quantity the left most bit of the whole field is the most 
  100.       significant bit.  When a multi-octet quantity is transmitted 
  101.       the most significant octet is transmitted 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 
  114.          by each switch to announce its existence to its 
  115.          neighboring switches and to establish the topology of the 
  116.          switch 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 (VLSP protocol) are used 
  126.          to 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.  
  133. K. Dobbins, et. al.                                        [Page 2]
  134.  
  135. I/D              SNDM Protocol Specification           April 1997
  136.  
  137.    -  Address resolution services.  Interswitch Resolve messages 
  138.       (ARLD protocol) are used to resolve a packet destination 
  139.       address when the packet source and destination pair does not 
  140.       match a known connection.  Interswitch New User messages 
  141.       (also part of the ARLD protocol) are used to provide end-
  142.       station address mobility between switches.
  143.  
  144.    -  Tag-based flooding.  A tag-based broadcast method (SBCD 
  145.       protocol) is used to restrict the broadcast of unresolved 
  146.       packets to only those ports within the fabric that belong to 
  147.       the same VLAN as the source.
  148.  
  149.    -  Call tapping services.  Interswitch Tap messages (SFCT 
  150.       protocol) are used to monitor traffic moving between two end 
  151.       stations.  Traffic can be monitored in one or both 
  152.       directions along the connection path.
  153.  
  154.                                  NOTE
  155.  
  156.               This document describes the SNDM protocol.
  157.               Other ISMP protocols are described in other 
  158.               RFCs.  See the References section for a list 
  159.               of these related RFCs.
  160.  
  161. 3.  General ISMP Packet Format
  162.  
  163.    ISMP packets are of variable length and have the following 
  164.    general structure:
  165.  
  166.    -  Frame header
  167.    -  ISMP packet header
  168.    -  ISMP message body
  169.  
  170. 3.1  Frame Header
  171.  
  172.    ISMP packets are encapsulated within an IEEE 802-compliant 
  173.    frame using a standard header as shown below:
  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.  
  191. K. Dobbins, et. al.                                        [Page 3]
  192.  
  193. I/D              SNDM Protocol Specification           April 1997
  194.  
  195.    Destination address
  196.  
  197.       This 6-octet field contains the Media Access Control (MAC) 
  198.       address of the multicast channel over which all switches in 
  199.       the fabric receive ISMP packets.  The destination address of 
  200.       all ISMP packets contain a value of 01-00-1D-00-00-00.
  201.  
  202.    Source address
  203.  
  204.       This 6-octet field contains the physical (MAC) address of 
  205.       the switch originating the ISMP packet.
  206.  
  207.    Type
  208.  
  209.       This 2-octet field identifies the type of data carried 
  210.       within the frame.  The type field of ISMP packets contains 
  211.       the value 0x81FD.
  212.  
  213. 3.2  ISMP Packet Header
  214.  
  215.    The ISMP packet header consists of 6 octets, as shown below: 
  216.  
  217.     0                   1                   2                   3
  218.     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
  219.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  220. 00 |///////////////////////////////////////////////////////////////|
  221.    ://////// Frame header /////////////////////////////////////////:
  222.    +//////// (14 octets)  /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  223. 12 |///////////////////////////////|            Version            |
  224.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  225. 16 |       ISMP message type       |        Sequence number        |
  226.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  227. 20 |                                                               |
  228.    +                                                               +
  229.    :                                                               :
  230.  
  231.  
  232.    Frame header
  233.  
  234.       This 14-octet field contains the frame header.
  235.  
  236.    Version
  237.  
  238.       This 2-octet field contains the version number of the 
  239.       InterSwitch Message Protocol to which this ISMP packet 
  240.       adheres.  This document describes ISMP Version 2.0.
  241.  
  242.    ISMP message type
  243.  
  244.       This 2-octet field contains a value indicating which type of 
  245.       ISMP message is contained within the message body.  Valid 
  246.       values are as follows:
  247.  
  248.  
  249. K. Dobbins, et. al.                                        [Page 4]
  250.  
  251. I/D              SNDM Protocol Specification           April 1997
  252.  
  253.          1    (reserved)
  254.          2    Interswitch Keepalive messages (SNDM protocol)
  255.          3    Interswitch Link State messages (VLSP protocol)
  256.          4    Interswitch Spanning Tree BPDU messages and Remote 
  257.               Blocking messages (LSMP protocol)
  258.          5    Interswitch Resolve and New User messages (ARLD 
  259.               protocol)
  260.          6    (reserved)
  261.          7    Tag-Based Flood messages (SBCD protocol)
  262.          8    Interswitch Tap messages (SFCT protocol)
  263.  
  264.       SNDM protocol messages have a message type of 2.
  265.  
  266.    Sequence number
  267.  
  268.       This 2-octet field contains an internally generated sequence 
  269.       number used by the various protocol handlers for internal 
  270.       synchronization of messages.
  271.  
  272. 3.3  ISMP Message Body
  273.  
  274.    The ISMP message body is a variable-length field containing the 
  275.    actual data of the ISMP message.  The length and content of 
  276.    this field are determined by the value found in the message 
  277.    type field.
  278.  
  279. 4.  SNDM Protocol Operational Overview
  280.  
  281.    Switches use the SNDM protocol to detect their switch neighbors 
  282.    and establish the topology of the switching fabric.
  283.  
  284.    At initialization, each switch sends an Interswitch Keepalive 
  285.    message out all local ports except those which have been 
  286.    preconfigured such that they cannot be Network ports (see Port 
  287.    States).  Then, as each switch discovers its neighboring 
  288.    switches via incoming Interswitch Keepalive messages, it 
  289.    notifies its local topology services who then build the 
  290.    topology tables for the switching fabric. 
  291.  
  292.    Each switch continues to send Interswitch Keepalive messages at 
  293.    regular intervals (currently 5 seconds).  If a switch has not 
  294.    heard from one of its neighbors for some predetermined interval 
  295.    (see Timers), notification is sent to all interested services 
  296.    and the neighboring switch is removed from the topology table.
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307. K. Dobbins, et. al.                                        [Page 5]
  308.  
  309. I/D             SNDM Protocol Specification           April 1997
  310.  
  311. 5.  Interswitch Keepalive Message
  312.  
  313.    The SNDM Interswitch Keepalive message consists of a variable 
  314.    number of octets, as shown below:
  315.  
  316.     0                   1                   2                   3
  317.     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
  318.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  319. 00 |                                                               |
  320.    +                          Frame header /                       +
  321.    :                        ISMP packet header                     :
  322.    |                                                               |
  323.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  324. 20 |                        Switch IP address                      |
  325.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  326. 24 |           Checksum            |        Switch ID length       |
  327.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  328. 28 |                                                               |
  329.    :                           Switch ID                           :
  330.    |                                                               |
  331.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  332.  n |                                                               |
  333.    +      Chassis MAC address      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  334.    |                               |        Base MAC count         |
  335.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  336. n1 |                                                               |
  337.    :                       Base MAC addresses                      :
  338.    |                                                               |
  339.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  340.  
  341.         n = 28 + switch ID length
  342.         n1 = n + 8
  343.  
  344.    Frame header/ISMP packet header
  345.  
  346.       This 20-octet field contains the frame header and the ISMP 
  347.       packet header.
  348.  
  349.    Switch IP address
  350.  
  351.       This 4-octet field contains the Internet Protocol (IP) 
  352.       address of the sending switch.
  353.  
  354.    Checksum
  355.  
  356.       This 2-octet field contains the checksum value calculated 
  357.       for the ISMP message, including the ISMP header.
  358.  
  359.    Switch ID length
  360.  
  361.       This 2-octet field contains the length of the Switch ID 
  362.       field.  This field always contains a value of 10.
  363.  
  364.  
  365. K. Dobbins, et. al.                                        [Page 6]
  366.  
  367. I/D             SNDM Protocol Specification           April 1997
  368.  
  369.    Switch ID
  370.  
  371.       This 10-octet field contains the internal ISMP identifier of 
  372.       the sending switch.  The identifier is generated by the 
  373.       sending switch and consists of the 6-octet physical (MAC) 
  374.       address of the switch, followed by a 4-octet value 
  375.       containing the logical port number over which the switch 
  376.       sent the SNDM packet.
  377.  
  378.    Chassis MAC
  379.  
  380.       This 6-octet field contains the physical (MAC) address of 
  381.       the chassis of the sending switch.
  382.  
  383.    Base MAC count
  384.  
  385.       This 2-octet field contains the number of entries in the 
  386.       list of Base MAC addresses.
  387.  
  388.    Base MAC addresses
  389.  
  390.       This variable-length field contains a list of the physical 
  391.       (MAC) addresses of all neighboring switches that the sending 
  392.       switch has previously discovered on the port over which the 
  393.       message was sent.  Each address is 6 octets long.  The 
  394.       number of addresses is found in the Base MAC count field.
  395.  
  396. 6.  Port States
  397.  
  398.    Each port on a switch can be in one of four different states.
  399.  
  400.    -  Unknown.  This is the default state of all ports at 
  401.       initialization.  Once the state of a port is determined, it 
  402.       is returned to the Unknown state under two conditions:
  403.  
  404.       -  If the last switch is lost on a Network port.
  405.  
  406.       -  If the last end user is lost on an Access port.
  407.  
  408.    -  Network.  A port is deemed a Network port when the switch 
  409.       has received an Interswitch Keepalive message over the port.
  410.  
  411.    -  Going to Access.  When any packet other than an Interswitch 
  412.       Keepalive message is received over an Unknown port, the 
  413.       state of the port is changed to Going to Access and a timer 
  414.       is activated.  If the timer expires without an Interswitch 
  415.       Keepalive message being received over the port, the port 
  416.       state changes to Access.
  417.  
  418.    -  Access.  A port is deemed an Access port when any packet 
  419.       other than an Interswitch Keepalive message has been 
  420.       received over the port and the Going to Access timer has 
  421.       expired.  A port can also be administratively designated an 
  422.  
  423. K. Dobbins, et. al.                                        [Page 7]
  424.  
  425. I/D              SNDM Protocol Specification           April 1997
  426.  
  427.       Access "control" port, meaning the port is to remain an 
  428.       Access port, regardless of the type of messages that are 
  429.       received on it.  Interswitch Keepalive messages are not sent 
  430.       over Access control ports.
  431.  
  432.    Three other types of ports are recognized:  the host management 
  433.    port, host data port, and host control port.  These ports are 
  434.    designated at initialization and are used to access the host 
  435.    CPU.  Interswitch Keepalive messages are not sent over these 
  436.    ports.
  437.  
  438. 7.  Timers
  439.  
  440.    The SNDM protocol uses three timers.
  441.  
  442.    -  Send Hello timer.  The Send Hello timer is used to control 
  443.       the interval at which Interswitch Keepalive messages are 
  444.       sent.  
  445.  
  446.    -  Aging timer.  The Aging Timer is used to detect when 
  447.       communication with a neighboring switch has been lost. 
  448.  
  449.    -  Going to Access timer.  The Going to Access timer is used to 
  450.       synchronize the transition of a port state to Access and 
  451.       prevent a port from being prematurely designation as an 
  452.       Access port during network initialization.  If an Unknown 
  453.       port receives any packet other than an Interswitch Keepalive 
  454.       message, the port state is set to Going To Access.  If the 
  455.       switch receives an Interswitch Keepalive message over that 
  456.       port before the timer expires, the port state is changed to 
  457.       Network.  Otherwise, when the timer expires, the port state 
  458.       is changed to Access.
  459.  
  460. References
  461.  
  462.    [RFC1700]    Reynolds, S.J., Postel, J.  Assigned Numbers.  
  463.                 October 1994.
  464.  
  465.    Dobbins, K., et. al.  ARLD Protocol Specification, Work in Progress.
  466.  
  467.    Dobbins, K., et. al.  ISM Protocol Specification, Work in Progress.
  468.  
  469.    Dobbins, K., et. al.  LSMP Protocol Specification, Work in Progress.
  470.  
  471.    Dobbins, K., et. al.  SBCD Protocol Specification, Work in Progress.
  472.  
  473.    Dobbins, K., et. al.  SFCT Protocol Specification, Work in Progress.
  474.  
  475.    Dobbins, K., et. al.  VLS Protocol Specification, Work in Progress.
  476.  
  477.  
  478.  
  479.  
  480.  
  481. K. Dobbins, et. al.                                        [Page 8]
  482.  
  483. I/D                 SNDM Protocol Specification           April 1997
  484.  
  485. Security Considerations
  486.  
  487.    Security issues are not discussed in this document.
  488.  
  489. Authors' Addresses
  490.  
  491.    Cabletron Systems, Inc., is located at:
  492.  
  493.       Post Office Box 5005
  494.       Rochester, NH  03866-5005
  495.       (603) 332-9400
  496.  
  497.    Kurt Dobbins       Email:  dobbins@ctron.com
  498.    Tom Grant          Email:  tgrant@ctron.com
  499.    John Livingston    Email:  jlston@ctron.com
  500.    Dave Ruffen        Email:  ruffen@ctron.com
  501.  
  502.  
  503. K. Dobbins, et. al.                                        [Page 9]
  504.  
  505. INTERNET-DRAFT          EXPIRES OCTOBER 1997        INTERNET-DRAFT
  506.