Architecting Multi-Layer Orchestration for Telco Networks

Raghavendra Rao Tadepalli , Wipro; and Vinay Devadatta , Practice Head, Wipro

IEEE Softwarization, November 2018

 

Just a few years back the word “orchestration” was hardly used by Telecom operators (telcos) and was mostly used in the world of music. Today any telco management discussion is incomplete without discussions on “orchestration”. There are different views on what “orchestration” means; it is often used interchangeably with management, controller etc... When ETSI[1] introduced NFV (Network Function Virtualization) to the communication industry, the NFV Orchestrator was a new functional block that caught everybody’s attention. Since then, a number of orchestration solutions have been specified and implemented by different forums, specification bodies, communication service providers and product vendors. Overtime, it was further realized that having just one orchestrator would not be sufficient and/or efficient and having multiple layers (at least two) of orchestration is required.  For example, Open Source MANO (OSM)[2] defines 2 layers of orchestration i.e. Service Orchestrator (SO) and Resource Orchestrator (RO). Similarly, Open Network Automation Platform (ONAP)[3], defines at least 2 layers of orchestration i.e. Service Orchestrator (SO) and Virtual Function Controller (VF-C), where the latter is aligned with the ETSI NFV-Orchestrator function.

Defining Orchestration

The authors propose that the function of orchestration consists of coordination and management. While the coordination part is a must, managerial functionality is optional.  The coordinator does not have absolute authority on components or entities that it needs to work with, whereas a manager has complete authority on the involved entities. The manager can decide on every aspect of the life cycle of subject components on its own. The manager itself might be controlled by a higher-level management entity, but downwards it enjoys exclusive absolute authority on the components it is managing. The coordinator, on the other hand, must work with entities which may or may not execute actions issued by it. Till the command is issued, the coordinator is not aware whether the command will be executed successfully. Hence, a coordinator in the true sense makes requests, rather than sending commands, and based on the response, realigns its action to achieve the intended goal. The coordinator must work within these constraints to achieve its goals. Another term used, specifically in SDN context, is controller. This basically controls a certain behavior or aspect of the subject entity. While it does not have absolute authority on the life cycle of the component, it exercises control on specific behaviors, and sometimes, shares this authority with other controllers.  The consequence of coordination may result in the creation of a transient element (e.g. a Network Service), and the coordinator may manage the life cycle of this new element.  

Orchestration in ETSI NFV MANO

In the case of the NFV MANO architecture, the NFV Orchestrator (NFVO) coordinates with VNFM (Virtual Network Function Manager) and VIM (Virtual Infrastructure Manager). While the latter two manage the Virtual Network Function (VNF) and Virtual Infrastructure (VI) respectively, the NFVO coordinates with these two managers to create a new transient entity: the Network Service (NS) . The NFVO, in its role as a manager, manages the life cycle of the NS using requests to VNFM(s) and VIMs(s). The orchestrator in its main role as a coordinator can only guarantee best effort results. In most architectures, we see NFVO working with a service orchestrator.  

Multi-Layered Orchestration 

In a hierarchical orchestration solution, an orchestrator at a given layer will need to work with a higher layer orchestrator rather than a manager. This is because a higher layer of manager would expect a command-acknowledgment behaviour rather than best-effort request-response behaviour. The lower layer orchestrator, being a coordinator, cannot guarantee requested action to the higher-level entity. At a generic level, in a multi-layered orchestration architecture, an orchestrator at the top of the hierarchy orchestrates multiple next level orchestrators and/or other management entities (e.g. VIM or VNFM).   

There are multiple factors that influence how the hierarchical orchestration solution is structured for a specific context. Some of these factors are: 

  • Geographical spread and placement of entities that need to be orchestrated (e.g. distributed NFVI PoPs).
  • Scalability constraints of the orchestrator. 
  • Business and operational requirements of the service provider deploying the orchestration solution.
  • Different network domains and the abstractions that each of the entities in these domains (e.g. VNFs, SDN Controllers, VNFMs, etc.) offer over their interfaces towards the orchestration layer.
  • The different layers of abstraction (e.g. resource, service, customer and product)   

The following figure illustrates a hierarchical layer of orchestrators; each layer of orchestration deals with different levels of abstraction and some of the layers are also structured based on the geographical region and network domain. There are obviously other multiple combinations in which such hierarchical layers of orchestrators can be structured and below is an illustration of such a possible scenario. 


Figure 1: Illustration of hierarchical orchestration

Coordination Interfaces between Hierarchical Orchestrators 

The interface constructs between the multiple layers of orchestrators are quite different from the traditional management systems. Typically, the interfaces between management systems are command/operation oriented i.e. a higher level management system issues a command or triggers an operation on the lower level management system and the command/operation is either successful or an error is reported back. The multi-orchestrator environment requires a different approach to interface design between the different layers of orchestrators.  

