Skip to main content

An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness
draft-contreras-coinrg-clas-evolution-03

Document Type Active Internet-Draft (individual)
Authors Luis M. Contreras , Mohamed Boucadair , Diego Lopez , Carlos J. Bernardos
Last updated 2024-07-05
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-contreras-coinrg-clas-evolution-03
COINRG                                                   L. M. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                              M. Boucadair
Expires: 6 January 2025                                           Orange
                                                                D. Lopez
                                                              Telefonica
                                                         C. J. Bernardos
                                        Universidad Carlos III de Madrid
                                                             5 July 2024

  An Evolution of Cooperating Layered Architecture for SDN (CLAS) for
                       Compute and Data Awareness
                draft-contreras-coinrg-clas-evolution-03

Abstract

   This document proposes an extension to the Cooperating Layered
   Architecture for Software-Defined Networking (SDN) by including
   compute resources and data analysis processing capabilities.

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 January 2025.

Copyright Notice

   Copyright (c) 2024 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

Contreras, et al.        Expires 6 January 2025                 [Page 1]
Internet-Draft               CLAS Evolution                    July 2024

   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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Cooperating Layered Architecture for Software-Defined
           Networking (CLAS) . . . . . . . . . . . . . . . . . . . .   3
   4.  Augmentation of CLAS with Compute and Data Analysis
           Awareness . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Compute Stratum . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Knowledge Plane . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Extended CLAS Architecture  . . . . . . . . . . . . . . .   7
   5.  Discussion on Research Aspects of the Proposed
           Architecture  . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Discussion Related to the Compute Stratum . . . . . . . .   9
     5.2.  Discussion Related to the Knowledge plane . . . . . . . .   9
     5.3.  Discussion Related to the Connectivity Stratum  . . . . .  10
     5.4.  Discussion Related to the Service Stratum . . . . . . . .  11
   6.  Applicability scenarios . . . . . . . . . . . . . . . . . . .  11
     6.1.  Cloud-edge Continuum  . . . . . . . . . . . . . . . . . .  11
     6.2.  Network-application Integration . . . . . . . . . . . . .  13
   7.  Communication between strata (and planes) . . . . . . . . . .  13
     7.1.  Communication between Applications and Service Stratum  .  13
     7.2.  Communication between Service Stratum and Connectivity
           Stratum . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.3.  Communication between Service stratum and Compute
           Stratum . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  Communication between Connectivity stratum and Compute
           stratum . . . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  TODO for next versions of this document . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Telecommunication networks are evolving towards a tight integration
   of interconnected compute environments, offering specifically
   capabilities for the instantiation of virtualized network functions
   interworking with physical variants of other network functions,
   altogether used to build and deliver services.

Contreras, et al.        Expires 6 January 2025                 [Page 2]
Internet-Draft               CLAS Evolution                    July 2024

   Moreover, network operations are endorsing automation (e.g.,
   [RFC8969]) and programmability (e.g., [RFC7149][RFC7426]) with the
   introduction of closed-loop mechanisms, intent declarations,
   Artificial Intelligence (AI) and Machine Learning (ML) techniques to
   facilitate informed (proactive) decisions as well as predictive
   behaviors enabling consistent automation.

   It is then necessary to provide a network management framework that
   could incorporate these technical components, structuring the
   different concerns (i.e., connectivity, processing and telemetry data
   generation and analysis) and the interaction among components
   operating the network.  Existing approaches (e.g.  [RFC8969]) only
   focus on the networking aspects (i.e., connectivity) without
   sufficient consideration of both compute domain and data analysis.
   In fact, those current approaches exhibit some limitations whcih
   could require evolutionary paths for future network management
   [I-D.boucadair-nmop-rfc3535-20years-later].

   This document describes an evolution of the Cooperating Layered
   Architecture for Software-Defined Networking (CLAS) [RFC8597] to
   include the aforementioned aspects into the architecture.

