SDN & NFV are an IT & Network thing! Right?

Posted by cfaurer on April 15th, 2015 filed in Frameworx Consulting, Frameworx Training

SDN & NFV are an IT & Network thing! Right? With an acronym like that it must be an IT & Network thing! But don’t be so sure, in fact SDN & NFV will have dramatic effect on the entire communication service provider enterprise and ecosystem value fabric.

TM Forum Zero-touch, Orchestration, Operations and Management (ZOOM)

“In the European Telecommunications Standards Institute’s (ETSI’s) initial NFV work, a decision was made to assume that existing legacy business and operational support systems (BSS/OSS) would not change and that NFV would be supported by adding new networking and BSS/OSS functions. However, research by the ZOOM team has shown that the ultimate impact of NFV on BSS/OSS will be significant and that it will require transformation not only of service providers’ operational practices, but also of existing BSS/OSS.” from NFV Can it Be Managed?

The next question to ask would be “which business and operational support systems (BSS/OSS) will need to be changed and what’s the impact on business processes?” Work to date done by the TM Forum ZOOM team suggests that these key areas will require significant transformation: PLM, CRM, Service Fulfillment, Service Assurance, Resource Management and Network Management.

SDN/NFV Impact Footprint on eTOM 14.5

What’s the footprint of those areas onto eTOM 14.5? Let’s look at each change area in turn by referring to the eTOM L1 horizontal process grouping impacted.

Frameworx Product Domain

Virtualized network functions will drive  a boon in product offerings supporting shorter and more dynamic product creation and deployment lifecycles. These product offering will rely on on-demand infrastructure changes to support customer and partner requests for self-care capabilities.  Self-service of the product will need to include handling of bundling, versioning, billing, charging, provisioning and inventory considerations.

A key capability offered by NFV is a loosening of the link to the physical realm and thus support for later stage provisioning and on-demand changes. These requirements will necessitate changes that will stretch across the full product lifecycle L1 horiziontal – planning, development, testing, on-boarding, launching, fulfillment, updating, assurance, billing, and more.

A key enhancement to the TMF Frameworx Business Process (eTOM) is still pending completion by the members but will offer a richer and more robust model to represent engaged parties that extend the current Supply Chain and Supplier/Partner L1 horizontal. This will support being able to including engaged party considerations in the discussion of SDN/NVF impacts on the business.

A more holistic view of product lifecycle management will need to be considered, which is aided now that eTOM 14.5 has adopted the Frameworx Domains structure for the L1 horizontal process groupings.

Frameworx Customer Domain

Today customer’s often find themselves having to sort out issues with their CPE and needing to wait for new equipment before things will work again. With the move toward virtualization many of the functions that require a CPE will be replaced with virtual CPE (vCPE) leading to shorter turnaround time in product delivery and maintenance. This benefit to the customer will put more pressure on the service provider to manage and maintain the product per the agreed to SLA.

With vCPE a more dynamic capability will need to be managed per the changing demands of the customer, supported by the changes described in the previous section regarding the Product Domain.

With the introduction of vCPE a much broader set of self-care and self-management capabilities can be offered to the customer spanning – ordering, inventory tracking, fulfillment, assurance, trouble shooting and more.

 

Frameworx Service Domain

To support NFV enabled product offerings the service catalog will need to present service candidates that have been designed to be end-to-end manageable in a Network as a Service environment (NaaS).

Service Order management activities will need to be streamlined and aligned with changes required in Product Order and Resource Order activities and systems as well as with AAA/Identity/Entitlement activities and systems. Service Order capabilities will need to be enhanced to support on-demand requests that will be passed to Software Defined Network (SDN) controllers and/or Policy managers. A critical success factor will be the ability to consistently manage service ordering rules end-to-end across multiple virtualized and physical domains. Further the link between the Service Catalog and Resource Catalog will need to be aligned to support successful Resource Ordering.

Service Activation with SDN/NFV in play creates an expectation that adequate physical capabilities will be available to support end-user initiated, on-demand provisioning. The scenario requiring bottom-up provisioning will require enhanced OSS capability to work closely with SDN controllers to ensure that adequate pre-provisioned resources are available. If not adequate, the OSS will need to trigger a physical provisioning request.

Service Inventory represents the realization/implementation of the Product as Services consuming Resources. With traditional service inventory its possible to track the static configuration information, which supports performing impact and root cause analysis with tracing across the resource-service-product-customer relationships. With the introduction of SDN, support of dynamic paths will be required. It will initially be more difficult to trace across the resource-service-product-customer relationships. OSS capability will be required to; provide visibility of what runs where; to know if the SLA is being met; to know if the service is utilizing resources efficiently (not under or over allocated).