The authors propose some of the key generic characteristics of the interface between multiple orchestrators (apart from interfaces reflecting functionality of the orchestrators ): 

  • Intent-based interfaces instead of command/operation based:

A higher-level orchestrator expresses its intent to the lower level orchestrator and the lower level orchestrator, in turn, decides how to achieve that intent by orchestrating various entities in its scope. 

  • Conversational style of interfaces instead of request/response paradigm

The orchestrators exchange conversations instead of request/response, for example, a service orchestrator might request a WAN orchestrator to create of a network service in a particular geographical region(s) with specific QoS, and the WAN orchestrator analyzes the request based on information it gathers from management systems, analytics feeds and VIMs and gets back to the service orchestrator on the alternatives that are feasible (say the original QoS requirements cannot be completely satisfied etc.). The service orchestrator can then either choose one of the alternatives or even decide to change the original request, considering the alternatives suggested. Such a conversational style enables the orchestrators acting at different levels of abstraction the scope to mitigate potential deadlocks, ensure proper reservations of network resources to efficiently achieve the primary intent. 

  • Best-effort instead of guaranteed action semantics

Unlike the conventional management systems, the orchestrators, by definition, are oriented towards best-effort based semantics. For example, if a service orchestrator expresses its intent to instantiate a set of VNFs to a NFV orchestrator, the NFV orchestrator may choose a slightly different combination or configuration of VNFs to instantiate based on the real-time information it has on the NFVI resource availability etc., to fulfil the intent. Such intent based best-effort semantics imply that the approach adopted to achieve the end to end system’s reliability has to be different from the conventional management system. One of the possible approaches could be to leverage coordination and management functions of orchestrator.


Multi-Layered Orchestration – Key Benefits 

 The orchestrators, unlike the management systems, are primarily entities responsible for sharing control, handle conflicts, and ensure that the primary intent (which includes various QoS characteristics required for operational efficiency and effectiveness) is achieved on a best-effort basis. The real benefit of embracing NFV and SDN in a telecommunication network can be achieved only if a collaborative style of multi-layered orchestration capability is employed.  

Conclusion

Telco networks are complex and need to be managed from multiple perspectives. Orchestration architecture enables loose coupling of monitoring and control from different perspectives while ensuring consistent behavior across the entire system. A coordinative approach rather than a master -slave approach ensures that lower level as well as higher-level objectives are dynamically balanced.  In a multilayer orchestration architecture, care should be taken that the coordinative approach is preserved across layers and highest intents flow dynamically through the management system.   

 

References 

  1. ETSI GS NFV-MAN 001 V1.1.1 (2014-12) : Network Functions Virtualisation (NFV); Management and Orchestration 

https://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf 

  1. Open Source MANO : OSM Release FOUR Technical Overview May 2018

https://www.kernel.org/doc/Documentation/networking/vrf.txt

  1. Introducing the ONAP Architecture (Amsterdam Release)

https://onap.readthedocs.io/en/amsterdam/guides/onap-developer/architecture/onap-architecture.html 

 

Raghavendra Rao Tadepalli

Raghavendra Rao Tadepalli

Raghavendra has extensive experience in the telecoms industry, working with equipment vendors and standard bodies like TM Forum, ETSI NFV and ONF. He is responsible for the Cloud Native applications portfolio as part of Wipro’s Telecom Network Equipment Provider business. His primary focus is R&D of OSS applications, Orchestration and automation, Network Function Virtualization and Software Defined Networks, and works with the Network Equipment Vendor business within Wipro. He holds a B.Tech in Computer Science.

 

 

Vinay Devadatta

Vinay Devadatta

Vinay has extensive experience in the communications industry, working with equipment vendors, communication service providers, OSS product vendors, OSS solution providers and telco management standards bodies like TM Forum, ETSI NFV, NGMN NGCOR. He is responsible for leveraging external and internal innovation and creating new service lines at Wipro Technologies. His expertise is in the areas OSS, NFV, Orchestration, automation, digital customer experience, automation and 5G.  He holds a B.Tech in Electronics & Communication Engineering and an M.Tech in Computer Science & Technology from IIT Roorkee.

 

Editor:

Editor

Eliezer Dekel

Eliezer Dekel a Chief Architect for Huawei Technologies Corporate Reliability Department. He is researching RAS for SDN and NFV. He retired from IBM Research - Haifa, as a Senior Technical Staff Member and Chief Architect for Distributed Systems. In his this role he focused on developing infrastructure technologies for very large scale distributed systems.

