Study paper Network LSO Final - TEC paper Network LSO Final.pdf · Telecom Engineering Center, Department of Telecommunications, Government of India 1 | P a g e Study Paper on Network

Telecom Engineering Center, Department of Telecommunications, Government of India

1 | P a g e

Study Paper on Network Life Cycle Service Orchestration

U C Meena ADG, R. Saji Kumar Director, Chandra Shekhar DDG, IT Division, Telecom Engineering Center, Department of Telecommunications, New Delhi.

Abstract: LSO is a new software platform that can take a customer order and implement service provisioning, orchestration, fulfillment, service assurance, and monitoring, serving as the central control panel for how services are delivered across the sprawling service provider network. Life

Cycle Service Orchestration(LSO) provides open and interoperable automation of management

operations of connectivity services in a network. The MEF LSO and MANO architecture and framework enables automated management and control of end-to-end Connectivity Services that span multiple provider domains. With the multitude of applications and domains (e.g consumer broadband, mobile backhaul, CDN, mobile packet core, business VPNs) cannot be control by a single software orchestrator or controller rather required a distributed domain orchestrator sharing a global view of services and network provided by an orchestrator of orchestrators or controllers. Open source organizations like OPNFV, OpenDaylight, Open-O and ON.Lab/ONOS/CORD involved in open networking open source initiatives who subscribe to Open interfaces and open APIs. The current development and some of the Use cases for LSO are Xceed Software Suit from Infinera, Netcracker Hybrid Operations Management by Netcracker, Nokia LeanOps OSS portfolio by Nokia, Amdocs Network Cloud Service Orchestrator etc.

Keywords: Life Cycle Service Orchestration(LSO), Operational Support System(OSS), Billing Support Systems(BSS), Software Defined Network(SDN), Network Functional Virtualisation(NFV), OpenFlow, Orchestrator, Management and Orchestration(MANO), Order Fulfillment, Agility, ONOS, OPNFV, Open-O, MEF

1.0 Introduction Life Cycle Service Orchestration binds together legacy Operational Support System(OSS) and Billing Support Systems (BSS) services, newer Software Defined Network(SDN) and Network Functional Virtualisation(NFV) software, and telecom hardware infrastructure. LSO is a new software platform that can take a customer order and implement service provisioning, orchestration, fulfillment, service assurance, and monitoring, serving as the central control panel for how services are delivered across the sprawling service provider network. Figure 1 shows the traditional OSS/BSS diagram where functions like billing, provisioning and operational have been performed for landline, broadband/FTTH and multiplay services. For years these OSS/BSS systems have been proprietary and having interfaces which are programmed to work with open systems like SDN and NFV. In figure 1, the customer with the help of Customer Relationship Management software may place the request of either provisioning the new service or changing the existing plan or terminating the service or request for billing. After placing the request of action, the systems in


2 | P a g e

OSS/BSS interacts with each other through their proprietary interfaces to complete the request placed by inquiring the billing system, database for policy inquiry of service plan or inventory status of resources.

Figure 1: BSNL OSS/BSS and NOC logical Architecture

Here in this NOC logical architecture BSNL uses Metasolv solution for completing the various tasks of provisioning of services in the network, this solution divides the provisioning task into a no various required activities where it configures the policy, check the availability of resources, configuring the available ports of the network elements through the proprietary interfaces named catridges and eMS of the network element. The task of developing these interfaces for variety of network elements requires additional manpower, financial resources and coordination between services provider, network elements manufacturer and the OSS/BSS solution provider. All the problems of proprietary hardware, interfaces are things of the past with the development of open source technologies of SDN, NFV and various standards required.

2.0 Software-defined networking Software-defined networking providers offer a wide selection of competing architectures, but at its most simple, the Software Defined Networking method centralizes control of the network by separating the control logic to off-device computer resources as shown in figure 2. All SDN models have some version of an SDN Controller, as well as southbound APIs and northbound APIs:


3 | P a g e

Controllers: The “brains” of the network, SDN Controllers offer a centralized view of the overall network, and enable network administrators to dictate to the underlying systems (like switches and routers) how the forwarding plane should handle network traffic. Southbound APIs: Software-defined networking uses southbound APIs to relay information to the switches and routers “below.” OpenFlow, considered the first standard in SDN, was the original southbound API and remains as one of the most common protocols. Despite some considering OpenFlow and SDN to be one in the same, OpenFlow is merely one piece of the bigger SDN landscape. Northbound APIs: Software Defined Networking uses northbound APIs to communicates with the applications and business logic “above.” These help network administrators to programmatically shape traffic and deploy services.

Figure 2: Architecture of SDN

3.0 Network functions virtualization Network functions virtualization (NFV) offers an alternative way to design, deploy, and manage networking services. It is a complementary approach to software-defined networking (SDN) for network management. While they both manage networks, they rely on different methods. While SDN separates the control and forwarding planes to offer a centralized view of the network, NFV primarily focuses on optimizing the network services themselves. In figure 3 NFV decouples the network functions, such as network address translation (NAT), firewalling, intrusion detection, domain name service (DNS), and caching, to name a few, from proprietary hardware appliances so they can run in software. It’s designed to consolidate and deliver the networking components needed to support a fully virtualized infrastructure – including virtual servers, storage, and even other networks. It utilizes standard IT virtualization technologies that run on high-volume service, switch and storage hardware to virtualize network


4 | P a g e

