Bitstream Transport over Ethernet (BToE)

Internet-Draft	Bitstream Transport over Ethernet (BToE)	July 2025
Spera & Broccardi	Expires 20 January 2026	[Page]

Abstract

This document defines Bitstream Transport over Ethernet (BToE), a method for capturing and transporting raw Layer 1 bitstream data across Ethernet Layer 2 networks. Unlike traditional frame-based transport mechanisms, BToE enables fully transparent transmission of physical layer signals, allowing for cable fault isolation, ASIC/FPGA debugging, and transceiver validation by preserving the integrity of all bits, including those outside valid Ethernet frames.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 January 2026.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

1. Introduction

Traditional Layer 2 tunneling and encapsulation mechanisms rely on the presence of syntactically valid Ethernet frames. Technologies such as SPAN, RSPAN, ERSPAN, and L2VPN XConnect are valuable for forwarding frame-aligned data but fail to address scenarios that require examination of physical-layer signals or invalid bit-level sequences. BToE (Bitstream Transport over Ethernet) addresses this gap by defining a method to transport raw bitstreams, prior to frame recognition or protocol validation.¶

3. Problem Statement

3.1. Frame-Centric Limitations

Existing frame-based mechanisms for traffic capture and transport require valid Ethernet framing. Protocols that are not supported or frames that are malformed cannot be reliably captured, resulting in diagnostic blind spots. Even Layer 2 protocol tunneling mechanisms cannot address physical-layer abnormalities that prevent frame construction.¶

3.2. Lack of Bit-Level Visibility

Faults at the physical layer — including bit-level corruption, alignment errors, clock mismatches, and FCS violations — often occur prior to or during frame construction. These are undetectable by tools that rely on frame interpretation.¶

3.3. ASIC/FPGA and Cable Diagnostics

In ASIC, FPGA, and transceiver validation workflows, engineers require access to the raw serialized line signal, including symbols and bits that never result in valid Ethernet frames. No standard mechanism exists today to extract and transport this data for remote analysis.¶

4. BToE Architecture

4.1. Overview

BToE defines a mechanism for capturing raw bitstreams on an ingress interface at the physical layer and encapsulating those bits into Ethernet payloads that can be delivered across a Layer 2 infrastructure. This allows transparent inspection and transport of all data on a link, including error sequences, idle characters, and malformed transmissions.¶

4.2. Buffering and Transport

A buffer is allocated per ingress port to collect bitstream data. The size of this buffer is configurable and defines how many bits should be collected prior to encapsulation. Optionally, a timeout may be defined to ensure data is not delayed indefinitely in the absence of new input.¶

Once the buffer threshold or timeout condition is met, the bits are encapsulated into a BToE frame and forwarded to a designated receiver.¶

4.3. Frame Format

The encapsulating Ethernet frame is structured as follows:¶

+------------------------+
| Ethernet Header        |
+------------------------+
| 802.1Q VLAN Tag        |
+------------------------+
| Raw Bitstream Payload  |
+------------------------+
| Frame Check Sequence   |
+------------------------+

The payload carries the raw bitstream exactly as captured at the ingress PHY interface, without any framing, alignment, or protocol-awareness applied. There is no protocol-specific BToE header within the payload.¶

5. Encapsulation and VLAN Tagging

The BToE payload is transported inside a VLAN-tagged Ethernet frame using 802.1Q. VLAN IDs may be pre-negotiated between sender and receiver to define dedicated transport paths for BToE traffic. No new EtherType is introduced; instead, existing encapsulation practices are reused with reserved VLANs or destination MAC addresses to identify BToE frames.¶

6. Conceptual Implementation Considerations

BToE-capable ingress interfaces must be able to extract the serialized bitstream from the physical layer and feed it into a buffer.¶

The buffer should support configurable size (in bits) and flush timeout.¶

At the transmission boundary, the system encapsulates buffered bits directly into Ethernet frames with VLAN tagging.¶

On the receiving side, the payload is decapsulated, and bitstream data is reconstructed for analysis, replay, or validation.¶

Transport domains should logically isolate BToE traffic to prevent interference with operational data.¶

7. Security Considerations

Transporting raw bitstreams introduces new privacy and integrity risks. BToE bypasses higher-layer protocol parsing and may transmit sensitive or malformed data without inspection. Deployments should ensure:¶

- Logical and physical isolation of BToE VLANs - Transport-layer encryption when traversing untrusted domains - Rate limiting or filtering to prevent replay or injection of invalid BToE frames¶