2.  Conventions and Definitions

   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.  Cooperating Layered Architecture for Software-Defined Networking
    (CLAS)

   [RFC8597] describes an SDN architecture structured in two different
   strata, namely Service Stratum and Transport Stratum.  On one hand,
   the Service Stratum contains the functions related to the provision
   of services and the capabilities offered to external applications.
   On the other hand, the Transport Stratum comprises the functions
   focused on the transfer of data between the communication endpoints
   (e.g., between end-user devices, between two service gateways, etc.).

   Each of the strata is structured in different planes, as follows:

   *  The Control plane, which centralizes the control functions of each
      stratum and directly controls the corresponding resources.

Contreras, et al.        Expires 6 January 2025                 [Page 3]
Internet-Draft               CLAS Evolution                    July 2024

   *  The Management plane, logically centralizing the management
      functions for each stratum, including the management of the
      control and resource planes.

   *  The Resource plane, that comprises the resources for either the
      transport or the service functions.

   Figure 1 illustrates the original CLAS architecture.

Contreras, et al.        Expires 6 January 2025                 [Page 4]
Internet-Draft               CLAS Evolution                    July 2024

                                         Applications
                                              /\
                                              ||
                                              ||
        +-------------------------------------||-------------+
        | Service Stratum                     ||             |
        |                                     \/             |
        |                       ...........................  |
        |                       . SDN Intelligence        .  |
        |                       .                         .  |
        |  +--------------+     .        +--------------+ .  |
        |  | Resource Pl. |     .        |   Mgmt. Pl.  | .  |
        |  |              |<===>.  +--------------+     | .  |
        |  |              |     .  |  Control Pl. |     | .  |
        |  +--------------+     .  |              |-----+ .  |
        |                       .  |              |       .  |
        |                       .  +--------------+       .  |
        |                       ...........................  |
        |                                     /\             |
        |                                     ||             |
        +-------------------------------------||-------------+
                                              ||    Standard
                                           -- || --    API
                                              ||
        +-------------------------------------||-------------+
        | Transport Stratum                   ||             |
        |                                     \/             |
        |                       ...........................  |
        |                       . SDN Intelligence        .  |
        |                       .                         .  |
        |  +--------------+     .        +--------------+ .  |
        |  | Resource Pl. |     .        |   Mgmt. Pl.  | .  |
        |  |              |<===>.  +--------------+     | .  |
        |  |              |     .  |  Control Pl. |     | .  |
        |  +--------------+     .  |              |-----+ .  |
        |                       .  |              |       .  |
        |                       .  +--------------+       .  |
        |                       ...........................  |
        |                                                    |
        |                                                    |
        +----------------------------------------------------+

    Figure 1: Cooperating Layered Architecture for SDN {{RFC8597}}

Contreras, et al.        Expires 6 January 2025                 [Page 5]
Internet-Draft               CLAS Evolution                    July 2024

4.  Augmentation of CLAS with Compute and Data Analysis Awareness

   The CLAS architecture was initially conceived from the perspective of
   exploiting the advantages of network programmability in operational
   networks.

   The evolution of current networks and the services they support are,
   however, introducing new aspects:

   *  Considerations of distributed computing capabilities attached to
      different points in the network, intended for hosting a variety of
      services and applications usually in a virtualized manner (e.g.,
      [I-D.contreras-alto-service-edge]).

   *  Introduction of evidence-driven techniques, such as Analytics,
      Artificial Intelligence (AI) and Machine Learning (ML) techniques
      in order to improve operations by means of closed loop automation
      (e.g., [I-D.irtf-nmrg-ai-challenges]).

   With that in mind, this memo proposes augmentations to the original
   CLAS architecture by adding the aforementioned aspects.

