Layer 2 header for packet transmission in switched interconnects

Abstract

The present disclosure relates to layer 2 headers for exchanging data packet transmissions in an interconnect. An apparatus can include a network interface configured to exchange Ethernet frames with an interconnect switch, and circuitry coupled to the network interface. The circuitry can be configured to, for an Ethernet frame including a layer 2 header and a payload, modify the layer 2 header to include first information in a destination address field of the layer 2 header. The first information can be addressing information used by the interconnect switch to forward the Ethernet frame. The circuitry can be configured to transmit, via the network interface, the Ethernet frame including the modified layer 2 header to the interconnect switch.

Description

Cross-reference of related applications

[0001] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 794,854, filed April 25, 2025; U.S. Provisional Application No. 63 / 823,615, filed June 13, 2025; and U.S. Provisional Application No. 63 / 839,762, filed July 7, 2025, all of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0002] This disclosure generally relates to systems and methods for providing an Ethernet-loaded storage framework to provide low-latency, high-bandwidth connectivity for computing node network extensions over Ethernet. Background Technology

[0003] As workloads become increasingly complex in areas such as machine learning and AI (artificial intelligence) inference, the demand for parallel processing capabilities is increasing significantly. Summary of the Invention

[0004] On one hand, this disclosure relates to an apparatus comprising: a network interface configured to exchange Ethernet frames with an interconnecting switch; and a circuit system coupled to the network interface and configured to: modify the Layer 2 header of an Ethernet frame containing a Layer 2 header and a payload to include first information in the destination address field of the Layer 2 header, wherein the first information is addressing information used by the interconnecting switch to forward the Ethernet frame; and transmit the Ethernet frame containing the modified Layer 2 header to the interconnecting switch via the network interface.

[0005] On the other hand, this disclosure relates to a circuit system for exchanging Ethernet frames with an interconnecting switch, wherein the circuit system is configured to: for an Ethernet frame containing a Layer 2 header and a payload, modify the Layer 2 header to include first information in the destination address field of the Layer 2 header, wherein the first information is addressing information used by the interconnecting switch to forward the Ethernet frame; and transmit the Ethernet frame containing the modified Layer 2 header to the interconnecting switch.

[0006] On the other hand, this disclosure relates to a method for exchanging Ethernet frames with an interconnecting switch, the method comprising: for an Ethernet frame containing a Layer 2 header and a payload, modifying the Layer 2 header to include first information in the destination address field of the Layer 2 header, wherein the first information is addressing information used by the interconnecting switch to forward the Ethernet frame; and transmitting the Ethernet frame containing the modified Layer 2 header to the interconnecting switch via a network interface. Attached Figure Description

[0008] The various objects, aspects, features, and advantages of this disclosure will become more apparent and better understood through a detailed description taken in conjunction with the accompanying drawings, in which similar reference numerals identify corresponding elements throughout. In the drawings, the same reference numerals generally indicate the same, functionally similar, and / or structurally similar elements.

[0009] Figure 1A and 1B This is a block diagram of a computing device used in conjunction with the methods and systems described herein, based on some embodiments.

[0010] Figure 2 This is an instance network environment that includes an instance Ethernet Load Storage IP (ELSIP) system, according to some embodiments.

[0011] Figure 3 This is a block diagram of instance frame 300 according to some embodiments.

[0012] Figure 4A This is a diagram illustrating an example of a 2-byte format of the second header according to some embodiments.

[0013] Figure 4B This is a diagram illustrating an example of a 3-byte format of the second header according to some embodiments.

[0014] Figures 5 to 7 These are examples of Ethernet frame formats according to some embodiments.

[0015] Figure 8 These are example implementations of the AI ​​Configuration Header (AFH) format based on some embodiments.

[0016] Figure 9 This is a flowchart illustrating an example process for exchanging Ethernet frames with an interconnecting switch, according to some embodiments.

[0017] Details of various embodiments of the method and system are set forth in the accompanying drawings and the description below. Detailed Implementation

[0018] The following disclosure provides numerous different embodiments or instances for implementing various features of the provided subject matter. Specific examples of components and arrangements are described below to simplify this disclosure. These are, of course, merely examples and are not intended to be limiting. For example, in the following description, a first feature communicating with or communicatively coupled to a second feature may include embodiments in which the first feature directly communicates with or is directly coupled to the second feature, and may also include embodiments in which an additional feature may intervene between the first and second features, such that the first feature indirectly communicates with or is indirectly coupled to the second feature. Additionally, in various instances, references to numbers and / or letters may be repeated. This repetition is for simplicity and clarity and does not in itself indicate a relationship between the various embodiments and / or configurations discussed.

[0019] The following IEEE standards (including any draft versions of such standards) are hereby incorporated herein by reference in their entirety and constitute the part disclosed herein for all purposes: IEEE 802.1 and IEEE 802.3 standards, including but not limited to IEEE 802.1Q. TM IEEE 802.1AX TM IEEE 802.1CB TM IEEE 802.3ae TM IEEE 802.3ba TM IEEE 802.3bj TM IEEE 802.3by TM IEEE 802.3cd TM and IEEE 802.3ck TM Standards. Although this disclosure may reference certain aspects of these standards, it is in no way limited by them.

[0020] The following description of sections and corresponding contents of this specification may be helpful in reading the descriptions of the various embodiments described below:

[0021] a. Section A describes the network and computing environments that can be used to practice the embodiments described herein; and

[0022] b. Section B describes embodiments of systems and methods for providing extended Ethernet frameworks.

[0023] A. Computing and Network Environment

[0024] Before discussing specific embodiments of the solutions of the present invention, it may be helpful to describe aspects of the operating environment and associated system components (e.g., hardware elements) in conjunction with the methods and systems described herein. Figure 1A and 1BA block diagram depicting a computing device 100 for practicing embodiments of the techniques disclosed herein. Figure 1A and 1B As shown, each computing device 100 includes a processor 121 (e.g., a central processing unit) and a main memory unit 122. Figure 1A As shown, the computing device 100 may include a storage device 128, a mounting device 116, a network interface 118, an I / O controller 123, display devices 124a to 124n, a keyboard 126, and a pointing device 127, such as a mouse. The storage device 128 may include an operating system and / or software. Figure 1B As shown, each computing device 100 may also include additional optional components such as memory port 103, bridge 170, one or more input / output devices 130a to 130n, and cache memory 140 that communicates with the central processing unit or processor 121.

[0025] The central processing unit or processor 121 is any logic circuit system that responds to and processes instructions fetched from main memory unit 122. In many embodiments, the central processing unit or processor 121 is provided by a microprocessor unit, such as a microprocessor unit manufactured by Intel Corporation of Santa Clara, California; a microprocessor unit manufactured by International Business Machines of White Plains, New York; or a microprocessor unit manufactured by Advanced Micro Devices of Sunnyvale, California. The computing device 100 may be based on any of these processors, or any other processor capable of operating as described herein.

[0026] Main memory unit 122 may be one or more memory chips capable of storing data and allowing direct access to any storage location by a microprocessor or processor 121, such as any type or variant of static random access memory (SRAM), dynamic random access memory (DRAM), ferroelectric RAM (FRAM), NAND flash memory, NOR flash memory, and solid-state drive (SSD). Main memory unit 122 may be based on any of the memory chips described above, or any other available memory chip capable of operating as described herein. Figure 1A In the embodiment shown, the processor 121 communicates with the main memory unit 122 via the system bus 150 (described in more detail below). Figure 1BAn embodiment of computing device 100 is depicted, wherein the processor communicates directly with main memory unit 122 via memory port 103. For example, in Figure 1B In this context, the main memory unit 122 can be DRDRAM.

