Point-to-Point Protocol extensions for bridging
RFC 1220
| Document | Type |
RFC - Proposed Standard
(April 1991; No errata)
Obsoleted by RFC 1638
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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]
Show full document text