4.1.  Compute Stratum

   The CLAS architecture is extended by adding a new stratum, named
   Compute Stratum.  This stratum contains the control, management, and
   resource planes related to the computing aspects.  This additional
   stratum cooperates with the other two in order to facilitate the
   overall service provision in the network.

   With this addition, and in order to be more explicit in the strata
   scope, the previously named Transport Stratum is renamed as
   Connectivity Stratum, representing the fact that this stratum
   responsibility is focused on the overall connectivity supporting the
   other two strata in the architecture.

4.2.  Knowledge Plane

   Data Analysis is usually part of the management plane.  In order to
   insist on the data analytics matters, this document defines Knowledge
   as a dedicated plane as it streams sensitive data that is
   instrumental for the CLAS strata.

   A further extension to the original CLAS architecture is related to
   the need of collecting, processing and sharing relevant data and
   information from each of the considered strata.  With that purpose a
   Knowledge plane is proposed to complement the already existing planes
   per stratum.

Contreras, et al.        Expires 6 January 2025                 [Page 6]
Internet-Draft               CLAS Evolution                    July 2024

   The Knowledge plane is in charge of handling the data analytics
   specificities of each stratum.  Thus, the Knowledge plane in the
   Service Stratum is focused on data relevant to the service as defined
   by the application or service owner, usually in terms of service key
   performance indicators (KPI), as for instance in [TMV].  Then, the
   Knowledge plane in the compute stratum concentrates on data related
   to the computing capabilities in use (e.g., CPU load, RAM usage,
   storage utilization, etc)
   [I-D.rcr-opsawg-operational-compute-metrics].  Finally, the Knowledge
   plane in the network stratum is in charge of handling the monitoring
   and telemetry information obtained from the network (e.g.,
   [RFC9418]).

4.3.  Extended CLAS Architecture

   Figure 2 presents the augmentation proposed showing the relationship
   among strata.

                                        Applications
                                              /\
                                              ||
        +-------------------------------------||-------------+
        | Service Stratum                     ||             |
        |                                     \/             |
        |  +--------------+     ...........................  |
        |  | Knowledge    |     . SDN Intelligence        .  |
        |  | Pl.          |<===>.                         .  |
        |  +-----/\-------+     .        +--------------+ .  |
        |        ||             .        |   Mgmt. Pl.  | .  |
        |        ||             .  +--------------+     | .  |
        |  +-----\/-------+     .  |  Control Pl. |-----+ .  |
        |  | Resource Pl. |     .  |              |       .  |
        |  |              |<===>.  +--------------+       .  |
        |  +--------------+     ...........................  |
        |                                /\             /\   |
        |                                ||             ||   |
        +--------------------------------||-------------||---+
                         Standard API -- || --          ||
        +--------------------------------||-----+       ||
        | Compute Stratum                ||     |       ||
        |                                \/     |       ||
        |  +----------+    ...................  |       ||
        |  | Knowledge|    . SDN             .  |  Std. ||
        |  | Plane    |<==>. Intelligence    .  |  API  ||
        |  +-----/\---+    .    +----------+ .  |    -- || --
        |        ||        .    | Mgmt. Pl.| .  |       ||
        |        ||        .  +----------+ | .  |       ||
        |  +-----\/---+    .  | Control  |-+ .  |       ||