functions. It is applicable to any data plane processing or control plane function in both wired and wireless network infrastructures. With this, several providers banded together and created the NFV ISG under the European Telecommunications Standards Institute (ETSI). The creation of ETSI NFV ISG resulted in the foundation of NFV’s basic requirements and architecture.

Figure 3: Comparison of Traditional Network with Virtualised Network Function

4.0 Lifecycle Service Orchestration (LSO)

Open and interoperable automation of management operations over the entire lifecycle of Layer 2 and Layer 3 Connectivity Services. This includes fulfillment, control, performance, assurance, usage, security, analytics and policy capabilities, over all the network domains that require coordinated management and control in order to deliver the service. Since Connectivity Services in a Network shall be agile, assured, and orchestrated, they rely on coordinated orchestration of distributed capabilities across potentially many internal networks and many network operators to enable end-to-end management. Such orchestration is executed for the entire Connectivity Service lifecycle where each functional area of the lifecycle is further streamlined and automated, from Product Offering definition through service fulfillment, control, assurance, and billing. For example, the fulfillment phases of the service lifecycle are focused on automating the inter-provider business interactions and interfaces for the buyer-seller process, including the product catalog, order, service location, and service qualification. Each of these phases is based on the Product Offering defined by the selling carrier. Since the Product Offering is fully defined in the product catalog, a model-driven approach is used to execute the subsequent stages of the service lifecycle, including pre-order, order, and service orchestration. By using a model-driven approach along with abstractions representing products, services, and resources, LSO ensures an agile approach to streamlining and automating the entire service lifecycle in a sustainable fashion.


5 | P a g e

Figure 4: Network Orchestrator implementation view

The figure 4 shows service provider goals for SDN and NFV include achieving a holistic view of their networks and services agility across their networks. But for achieving this, the network should have distributed control mechanism. With the multitude of applications and domains (e.g consumer broadband, mobile backhaul, CDN, mobile packet core, business VPNs) cannot be control by a single software orchestrator or controller rather required a distributed domain orchestrator sharing a global view of services and network provided by an orchestrator of orchestrators or controllers. In LSO, Connectivity Services are orchestrated by Service Providers across all internal and external network domains from one or more network operators. These network domains may be operated by communications Service Providers, data center operators, enterprises, wireless network operators, virtual network operators, or content providers. LSO encompasses all network domains that require coordinated end-to-end management and control to deliver Connectivity Services. Within each provider domain, the network infrastructure may be implemented with traditional WAN technologies, as well as NFV and/or SDN. LSO capabilities not only dramatically decrease the time to establish and modify the characteristics of the Connectivity Service, but also assure the overall service quality and security for these services.

5.0 MEF Model for SDN Orchestration LSO The service lifecycle addresses each functional area from Product Offering definition through service fulfillment, control, assurance, and billing.

5.1. The high level functional requirements for LSO functional management entities are as following:


6 | P a g e

5.1.1. Agile Product / Service Design Product and Service development lifecycle management agility is supported by LSO with its abilities to rapidly model or import modular model specifications from different layers of abstractions such as Product Offering, Product, Service, Service Component, and Resource.

5.1.2. Order Fulfillment and Service Control Order Fulfillment and Service Control support the orchestration of provisioning related activities involved in the fulfillment of a Customer order or a service control request, including the tracking and reporting of the provisioning progress. This breaks down into multiple functional orchestration areas:

Order Fulfillment Orchestration: deals with decomposing a customer order into one or multiple service provisioning activities and orchestrating of all customer order-related fulfillment activities;

Service Configuration and Activation Orchestration: responsible for the design, assignment, and activation activities for the end-to-end service and/or some or all Service Components;

Service Control Orchestration: permits the service to be dynamically changed within specific bounds described in policies that are established at the time of provisioning;

Service Delivery Orchestration: responsible for the service delivery via network implementation delegation of each Service Component to their respective delivery system or mechanism;

Service Activation Testing Orchestration: coordinates all service activation testing activities, for parts and/or the complete end-to-end service.

5.1.2.1. Order Fulfillment Orchestration

Order Fulfillment Orchestration is triggered from a Customer order, generally originating from a business application such as a Customer relationship management system or order entry system. This set of functionality will deliver an order initiated rapid on-demand customer experience provided all activities are automated. Its responsibilities include, but are not limited to:

Scheduling, assigning and coordinating Customer provisioning related activities; Generating the respective service creation / modification / move / deletion

request(s) based on specific Customer orders; - Undertaking necessary tracking of the execution process;

Adding additional information to an existing Customer order under execution; Modifying information in an existing Customer order under execution; - Canceling a

Customer order when the initiating sales request is cancelled; Monitoring the jeopardy status of Customer orders, and escalating Customer order

status as necessary in accordance with local policy; Instantiating, when appropriate, an event for the billing system; and Indicating completion of a Customer order by modifying the Customer order status.


7 | P a g e

5.1.2.2. Service Configuration and Activation Orchestration Responsibilities of the Service Configuration and Activation Orchestration include, but are not limited to:

Verifying whether specific Service Request sought by Customers are feasible; - Decomposition of the Service into Service Components;

Allocating the appropriate specific service parameters within each Service Component to support service requests, control requests, or requests from other processes;

Reserving specific service related resources (if needed) for a given period of time until the initiating Customer order is confirmed, or until the reservation period expires (if applicable);

Configuring specific services, as appropriate; Recovery of specific services; Updating of the Service state information to reflect that the specific service has been

