GSE architecture for AIDC
draft-zhuang-rtgwg-aidc-gse-architecture-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 | Rui Zhuang , Zheng Zhang | ||
| Last updated | 2026-06-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhuang-rtgwg-aidc-gse-architecture-00
RTGWG R. Zhuang
Internet-Draft China Mobile
Intended status: Informational Z. Zhang, Ed.
Expires: 26 December 2026 ZTE Corporation
24 June 2026
GSE architecture for AIDC
draft-zhuang-rtgwg-aidc-gse-architecture-00
Abstract
This document introduces a Global Scheduling Ethernet (GSE)
architecture for data centers used for AI computing. This
architecture can minimize the probability of packet forwarding
congestion in the network and improve the efficiency of packet
interaction.
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 26 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Zhuang & Zhang Expires 26 December 2026 [Page 1]
Internet-Draft AIDC GSE Architecture June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. GSE Architecture . . . . . . . . . . . . . . . . . . . . . . 2
3. GSE deployment scenarios . . . . . . . . . . . . . . . . . . 4
3.1. GSE Scenario 1 . . . . . . . . . . . . . . . . . . . . . 4
3.2. GSE Scenario 2 . . . . . . . . . . . . . . . . . . . . . 5
3.3. GSE summary . . . . . . . . . . . . . . . . . . . . . . . 7
4. GSE header . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The development of Artificial Intelligence (AI) and Machine Learning
(ML) has brought about a transformation in data center development.
Due to the data-intensive nature of large language model (LLM)
computations, AI tasks often generate large amounts of traffic. If
the link bandwidth is insufficient, it can lead to packet loss or
significant latency. AI computation has very high reliability
requirements and extremely low tolerance for packet loss and latency.
Network congestion that causes packet loss or excessive latency will
significantly impact the computational efficiency of AI tasks.
There are many implementations in the industry to reduce packet loss
and latency. This document introduces an implementation architecture
called GSE for reference.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. GSE Architecture
Zhuang & Zhang Expires 26 December 2026 [Page 2]
Internet-Draft AIDC GSE Architecture June 2026
+------------+
| Controller | Control Layer
+------------+
--------------------------------------------------------------------
Network Layer
+-------+ +-------+ +-------+
| Spine | | Spine | ...... | Spine | Layer2
+-------+ +-------+ +-------+
+-------+ +-------+ +-------+
| Spine | | Spine | ...... | Spine | Layer1
+-------+ +-------+ +-------+
+------+ +------+ +------+ +------+ +------+
| Leaf | | Leaf | | Leaf | | Leaf | ...... | Leaf |
+------+ +------+ +------+ +------+ +------+
--------------------------------------------------------------------
Computation Layer
+--------+ +--------+ +--------+ +--------+ +--------+
| Server | | Server | | Server | | Server | ...... | Server |
+--------+ +--------+ +--------+ +--------+ +--------+
Figure 1
Figure 1 shows a common data center architecture for AI computing,
divided into three layers: control layer, network layer, and
computation layer.
* The computation layer consists of servers used for AI computing,
including GPUs and NICs.
* The network layer uses a common Clos/Fat Tree topology as an
example, while other topologies can also be used in practice. In
a 3-layer Clos topology, it consists of Leaf switches connected to
the servers and Layer 1 and Layer 2 Spine switches.
* The control layer consists of centralized or distributed
controllers.
This document mainly focuses on implementation methods for the
network layer. Notably, cross-layer collaboration between the
network layer and the computation layer is also required.
To meet the stringent packet loss and latency requirements for AI
computing, the following implementation mechanisms can be used at the
network layer:
Zhuang & Zhang Expires 26 December 2026 [Page 3]
Internet-Draft AIDC GSE Architecture June 2026
* Credit-based authorization mechanism: The main idea is to use
credit-based authorization to control data transmission and reduce
congestion probability. Before packet transmission, the sender
initiates an authorization request to the receiver to ensure that
the receiver has sufficient bandwidth to receive packets, thereby
avoiding packet loss caused by last-hop congestion.
* Packet aggregation mechanism: The main idea is to aggregate
packets into uniform-sized segments, which is more conducive to
packet forwarding and reception control.
* Improved ECMP mechanism: This mechanism not only distributes
traffic evenly across ECMP links to avoid congestion, but also
ensures in-order packet arrival at the destination, thereby
reducing the buffering and processing overhead at the receiver.
Additionally, technologies such as PFC (Priority-based Flow Control,
IEEE802.1Qbb) and ECN (Explicit Congestion Notification, [RFC3168])
are also deployed to further reduce congestion-related packet loss.
3. GSE deployment scenarios
3.1. GSE Scenario 1
+----------+ +----------+
| Spine1 | | Spine2 |
+--+-+-+-+-+ +--+-+-+-+-+
| | | | | | | |
+-------------------------------------+ | | |
| | | | | +--------------------------+ | |
| | | | | | +--------+ |
| | | | | | | |
| | | | +--------------------------------------+
| | | +-----------------------+ | | |
+---+ +------+ | | | | |
| | | | | | | |
+----+-+--+ +--+-+----+ +--+--+---+ +-+--+----+
| Leaf1 | | Leaf2 | | Leaf3 | | Leaf4 |
+-+-----+-+ +-+-----+-+ +-+-----+-+ +-+-----+-+
| | | | | | | |
| .. | | ... | | ... | | ... |
| | | | | | | |
+-+-----+-+ +-+-----+-+ +-+-----+-+ +-+-----+-+
|N1|N2|...| |N9|N10|..| |N17|N18|.| |N25|N26|.|
+---------+ +---------+ +---------+ +---------+
Server1 Server2 Server3 Server4
Figure 2
Zhuang & Zhang Expires 26 December 2026 [Page 4]
Internet-Draft AIDC GSE Architecture June 2026
Each server include GPUs, NICs, etc. As shown in Figure 2, NIC1
connects to Leaf1, and NIC20 connects to Leaf3. Take the scenario
where GPU1 sends AI computing traffic to GPU20 as an example: Before
sending the traffic, NIC1, to which GPU1 is connected, initiates an
authorization request to NIC20, to which GPU20 is connected. Both
the request and response messages are encapsulated in a specific
message to ensure identification and forwarding by switches. When
NIC20 confirms that traffic transmission is possible, it sends a
negotiation response to NIC1. NIC1 only begins traffic sending after
receiving the authorization response.
This specific message (including negotiation request and negotiation
response) is generated and sent by hardware such as chips. Its outer
addressing can adopt an encapsulation similar to the GSE header
defined in this document. This specific negotiation message includes
information such as the required bandwidth, which is not defined in
this draft. This negotiation mechanism applies bidirectionally. For
example, the same workflow is followed when GPUs on Server2 or
Server3 send traffic to GPU1 on Server1.
This negotiation mechanism requires a link between the NIC and the
Leaf switch, which can be identified by the address of GPU/NIC plus
the interface index connected to the Leaf switch. For NICs
supporting the credit authorization mechanism, the NIC obtains the
port ID from its upstream Leaf switch, and initiates credit
authorization requests and responses based on this set of
identification information. Information exchange between the NIC and
the Leaf switch can be implemented via private ARP messages or
extensions such as LLDP, which are not defined in this document.
This GPU/NIC address and associated port information can be
advertised via control plane routing protocols, learned through
interactions between the Leaf and Spine switches.
If the NIC does not support the authorization mechanism, this process
can also be done by the Leaf switch connected to the NIC.
3.2. GSE Scenario 2
Zhuang & Zhang Expires 26 December 2026 [Page 5]
Internet-Draft AIDC GSE Architecture June 2026
+--------------------------------------------------------+
| ... PodM |
| |
| +----------+ +----------+ +----------+ |
| | Core1 | | Core2 | ... | CoreZ | |
| +--+-------+ ++---------+ +----------+ |
| | | ...... |
| | +----+ |
| | | |
| +--+------++ +----------+ +----------+ |
+-- | SSpine1 | | SSpine2 | ... | SSpineN | -----+
+----------+ +----------+ +----------+
+----------+ +----------+
| Spine1 | | Spine2 |
+----------+ +----------+
+----+-+--+ +--+-+----+ +--+--+---+ +-+--+----+
| Leaf1 | | Leaf2 | | Leaf3 | | Leaf4 |
+-+-----+-+ +-+-----+-+ +-+-----+-+ +-+-----+-+
|
+-+-----+-+ +-+-----+-+ +-+-----+-+ +-+-----+-+
|N1|N2|...| |N9|N10|..| |N17|N18|.| |N25|N26|.|
+---------+ +---------+ +---------+ +---------+
Server1 Server2 Server3 Server4
Figure 3
Figure 1 only shows a portion of a single PoD. Typical data centers
used for AI computing are much larger and require more connections to
other PoDs. Figure 3 provides an example where not all connections
are displayed due to the complexity of the wiring. Each PoD's SSpine
switch is connected to other PoDs' SSpine switches via a Core switch.
It is difficult to ensure that traffic flows from one PoD's Leaf
switch to another PoD's Leaf switch without congestion throughout the
entire forwarding process. However, within a single PoD, a method
similar to that in Scenario 1 can be used, employing GSE to ensure
low-latency, congestion-free forwarding of traffic from the Leaf
switch to the Core switch.
Before forwarding traffic from N1, Leaf1 sends a negotiation message
to the SSpine1 switch, specifying the link between SSpine1 and Core1.
Leaf1 will only begin forwarding traffic from N1 if the bandwidth
between SSpine1 and Core1 is sufficient, i.e., if the negotiation is
successful. If the link bandwidth between SSpine1 and Core1 is
insufficient, Leaf1 can send another negotiation message to the
SSpine1 switch, specifying the link between SSpine1 and Core2.
Again, Leaf1 will only begin forwarding traffic from N1 if the
Zhuang & Zhang Expires 26 December 2026 [Page 6]
Internet-Draft AIDC GSE Architecture June 2026
negotiation is successful. This ensures that unless a link failure
occurs, there will be no packet loss before the traffic reaches
Core1.
3.3. GSE summary
The requirements for the two scenarios above are similar; both
require carrying the corresponding port information when announcing
routes (routes from the NIC/GPU and routes obtained from other PoDs).
Therefore, the port ID information used for authorization can be
advertised along with the route; for the advertising method, refer to
[I-D.zhang-idr-portid-ec]. Based on the information, certain
existing implementations support pre-transmission negotiation to
ensure sufficient bandwidth at the egress point before sending
traffic.
After traffic transmission begins, data packets are aggregated into
uniform-sized segments, and sequence numbers are added to these
packets based on the segments they belong to. This ensures that even
if a link fails or congestion occurs, data packets passing through
different paths can be reordered based on sequence numbers. During
the transmission of the same segment, in order to utilize the same
path on the ECMP links as much as possible to reduce the buffering
and processing pressure on packet reassembly, an entropy value is
needed to guarantee the stability of path selection. In some
implementations, the source and destination queue identifiers, such
as QP, can be used directly as entropy. Although this mechanism
reduces the probability of congestion, network congestion can still
occur. In such cases, other idle or light load ECMP links can be
used to transmit segments. Simultaneously, mechanisms such as PFC
and ECN can be also used to adjust the traffic transmission rate,
thereby further reducing the probability of congestion.
Such a message forwarding mechanism is difficult to implement using
traditional IP-based forwarding, so additional definitions may be
required. These defined fields can be identified and processed by
GSE header encapsulation.
4. GSE header
+------------------------------------------------------------------+
| Destination | port-ID | Priority | Entropy | Seq | ......
+------------------------------------------------------------------+
Figure 4
Zhuang & Zhang Expires 26 December 2026 [Page 7]
Internet-Draft AIDC GSE Architecture June 2026
Figure 4 shows a GSE packet header example for reference. It can be
recognized and forwarded by the network layer, one implementation
uses a new type Ethernet encapsulation.
* Destination: The IP address or address value of the GPU/NIC or
switch;
* port-ID: Port-ID used for authorization;
* Priority: Traffic transmission priority, similar to DSCP.
* Entropy: Values used for traffic load balancing.
* Seq: The sequence number of the data packet is used for reassembly
in case of out-of-order delivery.
5. IANA Considerations
This document includes no request to IANA.
6. Security Considerations
This draft provides an implementation reference. Implementing this
scheme will introduce new packet identification and forwarding
processes, impacting the implementation of switches and NICs.
Inappropriate implementation and deployment may lead to packet
forgery attacks.
7. References
7.1. Normative References
[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>.
7.2. Informative References
[I-D.zhang-idr-portid-ec]
Zhang, J., Zhuang, R., Zhang, Z., and D. Yuan, "BGP PORT
EC for AIDC", Work in Progress, Internet-Draft, draft-
zhang-idr-portid-ec-01, 15 March 2026,
<https://datatracker.ietf.org/doc/html/draft-zhang-idr-
portid-ec-01>.
Zhuang & Zhang Expires 26 December 2026 [Page 8]
Internet-Draft AIDC GSE Architecture June 2026
[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>.
Authors' Addresses
Rui Zhuang
China Mobile
China
Email: zhuangruiyjy@chinamobile.com
Zheng Zhang (editor)
ZTE Corporation
China
Email: zhang.zheng@zte.com.cn
Zhuang & Zhang Expires 26 December 2026 [Page 9]