Contreras, et al.        Expires 6 January 2025                 [Page 7]
Internet-Draft               CLAS Evolution                    July 2024

        |  | Resource |    .  | Plane    |   .  |       ||
        |  | Plane    |<==>.  +----------+   .  |       ||
        |  +----------+    ...................  |       ||
        +----------------------------------/\---+       ||
                           Standard API -- || --        ||
                       +-------------------||-----------||-----+
                       | Connectivity      ||           ||     |
                       | Stratum           ||           ||     |
                       |                   \/           \/     |
                       |  +----------+    ...................  |
                       |  | Knowledge|    . SDN             .  |
                       |  | Plane    |<==>. Intelligence    .  |
                       |  +-----/\---+    .    +----------+ .  |
                       |        ||        .    | Mgmt. Pl.| .  |
                       |        ||        .  +----------+ | .  |
                       |  +-----\/---+    .  | Control  |-+ .  |
                       |  | Resource |    .  | Plane    |   .  |
                       |  | Plane    |<==>.  +----------+   .  |
                       |  +----------+    ...................  |
                       +---------------------------------------+

                  Figure 2: Extended CLAS architecture

   The relationship among the Connectivity and Compute strata is not
   hierarchical in any sense.  Both are at the same level and there is
   no dependecy of one of them over the other.  A more simplistic
   representation of the different starta is presented in Figure 3 with
   less details regarding the planes for the sake of clarity.

                             Service Stratum
                              A           A
                              |           |
                      --------|-----------|-------
                              |           |
                              V           V
                     Connectivity <---> Compute
                       Stratum          Stratum

       Figure 3: Simple representation of the extended CLAS architecture

5.  Discussion on Research Aspects of the Proposed Architecture

Contreras, et al.        Expires 6 January 2025                 [Page 8]
Internet-Draft               CLAS Evolution                    July 2024

5.1.  Discussion Related to the Compute Stratum

   The inclusion of the Compute Stratum extends the resource layer/plane
   in a manner that the network (i.e., including processing capabilities
   and the associated connectivity) can be programmed consistently and
   in an integrated way.  This is very relevant when evolving to network
   architectures pursuing the could-edge continuum, even considering the
   extension to the very extreme edge.

   Important to note, the aforementioned cloud-edge continuum could be
   potentially constituted by resources from multiple administrative
   domains.  Enabling the management of multiple heterogeneous domains
   in a so-called "frictionless" manner is the necessary to be explored.

   It is also relevant the fact that different cloud management systems
   can be simultaneously in place, for instance OpenStack and
   Kubernetes.  This adds extra complexity to the integration with the
   other two strata, which should deal in principle with different APIs
   and interfaces for interworking.

   One key point related to the cross-strata interplay refers to the
   scheduling of workloads in the cloud-edge continuum.  The decision
   about where to instantiate the different functions or applications
   (for instance, following the micro-service approach in cloud-native
   applications) can be benefited from the information of both
   connectivity and compute domains in order to take optimal decisions
   from the service perspective.

   Finally, even for a single cloud management system, the compute
   stratum can be formed by multiple domains.  This could be teh case of
   multi-cluster systems in Kubernetes.

5.2.  Discussion Related to the Knowledge plane

   One of the aspects to investigate is the application of evidence-
   driven, “smart” management (most notably, based on AI) to network
   management and control.  These considerations are taken place as well
   in other fora [ITU].  There are multiple issues to consider:

   *  Telemetry data generation and context information.

   *  The lifecycle of data flows in the closed loop, in both
      directions,from network to management and vice versa.

   *  The flows controlling the behavior (policies/intents), as defined
      by network admins, and potentially users, towards the management
      elements.

Contreras, et al.        Expires 6 January 2025                 [Page 9]
Internet-Draft               CLAS Evolution                    July 2024

   *  Feedback (i.e., predictions, suggested actions, etc) patterns from
      management elements to network administrators, and users.

   *  Metadata models to represent sources and consumers of data at the
      Knowledge plane, supporting the dynamic attachment of new sources
      and consumers, including data composition elements.

   *  Flow patterns and models facilitating the cooperation among
      distinct Knowledge planes, implying knowledge sharing among
      different segments, and data and knowledge aggregation at
      different strata of control.

   *  Security and privacy issues regarding the usage of data flows,
      considering their provenance and potential attestation methods.

   A potential way to follow is the definition of a common, model-based,
   approach, also defining a recursive structure that could become a
   generalization of the CLAS model.

   Other relevant aspect particular to the knowledge plane is the
   interplay of the decisions that could be take across the distinct
   strata.  Such decisions could collide, so arbitration mechanisms
   could be required for consensus among the knowledge planes in each
   strata.