allocated, modified or recovered; Assigning and tracking Service Component provisioning activities; Managing service provisioning jeopardy conditions (e.g., Conditions that add to the risk

of missing a confirmed due date or activity required to continue processing the Service Request, such as: capacity is not available, capability is not supported, etc.); and

Tracking progress on service configurations and activations.

5.1.2.3. Service Control Orchestration While Order Fulfillment Orchestration deals with establishing or modifying a service through the ordering process, Service Control permits the service to be dynamically changed within specific bounds described in policies that are established at the time of ordering. After a service is provisioned and established, LSO may enable Service Control to Customers / parties, such as the ability to modify attributes subject to schedule policies and service constraint policies. Service Control Orchestration responsibilities include, but are not limited to:

Scheduling, assigning and coordinating service control related activities; Undertaking necessary tracking of the execution process of service control requests; Adding additional information to an existing service control request under execution; Modifying information in an existing service control request under execution; Modifying the service control request status, and indicating completion of a service

control request; Canceling a service control request; Monitoring the jeopardy status of service control requests, and escalating service

control requests as necessary; Instantiating, when appropriate, an event for the billing system to capture the policy

constrained change.


8 | P a g e

5.1.2.4. Service Delivery Orchestration Service Delivery Orchestration is responsible for coordinated execution of the service delivery orchestration plan, considering dependencies and such, generated by Service Configuration and Activation Orchestration, delegating and tracking the actual Service Components implementation to various delivery or implementation systems or methods, such as:

One or multiple Network Domain Controllers (e.g., subnetwork connectivity); An NFV Orchestrator (e.g., virtual CPE delivery); A request for an Access Provider product order for off-net Service Components (e.g.,

EAccess); Any other system, such as a workforce management system (e.g., last mile fiber

installation with human resources) or Supply Chain Management (e.g., delivery of a physical CPE).

5.1.2.5. Service Testing Orchestration Service Testing Orchestration plays a critical role within LSO by automating the test (including Service Activation Testing and In-Service Testing) and verification of Connectivity Services, seamlessly, across multiple operator networks.

5.1.3. Service Problem Management for LSO Service Problem Management capabilities for LSO support alarm surveillance, including the detection of errors and faults. LSO may receive trouble-related information about the Service, either end-to-end or per each Service Component. The information is organized to facilitate the evaluation of the overall performance and status associated with the Customer’s Services. Customers may be provided with trouble-related information by LSO so that they may track the service impact and status of trouble resolution.

5.1.4. Service Quality Management for LSO Service Quality Management capabilities in LSO include the collection of service performance information (e.g., delay, loss, etc.) in support of key quality indicators across all network operators who participate in delivering the connectivity service. This also includes gathering of feedback from the Customer, including Customer-provided performance measurements. Service quality is analyzed by comparing the service performance metrics with the service quality objectives described in the SLS. The results of the service quality analysis are provided to the Customer as well as information about known events that may impact the overall service quality (e.g., maintenance events, congestion, relevant known problems, demand peaks, etc.). LSO Service Quality Management capabilities also include capacity analysis in support of traffic engineering, traffic management, and service quality improvement.

5.1.5. Billing and Usage Measurements for LSO Billing and Usage Measurements capabilities in LSO enable operators to gather and provide usage measurements, traffic measurements, and service-related usage events (e.g., changes in service bandwidth, etc.) describing the usage of Service Components and associated resources. LSO billing and usage measurement capabilities are responsible for the collection and correlation of such information relative to specific Connectivity Services.


9 | P a g e

5.1.6. Security Management for LSO

Security Management in LSO provides for the protection of management and control mechanisms, controlled access to the network, and controlled access to service-related traffic that flows across the network. Such security management capabilities support the authentication of users and applications and provide access control to the variety of capabilities on the APIs supporting management and control based on the roles assigned to each authorized user. The security management capabilities of LSO include encryption and key management to ensure that only authenticated users are allowed to successfully access the management and control entities and functions.

5.1.7. Analytics for LSO Analytics capabilities in LSO support the fusion and analysis of information among management and control functionality across management domains in order to assemble a relevant and complete operational picture of the end-to-end Connectivity Services, Service Components, and the supporting network infrastructure – both physical and virtual. Analytics ensures that information is visible, accessible, and understandable when needed and where needed to accelerate decision-making. For example, LSO analytics may utilize service fulfillment, control, and usage information to predict and trend service growth for the network operator.

5.1.8. Policy-based Management for LSO The behavior of LSO may be prescribed by the set of rules under which the LSO orchestration, management and control logic must operate. Service policies may be encoded in such rules in order to describe and design the dynamic behavior of Services. LSO policy-based management capabilities provide rules-based coordination and automation of management processes across administrative domains supporting effective configuration, assurance, and control of services and their supporting resources.

5.1.9. Customer Management for LSO There are many types of interactions between Customers and Service Providers that are relevant to LSO. For example, a Service Provider may interact with potential Customers to determine serviceability of a Product Offering, helping to ensure that the underlying infrastructure is both capable and available to support the desired Product Offering or Service for the Customer.

5.1.10. Partner Management for LSO In support of LSO, the Service Provider will interact with Partners. For example, a Partner may interact with the Service Provider to help the Service Provider to determine Service feasibility.

5.2. LSO Reference Architecture The LSO Reference Architecture characterizes the management and control domains and functional management entities that enable cooperative LSO capabilities. The architecture also