Eliezer Dekel is the editor in chief of EAI Endorsed Transaction on Cloud Systems. He is also an Associate Editor for ACM Computing Surveys and a member of the editorial board for IEEE SDN Newsletter. Eliezer served on numerous conference program committees and organized, or served as chair in some of them. He has been involved in research in the areas of distributed and fault-tolerant computing, service-oriented technology, and software engineering. He was recently working on technologies for providing Quality of Service, with a focus on dependability, in very large scale multi-tier environments. For this area he initiated together with colleagues the very successful International Workshop on Large Scale Distributed Systems and Middleware (LADIS). This workshop, sponsored by ACM. It was one of the first workshops to focus on the foundations of "cloud computing." He was an organizer of CloudSlam'09 the first cloud computing virtual conference. Eliezer was also involved in several EU FP7 ICT funded projects.

Eliezer has a Ph.D. and M.Sc. in computer science from the University of Minnesota, and a B.Sc. in mathematics from Ben Gurion University, Israel. Prior to joining IBM Research - Haifa, Eliezer served on the faculty of the University of Texas at Dallas computer science department for more than ten years.

 

Pushing the Envelope of Application Quality of Experience with SD-WANs

Anand OswalEnterprise Networking Business, Cisco

IEEE Softwarization, November 2018

 

Pushing the Envelope of Application Quality of Experience with SD-WANs

The growing dependence on SaaS (Software as a Service) and cloud applications, video, and Voice Over IP can stress the capabilities of branch networks using traditional WAN technology. Retail stores, for example, depend on secure and fast communication with corporate back-office applications to keep sales humming. Wireless sensors for monitoring IoT implementations are becoming more commonplace and adding rivers of data to the network. The coming wave of VR and AR applications to stores, industrial shop floors, and entertainment venues will demand even more bandwidth at locations outside the domains of corporate and campus networks.

With traditional WAN implementations, workers at branch locations are often frustrated by lower application Quality of Experience (QoE) than their corporate or campus co-workers. You’ve probably had personal experience of this problem when you are on the phone with customer support only to have the frustrated agent excuse the long delay to your issue because “my application is not responding.” The traditional method of improving QoE at branches involves throwing more expensive bandwidth at the problem. However, there is a better, software-defined way to improve QoE while lowering communication costs at the same time.

Implementing a Software Defined-WAN (SD-WAN) for branch offices and distributed locations solves multiple challenges in optimizing network QoE in a distributed enterprise by:

  • Unifying connectivity across MPLS, Ethernet, internet, leased lines, DSL, and LTE networks to provide the ability to balance traffic among the channels.
  • Maintaining performance with a consistent QoE for SaaS, cloud, and data center applications accessed by remote branch workers.
  • Providing secure device and application access to sensitive enterprise data resources.
  • Reducing transmission costs while increasing bandwidth for interactive applications, video, and conferencing.
  • Using multilayer security to encrypt all data from the WAN edge to the cloud by applying segmentation to keep sensitive data from co-mingling with non-essential traffic.
  • Isolating malware-infected endpoints from the network to stop infections from spreading.

Maintaining QoE with Machine Learning

SD-WAN on edge routers builds a secure virtual IP fabric by combining routing, segmentation, security, policy, and orchestration. It reduces excessive backhauling from branches to headquarters to access SaaS applications in the multicloud, using direct internet connection instead of an MPLS link to the corporate data center and then out to the SaaS applications. For example, IT can deploy a Cloud-Onramp SaaS to provide better performance for the workers at a remote branch office that need to access cloud-SaaS applications, such as Office 365 or Salesforce. The SD-WAN fabric continuously measures the performance of SaaS applications across all the paths that are in use—MPLS, Ethernet, internet, leased lines, DSL, or LTE—and calculates a score based on a machine learning algorithm. This score gives network administrators visibility into application performance enabling them to make the most effective use of available links. Most importantly, the fabric automatically uses the score to choose the best-performing path between the end users at a remote branch and the cloud SaaS application in real time, adjusting as conditions and traffic change.

Application-Aware Security is Key to Quality of Experience

The ability of a software-defined WAN to continuously monitor, analyze, and react to changes in cloud and SaaS application traffic and security is crucial to providing remote workers with the QoE they need to work efficiently. With older WAN technology, many security network services such as application firewall and intrusion detection/prevention systems require that the traffic entering the branch has to be backhauled to corporate data center DMZs, adding latency and bandwidth usage. With an SD-WAN implementation, security services are built-in to the router for analyzing, filtering, and detecting intrusions in traffic flowing through the branch network.

In addition to securing network traffic from branch to cloud, an SD-WAN implementation incorporates security capabilities that include Application-Aware Firewall, Intrusion Prevention System, URL Filtering and DNS Web-layer security. These security capabilities help organizations achieve PCI compliance, segmentation, threat protection, content filtering, and much more. With Application-Aware Firewall policies can be implemented to allow trusted applications which are critical and block un-trusted applications.

Another consideration for maintaining application QoE for branches involves defining the type of connections required for specific levels of security. An SD-WAN implementation can segment traffic according to policies that manage sensitive compliance traffic like Payment Card Information (PCI), applications that connect directly to cloud resources, and guest access that keeps traffic from visitors’ devices completely separate from sensitive business data. Each of these, along with direct internet access, requires that the router understand the types of data traffic and apply the correct security measures. For example, PCI traffic is always directed to a secure VPN tunnel while guest traffic streams to the direct internet port, ensuring high priority to the financial applications and lower cost connectivity for guest traffic.

