Point-to-Point Protocol extensions for bridging
RFC 1220
Document | Type |
RFC - Proposed Standard
(April 1991; No errata)
Obsoleted by RFC 1638
|
|
---|---|---|---|
Author | Fred Baker | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1220 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text