10 | P a g e

identifies the Management Interface Reference Points, the logical points of interaction between specific functional management entities. These Management Interface Reference Points are further defined by Interface Profiles and implemented by APIs. The High Level LSO Reference Architecture is shown in Figure 5.

Figure 5: LSO Reference Architecture

5.2.1. Definition of LSO Functional Management Entities The LSO functional management entities within the LSO ecosystem that are involved in providing the cooperative LSO capabilities are as follows:

Business Applications (BUS): The Service Provider functionality supporting Business

Management Layer functionality (e.g., product catalog, ordering, billing, relationship management, etc.).

Service Orchestration Functionality (SOF): The set of service management layer functionality supporting an agile framework to streamline and automate the service lifecycle in a sustainable fashion for coordinated management supporting design, fulfillment, control, testing, problem management, quality management, usage measurements, security management, analytics, and policy-based management capabilities providing coordinated end-to-end management and control of Layer 2 and Layer 3 Connectivity Services.

Infrastructure Control and Management (ICM): The set of functionality providing domain specific network and topology view resource management capabilities including configuration, control and supervision of the network infrastructure. ICM is responsible for providing coordinated management across the network resources within a specific


11 | P a g e

management and control domain. For example, a system supporting ICM capabilities provides connection management across a specific sub network domain.

Element Control and Management (ECM): The set of functionality supporting element management layer capabilities for individual network elements. While a system supporting ECM capabilities provides for the abstraction of individual infrastructure elements, it may reflect the element view for multiple elements, but not provide coordinated management across the set of elements.

Customer Application Coordinator (CUS): A functional management entity in the Customer domain that is responsible for coordinating the management of the various service needs (e.g., compute, storage, network, etc.) of specific applications. The AC supports Customer interactions with the Service Provider to request, modify, manage, control, and terminate Products or Services.

5.2.2. Definition of Management Interface Reference Points Definitions for each Management Interface Reference Point within the LSO Reference Architecture are provided in fig . Each Management Interface Reference Point is identified with a name (e.g., CANTATA), as well as a context identifying the interacting LSO functional management entities (e.g., CUS:BUS).


12 | P a g e

6.0 ETSI Model for NFV Management and Orchestration

Network Functions Virtualisation (NFV) adds new capabilities to communications networks and requires a new set of management and orchestration functions to be added to the current model of operations, administration, maintenance and provisioning. In legacy networks, Network Function (NF) implementations are often tightly coupled with the infrastructure they run on. NFV decouples software implementations of Network Functions from the computation, storage, and networking resources they use. The virtualisation insulates the Network Functions from those resources through a virtualisation layer.

The Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework has the role to manage the NFVI and orchestrate the allocation of resources needed by the NSs and VNFs. Such coordination is necessary now because of the decoupling of the Network Functions software from the NFVI.

The virtualisation principle stimulates a multi-vendor ecosystem where the different components of NFVI, VNF software, and NFV-MANO architectural framework entities are likely to follow different lifecycles (e.g. on procurement, upgrading, etc.). This requires interoperable standardised interfaces and proper resource abstraction among them.

6.1. Management and Orchestration architectural framework Overview The NFV Architectural Framework (ETSI GS NFV 002) shown in figure 6 provided a functional architecture with more distribution and detailed description of the NFV Management and Orchestration (NFV-MANO) functionality, as well as a description of the reference points between NFV-MANO functional blocks and other functional blocks in the E2E NFV reference architecture.

Figure 6 : NFV-MANO architectural framework


13 | P a g e

6.1.1. The following entities from the NFV architectural framework (ETSI GS NFV 002) are considered

within scope of the NFV-MANO architectural framework: a) Functional blocks identified as belonging to NFV Management and Orchestration (NFV-

MANO). b) Other functional blocks that interact with NFV-MANO via reference points. c) All reference points that enable communications to, from, and within NFV-MANO.

6.1.1.1. The NFV-MANO architectural framework identifies the following NFV-MANO functional

blocks: • Virtualised Infrastructure Manager (VIM). • NFV Orchestrator (NFVO). • VNF Manager (VNFM).

6.1.1.2. NFV-MANO architectural framework identifies the following data repositories: • NS Catalogue. • VNF Catalogue. • NFV Instances repository. • NFVI Resources repository.

6.1.1.3. The NFV-MANO architectural framework identifies the following functional blocks that share reference points with NFV-MANO:

• Element Management (EM). • Virtualised Network Function (VNF). • Operation System Support (OSS) and Business System Support functions (BSS). • NFV Infrastructure (NFVI).

6.1.1.4. The NFV-MANO architectural framework identifies the following main reference points: • Os-Ma-nfvo, a reference point between OSS/BSS and NFVO. • Ve-Vnfm-em, a reference point between EM and VNFM. • Ve-Vnfm-vnf, a reference point between VNF and VNFM. • Nf-Vi, a reference point between NFVI and VIM. • Or-Vnfm, a reference point between NFVO and VNFM. • Or-Vi, a reference point between NFVO and VIM. • Vi-Vnfm, a reference point between VIM and VNFM.

6.1.2. NFV-MANO architectural framework functional blocks are: 6.1.2.1. NFV Orchestrator (NFVO)

The NFV Orchestrator has the following functions: • The orchestration of NFVI resources across multiple VIMs, fulfilling the Resource

Orchestration functions. • The lifecycle management of Network Services, fulfilling the Network Service Orchestration