SD-WAN Unites People, Devices, and Distributed Offices

SD-WAN implementations are relatively new but are quickly gaining traction in distributed enterprises. By improving application QoE for a remote and mobile workforce while enhancing security and lowering costs of connectivity, SD-WAN has an important role to play in uniting people, devices, and distributed offices. Is an SD-WAN implementation in your organization’s future? I’d like to hear from you about your plans.

 

 

Anand Oswal Anand Oswal

Anand Oswal (Twitter @aoswal1234) serves as Senior Vice President, Enterprise Networking Business. He is responsible for building the complete set of platforms and solutions for the Cisco enterprise networking portfolio. The portfolio spans enterprise products across routing, access switching, IoT connectivity, wireless, and network/cloud services deployed at customers worldwide. He holds more than 60 U.S. patents and focuses on innovation and inspiring his team to build awesome products and solutions.

Anand joined Cisco via the acquisition of Starent Networks, a leader in mobile packet core gateways. At Starent he was responsible for building revolutionary, industry-leading telecom products that were also maximized for profitable growth. Earlier still, he held leadership roles at Siara Systems, acquired by Redback Networks, Sun Microsystems, and Ericsson. Anand holds a bachelor's degree in telecommunications from the College of Engineering, Pune, India and a master's degree in computer networking from the University of Southern California, Los Angeles.

 

 

Francesco BenedettoFrancesco Benedetto

Francesco Benedetto was born in Rome, Italy, in 1977. He received the Dr.Eng. degree in electronic engineering and the Ph.D. degree in telecommunication engineering from the Roma Tre University, Rome, Italy, in 2002 and 2007, respectively. In 2007, he was a Research Fellow with the Department of Applied Electronics, Rome Tre University, where he has been an Assistant Professor of Telecommunications since 2008. His research interests include ground penetrating radar, software and cognitive radio, digital signal and image processing for telecommunications and economics, code acquisition, and synchronization for the 3G mobile communication systems and multimedia communication. Dr. Benedetto has been the Chair of the IEEE 1900.1 Working Group on “Definitions and Concepts for Dynamic Spectrum Access: Terminology Relating to Emerging Wireless Networks, System Functionality, and Spectrum Management,” since 2016. He is the Leader of the WP 3.5 on “Development of Advanced GPR Data Processing Technique” of the European COST Action TU1208—Civil Engineering Applications of Ground Penetrating Radar. He is an Editor of the IEEE SDN Newsletter, the General Chair of the Series of International Workshops on Signal Processing for Secure Communications (SP4SC 2014, 2015, and 2016), and the Lead Guest Editor of the Special Issue on “Advanced Ground Penetrating Radar Signal Processing Techniques” for the Signal Processing Journal (Elsevier). He also served as a reviewer for several IEEE Transactions, IET Proceedings, EURASIP, and Elsevier journals, and a TPC Member for several IEEE international conferences and symposia in the same fields.

.

 

IEEE Softwarization -November 2018
A collection of short technical articles

ETSI ZSM Architectural Framework for End-to-End Service and Network Automation 

By Nurit Sprecher,  ETSI ZSM

The automation of network management and service delivery is becoming essential to deliver services with agility and speed, and it is needed to ensure economic sustainability of the very diverse set of services offered by Digital Service Providers.

  

Intent Based Modelling Key to 5G & ZSM

By Marie-Paule Odini, Hewlett Packard Enterprise; and Andreas Krichel, Hewlett Packard Enterprise

Telecom Networks used to be rather static, hierarchical and with siloes: a fixed-broadband network with DSLAM (Digital Subscriber Line Access Multiplexer) and home CPE (Customer Premise Equipment) as leaves or a mobile network with a Core Network and base stations as leaves. With the move to softwarization and more dynamic allocation of resources on demand, for new services or to expand capacity, network topology tends to evolve more often. With 5G [11], this granularity and complexity of the network is exploding in terms of new resource types, service types, policies, access rights, instances and frequency of the changes. To keep up with this transformation and prevent manual errors, more and more automation is introduced in the network operations with an ultimate goal to become ‘zero touch’ as discussed in ETSI ZSM (Zero Touch Service Management)


Zero Trust Networking with Zero Touch Management

By Erik Giesa, Tempered Networks

