OSPF-TE Extensions for Computing Capability Advertisement

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 describes a control framework in which optical network resources and AI computing resources are coordinated across management, control, and data planes. In such 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 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.

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

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.

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.

Computing Capability Opaque LSA

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: Top-Level Computing Capability TLVs

Type	TLV
1	AIDC GPU Basic Information TLV
2	AIDC GPU Performance TLV
3	AIDC Global Compute Performance TLV

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.

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.

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.

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:

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.

Top-Level TLVs

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.

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 . 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.

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 . GPU Attribute Sub-TLVs

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

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.

GPU Vendor Sub-TLV 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.

GPU Model 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.

GPU-associated Link-Layer Protocol 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.

GPU-associated Transport Protocol 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.

Operating System 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.

GPU Driver Version 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.

GPU Computing Framework 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.

GPU Collective Communication Library 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.

AIDC GPU Performance TLV The AIDC GPU Performance TLV describes dynamic or frequently updated GPU performance information for a specific AIDC and GPU Type.

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. 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.

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.

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. 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.

LSA Origination and Processing

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.

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.

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. 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. 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.

Computing Capability Advertisement Use Case

Security Considerations The security considerations of OSPFv2 and OSPF-TE 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 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.

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:

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-ASBR) LSA	RFC9350
12	Computing Capability LSA (`COMPUTING-CAPABILITY-OPAQUE-TYPE`)	(This document)

IANA is requested to create a new "OSPF Computing Capability TLVs" registry with the following initial allocations: OSPF Computing Capability TLVs

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)

IANA is requested to create a new "OSPF AIDC GPU Attribute Sub-TLVs" registry with the following initial allocations: OSPF AIDC GPU Attribute Sub-TLVs

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)