| Internet-Draft | OSPF-TE Compute Info | July 2026 |
| Li, et al. | Expires 7 January 2027 | [Page] |
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.¶
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 (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.¶
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 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.¶
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.¶
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.¶
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.¶
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 |
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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]¶
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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 |
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.¶
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.¶
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.¶
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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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.¶
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.¶
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.¶
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 |
+--------+ +-----------------+
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 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 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:¶
| 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:¶
| 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) |