OSPF-TE Extensions for Computing Capability Advertisement
draft-li-ccamp-ospf-te-extension-computing-cap-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 | Ao Li , Tianhe Liu , Zheng Yanlei | ||
| Last updated | 2026-07-06 | ||
| 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-li-ccamp-ospf-te-extension-computing-cap-00
CCAMP A. Li
Internet-Draft China Unicom
Intended status: Standards Track T. Liu
Expires: 7 January 2027Beijing University of Posts and Telecommunications
Y. Zheng
China Unicom
6 July 2026
OSPF-TE Extensions for Computing Capability Advertisement
draft-li-ccamp-ospf-te-extension-computing-cap-00
Abstract
This document defines extensions to OSPF Traffic Engineering (OSPF-
TE) for advertising computing capability information associated with
Artificial Intelligence Data Centers (AIDCs) in optical networks.
The extensions enable an ASON or GMPLS-capable optical network to
maintain a synchronized view of both network TE resources and
selected computing resource attributes, so that service placement and
path computation can consider computing resource status.
The mechanism uses OSPFv2 Type-10 Opaque LSAs and a set of top-level
TLVs and sub-TLVs. The extensions do not define new OSPF packet
types and do not modify the OSPF neighbor establishment, database
exchange, flooding, or acknowledgement procedures.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 7 January 2027 [Page 1]
Internet-Draft OSPF-TE Compute Info July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Computing Capability Opaque LSA . . . . . . . . . . . . . . . 4
5.1. LSA Type and Opaque Type . . . . . . . . . . . . . . . . 5
5.2. LSA ID . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. TLV Encoding Rules . . . . . . . . . . . . . . . . . . . 6
6. Top-Level TLVs . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. AIDC GPU Basic Information TLV . . . . . . . . . . . . . 6
6.1.1. GPU Attribute Sub-TLVs . . . . . . . . . . . . . . . 8
6.2. AIDC GPU Performance TLV . . . . . . . . . . . . . . . . 12
6.3. AIDC Global Compute Performance TLV . . . . . . . . . . . 13
7. LSA Origination and Processing . . . . . . . . . . . . . . . 14
7.1. Origination Triggers . . . . . . . . . . . . . . . . . . 14
7.2. Processing Rules . . . . . . . . . . . . . . . . . . . . 15
7.3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Large AI workloads may require computing resources from multiple
AIDCs. In such deployments, optical networks can provide high-
bandwidth, low-latency, and reliable interconnection among AIDCs.
Coordinated use of optical-network resources and computing resources
can support cross-site inference, multi-data-center training, and
other distributed computing services.
The Optical Networks and AI Computing Orchestration (ONCO) framework
[I-D.hu-ccamp-onco-control-framework] describes a control framework
in which optical network resources and AI computing resources are
coordinated across management, control, and data planes. In such
Li, et al. Expires 7 January 2027 [Page 2]
Internet-Draft OSPF-TE Compute Info July 2026
deployments, selected computing capability metrics may be collected
in the compute domain and provided to an OSPF-TE speaker through an
OC-GW, a controller, or another originating function. OSPF-TE can
then be used to advertise these metrics within the OSPF-TE domain.
In optical networks, OSPF-TE is used to distribute Traffic
Engineering (TE) attributes for path computation. When
geographically distributed AIDCs are interconnected, network
reachability alone does not determine whether a requested service can
be placed at a particular AIDC. Path computation based only on
traditional network TE attributes, such as connectivity, bandwidth,
or network metrics, cannot reflect computing capability or resource
status. Computing-aware routing decisions therefore need to consider
both network TE attributes and selected computing capability metrics.
This document defines extensions to OSPF-TE [RFC3630] to advertise
selected AIDC computing capability information in an OSPF-TE-enabled
optical network. The advertisement may be originated by an OC-GW, an
optical network node, or another OSPF-TE speaker that has access to
the relevant computing capability information. The resulting
information is flooded according to normal OSPF-TE flooding
procedures. This extension is not intended to advertise full
computing capability information. It is intended to advertise
selected computing capability metrics that are relevant to computing-
aware routing decisions.
The extensions defined in this document are distinct from the
existing use of OSPF-TE to carry optical-network TE information.
Existing OSPF-TE advertisements describe network-side resource
attributes used for optical path computation, such as TE links,
interface attributes, and switching capabilities. In contrast, the
Computing Capability LSA defined by this document carries compute-
domain summaries associated with an AIDC or an OC-GW, such as GPU
type, GPU-associated interface capability, and aggregate memory or
storage status. Both kinds of information reuse the OSPFv2 Type-10
Opaque LSA flooding mechanism, but they are distinguished by their
Opaque Type and TLV semantics. Therefore, the computing-capability
advertisement augments the TE database with selected computing
capability metrics; it does not replace, reinterpret, or alter the
existing optical TE advertisements used to compute network paths.
To achieve these objectives, this document defines a dedicated
container for computing information in an Opaque LSA and uses TLVs
and sub-TLVs to encode AIDC-level and GPU-Type-level attributes, such
as GPU type and capability and summaries of memory and storage
capability. The mechanism introduces no new OSPF packet types and
does not alter adjacency establishment, database exchange, flooding,
or acknowledgement procedures.
Li, et al. Expires 7 January 2027 [Page 3]
Internet-Draft OSPF-TE Compute Info July 2026
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
The following terms are used in this document:
Artificial Intelligence Data Center (AIDC): A data center that
provides GPU, memory, storage, and related computing resources for AI
services.
Automatically Switched Optical Network (ASON): An optical network
that supports automatic connection setup, control, and resource
management through a control plane.
Optical-Compute Gateway (OC-GW): A protocol mediation gateway
deployed at the AIDC edge, facilitating the exchange of compute
metrics between the compute domain and the optical network. It
translates compute metrics into network-layer TE attributes.
4. Applicability
This extension is applicable to networks that support Opaque LSAs and
OSPF-TE. It is intended for deployments in which a network control
plane or path computation function needs selected AIDC computing
capability information to be advertised by an OC-GW, an optical
network node, or another originating OSPF-TE speaker, and to be
flooded among optical network nodes within the applicable OSPF area.
Because the computing information is flooded by means of Type-10
Opaque LSAs, the mechanism is primarily applicable to distribution
within a single OSPF area. Summarization, translation, or policy-
based distribution of computing information across areas, across AS,
or across operator domains is outside the scope of this document.
This document does not define how the computing control system
obtains local server, GPU, memory, storage, or task information
inside an AIDC. It also does not define the service-request
signaling protocol used to request a computing destination. Those
functions are outside the scope of this document. The focus of this
document is the OSPF-TE advertisement of computing information.
5. Computing Capability Opaque LSA
Li, et al. Expires 7 January 2027 [Page 4]
Internet-Draft OSPF-TE Compute Info July 2026
5.1. LSA Type and Opaque Type
The Computing Capability LSA is an OSPFv2 Type-10 Opaque LSA. It
uses a new Opaque Type, COMPUTING-CAPABILITY-OPAQUE-TYPE, to be
assigned by IANA. The suggested value is 12. Until IANA allocation
is completed, implementations MUST treat the value as experimental or
configurable.
The LSA payload consists of one or more top-level TLVs. This
document defines the following top-level TLVs:
+======+=====================================+
| Type | TLV |
+======+=====================================+
| 1 | AIDC GPU Basic Information TLV |
+------+-------------------------------------+
| 2 | AIDC GPU Performance TLV |
+------+-------------------------------------+
| 3 | AIDC Global Compute Performance TLV |
+------+-------------------------------------+
Table 1: Top-Level Computing Capability TLVs
An implementation receiving an unknown top-level TLV in a Computing
Capability LSA MUST ignore the unknown TLV and continue processing
the remaining TLVs in the LSA.
5.2. LSA ID
In an Opaque LSA, the 32-bit Link State ID consists of an 8-bit
Opaque Type and a 24-bit Opaque ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The Opaque Type is COMPUTING-CAPABILITY-OPAQUE-TYPE. The Opaque ID
identifies one instance of computing capability under that Opaque
Type. The Opaque ID has no topological meaning.
A router MAY originate multiple Computing Capability LSAs. For
example, a router may originate one LSA per AIDC GPU Type and one
additional LSA for global AIDC-level performance information.
Li, et al. Expires 7 January 2027 [Page 5]
Internet-Draft OSPF-TE Compute Info July 2026
5.3. TLV Encoding Rules
All multi-octet fields are encoded in network byte order. Unless
otherwise specified, reserved fields MUST be set to zero on
transmission and MUST be ignored on receipt.
Top-level TLVs and sub-TLVs use the following generic format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
*Type:* A 16-bit identifier.
*Length:* A 16-bit field that specifies the total length of the TLV
or sub-TLV in octets, including the Type and Length fields.
*Value:* A variable-length field. The Value field MAY contain one or
more sub-TLVs.
TLVs and sub-TLVs SHOULD be padded to a 32-bit boundary when
necessary. Padding octets are used only for alignment, MUST be set
to zero on transmission, and MUST be ignored on receipt. Padding
octets are not included in the Length field. A receiver MUST ignore
padding. [RFC3630]
6. Top-Level TLVs
6.1. AIDC GPU Basic Information TLV
The AIDC GPU Basic Information TLV describes static or slowly
changing properties of a GPU Type in an AIDC. A Computing Capability
LSA that describes GPU information MUST include exactly one AIDC GPU
Basic Information TLV.
Li, et al. Expires 7 January 2027 [Page 6]
Internet-Draft OSPF-TE Compute Info July 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AIDC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OC-GW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-side Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 2 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 3 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 4 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 5 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 6 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 7 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 8 Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
*AIDC ID:* A 32-bit identifier of the AIDC. The value MUST be unique
within the administrative domain.
*OC-GW ID:* A 32-bit identifier of the OC-GW. The value MUST be
unique within the administrative domain.
*Client-side Port ID:* A 32-bit identifier of the customer-facing
port or UNI-side interface associated with the AIDC or OC-GW.
*GPU Attribute Sub-TLVs:* One or more sub-TLVs defined in
Section 6.1.1. The GPU Vendor sub-TLV and GPU Model sub-TLV are
keys. Exactly one GPU Vendor sub-TLV and exactly one GPU Model sub-
TLV MUST be present in this TLV. Other GPU Attribute sub-TLVs MAY
appear multiple times when multiple values are supported.
Li, et al. Expires 7 January 2027 [Page 7]
Internet-Draft OSPF-TE Compute Info July 2026
6.1.1. GPU Attribute Sub-TLVs
GPU Attribute sub-TLVs are carried in the AIDC GPU Basic Information
TLV. Each sub-TLV uses the generic sub-TLV format defined in
Section 5.3.
+======+======================================+============+
| Type | Sub-TLV | Max Length |
+======+======================================+============+
| 1 | GPU Vendor | 12 octets |
+------+--------------------------------------+------------+
| 2 | GPU Model | 12 octets |
+------+--------------------------------------+------------+
| 3 | GPU-associated Link-Layer Protocol | 16 octets |
+------+--------------------------------------+------------+
| 4 | GPU-associated Transport Protocol | 16 octets |
+------+--------------------------------------+------------+
| 5 | Operating System | 12 octets |
+------+--------------------------------------+------------+
| 6 | GPU Driver Version | 16 octets |
+------+--------------------------------------+------------+
| 7 | GPU Computing Framework | 12 octets |
+------+--------------------------------------+------------+
| 8 | GPU Collective Communication Library | 8 octets |
+------+--------------------------------------+------------+
Table 2: GPU Attribute Sub-TLVs
The Value field of each GPU Attribute sub-TLV is an ASCII string. It
MUST NOT be NUL-terminated. If a value is shorter than the maximum
length, the Length field MUST indicate the actual sub-TLV length,
including the Sub-TLV Type and Length fields. If a value exceeds the
maximum length, the originator MUST either advertise an abbreviated
value that is locally unambiguous or omit the sub-TLV.
For the Operating System and GPU Driver Version sub-TLVs, an AIDC may
contain multiple versions for the same GPU Type. To reduce protocol
overhead, an implementation SHOULD advertise the highest capability
version within the same major version unless operator policy requires
more detailed advertisement.
6.1.1.1. GPU Vendor Sub-TLV
Li, et al. Expires 7 January 2027 [Page 8]
Internet-Draft OSPF-TE Compute Info July 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU Vendor, max 12 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GPU Vendor Sub-TLV is used to advertise the GPU vendor
information. The Sub-TLV Type field is set to 1. The Length field
is variable and specifies the total sub-TLV length in octets,
including the Sub-TLV Type and Length fields. The Value field
contains the GPU vendor name encoded as an ASCII string. The Value
field MUST NOT exceed 12 octets.
6.1.1.2. GPU Model
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU Model, max 12 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GPU Model Sub-TLV is used to advertise the GPU model information.
The Sub-TLV Type field is set to 2. The Length field is variable and
specifies the total sub-TLV length in octets, including the Sub-TLV
Type and Length fields. The Value field contains the GPU model name
encoded as an ASCII string. The Value field MUST NOT exceed 12
octets.
6.1.1.3. GPU-associated Link-Layer Protocol
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU-associated Link-Layer Protocol, max 16 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires 7 January 2027 [Page 9]
Internet-Draft OSPF-TE Compute Info July 2026
The Link-Layer Protocol Sub-TLV is used to advertise the link-layer
protocol of the network interface associated with the GPU. The Sub-
TLV Type field is set to 3. The Length field is variable and
specifies the total sub-TLV length in octets, including the Sub-TLV
Type and Length fields. The Value field contains the link-layer
protocol name encoded as an ASCII string. The Value field MUST NOT
exceed 16 octets.
6.1.1.4. GPU-associated Transport Protocol
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU-associated Transport Protocol, max 16 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Transport-Layer Protocol Sub-TLV is used to advertise the
transport-layer protocol of the network interface associated with the
GPU. The Sub-TLV Type field is set to 4. The Length field is
variable and specifies the total sub-TLV length in octets, including
the Sub-TLV Type and Length fields. The Value field contains the
transport-layer protocol name encoded as an ASCII string. The Value
field MUST NOT exceed 16 octets.
6.1.1.5. Operating System
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Operating System, max 12 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Operating System Sub-TLV is used to advertise the operating
system information associated with the GPU. The Sub-TLV Type field
is set to 5. The Length field is variable and specifies the total
sub-TLV length in octets, including the Sub-TLV Type and Length
fields. The Value field contains the operating system name encoded
as an ASCII string. The Value field MUST NOT exceed 12 octets.
Li, et al. Expires 7 January 2027 [Page 10]
Internet-Draft OSPF-TE Compute Info July 2026
6.1.1.6. GPU Driver Version
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU Driver Version, max 16 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GPU Driver Version Sub-TLV is used to advertise the GPU driver
version. The Sub-TLV Type field is set to 6. The Length field is
variable and specifies the total sub-TLV length in octets, including
the Sub-TLV Type and Length fields. The Value field contains the GPU
driver version encoded as an ASCII string. The Value field MUST NOT
exceed 16 octets.
Multiple driver versions may exist for the same type of GPU within an
AIDC. To reduce protocol overhead, it is RECOMMENDED that only the
driver version with the highest capability among driver versions with
the same major version be advertised.
6.1.1.7. GPU Computing Framework
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU Computing Framework, max 12 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GPU Computing Framework Sub-TLV is used to advertise the GPU
computing framework. The Sub-TLV Type field is set to 7. The Length
field is variable and specifies the total sub-TLV length in octets,
including the Sub-TLV Type and Length fields. The Value field
contains the GPU computing framework name encoded as an ASCII string.
The Value field MUST NOT exceed 12 octets.
6.1.1.8. GPU Collective Communication Library
Li, et al. Expires 7 January 2027 [Page 11]
Internet-Draft OSPF-TE Compute Info July 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GPU Collective Communication Library, max 8 octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GPU Server Collective Communication Database Sub-TLV is used to
advertise the GPU server collective communication database. The Sub-
TLV Type field is set to 8. The Length field is variable and
specifies the total sub-TLV length in octets, including the Sub-TLV
Type and Length fields. The Value field contains the name of the GPU
server collective communication database encoded as an ASCII string.
The Value field MUST NOT exceed 8 octets.
6.2. AIDC GPU Performance TLV
The AIDC GPU Performance TLV describes dynamic or frequently updated
GPU performance information for a specific AIDC and GPU Type.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 2 | Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GPU Memory Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth of GPU-associated NIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GPU Util. | GPU NIC State | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
The Type field is 2 octets in length and is set to 2, indicating the
Type 2 Top-Level TLV. The Length field is 2 octets in length and is
set to 14, including the Type and Length fields. The Value field
contains the following fields:
*GPU Memory Capacity:* A 4-octet unsigned integer that indicates the
memory capacity of the corresponding type of GPU, in GB.
*Bandwidth of GPU-associated NIC:* A 4-octet unsigned integer that
indicates the bandwidth of the network interface associated with the
corresponding type of GPU, in GB/s.
Li, et al. Expires 7 January 2027 [Page 12]
Internet-Draft OSPF-TE Compute Info July 2026
*GPU Utilization:* A 1-octet unsigned integer that indicates the
utilization of the corresponding type of GPU.
*GPU-associated NIC State:* A 1-octet field that indicates the
operational state of the network interface associated with the GPU.
A value of 1 indicates that the interface is UP. A value of 2
indicates that the interface is DOWN.
*Padding:* A 2-octet field. It MUST be set to zero on transmission
and MUST be ignored on receipt.
6.3. AIDC Global Compute Performance TLV
The AIDC Global Compute Performance TLV describes AIDC-level
computing performance information that is not specific to a single
GPU Type. Each AIDC SHOULD originate one AIDC Global Compute
Performance TLV per advertising OC-GW or edge ASON node.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Memory Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Storage Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Memory Util. | Storage Util. | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type = 1 | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Intra-Node Communication Architecture ~
| max 12 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
The Type field is 2 octets in length and is set to 3, indicating the
Type 3 Top-Level TLV. The Length field is variable and specifies the
total TLV length in octets, including the Type and Length fields.
The Value field contains the following fields:
*Total Memory Capacity:* A 32-bit unsigned integer indicating the
total memory capacity of the AIDC, in gigabytes.
*Total Storage Capacity:* A 32-bit unsigned integer indicating the
total storage capacity of the AIDC, in gigabytes.
Li, et al. Expires 7 January 2027 [Page 13]
Internet-Draft OSPF-TE Compute Info July 2026
*Memory Utilization:* An 8-bit unsigned integer indicating AIDC-level
memory utilization percentage. Values from 0 to 100 are valid.
*Storage Utilization:* An 8-bit unsigned integer indicating AIDC-
level storage utilization percentage. Values from 0 to 100 are
valid.
*Padding:* A 2-octet field. It MUST be set to zero on transmission
and MUST be ignored on receipt.
*Intra-AIDC Communication Architecture Sub-TLVs:* Zero or more sub-
TLVs. Multiple instances MAY be present when an AIDC supports
multiple communication architectures. The Value field is an ASCII
string with a maximum length of 12 octets. The string identifies an
intra-AIDC communication architecture or framework supported by the
AIDC.
7. LSA Origination and Processing
7.1. Origination Triggers
A node that originates Computing Capability LSAs SHOULD originate or
refresh them in the following cases:
* when the OSPF adjacency reaches Full state and the node is
responsible for advertising AIDC computing information;
* when an AIDC is added, removed, enabled, or disabled;
* when the computing resource is added, removed, enabled, or
disabled;
* when a dynamic metric crosses an operator-configured threshold;
* when a periodic refresh is required by OSPF LSA aging rules;
* when local policy requires re-advertisement.
Implementations MUST provide configurable dampening or threshold
controls for frequently changing metrics such as GPU utilization,
memory utilization, and storage utilization. This is required to
avoid excessive OSPF flooding caused by small resource fluctuations.
Li, et al. Expires 7 January 2027 [Page 14]
Internet-Draft OSPF-TE Compute Info July 2026
7.2. Processing Rules
A router receiving a Computing Capability LSA MUST process the LSA
using normal OSPF Opaque LSA processing rules. If the LSA is
accepted into the LSDB, the router MUST flood it according to the
normal Type-10 Opaque LSA flooding rules.
A router that understands the Computing Capability LSA SHOULD parse
the TLVs and make the resulting information available to local
applications such as path computation, service placement, or
controller agents.
A router that does not understand one or more TLVs or sub-TLVs MUST
ignore the unknown TLVs or sub-TLVs and MUST NOT reject the whole LSA
solely because unknown information is present.
A receiver MUST validate all Length fields before parsing the Value
field. If a TLV or sub-TLV Length is malformed, the receiver MUST
ignore the malformed TLV or sub-TLV and SHOULD log a diagnostic
message.
When multiple LSAs advertise information for the same AIDC and GPU
Type, normal OSPF LSA selection rules determine the active LSA for a
given {LS type, Link State ID, Advertising Router}. If semantically
duplicate information is originated by multiple routers, local policy
determines which information is preferred.
7.3. Use Case
This document does not mandate a specific usage. However, the
advertised information is intended to support path computation and
service placement procedures that consider both network TE
constraints and computing constraints. Service signaling, including
any RSVP-TE extension used to carry a computing request or task-
deployment notification, is outside the scope of this document.
Figure 6 illustrates one possible deployment of the mechanism defined
in this document. In this example, AIDC 1 is the source site, while
AIDC 2 and AIDC 3 are candidate destination sites. This example does
not constrain other deployments.
Each optical node may obtain selected computing capability metrics
from its associated AIDC and originate a Computing Capability LSA
toward its attached optical node. After a valid LSA is accepted, it
is flooded among Optical Nodes 1, 2, and 3 according to the normal
OSPFv2 Type-10 Opaque LSA procedures.
Li, et al. Expires 7 January 2027 [Page 15]
Internet-Draft OSPF-TE Compute Info July 2026
For example, AIDC 2 and AIDC 3 may advertise different GPU
utilization values. AIDC 2 may advertise a GPU utilization of 80
percent, while AIDC 3 may advertise a GPU utilization of 30 percent.
A path computation function associated with Optical Node 1 can
combine these computing capability metrics with network TE
attributes. If the paths to both candidate AIDCs satisfy the network
constraints, the function may prefer AIDC 3 because of its lower
advertised GPU utilization.
+--------+ +-----------------+ +-----------------+ +--------+
| AIDC 1 |--| Optical Node 1 |--| Optical Node 2 |--| AIDC 2 |
| | | GMPLS/OSPF-TE | | GMPLS/OSPF-TE | | |
+--------+ +--------+--------+ +--------+--------+ +--------+
| |
| |
+--------+ +--------+--------+ |
| AIDC 3 |--| Optical Node 3 |-----------+
| | | GMPLS/OSPF-TE |
+--------+ +-----------------+
Figure 6: Computing Capability Advertisement Use Case
8. Security Considerations
The security considerations of OSPFv2 [RFC2328] and OSPF-TE [RFC3630]
apply to the extensions defined in this document. Computing
Capability LSAs are carried as OSPFv2 Type-10 Opaque LSAs and are
flooded by the OSPF control plane.
The information advertised by this mechanism may be operationally
sensitive. It can reveal data-center capacity, GPU inventory,
software versions, resource utilization, and availability.
Falsified, modified, or replayed LSAs can affect computing-aware
routing decisions.
The authentication and integrity protection mechanisms used for
normal OSPF LSA exchanges MUST also be applied to Computing
Capability LSAs. A router MUST accept Computing Capability LSAs only
from trusted OSPF neighbors. Operators SHOULD apply appropriate
filtering, scoping, and operational policy to limit the distribution
of these LSAs to the intended OSPF area and to trusted control-plane
participants.
OSPF authentication does not provide confidentiality or protection
against traffic analysis. Operators that consider the advertised
computing capability information sensitive SHOULD use deployment-
level isolation, trusted control-plane environments, and other
appropriate mechanisms to protect confidentiality. Operators SHOULD
Li, et al. Expires 7 January 2027 [Page 16]
Internet-Draft OSPF-TE Compute Info July 2026
isolate tenant-facing OSPF sessions from internal control-plane OSPF
sessions, for example through separate processes, instances, areas,
or virtual routing contexts.
Implementations MUST validate all TLV and sub-TLV lengths before
parsing. A malformed TLV or sub-TLV MUST NOT cause the receiver to
reject the entire LSA unless required by normal OSPF processing.
Implementations SHOULD log malformed Computing Capability LSAs to
support operational diagnosis and to reduce the risk of control-plane
resource exhaustion.
Operators SHOULD ensure that all entities that collect, translate,
originate, receive, or flood Computing Capability LSAs are mutually
trusted and that their configuration is protected from unauthorized
modification.
9. IANA Considerations
IANA is requested to allocate a new OSPFv2 Opaque LSA Opaque Type for
COMPUTING-CAPABILITY-OPAQUE-TYPE from the "Opaque Link-State
Advertisements (LSA) Option Types" registry. For clarity, the
existing Opaque Types and the requested new allocation are listed
below:
Li, et al. Expires 7 January 2027 [Page 17]
Internet-Draft OSPF-TE Compute Info July 2026
+=======+========================================+===========+
| Value | Opaque Type | Reference |
+=======+========================================+===========+
| 1 | Traffic Engineering LSA | RFC3630 |
+-------+----------------------------------------+-----------+
| 2 | Sycamore Optical Topology Descriptions | John_Moy |
+-------+----------------------------------------+-----------+
| 3 | grace-LSA | RFC3623 |
+-------+----------------------------------------+-----------+
| 4 | Router Information (RI) | RFC7770 |
+-------+----------------------------------------+-----------+
| 5 | L1VPN LSA | RFC5252 |
+-------+----------------------------------------+-----------+
| 6 | Inter-AS-TE-v2 LSA | RFC5392 |
+-------+----------------------------------------+-----------+
| 7 | OSPFv2 Extended Prefix Opaque LSA | RFC7684 |
+-------+----------------------------------------+-----------+
| 8 | OSPFv2 Extended Link Opaque LSA | RFC7684 |
+-------+----------------------------------------+-----------+
| 9 | TTZ LSA | RFC8099 |
+-------+----------------------------------------+-----------+
| 10 | OSPFv2 Dynamic Flooding Opaque LSA | RFC9667 |
+-------+----------------------------------------+-----------+
| 11 | OSPFv2 Extended Inter-Area ASBR (EIA- | RFC9350 |
| | ASBR) LSA | |
+-------+----------------------------------------+-----------+
| 12 | Computing Capability LSA (COMPUTING- | (This |
| | CAPABILITY-OPAQUE-TYPE) | document) |
+-------+----------------------------------------+-----------+
Table 3
IANA is requested to create a new "OSPF Computing Capability TLVs"
registry with the following initial allocations:
+=======+=====================================+=================+
| Value | Name | Reference |
+=======+=====================================+=================+
| 1 | AIDC GPU Basic Information TLV | (This document) |
+-------+-------------------------------------+-----------------+
| 2 | AIDC GPU Performance TLV | (This document) |
+-------+-------------------------------------+-----------------+
| 3 | AIDC Global Compute Performance TLV | (This document) |
+-------+-------------------------------------+-----------------+
Table 4: OSPF Computing Capability TLVs
Li, et al. Expires 7 January 2027 [Page 18]
Internet-Draft OSPF-TE Compute Info July 2026
IANA is requested to create a new "OSPF AIDC GPU Attribute Sub-TLVs"
registry with the following initial allocations:
+=======+======================================+=================+
| Value | Name | Reference |
+=======+======================================+=================+
| 1 | GPU Vendor | (This document) |
+-------+--------------------------------------+-----------------+
| 2 | GPU Model | (This document) |
+-------+--------------------------------------+-----------------+
| 3 | GPU-associated Link-Layer Protocol | (This document) |
+-------+--------------------------------------+-----------------+
| 4 | GPU-associated Transport Protocol | (This document) |
+-------+--------------------------------------+-----------------+
| 5 | Operating System | (This document) |
+-------+--------------------------------------+-----------------+
| 6 | GPU Driver Version | (This document) |
+-------+--------------------------------------+-----------------+
| 7 | GPU Computing Framework | (This document) |
+-------+--------------------------------------+-----------------+
| 8 | GPU Collective Communication Library | (This document) |
+-------+--------------------------------------+-----------------+
Table 5: OSPF AIDC GPU Attribute Sub-TLVs
10. References
10.1. Normative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, October 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
Li, et al. Expires 7 January 2027 [Page 19]
Internet-Draft OSPF-TE Compute Info July 2026
[I-D.hu-ccamp-onco-control-framework]
Hu, Q., Han, Z., and Y. Tan, "A Control Framework for
Optical Networks and AI Computing Orchestration (ONCO)",
Work in Progress, Internet-Draft, draft-hu-ccamp-onco-
control-framework-02, 2026,
<https://datatracker.ietf.org/doc/html/draft-hu-ccamp-
onco-control-framework-02>.
Authors' Addresses
Ao Li
China Unicom
Email: lia12@chinaunicom.cn
Tianhe Liu
Beijing University of Posts and Telecommunications
Email: theo@bupt.edu.cn
Yanlei Zheng
China Unicom
Email: zhengyanlei@chinaunicom.cn
Li, et al. Expires 7 January 2027 [Page 20]