5.3.  Discussion Related to the Connectivity Stratum

   The consideration of multi-domain scenarios has different
   implications in both connectivity and compute strata.  Thus, a muti-
   domain (i.e., multi-cluster) scenario in the compute strata could
   imply the intercation with just one single domain at connectivity
   stratum level.  In contrast, multi-domain scenarios at the
   connectivity stratum will usually imply multi-domain situation at the
   compute stratum as well.

   Another aspect to solve is the dichotomy between overlay and underlay
   connectivity typically present in cloud-based services.  Cloud
   management systems provide mechanisms for the communications between
   the distinct instances, being such connectivity commonly solved by
   means of overlay connectivity or, at least, without any specific
   traffic engineering in place, precisely due to the lack of
   coordination between the clous and network management systems.  Thus,
   a more integrated functioning of compute and connectivity strata
   could help to sophisticate the communication capabilities of cloud-
   based services.

Contreras, et al.        Expires 6 January 2025                [Page 10]
Internet-Draft               CLAS Evolution                    July 2024

5.4.  Discussion Related to the Service Stratum

   As mentioned before, service instantiation can be highly benefited
   from the availability of metrics and date fo both compute and
   connectivity strata.  However, in order to build a consistent view of
   both, it is necessary to guarantee on one hand that the time
   reference of such information is consistent in both strata, and on
   the othe rhand, that the age of information is sufficiently good for
   the decision to be taken (i.e., to avoid considering past, not valid
   information). thus, mechanisms for efficiently populating and
   processing such information should be in place.

   It should be also noted that current transition to cloud-based
   services makes the compute stratum the natural entry point for
   service instantiation.  Thus, the typical interface (or API) for
   service deployment will be determined by the one available in the
   cloud management system, in contrast with the interface (or API)
   supported by the connectivity stratum.  This could be the case of the
   Custom Resources for Kubernetes in the cloud stratum, versus the YANG
   models for network services in the connectivity stratum.  Proper
   translation and adaptation mechanisms can be required to ensure full
   end-to-end service provision (especially to solve the overlay -
   underlay dichotomy mentioned before).

   Also of relevance is the accounting of resources allocated to the
   service in both connectivity and compute strata.  Resources in each
   strata are of different nature and consistent accounting should be
   defined.

   Finally, when dealing with contextual information and/or metadata, it
   is also possible to distinguish metadata for the service from
   metadata that could be used/required for the supportive compute and
   connectivity infrasrtructure.  Both levels of metadata should be
   consistent to avoid misfunctioning that could impact the service.

6.  Applicability scenarios

   This section describes deployment scenarios suitable for the CLAS
   architecture evolution.

6.1.  Cloud-edge Continuum

   More and more, computing facilities are being deployed by network
   service providers to satisfy a number of use cases requiring of
   distributed compute processing capabilities (e.g., for micro-service
   instantiation), some of them as edge nodes because of the need of
   proximity.  Use cases in [I-D.irtf-coinrg-use-cases] exemplify those
   needs.

Contreras, et al.        Expires 6 January 2025                [Page 11]
Internet-Draft               CLAS Evolution                    July 2024

   Such distributed computing facilities form what is known as cloud-
   edge continuum.  Those distributed facilities need to be
   interconnected for accomplishing end-to-end services, based in the
   interaction of multiple applications of service functions placed in
   different compute nodes for performance or resource efficiency
   reasons.

   Current ways of deploying services follow the cloud-native approach
   of instantiating a set of micro-services that can be located at
   different compute nodes.  Typical cloud management systems such as
   Kubernetes take care of the allocation of cloud-edge resources across
   distinct nodes or clusters.  For the networking part, it is necessary
   to interact with network controllers capable of providing the
   necessary connectivity with certain guarantees.

   The extended CLAS architecture represents a framework where the
   cloud-native resources can be handled in combination with the
   connectivity part, assuring the service not only at the provisioning
   phase but during the complete service lifecycle, and supporting them
   across different domains.

   Features that can expected to be satisfied in this type of scenarios
   are:

   *  Overall resource optimization of system resources at different
      levels (i.e., compute, network, etc).  This can imply a process of
      learning and inferring status based on historical resource usage
      data.

   *  Assurance of Service Level Objectives (SLOs) by acting on either
      the compute or the connectivity parts.  This can motivate the need
      of compute workloads migration along the service lifetime between
      compute nodes, requiring to adapt the connectivity to the new
      placement.

   *  Secure transfer of data across the cloud-edge continuum, with the
      necessary isolation of services among users, and the required
      Confidentiality and integrity properties, which can imply the
      application of isolation capabilities trustworthiness verification
      in both compute and connectivity strata.

