]> China Telecom

xiechf@chinatelecom.cn

Huawei

lana.wubo@huawei.com

Red Hat

ncocker@redhat.com

Futurewei

ldunbar@futurewei.com

Operations and Management onions Automation Telcom Cloud Network Operation Network Topology This document describes how the various data models that are produced in the IETF can be combined in the context of Telco Cloud service delivery. Specifically, this document describes the communication of a Network Orchestrator and Cloud orchestrator for the realization of optimized Telco Cloud services to implement inter-dc reachability and connectivity services.

Introduction The IETF has produced several YANG data models that are instrumental for automating the provisioning and delivery of connectivity services. An overview of these data models and a framework that describes how these various modules can be used together are described in . This document adopts the rationale of , but with a focus on the network coordination with Telco Cloud services. The document also identifies some gaps related to existing models. The document outlines an architecture and communication process of Network Orchestrators and Cloud orchestrators.

Conventions and Definitions This document assumes that the reader is familiar with the contents of , , and as it uses terms from those RFCs. This document uses the term "network model" as defined in Section 2.1 of .

A Reference Architecture of Telco Cloud Network Coordination In some implementation, Cloud Orchestrator and Network Orchestrator are only associated with their own respective services. That is, Cloud Orchestrator is responsible for data center (DC) services, such as application, compute, and/or storage services within the DC, while network Orchestrator plans and deploys connections based on planed inter-DC traffic demands. In certain scenarios, such as the cross-site connectivity service interfaces definition, to support cloud-based cross-data center (DC) scaling, the NFV cloud platform can leverage network-exposed API interfaces to dynamically collect underlay WAN network status and establish/update inter-DC connections. The architecture option is shown in the figure below.

Coordination of Network Resources for the Cloud Service Provisioning | | |( Telco Cloud | IETF Service&Network|(Provider Network | | Orchestration) | Data models/API | Orchestration) | +----------------+ +--------------------+ | | | | | | +---------------|-+ +-|---------------+ | +--+ v | | v | | |NF+ +----+ .1| 192.0.2.0/31 |.0+--+ | | +--+...+DCGW+----------------------- ----+PE| | |+---+ +----+ | VLAN 100 | +--+ | ||APP| | | | |+---+ | | Provider | | DC Network | | Network | +-----------------+ +-----------------+ |----------- AC ------- ----| Legend: DCGW: DC Gateway ]]>

This NFV cloud architecture option implies that the Cloud Orchestrator operates with network-awareness. The Network Orchestrator exposes the interfaces to provide pre-planned bandwidth and dynamic connections. The Cloud Orchestrator can then dynamically control and manage the capacity and network connections between WANs of inter-DC. As suggested in , The candidate IETF interfaces between Network Orchestrator and Cloud Orchestrator are outlined in the table below:

Number	Network Function Requirements	IETF YANG Models
1	Multi-site Connectivity	- L3SM - L3NM - L2SM - L2NM - RFC9543 NSS YANG Model - I-D.ietf-teas-ietf-network-slice-nbi - AC Service YANG Model I-D.ietf-opsawg-teas-attachment-circuit
2	Capacity Management	- Service Attachment Point - TE Service Mapping - TE Topology - TE Tunnel - SR Policy
3	Fault Management	- Alarm Management
4	Performance Management	- Network and VPN Service PM

However, this NFVO architecture option cannot meet the emerging needs of telecom cloud applications because it is difficult to plan bandwidth between large-scale edge DCs and enterprise sites. For example, AI-based video analysis and AI-driven knowledge reasoning will be deployed in edge data centers, which are characterized by a large number of deployments and significant variations in resource capabilities. Combined with the diversity of enterprise sites, the new telecom cloud needs fast, private, and reliable connections between site-to-site, site-to-cloud, or cloud-to-cloud endpoints. A potential alternative architecture option involves centralized scheduling of cloud and network resources to coordinate their integration, enabling rapid deployment of network services and applications such as SD-WAN, SASE, and other edge cloud services. This approach ensures agile allocation of cloud resources and optimization of WAN network resources to meet dynamic demand.

Alternative Architecture of the Cloud Service Provisioning

This proposed telco cloud reference architecture is an open framework to allow for multiple vendor Network Orchestrators and multiple vendor Cloud Orchestrators. The goal is to enable standard data models or APIs to provide those services.

Telco Cloud Service Requirements

Optimized Scenarios of Telco Cloud Service Placement