[0027] Figure 1B An embodiment is depicted in which the main processor 121 communicates directly with the cache memory 140 via an auxiliary bus (sometimes referred to as a back-side bus). In other embodiments, the main processor 121 uses a system bus 150 to communicate with the cache memory 140. The cache memory 140 typically has a faster response time than the main memory unit 122 and is provided by, for example, SRAM, BSRAM, or EDRAM. Figure 1B In the embodiments shown, processor 121 communicates with various I / O devices 130 via local system bus 150. Various buses can be used to connect the central processing unit or processor 121 to any of the I / O devices 130, such as VESA VL bus, ISA bus, EISA bus, Micro Channel Architecture (MCA) bus, PCI bus, PCI-X bus, PCI Fast Bus, or NuBus. In embodiments where the I / O device is a video display 124, processor 121 can communicate with the display 124 using an Advanced Graphics Port (AGP). Figure 1B An embodiment of a computer or computer system 100 is depicted, wherein the main processor 121 may communicate directly with the I / O device 130b, for example, via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communication technologies. Figure 1B An embodiment in which local bus and direct communication are mixed is also depicted: processor 121 communicates with I / O device 130a using local interconnect bus, while communicating directly with I / O device 130b.

[0028] Various I / O devices 130a to 130n may be present in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, dials, touchpads, touchscreens, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and dye-to-sublimation printers. The I / O devices can be controlled by the I / O controller 123, such as... Figure 1AAs shown in the figure. The I / O controller can control one or more I / O devices, such as keyboard 126 and pointing device 127, such as mouse or optical pen. In addition, the I / O devices can also provide storage and / or mounting media for computing device 100. In other embodiments, computing device 100 can provide USB connectivity (not shown) to receive handheld USB storage devices, such as the USB flash drive series devices manufactured by Twintech Industry, Inc. of Los Alamitos, California.

[0029] Refer again Figure 1A The computing device 100 may support any suitable installation device 116, such as a disk drive, CD-ROM drive, CD-R / RW drive, DVD-ROM drive, flash drive, tape drive of various formats, USB device, hard disk drive, network interface, or any other device suitable for installing software and programs. The computing device 100 may further include storage devices for storing the operating system and other related software, and for storing application software programs (e.g., any program or software 120 for implementing (e.g., configured and / or designed for) the systems and methods described herein), such as one or more hard disk drives or redundant arrays of independent disks. Optionally, any of the installation devices 116 may also be used as storage devices. Furthermore, the operating system and software can be run from bootable media.

[0030] Furthermore, computing device 100 may include a network interface 118 for interfacing with a network via a high-speed wired connection, including but not limited to copper or fiber-based Ethernet links compliant with IEEE 802.3 (e.g., 10GbE, 25GbE, 100GbE, 400GbE) and relevant IEEE 802.1 standards for bridging and traffic management. Various communication protocols (e.g., TCP / IP, Ethernet, SONET, SDH, or Fiber Distributed Data Interface (FDDI)) can be used to establish the connection. In one embodiment, computing device 100 communicates with other computing devices 100 via any type and / or form of gateway or tunneling protocol, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Network interface 118 may include a built-in network adapter, network interface card, or any other means suitable for interfacing computing device 100 with a wired Ethernet network capable of performing the operations described herein.

[0031] In some embodiments, computing device 100 may include or be connected to one or more display devices 124a to 124n. Therefore, any of the I / O devices 130a to 130n and / or I / O controller 123 may include any type and / or form of suitable hardware, software, or a combination of hardware and software to support, enable, or provide computing device 100 with connectivity to and use of display devices 124a to 124n. For example, computing device 100 may include any type and / or form of video adapter, video card, driver, and / or library to interface with, communicate with, connect to, or otherwise use display devices 124a to 124n. In one embodiment, a video adapter may include multiple connectors to interface with display devices 124a to 124n. In other embodiments, computing device 100 may include multiple video adapters, each connected to display devices 124a to 124n. In some embodiments, any portion of the operating system of computing device 100 may be configured to use multiple display devices 124a to 124n. In other embodiments, I / O device 130 may be a bridge between system bus 150 and external communication buses (such as USB bus, Apple Desktop bus, RS-232 serial connection, SCSI bus, FireWire bus, FireWire 800 bus, Ethernet bus, AppleTalk bus, Gigabit Ethernet bus, Asynchronous Transfer Mode bus, Fibre Channel bus, Fibre Channel bus, Serial Attached Small Computer System Interface bus, USB connection, or HDMI bus).

[0032] Figure 1A and 1BThe computing device 100 of the type described herein can operate under the control of an operating system that controls task scheduling and access to system resources. The computing device 100 can run any operating system, such as any version of Microsoft Windows, different versions of Unix and Linux, any version of MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open-source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein. Typical operating systems include, but are not limited to: Android, produced by Google Inc.; Windows 7, 8, and 10, produced by Microsoft Corporation of Redmond, Washington; macOS, produced by Apple Computer of Cupertino, California; WebOS, produced by Research In Motion (RIM); OS / 2, produced by International Business Machines of Armonk, New York; and Linux, a free operating system distributed by Caldera Corp. of Salt Lake City, Utah, or any type and / or form of Unix operating system, etc.

[0033] The computer system or computing device 100 may be any workstation, desktop computer, rack server, high-performance computing node, or other type and / or form of computing device capable of communicating via a wired Ethernet network. In some embodiments, the computing device 100 may have different processors, operating systems, and input / output configurations consistent with its role in a high-performance computing environment. For example, in one embodiment, the computing device 100 is a GPU / XPU-based accelerator node, an AI or machine learning server, or a data center computing device designed to operate within a cluster connected by Ethernet. Furthermore, the computing device 100 may be any form of computing system with sufficient processor power, memory capacity, and network interface capabilities to perform the operations described herein.

[0034] The aspects of the operating environment and components described above will become apparent in the context of the systems and methods disclosed herein.

[0035] B. Systems and methods for providing extended Ethernet frameworks

[0036] As workloads in fields such as machine learning (ML), artificial intelligence (AI) inference, and data analytics grow in complexity and scale, the demand for parallel processing continues to rise. To meet this demand, GPUs (or more generally XPUs, which include various custom ML accelerators) are increasingly being expanded into rack-scale and multi-rack deployments. These systems rely on efficient interconnect architectures to move large amounts of memory traffic with minimal latency and overhead. Ethernet offers compelling advantages for such architectures, including high-speed links, high-performance switches, a mature ecosystem, and operational familiarity. Consequently, several industry initiatives are exploring Ethernet-based designs for AI-centric networks that extend or reuse components of the Ethernet infrastructure.

[0037] While Ethernet provides a robust physical and link layer foundation, its standard protocol stack introduces inefficiencies that hinder the performance of latency-sensitive, high-throughput AI interconnects. Specifically, the use of both L2 (MAC) and L3 (IP) headers introduces redundant information and protocol overhead that can exceed the payload size of many memory transactions. For example, small packets carrying 64 to 128 bytes of memory data can incur 34+ bytes of header overhead when including Ethernet, IP, and UDP headers. This severely limits the efficiency and link utilization of AI workloads characterized by high-rate, fine-grained memory operations. Furthermore, the L2 / L3 header structure lacks built-in support for forwarding features crucial to AI architecture, such as adaptive routing, congestion notification, and flow labeling.

[0038] To address these limitations, this disclosure provides techniques for a compact and flexible AI Architecture Header (AFH). In some embodiments, the AFH overlays the L2 MAC header to eliminate IP redundancy while retaining features such as destination / source addressing, time-to-live (TTL), traffic class (e.g., DSCP), and explicit congestion notification (ECN). In some embodiments, optional extended fields in the AFH support additional functionality, such as adaptive routing eligibility and congestion signaling via congestion notification messages (CNM). The AFH can reduce header overhead to only 14 to 18 bytes based on configuration, significantly improving efficiency for small packets. The AFH also allows system designers complete flexibility in address formatting and interpretation, and enables switches to parse only the header fields required for forwarding decisions, for example. This allows Ethernet architectures to emulate the behavior and performance of proprietary HPC interconnects while remaining standards- and vendor-neutral.

