UnifiedBus over Ethernet (UBoE)

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 7 January 2027.¶

Copyright Notice

Copyright (c) 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

UnifiedBus (UB) [UB2.0] is a high-performance layered interconnection protocol designed for large-scale AI and HPC clusters, providing ultra-low-latency data transmission and advanced remote memory access capabilities. To enable interworking between the UB domains and legacy standard Ethernet/IP networks, the UBoE protocol is defined to encapsulate native UB upper-layer protocol data within standard IPv4/IPv6 and UDP packets over Ethernet.¶

All UBoE deployment scenarios adopt a unified encapsulation format. Cross-protocol translation between UB and UBoE occurs in UB2E switch based deployment scenarios, where network-layer header adaptation is required to bridge UB-specific network layer metadata and standard IP/Ethernet forwarding semantics.¶

This document illustrates the UBoE encapsulation format, IP/UDP header field value configurations, and ICRC integrity verification rules. It specifies the UB-to-UBoE header adaptation behaviors at UB2E switches, including bidirectional adaptation logic and mapping rules between UB-specific network layer fields (including routing type, congestion markings and traffic isolation partitions) and Eth/IP network layer. It also analyzes the congestion control algorithm selection impacts introduced by semantic translation of congestion markings during packet conversion.¶

This document does not modify the UnifiedBus (UB) [UB2.0] specification. While some information regarding UBoE was implicitly scattered throughout UB [UB2.0], this document consolidates such content and supplements it with additional details necessary for UBoE but not explicitly defined in the original specification. It provides a comprehensive and explicit reference to assist the Internet community in understanding and implementing the UBoE endpoints or UB2E switches for interconnecting UB domains and Ethernet/IP domain.¶

2. Terminologies

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

CNP: Congestion Notification Packet¶

ECN: Explicit Congestion Notification¶

ICRC: Invariant Cyclic Redundancy Check¶

TPH: Transport Header¶

TAH: Transaction Header¶

UB: UnifiedBus¶

UBoE: UnifiedBus over Ethernet¶

UBPU: UB Processing Unit¶

3. UBoE Usage

UB system offers a rich set of I/O and memory services based on Unified Remote Memory Access(URMA) and/or load/store-like access methods. In a single UB domain, UB processing units (UBPU) always use native and full stack UB protocol to communicate with each other [UB2.0]. However, in some deployments, UBPUs across multiple UB domains want to enjoy such advanced features via an interconnected Ethernet/IP network to better reuse the existing network equipments.¶

Three typical UBoE deployment scenarios are defined in this document, covering endpoint direct encapsulation, single-ended switch conversion, and dual-ended bidirectional switch conversion. All scenarios share the same UBoE encapsulation formats, while switch-based scenarios introduce additional network header conversion and adaptation procedures.¶

Figure 1 depicts the UBoE direct pass-through encapsulation scenario. UBoE-capable endpoints (e.g. UBoE NIC) directly perform UBoE encapsulation, overlaying the UB transport layer and upper-layer protocols directly on top of the standard Ethernet/IP network layer. No intermediate protocol conversion devices are deployed. Cross-domain UB service communication is fully implemented by endpoint-based UBoE encapsulation and decapsulation. All Ethernet/IP intermediate devices forward UBoE packets transparently.¶

• UBoE endpoint: A UBoE capable endpoint where at least one port is configured for UBoE packet exchange, while the rest are configured for native UB and/or other packet types. It can be some processing units.¶

• UBoE NIC: A network interface card (NIC) capable of transmitting and receiving UBoE packets over the network. It is a specific UBoE endpoint.¶

===== domain boundary, not physical links
----- links

           +---------------------------------------------+
           |               Eth/IP switches               |
           +---------------------------------------------+
              |                    |                  |
              |                    |                  |
Eth/IP        |                    |                  |
domain    +-------+            +------+         +--------+
========= | UBoE  | ========== | UBoE |=========|  UBoE  | ====
three UB  | NIC1  |            | NIC2 |         |endpoint|
domains   +-------+            +------+         +--------+

Figure 2 illustrates the single-ended UB2E switch protocol conversion scenario, which introduces a single UB2E switch as the protocol conversion node between UB native domain and Ethernet/IP domain, different from the endpoint-only encapsulation mode in Figure 1. For any single data flow in this scenario, only unidirectional protocol conversion is supported: either native UB packets from the UB domain are encapsulated into UBoE packets for Ethernet/IP transmission, or UBoE packets from the IP domain are decapsulated into native UB packets to access the local UB domain.¶

