Network Working Group A. Spera Internet-Draft P. Broccardi Intended status: Informational Cisco Systems Expires: 20 January 2026 19 July 2025 Bitstream Transport over Ethernet (BToE) draft-spera-btoe-00 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 Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Spera & Broccardi Expires 20 January 2026 [Page 1] Internet-Draft Bitstream Transport over Ethernet (BToE) July 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 3.1. Frame-Centric Limitations . . . . . . . . . . . . . . . . 2 3.2. Lack of Bit-Level Visibility . . . . . . . . . . . . . . 3 3.3. ASIC/FPGA and Cable Diagnostics . . . . . . . . . . . . . 3 4. BToE Architecture . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Buffering and Transport . . . . . . . . . . . . . . . . . 3 4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 3 5. Encapsulation and VLAN Tagging . . . . . . . . . . . . . . . 4 6. Conceptual Implementation Considerations . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] and RFC 8174 [RFC8174]. 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. Spera & Broccardi Expires 20 January 2026 [Page 2] Internet-Draft Bitstream Transport over Ethernet (BToE) July 2025 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: Spera & Broccardi Expires 20 January 2026 [Page 3] Internet-Draft Bitstream Transport over Ethernet (BToE) July 2025 +------------------------+ | 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: Spera & Broccardi Expires 20 January 2026 [Page 4] Internet-Draft Bitstream Transport over Ethernet (BToE) July 2025 - 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 8. IANA Considerations This document makes no request of IANA. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Authors' Addresses Adam Spera Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America Email: adamspera@hotmail.com Paul Broccardi Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America Email: paulbroccardi@gmail.com Spera & Broccardi Expires 20 January 2026 [Page 5]