[0039] In some embodiments, the apparatus may include a circuitry configured to generate Ethernet frames containing AFH (Awareness of Components) instead of a MAC+IP+UDP stack. The circuitry may populate the Destination Address (DA) field of the L2 header with configuration-level addressing information, while optional fields in the AFH extension may indicate per-packet routing behavior, such as whether a packet is eligible for adaptive routing or congestion notification. For example, the circuitry may set bits in the header to indicate that a packet is a congestion control message, or set a DSCP field to classify packets for Quality of Service (QoS) handling at the switch. The AFH extension may also include flow tags to support intra-configuration routing. Network interfaces (e.g., port macros) may transmit frames to interconnecting switches (e.g., configuration switches), which parse the relevant fields of the AFH and forward the frames accordingly. In this way, the techniques disclosed herein use overhead-reduced configuration-aware headers tailored for AI and ML workloads to achieve efficient memory transaction transfers across single- or multi-layer Ethernet configurations.

[0040] In view of the above, the following figures and description illustrate various examples of Layer 2 header technology used for packet transmission in switching. The following figures and description are non-limiting examples and can be implemented in any of a variety of other configurations while still remaining within the scope of this disclosure. Other embodiments may be used alternatively or in place. Details that are obvious to those skilled in the art may be omitted. Some embodiments may be practiced with additional components or steps and / or without using all the components or steps described.

[0041] Figure 2 This is an example network environment 200 including an example Ethernet Load Memory IP (ELSIP) system 210 according to some embodiments. The ELSIP system 210 may be a 400G Extended Network Interface Controller (NIC) that enables the transmission of memory read and write transactions between multiple endpoints (e.g., up to 128) via a high-throughput Ethernet interface. In the illustrated example, the ELSIP system 210 includes an 8×100G port macro 212 and two Ethernet Load Memory IP examples (ELSIP0 214 and ELSIP12 16). The ELSIP system 210 is communicatively coupled to a CPU 230 and a System-on-Chip (SoC) 220 via an AXI-based master / slave interface.

[0042] Port macro 212 provides physical and media access control (MAC) layers for multiple high-speed Ethernet ports (e.g., Ethernet port 0 and Ethernet port 1) and supports the standard MAC / PCS interface. Each ELSIP 214, 216 implements transport logic for converting memory transaction packets into transport packets, which may contain zero or more memory commands and are protected by end-to-end integrity checks. The transport layer ensures that memory transactions are delivered in an ordered manner along AXI channels between the source and destination endpoints.

[0043] In some implementations, the ELSIP system 210 supports both standard and optimized packet delivery header formats. This allows the system to reduce protocol overhead when operating in optimized mode, while still enabling interoperability using the standard format if needed. The delivery header is interpreted by an intermediary switch to route packets to their destination across the architecture.

[0044] Each ELSIP example further supports multiple virtual channels (VCs) implemented via separate lossless flow control classes. These VCs provide deadlock avoidance and allow performance isolation. The ELSIP system 210 supports link-level flow control mechanisms such as priority flow control (PFC) and credit-based Uniform Ethernet Congestion Control (UEC) per VC.

[0045] The ELSIP system 210 can optionally implement link-level replay (LLR), which replays data packets at the link layer in the event of a transmission failure. This reduces the burden on ELSIP transport logic to handle retransmissions, thereby improving efficiency and reducing latency in many failure scenarios.

[0046] CPU 230 can be used to configure and manage ELSIP examples, including flow control parameters, header formatting, and monitoring. The interface with SoC 220 can be implemented as an AXI data plane (DP) master / slave interface, enabling memory transactions to be sent from or written to the memory system or other AXI connectivity components.

[0047] In some embodiments, the ELSIP system 210 may include one or more integrated circuit blocks (e.g., ELSIP0 214 and ELSIP1 216) that implement transmission logic for transmitting and receiving Ethernet frames according to the techniques described herein. Each ELSIP 214, 216 may include circuitry configured to format memory transactions into payloads, attach transmission-related headers (e.g., containing flow control or congestion notification metadata), and construct Ethernet frames for transmission. ELSIPs 214, 216 may be coupled to an 8×100G port macro 212, which operates as a high-throughput network interface configured to exchange Ethernet frames with external interconnect switches (e.g., component switches in an extended AI cluster). For example, port macro 212 may transmit and receive frames conforming to the Extended Ethernet (SUE) format, including a modified Layer 2 header and one or more optional extended headers used by the interconnect switches to route and manage traffic.

[0048] Each ELSIP 214, 216 may include logic to process or generate portions of an Ethernet frame in a manner that supports adaptive routing and congestion-aware behavior. For example, the circuitry may be configured to insert a second header into the frame, the second header containing one or more fields, such as an Adaptive Routing Qualification (AR) field, a hop number field, and / or an Explicit Congestion Notification (ECN) field. In some embodiments, the second header may further include a Differentiated Service Code Point (DSCP) field indicating the traffic class and control bits indicating whether the packet is eligible for congestion and path failure notification or whether it is itself a notification. The values ​​of these fields may be set by the ELSIP logic to guide switching behavior, for example, to signal congestion response eligibility or to differentiate routing intent from standard IP semantics. Additionally, one or more ELSIP blocks may be appended with flow tag metadata, which the switch may use to dynamically select routes. Once constructed, the Ethernet frame containing the modified Layer 2 header and any second header is transmitted to the building switch via port macro 212.

[0049] Figure 3 This is a block diagram of example frame 300 according to some embodiments. As used herein, "frame" can refer to a data frame, control frame, management frame, or any signal, data packet, segment, or formatted transmission unit that can be generated, processed, transmitted, and / or received to facilitate communication between devices via a wired medium (e.g., a wired Ethernet network). In some embodiments, frame 300 may be an Ethernet frame. The term "Ethernet frame" can refer to a data packet formatted according to the standard IEEE 802.3 Ethernet framing or a modified Ethernet frame suitable for high-performance interconnects. In some embodiments, an Ethernet frame may include a custom header (e.g., AFH) and a payload containing memory transactions or control information.

[0050] Frame 300 may contain the following "fields": Layer 2 Header L2 / IP 302, Routing Transport Header (RTH) 304, Packet Transaction 306, Payload Error Detection Field (ECRC) 308, Alignment Padding (PAD) 310, and Ethernet Frame Check Sequence (FCS) 312. As used herein, "field" may refer to a portion of a frame that occupies a defined bit range and carries control information, addressing information, payload data, or error detection information for processing, forwarding, or acknowledging the frame.

[0051] L2 / IP 302 may contain destination and source addressing information and may represent a standard Ethernet header, IP header, or a compressed combination thereof. RTH 304 may contain routing-related information used by interconnect switches to perform forwarding, congestion handling, or adaptive routing decisions within the architecture. Packet Transaction 306 field may contain one or more memory transactions encapsulated within the frame payload, such as memory read or write operations. ECRC 308 may contain an end-to-end integrity check value calculated based on the packet transaction for payload corruption detection. PAD 310 may contain unused bits or bytes added to meet alignment, size, or transmission requirements. FCS 312 may contain a cyclic redundancy check value for detecting transmission errors across Ethernet frames. In some embodiments, frame 300 may be transmitted to the architecture switch via an Ethernet port (e.g., via port macro 212), where the included header (e.g., L2 / IP 302) is parsed to facilitate forwarding, congestion handling, and adaptive routing across the interconnect.