Example of Overlay Network and Cloud Service Placement The diagram below illustrates a telco cloud network example connecting multiple data centers (DCs) and enterprise CEs. Multiple data centers are shown, each potentially hosting different services or applications. For instance, DC-1 is directly linked to gateway GW2A and GW2B, suggesting it may host critical applications or services that require high availability. Various DC gateways are deployed to manage traffic flow towards Data Centers or Application instances. Two CE1 devices are connected to PE5A and PE5B respectively, indicating the start points for customer traffic entering the provider's network. There are several Provider Edge devices (PE5A, PE5B, etc.) which serve as entry and exit points for traffic moving between the customer and the provider's network. The Border routers (BRs) facilitates the transfer of data across different parts of the network. They connect the access/aggregation layer to the core network.

Coordination of Network Resources for the Cloud Service Provisioning

To create services across DCs like optimized service placement, generic API calls are needed. A typical usage is to use Restful APIs of Cloud Orchestrator and Network Orchestrator and used by the Super Orchestrator to provision the inter-DC services connections and also applications. When deploying cross-DC cloud services, it is assumed that the Super Orchestrator has access to the DC and network connectivity topology (e.g. TE Topology ), as well as centralized resource information for both the DCs and the network. Some standard network inventory interfaces are available. For example, the Service Attachment Points (SAPs) or ACs can obtain the AC/Bearer information of the PE, which suggests that the private line service provisioning resource resources on the network side, but there is no cloud DC service provisioning resource information, such as CPU, GPU, storage, and DC network information. DC aware TE topology model defines YANG models about the information. One API example is as below.

Cloud Inventory API

The flowchart below gives an example of hospital applications are deployed and ensure efficient use of network connections for optimized data flow.

Cloud Service Placement

Here is a step-by-step breakdown of the flowchart with detailed explanations for each step:

1. Step 1: Requirement Analysis: This is the first step where the Super Orchestrator gathers and analyzes requirements for branch data transfer. Key Requirements are bandwidth must be at least 100 Mbps, data must be transmitted over a private connectionbe, and support AI analysis. the Super Orchestrator also determines the optimal allocation of resources for data transfer. Data will flow from the branch office to the center data center (DC). A edge DC is selected as an intermediate hop. A dedicated line of 100 Mbps of bandwidth with redundant links and to the center and edge DC is needed. Underlay Network Controllers may expose to Network Orchestrator s a set of network data models, such as the AC, L3SM , L3NM , L2SM , L2NM , RFC9543 NSS YANG Model , Service Attachment Points (SAPs) , TE Service Mapping , TE Tunnel , or SR Policy . Network Orchestrator can use these models to set up connections between the Provider Edge devices, and also customer facing ACs between CEs and PEs, DC-GWs and PEs.
2. Step 2: Application Instances Deployment and Parallel Network Connectivity: This step involves deploying AI at the center DC and the edge DC. With request from Super Orchestrator, Cloud Orchestrator allocates resources, including GPU clusters and storage. Also Network Orchestrator can configure PE.
3. Step 3: Validation and Monitoring: This step ensures that the service meets performance and reliability expectations. Through the open interfaces, Super orchestrator can monitor status of cloud resources and WAN connections. The open interfaces could be VPN PM ,Alarm Management , or new service assurance models.

The steps described above assume that ​​Super Orchestrator​​ can access both network and cloud resources to perform resource analysis and allocation.

Example of Telco Cloud Service Creation Flow An example of service creation flow is as follows:

Cloud Service Creation | | | | | | +--------------------------+ | | |2.Deploy the cloud service| | | +--------------------------+ | | | | | 1.2 Create a network service | |------------------------------------------------------->| | | | | | +----------------------------+ | | |2.Deploy the network service| | | +------------------------------+ | 3.Create cloud service response | |-------------------------------| | | | | | | | | 3. Create Network service response | |--------------------------------------------------------| | | | | | | | | | | 4. Subscribe for cloud performance metric | |------------------------------>| | | | | | 5.Subscribe for network performance metric | |------------------------------------------------------->| | | | +------------------------+ | | | | | | |5.Continuous monitoring | | | +------------------------+ | | | | | | | | ]]>

More Examples to Add

Optimized Scenarios of Telco Cloud Service Assurance A scaling example is to add.

Security Considerations TBC.

IANA Considerations None.

References Normative References Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. Informative References Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy (RFC 8406). The objective is to contribute to a larger deployment of Network Coding techniques in and above the network layer in satellite communication systems. This document also identifies open research issues related to the deployment of Network Coding in satellite communication systems. This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. Orange Juniper Telefonica Nokia Huawei Technologies Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a YANG service model for managing bearers over which ACs are established. Telefonica Alef Edge This document proposes the extension of the TE topology model for including information related to data center resource capabilities. This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text. As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. Samsung Electronics Huawei Huawei Huawei Cisco Nvidia This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Cisco Systems Cisco Systems Huawei Technologies Individual Oracle Corporation SoftBank Juniper Networks This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.

Acknowledgments The authors wish to thank xxx and many others for their helpful comments and suggestions.

Contributors Huawei

jie.dong@huawei.com