Contreras, et al.        Expires 6 January 2025                [Page 12]
Internet-Draft               CLAS Evolution                    July 2024

6.2.  Network-application Integration

   Nowadays applications take service decisions mostly decoupled from
   network status and conditions.  Similarly, the network is not aware
   of applications needs, so that is not possible in certain cases to
   satisfy application needs.  Thus, emerges the need of further
   collaboration or integration between applications and the network.
   [RFC9419] discusses principles for designing mechanisms allowing
   application - network collaboration.

   Such collaboration can proactively or reactively trigger actions in
   the network at run time.  Features that can expected to be satisfied
   in this type of scenarios are:

   *  Monitoring information that could be relevant for either the
      application or the network.  The monitoring information will be a
      composition of information from both compute and connectivity
      strata.

   *  Exposure of capabilities from the network, including (and even
      combining) both the compute and connectivity strata.

   *  Usage of metadata for either the connectivity or the processing of
      the information at service level

7.  Communication between strata (and planes)

   The communication between strata (and the planes within) is
   represented in Figure 2 by means of generic standard APIs.  An
   initial or preliminary analysis of possible means of communicationg
   strata is provided here.

   This is not an exhaustive exercise but an effort to concretize
   examples of communication mechanisms.  Further versions of the
   document will refine this initial exercise.

7.1.  Communication between Applications and Service Stratum

   The following mechanisms can be identified as communication means
   between Applications and Service Stratum.

   *  Connectivity Provisioning Negotiation Protocol (CPNP) [RFC8921]

   *  Interconnection Intents
      [I-D.contreras-nmrg-interconnection-intents]

   *  Slice intent [I-D.contreras-nmrg-transport-slice-intent]

Contreras, et al.        Expires 6 January 2025                [Page 13]
Internet-Draft               CLAS Evolution                    July 2024

   *  Selection of proper edge for service placement
      [I-D.contreras-alto-service-edge]

   *  Composition of service function chains
      [I-D.lcsr-alto-service-functions]

7.2.  Communication between Service Stratum and Connectivity Stratum

   Similarly, the following are potential mechanisms for communication
   between Service Stratum and Connectivity Stratum

   *  Framework for Automating Service and Network Management [RFC8969],
      as well as the models referenced there

   *  IETF Network Slice Service model
      [I-D.ietf-teas-ietf-network-slice-nbi-yang]

   *  Service function aware TE topology model
      [I-D.ietf-teas-sf-aware-topo-model]

7.3.  Communication between Service stratum and Compute Stratum

   Between both Service and Compute Stratum the follwoing mechanisms
   could be used.

   *  Data Center aware TE topology model
      [I-D.llc-teas-dc-aware-topo-model]

   *  Cloud-based solutions (e.g., Kubernetes)

7.4.  Communication between Connectivity stratum and Compute stratum

   Finally, the direct communication between COnnectivity and Compute
   strata can be realized by mechanisms as follows:

   *  Traffic steering with service function awareness
      [I-D.ietf-cats-framework]