[0052] Frame 300 may be implemented by an apparatus. As used herein, "apparatus" may be a network interface controller (e.g., ELSIP system 210), an XPU (e.g., a GPU or AI accelerator), or any system, circuit system, or integrated logic that transmits memory transactions via an Ethernet-based interconnect architecture. An apparatus may include a circuit system. As used herein, "circuit system" may refer to a hardwired circuit system, a programmable circuit system, state machine logic, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), digital logic, a microcontroller, a processor core, a network interface controller (NIC), or any combination thereof. In some embodiments, the circuit system may be implemented as part of an apparatus for transmitting Ethernet frames formatted according to AFH. The circuit system may be configured to generate and insert header fields, modify layer 2 address fields, set congestion notification indicators, calculate checksums or error detection codes, and / or transmit formatted frames to an architecture switch or interconnect device via an Ethernet link. The circuit system may be distributed across one or more blocks, including, but not limited to, ELSIP blocks (e.g., ELSIP0 214 or ELSIP1 216), control processors, or port macros (e.g., port macro 212).

[0053] In some embodiments, the apparatus includes a network interface configured to exchange Ethernet frames (e.g., frame 300) with interconnecting switches. As used herein, the term "network interface" may refer to a physical layer and / or link layer interface circuitry that supports Ethernet communication, including but not limited to port macros (e.g., Figure 2 The 8×100G port macro 212). The network interface is operatively coupled to one or more ELSIP blocks (e.g., ELSIP0 214, ELSIP1 216) to exchange frame sequences with an interconnect switch (e.g., a building block switch within a GPU or XPU cluster), for example... Figure 3 Frame 300. As used herein, the term "interconnect switch" can refer to any device, logical, or network element that performs packet switching or forwarding operations across network architectures. This can include stand-alone architecture switches, top-of-rack (ToR) switches, or integrated switch blocks. Interconnect switches can operate based on Layer 2 (e.g., MAC address), Layer 3 (e.g., IP), or custom routing fields (e.g., flow tags or adaptive routing indicators). Interconnect switches can parse fields in Ethernet frames to perform routing, congestion control, and switching operations within extended Ethernet architectures.

[0054] In some embodiments, the circuitry is configured to modify the Layer 2 header of an Ethernet frame to include first information in the DA field of the Layer 2 header. As used herein, the term "Layer 2 header" may refer to any data structure or field included at the beginning of an Ethernet frame that provides addressing and control information for data link layer communication. The Layer 2 header may include one or more address fields (e.g., destination and source MAC addresses), a type / length field, or other control bits. In some embodiments, the Layer 2 header may correspond to an Ethernet header or a custom format suitable for high-performance switching architectures, such as AFH. For example, the L2 / IP 302 of frame 300 may be a Layer 2 header and may contain a destination address field used by interconnecting switches to determine how to forward the Ethernet frame within the architecture.

[0055] The "Destination Address (DA)" field can refer to any portion of a Layer 2 header (e.g., L2 / IP 302) that encodes address information identifying the target destination within the switching architecture or interconnect network. In some embodiments, this may correspond to a 48-bit MAC address. In some other embodiments, the destination address field can be extended, adapted, or reloaded to carry addressing information specific to high-speed AI interconnect switches. For example, the DA field can encode a logical routing identifier, endpoint index, or path tag used by the interconnect switch to forward frames to their intended recipient. In these instances, the circuitry can access local configuration registers, receive flow control signals, and / or parse upper-layer headers to determine the appropriate value to insert into the destination address field. This enables the interconnect switch to perform fast lookups and forwarding based on the inserted addressing information.

[0056] As discussed above, the circuit system can be configured to modify the Layer 2 header to include first information in the DA field of the Layer 2 header. This first information may include any addressing information used by the interconnect switches to forward Ethernet frames. This may include a MAC address, logical endpoint ID, configuration path identifier, or a combination thereof. In some embodiments, the addressing information may be dynamically calculated based on routing policies, flow rules, or endpoint discovery protocols. The circuit system may retrieve or calculate this first information based on the context associated with the memory transactions carried in the frame payload, and may accordingly insert or overwrite the DA field of the Layer 2 header. This dynamic rewriting of the Layer 2 destination address field allows each Ethernet frame to be correctly routed through the interconnect configuration based on its transaction-level semantics or routing metadata.

[0057] In some embodiments, the circuitry may be configured to generate a second header as part of an Ethernet frame (e.g., frame 300), the second header containing one or more fields selected from AR, TTL, or ECN fields. As used herein, the term "second header" may refer to any set of fields or bit sequence appended to or embedded within an Ethernet frame (e.g., frame 300) to enable extended routing, transport, or congestion control functions. The second header may be, for example, the Routing Transport Header (RTH) 304 of frame 300 or may be implemented within the Routing Transport Header (RTH) 304.

[0058] The AR field in the second header (e.g., RTH 304) may contain one or more bits that indicate to the interconnecting switches whether to apply an adaptive routing policy to the associated Ethernet frame. In these instances, adaptive routing can refer to the process by which a switch selects a path for a frame based on current network conditions, such as link utilization, congestion, or failure. The AR field can be used by interconnecting switches to make dynamic forwarding decisions to optimize bandwidth usage, reduce latency, or avoid congested links.

[0059] The TTL field in the second header (e.g., RTH 304) can contain an integer value representing the hop count limit for an Ethernet frame (e.g., Frame 300). Each switch or routing device along the path can decrement the TTL value by 1, and if the value reaches 0, the frame can be discarded. This mechanism prevents outdated frames from cycling or propagating excessively within the architecture.

[0060] The ECN field in the second header (e.g., RTH 304) may contain one or more bits indicating whether the source and / or destination device has ECN capability and whether the frame (e.g., frame 300) experienced congestion along its path. The ECN field can be used to signal congestion to endpoints without dropping frames, enabling proactive congestion control responses such as rate throttling or flow redirection. The ECN field can be interpreted by interconnecting switches to adaptively manage network traffic.

[0061] In some embodiments, the second header (e.g., RTH 304) further includes a first field indicating whether the Ethernet frame (e.g., frame 300) is eligible for congestion notification, a DSCP field indicating the traffic class of the Ethernet frame, and a CNM field indicating to the interconnecting switch whether the Ethernet frame (e.g., frame 300) is a CNM. As used herein, "first field" may refer to one or more bits or flags indicating whether the Ethernet frame (e.g., frame 300) is eligible to participate in the congestion notification mechanism within the architecture. This eligibility indication may be parsed by the interconnecting switch to determine whether a congestion-related tag or message can be generated in response to a detected congestion condition.

