Point-to-Point Protocol extensions for bridging
RFC 1220

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                   F. Baker, Editor
Request for Comments: 1220                                           ACC
                                                              April 1991

            Point-to-Point Protocol Extensions for Bridging

1.  Status of this Memo

   This document defines an extension of the Internet Point-to-Point
   Protocol (PPP) described in RFC 1171, targeting the use of Point-to-
   Point lines for Remote Bridging.  It is a product of the Point-to-
   Point Protocol Extensions Working Group of the Internet Engineering
   Task Force (IETF).

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

2.  Historical Perspective

   Two basic algorithms are ambient in the industry for Bridging of
   Local Area Networks.  The more common algorithm is called
   "Transparent Bridging" and has been standardized for Extended LAN
   configurations by IEEE 802.1.  IEEE 802.5 has proposed an alternative
   approach, called "Source Routing", and is in the process of
   standardizing that approach for IEEE 802.5 extended networks.

   Although there is a subcommittee of IEEE 802.1 addressing remote
   bridging, neither standard directly defines Remote Bridging per se,
   as that would technically be beyond the IEEE 802 committee's charter.
   Both allow for it, however, modeling the line as an unspecified
   interface between half-bridges.

   This document assumes that the devices at either end of a serial link

      - have agreed to utilize the RFC 1171 line discipline in some form.

      - may have agreed, by some other means, to exchange other
        protocols on the line interspersed with each other and with any
        bridged PDUs.

      - may be willing to use the link as a vehicle for Remote Bridging.

      - may have multiple point-to-point links that are configured in
        parallel to simulate a single line of higher speed or

Point-to-Point Protocol Extensions Working Group                [Page 1]
RFC 1220            Bridging Point-to-Point Protocol          April 1991

        reliability, but message sequence issues are solved by the
        transmitting end.

3.  General Considerations

3.1.  Link Quality Monitoring

   It is strongly recommended that Point-to-Point Bridge Protocol
   implementations utilize Magic Number Loopback Detection and Link-
   Quality-Monitoring.  This is because the 802.1 Spanning Tree
   protocol, which is integral to both Transparent Bridging and Source
   Routing (as standardized), is unidirectional during normal operation,
   with HELLO PDUs emanating from the Root System in the general
   direction of the leaves, without any reverse traffic except in
   response to network events.

3.2.  Message Sequence

   The multiple link case requires consideration of message
   sequentiality.  The transmitting station must determine either that
   the protocol being bridged requires transmissions to arrive in the
   order of their original transmission, and enqueue all transmissions
   on a given conversation onto the same link to force order
   preservation, or that the protocol does NOT require transmissions to
   arrive in the order of their original transmission, and use that
   knowledge to optimize the utilization of the several links, enqueuing
   traffic to links to minimize delay.

   In the absence of such a determination, the transmitting station must
   act as though all protocols require order preservation; many
   protocols designed primarily for use on a single LAN in fact do.  A
   protocol could be described to maintain message sequentiality across
   multiple links, either by sequence numbering or by fragmentation and
   re-assembly, but this is neither elegant nor absolutely necessary.

3.3.  Maximum Receive Unit Considerations

   Please note that the negotiated MRU must be large enough to support
   the MAC Types that are negotiated for support, there being no
   fragmentation and re-assembly.  Even Ethernet frames are larger than
   the default MRU of 1500 octets.

3.4.  Separation of Spanning Tree Domains

   It is conceivable that a network manager might wish to inhibit the
   exchange of BPDUs on a link in order to logically divide two regions
   into separate Spanning Trees with different Roots (and potentially
   different Spanning Tree implementations or algorithms).  In order to

Point-to-Point Protocol Extensions Working Group                [Page 2]
RFC 1220            Bridging Point-to-Point Protocol          April 1991

   do that, he must configure both ends to not exchange BPDUs on a link.
   For the sake of robustness, a bridge which is so configured must
   silently discard the BPDU of its neighbor, should it receive one.