Applying AC and TE YANG Models to Neotec Edge AI Use Case

Abstract

This document explores how existing IETF YANG models, specifically the Attachment Circuit (AC) and Traffic Engineering (TE) topology models, can be applied to support a representative Neotec use case involving dynamic AI model placement at Edge Cloud sites. The use case, derived from China Telecom's Neotec side meeting at IETF 122, involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG models to query bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model suitability and identify potential gaps. The goal is to inform future work under the proposed Neotec Working Group.¶

2. Conventions used in this document

Cloud Manager:

The Cloud Manager is primarily responsible for Placing workloads, Managing compute resources across Edge Cloud sites, Monitoring the health and scaling status of VMs, containers, or services, Making application-level decisions (e.g., where to place a function based on latency, CPU, GPU availability), etc..¶

Orchestrator:

network service orchestrator, which is responsible for making multi-domain, multi-technology decisions, Stitching together network connectivity (e.g., L2/L3 VPNs, SR paths, or tunnels),provisioning and managing, network slices, or TE tunnels¶

Network Controller:

Works within a single network domain (e.g., an IP/MPLS core or a DC fabric). Knows detailed TE topology, link state, and path attributes. Takes instructions from the orchestrator and programs routers/switches using protocols like BGP, NETCONF, or PCEP.¶

UE:

User Equipment¶

UPF:

User Plane Function [TS.23.501-3GPP]¶

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. YANG Models and APIs to Support Dynamic AI Model Placement

In this use case, multiple Edge Cloud sites are located in close geographic proximity, allowing any of them to potentially host AI inference model instances for city surveillance tasks such as traffic congestion detection or garbage classification. The Cloud Manager must evaluate the end-to-end data paths between the street-level cameras and each Edge Cloud site to determine which sites offer sufficient compute resources and the required network performance (e.g., low latency and high throughput). This assessment enables dynamic placement of AI inference models in response to real-time events while ensuring reliable data delivery from the field.¶

This path typically spans three segments. The first is the access segment from the cameras local access node, such as a WiFi Access Point or an eNB, to a PE router. The second segment traverses the provider transport network between that Access PE and the PE router serving the candidate Edge Cloud site. The third segment connects that Edge PE to the Edge Cloud Gateway or compute node where the AI workload is deployed.¶

There are two primary types of access connectivity for the cameras: via cellular networks (e.g., through eNBs/gNBs and UPFs) or via WiFi Access Points. In cellular based access, cameras connect to the network through eNBs, which forward user data to User Plane Functions (UPFs) vir GTP-U tunnels. The UPFs serve as termination points for GTP-U tunnels and are often co-located with or adjacent to Edge Cloud sites. When the Cloud Manager selects Edge Cloud sites for hosting AI inference modules, it must ensure that the corresponding nearby UPFs are assigned as the serving UPFs for the associated eNBs. This enables the establishment of GTP-U tunnels from the eNBs directly to the selected Edge Cloud locations, minimizing latency and improving efficiency for real-time AI processing.¶

For cameras connected through WiFi Access Points, no GTP tunneling is involved. These access points typically connect to PE routers through Layer 2 or Layer 3 links. In this case, the Attachment Circuit (AC) YANG model can be directly used to represent the logical connectivity between the WiFi AP and the Access PE. The Cloud Manager or orchestrator can query the AC model to evaluate operational status, available bandwidth, latency, and packet loss, and determine whether the path is capable of supporting the target AI workload.¶

In both access scenarios, after determining viable Edge Cloud sites, the Cloud Manager must also evaluate the transport network (Segment 2) between the access side PE (or the PE adjacent to the UPF) and the Edge side PE. This segment is typically traffic engineered and can be modeled using the IETF TE topology model [RFC8795] and the TE tunnel model [RFC8776]. These models expose metrics such as available bandwidth, TE delay, and administrative attributes, which the orchestrator can use to assess whether the transport paths meet the end to end SLA constraints.¶

Finally, the last segment (Segment 3: from the Edge PE to the Edge Cloud Gateway or compute node) is again modeled using the AC YANG model. By combining insights from the AC and TE models across all three segments, the Cloud Manager and orchestrator can select Edge Cloud sites that not only have available compute capacity but also meet the network performance requirements to support low latency, high bandwidth AI model inference.¶

                         +---------------------+
                         |     Street Cameras  |
                         +---------------------+
                             /             \
                            /               \
            (Cellular Access)           (WiFi Access)
                          /                 \
                    +--------+         +-------------+
                    |  eNB   |         |  WiFi AP   |
                    +--------+         +-------------+
                          |                   |
                          |                   |
            +----------------------+    +----------------------+
            |        UPF           |    |    Access PE Router  |
            +----------------------+    +----------------------+
                    |                             |
                    |       Segment 1             |
                    |<--------------------------->|
                            (Access Segment)

                            \                 /
                             \               /
                              \             /
                            +----------------------+
                            |  Provider Transport   |
                            |     Network (TE)      |
                            +----------------------+
                                        |
                             Segment 2  | (PE-to-PE)
                                        v
                          +---------------------------+
                          |   Edge PE Router (per site)|
                          +---------------------------+
                                        |
                                        |
                           Segment 3    v
                                 +--------------------+
                                 |  Edge Cloud Gateway|
                                 |  + AI Model Module |
                                 +--------------------+