[0062] The DSCP field can refer to a field containing one or more bits that encodes the priority, service level, or quality of service specification of an Ethernet frame. The DSCP field can also refer to a traffic class, where, as used herein, the term "traffic class" can refer to a traffic classification used by interconnecting switches to apply differential processing, such as queue selection, scheduling priority, bandwidth allocation, or lossless versus lossy processing. In some embodiments, the DSCP field may be included in a second header (e.g., Figure 3 Within the RTH304 header, and can be interpreted by the interconnecting switch independently of other header fields.

[0063] The CNM field can refer to one or more bits that indicate whether the Ethernet frame itself is CNM. When the CNM field indicates that the Ethernet frame is CNM, the interconnecting switches can process, forward, or prioritize the frame according to the congestion notification handling rules defined for the architecture, rather than treating the frame as a regular data bearer frame.

[0064] In some embodiments, the circuit system may be configured to set values ​​for a first field, a DSCP field, and a CNM field indicating congestion notification eligibility to indicate to the interconnecting switch whether to send CNM to the sender or the destination. As used herein, the term “sender” may refer to a device, endpoint, or source node capable of transmitting an Ethernet frame (e.g., frame 300). The term “destination” may refer to a device, endpoint, or target node identified by addressing information in the frame (e.g., frame 300), for example, via the destination address field in the Layer 2 header.

[0065] In some implementations, the circuit system can determine whether congestion feedback should be directed back to the sender or forwarded to the destination based on local policies, congestion states, routing conditions, or header values ​​associated with the Ethernet frame. The circuit system can then encode this indication by setting corresponding values ​​in the First Field, DSCP Field, and CNM Field. For example, setting a specific value in the CNM Field can indicate that the Ethernet frame itself is CNM, while the combination of the First Field and DSCP Field can further indicate the priority, handling class, or routing process associated with delivering the congestion notification.

[0066] Interconnect switches can parse the first field, the DSCP field, and the CNM field to determine whether to generate, forward, or relay a CNM and whether the notification should be delivered to the sender or the destination. In this way, circuit systems can explicitly control congestion notification behavior at the Ethernet frame level, allowing congestion feedback to selectively target appropriate endpoints within the extended Ethernet architecture.

[0067] In some embodiments, the DSCP field included in the second header (e.g., RTH 304) is defined and interpreted differently from the DSCP field in the Internet Protocol header (e.g., processed by an interconnecting switch). As used herein, the term "Internet Protocol header" may refer to any portion of a network layer packet structure that conforms to a standardized or proprietary Internet protocol format (e.g., IPv4, IPv6) and contains addressing and control information (e.g., source and destination IP addresses, version field, header length, type of service, total length, identifier, fragmentation flag, TTL, protocol type, header checksum, and / or options). The Internet Protocol header may be associated with an encapsulated transport layer payload (e.g., TCP, UDP) and can be used to route packets across interconnecting networks based on logical addressing. In some embodiments, the Internet Protocol header may be omitted, compressed, replaced, or bypassed to support alternative transport schemes (e.g., custom layer 2 encapsulation, such as AFH).

[0068] In some embodiments, the circuitry system may generate and populate a DSCP field in a second header (e.g., RTH 304) independently of any DSCP field that may be present in the IP header or independently of the presence of the IP header. Interconnect switches may be configured to recognize that the DSCP field carried in the second header belongs to a namespace separate from the IP-based DSCP field, and to apply traffic classification, queue selection, or congestion management decisions based on the second header DSCP field rather than the IP-layer DSCP value.

[0069] By treating the DSCP field in the second header differently from the DSCP field area in the Internet Protocol header, interconnect switches can support configuration-specific traffic classes and policies, independent of Layer 3 semantics. This allows Ethernet frames (e.g., Frame 300) to carry traffic class information optimized for extended Ethernet configurations, memory transaction traffic, or AI / XPU workloads, while avoiding ambiguity or conflict with DSCP values ​​that can otherwise be associated with IP-based network protocols.

[0070] In some embodiments, the second header (e.g., RTH 304) includes a second field indicating the presence of a flow tag field in an Ethernet frame (e.g., frame 300). As used herein, the term "flow tag field" may refer to a set of bits within a header (e.g., within RTH 304) that identifies a specific flow or traffic class for routing and traffic engineering purposes across interconnect architectures. The second field may be a flag bit, presence indicator, or control field used by interconnect switches to determine whether to parse the flow tag field and use it for routing decisions.

[0071] The flow tag field may contain a set of values, which may be one or more bits indicating logical flow, routing hints, priority paths, or other forwarding classifications. As used herein, the term "set of values" may refer to any code point, numerical value, tag, or coded identifier that selects or influences routing through interconnect switches. As used herein, the term "routing" may refer to a selected forwarding path or sequence of egress ports within a switching architecture used to deliver packets from source to destination. Interconnect switches may use the values ​​set in the flow tag field to perform path selection, load balancing, or latency-aware routing based on dynamic topology or congestion conditions.

[0072] In some implementations, the flow tag field may be implemented as part of RTH 304 of frame 300. For example, RTH 304 may include one or more subfields dedicated to routing control, including the aforementioned flow tag field and the second field. The circuit system may be configured to generate the second field and the flow tag field and insert them into the second header (e.g., RTH 304) of the Ethernet frame (e.g., frame 300) before transmission to the interconnecting switch.

[0073] In some embodiments, the circuitry is configured to add a flow tag field to a second header (e.g., RTH 304) and set the second field to a value indicating the presence of the flow tag field. The flow tag field may contain a set of values ​​to indicate a specific route or routing behavior to the interconnecting switches. The flow tag field may be implemented as a routing transport header (e.g., Figure 3 The value set may contain fields or subfields within RTH 304, and may contain values ​​that enable per-flow or per-class routing decisions based on topology, congestion status, or traffic engineering policies. The value set may contain labels, indices, or path hints used by interconnecting switches to select among multiple available routes. A second field, which may be included elsewhere in RTH 304 or in the second header, serves as an indicator to the interconnecting switches that the flow tag field exists and should be resolved during forwarding.

[0074] In some embodiments, the circuitry is configured to transmit Ethernet frames (e.g., frame 300) containing a modified Layer 2 header to an interconnecting switch via a network interface. As described above, the Ethernet frame (e.g., frame 300) may contain a Layer 2 header (e.g., L2 / IP 302), a second header (e.g., RTH 304), and a payload (e.g., packetized transaction 306). The modified Layer 2 header may contain a DA field updated with addressing information used by the interconnecting switch to forward frames across architectures.

[0075] The network interface may include one or more Ethernet ports, Physical Writer Sublayer (PCS) logic, Media Access Control (MAC) logic, or serializer / deserializer (SerDes) circuitry. It can support full-duplex or half-duplex transmission and is compatible with various link speeds (e.g., 10G, 25G, 100G) and standards (e.g., IEEE 802.3, custom Ethernet variants). The network interface can be implemented within or alongside an ELSIP (e.g., ELSIP0 214 or ELSIP1 216) and can be directly coupled to a port macro, such as... Figure 2 The port macro is 212.

[0076] Interconnect switches can be standalone or integrated switching architectures that route Ethernet frames (e.g., Frame 300) between various endpoints (e.g., XPUs, memory devices, or other accelerators) within an extended or distributed system. When an Ethernet frame is transmitted, the interconnect switch can parse the header, particularly the modified Layer 2 header, and perform actions such as forwarding, congestion response, or adaptive routing based on embedded information.

[0077] In this way, the circuit system ensures that formatted Ethernet frames (containing custom or modified Layer 2 headers) are delivered to interconnect switches to enable intelligent architecture-level forwarding and system-level scalability.

[0078] In some embodiments, Ethernet frame 300 may include a fixed- or variable-length header structure containing a set of defined fields. For example, Table 1 below illustrates a set of instance fields that may exist in a second header (e.g., RTH 304), along with their corresponding bit widths, functional descriptions, and whether the fields can be modified by a switch or intermediate network element.

[0079] Table 1

[0080]

[0081]

[0082] These fields may include, but are not limited to:

[0083] 1) AR (Adaptive Routing Eligibility): A 1-bit field that indicates whether a frame is eligible for adaptive routing. A value of 0 indicates that deterministic routing is used, maintaining in-order delivery, while a value of 1 allows for adaptive routing of frames at each hop, potentially improving congestion avoidance at the cost of packet reordering.

[0084] 2) F (Flow Mark Present): A 1-bit field indicating whether the second header contains a flow mark. When set to 0, the header can span 2 bytes, and entropy calculation can only use source and destination addresses. When set to 1, the header expands to 3 bytes, and entropy-based routing can be incorporated into the flow mark.

[0085] 3) C (Congestion Eligibility): A 1-bit field that specifies whether a frame is eligible to generate CNM. A value of 1 marks the frame as eligible to have its congestion monitored.

