onsen L. Contreras Internet-Draft Telefonica Intended status: Informational N. Cocker Expires: 7 January 2027 Red Hat 6 July 2026 Abstractions for Telco-Cloud Scenarios draft-lcnc-onsen-telco-cloud-00 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 true 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 7 January 2027. Contreras & Cocker Expires 7 January 2027 [Page 1] Internet-Draft Abstractions for Telco-Cloud July 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Distributed Infrastructure . . . . . . . . . . . . . . . 4 3.2. Joint Network and Compute Decisions . . . . . . . . . . . 4 3.3. Dynamic Service Lifecycle . . . . . . . . . . . . . . . . 5 4. Abstractions for Telco-Cloud . . . . . . . . . . . . . . . . 5 4.1. Abstraction Dimensions . . . . . . . . . . . . . . . . . 5 4.2. Abstraction Function . . . . . . . . . . . . . . . . . . 6 5. Security and Operational Considerations . . . . . . . . . . . 7 5.1. Information exposure control . . . . . . . . . . . . . . 7 5.2. Inference and aggregation risk . . . . . . . . . . . . . 8 5.3. Authentication and authorization . . . . . . . . . . . . 8 5.4. Trust boundaries . . . . . . . . . . . . . . . . . . . . 8 5.5. Integrity and freshness . . . . . . . . . . . . . . . . . 8 5.6. Availability . . . . . . . . . . . . . . . . . . . . . . 8 5.7. Multi-tenancy isolation . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 7 January 2027 [Page 2] Internet-Draft Abstractions for Telco-Cloud July 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 * Resource Domain: Administrative or technological domain exposing networking, computing, storage or application resources. * Service Orchestrator: Entity responsible for service lifecycle management and placement decisions. 3. Motivation Telco network and cloud computing facilities are nowadays manaed 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, whihc include * Fragmented resource visibility. Contreras & Cocker Expires 7 January 2027 [Page 3] Internet-Draft Abstractions for Telco-Cloud July 2026 * Limited support for cross-domain optimization (if any). * Scalability constraints due to the inmpossibility of coordinating actions. * Exposure of excessive implementation details when it is possible to expose information. * 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 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 leveraage 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. 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 increasingly depend 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. Contreras & Cocker Expires 7 January 2027 [Page 4] Internet-Draft Abstractions for Telco-Cloud July 2026 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. Abstractions must therefore represent changing infrastructure conditions that could allow the management systems on each domain to react and adapt to the new conditions. (Note. Further scenarios of interest will be described in future versions of the document). 4. Abstractions for Telco-Cloud 4.1. Abstraction Dimensions 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. 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. Contreras & Cocker Expires 7 January 2027 [Page 5] Internet-Draft Abstractions for Telco-Cloud July 2026 * 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. * 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). 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. Contreras & Cocker Expires 7 January 2027 [Page 6] Internet-Draft Abstractions for Telco-Cloud July 2026 +-----------------------------------------------------------+ | 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 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. 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. Contreras & Cocker Expires 7 January 2027 [Page 7] Internet-Draft Abstractions for Telco-Cloud July 2026 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. 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. Contreras & Cocker Expires 7 January 2027 [Page 8] Internet-Draft Abstractions for Telco-Cloud July 2026 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. 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 7 January 2027 [Page 9]