For the first and third segments, the Attachment Circuit (AC) YANG model, defined in [opsawg-teas-attachment-circuit], provides a standardized abstraction of the logical link between a service access point and the provider's routing infrastructure. This model allows the Cloud Manager to retrieve configuration and operational status of these links, including encapsulation type, bandwidth, and link status. By querying this information, the orchestrator can determine whether each access circuit is operational and capable of delivering real-time video streams to or from the AI inference point.¶

The second segment, the PE to PE transport path across the provider network, requires querying a different set of YANG models. The base network and topology models defined in [RFC8345] provide the foundation, while the Traffic Engineering Topology model [RFC8795] adds details such as TE metrics, link delay, bandwidth availability, and administrative constraints. These models are typically maintained by network controllers and made accessible via NETCONF or RESTCONF interfaces. The Cloud Manager can use this information to assess the performance characteristics of available transport paths between PEs. In addition, the orchestrator may use the TE Tunnel model [RFC8776] to discover existing LSPs or establish new traffic engineered paths. In architectures using PCE, path queries can also be issued via PCEP or a REST API to identify optimal transport paths that meet performance policies.¶

By combining the Attachment Circuit and TE topology models, the Cloud Manager can construct an end to end view of network connectivity from each camera access point to every potential Edge Cloud site. It can then select the subset of Edge Cloud locations that not only have sufficient computing resources but also meet the required network performance criteria for serving the selected set of street cameras. This allows dynamic, network aware placement of AI inference models, ensuring efficient use of edge infrastructure while meeting service quality requirements.¶

GET https://<controller>/restconf/data/ietf-ac:attachment-circuits
/ac[pe-address='192.0.2.11']

{
  "ietf-ac:ac": [
    {
      "name": "ac-to-eNB-001",
      "pe-address": "192.0.2.11",
      "ce-interface": "ge-0/0/1",
      "oper-status": "up",
      "admin-status": "enabled",
      "encapsulation-type": "dot1q",
      "bandwidth": {
        "configured": 1000,
        "available": 850,
        "unit": "Mbps"
      },
      "performance-metrics": {
        "latency": {
          "average": 5,
          "max": 10,
          "unit": "ms"
        },
        "packet-loss": {
          "percentage": 0.01
        }
      }
    }
  ]
}

GET https://<controller>/restconf/data/ietf-te-topology:te-topologies
/topology=default/te-node=PE1

{
  "te-links": [
    {
      "name": "PE1-to-PE5",
      "link-id": "link-001",
      "oper-status": "up",
      "te-default-metric": 30,
      "te-bandwidth": {
        "max-link-bandwidth": 10000,
        "available-bandwidth": 7000,
        "unit": "Mbps"
      },
      "delay": {
        "unidirectional-delay": 8,
        "unit": "ms"
      },
      "adjacent-te-node-id": "PE5"
    }
  ]
}

4. Potential APIs for Kubernetes to Query Network Conditions

This section outlines a potential Neotec API interface to enable Kubernetes (or its external workload orchestrators) to make network-aware workload placement decisions, such as selecting appropriate Edge Cloud sites for deploying latency-sensitive AI inference modules.¶

Cloud-native platforms such as Kubernetes do not consume YANG-modeled data directly. Instead, they rely on REST-style APIs or gRPC interfaces with JSON or protobuf-encoded payloads. To support Neotec use cases, the network infrastructure can expose an abstracted API that translates YANG-modeled topology and performance data into a form consumable by Kubernetes or its scheduling extensions.¶

A representative Neotec API endpoint could take the form:¶

GET /network-advisor/query-path-performance?
source-node=<access-node-id>&target-node=<edge-site-id>

This API allows Kubernetes to query the performance of the network path between a street camera's access node (e.g., a WiFi AP or eNB/UPF) and a candidate Edge Cloud site. The API response includes metrics such as available bandwidth, average path latency, and operational status. A sample response might be:¶

{
  "source-node": "AP-235",
  "target-node": "EdgeSite-4",
  "path-latency-ms": 6.5,
  "available-bandwidth-mbps": 920,
  "path-status": "healthy"
}

5. Dynamic UCMP Load Balancing for Periodic Inter Site AI Traffic

In the Neotec use case described in Section 1, AI inference modules are deployed across four Edge Cloud sites to support distributed city surveillance. These modules periodically exchange large volumes of data, for instance, during result aggregation or synchronized event analysis. These data exchanges are not continuous but are periodic and event driven, requiring guaranteed bandwidth and low latency for short time windows.¶

