onsen L. Contreras Internet-Draft Telefonica Intended status: Informational N. Cocker Expires: 6 May 2027 Red Hat 2 November 2026 Abstractions for Telco-Cloud Scenarios draft-lcnc-onsen-telco-cloud-01 Abstract Cloud infrastructures are becoming increasingly distributed, spanning centralized facilities and distributed edge sites, all of them interconnected through networks from one or more administrative domains. Services running on top of such computing enironments require dynamic placement, admission control, lifecycle management, and coordinated scaling across sites, requiring proper allocation and operation of both compute and network resources in order to preserve the required expectations from customers and providers. Existing orchestration systems often depend on fragmented visibility of infrastructure resources (in both compute and network domains) and must interact with multiple management systems before determining service feasibility. This document discusses the role of network abstractions in Telco- Cloud environments benefiting the interplay and operation of cloud and network domains, building up a truly operational Telco-Cloud approach. It identifies abstraction dimensions that can simplify service orchestration while enabling scalable operation across heterogeneous network and cloud infrastructures. 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 6 May 2027. Contreras & Cocker Expires 6 May 2027 [Page 1] Internet-Draft Abstractions for Telco-Cloud November 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Distributed Infrastructure . . . . . . . . . . . . . . . 4 3.2. Joint Network and Compute Decisions . . . . . . . . . . . 5 3.3. Dynamic Service Lifecycle . . . . . . . . . . . . . . . . 5 4. Abstractions for Telco-Cloud . . . . . . . . . . . . . . . . 6 4.1. Abstraction Dimensions . . . . . . . . . . . . . . . . . 6 4.2. Abstraction Function . . . . . . . . . . . . . . . . . . 7 4.3. Consumption of Abstractions . . . . . . . . . . . . . . . 8 5. Security and Operational Considerations . . . . . . . . . . . 8 5.1. Information exposure control . . . . . . . . . . . . . . 8 5.2. Inference and aggregation risk . . . . . . . . . . . . . 8 5.3. Authentication and authorization . . . . . . . . . . . . 9 5.4. Trust boundaries . . . . . . . . . . . . . . . . . . . . 9 5.5. Integrity and freshness . . . . . . . . . . . . . . . . . 9 5.6. Availability . . . . . . . . . . . . . . . . . . . . . . 9 5.7. Multi-tenancy isolation . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The evolution of cloud-native networking and distributed cloud infrastructures is transforming how telecommunication services are deployed and operated. Telco-Cloud environments combine networking, computing, storage, and application resources distributed across multiple locations, including central data centers, edge sites, and highly distributed far-edge locations. Contreras & Cocker Expires 6 May 2027 [Page 2] Internet-Draft Abstractions for Telco-Cloud November 2026 Emerging services require deployment decisions that simultaneously consider networking and computing characteristics. In this context, current service orchestration workflows frequently rely on interactions with multiple cloud managers, network controllers, monitoring systems, and inventory repositories. Such interactions introduce complexity and can delay admission control and service instantiation processes. Proper network abstractions can provide simplified and consistent views of compute and network infrastructure capabilities that enable orchestration systems to make informed decisions without requiring exposure to detailed implementation information. This document examines the requirements and architectural considerations for network abstractions in Telco-Cloud scenarios. 2. Terminology This documents makes use of the following terminology: * Telco-Cloud: Distributed cloud infrastructure supporting network and IT workloads, being interconnected through one or more network domains. * Edge Site: Compute and networking resources deployed closer to users or data sources. * Abstraction: Representation of infrastructure capabilities and constraints while hiding implementation details. The abstractions apply to both compute and networking resources * Abstraction Consumer: the entity that consumes one or more abstracted views of resource domains to support service placement, lifecycle management, or operational decisions. A Service Orchestrator is one possible Abstraction Consumer. * Abstracted View: a representation of selected capabilities, constraints, and dynamic conditions of one or more resource domains, while hiding internal implementation details not required by the consumer. * Resource Domain: Administrative or technological domain exposing networking, computing, storage or application resources. * Service Orchestrator: Entity responsible for service lifecycle management and placement decisions. Contreras & Cocker Expires 6 May 2027 [Page 3] Internet-Draft Abstractions for Telco-Cloud November 2026 3. Motivation Telco network and cloud computing facilities are nowadays managed in a fully decoupled way. Existing Telco-Cloud orchestration frameworks typically retrieve information from multiple independent systems responsible for networking, cloud infrastructure, observability, and policy management. This creates a number of challenges, which include * Fragmented resource visibility. * Limited support for cross-domain (i.e., compute and network) resource optimization (if any). * Scalability constraints due to the impossibility of coordinating actions. * Exposure of excessive implementation details in situations when it is possible to expose information. * Difficult or not possible coordinated actions in situations of failure or service affection in any of the domains (i.e., outages, resource congestion or exhaustion, etc). * Difficulties in supporting federation across multiple domains on the compute or the network side (alone or together). (Note. The initial approach of this document concetrates on single administrative domain for both cloud and network domains. Other scenarios are left for further study). A common abstraction framework capable of representing networking, compute and infrastructure capabilities may reduce these limitations. 3.1. Distributed Infrastructure Telco-Cloud deployments may be comprised of different compute facilities and networks segments interconnecting them. All that infrastrcuture can span hundreds or thousands of resource locations with different capabilities and ownership models. The applications to be deployed and consumed on such rich infrastrcuture will leverage on service orchestrator for instantiation, migration, scaling, operation, etc. Service orchestrators require mechanisms to discover and consume infrastructure information without maintaining detailed knowledge of every resource. Contreras & Cocker Expires 6 May 2027 [Page 4] Internet-Draft Abstractions for Telco-Cloud November 2026 It is in that point where proper abstractions can serve the purpose of facilitating orchestration and operation in a number of situations, as described in next sub-sections. 3.2. Joint Network and Compute Decisions Application placement decisions are increasingly dependent on both networking and computing conditions. Examples of that include aspects such as latency-constrained AI inference, dynamic deployment of user plane functions, event-driven content delivery services, or industrial edge applications, for naming a few. In such scenarios, network information cannot be considered independently from compute resource availability. Constraints in both domains have to be taken into account to ensure that decisions are aware of conditions impacting the final service. 3.3. Dynamic Service Lifecycle Modern cloud-native workloads scale dynamically according to the changing needs of a service. The virtualized nature of the applications supporting the services allow for dynamic re-sizing based on different performance or service-related parameters (e.g., number of sessions). Scaling actions may require changes due to either network or compute needs, such as increased throughput, alternative network paths, new service endpoints, or migration of workloads among sites. Telco-Cloud abstractions may be required at different stages of the service lifecycle. During initial service deployment, abstracted information can support admission control, candidate-site selection and workload placement (not only in terms of computing resources but also taking into consideration connectivity performance). Once the service is deployed and operational, however, lifecycle adaptations such as scaling, relocation, redundancy, recovery, or connectivity changes may be triggered at runtime. That is, abstractions are needed to support not only initial service placement but also runtime decisions driven by changes in resource availability, service demand, network conditions, or operational policies, in a way that the management systems on each domain can react and adapt to new conditions. Abstracted Views used for the service lifecycle need to reflect relevant information in the underlying resource domains with sufficient freshness for the decisions they support. Runtime adaptation may be performed by the same entity that performed the initial placement or by another authorized Abstraction Consumer. Contreras & Cocker Expires 6 May 2027 [Page 5] Internet-Draft Abstractions for Telco-Cloud November 2026 4. Abstractions for Telco-Cloud Distinct kind of abstractions could be required for supporting a more integrated Telco-Cloud solution. Some example use cases demanding those abstractions are: * Edge Artificial Intelligence: dynamic placement of AI inference functions according to latency and resource constraints. * Distributed User Plane Functions: placement and scaling of UPFs according to user demand and network conditions. * Industrial Applications: deployment of industrial workloads requiring deterministic performance and local processing. * Immersive and/or low-latency application: consideration of latency, bandwidth and compute processing combining network and cloud capabilities. 4.1. Abstraction Dimensions The following list presents a set of needed abstractions identified so far as necessary for such use cases. * Connectivity abstractions: these abstractions can represent communication reachability, latency ranges, bandwidth availability, resilience characteristics, and traffic engineering capabilities. * Compute abstractions: these abstractions represent available compute, storage, acceleration, and cloud capabilities. * Service abstractions: these ones focus on service capabilities in terms directly usable by orchestration systems (e.g., particularities of the service such as the location of the data or the model to be used in the case of AI inference, the number of sessions supported by an UPF instance, the geolocation of the user for a low-latency application, etc). * Policy abstractions: they represent administrative constraints, operational policies, business rules, and optimization objectives. * Location abstractions: these are associated to geographical and topological relations relevant for service placement decisions. * Other meaningful abstractions: to be defined (e.g., energy-related information, etc). Contreras & Cocker Expires 6 May 2027 [Page 6] Internet-Draft Abstractions for Telco-Cloud November 2026 Such abstractions could require to represent aspects such as capability (i.e., what a resource domain or candidate location can provide), availability (i.e., whether the required capability can currently be provided) and freshness (i.e., indication that the abstracted information remains valid for the decision for which it is being consumed), or help to derive operational insights as resiliency level (i.e., existence of alternatives making possible to maintain the service even when certain conditions change). 4.2. Abstraction Function From an architectural perspective it can be considered that an abstraction function is in place to collect and expose information from multiple network and cloud infrastructure domains, generating the abstracted views useful for the Telco-Cloud service rchestration and operation. The abstraction function could be a single component or a number of components offering the desired functionality. As possible information sources it could be considered that the abstraction function interacts (by means of APIs or standardized interfaces) with network telemetry systems, cloud management platforms, service inventories, topology repositories, SDN controllers or different observability platforms. +-----------------------------------------------------------+ | Service Orchestrator | +-----------------------------------------------------------+ ^ | Abstracted views | (connectivity, compute, | service, policy, location) v +-----------------------------------------------------------+ | Abstraction Function | | (single or multiple components) | +-----------------------------------------------------------+ ^ ^ ^ ^ ^ ^ | APIs / standardized interfaces | v v v v v v +---------+ +--------+ +--------+ +--------+ +-----+ +--------+ | Network | | Cloud | |Service | |Topology| | SDN | |Observ. | |Telemetry| | Mgmt. | |Invent. | | Repos. | |Ctrl.| |Platf. | +---------+ +--------+ +--------+ +--------+ +-----+ +--------+ Figure 1: Abstraction Function reference model Contreras & Cocker Expires 6 May 2027 [Page 7] Internet-Draft Abstractions for Telco-Cloud November 2026 Figure 1 illustrates the reference positioning of the abstraction function between the service orchestrator and the underlying resource domains. The definition of such abstraction function is out of scope of this document. 4.3. Consumption of Abstractions The way in which the abstractions are consumed could defer during the lifecycle of services in the telco-cloud. On one hand, for the initial deployment, an Abstraction Consumer may retrieve an Abstracted View to discover and evaluate candidate resources, following a query-driven use of the abstraction. On the other hand, at runtime, changes in the underlying infrastructure may require adaptation at different time scales making an Abstraction Consumer needing to become aware of relevant changes in a given Abstracted View, then requiring event-driven consumption. 5. Security and Operational Considerations Abstractions must avoid exposing sensitive infrastructure information while still providing meaningful visibility to service orchestration entities. The abstraction function described in this document collects information from multiple network and cloud resource domains and exposes derived views to service orchestration entities. This position, between the resource domains and their consumers, raises a number of security considerations. 5.1. Information exposure control Abstractions MUST avoid disclosing sensitive infrastructure details (e.g., exact topology, addressing, capacity, or tenant identities) while still providing views that are meaningful for placement and lifecycle decisions. The level of detail exposed should reveal only the information required by the consuming orchestrator. 5.2. Inference and aggregation risk Even when individual attributes are abstracted, a consumer observing abstracted views over time may infer sensitive properties of the underlying infrastructure, such as real capacity, topology, or the presence of specific tenants. The design of abstractions should consider aggregation, generalization, and rate limiting to mitigate such inference. Contreras & Cocker Expires 6 May 2027 [Page 8] Internet-Draft Abstractions for Telco-Cloud November 2026 5.3. Authentication and authorization Access to abstracted views MUST be authenticated and authorized. Different consumers may be entitled to different levels of abstraction; the abstraction function is responsible for enforcing per-consumer access policies and for preventing a consumer from obtaining views beyond its authorization scope. 5.4. Trust boundaries When information originates from several administrative or technological domains, the abstraction function acts as a trust boundary between producers and consumers. The authenticity and integrity of the information received from source systems (telemetry, controllers, inventories, etc.) should be protected, so that abstracted views are not derived from tampered or spoofed inputs. 5.5. Integrity and freshness Placement and scaling decisions rely on the correctness of abstracted views. Stale or manipulated views may lead to incorrect decisions with operational impact (e.g., admission of a service that cannot actually be supported). Mechanisms to ensure integrity, provenance, and freshness of the exposed information should therefore be considered. 5.6. Availability The abstraction function may become a single point of failure or a target for denial-of-service attacks, since multiple orchestration decisions depend on it. Resilience, redundancy, and protection against resource-exhaustion attacks should be taken into account, particularly when the function is realized as a single component. 5.7. Multi-tenancy isolation Where a single abstraction function serves multiple tenants or orchestration domains, isolation between the views provided to each of them MUST be preserved, avoiding cross-tenant leakage of infrastructure or service information. 6. IANA Considerations This document has no IANA actions. Contreras & Cocker Expires 6 May 2027 [Page 9] Internet-Draft Abstractions for Telco-Cloud November 2026 Acknowledgements TBC Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com Nabeel Cocker Red Hat New York, NY, United States of America Email: ncocker@redhat.com Contreras & Cocker Expires 6 May 2027 [Page 10]