oss bss_futures_overview

TM Forum 2014. All Rights Reserved.

Frameworx Exploratory Report

OSS/BSS Futures Overview Why OSS needs to change IG1117 Release 14.5.0 October 2014 Latest Update: Frameworx Release 14.5 Member Evaluation Version 14.0.5 IPR Mode: RAND

OSS/BSS Futures Overview

© TM Forum 2014. All Rights Reserved. Page 2 of 32

Notice

Copyright © TM Forum 2014. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by TM FORUM or its successors or assigns. This document and the information contained herein is provided on an “AS IS” basis and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Direct inquiries to the TM Forum office:

240 Headquarters Plaza, East Tower – 10th Floor, Morristown, NJ 07960 USA Tel No. +1 973 944 5100 Fax No. +1 973 944 5110 TM Forum Web Page: www.tmforum.org

http://www.tmforum.org/IPRPolicy/11525/home.html

http://www.tmforum.org/



Table of Contents

Notice .................................................................................................................................. 2

Table of Contents ................................................................................................................. 3

Table of Figures.................................................................................................................... 5

Executive Summary .............................................................................................................. 6

1 Business Drivers ............................................................................................................... 7 1.1 Agility .................................................................................................................... 7 1.2 Partnering and Openness ........................................................................................ 7 1.3 Customer Experience .............................................................................................. 7

2 Why virtualization changes OSS/BSS management............................................................. 9 2.1 Impact on OSS Realization ...................................................................................... 9 2.2 Impact on OSS Functionality .................................................................................... 9

3 How OSS/BSS technical approaches need to adapt............................................................11 3.1 Agility Drivers – technical approaches .......................................................................11

3.1.1 Processes – Dev Ops ......................................................................................11 3.1.2 Technical Best Practices for Agility.....................................................................13

3.2 Partnering Drivers – technical approaches.................................................................15 3.2.1 Partnering ......................................................................................................15

3.3 Agility Drivers - Standards Design Approaches...........................................................16 3.3.1 What kind of standards? ...................................................................................17 3.3.2 An analogy is useful. ........................................................................................17 3.3.3 How does this help timeliness?..........................................................................18 3.3.4 Integration technologies ...................................................................................18

4 OSS/BSS support for future operations .............................................................................19 4.1 Evolving Operations ...............................................................................................19

4.1.1 Implication of Dev Ops on OSS/BSS Futures ......................................................19 4.1.2 Implication of Net Ops DevOps convergence ......................................................19

4.2 Technical Capabilities .............................................................................................20 4.2.1 Support for multi-partner changing business models.............................................20 4.2.2 Agile multi-vendor, multi-technology integration....................................................21

4.3 Technical Methodology ...........................................................................................21 4.3.1 Organizational Impacts.....................................................................................21 4.3.2 Merging of cultures across multiple businesses....................................................21 4.3.3 ZOOM Technical Standards..............................................................................22

4.4 Deployment environment ........................................................................................22 4.4.1 Migration to a hybrid virtualized environment .......................................................22

5 Results from ZOOM Fx 14-5 ..............................................................................................23 5.1 NFV Readiness Theme #3 ......................................................................................23

5.1.1 Virtualization Procurement and Operations Impacts .............................................23 5.1.2 Hybrid current and virtualized networks ..............................................................23

5.2 End to end Management Theme #2 .........................................................................24 5.3 Impact of Policy .....................................................................................................24

5.3.1 Changes to policy management ........................................................................24 5.3.2 Changes to how SLAs are delivered ..................................................................25 5.3.3 Changes to how we think about security .............................................................25

5.4 Relevant TM Forum catalyst results and studies .........................................................26

6 Future areas of study ........................................................................................................28 6.1.1 Orchestration ..................................................................................................28 6.1.2 Service chaining..............................................................................................28 6.1.3 Virtualization Maturity Model .............................................................................28

7 References .......................................................................................................................29 7.1 References ...........................................................................................................29

8 Administrative Appendix ...................................................................................................32



8.1 Document History ..................................................................................................32 8.1.1 Version History................................................................................................32 8.1.2 Release History...............................................................................................32



Table of Figures

Figure 1 Introduction of explicit Virtualization 9

Figure 2 Traditional Telco OSS/BSS Landscape 11

Figure 3 Application, Product and Service lifecycle processes 12

Figure 4 Shift form Vertical product service stacks to platforms 13

Figure 5 Components support multiple views 14



Executive Summary

Virtualization is a trend that is sweeping across the IT and Communications industries and in its wake it is bringing radical change to technical solutions, development methods and operations practices.

Recent publications from ETSI1 on Network Functions Virtualization (NFV) have provided early insight as to how Network Functions can be virtualized by adaptions of virtualization techniques for Compute, Storage, and Network developed by the IT industry.

In the initial ETSI work, a decision was taken to assume that existing legacy OSS /BSS was out of scope, and that NFV would be supported by additional functions added to both Networks and OSS /BSS solutions.

However TM Forum studies in the ZOOM Project have shown that the ultimate impact of NFV on OSS/BSS will be significant, and that it will require a transformation of both OSS/BSS solutions, and Service Provider (SP) operational practices.

The reasons for this are that the ultimate goals of NFV are improving agility in introduction of services together with saving operational costs It turns out that current OSS and BSS solutions are a significant barrier to achieving overall service agility, unless they too are re-engineered. This document overviews the necessary changes to OSS/BSS design and implementations that are further developed in the OSS/BSS Futures Framework [23], reviews some of the related results from Fx 14-5 studies and catalysts demonstrations at TM forum Live Nice 2014.

The evolution of OSS/BSS Futures is needed to support the ZOOM requirements of:

o Theme #1: DevOps Transformation Framework for the Digital Ecosystem

o Theme #2: Blueprint for End-to-End Management

o Theme #3 NFV Readiness for Procurement and Operations

Interestingly the studies have shown that two pieces of prior work conducted by the TM Forum are highly relevant to OSS/BSS Futures:

o Cloud Service management – the Digital Service Reference Architecture –DSRA [4] has developed some relevant frameworks for cloud virtualization and the concept of a’ well enabled Service’. The ZOOM OSS/BSS Futures framework has shown a simple extension of this notion to a ‘well enabled Virtual Network Function’ e.g. weVNF.

