home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1200s / rfc1220.txt < prev    next >
Text File  |  1991-04-16  |  37KB  |  1,011 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   F. Baker, Editor
  8. Request for Comments: 1220                                           ACC
  9.                                                               April 1991
  10.  
  11.  
  12.             Point-to-Point Protocol Extensions for Bridging
  13.  
  14. 1.  Status of this Memo
  15.  
  16.    This document defines an extension of the Internet Point-to-Point
  17.    Protocol (PPP) described in RFC 1171, targeting the use of Point-to-
  18.    Point lines for Remote Bridging.  It is a product of the Point-to-
  19.    Point Protocol Extensions Working Group of the Internet Engineering
  20.    Task Force (IETF).
  21.  
  22.    This RFC specifies an IAB standards track protocol for the Internet
  23.    community, and requests discussion and suggestions for improvements.
  24.    Please refer to the current edition of the "IAB Official Protocol
  25.    Standards" for the standardization state and status of this protocol.
  26.    Distribution of this memo is unlimited.
  27.  
  28. 2.  Historical Perspective
  29.  
  30.    Two basic algorithms are ambient in the industry for Bridging of
  31.    Local Area Networks.  The more common algorithm is called
  32.    "Transparent Bridging" and has been standardized for Extended LAN
  33.    configurations by IEEE 802.1.  IEEE 802.5 has proposed an alternative
  34.    approach, called "Source Routing", and is in the process of
  35.    standardizing that approach for IEEE 802.5 extended networks.
  36.  
  37.    Although there is a subcommittee of IEEE 802.1 addressing remote
  38.    bridging, neither standard directly defines Remote Bridging per se,
  39.    as that would technically be beyond the IEEE 802 committee's charter.
  40.    Both allow for it, however, modeling the line as an unspecified
  41.    interface between half-bridges.
  42.  
  43.    This document assumes that the devices at either end of a serial link
  44.  
  45.       - have agreed to utilize the RFC 1171 line discipline in some form.
  46.  
  47.       - may have agreed, by some other means, to exchange other
  48.         protocols on the line interspersed with each other and with any
  49.         bridged PDUs.
  50.  
  51.       - may be willing to use the link as a vehicle for Remote Bridging.
  52.  
  53.       - may have multiple point-to-point links that are configured in
  54.         parallel to simulate a single line of higher speed or
  55.  
  56.  
  57.  
  58. Point-to-Point Protocol Extensions Working Group                [Page 1]
  59.  
  60. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  61.  
  62.  
  63.         reliability, but message sequence issues are solved by the
  64.         transmitting end.
  65.  
  66. 3.  General Considerations
  67.  
  68. 3.1.  Link Quality Monitoring
  69.  
  70.    It is strongly recommended that Point-to-Point Bridge Protocol
  71.    implementations utilize Magic Number Loopback Detection and Link-
  72.    Quality-Monitoring.  This is because the 802.1 Spanning Tree
  73.    protocol, which is integral to both Transparent Bridging and Source
  74.    Routing (as standardized), is unidirectional during normal operation,
  75.    with HELLO PDUs emanating from the Root System in the general
  76.    direction of the leaves, without any reverse traffic except in
  77.    response to network events.
  78.  
  79. 3.2.  Message Sequence
  80.  
  81.    The multiple link case requires consideration of message
  82.    sequentiality.  The transmitting station must determine either that
  83.    the protocol being bridged requires transmissions to arrive in the
  84.    order of their original transmission, and enqueue all transmissions
  85.    on a given conversation onto the same link to force order
  86.    preservation, or that the protocol does NOT require transmissions to
  87.    arrive in the order of their original transmission, and use that
  88.    knowledge to optimize the utilization of the several links, enqueuing
  89.    traffic to links to minimize delay.
  90.  
  91.    In the absence of such a determination, the transmitting station must
  92.    act as though all protocols require order preservation; many
  93.    protocols designed primarily for use on a single LAN in fact do.  A
  94.    protocol could be described to maintain message sequentiality across
  95.    multiple links, either by sequence numbering or by fragmentation and
  96.    re-assembly, but this is neither elegant nor absolutely necessary.
  97.  
  98. 3.3.  Maximum Receive Unit Considerations
  99.  
  100.    Please note that the negotiated MRU must be large enough to support
  101.    the MAC Types that are negotiated for support, there being no
  102.    fragmentation and re-assembly.  Even Ethernet frames are larger than
  103.    the default MRU of 1500 octets.
  104.  
  105. 3.4.  Separation of Spanning Tree Domains
  106.  
  107.    It is conceivable that a network manager might wish to inhibit the
  108.    exchange of BPDUs on a link in order to logically divide two regions
  109.    into separate Spanning Trees with different Roots (and potentially
  110.    different Spanning Tree implementations or algorithms).  In order to
  111.  
  112.  
  113.  
  114. Point-to-Point Protocol Extensions Working Group                [Page 2]
  115.  
  116. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  117.  
  118.  
  119.    do that, he must configure both ends to not exchange BPDUs on a link.
  120.    For the sake of robustness, a bridge which is so configured must
  121.    silently discard the BPDU of its neighbor, should it receive one.
  122.  
  123. 4.  IEEE 802.1 Transparent Bridging
  124.  
  125. 4.1.  Overview of IEEE 802.1 Transparent Bridging
  126.  
  127.    As a favor to the uninitiated, let us first describe Transparent
  128.    Bridging.  Essentially, the bridges in a network operate as isolated
  129.    entities, largely unaware of each others' presence.  A Transparent
  130.    Bridge maintains a Forwarding Database consisting of
  131.  
  132.             {address, interface}
  133.  
  134.    records by saving the Source Address of each LAN transmission that it
  135.    receives along with the interface identifier for the interface it was
  136.    received on.  It goes on to check whether the Destination Address is
  137.    in the database, and if so, either discards the message (if the
  138.    destination and source are located at the same interface) or forwards
  139.    the message to the indicated interface.  A message whose Destination
  140.    Address is not found in the table is forwarded to all interfaces
  141.    except the one it was received on; this describes Broadcast/Multicast
  142.    behavior as well.
  143.  
  144.    The obvious fly in the ointment is that redundant paths in the
  145.    network cause indeterminate (nay, all too determinate) forwarding
  146.    behavior to occur.  To prevent this, a protocol called the IEEE
  147.    802.1(d) Spanning Tree Protocol is executed between the bridges to
  148.    detect and logically remove redundant paths from the network.
  149.  
  150.    One system is elected as the "Root", which periodically emits a
  151.    message called a Bridge Hello Protocol Data Unit, or BPDU, heard by
  152.    all of its neighboring bridges.  Each of these modifies and passes
  153.    the BPDU on to its neighbors, and they to theirs, until it arrives at
  154.    the leaf LAN segments in the network (where it dies, having no
  155.    further neighbors to pass it along) or until the message is stopped
  156.    by a bridge which has a superior path to the "Root".  In this latter
  157.    case, the interface the BPDU was received on is ignored (i.e., it is
  158.    placed in a Hot Standby status, no traffic is emitted onto it except
  159.    the BPDU, and all traffic received from it is discarded) until a
  160.    topology change forces a recalculation of the network.
  161.  
  162. 4.2.  IEEE 802.1 Remote Bridging Activity
  163.  
  164.    There exist two basic sorts of bridges - ones that interconnect LANs
  165.    directly, called Local Bridges, and ones that interconnect LANs via
  166.    an intermediate medium such as a leased line, called Remote Bridges.
  167.  
  168.  
  169.  
  170. Point-to-Point Protocol Extensions Working Group                [Page 3]
  171.  
  172. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  173.  
  174.  
  175.    The Point-to-Point Protocol might be used by a Remote Bridge.
  176.  
  177.    There is more than one proposal within the IEEE 802.1 Interworking
  178.    Committee for modeling the Remote Bridge.  In one model, the
  179.    interconnecting serial link(s) are treated in the same way that a LAN
  180.    is, having a standard IEEE 802.1 Link State; in another, the serial
  181.    links operate in a mode quite different from the LANs that they
  182.    interconnect.  For the sake of simplicity of specification, the first
  183.    model is adopted, although some of the good ideas from proponents of
  184.    the second model are included or allowed for.
  185.  
  186.    Therefore, given that transparent bridging is configured on a line or
  187.    set of lines, the specifics of the link state with respect to the
  188.    bridge is defined by IEEE 802.1(d).  The Bridge Protocol Data Unit,
  189.    or BPDU, is defined there, as well as the algorithms for its use.
  190.  
  191.    It is assumed that, if a Point-to-Point Link neighbor receives IEEE
  192.    802.1 BPDUs without rejecting them with the RFC 1171 Protocol-Reject
  193.    LCP PDU, Transparent Bridging is permitted on the link.
  194.  
  195. 4.3.  IEEE 802.5 Source Routing
  196.  
  197.    The IEEE 802.5 Committee has defined a different approach to bridging
  198.    for use on the Token Ring, called Source Routing.  In this approach,
  199.    the originating system has the responsibility of indicating what path
  200.    that the message should follow.  It does this, if the message is
  201.    directed off the local ring, by including a variable length MAC
  202.    header extension called the Routing Information Field, or RIF.  The
  203.    RIF consists of one 16 bit word of flags and parameters followed by
  204.    zero or more ring-and-bridge identifiers.  Each bridge en route
  205.    determines from this "source route list" whether it should receive
  206.    the message and how to forward it.
  207.  
  208.    The algorithm for Source Routing requires the bridge to be able to
  209.    identify any interface by its ring-and-bridge identifier, and to be
  210.    able to identify any of its OTHER interfaces likewise.  When a packet
  211.    is received which has the Routing Information Field (RIF) present, a
  212.    boolean in the RIF is inspected to determine whether the ring-and-
  213.    bridge identifiers are to be inspected in "forward" or "reverse"
  214.    sense.  In a "forward" search, the bridge looks for the ring-and-
  215.    bridge identifier of the interface the packet was received on, and
  216.    forwards the packet toward the ring identified in the ring-and-bridge
  217.    identifier that follows it.  In a "reverse" search, the bridge looks
  218.    for the ring-and-bridge identifier of the OTHER INTERFACE, and
  219.    delivers the packet to the indicated interface if such is found.
  220.  
  221.    The algorithms for handling multicasts ("Functional Addresses" and
  222.    "Group Addresses") have been the subject of much discussion in 802.5,
  223.  
  224.  
  225.  
  226. Point-to-Point Protocol Extensions Working Group                [Page 4]
  227.  
  228. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  229.  
  230.  
  231.    and are likely to be the most troublesome for bridge implementations.
  232.    Fortunately, they are beyond the scope of this document.
  233.  
  234. 4.4.  IEEE 802.5 Remote Bridging Activity
  235.  
  236.    There is no Remote Bridge proposal in IEEE 802.5 at this time,
  237.    although IBM ships a remote Source Routing Bridge.  Simplicity would
  238.    dictate that we choose the same model for IEEE 802.5 Source Routing
  239.    that was selected for IEEE 802.1, but necessity requires a ring
  240.    number for the line in some cases.  We allow for both models.
  241.  
  242.    Given that source routing is configured on a line or set of lines,
  243.    the specifics of the link state with respect to the bridge is defined
  244.    by the IEEE 802.5 Addendum on Source Routing.  The requisite PDUs for
  245.    calculating the spanning tree (used for assuring that each ring will
  246.    receive at most one copy of a multicast) are defined there, as well
  247.    as the algorithms for their use.  MAC PDUs (Beacon, Ring Management,
  248.    etc) are specific to the MAU technology and are not exchanged on the
  249.    line.
  250.  
  251. 4.5.  Source Routing to Transparent Bridge Translation
  252.  
  253.    IEEE 802 also has a subcommittee looking at the interoperation of
  254.    Transparent Bridging and Source Routing.  For the purposes of this
  255.    standard, such a device is both a transparent and a source routing
  256.    bridge, and will act on the line in both ways, just as it does on the
  257.    LAN.
  258.  
  259. 5.  Traffic Services
  260.  
  261.    Several services are provided for the benefit of different system
  262.    types and user configurations.  These include LAN Frame Checksum
  263.    Preservation, LAN Frame Checksum Generation, Tinygram Compression,
  264.    and the identification of closed sets of LANs.
  265.  
  266. 5.1.  LAN Frame Checksum Preservation
  267.  
  268.    IEEE 802.1 stipulates that the Extended LAN must enjoy the same
  269.    probability of undetected error that an individual LAN enjoys.
  270.    Although there has been considerable debate concerning the algorithm,
  271.    no other algorithm has been proposed than having the LAN Frame
  272.    Checksum received by the ultimate receiver be the same value
  273.    calculated by the original transmitter.  Achieving this requires, of
  274.    course, that the line protocols preserve the LAN Frame Checksum from
  275.    end to end.  The protocol is optimized towards this approach.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Point-to-Point Protocol Extensions Working Group                [Page 5]
  283.  
  284. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  285.  
  286.  
  287. 5.2.  Traffic having no LAN Frame Checksum
  288.  
  289.    The fact that the protocol is optimized towards LAN Frame Checksum
  290.    preservation raises twin questions: "What is the approach to be used
  291.    by systems which, for whatever reason, cannot easily support Frame
  292.    Checksum preservation?" and "What is the approach to be used when the
  293.    system originates a message, which therefore has no Frame Checksum
  294.    precalculated?".
  295.  
  296.    Surely, one approach would be to require stations to calculate the
  297.    Frame Checksum in software if hardware support were unavailable; this
  298.    would meet with profound dismay, and would raise serious questions of
  299.    interpretation in a Bridge/Router.
  300.  
  301.    However, stations which implement LAN Frame Checksum preservation
  302.    must already solve this problem, as they do originate traffic.
  303.    Therefore, the solution adopted is that messages which have no Frame
  304.    Checksum are tagged and carried across the line.
  305.  
  306.    When a system which does not implement LAN Frame Checksum
  307.    preservation receives a frame having an embedded FCS, it converts it
  308.    for its own use by removing the trailing four octets.  When any
  309.    system forwards a frame which contains no embedded FCS to a LAN, it
  310.    forwards it in a way which causes the FCS to be calculated.
  311.  
  312. 5.3.  Tinygram Compression
  313.  
  314.    An issue in remote Ethernet bridging is that the protocols that are
  315.    most attractive to bridge are prone to problems on low speed (64 KBPS
  316.    and below) lines.  This can be partially alleviated by observing that
  317.    the vendors defining these protocols often fill the PDU with octets
  318.    of ZERO.  Thus, an Ethernet or IEEE 802.3 PDU received from a line
  319.    that is (1) smaller than the minimum PDU size, and (2) has a LAN
  320.    Frame Checksum present, must be padded by inserting zeroes between
  321.    the last four octets and the rest of the PDU before transmitting it
  322.    on a LAN.  These protocols are frequently used for interactive
  323.    sessions, and therefore are frequently this small.
  324.  
  325.    To prevent ambiguity, PDUs requiring padding are explicitly tagged.
  326.    Compression is at the option of the transmitting station, and is
  327.    probably performed only on low speed lines, perhaps under
  328.    configuration control.
  329.  
  330.    The pseudo-code in Figure 1 describes the algorithms.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Point-to-Point Protocol Extensions Working Group                [Page 6]
  339.  
  340. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  341.  
  342.  
  343. 5.4.  LAN Identification
  344.  
  345.    In some applications, it is useful to tag traffic by the user
  346.    community it is a part of, and guarantee that it will be only emitted
  347.    onto a LAN which is of the same community.  The user community is
  348.    defined by a LAN ID.  Systems which choose to not implement this
  349.    feature must assume that any frame received having a LAN ID is from a
  350.    different community than theirs, and discard it.
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Point-to-Point Protocol Extensions Working Group                [Page 7]
  395.  
  396. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  397.  
  398.  
  399. Figure 1: Tinygram Compression Pseudo-Code
  400.  
  401. PPP Transmitter:
  402.  
  403. if (ZeroPadCompressionEnabled &&
  404.     BridgedProtocolHeaderFormat == IEEE8023 &&
  405.     PacketLength == Minimum8023PacketLength) {
  406.  /*
  407.   * Remove any continuous run of zero octets preceding,
  408.   * but not including, the LAN FCS, but not extending
  409.   * into the MAC header.
  410.   */
  411.     Set (ZeroCompressionFlag);            /* Signal receiver */
  412.     if (is_Set (LAN_FCS_Present)) {
  413.         FCS = TrailingOctets (PDU, 4);    /* Store FCS */
  414.         RemoveTrailingOctets (PDU, 4);    /* Remove FCS */
  415.         while (PacketLength > 14 &&       /* Stop at MAC header */
  416.                TrailingOctet (PDU) == 0)  /*  or last non-zero octet */
  417.             RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
  418.         Appendbuf (PDU, 4, FCS);          /* Restore FCS */
  419.     }
  420.     else {
  421.         while (PacketLength > 14 &&       /* Stop at MAC header */
  422.                TrailingOctet (PDU) == 0)  /*  or last zero octet */
  423.             RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
  424.     }
  425. }
  426.  
  427. PPP Receiver:
  428.  
  429. if (ZeroCompressionFlag) {                /* Flag set in header? */
  430.  /* Restoring packet to minimum 802.3 length */
  431.     Clear (ZeroCompressionFlag);
  432.     if (is_Set (LAN_FCS_Present)) {
  433.         FCS = TrailingOctets (PDU, 4);   /* Store FCS */
  434.         RemoveTrailingOctets (PDU, 4);   /* Remove FCS */
  435.         Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
  436.         Appendbuf (PDU, 4, FCS);         /* Restore FCS */
  437.     }
  438.     else {
  439.         Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
  440.     }
  441. }
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Point-to-Point Protocol Extensions Working Group                [Page 8]
  451.  
  452. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  453.  
  454.  
  455. 6.  Protocol Data Unit Formats
  456.  
  457. 6.1.  Common LAN Traffic
  458.  
  459.    Figure 2: 802.3 Frame format
  460.  
  461.     0                   1                   2                   3
  462.     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
  463.    +-+-+-+-+-+-+-+-+
  464.    |   HDLC FLAG   |
  465.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  466.    |      0xFF     |      0x03     |      0x00     |      0x31     +
  467.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  468.    |F|I|Z|0| Count |    MAC Type   |  LAN ID high word (optional)  +
  469.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  470.    |   LAN ID low word (optional)  |      Destination MAC Address  +
  471.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  472.    |                       Destination MAC Address                 +
  473.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  474.    |                       Source MAC Address                      +
  475.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  476.    |     Source MAC Address        |      Length/Type              +
  477.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  478.    |               LLC data                                        +
  479.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  480.    |                              ...                              +
  481.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  482.    |                   LAN FCS (optional)                          +
  483.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  484.    |                potential line protocol pad                    +
  485.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  486.    |           HDLC CRC            |   HDLC FLAG   |
  487.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  488.  
  489.    For Bridging LAN traffic, the format of the frame on the line is as
  490.    shown in Figures 2 or 3.  This conforms to RFC 1171 section 3.1
  491.    "Frame Format".  It also allows for RFC 1172 [2] negotiation of
  492.    Protocol Field Compression and Address and Control Field Compression.
  493.    It is recommended that devices which use controllers that require
  494.    even memory addresses negotiate to NOT USE Protocol Field Compression
  495.    on other than low speed links.
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Point-to-Point Protocol Extensions Working Group                [Page 9]
  507.  
  508. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  509.  
  510.  
  511.    Figure 3: 802.4/802.5/FDDI Frame format
  512.  
  513.     0                   1                   2                   3
  514.     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
  515.    +-+-+-+-+-+-+-+-+
  516.    |   HDLC FLAG   |
  517.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  518.    |      0xFF     |      0x03     |      0x00     |      0x31     +
  519.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  520.    |F|I|Z|0| Count |    MAC Type   |  LAN ID high word (optional)  +
  521.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  522.    |   LAN ID low word (optional)  |   Pad Byte    | Frame Control +
  523.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  524.    |                       Destination MAC Address                 +
  525.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.    |     Destination MAC Address   |  Source MAC Address           +
  527.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  528.    |                       Source MAC Address                      +
  529.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  530.    |               LLC data                                        +
  531.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  532.    |                              ...                              +
  533.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.    |                       FCS (optional)                          +
  535.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.    |              optional Data Link Layer padding                 +
  537.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.    |           HDLC CRC            |   HDLC FLAG   |
  539.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  540.  
  541.  
  542. The fields of this message are as follows:
  543.  
  544. Address Field and Control Field:
  545.      As defined by RFC 1171
  546.  
  547. Protocol Field:
  548.      0x0031
  549.  
  550. Flags:
  551.      bits 0-3: length of the line protocol pad field.
  552.      bit 4:  Reserved, Set to Zero
  553.      bit 5:  Set if IEEE 802.3 Pad must be zero filled to minimum size
  554.      bit 6:  Set if the LAN ID Field is present
  555.      bit 7:  Set if the LAN FCS Field is present
  556.  
  557.      The "number of trailing "pad" octets is a deference to the fact
  558.      that any point-to-point frame may have padding at the end.  This
  559.  
  560.  
  561.  
  562. Point-to-Point Protocol Extensions Working Group               [Page 10]
  563.  
  564. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  565.  
  566.  
  567.      number tells the receiving system how many octets to strip off the
  568.      end.
  569.  
  570. MAC Type:
  571.      0: Reserved
  572.      1: IEEE 802.3/Ethernet
  573.      2: IEEE 802.4
  574.      3: IEEE 802.5
  575.      4: FDDI
  576.      other:  Assigned by the Internet Assigned Numbers Authority
  577.  
  578. LAN ID:
  579.      This optional 32 bit field identifies the Community of LANs which
  580.      may be interested to receive this frame, as described in section
  581.      5.4.  If the LAN ID flag is not set, then this field is not
  582.      present, and the PDU is four octets shorter.
  583.  
  584. Frame Control:
  585.      On 802.4, 802.5, and FDDI LANs, there are a few octets preceding
  586.      the Destination MAC Address, one of which is protected by the FCS.
  587.      Since the MAC Type field defines the bit ordering, these are sent
  588.      in MAC order.  A pad octet is present to avoid odd machine address
  589.      boundary problems.
  590.  
  591. Destination MAC Address:
  592.      As defined by the IEEE.  Since the MAC Type field defines the bit
  593.      ordering, this is sent in MAC order.
  594.  
  595. Source MAC Address:
  596.      As defined by the IEEE.  Since the MAC Type field defines the bit
  597.      ordering, this is sent in MAC order.
  598.  
  599. LLC data:
  600.      This is the remainder of the MAC frame.  This is that portion of
  601.      the frame which is (or would be were it present) protected by the
  602.      LAN FCS; for example, the 802.5 Access Control field, and Status
  603.      Trailer are not meaningful to transmit to another ring, and are
  604.      omitted.
  605.  
  606. LAN Frame Checksum:
  607.      If present, this is the LAN FCS which was calculated by (or which
  608.      appears to have been calculated by) the originating station.  If
  609.      the FCS Present flag is not set, then this field is not present,
  610.      and the PDU is four octets shorter.
  611.  
  612. Optional Data Link Layer Padding
  613.      RFC 1171 specifies that an arbitrary pad can be added after the
  614.      data intended for transmission.  The "Count" portion of the flag
  615.  
  616.  
  617.  
  618. Point-to-Point Protocol Extensions Working Group               [Page 11]
  619.  
  620. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  621.  
  622.  
  623.      field contains the length of this pad, which may not exceed 15
  624.      octets.
  625.  
  626. CRC-CCITT
  627.      Mentioned primarily for clarity.  The CRC used on the PPP link is
  628.      separate from and unrelated to the LAN FCS.
  629.  
  630. 6.2.  IEEE 802.1 Bridge
  631.  
  632.    This is the BPDU as defined by IEEE 802.1(d), without any MAC or
  633.    802.2 LLC header (these being functionally equivalent to the Address,
  634.    Control, and Protocol Fields).  The LAN Pad and Frame Checksum fields
  635.    are likewise superfluous and absent. The Address and Control Fields
  636.    are optional, subject to the Address and Control Field Compression
  637.    negotiation.
  638.  
  639.    Figure 4: Bridge "Hello" PDU
  640.  
  641.     0                   1                   2                   3
  642.     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
  643.    +-+-+-+-+-+-+-+-+
  644.    |   HDLC FLAG   |
  645.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  646.    |      0xFF     |      0x03     |      0x02     |      0x01     +
  647.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  648.    |              BPDU data                                        +
  649.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  650.    |                              ...                              +
  651.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  652.    |           HDLC CRC            |   HDLC FLAG   |
  653.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  654.  
  655.  
  656.    The fields of this message are as follows:
  657.  
  658.    Address Field and Control Field:
  659.         As defined by RFC 1171
  660.  
  661.    Protocol Field:
  662.         0x0201
  663.  
  664.    MAC Frame:
  665.         802.1(d) BPDU
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Point-to-Point Protocol Extensions Working Group               [Page 12]
  675.  
  676. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  677.  
  678.  
  679. 6.3.  IEEE 802 Network Control Protocol
  680.  
  681.    The Bridge Network Control Protocol is responsible for configuring,
  682.    enabling, and disabling the bridges on both ends of the point-to-
  683.    point link.  As with the Link Control Protocol, this is accomplished
  684.    through an exchange of packets.  BNCP packets may not be exchanged
  685.    until LCP has reached the network-layer Protocol Configuration
  686.    Negotiation phase.  Likewise, LAN traffic may not be exchanged until
  687.    BNCP has first opened the connection.
  688.  
  689.    The Bridge Network Control Protocol is exactly the same as the Point-
  690.    to-Point Link Control Protocol with the following exceptions:
  691.  
  692.    Data Link Layer Protocol Field
  693.         Exactly one Bridge Network Control Protocol packet is encapsulated
  694.         in the Information field of PPP Data Link Layer frames where the
  695.         Protocol field indicates type hex 8031 (BNCP).
  696.  
  697.    Code field
  698.         Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  699.         Configure-Nak, Configure-Reject, Terminate-Request,
  700.         Terminate-Ack and Code-Reject) are used.  Other Codes should
  701.         be treated as unrecognized and should result in Code-Rejects.
  702.  
  703.    Timeouts
  704.         BNCP packets may not be exchanged until the Link Control
  705.         Protocol has reached the network-layer Protocol Configuration
  706.         Negotiation phase.  An implementation should be prepared to wait
  707.         for Link Quality testing to finish before timing out waiting
  708.         for Configure-Ack or other response.
  709.  
  710.    Configuration Option Types
  711.         The Bridge Network Control Protocol has a separate set of
  712.         Configuration Options.  These permit the negotiation of the
  713.         following items:
  714.  
  715.              - MAC Types supported
  716.              - Tinygram Compression support
  717.              - LAN Identification support
  718.              - Ring and Bridge Identification
  719.  
  720. 6.4.  IEEE 802.5 Remote Ring Identification Option
  721.  
  722.    Since the Remote Bridges are modeled as normal Bridges with a strange
  723.    internal interface, each bridge needs to know the ring/bridge numbers
  724.    of the bridges it is adjacent to.  This is the subject of a Link
  725.    Negotiation.  The exchange of ring-and-bridge identifiers is done
  726.    using this option on the Network Control Protocol.
  727.  
  728.  
  729.  
  730. Point-to-Point Protocol Extensions Working Group               [Page 13]
  731.  
  732. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  733.  
  734.  
  735.    The Token Ring Ring-and-Bridge Identifier, and its use, is specified
  736.    by the IEEE 802.5 Addendum on Source Routing.  It identifies the ring
  737.    that the interface is attached to by its configured ring number, and
  738.    itself by bridge number on the ring.
  739.  
  740.    Figure 5: Remote Ring Identification Option
  741.  
  742.     0                   1                   2                   3
  743.     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
  744.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  745.    |     type=1    |length = 4     | ring number           |bridge#|
  746.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  747.  
  748.  
  749.    Type 1 = IEEE 802.5 Source Routing Ring/Bridge Identifier
  750.  
  751.    Length
  752.         4 Octets
  753.  
  754.    Ring Number
  755.         A 12 bit number identifying the token ring, as defined in the
  756.         IEEE 802.5 Source Routing Specification.
  757.  
  758.    Bridge Number
  759.         A 4 bit number identifying the bridge on the token ring, as
  760.         defined in the IEEE 802.5 Source Routing Specification.
  761.  
  762. 6.5.  IEEE 802.5 Line Identification Option
  763.  
  764.    This option permits the systems to treat the line as a visible "Token
  765.    Ring", in accordance with the Source Routing algorithm.  The bridges
  766.    exchange ring-and-bridge identifiers using this option on the Network
  767.    Control Protocol.  The configured ring numbers must be identical in
  768.    normal operation.
  769.  
  770.    The Token Ring Ring-and-Bridge Identifier, and its use, is specified
  771.    by the IEEE 802.5 Addendum on Source Routing.  It identifies the ring
  772.    that the interface is attached to by its configured ring number, and
  773.    itself by bridge number on the ring.
  774.  
  775.    Figure 6: Line Identification Option
  776.  
  777.     0                   1                   2                   3
  778.     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
  779.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  780.    |     type=2    |length = 4     | ring number           |bridge#|
  781.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  782.  
  783.  
  784.  
  785.  
  786. Point-to-Point Protocol Extensions Working Group               [Page 14]
  787.  
  788. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  789.  
  790.  
  791.    Type 2 = IEEE 802.5 Line "Ring/Bridge" Identifier
  792.  
  793.    Length
  794.         4 Octets
  795.  
  796.    Ring Number
  797.         A 12 bit number identifying the line, as defined in the
  798.         IEEE 802.5 Source Routing Specification.
  799.  
  800.    Bridge Number
  801.         A 4 bit number identifying the bridge on the token ring, as
  802.         defined in the IEEE 802.5 Source Routing Specification.
  803.  
  804. 6.6.  MAC Type Support Selection
  805.  
  806.    The MAC Type Selection Option is provided to permit nodes to
  807.    advertise what sort of traffic they are prepared to convey.  A device
  808.    negotiating a 1600 octet MRU, for example, may not be willing to
  809.    support 802.5 (although it might, with certain changes necessary in
  810.    the RIFs it passes, and given that the hosts it supports implement
  811.    the 802.5 Maximum Frame Size correctly), and is definitely not
  812.    prepared to support 802.4 or FDDI.
  813.  
  814.    A system which does not announce the MAC Types that it supports may
  815.    be assumed to support all MAC Types; it will discard those that it
  816.    does not understand.  A system which chooses to announce MAC Types is
  817.    advising its neighbor that all unspecified MAC Types will be
  818.    discarded.  Announcement of multiple MAC Types is accomplished by
  819.    placing multiple options in the Configure Request.
  820.  
  821.    The Rejection of a MAC Type Announcement (in a Configure-Reject) is
  822.    essentially a statement that traffic appropriate to the MAC Type, if
  823.    encountered, will be forwarded on the link even though the receiving
  824.    system has indicated it will discard it.
  825.  
  826.    Figure 7: MAC Type Selection Option
  827.  
  828.     0                   1                   2
  829.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  830.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  831.    |     type=3    |length = 3     | MAC Type      |
  832.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  833.  
  834.  
  835.    Type 3 = MAC Type Selector
  836.  
  837.    Length
  838.         3 Octets
  839.  
  840.  
  841.  
  842. Point-to-Point Protocol Extensions Working Group               [Page 15]
  843.  
  844. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  845.  
  846.  
  847.    MAC Type Selector
  848.         One of the values of the PDU's MAC Type Field that this system is
  849.         prepared to receive and service.
  850.  
  851. 6.7.  Tinygram Compression
  852.  
  853.    Not all systems are prepared to make modifications to messages in
  854.    transit; on high speed lines, it is probably not worth the effort.
  855.    This option permits the system to negotiate compression.
  856.  
  857.    Consistent with the behavior of other compression options in the
  858.    Internet Point-to-Point set of protocols, no negotiation implies no
  859.    compression.  The systems need not agree on the setting of this
  860.    parameter; one may be willing to decompress and the other not.  A
  861.    system which does not negotiate, or negotiates this option to be
  862.    disabled, should never receive a compressed packet, however.
  863.  
  864.    Figure 8: Tinygram Compression Option
  865.  
  866.     0                   1                   2
  867.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  868.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  869.    |     type=4    |length = 3     | Compression   |
  870.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  871.  
  872.  
  873.    Type 4 = Tinygram Compression Support Option
  874.  
  875.    Length
  876.         3 Octets
  877.  
  878.    Compression Enable/Disable
  879.         If the value is 1, Tinygram Compression is enabled.  If the
  880.         value is 2, Tinygram Compression is disabled, and no
  881.         decompression will occur.
  882.  
  883. 6.8.  LAN Identification Support
  884.  
  885.    Not all systems are prepared to make use of the LAN Identification
  886.    field.  This option enables the systems to negotiate its use.
  887.  
  888.    The parameter is advisory; if the value is "enabled", then there may
  889.    exist labeled LANs beyond the system, and the system is prepared to
  890.    service traffic to it.  if the value is "disabled", then there are no
  891.    labeled LANs beyond the system, and all such traffic will by
  892.    definition be dropped.  Therefore, a system which is advised that his
  893.    peer does not service LAN Identifications need not forward such
  894.    traffic on the link.
  895.  
  896.  
  897.  
  898. Point-to-Point Protocol Extensions Working Group               [Page 16]
  899.  
  900. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  901.  
  902.  
  903.    The default value is that LAN Identification disabled.
  904.  
  905.    Figure 9: LAN Identification Option
  906.  
  907.     0                   1                   2
  908.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  909.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  910.    |     type=5    |length = 3     | Identification|
  911.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  912.  
  913.  
  914.    Type 5 = LAN Identification Support Option
  915.  
  916.    Length
  917.         3 Octets
  918.  
  919.    Identification Enable/Disable
  920.         If the value is 1, LAN Identification is enabled.  If the value
  921.         is 2, LAN Identification is disabled.
  922.  
  923. 7.  Acknowledgements
  924.  
  925.    This document is a product of the Point-to-Point Protocol Extensions
  926.    Working Group.  Special thanks go to Steve Senum of Network Systems,
  927.    Dino Farinacci of 3COM, and Rick Szmauz of Digital Equipment
  928.    Corporation.
  929.  
  930. 8.  Bibliography
  931.  
  932.    [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of
  933.        Multi-Protocol Datagrams Over Point-to-Point Links", RFC 1171,
  934.        CMU, July 1990.
  935.  
  936.    [2] Hobby R., and D. Perkins, "The Point-to-Point Protocol (PPP)
  937.        Initial Configuration Options", RFC 1172, CMU, UC Davis, July
  938.        1990.
  939.  
  940.    [3] IEEE Draft Standard P802.1d/D9 MAC Bridges, Institute of
  941.        Electrical and Electronic Engineers.  Also Published as ISO DIS
  942.        10038, July 1989.
  943.  
  944.    [4] IEEE Draft Standard P802.5d/D13 Draft Addendum to ANSI/IEEE Std
  945.        802.5-1988 Token Ring MAC and PHY Specification Enhancement for
  946.        Multiple-Ring Networks, Institute of Electrical and Electronic
  947.        Engineers, May 1989.
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Point-to-Point Protocol Extensions Working Group               [Page 17]
  955.  
  956. RFC 1220            Bridging Point-to-Point Protocol          April 1991
  957.  
  958.  
  959. 9.  Security Considerations
  960.  
  961.    Security issues are not discussed in this memo.
  962.  
  963. 10.  Author's Address
  964.  
  965.    Fred Baker
  966.    Advanced Computer Communications
  967.    720 Santa Barbara Street
  968.    Santa Barbara, CA 93101
  969.  
  970.    Phone: (805) 963-9431
  971.  
  972.    EMail: fbaker@ACC.COM
  973.    Or send comments to: ietf-ppp@ucdavis.edu
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Point-to-Point Protocol Extensions Working Group               [Page 18]
  1011.