[0086] 4) CNM (Congestion Notification Message): A 1-bit field that indicates whether the frame itself is a CNM (e.g., 1) or an original data frame (e.g., 0). CNM frames can be generated by a switch in response to observed congestion or a lack of a path to the destination, and can be directed to the original sender.

[0087] 5) ECN (Explicit Congestion Notification): A 2-bit field used to convey congestion-related flags, conforming to ECN conventions. For example, a value of 10 or 01 indicates a transmission that supports ECN (ECT), and a value of 11 indicates that congestion has been encountered (CE).

[0088] 6) DSCP (Differentiated Service Code Point): A 6-bit field that encodes the traffic class or virtual channel associated with the frame. DSCP encoding may be AI-specific and does not need to match IP-based DSCP encoding.

[0089] 7) TTL (Time to Live): A 4-bit field that is decremented by each switch the frame traverses. When the TTL reaches 0, the frame can be discarded or transferred to the control plane for processing.

[0090] Each field can be parsed or modified by one or more switches along the configuration path, depending on whether the field is designated as switch-modifiable. In some implementations, certain fields (e.g., CNM, ECN, DSCP, and TTL) can be dynamically updated at runtime, while others (e.g., AR or F) can remain static throughout the frame traversal.

[0091] Instance structure and field locations are in Figure 4A and Figure 4B The format is shown in the image. Specifically, when no stream marker is present, a 2-byte format can be used. Figure 4A ), and when stream tags are included, a 3-byte format can be used ( Figure 4B ).

[0092] Figure 4A This is a diagram illustrating an example 2-byte format of the second header 401 according to some embodiments. In some embodiments, the second header 401 may be or be included in Figure 3 In RTH 304. The second header 401 can be generated by, for example, a circuit system within a high-performance interconnect architecture configured to insert routing and congestion-related metadata into Ethernet frames. Figure 4A The format described corresponds to the case where the "stream marker" field is not present (for example, where field "F" is set to 0).

[0093] Figure 4A The first line indicates the bit positions from 0 to 31. The second line maps the named fields to specific bit positions. As shown, the second header 401 contains a 1-bit AR field at bit position 0, a 1-bit Stream Mark Presence (F) field set to 0 at bit position 1, a 1-bit Congestion Eligibility (C) field at bit position 2, and a 1-bit CNM field at bit position 3. The 4-bit TTL field occupies bits 4 to 7 and indicates the remaining lifetime of the packet as it traverses the interconnection network. The 6-bit DSCP field occupies bits 8 to 13 and encodes the traffic class. The 2-bit ECN field is located at bits 14 and 15 and encodes ECN-related statuses, such as encountered congestion or ECN-enabled transmissions.

[0094] Figure 4A The second header 401 shown in the image spans two bytes (16 bits) and can be located in the layer 2 header (e.g., ...). Figure 3 This occurs after L2 / IP 302 and before the payload (e.g., packetized transaction 306). Interconnect switches can resolve this. Figure 4A One or more of the fields shown in the diagram are used to perform adaptive routing, enforce time-to-live policies, generate or respond to congestion events, and / or perform class-based queuing or forwarding operations. In some embodiments, Figure 4A The second header 401 shown can be implemented within a custom header area, such as AFH. The remaining bits (16 to 31) can be reserved, left unused, or used for other optional extensions.

[0095] Figure 4B This is a diagram illustrating an example 3-byte format of the second header 402 according to some embodiments. The second header 402 may be or be included in RTH 304. Figure 4B The format described corresponds to the case where a "stream marker" field exists (i.e., where field "F" is set to 1), and therefore includes an extended field layout (e.g., with...). Figure 4A (Compared). As shown, Figure 4BThe second header 402 contains an additional 8-bit stream marker field spanning bits 16 to 23. The remaining bits (24 to 31) may be reserved, left unused, or used for other optional extensions.

[0096] Including the flow label field allows for enhanced routing capabilities. Specifically, the flow label field carries predetermined values ​​used by interconnecting switches to perform entropy-based or deterministic routing decisions across architectures. The presence of this field is indicated by setting the F field to 1. When present, the entropy calculation used for forwarding frames incorporates not only the source and destination addresses but also the flow label.

[0097] In some embodiments, Figure 4B The second header described in the text can also be positioned at... Figure 3 The image shows the layer 2 header (e.g., L2 / IP 302) and payload (e.g., packetized transaction 306) of Ethernet frame 300. This second header 402 can form part of AFH, which enables fine-grained control over routing behavior, congestion response, and traffic classification in AI / GPU extended networks.

[0098] Figure 5 This is an example of an Ethernet frame format 500 according to some embodiments. This format 500 includes a 2-byte flexible header to support Ethernet transmissions at AI scale. As shown, format 500 can be organized into seven 32-bit words representing portions of an Ethernet frame. The first and second 32-bit words define DA and source address (SA) fields, each spanning 32 bits. DA occupies all 32 bits of the first word and the 16 high-order bits (bit positions 0 to 15) of the second word. SA spans the 16 low-order bits (bit positions 16 to 31) of the second word and the entire third word (bit positions 0 to 31). These address fields correspond to a Layer 2 header (e.g., ...). Figure 3 In L2 / IP 302), and implements standard or modified MAC-level forwarding by interconnecting switches.

[0099] In the fourth 32-bit word, the EtherType field, indicating the presence of a flexible header, is encoded in bits 0 through 15. The remaining bits of this word define a compact 2-byte flexible header for in-network processing. Specifically, bit 16 stores the AR flag; bit 17 stores the F flag, which is set to 0 to indicate the absence of the Flow Marker field (e.g., in a 2-byte flexible header format); bit 18 stores the C flag indicating CNM eligibility; and bit 19 stores the CNM flag, which can be asserted by the switch to indicate that the frame is CNM. Bits 20 through 23 contain the TTL field for hop count limit control; bits 24 through 29 contain the DSCP field indicating the traffic class; and bits 30 through 31 encode the ECN field. These fields collectively correspond to the second header mentioned above (e.g., ...). Figure 3 RTH 304 in, and with, for example Figure 4AThe layout alignment shown in the image (where F=0) is as follows. The fifth and sixth characters contain the payload and CRC, respectively, thus completing an optimized frame structure suitable for deployment in an AI-based switching environment.

[0100] Figure 6 This is an example of an Ethernet frame format 600 according to some embodiments. This format 600 contains a 3-byte flexible header to support Ethernet transmissions at AI scale. DA spans the first word (bits 0 to 31) and the lower half of the second word (bits 0 to 15), while SA occupies the upper half of the second word (bits 16 to 31) and the entire third word (bits 0 to 31). These MAC address fields correspond to a Layer 2 header (e.g., ...). Figure 3 It supports L2 / IP 302 and address-based forwarding by interconnecting switches.

[0101] The fourth character contains VLAN-specific fields. Bits 0 to 15 encode the Tag Protocol Identifier (TPID), which is set to 0x8100 to indicate the presence of an IEEE 802.1Q VLAN tag. Bits 16 to 18 store the External Priority Code Point (OPCP), bit 19 stores the Canonical Format Indicator (OCFI), and bits 20 to 31 encode the External VLAN Identifier (OVID). This layout ensures compatibility with VLAN-aware Ethernet infrastructure.

[0102] The fifth word begins with the EtherType field (bits 0 to 15), signaling the start of the flexible header. The remaining bits of this word (bits 16 to 31) form the 2-byte portion of the flexible header, including: the AR bit at bit 16, the F bit set to 1 at bit 17 (indicating the presence of a flow flag), the Congestion Eligibility (C) bit at bit 18, the CNM bit at bit 19, the TTL field spanning bits 20 to 23, the DSCP field spanning bits 24 to 29, and the ECN field in bits 30 to 31. This layout is consistent with... Figure 4B Consistent, Figure 4B Define a 3-byte flexible header format.

