Abstractions for Telco-Cloud Scenarios
draft-lcnc-onsen-telco-cloud-00

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]