Networking has evolved into a messy patchwork of inflexible and complicated systems with an expanding attack surface. Network administrators and security professionals responsible for designing, deploying, securing, and maintaining networks are simply overwhelmed and ill-equipped to keep up. The ‘go to’ strategy has been to implement Virtual Private Networks (VPNs), firewalls, Access Control Lists (ACLs), etc. and apply IP routing schemes intended to keep devices within the network connected, while keeping hackers and unwanted visitors out. The software and security industries set out to fix this problem by encrypting communications with protocols like SSL/TLS, HTTPS, SSH, SLADP, DNSSEC, IPSec, etc., yet networks continue to be breached.  Unfortunately, these protocols on their own do not really move the needle and actually move us in the wrong direction since they are all based on TCP/IP.


Pushing the Envelope of Application Quality of Experience with SD-WANs

Anand Oswal, Enterprise Networking Business, Cisco

The growing dependence on SaaS (Software as a Service) and cloud applications, video, and Voice Over IP can stress the capabilities of branch networks using traditional WAN technology. Retail stores, for example, depend on secure and fast communication with corporate back-office applications to keep sales humming. Wireless sensors for monitoring IoT implementations are becoming more commonplace and adding rivers of data to the network. The coming wave of VR and AR applications to stores, industrial shop floors, and entertainment venues will demand even more bandwidth at locations outside the domains of corporate and campus networks.


Architecting Multi-Layer Orchestration for Telco Networks

Raghavendra Rao Tadepalli , Wipro ; and Vinay Devadatta , Wipro

Just a few years back the word “orchestration” was hardly used by Telecom operators (telcos) and was mostly used in the world of music. Today any telco management discussion is incomplete without discussions on “orchestration”. There are different views on what “orchestration” means; it is often used interchangeably with management, controller etc...

 

ETSI ZSM Architectural Framework for End-to-End Service and Network Automation

Nurit Sprecher, ETSI ZSM

IEEE Softwarization, November 2018

 

The automation of network management and service delivery is becoming essential to deliver services with agility and speed, and it is needed to ensure economic sustainability of the very diverse set of services offered by Digital Service Providers.

The challenges introduced by the disruptive deployment of 5G trigger the need for network transformation and radical change in the way networks and services are managed and orchestrated. These challenges are driven by the extreme range of requirements, including seemingly infinite capacity, imperceptive latency, demand for personalized services and unmatched degree of user experience, global web-scale reach and support for massive machine-type communications. Networks are being transformed into programmable, software-driven, service-based and holistically-managed network architecture, utilizing technology enablers and catalysts, such as Network Function Virtualization (NFV), Software Defined Networking (SDN) and Multi-access Edge Computing (MEC). New business models, including those enabled by technology breakthroughs such as Network Slicing, support new markets and impose unprecedented operational agility and higher cooperation across network domains. The resulting exponential increase in overall complexity makes automation a necessity.

Service delivery must be fully automated using digital service Life Cycle Management (LCM) systems including service management, network and cloud resource management as well as a new approach to how data is managed and exposed. The ultimate automation target is to enable largely autonomous networks which are driven by high-level policies (also known as intents) and rules () defined by the service provider or a network slice tenant. Autonomous networks must be able to self-configure, self-monitor, self-heal and self-optimize without further human intervention. This requires a new architecture framework that is designed for closed-loop control and optimized for data-driven machine learning and artificial intelligence algorithms.

The ETSI Industry Specification Group (ISG) Zero touch network and Service Management (ZSM) [1] was formed in December 2017 with the goal to define a new architectural framework for end-to-end, cross-domain/cross-technology service and network that enables automation at scale and allows all operational processes and tasks – delivery, deployment, configuration, assurance, and optimization – to be executed automatically. The root design goal of ZSM is to enable zero-touch automated network and service management in a multi-vendor environment, supporting multiple way of providing automation. Network and service intelligence, as well as orchestration, are the new battlegrounds for network automation as to a large extent they are replacing human intelligence and knowledge. The ZSM architecture aims to enable new levels of agility, responsiveness and efficiency in launching new services at scale. While a first version of the architecture has been developed, the design and specification work is still in progress.

The architectural principles and requirements were agreed on with the aim of shaping the architectural baseline and guiding its further development during the standardization process. The architecture is service-based, modular, flexible and extensible. It allows deployments that can be adapted to different volumes of managed entities and/or to various scales of the geographic distribution of these entities. Modules can be independently deployed and scaled. The functional components of the architecture will also be designed for failure – so that management services can cope with failure of themselves and of the infrastructure without or only with modest service degradation.

 

Figure 1: ZSM Architecture

As depicted in Figure 1 above, the architecture supports the separation of management and automation into different areas of concern: (network) domain management and end-to-end (cross-domain) service management; both are responsible for fulfillment (orchestration and control), assurance and intelligent automation within their scopes.

A (network) Management Domain is the scope of management inside an operator that is typically delineated by an administrative or technological boundary (e.g. wireless domain, fixed access domain, IP/optical domain, etc.). Cloud and network resources are managed inside a network domain, including connectivity, physical and/or virtual network functions. (Network) Management Domain addresses its own sphere of expertise and abstracts the complexity of the domain resources towards management components outside the domain. Several management domains may be composed into a higher-level management domain.