[0103] The sixth word begins with the flow tag field in bits 0 through 7, used for entropy-aware routing or deterministic path selection. The remaining bits of this word (bits 8 through 31) indicate the start of the payload. The seventh word contains a CRC field for error checking and frame acknowledgment. This optimized frame format provides VLAN compatibility while supporting programmable routing and congestion handling mechanisms within Ethernet switching architectures at AI and high-performance scales.

[0104] Figure 7This is an example of Ethernet frame format 700 according to some embodiments. Format 700 includes a VLAN tag but omits the flexible header. This frame structure contains seven 32-bit words and is very useful for deployments that support VLAN-based segmentation but do not require advanced routing or congestion control features provided by the flexible header format.

[0105] DA spans the second word (bits 0 to 31) and the lower half of the third word (bits 0 to 15), while SA occupies the upper half of the second word (bits 16 to 31) and the entire third word (bits 0 to 31). These address fields correspond to the Layer 2 header (e.g., ...). Figure 3 It includes L2 / IP302 and implements forwarding based on standard MAC addressing.

[0106] The fourth field contains the VLAN tag field. Bits 0 to 15 encode the 0x8100 TPID value to indicate an IEEE 802.1Q tag. Bits 16 to 18 contain the External Priority Code Point (OPCP), bit 19 contains the External Canonical Format Indicator (OCFI), and bits 20 to 31 store the External VLAN Identifier (OVID). These fields ensure compatibility with VLAN-aware switching infrastructure.

[0107] In the fifth word, the EtherType field occupies bits 0 through 15 and can indicate a type such as FLEX HDR. However, in this example, there is no flexible header field following EtherType. Instead, the payload starts directly from bit 16 and continues through the remaining fifth word and into subsequent words. Because the F bit (stream marker present), AR, TTL, DSCP, CNM, and other fields associated with flexible headers are absent, this format represents a simplified header structure. The sixth word encodes the CRC field.

[0108] Figure 8 This is an example embodiment of the AI ​​Configuration Header (AFH) format 800 according to some embodiments. AFH provides a spatially efficient representation that supports advanced configuration-level functions (such as congestion control and TTL-based forwarding) while reducing overall packet overhead. This enables optimized encapsulation of IPv4 packet fields within Layer 2 Ethernet-compatible frames.

[0109] like Figure 8As shown, AFH Format 800 contains multiple header portions aligned with 32-bit word boundaries. The first word contains unused bits and Destination IP (DIP) information, while the second word contains the DIP and Total Length fields. The Source IP (SIP) portion is embedded in the following words, where additional control bits and metadata fields are encoded across subsequent headers. For example, the ET=AFH_BASE field defines the EtherType that identifies Format 800 as an AFH frame. This header contains a Reserved (Res) field, a TTL field, and a TOS (Type of Service) field. Next is the next protocol (e.g., RTH), which further includes packet ordering, Virtual Channel (VC), endpoint identifier, XPU ID, PSN (Package Sequence Number), EPSN (Expected PSN), partition ID, and additional details of the operation code. The remainder of Format 800 contains the packetized transaction payload, end-to-end CRC (ECRC), optional L2 padding, and Frame Checksum (FCS).

[0110] Table 2 below illustrates how fields selected from the IPv4 header can be mapped to AFH format. Table 2 shows the original IPv4 field name, its original bit size, its corresponding size in AFH format, and its mapping position or encoding in AFH. Fields omitted in the AFH representation are indicated by 0 in the "Mapping Size" column and / or blank entries in the "Mapping" column.

[0111] Table 2

[0112]

[0113] As shown, this mapping compresses selected fields while eliminating unnecessary IPv4 components, resulting in reduced header overhead and improved forwarding efficiency. The system can use this format for AI architectures operating under L2 and bypassing IP layer processing, while still enabling per-hop TTL control via accompanying headers (e.g., CNM, ECN), DSCP-based traffic differentiation, and congestion notification. The method also allows switching architectures to perform early header resolution and address masks for DIP-based forwarding lookups.

[0114] Figure 9 This is a flowchart illustrating a process 900 for exchanging Ethernet frames (e.g., frame 300) with an interconnecting switch according to some embodiments. In some embodiments, process 900 is performed by one or more processors (e.g., processor 121) of a device (e.g., device 102, network device 106, etc.). In other embodiments, process 900 is performed by other entities. In some embodiments, process 900 includes more than Figure 9 The steps shown may be more, fewer, or different from those shown.