8.  TODO for next versions of this document

   This version is a work-in-progress.  Next versions of the document
   will address some further aspects such as:

   *  Deployment scenarios (including legacy ones).

   *  Potential use cases (specially in alignment with on-going
      activities in COINRG / NMRG).

Contreras, et al.        Expires 6 January 2025                [Page 14]
Internet-Draft               CLAS Evolution                    July 2024

9.  Security Considerations

   Same security considerations as reflected in [RFC8597] with regards
   to the strata architecture apply also here.

   Apart from that, the introduction of the Knowledge plane on the data
   management imposes additional security concerns, as those identified
   in [I-D.irtf-nmrg-ai-challenges].

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2.  Informative References

   [I-D.boucadair-nmop-rfc3535-20years-later]
              Boucadair, M., Contreras, L. M., de Dios, O. G., Graf, T.,
              and R. Rahman, "RFC 3535, 20 Years Later: An Update of
              Operators Requirements on Network Management Protocols and
              Modelling", Work in Progress, Internet-Draft, draft-
              boucadair-nmop-rfc3535-20years-later-03, 18 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-boucadair-
              nmop-rfc3535-20years-later-03>.

   [I-D.contreras-alto-service-edge]
              Contreras, L. M., Randriamasy, S., Ros-Giralt, J., Perez,
              D. A. L., and C. E. Rothenberg, "Use of ALTO for
              Determining Service Edge", Work in Progress, Internet-
              Draft, draft-contreras-alto-service-edge-10, 13 October
              2023, <https://datatracker.ietf.org/doc/html/draft-
              contreras-alto-service-edge-10>.

   [I-D.contreras-nmrg-interconnection-intents]
              Contreras, L. M. and P. Lucente, "Interconnection
              Intents", Work in Progress, Internet-Draft, draft-

Contreras, et al.        Expires 6 January 2025                [Page 15]
Internet-Draft               CLAS Evolution                    July 2024

              contreras-nmrg-interconnection-intents-04, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-contreras-
              nmrg-interconnection-intents-04>.

   [I-D.contreras-nmrg-transport-slice-intent]
              Contreras, L. M., Demestichas, P., and J. Tantsura, "IETF
              Network Slice Intent", Work in Progress, Internet-Draft,
              draft-contreras-nmrg-transport-slice-intent-06, 24 October
              2022, <https://datatracker.ietf.org/doc/html/draft-
              contreras-nmrg-transport-slice-intent-06>.

   [I-D.ietf-cats-framework]
              Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
              Drake, "A Framework for Computing-Aware Traffic Steering
              (CATS)", Work in Progress, Internet-Draft, draft-ietf-
              cats-framework-02, 30 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cats-
              framework-02>.

   [I-D.ietf-teas-ietf-network-slice-nbi-yang]
              Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
              "A YANG Data Model for the RFC 9543 Network Slice
              Service", Work in Progress, Internet-Draft, draft-ietf-
              teas-ietf-network-slice-nbi-yang-13, 9 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slice-nbi-yang-13>.

   [I-D.ietf-teas-sf-aware-topo-model]
              Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, L.
              M., Ceccarelli, D., Tantsura, J., and D. Shytyi, "SF Aware
              TE Topology YANG Model", Work in Progress, Internet-Draft,
              draft-ietf-teas-sf-aware-topo-model-13, 4 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-sf-
              aware-topo-model-13>.

   [I-D.irtf-coinrg-use-cases]
              Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., de Foy,
              X., Griffin, D., and M. Rio, "Use Cases for In-Network
              Computing", Work in Progress, Internet-Draft, draft-irtf-
              coinrg-use-cases-05, 23 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-irtf-coinrg-
              use-cases-05>.

