UnifiedBus over Ethernet (UBoE)
draft-li-uboe-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yizhou Li , Yali Zhang , Peng Zheng | ||
| Last updated | 2026-07-14 (Latest revision 2026-07-05) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | Submission Received | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-uboe-00
Independent Stream Y. Li
Internet-Draft Y. Zhang
Intended status: Informational P. Zheng
Expires: 7 January 2027 Huawei Technologies
6 July 2026
UnifiedBus over Ethernet (UBoE)
draft-li-uboe-00
Abstract
This document specifies the UnifiedBus over Ethernet (UBoE) protocol,
which enables seamless interconnection between native UnifiedBus (UB)
domains and standard Ethernet/IP network for AI and HPC high-
performance scenarios. It defines the UBoE packet encapsulation
based on IPv4/IPv6 and UDP over Ethernet, including the invariant CRC
(ICRC) integrity protection for end-to-end packet verification. This
document further specifies the cross-domain packet conversion and
header adaptation behaviors at UB2E switches, including bidirectional
mapping rules for UB-specific network layer and IP network layer.
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
Li, et al. Expires 7 January 2027 [Page 1]
Internet-Draft UBoE July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. UBoE Usage . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. UBoE Packet Format and IP Header Fields . . . . . . . . . . . 6
4.1. IP and UDP Header fields for UBoE Packets . . . . . . . . 8
4.2. ICRC for UBoE Packets . . . . . . . . . . . . . . . . . . 10
5. UB and UBoE Conversion and Adaptation . . . . . . . . . . . . 11
5.1. Adaptation of RT (Routing Type) . . . . . . . . . . . . . 12
5.2. Adaptation of CCI (Congestion Control Indicator) . . . . 13
5.2.1. FECN and ECN Semantic Comparison and Mapping Rules . 14
5.2.2. Impact on Transport Congestion Control Loop . . . . . 16
5.3. Adaptation of NPI (Network Partition Identifier) . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
Li, et al. Expires 7 January 2027 [Page 2]
Internet-Draft UBoE July 2026
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.
Li, et al. Expires 7 January 2027 [Page 3]
Internet-Draft UBoE July 2026
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 1: UBoE Direct Pass-Through Encapsulation Deployment
Li, et al. Expires 7 January 2027 [Page 4]
Internet-Draft UBoE July 2026
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 2: Single-Ended UB2E Switch Conversion Deployment
Li, et al. Expires 7 January 2027 [Page 5]
Internet-Draft UBoE July 2026
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 |
+-------+ +-------+ +-------+ +-------+
Figure 3: Dual-Ended UB2E Switch Conversion Deployment
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.
Li, et al. Expires 7 January 2027 [Page 6]
Internet-Draft UBoE July 2026
+------------------+ +---------------------+
| 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
Figure 4: UB and UBoE Protocol Stack
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 -----------
Figure 5: UBoE Frame Structure
Li, et al. Expires 7 January 2027 [Page 7]
Internet-Draft UBoE July 2026
4.1. IP and UDP Header fields for UBoE Packets
UBoE supports both IPv4 and IPv6. The formats of the IPv4 header and
IPv6 header are conformant with [RFC0791], [RFC2474], [RFC3168] and
[RFC8200]. Table 1 and Table 2 below show the values for relevant
fields in IPv4 header and IPv6 header of UBoE packets respectively.
+================+================================================+
| Relevant IPv4 | Value |
| Header Field | |
| in UBoE | |
+================+================================================+
| Internet | 5 |
| Header Length | |
| (IHL) | |
+----------------+------------------------------------------------+
| Differentiated | Set to a proper value for UB traffic. |
| Services | |
| Codepoint | |
| (DSCP) | |
+----------------+------------------------------------------------+
| Explicit | Set to '01' or '10' to indicate that the |
| Congestion | packet can be marked in the network to |
| Notification | indicate congestion [RFC3168]; otherwise, set |
| (ECN) | to '00'. Refer to Section 5 for field mapping |
| | rules when UB2E switch conversion is used. |
+----------------+------------------------------------------------+
| Total Length | Set to the length of the IPv4 packet in bytes |
| | including the IPv4 header and up to and |
| | including the ICRC. |
+----------------+------------------------------------------------+
| Flags | '010'. Don't fragment bit is set. |
+----------------+------------------------------------------------+
| Fragment | 0 |
| Offset | |
+----------------+------------------------------------------------+
| Time to Live | Set to a value greater than the network |
| | diameter. |
+----------------+------------------------------------------------+
| Protocol | 0x11 for UDP |
+----------------+------------------------------------------------+
| Source Address | IP address of the source UB end point |
+----------------+------------------------------------------------+
| Destination | IP address of the destination UB end point |
| Address | |
+----------------+------------------------------------------------+
Table 1: UBoE with IPv4 header
Li, et al. Expires 7 January 2027 [Page 8]
Internet-Draft UBoE July 2026
+================+================================================+
| Relevant IPv6 | Value |
| Header Field | |
| in UBoE | |
+================+================================================+
| Differentiated | Set to a proper value for UB traffic. |
| Services | |
| Codepoint | |
| (DSCP) | |
+----------------+------------------------------------------------+
| Explicit | Set to '01' or '10' to indicate that the |
| Congestion | packet can be marked in the network to |
| Notification | indicate congestion [RFC3168]; otherwise, set |
| (ECN) | to '00'. Refer to Section 5 for field mapping |
| | rules when UB2E switch conversion is used. |
+----------------+------------------------------------------------+
| Payload Length | Set to the length of the IPv6 packet payload |
| | starting from the first byte after the IPv6 |
| | header up to and including the ICRC. |
+----------------+------------------------------------------------+
| Next Header | 0x11 for UDP |
+----------------+------------------------------------------------+
| Hop Limit | Set to a value greater than the network |
| | diameter. |
+----------------+------------------------------------------------+
| Source Address | IP address of the source UB end point |
+----------------+------------------------------------------------+
| Destination | IP address of the destination UB end point |
| Address | |
+----------------+------------------------------------------------+
Table 2: UBoE with IPv6 header
Figure 6 shows the UDP header fields for UBoE :
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: UDP Header for UBoE Packet
* Destination Port: IANA has assigned the value 4792 for IP Routable
UB UDP port, and this value SHOULD be used by default as the
destination UDP port for UBoE. This well-known port is also used
Li, et al. Expires 7 January 2027 [Page 9]
Internet-Draft UBoE July 2026
to carry UB transport and upper-layer information over UDP over
IP-address-compatible UB network layer. This draft only focuses
on UBoE.
* Source Port: It is recommended that the UDP source port number be
used as load balance factor. This is to enable a level of entropy
for the traffic load-balancing. The implementation is free to
choose a proper granularity for load-balancing, e.g., flow-based
or packet-based.
* UDP Checksum: It SHOULD be transmitted as zero. When a packet is
received with a UDP checksum of zero, it MUST be accepted for
decapsulation. Optionally, if the UBoE encapsulating end point
includes a non-zero UDP checksum, it MUST be correctly calculated
across the entire packet as per [RFC0768]. When a UBoE
decapsulating end point receives a packet with a non-zero
checksum, it MAY choose to verify the checksum value. If it
chooses to perform such verification, and the verification fails,
the packet MUST be dropped. If the decapsulating destination
chooses not to perform the verification, or performs it
successfully, the packet MUST be accepted for decapsulation.
4.2. ICRC for UBoE Packets
UBoE implements a 32-bit ICRC to offer the end-to-end integrity
protection of the entire IP packets. Calculation starts with the
first byte of the IP header up until and including the last UB
Payload byte right before the ICRC field itself.
The following variant fields in the IP header and UDP header are
replaced with all ones in ICRC calculation/check to ensure the
changes to these fields along the way donot affect the calculated
ICRC value.
* IPv4 for UBoE
- Time to Live
- Header Checksum
- Type of Service (DSCP and ECN)
* IPv6 for UBoE
- Traffic Class (DSCP and ECN)
- Flow Label
Li, et al. Expires 7 January 2027 [Page 10]
Internet-Draft UBoE July 2026
- Hop Limit
* UDP for UBoE
- Checksum
The ICRC detailed calculation rules follow the ICRC section in
[UB2.0].
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|
+---------------------------------+-------------------------------+
Figure 7: Logical View of the IP-Compliant UB Network Header
Li, et al. Expires 7 January 2027 [Page 11]
Internet-Draft UBoE July 2026
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
Figure 8: Conversion and adaption by UB2E switch
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.
5.1. Adaptation of RT (Routing Type)
The UB IP-compliant network header includes a 2-bit Routing Type (RT)
field that controls the load balancing mode and multipath route
selection policy within the UB domain. The RT field settings are
defined as follows:
Li, et al. Expires 7 January 2027 [Page 12]
Internet-Draft UBoE July 2026
+==========+=====================+==================================+
| RT Value | Load Balancing Mode | Multipath Route |
| | | Selection Policy |
+==========+=====================+==================================+
| 00 | Per-flow | All available |
| | | paths |
+----------+---------------------+----------------------------------+
| 01 | Per-packet | All available |
| | | paths |
+----------+---------------------+----------------------------------+
| 10 | Per-flow | The Shortest |
| | | paths only |
+----------+---------------------+----------------------------------+
| 11 | Per-packet | The Shortest |
| | | paths only |
+----------+---------------------+----------------------------------+
Table 3: Routing Type (RT) field in UB IP-Compliant network Header
Since the standard IP header and Ethernet frame do not have
equivalent fields to carry routing type information, the RT field
requires special handling during conversion.
UB to Eth/IP Direction: The RT information in the UB network header
is discarded.
Eth/IP to UB Direction: RT field must be populated. Value set to 10
(Per-flow, Shortest paths) as default. The standard Ethernet
routers/switches typically perform per-flow load balancing based on
5-tuple hash and select among the shortest paths, this default value
aligns with that behavior, so that the UB domain will not
misinterpret how the packet is forwarded in the Eth/IP domain.
The RT field MAY be configurable by network administrators to
accommodate specific deployment requirements for Eth/IP to UB
Direction. However, the default value of 10 is RECOMMENDED for most
deployments to ensure consistent behavior with standard Ethernet
switching.
5.2. Adaptation of CCI (Congestion Control Indicator)
UB 2.0 [UB2.0] defines multiple CCI modes for congestion indicators
in the UB domain. Only the FECN mode supports compatible mapping
with standard IP ECN natively, which is mandatory for UB/UBoE
interworking via UB2E switches. Table 4 summarizes the CCI modes and
their suitability for UB to UBoE conversion network layer.
Li, et al. Expires 7 January 2027 [Page 13]
Internet-Draft UBoE July 2026
+==========+==============+=============+===========================+
| CCI Mode | Description | Suitability | Reason |
+==========+==============+=============+===========================+
| CAQM | Active queue | No | Relies on richer UB- |
| | management | | specific fields like |
| | with | | Hint or Increase for |
| | bandwidth | | bandwidth control, |
| | control | | unmapable to standard |
| | | | IP ECN |
+----------+--------------+-------------+---------------------------+
| FECN | Forward ECN | Yes | The 2-bit FECN field |
| | with | | naturally maps to the |
| | severity | | 2-bit IP ECN field, |
| | levels | | aligning with standard |
| | | | mechanisms with some |
| | | | adaptations. |
+----------+--------------+-------------+---------------------------+
| FECN_RTT | FECN with | No | Requires a Timestamp |
| | Timestamp | | field for RTT |
| | for | | measurement, which is |
| | | | not available in |
| | | | standard IP ECN. |
+----------+--------------+-------------+---------------------------+
Table 4: CCI Mode Suitability for UB-to-UBoE by Switch
As shown in Table 4 , the UB endpoints SHOULD configure the CCI field
to use the FECN mode (CCI.Mode = 3'b100). This ensures that the
congestion information can be seamlessly mapped to the standard IP
ECN field, allowing intermediate standard Ethernet switches to
correctly recognize and process congestion markings. If the other
CCI mode is configured, the administrator need ensure that the switch
implements the compatible protocol extension in Eth/IP domain.
5.2.1. FECN and ECN Semantic Comparison and Mapping Rules
The IP ECN field defined in [RFC3168] uses a 2-bit codepoint to
indicate congestion. While UB FECN also uses a 2-bit field for
congestion marking, their semantic definitions and the amount of
information carried differ. Table 5 summarizes the semantic
comparison between the two.
CE: Congestion Experienced
Li, et al. Expires 7 January 2027 [Page 14]
Internet-Draft UBoE July 2026
+========+============+=============+==========================+
| 2-bit | UB FECN | IP ECN | Semantic Equivalence |
| (F)ECN | Meaning | Meaning | |
| value | | [RFC3168] | |
+========+============+=============+==========================+
| 00 | Unmarkable | Not-ECT | Yes |
+--------+------------+-------------+--------------------------+
| 01 | Light CE | ECT(1), | No. Note: Various |
| | | ECN-Capable | usages exist for ECT(1), |
| | | | some are proprietary. |
+--------+------------+-------------+--------------------------+
| 10 | Markable | ECT(0), | Yes |
| | | ECN-Capable | |
+--------+------------+-------------+--------------------------+
| 11 | Severe CE | CE | Yes |
+--------+------------+-------------+--------------------------+
Table 5: Semantic Comparison of UB FECN and IP ECN Codepoints
When converting packets between UB and Eth/IP domains, the UB2E
switch performs bidirectional mapping between the 2-bit FECN field in
UB FECN CCI mode and the 2-bit IP ECN field. The detailed mapping
rules are as follows:
Congestion Experienced (CE) Mapping:
* FECN to ECN: The mapping behavior for Light CE (01) and Severe CE
(11) in UB FECN to the CE (11) codepoint in IP ECN is
configurable. The switch can be configured to map both Light CE
and Severe CE to IP ECN-CE, or to map only Severe CE to IP ECN-CE
(while mapping Light CE to an ECN-Capable state). The default to
map both to IP ECN-CE. When both are mapped to IP ECN-CE, the
severity distinction is lost during this conversion, and both are
treated as equivalent to the standard CE state.
* ECN to FECN: The CE (11) codepoint in IP ECN can be uniformly
configured to map to either Light CE (01) or Severe CE (11) in UB
FECN. The default is mapping to Severe CE (11).
ECN-Capable / Markable Mapping:
* FECN to ECN: The Markable (10) state in UB FECN can be configured
to map to either ECT(0) (10) or ECT(1) (01) in IP ECN. The
default mapping is ECT(0) (10).
* ECN to FECN: Compliant with [RFC3168], both ECT(0) (10) and ECT(1)
(01) in IP ECN are mapped to the Markable state (10) in UB FECN by
default.
Li, et al. Expires 7 January 2027 [Page 15]
Internet-Draft UBoE July 2026
Some proprietary implementations utilize the IP ECN ECT(1) (01)
codepoint to indicate a lower severity of congestion, which is
equivalent to Light CE (01) in UB FECN. Then a strict one-to-one
semantic mapping can be established between UB FECN and IP ECN
codepoints.
Handling of Additional UB Congestion Related Information: Beyond the
2-bit congestion marking, the UB FECN CCI mode contains additional
congestion information, i.e. the Location of Congestion (LoC) bit.
Since the standard IP ECN field has no equivalent mechanism to carry
this extra information, the LoC bit in the FECN CCI mode will be
discarded when converting a packet to the Eth/IP domain. Conversely,
when converting from the Eth/IP domain to the UB domain, LoC bit is
restored to 0 by default, indicating congestion, if any, occurs at an
intermediate switch .
5.2.2. Impact on Transport Congestion Control Loop
FECN/ECN mapping at network-layer affects the end-to-end UB transport
congestion control loop, which relies on receiver-side congestion
marking feedback to trigger sender rate adjustment. As specified in
Section 5.2, the endpoint is restricted to use congestion control
algorithms based on FECN CCI mode for switch based UBoE scenarios,
while CAQM and FECN_RTT CCI modes are not mappable without specific
extensions in congestion marking.
The native UB protocol supports multiple customizable congestion
control algorithms, including Low Delay Control Protocol (LDCP),
Confined Active Queue Management (CAQM), and DCQCN-like mechanisms.
CAQM is not viable for UB/UBoE conversion scenario without specific
extension of CAQM CCI mode. Therefore LDCP and DCQCN-like mechanisms
are applicable in UB/UBoE interconnection scenarios.
Two types of receivers exist in switch-based UBoE deployments, UBoE
endpoints (direct IP termination) and native UB endpoints behind UB2E
switches. UBoE endpoints directly use IP ECN-CE as the congestion
signal, while native UB endpoints behind UB2E switches use the
restored UB FECN markings. Receivers adopt whichever valid
congestion marking signal is available according to their deployment
type.
The DCQCN-like Algorithm in UB uses the Congestion Notification
Packet (CNP) to echo back the congestion markings and optionally
supports two congestion levels, namely light congestion and severe
congestion. Therefore, if a receiver can only get single congestion
level based IP ECN-CE in UBoE scenarios, it shall either disable the
two-level congestion reporting in CNP feedback or treat all ECN-CE
markings as equivalent to severe congestion in CNP.
Li, et al. Expires 7 January 2027 [Page 16]
Internet-Draft UBoE July 2026
5.3. Adaptation of NPI (Network Partition Identifier)
The UB IP-compliant network header includes a 25-bit Network
Partition Identifier (NPI) field to enforce logical traffic isolation
among network partitions in UB domains. Figure 9 shows the NPI field
format.
+--------------------------------------------------------------+
| Permission | ID |
| 1-bit | 24-bit |
+--------------------------------------------------------------+
Figure 9: NPI field format in UB IP-Compliant network Header
* Permission bit (1 bit): The most significant bit indicating
endpoint privilege level. 0 indicates high privilege, 1 indicates
low privilege.
* Partition ID (24 bits): Identifies the network partition. ID
value 0 is invalid, and ID value 1 represents the default
partition.
In native UB domains, endpoints belonging to different Partition IDs
cannot intercommunicate. For endpoints sharing the same Partition
ID, the Permission bit provides secondary fine-grained access
control: communication is permitted for high-to-high and high-to-low
privileged pairs, while low-to-low communication is prohibited.
Notably, UB switches only validate the Partition ID during forwarding
and do not check the Permission bit; privilege is enforced at UB
endpoints.
Both UB NPI and Ethernet VLAN mechanisms provide traffic isolation,
these two fields are mapped at the UB2E switch in UB/UBoE conversion.
Since standard Ethernet VLAN has no equivalent privilege concept, the
permission bit is discarded in baseline UB-to-UBoE conversion and set
to high-privilege (0) by default in the reverse direction.
The detailed mapping rules at UB2E switch are defined as follows:
UB to Eth/IP Direction:
* The 24-bit Partition ID is mapped to the 12-bit VLAN ID. The
mapping takes the lower 12 bits of the Partition ID. If the
Partition ID exceeds 12 bits (4095), the upper bits are truncated,
and administrators MUST ensure that Partition IDs in the same UB
domain do not collide after truncation.
Li, et al. Expires 7 January 2027 [Page 17]
Internet-Draft UBoE July 2026
* The 1-bit Permission bit is removed during UB-to-UBoE translation
and is not carried in Ethernet/IP frames.
* UB2E switches support configurable NPI-to-VLAN translation.
Eth/IP to UB Direction:
* The 12-bit VLAN ID from the Ethernet frame is mapped to the lower
12 bits of the 24-bit Partition ID in the UB domain. The upper 12
bits of the Partition ID are set to 0 by default.
* The Permission bit is set to 0 (high privilege) by default,
allowing maximum compatibility and communication capability.
* UB2E switches support configurable VLAN-to-NPI translation.
UB2E switches in Figure 3 (Double-Ended UB2E Switch Conversion) may
support an optional enhanced mapping to restore the original
Permission bit information instead of to use the default. In this
optional mode, the ingress UB2E switch maps one Partition ID with
different Permission bit values (0/1) to two distinct VLAN IDs. The
egress UB2E switch restores both the original Partition ID and the
original Permission bit from the VLAN ID. However it consumes more
VLAN IDs and has more complex configurations. Administrators can
enable it based on deployment requirements.
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.
Li, et al. Expires 7 January 2027 [Page 18]
Internet-Draft UBoE July 2026
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
9.1. Normative References
[UB2.0] "UnifiedBus(UB) Base Specification 2.0", 2025,
<https://www.unifiedbus.com/en/docs/UB-Base-Specification-
2.0-preview-en>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
9.2. Informative References
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
Li, et al. Expires 7 January 2027 [Page 19]
Internet-Draft UBoE July 2026
Authors' Addresses
Yizhou Li
Huawei Technologies
Email: liyizhou@huawei.com
Yali Zhang
Huawei Technologies
Email: zhangyali369@huawei.com
Peng Zheng
Huawei Technologies
Email: dave.zheng@huawei.com
Li, et al. Expires 7 January 2027 [Page 20]