End-to-end (cross-domain) Service Management Domain manages end-to-end, customer-facing services and coordinates them across domains.

Decoupling (network) Management Domain from End-to-end (cross-domain) Service Management Domain prevents monolithic systems, reduces complexity in the entire service and enables domain and end-to-end management to evolve independently. The architecture supports open interfaces as well as model-driven service and resource abstraction.

The architecture allows operational data to be kept separate from the management applications, enabling efficient access to data and cross-domain data exposure (e.g. topology, telemetry data) that can be leveraged by network and service intelligence capabilities (e.g. data-driven machine learning, artificial intelligence and other technologies for automation). The architecture is designed to enable closed-loop automation (connecting assurance and fulfillment processes) at the network and service management levels where the automated decision-making mechanisms (e.g. self-optimization, automated service assurance) can be bounded by rules and policies.

Each domain includes functional components that perform specific task(s) and expose one or more management services via service interface(s). Some of the services are internal services and can only be consumed by authorized functional components inside the domain. Other services can be exposed and also consumed by authorized functional components outside the domain (including those contained in the E2E service management domain and the digital storefront, as well as other domains). The management services within the management domain are assembled into logical groups needed for closed-loop automation, such as domain control services, domain orchestration services, domain intelligence services and domain assurance services. Other groups may be added as needed.

The management services are provided and consumed through the integration fabrics, following either the request-response / request-response-notify pattern for service invocation or the publish-subscribe pattern for live event streaming.

The ISG ZSM is currently working on the description and specification of the management services. The draft specification ETSI GS ZSM 002 "ZSM Reference Architecture" is publicly available in the ETSI ZSM Open Area [2].

For the end-to-end network and service automation solution work, existing standard specifications and solutions (both ETSI and external entities) will be analyzed and where appropriate leveraged to avoid duplication and maximize synergies. The ISG will conduct a gap analysis to ensure that existing activities are not duplicated and that the barriers to end-to-end automation are addressed. If a gap can be addressed by an existing body, that body will be encouraged to do the work to avoid duplication. The ISG will work to fill the remaining gaps.

 
References 

[1] ETSI ZSM - https://www.etsi.org/technologies-clusters/technologies/zero-touch-network-service-management

[2] http://docbox.etsi.org/ISG/ZSM/Open

  

Nurit SprecherNurit Sprecher

