PPP Bridging Control Protocol (BCP)
obsoleted by
- rfc-2878 — PPP Bridging Control Protocol (BCP)
obsoletes
- rfc-1220 — Point-to-Point Protocol extensions for bridging
Extracted elements (30)
Higher-numbered MAC Type values (11, 12) represent canonical address formats for 802.5 and FDDI, requiring backward compatibility with the lower-numbered non-canonical variants; this preserves interoperability with earlier versions of the specification.
In the split-bridge Source Routing model, the transmitting system (not the receiver) is chosen to update the RIF so that the receiving system can forward frames without processing the RIF, keeping the bridging algorithm simple and ensuring interoperability.
LAN Frame Checksum preservation is the primary design choice because IEEE 802.1 requires the Extended LAN to enjoy the same undetected error probability as a single LAN; no alternative algorithm has been proposed, so the FCS calculated by the originator is carried end-to-end.
Tinygram compression is optional and sender-controlled rather than mandatory because not all systems can modify frames in transit, and on high-speed lines the overhead is not worthwhile; systems that do not negotiate it should never receive a compressed packet.
By default, PPP Source Route Bridges use the independent-bridge model to ensure interoperability in the absence of option negotiation; the split-bridge model requires successful negotiation of the Bridge-Identification Configuration Option.
When two bridges disagree on spanning tree protocol, the system with the lower-numbered protocol SHOULD Configure-Nak suggesting its own protocol; if no agreement is reached, BCP MUST NOT enter the Opened state except when one side supports no spanning tree at all.
A Configure-Nak for MAC-Address MUST specify a valid IEEE 802.1 format physical address where the multicast bit MUST be zero.
A higher-numbered system MUST NOT change its bridge number to a lower number to resolve a Bridge-Identification mismatch; a system MAY change its bridge number to the higher of the two numbers.
A system MUST NOT transmit a MAC Type numbered higher than 4 unless it has received from its peer a MAC-Support Configuration Option indicating that the peer is willing to receive frames of that MAC Type.
An implementation that does not support any spanning tree protocol MUST silently discard any received IEEE 802.1D BPDU packets, and MUST either silently discard or respond to other received BPDU packets with an LCP Protocol-Reject packet.
Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST reach the Network-Layer Protocol phase and the Bridging Control Protocol MUST reach the Opened state.
If a spanning tree protocol is not agreed upon (except when one system supports none), the Bridging Control Protocol MUST NOT enter the Opened state.
If an implementation supports a MAC Type that is the higher-numbered format of a given MAC Type, it MUST also support the lower-numbered format; e.g., supporting FDDI with canonical addresses requires also supporting FDDI with non-canonical addresses.
In the absence of a determination about whether a bridged protocol requires in-order delivery, the transmitting system MUST act as though all protocols require order preservation.
In the split-bridge model, the system that transmits an Explorer frame onto the PPP link MUST update the RIF on behalf of the two systems, to ensure interoperability and preserve the simplicity of the bridging algorithm.
PPP links supporting Bridging MUST negotiate an MRU large enough to support the MAC Types negotiated for Bridging support, since bridged Ethernet frames are larger than the default PPP MRU of 1500 octets.
The Bridge-Identification option MUST NOT be included in the same Configure-Request as the Line-Identification option, as the two options model mutually exclusive bridging configurations.
The MAC-Support Configuration Option MUST NOT be included in a Configure-Nak, as it is advisory only.
The two half-bridges MUST agree on bridge number in the Bridge-Identification option; if a bridge number is not agreed upon, the Bridging Control Protocol MUST NOT enter the Opened state.
BCP uses PPP Protocol type 0x8031 and is a Network Control Protocol (NCP) that follows the same packet exchange mechanism as LCP, using only Codes 1–7 (Configure-Request through Code-Reject); other codes SHOULD result in Code-Rejects.
Seven BCP Configuration Options are defined: Bridge-Identification (1), Line-Identification (2), MAC-Support (3), Tinygram-Compression (4), LAN-Identification (5), MAC-Address (6), and Spanning-Tree-Protocol (7).
The MAC Type field in the Bridged LAN Traffic header identifies the frame type and address bit ordering: values 1–4 cover IEEE 802.3/Ethernet (canonical), 802.4, 802.5 (non-canonical), and FDDI (non-canonical); values 11–12 are canonical variants of 802.5 and FDDI.
BCP Option Type values 1–7 are assigned by this document and referenced from the Assigned Numbers RFC: Bridge-Identification=1, Line-Identification=2, MAC-Support=3, Tinygram-Compression=4, LAN-Identification=5, MAC-Address=6, Spanning-Tree-Protocol=7.
Spanning Tree Protocol values for the Spanning-Tree-Protocol option and BPDU PPP Protocol field: 0=Null, 1=IEEE 802.1D, 2=IEEE 802.1G extended, 3=IBM Source Route, 4=DEC LANbridge 100; hex wire values 0x0201/0x0203/0x0205 used in BPDU frames.
Security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are specified for BCP or bridged traffic carried over PPP.
Bridged 802.3 frames on PPP use PPP Protocol 0x0031, followed by a flags byte (F=LAN FCS present, I=LAN ID present, Z=zero-pad to minimum size), a Pads nibble, MAC Type byte, optional 32-bit LAN ID, Destination MAC, Source MAC, Length/Type, LLC data, optional LAN FCS, optional pad, and Frame FCS.
Bridged 802.4/802.5/FDDI frames differ from 802.3 in that a Pad Byte and Frame Control field precede the Destination MAC Address, and an optional Data Link Layer padding field follows the LLC data before the Frame FCS.
The Bridge-Identification and Line-Identification configuration options share the same 4-byte format: Type (1 octet), Length=4, a 12-bit LAN Segment Number, and a 4-bit Bridge Number, packed into two octets.
The MAC-Address option (Type 6, Length 8) carries six octets of MAC address in 802.1 Canonical order, with the Local Assignment (L) and Multicast (M) bits explicitly positioned within the first octet.
The Spanning Tree BPDU format over PPP uses PPP Protocol field set to the spanning tree protocol identifier (e.g., 0x0201 for IEEE 802.1D/G, 0x0203 for IBM Source Route Bridge), followed by BPDU data and Frame FCS; no MAC or 802.2 LLC header is present.