The underlying network connecting these Edge Cloud sites typically includes multiple paths between nodes. These paths are pre-established during network provisioning and may be realized using technologies such as SRv6, SR-MPLS, MPLS-TE, or enhanced IP forwarding. However, by default, routers forward traffic across these paths using Equal-Cost Multipath (ECMP), which spreads traffic evenly without regard for service-specific requirements.¶

When AI data exchange events are triggered, it is critical that the AI flows receive prioritized and efficient use of the available transport capacity. This cannot be guaranteed under ECMP. Instead, the network must support UCMP (Unequal Cost Multipath), which allows traffic to be distributed unevenly across multiple paths based on their real time bandwidth and latency characteristics.¶

To enable this behavior, the Cloud Manager or AI Service Controller must be able to dynamically trigger a change in the traffic distribution policy, activating UCMP across all routers involved in the paths connecting the Edge sites. This UCMP behavior should be time bound, applying only during the data exchange window, after which the network should revert to its default behavior.¶

POST /network-policy/ucmp-activation
{
  "source-sites": ["EdgeSite-A", "EdgeSite-B"],
  "dest-sites": ["EdgeSite-C", "EdgeSite-D"],
  "start-time": "2025-05-01T10:00:00Z",
  "duration-sec": 300,
  "min-bandwidth-mbps": 5000,
  "max-latency-ms": 10
}

sr-policy {
  color 4001;
  endpoint "2001:db8:100::1";
  candidate-paths {
    preference 100;
    path {
      weight 70;
      sid-list [2001:db8:10::1, 2001:db8:11::2];
    }
    path {
      weight 20;
      sid-list [2001:db8:20::1, 2001:db8:21::2];
    }
    path {
      weight 10;
      sid-list [2001:db8:30::1, 2001:db8:31::2];
    }
  }
}

6. Gaps Between Existing IETF Specifications and Neotec Use Case Needs

The Neotec use case, supporting real time, event driven placement and coordination of AI inference workloads across Edge Cloud sites, requires close interaction between cloud orchestration platforms and programmable transport networks. While IETF has standardized robust YANG models for traffic engineering (e.g., ietf-te-topology, ietf-sr-policy, and ietf-ac), these models are network-internal, and fall short in addressing cloud-driven, time-scoped network adaptation requirements.¶

This document evaluates two core capabilities against existing IETF YANG models:¶

- Network-aware workload placement at Edge sites¶

- Dynamic UCMP policy activation for inter-site AI data exchange¶

From these exercises, the following gaps have been identified:¶

7. Need for Technology-Agnostic Modeling and Justification for a Separate Neotec WG

The modeling challenges discussed in Section 6 highlight the need for standardized mechanisms that enable dynamic coordination between cloud service platforms and transport networks. These requirements are not specific to any one transport technology (e.g., SRv6, SR-MPLS, MPLS-TE, or native IP), but instead call for common, technology agnostic abstractions that can be applied across diverse deployments.¶

Existing IETF working groups, such as TEAS, SPRING, IDR, and OPSAWG, are focused on protocol specific data modeling and operational behavior. While these groups have developed rich YANG models for their respective technologies, they are not scoped to define cross domain control inputs or service layer integration mechanisms that enable the network to adapt dynamically based on evolving service demands.¶

The proposed Neotec Working Group provides a focused venue to address this gap. Neotec's scope includes:¶

- Defining transport independent policy triggers and control inputs that allow applications and orchestration platforms to request network behavior aligned with workload demands (e.g., bandwidth guarantees, latency constraints, traffic prioritization).¶

- Developing modular YANG model extensions to allow temporary, per-service adjustments to traffic treatment across existing underlay technologies.¶

- Specifying interoperable API interfaces consistent with the approach outlined in the Neotec API strategy [neotec-api-strategy], where IETF documents define the API behavior and semantics, and developer-facing details (e.g., OpenAPI specifications) are maintained via open-source collaboration.¶

- Establishing a framework for policy lifecycle management, including activation, expiration, and real-time status feedback, to support cloud-network coordination at runtime.¶

By concentrating on service-driven, SLA-sensitive network behavior, Neotec aims to bridge the operational divide between cloud-native service orchestration and IETF-modeled transport infrastructure. its output will support reusable, vendor-neutral interfaces applicable across technologies and adaptable to dynamic service changes.¶

A dedicated WG will prevent fragmented development across protocol specific groups and promote architectural consistency. It will also provide a platform for broader engagement, enabling collaboration with the Kubernetes ecosystem, open source orchestration projects, and network operator communities. Neotec documents may explore solution frameworks and prototype workflows that extend the applicability of existing IETF models rather than replacing them.¶

Ultimately, Neotec seeks to define complementary APIs and interaction patterns that strengthen the cloud-network interface, enabling effective, scalable coordination of service placement, network telemetry, and policy enforcement across domains.¶

8. Security Considerations

To be added¶

9. IANA Considerations

None¶

10. References

Contributors