Nurit Sprecher at Nokia serves as a vice-chair of the ETSI ISG ZSM. Before, Nurit was the founding Chair of the ETSI MEC ISG. With 25 years of experience in the telecommunication industry, she has spent many years working as a principle system architect and technologist, defining the carrier-grade network and service architecture evolution and working on system design. Nurit has contributed to many projects carried out in the IETF, ITU-T SG15, IEEE, BBF and ETSI and has participated in core discussions on the Next Generation Network with Tier-1 carriers and a number of governments.
Nurit is a contributing author to many publications. She contributed to a workshop paper for the International Conference on Communications 2016 (ICC'16), entitled "Architecture Vision for the 5G era: Cognitive and Cloud optimized Network Evolution".
Nurit leads the Nokia standardization strategy and activities in the areas of management, virtualization and application enablement and is a distinguished member of the Nokia technical committee.

 

Editor:

Marie-Paule OdiniMarie-Paule Odini

Marie-Paule Odini is Distinguished Technologist in HPE focused on customer innovation and emerging trends in the communication industry including NFV, SDN, IoT, big data and 5G. She drives technical discussions towards 5G with customers and inside HPE. Active in industry forums and standard organization she held key positions such as ETSI NFV Vice Chair, IEEE SDN Chair, Editorial board member, 5G Americas key contributor and more recently co-chair of TIP (Telecom Infra Project) E2E network slicing project.

 

Intent Based Modelling Key to 5G & ZSM

Marie-Paule Odini, Hewlett Packard Enterprise; and Andreas Krichel, Hewlett Packard Enterprise

IEEE Softwarization, November 2018
 

Introduction – Evolution to a More Dynamic Network Environment

Telecom Networks used to be rather static, hierarchical and with siloes: a fixed-broadband network with DSLAM (Digital Subscriber Line Access Multiplexer) and home CPE (Customer Premise Equipment) as leaves or a mobile network with a Core Network and base stations as leaves. With the move to softwarization and more dynamic allocation of resources on demand, for new services or to expand capacity, network topology tends to evolve more often. With 5G [11], this granularity and complexity of the network is exploding in terms of new resource types, service types, policies, access rights, instances and frequency of the changes. To keep up with this transformation and prevent manual errors, more and more automation is introduced in the network operations with an ultimate goal to become ‘zero touch’ as discussed in ETSI ZSM (Zero Touch Service Management) [8].

 Figure 1 – Network evolution from Silo to flattened Network

As an example, dynamicity becomes a challenge when looking how traditional management systems operate networks today. They collect alarms from the different components of the network and map these alarms to a hierarchical model with Central and Regional Data Centers, and dedicated hardware systems. If resources start to be deployed dynamically and assigned to existing or new services dynamically, Root-Cause-Analysis needs to keep track of where and how resources and services are at a given time.

With NFV (Network Function Virtualization) [3] which is a big trend in telecom networks and a first step towards 5G architecture with stateless functions and Service Based Architecture (SBA), a number of paradigms are changing dramatically:

  • Software functions do not map 1-to-1 to physical equipment or geographic location
  • Software functions move inside a same physical equipment or across different physical equipment
  • Software functions may be shared across different networks
  • Software functions may be deployed inside Virtual Machine (VM) or Container, and associated to different management systems
  • Software functions may gain or lose capabilities along their lifetime and report different alarm types
  • Software functions may move to different locations while still serving the same customer services

With 5G, existing Network Functions (NF) are redesigned, decomposed, with some common enablers shared across different functions. Network Service (NS) instances are now composable of these new software functions changing dynamically, being re-configured and re-chained on the fly, thus increasing the complexity of managing these functions. At the same time, network function features will be deployed in short intervals. Hence, the orchestration of the service instances as well as their service development lifecycle will change continuously. Our classic OSS (Operation Support Systems) approaches are not made for this agility and do not fit these needs anymore.

Intent based API

Intent based is not a new concept. HP introduced and made early contributions back in 2015 on Intent for SDN at the Open Networking Foundation (ONF), which translated into Intent Based Northbound (NBI) API specification [4]. The message was “Don’t tell me what to do. Tell me what you want”. ONF Intent for network control APIs was largely adopted in the industry as described in a 2016 IEEE SDN article [5]. We also introduced the same concept in ETSI NFV not only for SDN or network resource orchestration [6] but suggested to investigate for other NFV interfaces [7], being overall Resource Orchestration (Compute, Network, Storage) but also Network Orchestration.

With Service Orchestration sitting on top of Network Orchestration same principle can now be applied to this layer and embrace other technologies that somewhat expand from the initial ETSI NFV architecture to a set of layers as described in Figure 2.

Figure 2 – Intent based API across the full stack, up to Service Orchestration 

 

Intent Based Modeling

As a consequence of using an intent-based API, a mapping is required between the intent (what you want) and the request to the underlying layers (what to do). In traditional more static networks, this mapping could also be static and follow the hierarchical model of the topology and resource-network-service relatively static mapping. But in an environment where Service Orchestration sits on top of NFV and SDN, with more dynamic networks, new thinking about intent-based modelling is required. It differs from classic information modeling as defined by TMF (Tele-Management Forum) with CFS/RFS (Customer Facing Service/Resource Facing Service) hierarchies [8].

Looking at future network services or even slicing, we may want to compose networks from one or multiple subdomains or operators, and mix Physical Network Functions (PNF) or Virtual Network Functions (VNF or CNF-container based functions). A main benefit of an intent-based model is that changes in the underlying infrastructure do not directly impact the model. Intent is invariant and portable. For instance, if a given function is moving from being physical to virtual, or to a different location, the overall Network Service (NS) intent model remains the same, but the interpretation of the model would translate the request (per policy) from being sent to a PNF management function to a VNF or CNF management function. Similarly, the northbound API would not change.

Intent-based modelling also contains the behavior needed to build the service by composing subordinated services and underlying software functions (micro-services). These policies enable a generic intelligent engine to interpret the need at runtime. There is no workflow anymore. Thanks to the intent model, and the current state of instances, the engine always finds a consistent state.

The model description must capture the entire semantics of the model, not just the data structure. We can call it the reason behind the model. If the reason is not expressed, the “intelligent” engine would not be able to build the prescription and hence unable to adapt the system to the new situation. To gain flexibility with changing situations (e.g. service variants or component status), it is important to express the policies taking a current context or status into account, within the service model description.

Dynamic Service Descriptors (DSD) and Orchestration Engine

To support Intent Based Modeling, a new concept of Dynamic Service Descriptors (DSD) is introduced. DSD declare the service Objects, their Relationship and behavior Policies, all dynamic.

   Figure 3 - Dynamic service descriptor (DSD) concept

The intent-based model is a set of Relationships that goes beyond the classic definition of service hierarchies, and allows a (directed) graph: each service object is requested by other service objects and may request other service objects.

At runtime, each service instance has a well-defined status. Transition of the status can be associated to a concrete action request coming from another management system.

With intent based modelling and declarative service descriptors (such as DSD), it is possible to build a generic engine, which generates and orchestrates actions to change the service’s state, when requested by another system, such as order management or automatically thanks to some AI (Artificial Intelligence) system.

Figure 4 – Orchestration with Dynamic service descriptor (DSD) concept

Cognitive functions allow to detect problems in a probabilistic approach or add value by optimizing infrastructure capacity use. This leads to Zero Touch Service Management (ZSM).

The concepts described in this paper are being implemented [9] and contributed to ETSI ZSM [10] [11].

References:

[1] – IEEE SDN Newsletter – SDN and NFV Evolution to 5G, Sept 2017

[2] - ETSI ZSM - https://www.etsi.org/technologies-clusters/technologies/zero-touch-network-service-management

[3] – ETSI NFV Architectural Framework – https://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf

[4] – ONF Intent Based Networking - https://www.opennetworking.org/news-and-events/blog/intent-based-networking/

[5] IEEE SDN, Sept 2016 – Fighting your way through the jungle of Intent

[6] – Report on SDN usage in an NFV environment - https://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/005/01.01.01_60/gs_NFV-EVE005v010101p.pdf

[7] ETSI NFV contribution, Aug 2015 - NFVEVE(15)000353 New Feature: Intent and NFV

[8] TMForum SID Model - https://www.tmforum.org/information-framework-sid/

[9] - https://www.sdxcentral.com/resources/nfv-sdn-training-sdnuniversity-archives/hpe-intent-based-orchestration-webinar/

[10] – ETSI ZSM Operator White Paper - https://portal.etsi.org/TBSiteMap/ZSM/OperatorWhitePaper

[11] – ETSI ZSM Contribution – ZSM(18)000196 MoA for intent based orchestration

 

Marie-Paule Odini
Marie-Paule Odini is Distinguished Technologist in HPE focused on customer innovation and emerging trends in the communication industry including NFV, SDN, IoT, big data and 5G. She drives technical discussions towards 5G with customers and inside HPE. Active in industry forums and standard organization she held key positions such as ETSI NFV Vice Chair, IEEE SDN Chair, Editorial board member, 5G Americas key contributor and more recently co-chair of TIP (Telecom Infra Project) E2E network slicing project.

 

 

Andreas KrichelAndreas Krichel 

Andreas Krichel is Chief Architect for Orchestration in the Global OSS Solutioning team within HPE’s Communications & Media Solutions Business Unit. He shaped HPE’s Service Director product for intent based service orchestration including closed loop, based on HPE’s intent based service modelling with a generic engine. Andreas consults and proposes solutions to manage today’s and future services based on 5G Networks, Slicing, Edge, based on NFV/SDN or hybrid for Enterprise and Consumer Services. His track record for OSS solutions and architectures started 1994, it includes presentations and demos at various industry events. Andreas contributes actively to ETSI ZSM driving zero-touch operations with a focus on intent based service orchestration.

 

Editor:

Syed Hassan AhmedSyed Hassan Ahmed

Syed Hassan Ahmed (S'13, M'17, SM'18) is an Assistant Professor in the Department of Computer Science at Georgia Southern University1, Statesboro Campus, USA. Previously, he was a Post-Doctoral Fellow in the Department of Electrical and Computer Engineering, University of Central Florida, Orlando, USA. He completed his Bachelors in Computer Science from Kohat University of Science & Technology (KUST), Pakistan and Master combined Ph.D. Degree from School of Computer Science and Engineering (SCSE), Kyungpook National University (KNU), Republic of Korea (South Korea). In summer 2015, he was also a visiting researcher at the Georgia Tech, Atlanta, USA. Collectively, he has authored/co-authored over 130 international publications including Journal articles, Conference Proceedings, Book Chapters, and 03 books. In 2016, his work on robust content retrieval in future vehicular networks lead him to win the Qualcomm Innovation Award at KNU, Korea. Dr. Hassan's research interests include Sensor and Ad hoc Networks, Cyber-Physical Systems, Vehicular Communications, and Future Internet. He is currently the Member of Board of Governors and IEEE VTS liaison to IEEE Young Professionals society. 

Furthermore, Dr. Hassan is a Senior IEEE and ACM Professional member, serving as a TPC Member or Reviewer in 100+ International Conferences and Workshops including IEEE Globecom, IEEE ICC, IEEE CCNC, IEEE ICNC, IEEE VTC, IEEE INFOCOM, ACM CoNEXT, ACM MobiHoc, ACM SAC, and many more. Furthermore, he has been reviewing papers for 30+ International Journals including IEEE Magazines on Wireless Communications, Networks, Communications, IEEE Communications Letters, IEEE Sensors Letters, IEEE Transactions on Industrial Informatics, Vehicular Technologies, Intelligent Transportation Systems, Big Data, and Mobile Computing. Moreover, Dr. Hassan has been an editorial member of more than 20 Special Issues with top-ranked journals in Communication Society and serving as an editorial board member of KSII Transactions on Internet & Information Systems, Wiley's Internet Technology Letters, Transactions on Emerging Telecommunications Technologies, IEEE Newsletters on Internet Initiative, Future Directions, and Software Defined Networks.