Limited by the single-ended conversion mechanism, some UB-specific network header field information is discarded when converting to IP network header.¶

• UBPU: UB Processing Unit, designed to generate, transmit, and receive native UB packets.¶

• UB2E switch: A UB switch with an integrated UB-to-UBoE packet conversion function, enabling seamless interoperability between UB and Ethernet/IP networks.¶

===== domain boundary, not physical links
----- links

           +---------------------------------------------+
           |               Eth/IP switches               |
           +---------------------------------------------+
              |                    |                  |
              |                    |                  |
Eth/IP        |                    |                  |
domain    +-------+            +------+         +--------+
========= | UB2E  | ========== | UBoE |=========| UBoE   | ====
three UB  | switch|            | NIC2 |         |endpoint|
domains   +-------+            +------+         +--------+
            |   |
        ----    ----
       |            |
   +-------+      +-------+
   | UBPU  | ...  | UBPU  |
   +-------+      +-------+

Figure 3 shows the the dual-ended UB2E switch protocol conversion scenario, deploying UB2E switches at both ingress and egress of the Ethernet/IP domain. Different from the single point conversion in Figure 2, the ingress UB2E switch converts native UB packets to UBoE packets, while the egress UB2E switch parses UBoE packets and potentially restores them to a more complete native UB packets for peer UB domain access.¶

===== domain boundary, not physical links
----- links



          +------------------------------------------+
          |               Eth/IP switches            |
          +------------------------------------------+
              |                                  |
Eth/IP        |                                  |
domain    +-------+        Eth/IP domain     +-------+
========= | UB2E  | ======================== | UB2E  | =====
two UB   _| switch|__       UB domains      _| switch|__
domains | +-------+  |                     | +-------+  |
        |            |                     |            |
        |            |                     |            |
    +-------+      +-------+          +-------+     +-------+
    |UBPU x | ...  |UBPU y |          |UBPU m | ... |UBPU n |
    +-------+      +-------+          +-------+     +-------+

All three deployment scenarios use UBoE encapsulation over standard IP network layers. Detailed specifications on IP and UDP header fields for UBoE packets are defined in Section 4.¶

Only Figure 2 (Single-Ended UB2E Switch Conversion) and Figure 3 (Double-Ended UB2E Switch Conversion) deploy UB2E switches to perform bidirectional packet translation between native UB network encapsulation and UBoE encapsulation. The protocol adaptation rules, field mapping logic, and header conversion behaviors of UB2E switches are elaborated in Section 5.¶

4. UBoE Packet Format and IP Header Fields

Figure 4 shows a protocol stack overview of UB and UBoE. UBoE encapsulation wraps the UB transport, transaction and payload data inside the IPv4/IPv6 and UDP headers, forming IP-routable packets that can traverse general Ethernet/IP fabrics.¶

        +------------------+         +---------------------+
        | UB Transaction   |         |   UB Transaction    |
        +------------------+         +---------------------+
        | UB Transport     |         |   UB Transport      |
        +------------------+         +---------------------+
        | UB Network Layer |         |     UDP + IP        |
        +------------------+         +---------------------+
        | UB Link Layer    |         | Ethernet Link Layer |
        +------------------+         +---------------------+
        | UB Physical      |         |   Ethernet Physical |
        +------------------+         +---------------------+
               UB                           UBoE

The UBoE frame structure is shown in Figure 5, used by all three deployment scenarios described in Section 3.¶

UB transport header(TPH) follows UDP header in UBoE packet. [UB2.0] defines three transport modes, reliable transport (RTP), unreliable transport (UTP) and compact transport (CTP). It also supports transport bypass configuration, meaning no transport header is present. Readers may refer to Section 6 of [UB2.0] for details regarding the rationale and method for selecting each transport enablement.¶

UBoE only uses UB RTP or UTP transport mode. TPH is 16 bytes in length in both modes. Compact transport (CTP) mode and transport bypass are not support in UBoE.¶

                    |<-------   IP payload ------------------>|
+----------+--------+---------+-------+-------+--------+------+---+
|Eth L2 Hdr| IP Hdr | UDP Hdr |UB TPH |UB TAH |payload | ICRC |FCS|
+----------+--------+---------+-------+-------+--------+------+---+
        ^         ^        ^       ^       ^               ^
        |         |        |       |       |               |