[0115] In step 910, one or more processors may process the layer 2 header (e.g., ... Figure 3 In Ethernet frames (e.g., frame 300) containing L2 / IP 302 and payload (e.g., packetized transaction 306), the Layer 2 header is modified to include first information in the destination address field of the Layer 2 header. This first information may include addressing information used by interconnecting switches to forward Ethernet frames.

[0116] In step 920, one or more processors may transmit Ethernet frames containing modified layer 2 headers to interconnect switches via network interfaces.

[0117] In some embodiments, process 900 may include one or more processors generating a second header (e.g., RTH 304) containing one or more of the following fields as part of an Ethernet frame: an Adaptive Routing (AR) field that indicates to the interconnecting switches whether adaptive routing is performed; a Time-to-Live (TTL) field that indicates to the interconnecting switches whether per-hop lifetime reduction is performed; or an Explicit Congestion Notification (ECN) field that indicates the capability associated with the ECN.

[0118] In some embodiments, the second header may include a first field indicating whether the Ethernet frame is eligible for congestion notification. In some embodiments, the second header may include a Differentiated Service Code Point (DSCP) field indicating the traffic class of the Ethernet frame. In some embodiments, the second header may include a Congestion Notification Message (CNM) field indicating to the interconnecting switches whether the Ethernet frame is a congestion notification message.

[0119] In some embodiments, process 900 may include one or more processors setting values ​​for a first field, a DSCP field, and a CNM field, the values ​​indicating to an interconnecting switch whether to send CNM to a sender or a destination. In some embodiments, the DSCP field indicates to the interconnecting switch that the DSCP field should be treated differently from the DSCP field in the Internet Protocol header. In some embodiments, the second header may include a second field indicating the presence of a flow tag field. In some embodiments, process 900 may include one or more processors adding a flow tag field to the second header to instruct the interconnecting switch to select a route based on the value set in the flow tag field and setting the second field to the value indicating the presence of the flow tag field.

[0120] As discussed herein, this disclosure provides techniques for generating and transmitting Ethernet frames (e.g., Frame 300) containing an enhanced Layer 2 compatible header format tailored for AI-scale interconnect networks. In some instances, these techniques include constructing a second header containing fields for Adaptive Routing (AR), Time to Live (TTL), Congestion Notification Indicator (C, CNM), Differentiated Service Code Point (DSCP), and optional flow tags. The second header may be encoded immediately following the EtherType field as part of a compact, flexible header (e.g., a 2-byte or 3-byte variant) compatible with existing Ethernet transport architectures, including optional VLAN tags. Flexible headers enable switches to perform advanced routing, congestion management, and traffic classification without requiring in-depth packet inspection or upper-layer protocol modifications.

[0121] By directly incorporating routing and congestion control metadata into the Layer 2 portion of Ethernet frames, the described systems facilitate scalable and efficient data transmission across large AI / GPU cluster architectures. Specifically, these techniques support per-hop routing decisions, entropy-based load balancing, and fine-grained congestion signaling using in-band mechanisms. The exposed flexible headers can be added, interpreted, or modified by ELSIP components, interconnect switches, or endpoints, and can coexist with standard Ethernet frames on the same physical interface. These can be deployed in systems that rely on low-latency switching, adaptive flow control, or high-throughput communication, such as those used in machine learning training clusters, cloud-scale computing, and high-performance data center networks.

[0122] A reference to "or" can be interpreted as inclusive, such that any term described using "or" can refer to a single, more than one, or any of all descriptive terms. A reference to at least one of a list of combined terms can be interpreted as inclusive or to refer to a single, more than one, or any of all descriptive terms. For example, a reference to "at least one of 'A' and 'B'" can include only 'A', only 'B', or both 'A' and 'B'. Such references used in conjunction with "include" or other open terms can include additional items.

[0123] It should be noted that certain paragraphs of this disclosure may refer to terms such as “first” and “second” in relation to subsets of transmit space streams, probe frames, responses, and devices for identification or distinction from one another. These terms are not intended to associate entities (e.g., first and second devices) merely temporally or sequentially, although in some cases these entities may include such a relationship. These terms also do not limit the number of possible entities (e.g., STA, AP, beamformer, and / or beamformee) that can operate within the system or environment. It should be understood that the described system may provide any or multiple of those components, and these components may be provided on a standalone machine or, in some embodiments, on multiple machines in a distributed system. Furthermore, bit field positions may be changed, and multiple bit words may be used. Additionally, the described system and method may be provided as one or more computer-readable programs or executable instructions embodied on or in one or more articles of manufacture (e.g., floppy disk, hard disk, CD-ROM, flash memory card, PROM, RAM, ROM, or magnetic tape). The program can be implemented in any programming language (e.g., LISP, PERL, C, C++, C#) or in any bytecode language (e.g., JAVA). The software program or executable instructions can be stored as object code on or in one or more artifacts.

[0124] While the foregoing written description of the methods and systems enables those skilled in the art to make and use embodiments thereof, it should be understood and appreciated that variations, combinations, and equivalents of specific embodiments, methods, and examples exist herein. Therefore, the methods and systems of the present invention should not be limited to the foregoing embodiments, methods, and examples, but rather to all embodiments and methods within the scope and spirit of this disclosure.

Claims

1. An apparatus comprising: A network interface configured to exchange Ethernet frames with interconnecting switches; and A circuit system coupled to the network interface and configured to: For an Ethernet frame that includes a Layer 2 header and a payload, the Layer 2 header is modified to include first information in the destination address field of the Layer 2 header, wherein the first information is addressing information used by the interconnecting switch to forward the Ethernet frame; and The Ethernet frame containing the modified Layer 2 header is transmitted to the interconnecting switch via the network interface.

2. The apparatus of claim 1, wherein the circuit system is configured to: A second header is generated as part of the Ethernet frame, comprising one or more of the following fields: an Adaptive Routing (AR) field, which indicates to the interconnecting switch whether adaptive routing is to be performed; a Time-to-Live (TTL) field, which indicates to the interconnecting switch whether per-hop lifetime reduction is to be performed; or an Explicit Congestion Notification (ECN) field, which indicates the capability associated with the ECN.

3. The apparatus of claim 2, wherein the second header further comprises: The first field indicates that the Ethernet frame is eligible for congestion notification; The Differentiated Service Code Point (DSCP) field indicates the traffic class of the Ethernet frame; and The Congestion Notification Message (CNM) field indicates to the interconnecting switch whether the Ethernet frame is a congestion notification message.

4. The apparatus of claim 3, wherein the circuitry is configured to set values ​​for the first field, the DSCP field, and the CNM field, the values ​​indicating to the interconnecting switch whether to send the CNM to the sender or the destination.

5. The apparatus of claim 3, wherein the DSCP field indicates to the interconnecting switch that the DSCP field is to be treated differently from the DSCP field area of ​​the Internet Protocol header.

6. The apparatus of claim 2, wherein the second header includes a second field indicating the presence of a flow tag field, and the flow tag field instructs the interconnect switch to select a route based on a value set in the flow tag field.

7. The apparatus of claim 6, wherein the circuitry is configured to: Add a stream marker field to the second header, and Set the second field to a value that indicates the existence of the stream marker field.

8. A circuit system for exchanging Ethernet frames with interconnecting switches, wherein the circuit system is configured to: For an Ethernet frame containing a Layer 2 header and a payload, the Layer 2 header is modified to include first information in the destination address field of the Layer 2 header, wherein the first information is addressing information used by the interconnecting switch to forward the Ethernet frame; and The Ethernet frame containing the modified Layer 2 header is transmitted to the interconnecting switch.

9. The circuit system of claim 8, wherein the circuit system is configured to: A second header is generated as part of the Ethernet frame, comprising one or more of the following fields: an Adaptive Routing (AR) field, which indicates to the interconnecting switch whether adaptive routing is to be performed; a Time-to-Live (TTL) field, which indicates to the interconnecting switch whether per-hop lifetime reduction is to be performed; or an Explicit Congestion Notification (ECN) field, which indicates the capability associated with the ECN.

10. The circuit system of claim 9, wherein the second header further comprises: The first field indicates that the Ethernet frame is eligible for congestion notification; The Differentiated Service Code Point (DSCP) field indicates the traffic class of the Ethernet frame; and The Congestion Notification Message (CNM) field indicates to the interconnecting switch whether the Ethernet frame is a congestion notification message.

11. The circuit system of claim 10, wherein the circuit system is configured to set values ​​for the first field, the DSCP field, and the CNM field, the values ​​indicating to the interconnecting switch whether to send CNM to the sender or the destination.

12. The circuit system of claim 10, wherein the DSCP field indicates to the interconnecting switch that the DSCP field is to be treated differently from the DSCP field area of ​​the Internet Protocol header.

13. The circuit system of claim 9, wherein the second header includes a second field indicating the presence of a flow tag field, and the flow tag field instructs the interconnect switch to select a route based on a value set in the flow tag field.

14. The circuit system of claim 13, wherein the circuit system is configured to: Add a stream marker field to the second header, and Set the second field to a value that indicates the existence of the stream marker field.

15. A method for exchanging Ethernet frames with interconnecting switches, the method comprising: For an Ethernet frame that includes a Layer 2 header and a payload, the Layer 2 header is modified to include first information in the destination address field of the Layer 2 header, wherein the first information is addressing information used by the interconnecting switch to forward the Ethernet frame; and The Ethernet frame containing the modified Layer 2 header is transmitted to the interconnected switch via the network interface.

16. The method of claim 15, further comprising: A second header is generated as part of the Ethernet frame, comprising one or more of the following fields: an Adaptive Routing (AR) field, which indicates to the interconnecting switch whether adaptive routing is to be performed; a Time-to-Live (TTL) field, which indicates to the interconnecting switch whether per-hop lifetime reduction is to be performed; or an Explicit Congestion Notification (ECN) field, which indicates the capability associated with the ECN.

17. The method of claim 16, wherein the second header further comprises: The first field indicates that the Ethernet frame is eligible for congestion notification; The Differentiated Service Code Point (DSCP) field indicates the traffic class of the Ethernet frame; and The Congestion Notification Message (CNM) field indicates to the interconnecting switch whether the Ethernet frame is a congestion notification message.

18. The method of claim 17, further comprising: The values ​​of the first field, the DSCP field, and the CNM field are set, and the values ​​indicate to the interconnecting switch whether to send the CNM to the sender or the destination.

19. The method of claim 17, wherein the DSCP field indicates to the interconnecting switch that the DSCP field is to be treated differently from the DSCP field area of ​​the Internet Protocol header.

20. The method of claim 16, wherein the second header includes a second field indicating the presence of a stream marker field, and the method further includes: A flow tag field is added to the second header, which instructs the interconnecting switch to select a route based on the value set in the flow tag field. Set the second field to a value that indicates the existence of the stream marker field.

Images