Point-to-Point Protocol extensions for bridging

LAN Frame Checksum Preservation is the protocol's primary optimized path because IEEE 802.1 requires an extended LAN to have the same probability of undetected error as a single LAN, and no algorithm other than end-to-end FCS preservation has been proposed to achieve this.

Magic Number Loopback Detection and LQM are strongly recommended because the IEEE 802.1 Spanning Tree protocol is inherently unidirectional during normal operation—only BPDUs from the Root flow outward with no reverse traffic—making it unable to detect unidirectional link failures on its own.

The PPP link is modeled as a standard IEEE 802.1 LAN interface rather than a separate serial-link mode, adopting the first of two competing IEEE 802.1 Interworking Committee models, because it simplifies the specification while still accommodating the ring-number-visibility requirements of Source Routing via optional BNCP options.

Tinygram Compression was introduced because protocols attractive for remote Ethernet bridging (often interactive-session protocols) frequently zero-pad PDUs to minimum Ethernet size, making zero-stripping an effective lossless compression technique specifically for low-speed (64 Kbps and below) links.

A device that performs Source Routing to Transparent Bridge translation acts as both a transparent and a source routing bridge on the PPP line simultaneously, behaving on the link exactly as it does on a LAN.

If a PPP neighbor receives IEEE 802.1 BPDUs without rejecting them with an RFC 1171 Protocol-Reject LCP PDU, Transparent Bridging is considered permitted on the link.

It is recommended that devices whose DMA controllers require even memory addresses negotiate to NOT use Protocol Field Compression except on low-speed links, since the odd-byte PPP protocol field causes alignment problems for such hardware.

A bridge configured to inhibit BPDU exchange on a link must silently discard any BPDU received from its neighbor, to preserve the separation of Spanning Tree domains.

A system that does not negotiate Tinygram Compression, or negotiates it disabled, should never receive a compressed packet.

A system which does not announce MAC Types may be assumed to support all MAC Types; a system that does announce MAC Types is advising its neighbor that all unspecified MAC Types will be discarded.

BNCP packets may not be exchanged until LCP has reached the network-layer Protocol Configuration Negotiation phase, and LAN traffic may not be exchanged until BNCP has first opened the connection.

BNCP uses only LCP Codes 1 through 7 (Configure-Request through Code-Reject); all other Code values must be treated as unrecognized and result in Code-Rejects.

In the absence of a determination about whether a bridged protocol requires ordered delivery, the transmitting station must act as though all protocols require order preservation when distributing traffic across multiple parallel links.

It is strongly recommended that Point-to-Point Bridge Protocol implementations utilize Magic Number Loopback Detection and Link-Quality-Monitoring, because the 802.1 Spanning Tree protocol is unidirectional during normal operation and reverse traffic only occurs in response to network events.

The negotiated MRU must be large enough to support the MAC Types negotiated for support, as there is no fragmentation and reassembly; even Ethernet frames exceed the default MRU of 1500 octets.

When a system that does not implement LAN Frame Checksum preservation receives a frame with an embedded FCS, it converts it by removing the trailing four octets; when forwarding a frame with no embedded FCS to a LAN, it forwards in a way that causes the FCS to be calculated.

LAN Frame Checksum Preservation carries the original LAN FCS calculated by the source station end-to-end across the PPP link. The FCS Present flag in the frame header signals its presence; its absence indicates the trailing four octets of LAN FCS were stripped.

The Bridge Network Control Protocol (BNCP) configures, enables, and disables bridge operation on both ends of the PPP link. It is structurally identical to LCP except it uses Protocol field 0x8031 and supports only Codes 1–7 with a separate set of Configuration Options: MAC Types supported, Tinygram Compression, LAN Identification, and Ring/Bridge Identification.

The LAN ID field is an optional 32-bit field that tags a bridged frame with a user-community identifier. Systems not implementing this feature must discard any frame that carries a LAN ID, treating it as belonging to a different community. The default is disabled.

Tinygram Compression removes trailing zero octets from short IEEE 802.3 PDUs (those at or below the minimum PDU size) before transmission on low-speed links, tagging the frame with the Zero-Compression flag so the receiver can re-pad to minimum 802.3 length. Compression is at the transmitter's option and is advisory.

Security issues are not discussed in this memo.

security

BNCP follows a strict ordering: (1) LCP must complete and reach network-layer Protocol Configuration Negotiation phase, (2) BNCP exchanges configuration options and opens the connection, (3) only then may LAN bridged traffic flow. An implementation must be prepared to wait for Link Quality testing to finish before timing out on Configure-Ack.

802.3 LAN traffic is carried under PPP Protocol 0x0031. The bridging header consists of a 1-byte Flags field (bits: FCS-present, LAN-ID-present, Zero-compression, reserved, and 4-bit pad count), a 1-byte MAC Type, an optional 4-byte LAN ID, followed by the full MAC frame (Destination MAC, Source MAC, Length/Type, LLC data) and optional LAN FCS.

802.4, 802.5, and FDDI frames use the same 0x0031 protocol and flag structure as 802.3 but prepend a pad byte and Frame Control field before the Destination MAC Address to preserve MAC-order bytes and avoid odd-boundary alignment problems.

IEEE 802.1 Bridge Hello PDUs (BPDUs) are carried under PPP Protocol 0x0201. The PDU contains only the raw 802.1(d) BPDU data with no MAC or 802.2 LLC header, no LAN pad, and no LAN FCS; Address and Control Fields are subject to standard PPP ACFC negotiation.

The LAN Identification Option (type=5, length=3 octets) carries a single byte: value 1 enables LAN ID support (labeled LANs exist beyond this system), value 2 disables it (all LAN-ID-tagged traffic will be dropped). Default is disabled.

The Line Identification Option (type=2, length=4 octets) has the same encoding as the Remote Ring Identification Option but represents the serial line itself as a virtual Token Ring; both peers must configure identical ring numbers for normal Source Routing operation.

The MAC Type Selection Option (type=3, length=3 octets) carries a single MAC Type byte advertising one LAN type the system is prepared to receive. Multiple options in a single Configure-Request advertise support for multiple MAC Types; values are 1=802.3/Ethernet, 2=802.4, 3=802.5, 4=FDDI, others IANA-assigned.

registry

The Remote Ring Identification Option (type=1, length=4 octets) encodes a 12-bit Token Ring ring number and a 4-bit bridge number in a single 16-bit field, exchanged via BNCP to identify the ring-and-bridge of the adjacent interface for Source Routing.

The Tinygram Compression Option (type=4, length=3 octets) carries a single byte: value 1 enables compression, value 2 disables it. No negotiation implies no compression.