o B2B2X Partnering Accelerator [8] [and associated APIs [7] has shown how both business and technical partnering can be realized in an industrialized agile way by adopting a set of business and design patterns that lead to agile re-usable solutions and APIs.

This document is aimed at managerial and technical people interested in TM Forum strategic directions of ZOOM and specifically management of virtualization.

Further information on the objectives of the ZOOM project is in the ZOOM Overview [1].

1 ETSI European Telecommunications Standards Institute



1 Business Drivers

OSS/BSS Futures is driven by recognition of a number of business and technical drivers that are impacting service provider OSS/BSS systems, operations processes and organization.

Four themes have been identified by the ZOOM program as needing to be addressed by the industry:

o Theme #1: DevOps Transformation Framework for the Digital Ecosystem

o Theme #2: Blueprint for End-to-End Management

o Theme #3: Operations and Procurement Readiness

o Theme #4: Open Source and open Systems Direction

The detail of these themes is driven by User Stories captured in the TR 229 ZOOM User Stories (which as an evergreen document is updated from time to time).

The OSS/BSS Futures framework addresses changes that support the needs of Themes #1 and #2, and is impacted by requirements identified in Theme #3.

As SPs look to transform their business operations – a popular phrase is ‘becoming a Telco 2.0’ – three business drivers have emerged2:

1.1 Agility

SPs are concerned to grow top line revenue by introducing profitable new services, possibly in competition or co-operation with Over the Top (OTT) Providers. To achieve this objective they need agile processes and systems for developing and operating new services, and the organization structures to enable this to happen. What is needed is a clear view of best practice processes for product and service lifecycle management, and how to adopt and adapt IT best practice for developing and operating new services.

1.2 Partnering and Openness

Reducing time to market and costs for new services requires SP to establish their core value and partner with other enterprise to co-provide services. This is most noticeably required for cross industry solution such as those needed for the Internet of Things (IoT), Smart TV, Smart Home, Smart Cities, Smart Grids, and e-Health.

The consequences of the need for partnering in new services is that a repeatable, agile and industrial scale solution to partnering is required; based on reuse of components and open APIs through configuration rather than by programming.

1.3 Customer Experience

Notwithstanding the other business drivers an overriding business driver is to maintain and improve customer experience and engagement. Whilst agility and partnering contribute to improved customer experience they are in themselves not

2 All of these are strongly influenced by regulation and legal differences in different territories for example data protection

law ful interception, etc.



enough; and the disciplines of customer experience need to be maintaining and improved during business transformation. The TM Forum has an extensive body of tried and tested methods for Customer Experience Management in its Customer Engagement Program [3] which addresses e2e management of services.

Customer Self Service

One emerging need is customer defined and controlled networking where the customer can self-configure services to meet their exact needs. This places stringent demands for zero touch operation on the technical solutions for OSS/BSS, particularly a need for high levels of automation.

http://www.tmforum.org/customerengagement/15846/home.html




2 Why virtualization changes OSS/BSS management

In addition to the business drivers impacting OSS/BSS Futures there are specific drivers arising from the introduction of IT virtualization techniques and technologies into NFV.

Virtualization technology developed by the IT industry creates two types of impacts/ opportunities for OSS/BSS Futures.

2.1 Impact on OSS Realization

OSS/BSS are intrinsically IT applications, and therefore can be realized by as Software as a Service on industry standard server virtual machines. This facilitates considerable flexibility in deploying these applications by both supplier and SP providers using a range of business models.

2.2 Impact on OSS Functionality

Current network services are typically provided in physical network appliances or equipment racks where there is a direct static relationship between the Network Service and the Physical Resources. – see left hand side Figure 1.

Figure 1 Introduction of explicit Virtualization

Whilst these current Network Service applications typically include some form of internal hypervisor or virtualization layer they are rarely explicitly exposed for direct management control.

When virtualization is introduced – right hand side Figure 1 – the relationship between the Virtualized Network Services / NFV Virtual Network Functions and the



Virtualization Infrastructure is directly exposed since the suppliers of these two layers may be different. The relationship between virtualized and virtualization layer is dynamic and have an M to 1 relationship to support virtualization requirements for multi-tenancy, and scaling out /in.

The virtualization infrastructure is designed so that it can distribute Virtualized Network Service workloads dynamically across multiple distributed compute, storage and networks resources. This is needed to support the scale out and in requirements whilst improving operational agility, flexibility and economy.

Clearly the management of work load demands, and their assignment to physical resources has to be supported by management /control applications since it is this ability to support dynamically changing relationships that provides the flexibility, agility and cost saving potential of virtualization.

This requirement to manage dynamic workloads impacts OSS processes, tool support and also organization, as there has to be explicit organizational responsibility for planning and managing capacity dynamically at run time.

A further challenge is that these new network services have to be virtualized services used in combination with current network services leading to a need to manage Hybrid Network Service shown by the 1:X relationship above.



3 How OSS/BSS technical approaches need to adapt

3.1 Agility Drivers – technical approaches

To support the business drivers of agility, and lower operations costs (OPEX), modified technical approaches for OSS /BSS are needed covering: processes and best practice techniques, technologies, and standards.

3.1.1 Processes – Dev Ops

Agility in technical solutions is a product of both the technical and architectural design principles, and the processes that are used to develop technical solutions.

The traditional SP waterfall model of: selecting a supplier’s supporting system, writing a 100+ page requirements document, then waiting for the supplier to develop the solution, and then testing with them – is a process that takes typically 6-12 months. This has led to traditional OSS/BSS solutions being complex mesh of proprietary products:

Figure 2 Traditional Telco OSS/BSS Landscape

Agile IT operations has evolved to a best practice called DevOps supported by a number of industry tools – Service Mesh, CohesiveFT, Chef, Puppet, SevOne, Salt, CF Engine, etc. – which are based on development and operation people working in a single concurrent activity rather than sequentially as in the Waterfall model. The key principles are:

o Incremental service definition

o Continuous integration

o Automated testing

o Automated interfaces to applications that facilitate continuous integration and testing.

Within service providers there are product and service development lifecycle models which need to be adapted to support these DevOps technique. However



these need to be extended to support complex service chains and performing DevOps concurrently across multiple partner organizations.3

Figure 3 Application, Product and Service lifecycle processes

To achieve the operational efficiencies targeted by NFV and SDN, traditionally separated operational processes need to become more closely linked and require a high level of automation.

NFV basically turns Network Elements (NE) into pure software applications, referred to as the Virtualized Network Functions (VNFs). The Application Lifecycle Management for VNFs needs to apply and extends IT management practices to Telco capabilities, and thus require TM Forum Frameworx to interwork with standards & practices of IT management bodies such as ITIL4 and DMTF5.

For example, ITIL integration with Business Process Framework processes/best practices needs to go beyond the Enterprise Management domain and should fully link to or cover parts of the Application Lifecycle Management processes everywhere across the Business Process Framework (aka eTOM).

Also, NFV and SDN introduce new capabilities (e.g. compute, storage, switch) and components (NFV Orchestrator, SDN controller, etc.) which lead to additional resources , services, processes, etc., where possible taken from existing bodies, or else to be defined.

In TR229 ZOOM/ NFV User Stories [2] there are a number of user stories related to DevOps that set out the actors and the process needs that they have for a DevOps style of product and service lifecycle management.

3 For Fx14-5 we have put in place the enablers for DevOps to be applied to Network Functions Virtualization (NFV).

Examples of DevOps use in will be developed- for example – in catalysts before fully specifying the FX ZOOM DevOps

extension. 4 ITIL Information Technology Infrastructure Library 5 DMTF Distributed Management Task Force



IG1100 Product Lifecycle Management Introductory Guide [26] provides a comprehensive overview of the key principles and concepts for product lifecycle management, and how Frameworx and specifically the Business Process Framework and KPIs support effective Product/Application Lifecycle Management.

For ZOOM and virtualization/NFV these processes need to be automated, operate faster and work with other partners.

3.1.2 Technical Best Practices for Agility

3.1.2.1 Platforms/Modules based on exposed Service APIs

This approach moves OSS/BSS design from the traditional waterfall model:

o To a model whereby these target OSS/BSS capabilities are packaged as modular components with exposed APIs,

o That enable solution teams to use and configure them without any support from the target OSS/BSS teams.

This is illustrated in the following example that shows a move from vertical integrated Network and OSS stacks to horizontal layered modular platforms.

Figure 4 Shift form Vertical product service stacks to platforms

The critical thing to notice is that this affects both the platforms to provide services offered to end customer e.g. Networks and control, and their supporting OSS and BSS. Thus the impact and drivers are broader than just OSS/BSS change they affect all applications including networking applications. The underpinning concepts are based on service oriented design principles and are applicable to all applications including OSS/BSS. This model is needed for common OSS /BSS services such as: customer portal, API Gateway, billing, provisioning, etc., if they are to be flexibly used by solution engineering teams.

Benefits include

o Greater flexibility and agility of solutions



o Clearly defined API interfaces that can be published and change managed (governed) by the provider of the API. For example Amazon EC2 can be used without having to write requirements for and interlock with Amazon development teams

o Business Process workflow can be changed without re-coding the business logic behind the APIs.

The TM Forum Digital Services Reference Architecture (DSRA) [4] [5] is based on these principles.6

3.1.2.2 Composability of manageable services

ZOOM and DSRA [4] [5] studies have shown that for real world examples of new digital services that it is necessary to compose services from other services and at the same time be able to manage the composite service.

For networks it is necessary to create abstracted services that are layered of composed from lower level services. At each layer of abstraction manageability is needed.

The DSRA model introduces the notion of a ‘well enable service’ where every service at whatever layer has a standard set of management services that are designed to be composable.

So for example: a composite set of VNF services comprising: firewall, web accelerators, and MPLS edge router; when each is realized with ‘well enabled management interfaces’ could be composed into an enterprise access network service function, which could be managed as a composite also using ‘well enabled management interfaces’.

Figure 5 Components support multiple views

It shows one implication of this approach which is that the granularity of management and the network service has to be aligned if it is to be possible to compose services from other services. In current OSS/BSS practice the granularity of management and the service is not always so clear. Note that management of a service particularly in a legacy situation might be via a proxy rather than directly, and literally, on the service component. This and other practical consideration are

6 The IG 1118 OSS/BSS Futures [23] Future Mode of Operations (FMO) and the subset of focused on OSS/BSS and

Control called Management Control Continuum (MCC) is based on proposals to enhance the DSRA.



described in the DSRA [4] and prior Service Delivery Framework [5] documents and the IG1118 Future Mode of Operations (FMO) and Management Control Continuum (MCC) enhancements.

Benefits of this approach are:

o Supports multi-vendor multi technology integrations

o Leads to a consistent way to manage any service at any layer of abstraction

o Possible to dynamically create these composed management APIs i.e. they are configured, not coded, leading to greater agility in creating solutions.78

3.1.2.3 Separation of Business Process Workflow from application logic

This principle changes the common model for programming processes:

o from embedded process in applications i.e. move from a traditional integration model of implementing processes in Applications, e.g. App A calls code in App B which calls code in App C

o to a model based on “main loop calling app subroutines” as opposed to ‘goto’ style programming; Orchestration is one implementation approach to this but not the only one.

Benefits include:

o Greater flexibility and agility of solutions as solution teams can change Workflow without recoding applications.

3.1.2.4 Integration API Design Principles

Design of APIs needs to be based on well-established software design patterns including:

o Loose Coupling, including inter-application ‘eventing’ infrastructure supported via an event broker

o API Contracts

o and use Shared Information Model.

Many of these requirements are satisfied by the TM Forum Framework Integration Framework Interfaces [6] and APIs [7].

A further Integration API design principle is that OSS management has to support multi-technology, multi-vendor and multi-partner solutions. Simple to say but has significant implication on how industry agreement are formed, managed, and governed.

3.2 Partnering Drivers – technical approaches

3.2.1 Partnering

Frequently with new digital services, the challenge is to set up arrangements amongst multiple partners quickly to co-provide services.

7 TM Forum Live 14 Nice June 2104 Catalyst: Service Bundling in a B”B”X Marketplace Catalyst 8 TM Forum Live 14 Nice June 2104 Catalyst: Cloud NFV: Dynamic, data-driven Management and Operations

http://www.tmforumlive.org/catalysts/

http://www.tmforumlive.org/service-bundling-in-a-b2b2x/


http://www.tmforumlive.org/cloudnfv/



TM Forum B2B2X Partnering program [8] has created a method that allows the establishment of agile business and technical partnerships on a repeatable industrial scale. It is based on members’ operational experiences (including BT, NBN Co, NTT, Orange and others) and requires:

o Business people to capture a partnership model definition in a systematic way using a set of templates based on reusable concepts and components.

o Developers to use the partnership model definition to quickly configure pre-defined reusable concepts, components, (Gateways) and APIs. These focus on operational processes between partners such as ordering, configuration, catalog information exchange, trouble or incident management, billing and capacity scaling management processes.

It has been practically demonstrated in multiple TM Forum Catalyst projects [9] [10].

The key elements of the Partnership Model are five aspects or perspectives:

1. Customer market proposition aspect captures the unique business concept for the agreement to be created. This stage uses the industry standard Osterwalder Business Model Canvas9 analysis method to capture the business model requirements as inputs to creation of the Partnership Agreement. This is where the products to be developed or supplied by each partner are defined.

The Customer and Market Neutral Partnership Agreements address:

2. Business Model: including business roles, service interactions and product/service relationships that partners hold within a value chain or fabric e.g. instant messaging, access networks, cloud service, etc.

3. Commercial Model: including business rules and policies, terms and conditions

4. Financial Model: including revenue principles and flows including rebates and dispute resolution

5. Operational Model: including both functional and non-functional requirements – such as process performance, reliability, etc. It is based upon defining a set of Touchpoints that can be implemented as APIs –working examples in WS and REST have been specified.

In the ZOOM catalyst projects [9] [10], it has been demonstrated that the touch points can be defined using a standard verbs set, and that the API payload can be dynamically rendered from a definition in a catalog of the product being offered.

3.3 Agility Drivers - Standards Design Approaches

Traditionally Standards Defining Organization (SDO) activities have been considered in the context of defining an industry model from requirements ,and then defining and standardizing interfaces between the components in that model. This presumes that standards are used in a traditional development model where specifications are created, and that subsequently developers in suppliers build to those interface specifications.

9 Business Model Canvas http://businessmodelgeneration.com/canvas/bmc

http://businessmodelgeneration.com/canvas/bmc



The challenge for this approach is that implementable standards have rarely been developed in less than 18 months, unless the input to the process is a complete de facto standards specification, which is simply endorsed.

3.3.1 What kind of standards?

In a continuous development model the question to be asked is what standards should be developed – noting that an 18 month standards cycle is infeasible in any real world development.

The key requirements on a standard for agile development are:

o Interoperability: Standards for interoperability have been traditionally defined by creating a detailed set of requirement and a single specific implementation of that set of requirements with supporting test tools. This assumes that all the requirements are known at the outset which is rarely correct.

o Timeliness: Standards need to be timely and the current approach is to develop a large body of requirements and then expect them to be all implemented. What is needed is a standards approach that is deliberately designed to be incremental, each increment being limited in scope and time.

TM Forum Catalysts at June 2014 [10] [11] have shown an alternative way to achieving interoperability in an agile incremental manner, which is based upon defining metamodels and fragment of models that can be readily enhanced based on those metamodels.

The key observation is that not all the specification work needs to be done within the SDO, some can be done by implementers themselves following standardized patterns and metamodels. This means that the standards required are different to those traditionally defined by SDOs.

3.3.2 An analogy is useful.

The common example used is the need to develop a building block modular approach to designing solutions:

o The kind of components /modules that that are needed are not arbitrary building blocks but component /modules based on a common form and structure that allows them to be combined flexibly. To achieve this all components have to conform to a common architecture and rules.

o For Lego™ blocks, what makes them flexible is that they all conform to rules about shape, pitch increments and pin and socket sizes, i.e. the design rules for all Lego™ blocks.

o The equivalent for OSS/BSS Futures [23] is to agree and define the metamodels for components and their interfaces so that user can create their models for interfaces based on a metamodel pattern. This leads to interoperability as all the component and interfaces follow common pattern and the variability is managed where it is needed – by the implementer, not by the SDO. This is elaborated in Ref [23] and [27].

o For example: in the TM Forum June 2014 catalysts [10] [11] the interface verbs were standardized and the payload was based on a core common information model (TM Forum Information Framework) together with metamodel rules for extending the data payload to meet the needs of the specific module/component being managed.



3.3.3 How does this help timeliness?

The availability of a metamodel and a core information model and rules for extension means that component and interface developer have:

o A framework that allows them to develop their own interfaces at the pace that suits them

o Solutions that they know will interoperate with others

o Interfaces that can be published in catalog with supporting API tools so that potential users can try them out in a safe environment before committing to development.

The result is that the SDO facilitates the creation of well-structured modules/ components and interfaces that are defined by implementers themselves.

Timeliness is achieved because:

o The implementer has fewer dependencies on SDO to create interoperable interfaces.

o Metamodels usually allow for pragmatic workarounds to be identified, and identify better long term approaches to be identified and evaluated, i.e. Extensions to Metamodel and core information model capabilities are typically easier to spot well before they are needed.

o The Common Information models leads to a core shared set of semantics for the key managed entities e.g. Products, VNF, etc.

These concepts are also the basis of the TM Forum DSRA approach to service lifecycle management [12] and the IG1118 OSS/BSS Futures [23] PMO and MCC architecture extensions to Frameworx and DSRA.

3.3.4 Integration technologies

Use of metamodels, design patterns and core information models allow developers and SDOs to evolve best practice from one generation of integration technologies to another, and facilitate easy interworking of solutions in one technology with those using earlier integration technologies. Solutions therefore are less brittle and easier to evolve.



4 OSS/BSS support for future operations

This section relates to the business issues described in the ZOOM eBook on Theme #2 DevOps transformation framework for the digital ecosystem [29].

In creating a vision of a future OSS/BSS there is a temptation to produce a better solution to the previous generation of OSS/BSS requirements. TM Forum studies show that OSS/BSS Futures need to have characteristics suited to the needs of future operations, not historical operations, and that these require different and novel technical approaches described in IG1118 [23].

Based on the business and technical drivers, and the expected impact on operations the following characteristics need to be implemented:

Evolving Operations

o Enhancement of IT operations and Dev Ops practices

o New ways of managing SLAs and end to end security

Technical capabilities

o Support for multi partner changing business models.

o Agile multi-vendor, multi-technology integration.

Technical methodology

o Organizational Impacts

o Merging of cultures across multiple businesses

o ZOOM Technical standards.

Deployment environment:

o Support from the outset a hybrid management environment because that is where Service provider deployments will start.

The following sections examine some of these requirements in more detail.

4.1 Evolving Operations

4.1.1 Implication of Dev Ops on OSS/BSS Futures

Adoption of virtualization in the enterprise space has led to the development of agile and efficient ways of developing and operating applications that is generally referred to DevOps. The key to DevOps are a few succinct best practices including:

o Continuous integration

o API centric – Model Driven Integration with Automated Management interfaces

o Automated testing – sandboxes.

4.1.2 Implication of Net Ops DevOps convergence

Current NetOps management is commonly based on manual techniques so potentially there is much to be gained by adopting and enhancing DevOps best practices for management of NFV and virtualized services.

However DevOps is generally applied to discreet services, frequently web delivered, and early NFV trials and catalysts are showing that there are additional



challenges that need to be addressed for network virtualization beyond that covered by current IT virtualization methods:

o NFV Services and VNF are chained thus creating strong dependencies between VNFs to deliver e2e virtualized services. This means that much stronger version control and compatibility testing is needed between separate VNF deployments to ensure e2e service is maintained, than would be typical for enterprise applications.

o Networks are layered to support abstraction for different types of network services and different scope. Development and Operations methods need to support management of composition from lower level services.

o NFV services are often ‘mission critical’ creating a need for high levels of resilience and rapid fallback capabilities.

o Sandbox test environments are more complex to set up.

o The NFV VNF workloads are rather different from typical enterprise applications. E.g. some are long running.

o Services are often co-provided by multiple operators which require that Dev Ops and Net Ops best practices are evolved to support concurrent synchronized development and integration across multiple partners.

o Agile development methodology has to be evolved to support services provided using current network service platforms and virtualized services.

o Virtualized services will cover a diverse range of network functions and technologies so consistent frameworks and interfaces are needed to support integration as a configuration rather than a development activity.

o Requirements for multi-tenancy limit the physical deployment of workloads and in some case the types of virtualization containers e.g. Docker, when strong isolation is required, or there are regulatory constraints.

Some of these lessons have been learned from the TM Forum Live 14 Catalyst scenarios: Orchestrating SDN and NFV while Enforcing an SLA over a WAN[19].

4.2 Technical Capabilities

4.2.1 Support for multi-partner changing business models

Many services are based upon integrating services from multiple suppliers. This is sometimes called Cross Domain integration and management.

The OSS/BSS Futures modular service model is designed so that any interface between two services that cross an administration domain can be formed in an agility and repeatable manner at industrial scale. The OSS/BSS Futures framework uses the B2B2X Accelerator [8] and TR211 Online Partnering Guide [21] which allows any service interface to be ‘wrapped’ by a partnership agreement.

The B2B2X Accelerator approach is designed so that the decisions that are product dependent are decoupled from those that are partnership or business model dependent. These decisions are designed to be systematic by selection from a list of available choices; thus Partnerships are a configuration activity rather than a bespoke development activity. For Operational Processes this is achieved using reusable B2B2X touch points realized as APIs in multiple technologies.



4.2.2 Agile multi-vendor, multi-technology integration

The ZOOM NFV vision is based on the ability to flexibly integrate solutions covering multiple technologies and multiple vendors. Of these two challenge the most immediate is the Multi-technology integration challenge.

A number of standards initiatives around management of virtualized services have sprung up but inevitably they are diverging; meaning that multi-technology integration is becoming an adaptor and coding challenge, rather than plug and play or simple configuration activity. It is clear that some umbrella activity needs to be in place to establish and drive the multi technology converged management agenda. Historically activities such as NGMN have ‘a postori’ initiated remedial convergence activities that have arisen from multiple incompletely coordinated activities.

The OSS/BSS Futures [23] framework leverages best practice and experience from many catalyst demonstrations, and studies between NGMN, the TM Forum and 3GPP, The TM Forum DSRA [4] proposes a simple set of modelling principles and API patterns which if widely adopted would considerably alleviate the current integration challenge and lay the foundation for automated APIs that can be integrated by configuration rather than coding to support DevOps for Network Functions Virtualization.

Such a capability is an essential pre-requisite for achieving a DevOps style of automated development and integration. Without widespread adoption of these principles, solutions will be unable to support the necessary levels of automation to meet the NFV agility goal.

4.3 Technical Methodology

4.3.1 Organizational Impacts

Given that future operations will evolve to be radically different form today’s and that Product / Service Lifecycle Management needs to be highly automated this will impact organizations processes and structure.

Following the DevOps experiences would suggest that separate development, operations and QA organizations will need to be replaced by multi skilled functional teams where development is structured as incremental enhancement with continuous integration and testing, and where the whole team is focused on business goals.

4.3.2 Merging of cultures across multiple businesses

ZOOM NFV operations will need to adopt and adapt IT DevOps practices. As described in Sec 4.1.2 there are some additional challenges for ZOOM NFV to achieve the necessary agility.

A future challenge will arise for integration across suppliers and administration domains. This implies that the agile incremental development in multiple suppliers needs to be coordinated and synchronized. Current DevOps practice does not address across enterprise development synchronization, and clearly there are best practices and standards needed for the exchange of product and service definitions, lifecycle state and other development and operations metadata.

These approaches means that DevOps teams need to work in a systematic way with other suppliers, that requires the establishment of best practice guidelines for governance mechanisms between suppliers.



ZOOM OSS/BSS Future framework adopts the TM Forum Integration program approach to developing APIs which included changes to the practices for governance of development of APIs between organizations. ZOOM catalysts on Service Bundling [10] and Catalog have shown how product and service information can be shared and integrated across multiple organizations.

4.3.3 ZOOM Technical Standards

As services move to be constructed as mashups composed from multiple independent service suppliers (and from different parts of an enterprise) a set of methods and tools will be need to capture those designs throughout the complete service realization lifecycles.

The DSRA models [4] [5] [12] augmented by the OSS/BSS Futures models [23] provide these best practices and the minimum standards need to establish Product and Service catalog, exchange and synchronize catalog information and metadata, and coordinate the lifecycle of multiple services from suppliers.

Previously for DevOps typical situations, these catalogs, repositories and metadata could be decided within a single tool or by a single enterprise. To achieve DevOps efficiencies across multiple partners requires that the core of this information is standardized.

4.4 Deployment environment

4.4.1 Migration to a hybrid virtualized environment

A specific realization challenge is that the first step for service providers is to introduce virtualized services into a traditional current network environment. i.e. the initial operations, will be of hybrid networks not purely virtualized.

This has impacts on operations processes and organization and sets requirement on APIs between current OSS/BSS and the OSS needed for hybrid and virtualized service.

An NFV Readiness briefing on migration and operation of hybrid networks has been developed [14].



5 Results from ZOOM Fx 14-5

5.1 NFV Readiness Theme #3

A number of studies were carried out to support the NFV Readiness Theme that do influence both requirements and technical realization of future OSS/BSS.

5.1.1 Virtualization Procurement and Operations Impacts 10

There are a number of areas where virtualization impacts OSS/BSS implementations:

o Procurement: Virtualization enables entirely novel disruptive supply chain arrangements to be considered by service provider. It allows in principle separation of supply of computing infrastructure from Network Service and Virtualized Function, and for maintenance to be provided by third party maintainers.

o Operations and organizations need to embrace the new supply chain arrangements and work out processes for operating the virtualized Network Service and the Virtualization Infrastructure. It raises operations question such as:

o When a VNF is delivered, how do I manage on boarding into my organization? i.e. ‘what is in the box’? What management tools does it support? And how will I manage it automatically within my IT and network operations? How will support be coordinated between NFVI and VNF suppliers?

These considerations are explored in more depth in the briefing IG1121 NFV Readiness: VNF Procurement and Lifecycle Management [13]. This examined the procurement and operational impact throughout the complete service lifecycle [13] including license management.

5.1.2 Hybrid current and virtualized networks

A number of migration challenges have been identified including:

o SP Change Management: SPs cannot move in one step to full NFV implementation, because of cost and operational constraints (processes, change management, culture, organization, training, etc.).

o NFV Maturity As initial phases of NFV are starting to rollout, various technologies will evolve and vendors will improve their implementation. Therefore, the versioning of implementations as well as inter-operability will need to be addressed.

o BSS/OSS Impacts Existing OSS and integration with BSS will need new architecture to a new set of supporting systems, which may also be virtualized. This is a focus of the OSS/BSS Futures Framework [23].

o Effortless Customer Experience During migration SPs need to maintain current customer services without degrading customer experience such as zero or minimum down-time and minimum “learning” experience, while maintaining integrated service features.

o E2E management views across current networks and virtualized networks are critical to supporting high quality Customer Experience.

10 This section does not cover all the procurement impact



The document identifies through a set of migration exemplars areas which will require technical change to support migration and hybrid networks including:

o Managing Virtualization infrastructure layer including Optimization Functionality to allow dynamic configuration.

o Dynamic operations of integration interfaces to support agile change to products and compositions of products.

o Flow of control over APIs between current and virtualized networks.

o Data of Record: in some migration scenarios the data of record moves from the current Network to the hybrid Network Service Management systems.

5.2 End to end Management Theme #2

This section relates to the business issues described in the ZOOM eBook on Blueprint for end to end management [28].

There are two end to end management requirements:

o The first is the e2e management of new services introduction (Product Lifecycle management or Concept to Market) described in Section 4 on DevOps.

o The second is the e2e management of the service offered to the end customer. OSS/BSS Futures provides the OSS Framework management of modular virtualized services for two types of e2e management services:

o End to end performance of the services. By defining a set of Performance and SLA interfaces on VNF that allow consistent measurements to be obtained on which SLA performance can be judged.

o End to end security of the services. By defining standards based security service available on every VNF.

5.3 Impact of Policy

5.3.1 Changes to policy management

The ZOOM OSS/BSS Futures framework [23] and ZOOM Policy Management Architecture [24] include a policy management model which is based on a number of observations:

o The distributed nature and complexity of NFV ZOOM solutions is such that a centralized management model requires substantial real time exchange of information between the virtualized functions and the management systems.

o The processing and information transfer demand can be mitigated by using a closed control loop Policy management approach, where policies are distributed out to local decision points and controlled and end to end goal are measured e.g. SLA security. When these fall are outside the intended targets, corrections are made to policies to bring the behavior of the overall service back to meet the intended targets.



Two catalysts at TM Forum Live 14 demonstrated exactly this approach (described later):

o Closing the Loop: Data-driven Network Performance Optimization for NFV and SON: [18]

o Orchestrating SDN and NFV while Enforcing an SLA over a WAN: [19]

The ZOOM Policy Management Architecture also supports some additional styles of closed control loop Policy Management.

5.3.2 Changes to how SLAs are delivered

As was demonstrated in two ZOOM catalysts (described later) the approach to managing e2e SLA moves from:

o a static design of an e2e service that allocates statically targets for each component.

o to a model where the e2e SLA targets are set by setting policies and the individual policies are dynamically adjusted to achieve the design target at run time.

The reason this architectural change is needed is that the introduction of virtualization breaks the static relationship between the service and the resources used to support it; and replaces it by a dynamic relationship through virtualization infrastructure to get the required scaling and agility; Which means traditional static ‘a priori’ design approach will not work.

Virtualization also changes the assurance approach from localizing a fault which is impacting the overall SLA, to one where policies are adjusted dynamically so that the delivered service adapts, and converges on the target design SLA.

Two results have been creted that address these needs:

o E2E SLA Management for Cloud The SLA Management program and the work in TR178 [15] investigates how the SLA Principles and Business Metrics [16] can be used to support End to End SLA for cloud services provided by multiple cooperating providers, each operating as separate Administrative Domains..

o A White paper analyzing the impacts of NFV virtualization [17] captures from TM Forum Live June 2014 catalysts and other studies the additional challenges and requirements for managing Performance and SLAs for NFV.

5.3.3 Changes to how we think about security

The ZOOM Security Fabric [20] Framework proposes a lightweight security model for configuring and monitoring e2e security of Virtualized Services including NFV VNFs. It is based on a notion from the ZOOM DSRA Framework for a well enabled (virtualized) service where every service / VNF has a standard set of management API functionality. It also leverages existing virtualization stack security APIs to link the security mechanisms of the virtualized services layer with those of the virtualization Infrastructure.

The Security User Stories IG1124 [20] are derived from ETSI [25], ATIS and TM Forum Studies TR 229 [2]. They show that a security policy based approach is needed which is based on a closed control loop of setting security policies and hen monitoring to check that those polices are being applied correctly, and if not, applying necessary corrections.



The studies show that the ZOOM Policy Management Architecture [24] is directly applicable and that the test methods for SLA and Security can be quite similar; provided that all virtualized services are well enabled with Management interfaces supporting SLA and performance management, and security management. DSRA work on Simple Management APIs [22] cover most of the requirements and can be extended to provide security management functions that meet the security User Stories Essentially the Security Management interface is a policy based extension of the Simple Management APIs for configuration and health.

5.4 Relevant TM Forum catalyst results and studies

OSS/BSS Futures leverages the results of a number of catalysts and studies by the TM Forum on the likely requirements on the OSS Future framework. Demonstrated at TM Forum Live 2014! :

o Closing the Loop: Data-driven Network Performance Optimization for NFV and SON: [18] This Catalyst demonstrated how to build a closed control loop using KPIs (including network performance, customer experience, and service quality data) to enable network changes, optimization and self-healing. The TM Forum Performance Management interface was used aside 3GPP interfaces to enable this in the context of ETSI’s NFV orchestration and 3GPP’s Self-Optimizing Network (SON) scenarios.

o Orchestrating SDN and NFV while Enforcing an SLA over a WAN: [19] This Catalyst demonstrates for ODCA’s Software Defined Networking Usage Model examples the use of a cloud orchestrator with OpenStack integration to provision a virtualized network topology (VMs & VNFs) while monitoring and enforcing SLAs via SDN-OpenFlow, across legacy MPLS WAN. It also demonstrated how virtual machines can be managed by monitoring SLA information in a closed control loop. Service quality metrics can be captured from virtual applications hosted by virtual machines, passed to a cloud service manager, which then determines if SLAs have been violated.

o CloudNFV™: Dynamic, data-driven Management and Operation [11] working demonstration that showed that the higher-level objectives of both ETSI NFV and the TM Forum are practically achievable today. This Catalyst delivered a metamodel for event-driven management and operations, and a live demonstration of a dynamic implementation with IMS as virtual network function deployed via OpenStack and optimized based on network telemetry to maintain quality of service.

o NFV Management Ecosystem [30] An implementation of management and orchestration (MANO) as defined by the ETSI NFV ISG is the platform to demonstrate real-time, dynamic management of capacity, performance, quality of service (QoS) and service level agreements (SLA) as well as enabling real-time billing and compensation.

o Service Bundling in a B2B2X Marketplace [10] showed how a buyer can bundle a collection of services sourced from different suppliers and deliver them seamlessly to a customer. These components could include traditional network access products, as well as NFV and IaaS products. Concrete business roles and process touchpoints enable a well-defined relationships among players in the value chain to ensure



seamless delivery. This demonstration was made possible through the use of established ebXML interfaces and newly-added REST APIs

For Digital Disruption 2014

o Multi-Cloud SDN-NFV Service Orchestration: A forthcoming Catalyst at Digital Disruption 2014. This project will demonstrate seamless management for services relying on virtualized resources residing in a public cloud. The project leverages experience form operating real time streaming service at the Sochi Olympics and is exploring the feasibility of moving to a “software defined everything” where controlling functions can be hosted as needed on cloud infrastructures, and orchestration and management can be achieved across heterogeneous multi-cloud environments.



6 Future areas of study

In the current phase the team decided explicitly to defer some topics because there were foundational topics that need to be addressed first.

6.1.1 Orchestration

To model orchestration architectural two things were recognized by the team to be necessary:

o NFV Entity Information Model: One cannot effectively orchestrate entities and their relationships without having a robust and reasonable stable information model for those entities. Information Modelling the NFV entities has been a priority for the current phase which will be used as a foundation for the next phase.

o Policy based Orchestration: based on TM Forum Live 14 June 2014 Catalyst results it seems that orchestration of NFV might be better achieved by explicit use of a policy model rather than using simpler statically defined scripting or procedural approaches to orchestration. The focus for the current phase has been to develop a policy based framework and model which include a closed control loop rather than the simpler open loop approach of some orchestration solutions. Exploiting Policy based model will be used as a foundation for the next phase of work on orchestration.

For the next phase of ZOOM the Policy Management Architecture and Information Model can be used to explore a policy based orchestration approach.

6.1.2 Service chaining

Service chaining is about how the relationships between NFV entities are formed and change dynamically. It was decided to address the relationships after the Core Information model for NFV entities and policy management had been completed.

6.1.3 Virtualization Maturity Model

Virtualization inevitably will be introduced gradually to networks and there will be a need to operate hybrid networks for quite some time.

As the industry will be learning and evolving best practice, there is a need for shared metrics and methods for assessing organization maturity in adopting operating virtualization. A Virtualization Maturity Model shared and adopted across the industry would be helpful for:

o Exchanging best practice experiences

o Evaluating what works well

o Allow service providers to benchmark themselves with other providers to establish which areas need priority attention.



7 References

7.1 References

Reference

Description Source Brief Use Summary

[1] Zoom Overview

http://www.tmforum.org/zoom/16335/home.html

TM

Forum

Overview of ZOOM benefits, goals

and principles

[2] TR229 ZOOM/NFV User Stories

http://www.tmforum.org/TechnicalReports/TR229ZOOMNFVUser/54793/article.html

https://collab.tmforum.org/sf/go/doc26173?nav=1

TM

Forum

ATIS

ETSI

Evergreen compendium of ZOOM /

NFV/ Virtualization User Stories. Uses a consistent template for capturing all User Stories and organizes them into

a service lifecycle

[3] Customer Engagement Program TM Forum

Addresses best practice and metrics for Improving Customer Engagement.

[4] Introduction to the DSRA

http://www.tmforum.org/IntroductoryGuides/Introductiontothe/52079/article.html

TM

Forum

Overview of Digital Services

Reference Architecture originally developed for multi cloud multi provider management integration.

Evolved to support Digital services and their ecosystems

[5] TMF061, Service Delivery Framework

Reference Architecture http://www.tmforum.org/TechnicalSpecifications/TMF061ServiceDelivery/55197/ar

ticle.html

TM

Forum

Precursor to DSRA [4] – provides a

more detailed architectural specification specifically on service lifecycle management

[6] Standardized Interfaces & APIs http://www.tmforum.org/StandardizedInte

rfaces/10414/home.html

TM Forum

Interfaces for managing resources and for use between management

applications.

[7] API Zone http ://www.tmforum.org/APIZone/15739/

home.html

TM Forum

API based integration interfaces – part of Fx Integration Framework focused

on REST technology and documented on GitHub and Apigee for developers.

[8] B2B2X Partnering Accelerator

http://www.tmforum.org/B2B2XPartneringAccelerator/15671/home.html

TM

Forum

Describes a systematic industrial

approach to forming and operating B2B2X partnerships. Based on member operational experiences and

TM Forum APIs.

[9] Catalyst: Implementing an Open Wholesale B2B Marketplace

http://www.tmforum.org/ImplementinganOpen/14909/home.html

TM Forum

Demonstration of B2B2X Accelerator best practice based on BT and NBN

co et al operational deployment~200 implementations.

[10] Catalyst: Service Bundling in a B2B2X

Marketplace http://www.tmforumlive.org/service-bundling-in-a-b2b2x/

TM

Forum

Demonstration of B2B2X Accelerator

best practice based applied to composition of Cloud NFV and broadband access service. Showed











http://www.tmforum.org/TechnicalSpecifications/TMF061ServiceDelivery/55197/article.html



http://www.tmforum.org/StandardizedInterfaces/10414/home.html

http://www.tmforum.org/StandardizedInterfaces/10414/home.html

http://www.tmforum.org/APIZone/15739/home.html

http://www.tmforum.org/APIZone/15739/home.html









how to design and deploy manageable composite service by

configuration in minutes.

,[11] Catalyst: CloudNFV™: Dynamic, data-driven Management and Operations


TM Forum

Demonstration of mashup of enterprise services into a manageable

compositions. Showed how to design and deploy manageable composite service by configuration in minutes.

Similar approach to [11].

[12] TMF617, Software Enabled Services Management Interface Information

Agreement, Version 1.6 http://www.tmforum.org/InformationAgreements/TMF617SoftwareEnabled/46850/a

rticle.html

TM Forum

API requirements for Simple Management API for well enabled

services /modules. Basis of management in DSRA.

[13] IG1121 NFV Readiness: VNF Procurement and Lifecycle Management

TM Forum

Assesses impact of virtualization and NFV on procurement and operations

management of the service sourcing lifecycle.

[14] IG1122 NFV Operational Readiness:

Operating a hybrid virtualization network infrastructure

TM

Forum

Proposes management dashboard for

managing hybrid networks and studies a number of exemplar migration scenarios and best practice

for migration step planning.

[15] TR178, Enabling End-to-End Cloud SLA Management

http://www.tmforum.org/TechnicalReports/TR178EnablingEndtoEnd/50148/article.html

TM Forum

Report on how to manage e2e SSL across multi-cloud multi-provider

deployments.

[16] Business Metrics Solution Suite 2.0 http://www.tmforum.org/DownloadRelease13/14772/home.html

TM Forum

TM forum Metrics suite for business management and operations and customer experience.

[17] IG1120 Virtualization Impact on SLA Management

TM Forum

Assess the additional impacts on SLA of moving to virtualized environment as compared to TR 178.

[18] Catalyst: Closing the Loop: Data-driven Network Performance Optimization for NFV and SON

http://www.tmforumlive.org/closing-the-loop/

TM Forum

Investigates use of closed control loop for managing NFV and SON based networks solutions. Uses TMF r

Performance management interface and uses a policy management approach.

[19] Catalyst Orchestrating SDN and NFV while Enforcing an SLA over a WAN http://www.tmforumlive.org/enforcing-sla/

TM Forum

Investigation of management of SA over multi cloud multi-data center multi-technology environment.

[20] IG1124 ZOOM NFV Security Fabric Overview

TM Forum

Initial scope of a approach to mangling e2e Security of virtualized

services that sets scope and functional requirements on two Security Management APIs


http://www.tmforum.org/InformationAgreements/TMF617SoftwareEnabled/46850/article.html






http://www.tmforum.org/DownloadRelease13/14772/home.html

http://www.tmforum.org/DownloadRelease13/14772/home.html



http://www.tmforumlive.org/enforcing-sla/



[21] TR211 On line Partnering Step by step Guide

http://www.tmforum.org/PartnershipWorkspace/16188/home.html

TM Forum

ON line step by step guide to the B2B2Accerator pack [8] with

templates and completed examples.

[22] Developer Pack: Simple Management

API http://www.tmforum.org/DeveloperPackSimple/14254/home.html

TM

Forum

Developer focused material for Simple

Management API

[23] IG1118 OSS/BSS Futures – Preparing the Future Mode of Operation

TM Forum

Companion document with a deeper dive on the impacts of Virtualization or OSS and BSS.

[24] TR235 Policy Model and Architecture Snapshot

TM Forum

Policy management framework for inclusion in future TM Forum Information Framework that support

know Policy management Requirements for NFV.

[25] Draft ETSI GS NFV-SEC 001

V0.2.1Network Functions Virtualisation (NFV); NFV Security; Problem Statement

ETSI Core requirement for NFV e2e

Security.

[26] IG1100 Product Lifecycle Management

Introductory Guide, Version 1.1 http://www.tmforum.org/browse.aspx?linkID=50699&docID=18745

TM

Forum

Provides comprehensive description

and model for Product and service lifecycle management.

[27] TR234 ZOOM Information Model Snapshot


TM Forum

Proposed update to Information Framework model to support virtualization. Key assets are:

integration with existing deployed non virtualized networks: supports all key ETIS NFV MANO Concepts: supports

modelling of non-functional requirements on the NFVI (Hypervisors, Virtual Machines)

[28] eBook: Blueprint for end to end management

TM Forum

TM Forum Quick Insight guide

[29] eBook: DevOps transformation

framework for the digital ecosystem

TM

Forum

TM Forum Quick Insight guide

30 NFV Management Ecosystem

An implementation of management and orchestration (MANO) as defined

by the ETSI NFV ISG is the platform to demonstrate real-time, dynamic management of capacity,

performance, quality of service (QoS) and service level agreements (SLA) as well as enabling real-time billing

and compensation. This rapid implementation of a NFV ecosystem is enabled through use of

standardized APIs from TM Forum and other organizations



http://www.tmforum.org/DeveloperPackSimple/14254/home.html

http://www.tmforum.org/DeveloperPackSimple/14254/home.html

http://www.tmforum.org/browse.aspx?linkID=50699&docID=18745

http://www.tmforum.org/browse.aspx?linkID=50699&docID=18745




8 Administrative Appendix

This Appendix provides additional background material about the TM Forum and this document. In general, sections may be included or omitted as desired; however, a Document History must always be included.

8.1 Document History

8.1.1 Version History

<This section records the changes between this and the previous document version as it is edited by the team concerned. Note: this is an incremental number which does not have to match the release number and used for change control purposes only>

Version Number Date Modified Modified by: Description of changes

<<Version Number

>>

DD/MMM/YY <<name>> Description e.g. first

issue of document

V 14.0.2 30/10/2014 D Milham Draft with team informal review comments

incorporated.

V14.0.3 31/10/2014 D Milham On line edits from review call

V14.0.4 4/11/2014 D Milham Verbal edits proposed from

review call 31st Oct

V14.0.5 6/11/2014 D Milham Adjustments to address final editorial comment review

period

8.1.2 Release History

< This section records the changes between this and the previous Official document release. The release number is the ‘Marketing’ number which this version of the document is first being assigned to >

Release Number Date Modified Modified by: Description of

changes

<<Release Number >>

DD/MMM/YY <<name>> Description e.g. first issue of document

Date post:	07-Jul-2015
Category:	Technology
Upload:	jdrevuelta
View:	765 times
Download:	7 times