Service Quality management poses significant challenges in the new SDN/NFV environment. Typically today KPIs are not available in the virtual space but only in the physical realm. This will need to be addressed by defining integrated metrics hierarchies between the OSS management realm and the NFV management realm (MANO see figure below). Further, this will necessitate revised and improved business processes that provide a closed-loop link between Assurance and Fulfillment activities.

Service Problem management today typically keeps the Assurance activities separate from the Fulfillment activities and therefore represents an open-loop process. With SDN/NFV that won’t suffice and a closed-loop solution will be required so that a problem with the service may request of capacity planning that additional capability be made available (e.g. more virtual machines) and then be informed when the changes have been made. This will support the requirement for a more dynamic realization of the Product as expected by the Customer as Services and Resources, as discussed previously.

Frameworx Resource Domain

Network Planning, Design & Optimization improvements will be required to ensure necessary and sufficient virtual and physical infrastructure is available based on simulation and analytics capacity projection models. A closed-loop system for optimization will be required, whereby inputs from service quality, traffic prediction, resource utilization, resource performance and more will be required in near real-time to support maintaining necessary and sufficient physical and virtual network capacity.

Resource Inventory management today is quite stable relative to what’s expected to become the norm with NFV capabilities. At the moment, the industry does not have a standardized model for virtualized resources – forwarding graph, VNF such as virtual router, virtual machine, etc. Neither is there an industry standard model to represent the capability and/or capacity of applications (VNF, VM, etc.). Getting new applications on-board is an ill defined process and the focus of standardization efforts. A strength today is that CSPs have a long history and good experience with managing physical network functions. In the NFV enabled environment it will be critical for network changes to be announced and distributed to all engaged parties in near real-time. Further, the scope of control of managed virtual resources will need to be expanded to cover a broader distributed physical platform that will be beyond the immediate control of a CSP.

Configuration Management will need to expand to support a more dynamic and realtime environment made possible by NFV capabilities. Increasing demand from customers for service preferences that meet their particular needs will require more configuration templates be managed according to service delivery rules and on-demand. Management across VNF configurations, physical configurations and service management business and operation rules will need to run in a seamless manner and become much more responsive to market demands.

Discovery & Reconciliation of physical and logical resources must become much more dynamic in order to support virtualized network functions. Today, if a virtual machine (VM) fails it is often moved to a different physical server and restarted. Pre-authorizing and tracking such changes will need to be coordinated between the OSS, resource inventory and the physical and virtual infrastructure. Self-registration, auto-discovery, self-discovery capabilities will need to be enhanced to support the real-time and dynamic change environment of NFV.

Resource Activation of network equipment by an OSS today as part of service activation will consume capacity of only the specific piece of network equipment. This will need to change in order to support OSS activation of NFV, which requires interaction with physical resource inventory to provide the necessary capacity in the hosting physical equipment environment.

Outside Plant will become part of the equation with NFV to ensure support for scaling with diverse path redundancy between data centers. This may require being able to select using different ducts and/or conduits leaving and entering data centers.

Fault Management will need to expand beyond management at the element and network management system and OSS level. The NFV Management & Orchestration (MANO) architecture creates additional points of interaction that must be fault managed. The NFV orchestrator, VNF manager and virtualized infrastructure manager will all need to do their own fault management and coordinate configuration changes with OSS, NMS & EMS in order to support end-to-end, cross-domain impact and root cause analysis.

Performance Management is handled today in a manner similar to fault management in that it is typically the responsibility of the element and network management system and OSS. As seen in the NFV MANO architecture the responsibility for performance management will need to be distributed across NFVO, VNFM & VIM. Additionally, these activities will need to be coordinated and synchronized with inventory, configuration and metrics activities in support of assurance as well as impact and root cause analysis between BSS/OSS and MANO.

SDN/NFV brings new challenges to activities supported by BSS/OSS

An SDN/NFV environment will require dynamic, policy-driven processes that run with real-time responsiveness. Management of this environment will require monitoring and tracking both virtual and physical resources and the services they offer as products to customers. The end-to-end status of the product-service-resource chain will need to be managed to support maintaining proper configuration, capacity, scaling (up and down) in order to meet the dynamic demands of the customer. Dynamic, flexible pricing and revenue sharing models will be required.

To keep such a dynamic environment up and running will require more automation than is in place today with tighter connections between and across design, fulfillment, assurance, billing and revenue management. In other words, much of what is represented by the TMF Frameworx across business activities and processes (eTOM); business, API and system information (SID); business (BSS) and operational (OSS) application capability (TAM); business services and APIs (Integration Framework) and business metrics (Metrics).

This work is underway by the TMF members participating in and contributing to the ZOOM and Frameworx team deliverables. Join your colleagues and get involved in defining the future!

Name: *

Email Address: *

Subject: *

Message: *

4 + = ten

Adapted from “SDN & NFV – Impacts on OSS” TMF ZOOM project contribution