EtherType=IP      |        |       |       |               |
Protocol=UDP ------        |       |       |               |
dest port=IP routable UB----       |       |               |
UB Transport Header (TPH) ----- ----       |               |
UB Transaction Header (TAH)   --------------               |
ICRC protection starting from IP Hdr to payload  -----------

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Source Port         |       Dest Port = 4792        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           UDP Length          |        UDP Checksum           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. UB and UBoE Conversion and Adaptation

As introduced in Section 3, Figure 2 (Single-Ended UB2E Switch Conversion) and Figure 3 (Double-Ended UB2E Switch Conversion) leverage UB2E switches to perform the cross-protocol translation between native UB packets and UBoE packets. This section specifies such packet conversion and header adaptation logic. The key of UB/UBoE conversion lies in the conversion of network-layer headers.¶

The native UB protocol stack supports three distinct types of network layer addresses, each with a specific length corresponding to a slightly different network layer header format. Among them, one type carries a standard IP header; therefore, we refer to this specific format as the IP-compliant UB network header.¶

Figure 7 illustrates the logical view of the IP-compliant UB network header. It essentially consists of two parts: the UB-specific network information fields and a standard IPv4/IPv6 header format. The former part is intended to provide richer or more specific information within the native UB domain as follows.¶

• RT (2b): Routing type.¶

• CCI (16b): Congestion control indicator.¶

• NPI (25b): Network partition identifier.¶

UB-specific network info fields        exact same as IP header
(logically, not the exact format)                |
                 |                               |
                 |                               |
                 v                               v
+---------------------------------+-------------------------------+
| additional info (RT, CCI, NPI)  | standard IPv4/v6 header format|
+---------------------------------+-------------------------------+

When interconnecting the UB domain with Eth/IP networks via a switch, only the IP-compliant UB network header is permitted for data packet within the UB domain. This constraint ensures that the UB2E switch can seamlessly extract the IP header from the UB network header, and vice versa. The UB domain MUST employ appropriate configuration, management tools, and software to enforce this requirement.¶

  UB pkt with the IP-Compliant
  UB Network Header               +--------+     UBoE packet
  ------------------------------> |  UB2E  | ------------------>
  <------------------------------ | switch | <-----------------
         UB domain                +--------+    Eth/IP domain

When forwarding a packet between the UB domain and the Eth/IP domain, as shown in Figure 8, as the IP-compliant UB network header inherently contains a standard IP header, the switch directly reuses this standard IP header portion during packet conversion. The fields within this preserved IP header SHOULD remain consistent with the rules defined in the tables of Section 4.1.¶

The fundamental structural difference between the two network-layer headers is that the IP-compliant UB network header carries additional UB-specific metadata RT, CCI and NPI. The switch strips these three fields and embed the required information in other standard UBoE fields with adaptation when converting UB packets to UBoE for egress to IP networks, and reconstructs them when converting inbound UBoE packets back to native UB format using some rules. The following subsections break down the adaptation required for RT, CCI and NPI information.¶

+--------------------------------------------------------------+
| Permission |                       ID                        |
|   1-bit    |                     24-bit                      |
+--------------------------------------------------------------+

6. Security Considerations

UBoE inherits all security constraints and isolation mechanisms defined in the UB 2.0 base specification [UB2.0]. Encapsulating UB upperlayer data payload in standard UDP/IP packets does not introduce new security vulnerabilities. Standard IP security practices, including access control lists, VLAN isolation, and traffic filtering, can be deployed to protect UBoE cross-domain traffic.¶

Misconfiguration of NPI-to-VLAN mapping rules may cause partition isolation or privilege control anomalies. Operators shall strictly manage UB2E switch mapping policies and partition allocation to avoid cross-domain unauthorized traffic leakage. No new security extensions or threats specific to UBoE are introduced in this specification.¶

7. IANA Considerations

A well-known UDP port (4792) has been assigned by the IANA in the Service Name and Transport Protocol Port Number Registry for IP Routable UB. UBoE uses this UDP port number.¶

8. Acknowledgements

Thanks to Liudong Xiong and Chuanning Cheng for their review and comments. Thanks to Wei Pan for sharing his knowledge on the registered UDP port (4792).¶

9. References

Authors' Addresses