functions.


14 | P a g e

• Network Service instantiation and Network Service instance lifecycle management, e.g. update, query, scaling, collecting performance measurement results, event collection and correlation, termination. • Management of the instantiation of VNF Managers where applicable. • Management of the instantiation of VNFs, in coordination with VNF Managers. • Validation and authorization of NFVI resource requests from VNF Managers, as those may impact Network Services (granting of the requested operation needs to be governed by policies). • Policy management and evaluation for the Network Service instances and VNF instances (e.g. policies related with affinity/anti-affinity, scaling, fault and performance, geography, regulatory rules, NS topology, etc.). • Policy management and enforcement for the Network Service instances and VNF instances (e.g. NFVI resources access control, reservation and/or allocation policies, placement optimization based on affinity and/or anti-affinity rules as well as geography and/or regulatory rules, resource usage, etc.). • Collect usage information of NFVI resources by VNF instances or groups of VNF instances, for example, by collecting information about the quantity of NFVI resources consumed via NFVI interfaces and then correlating NFVI usage records to VNF instances.

6.1.2.2. VNF manager (VNFM) The VNF Manager is responsible for the lifecycle management of VNF instances. Each VNF instance is assumed to have an associated VNF Manager. A VNF manager may be assigned the management of a single VNF instance, or the management of multiple VNF instances of the same type or of different types. The following list expresses the non-exhaustive set of functions performed by the VNF Manager function: • VNF instantiation, including VNF configuration if required by the VNF deployment template (e.g. VNF initial configuration with IP addresses before completion of the VNF instantiation operation). • VNF instantiation feasibility checking, if required. • VNF instance software update/upgrade. • VNF instance modification. • VNF instance scaling out/in and up/down. • VNF instance-related collection of NFVI performance measurement results and faults/events information, and correlation to VNF instance-related events/faults. • VNF instance assisted or automated healing. • VNF instance termination. • VNF lifecycle management change notification. • Management of the integrity of the VNF instance through its lifecycle. • Overall coordination and adaptation role for configuration and event reporting between the VIM and the EM.

6.1.2.3. Virtualised infrastructure manager (VIM)


15 | P a g e

The Virtualised Infrastructure Manager (VIM) is responsible for controlling and managing the NFVI compute, storage and network resources, usually within one operator's Infrastructure Domain (e.g. all resources within an NFVI-PoP, resources across multiple NFVI-POPs, or a subset of resources within an NFVI-PoP). The following list expresses the set functions performed by the VIM: • Orchestrating the allocation/upgrade/release/reclamation of NFVI resources(including the optimization of such resources usage), and managing the association of the virtualised resources to the physical compute, storage, networking resources. Therefore, the VIM keeps an inventory of the allocation of virtual resources to physical resources, e.g. to a server pool. • Supporting the management of VNF Forwarding Graphs (create, query, update, delete), e.g. by creating and maintaining Virtual Links, virtual networks, sub-nets, and ports, as well as the management of security group policies to ensure network/traffic access control. • Managing in a repository inventory related information of NFVI hardware resources (compute, storage, networking) and software resources (e.g. hypervisors), and discovery of the capabilities and features (e.g. related to usage optimization) of such resources. • Management of the virtualised resource capacity (e.g. density of virtualised resources to physical resources), and forwarding of information related to NFVI resources capacity and usage reporting. • Collection of performance and fault information (e.g. via notifications) of hardware resources (compute, storage, and networking) software resources (e.g. hypervisors), and virtualised resources (e.g. VMs); and forwarding of performance measurement results and faults/events information relative to virtualised resources.