Contreras, et al.        Expires 6 January 2025                [Page 16]
Internet-Draft               CLAS Evolution                    July 2024

   [I-D.irtf-nmrg-ai-challenges]
              François, J., Clemm, A., Papadimitriou, D., Fernandes, S.,
              and S. Schneider, "Research Challenges in Coupling
              Artificial Intelligence and Network Management", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-
              03, 4 March 2024, <https://datatracker.ietf.org/doc/html/
              draft-irtf-nmrg-ai-challenges-03>.

   [I-D.lcsr-alto-service-functions]
              Contreras, L. M., Randriamasy, S., and X. Liu, "ALTO
              extensions for handling Service Functions", Work in
              Progress, Internet-Draft, draft-lcsr-alto-service-
              functions-02, 13 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-lcsr-alto-
              service-functions-02>.

   [I-D.llc-teas-dc-aware-topo-model]
              Lee, Y., Liu, X., and L. M. Contreras, "DC aware TE
              topology model", Work in Progress, Internet-Draft, draft-
              llc-teas-dc-aware-topo-model-03, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-llc-teas-dc-
              aware-topo-model-03>.

   [I-D.rcr-opsawg-operational-compute-metrics]
              Randriamasy, S., Contreras, L. M., Ros-Giralt, J., and R.
              Schott, "Joint Exposure of Network and Compute Information
              for Infrastructure-Aware Service Deployment", Work in
              Progress, Internet-Draft, draft-rcr-opsawg-operational-
              compute-metrics-05, 31 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-rcr-opsawg-
              operational-compute-metrics-05>.

   [ITU]      "Functional architecture for intelligent network status
              awareness based on federated learning", April 2024.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
              <https://www.rfc-editor.org/rfc/rfc7149>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/rfc/rfc7426>.

Contreras, et al.        Expires 6 January 2025                [Page 17]
Internet-Draft               CLAS Evolution                    July 2024

   [RFC8597]  Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M.,
              and P. Iovanna, "Cooperating Layered Architecture for
              Software-Defined Networking (CLAS)", RFC 8597,
              DOI 10.17487/RFC8597, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8597>.

   [RFC8921]  Boucadair, M., Ed., Jacquenet, C., Zhang, D., and P.
              Georgatsos, "Dynamic Service Negotiation: The Connectivity
              Provisioning Negotiation Protocol (CPNP)", RFC 8921,
              DOI 10.17487/RFC8921, October 2020,
              <https://www.rfc-editor.org/rfc/rfc8921>.

   [RFC8969]  Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
              L. Geng, "A Framework for Automating Service and Network
              Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
              January 2021, <https://www.rfc-editor.org/rfc/rfc8969>.

   [RFC9418]  Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T.
              Arumugam, "A YANG Data Model for Service Assurance",
              RFC 9418, DOI 10.17487/RFC9418, July 2023,
              <https://www.rfc-editor.org/rfc/rfc9418>.

   [RFC9419]  Arkko, J., Hardie, T., Pauly, T., and M. Kühlewind,
              "Considerations on Application - Network Collaboration
              Using Path Signals", RFC 9419, DOI 10.17487/RFC9419, July
              2023, <https://www.rfc-editor.org/rfc/rfc9419>.

   [TMV]      "Service performance measurement methods over 5G
              experimental networks", May 2021.

Acknowledgments

   This work has been partially funded by the European Union under
   Horizon Europe projects NEMO (NExt generation Meta Operating system)
   grant number 101070118, and CODECO (COgnitive, Decentralised Edge-
   Cloud Orchestration), grant number 101092696.

Authors' Addresses

   Luis M. Contreras
   Telefonica
   Ronda de la Comunicacion, s/n
   28050 Madrid
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com

Contreras, et al.        Expires 6 January 2025                [Page 18]
Internet-Draft               CLAS Evolution                    July 2024

   Mohamed Boucadair
   Orange
   35000 Rennes
   France
   Email: mohamed.boucadair@orange.com

   Diego R. Lopez
   Telefonica
   Seville
   Spain
   Email: diego.r.lopez@telefonica.com

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   28911 Leganes, Madrid
   Spain
   Email: cjbc@it.uc3m.es

Contreras, et al.        Expires 6 January 2025                [Page 19]