6.1.2.4. NS Catalogue The NS Catalogue represents the repository of all of the on-boarded Network Services, supporting the creation and management of the NS deployment templates (Network Service Descriptor (NSD), Virtual Link Descriptor (VLD), and VNF Forwarding Graph Descriptor (VNFFGD) via interface operations exposed by the NFVO.

6.1.2.5. VNF Catalogue The VNF Catalogue represents the repository of all of the on-boarded VNF Packages, supporting the creation and management of the VNF Package (VNF Descriptor (VNFD), software images, manifest files, etc.) via interface operations exposed by the NFVO. Both NFVO and VNFM can query the VNF Catalogue for finding and retrieving a VNFD, to support different operations (e.g. validation, checking instantiation feasibility). Clause 6 describes in detail the type of information elements captured in the VNFD.

6.1.2.6. NFV Instances repository


16 | P a g e

The NFV Instances repository holds information of all VNF instances and Network Service instances. Each VNF instance is represented by a VNF record, and each NS instance is represented by an NS record. Those records are updated during the lifecycle of the respective instances, reflecting changes resulting from execution of NS lifecycle management operations and/or VNF lifecycle management operations.

6.1.2.7. NFVI Resources repository The NFVI Resources repository holds information about available/reserved/allocated NFVI resources as abstracted by the VIM across operator's Infrastructure Domains, thus supporting information useful for resources reservation, allocation and monitoring purposes.

6.1.2.8. NFV-MANO reference points The functions performed by various reference points between NFV-MANO functional blocks and between those and other functional blocks.

6.1.2.8.1. Os-Ma-nfvo

This reference point is used for exchanges between OSS/BSS and NFV Orchestrator, and supports the following: • Network Service Descriptor and VNF package management. • Network Service instance lifecycle management:

Network Service instantiation. Network Service instance update (e.g. update a VNF instance that is comprised in the

Network Service instance). Network Service instance query (e.g. retrieving summarised information about NFVI

resources associated to the Network Service instance, or to a VNF instance within the Network Service instance).

Network Service instance scaling. Network Service instance termination.

• VNF lifecycle management: For VNF lifecycle management, the NFV Orchestrator identifies the VNF Manager and

forwards such requests (see Or-Vnfm description). • Policy management and/or enforcement for Network Service instances, VNF instances and NFVI resources (for authorization/access control, resource reservation/placement/allocation, etc.).

6.1.2.8.2. Ve-Vnfm-em This reference point is used for exchanges between EM and VNF Manager, and supports the following: • VNF instantiation. • VNF instance query (e.g. retrieve any run-time information). • VNF instance update (e.g. update configuration). • VNF instance scaling out/in, and up/down. • VNF instance termination. • Forwarding of configuration and events from the EM to the VNFM. • Forwarding of configuration and events regarding the VNF from the VNFM to the EM.


17 | P a g e

NOTE: This reference point is only used if the EM is aware of virtualisation.

6.1.2.8.3. Ve-Vnfm-vnf This reference point is used for exchanges between VNF and VNF Manager, and supports the following: • VNF instantiation. • VNF instance query (e.g. retrieve any run-time information). • VNF instance update (e.g. update configuration). • VNF instance scaling out/in, and up/down. • VNF instance termination. • Forwarding of configuration and events from the VNF to the VNFM. • Forwarding of configuration, events, etc. regarding VNF, from the VNFM to the VNF. • Verification that the VNF is still alive/functional.

6.1.2.8.4. Nf-Vi This reference point is used for exchanges between Virtualisation Infrastructure Manager and NFV Infrastructure, and supports the following: • Aallocate VM with indication of compute/storage resource. • Update VM resources allocation. • Migrate VM. • Terminate VM. • Create connection between VMs. • Configure connection between VMs. • Remove connection between VMs. • Forwarding of configuration information, failure events, measurement results, and usage records regarding NFVI (physical, software, and virtualised resources) to the VIM.

6.1.2.8.5. Or-Vnfm This reference point is used for exchanges between NFV Orchestrator and VNF Manager, and supports the following: • NFVI resources authorization/validation/reservation/release for a VNF. • NFVI resources allocation/release request for a VNF. • VNF instantiation. • VNF instance query (e.g. retrieve any run-time information). • VNF instance update (e.g. update configuration). • VNF instance scaling out/in, and up/down. • VNF instance termination. • VNF package query. • Forwarding of events, other state information about the VNF that may impact also the Network Service instance.

6.1.2.8.6. Or-Vi This reference point is used for exchanges between the NFV Orchestrator and the VIM, and supports the following: • NFVI resource reservation/release. • NFVI resource allocation/release/update.


18 | P a g e

• VNF software image addition/deletion/update. • Forwarding of configuration information, events, measurement results, usage records regarding NFVI resources to the NFV Orchestrator.

6.1.2.8.7. Vi-Vnfm This reference point is used for exchanges between the VNF Manager and the Virtualised Infrastructure Manager, and supports the following: • NFVI resources reservation information retrieval. • NFVI resources allocation/release. • Exchanges of configuration information between reference point peers, and forwarding to the VNF Manager such information for which the VNFM has subscribed to (e.g. events, measurement results, and usage records regarding NFVI resources used by a VNF).

7.0 LSO Open source leaders

List of the open source organizations most involved in open networking open source initiatives who subscribe to Open interfaces and open APIs: OpenDaylight – OpenDaylight is a project within the Linux Foundation focused on building

an extensible open source SDN controller designed for a wide variety of use cases. MEF is working with OpenDaylight to code a set of Northbound APIs that conform to the LSO Presto Reference Point describe in the previous section.

ONOS/CORD – ONOS and CORD are projects within the Linux Foundation focused on the ONOS codebase. ONOS is an open source SDN controller originally focused on CSP WAN deployments but has been extended to provide all the major SDN services needed by CSPs. CORD (Central Office Re-architected as a Data Center) is a project based on ONOS that is focused on supporting connectivity and cloud-based services for residential, enterprise and mobile subscribers.

ON.Lab (Open Networking Laboratory) – an organization founded by SDN inventors and leaders from Stanford University and UC Berkeley to foster an open source community to develop tools and platforms to realize the full potential of SDN. ONOS was created by and continues to be a large part of ON.Lab’s ongoing open source development. The MEF is working an Enterprise version of CORD version with ON.Lab.

OPNFV – a project within the Linux Foundation that brings system level integration, as well as deployment and testing to the OPNFV reference NFV platform to accelerate the transformation of enterprise and service provider networks. OPNFV’s reference platform includes open source components such as OpenDaylight, ONOS, OpenStack, Ceph Storage, KVM, Open vSwitch, DPDK and of course, Linux itself.

Open-O - another project hosted by the Linux Foundation focused on the NFV MANO component and started its life with a heavy Chinese influence, with founders including service providers China Mobile and China Telecom. And Huawei has pledged $30 million for the project over the next three years. ETSI has a parallel project focused on MANO as well, called Open Source MANO (OSM), supported by a different group of vendors and service providers.


19 | P a g e

8.0 Current Development and Use Cases

8.1. Xceed Software Suite The Xceed Software Suite is an open, SDN solution for operators deploying programmable optical transport networks. Xceed is designed for MEF compliant Lifecycle Service Orchestration (LSO) and on demand MEF CE2.0 service creation using MEF 55 LSO application programming interfaces (APIs). The Xceed Software Suite is the only optical transport SDN controller recognized as Powered by Open DayLight. Xceed accelerates service innovation by delivering revenue ready applications for dynamic bandwidth and automating CE2.0 service delivery.


20 | P a g e

8.2. NEC/Netcracker Hybrid Operations Management NEC/Netcracker Hybrid Operations Management (HOM) is focused on enabling virtual and traditional networks to operate simultaneously at scale. HOM leverages years of proven expertise in end-to-end service management and MANO and fills the gaps in today’s solutions for automating hybrid network management, including assurance, continuous optimization, security and stability. HOM provides the following integration capabilities with NFV platforms:

Orchestration of several NFVOs via open standard APIs (REST WS, etc.) NFVO-agnostic service and resource modeling tools (TOSCA, YAML, YANG, etc.) Integration adapters and translation tools for 3rd party models


21 | P a g e

8.3. Nokia LeanOps OSS portfolio Nokia OSS solution uses cloud and virtualization technologies (NFV/SDN) to drive operations automation and increase productivity. The solution provides orchestration across multiple domains and traditional OSS fulfillment and assurance stacks to create an integrated closed-loop ecosystem of operations support systems. Developed around a LeanOps foundation it provides a 3D GUI designed according to Human factors engineering principles, facilitating simplified lifecycle operations and data rich inventory of very large hybrid networks using shared data models. The LeanOps approach uniquely brings together Analytics, Automation, programmability combined with Human Factors engineering for an engaging representation of physical and virtual services. The


22 | P a g e

merging of network and cloud experience with Human factors enables intuitive and efficient interactive actions to be made across the hybrid network.

8.4. Cisco Network Services Orchestrator Enabled by Tail-f Cisco Network Services Orchestrator provides end-to-end automation to design and deliver services faster. Network operators can create and change services without lengthy custom coding or service disruptions. They can automate multivendor devices across their physical and virtual environments, and continually refine and repackage network services to meet new customer needs.


23 | P a g e

8.5. Other Use Cases

8.5.1. FSP Service Manager by ADVA Optical Networks FSP Service Manager enables service providers and enterprises to introduce new levels of efficiency in the operation of optical transport networks. Seamlessly integrated with and built on top of ADVA's FSP Network Manager, the FSP Service Manager provides the capability to quickly and easily manage the end-to- end delivery of high-quality services across networks.

8.5.2. Amdocs Network Cloud Service Orchestrator by Amdocs Ltd. Amdocs Network Cloud Service Orchestrator is an open, catalog-driven solution for service providers transitioning from physical networks to dynamic network-clouds. Amdocs Network Cloud Service Orchestrator continuously designs, fulfills and assures network services, from any virtual network functions (VNF) vendor, over all mainstream CMS and SDN-c.

8.5.3. CENX by CENX Inc. CENX's software fundamentally changes the way service providers view their networks. CENX ingests all of an operator’s network data, across multiple domains and physical and virtual infrastructure. Harnessing the power of big data analytics, CENX visualizes network and service topology, inventory, fault, and performance in a single pane, in real time.

8.5.4. Blue planet SDN/NFV Orchestration Platform by Ciena Blue Planet Division Blue Planet helps service providers transform and grow their business by accelerating the delivery of on-demand services, while reducing costs through automation. Deployed in production networks by service providers worldwide, Blue Planet provides integrated


24 | P a g e

network intelligence within an open architecture, to simplify network operations, drive smarter business decisions, and elevate the customer experience.

8.5.5. CloudSmartz SDxSuite Solution by CloudSmartz

CloudSmartz delivers Software-Defined Networking and Network Function Virtualization innovation to the Telecommunications Industry. CloudSmartz SDxSuite is a Lifecycle Service Orchestration Solution providing on-demand zero-touch provisioning, a single-pane-of-glass portal, self-service automation and reduced OpEx. SDxSuite is a catalyst for SDN revenue generation for service providers that is exceptionally flexible and profitable – fulfilling the promise of SDN.

8.5.6. Comarch NFV/SDN by COMARCH

The Comarch NFV/SDN solution is based on Comarch OSS Suite, which enables CSPs to provide customer services on top of the hybrid network built from “legacy” components and distributed NFVIPoPs connected by an SDN and non-SDN network. Ability to manage hybrid networks by modernizing OSS and thus avoiding the introduction of new silos. Model-driven life cycle management based on modernized service and resource catalog pre-integrated with BSS product catalog.

8.5.7. FlowOne V Solution by Comptel Corporation The FLOWONE V solution, which runs on top of Comptel’s fulfillment stack, incorporates virtualised network function on boarding and service chaining, digital service design and orchestration, and dynamic, closed-loop service assurance. It allows operators to transform their current service delivery processes by connecting the cloud and physical resources (e.g. compute, storage, network) with business management processes and systems (e.g. customer care, billing, customer order management).

8.5.8. EPIC LSO Platform by ECI ECI has designed and developed an open source OpenLSO Innovation Platform (EPIC) that provides customers with a centralized platform that configures and monitors the network. Its standard interfaces can be used by carriers across the board. EPIC will provide fulfillment and assurance of complicated services across legacy, SDN, NFV and cloud networks. It enables both ECI and our customers to write new applications to provide improved customer experience and OPEX reduction by automating processes.

8.5.9. Ericsson Cloud Manager by Ericsson Ericsson Cloud Manager is a cloud management system that handles the life-cycle management of virtual applications, i.e. on-boarding, instantiation, configuration, assurance and application adjustments. It also enables the creation, orchestration, activation, and monitoring of services running on virtualized IT and programmable network resources at consistent levels of quality.


25 | P a g e

8.5.10. HPE Service Director by Hewlett Packard Enterprise HPE Service Director is a new and unique service orchestration OSS solution, automating service lifecycle with a 100% catalog driven approach. It combines Fulfillment and Assurance as a Closed Loop across PNF, VNF and SDN, dramatically reducing time-to-market and time-to-service.

8.5.11. Huawei NetMatrix by Huawei Huawei NetMatrix supports automated service provisioning via a self-service GUI with customization SLA settings, an open API for legacy, SDN, and third-party networks, MANO collaboration capabilities, and a robust southbound integration framework.

8.5.12. OpenLSO by MEF OpenLSO is a MEF-facilitated service orchestration ecosystem that demonstrates integrated use of Open Source solutions and interfaces that adhere to MEF-defined LSO specifications. OpenLSO is primarily aimed at Service Providers that wish to accelerate their adoption of LSO as defined by MEF in order to achieve fullyfeatured end to end service orchestration of MEF-defined service lifecycles.

8.5.13. Oracle Communications Service and Network Orchestration by Oracle Oracle Communication Service and Network Orchestration is an open, multi-domain, crosslayer orchestration solution enabling agile operations for Cloud-based and on-premise services spanning hybrid networks built over physical and virtualized infrastructure. The solution leverages a high-level conceptual model coordinating the catalog-driven design and service assembly, with expert micro-orchestration functions to optimize modularity and maximize re-use. This enables highly scalable operations while reducing complexity and overall TCO over time.

9.0 Conclusion

A significant transformation is taking place in data communication networks that will accelerate network

operator’s abilities to deliver self-service, on demand services over interconnected, multi-operator

networks.


26 | P a g e

Figure 7: SDN and NFV implementation in Orchestration environment

The figure 7 shows how customer can easily place an request for service requirement through next

generation OSS/BSS systems which connected with centralized orchestrators. This orchestrator with open

interfaces and standard APIs will further coordinates with domain controller or orchestrator of SDN and

NFV. The controller of individual domain like SDN and NFV will further coordinates with network resources

and elements to manage, configure and provisioning of services.

The orchestrator helps to build network more agile and dynamic with the demands of real time changes in

services. The SDN and NFV technologies with the help of orchestrator’s enable the transport domain and

service provisioning real time, instantaneous and transparent.


27 | P a g e

Figure 8: Life Cycle Service Orchestration Evolution toward an Orchestrator of Orchestrators

The goal of the service provider and the industry next generation network based on network as a

service principle is to have agile networks that deliver assured connectivity services orchestrated

across network domains between physical or virtual service endpoints. The figure 8 shows how

the different services will be provided by different vendors and global network will require a multi

domain orchestrator to coordinate with individual domain orchestrators.

10.0 Reference

1. An industry Initiative for Third Generation Network and Services by MEF Forum.

2. The Third Network: Lifecycle Service Orchestration Vision by MEF

3. LSO Reference Architecture and Framework 2016 by MEF Forum.

4. ETSI GS NFV-MAN 001 V1.1.1(2014-12) 002: "Network Functions Virtualisation (NFV);

Management and Orchestration".


28 | P a g e

Abbreviations

API Application Programming Interface APN Access Point Name BRAS Broadband Remote Access Server BSS Business Support System BUS Business Applications CDN Content Delivery Network CPE Customer Premises Equipment CSP Cloud Service Provider CUS Customer Application Coordinator DNS Domain Name System DSLAM Digital subscriber line access multiplexer E2E End to End ECM Element Control and Management EMS Element Management System EM Element Management ETSI European Telecommunications Standards Institute FTTH Fiber To The Home FW Firewall GUI Graphical User Interface IaaS Infrastructure as a Service ICM Infrastructure Control and Management I-CSCF Interrogating-Call Session Control Function IMS IP Multimedia Subsystem IP Internet Protocol IT Information Technology

LAN Local Area Network LTE Lone-Term Evolution LSO Life Cycle Service Orchestration MAC Media Access Control MANO Management and Orchestration NaaS Network as a Service NAT Network Address Translation NF Network Function NFV Network Functions Virtualisation


29 | P a g e

NFVI Network Functions Virtualisation Infrastructure NFVO Network Functions Virtualisation Orchestrator NS Network Services NSD Network Service Descriptor OSS Operations Support System OTT Over-The-Top QoE Quality of Experience

QoS Quality of Service SDN Software Defined Networking SLS Service Level Specifications SOF Service Orchestration Functionality SGSN Serving GPRS Support Node VLAN Virtual Local Access Network VLD Virtual Link Descriptor VM Virtual Machine VIM Virtualised Infrastructure Manager VNF Virtual Network Function VNFM VNF Manager VNFFGD VNF Forwarding Graph Descriptor VNF FG VNF Forwarding Graph VPN Virtual Private Network WAN Wide Area Network

Documents

Study paper Network LSO Final - TEC paper Network LSO Final.pdf · Telecom Engineering Center, Department of Telecommunications, Government of India 1 | P a g e Study Paper on Network