TM Forum 2020. All Rights Reserved. TM Forum Exploratory Report NaaS Service Fulfillment Guidelines IG1224 Team Approved Date: 02-Oct-2020 Release Status: Pre-production Approval Status: Team Approved Version 1.0.0 IPR Mode: RAND IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 2 of 28 Notice Copyright © TM Forum 2020. 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: 8 Campus Drive, #105 Parsippany, NJ 07054 USA Tel No. +1 973 944 5100 Fax No. +1 973 998 7916 TM Forum Web Page: www.TM Forum.org IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 3 of 28 Table of Contents Notice ................................................................................................................................... 2 Table of Contents ............................................................................................................... 3 Executive Summary ............................................................................................................... 4 Introduction .......................................................................................................................... 5 1. Functional Architecture & Components ............................................................................ 7 2. Guideline Scenario ........................................................................................................... 10 3. Service Design Time ......................................................................................................... 11 3.1. Service Decomposition ................................................................................. 11 3.1.1. Catalyst Example: NaaS Wavelength Service Decomposition .................. 12 3.2. Service Modeling .......................................................................................... 13 3.3. Service Specification ..................................................................................... 14 3.3.1. Catalyst Example: NaaS Wavelength Service Specification ...................... 15 3.4. Service Catalog.............................................................................................. 17 3.5. Considerations in selecting service fulfillment APIs ..................................... 19 4. Service Run Time ............................................................................................................. 21 4.1. Role of E2E Service Management Domain ................................................... 21 4.2. Sequence diagram ........................................................................................ 21 4.3. Order Management ...................................................................................... 23 4.4. Service and Resource Inventory ................................................................... 24 5. Reference Material .......................................................................................................... 26 5.1. Automating NaaS Lambda Services Catalyst ................................................ 26 5.1.1. Catalyst Functional Architecture .............................................................. 26 6. Administrative Appendix ................................................................................................. 28 6.1. Document History ......................................................................................... 28 6.1.1. Version History ......................................................................................... 28 6.1.2. Release History ......................................................................................... 28 6.2. Acknowledgments ........................................................................................ 28 IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 4 of 28 Executive Summary The purpose of this document is to describe how a domain engineer/designer or architect would use the TM Forum Open Digital Architecture (ODA) assets to expose and manage the lifecycle of the production domain capabilities (network technologies, media, applications, etc.) as services. These capabilities are also referred to as Network as a Service or NaaS. These guidelines focus on the service fulfillment function of the service lifecycle. This NaaS Service Fulfillment document will help both IT and production domain solution designers and architects build working solutions by providing them with sample use cases showing how this can be done. There are multiple options in how to implement service fulfillment solutions and these will vary according to what the service providers is (or will be) using. Nevertheless, these guidelines describe best practices for which approach to take in different circumstances and develop a framework solution across systems, processes, data and people utilizing standards, and policies, while putting compliance mechanisms and measures in place. This is important when a diverse collection of individuals from different parts of an organization are working together to deliver solutions to their business based on the common vision of an Open Digital Architecture (ODA) with interoperable industry standard Open APIs. This practice builds on information in various implementation guides (e.g. Open API design guidelines), TMF APIs, in particular TMF909 NaaS API component suite, alongside catalysts and members' contributions on their implementations. These ODA Transformation Guides are attempting to "join the dots" and utilizes "best practice" processes as described by members who have successfully implemented TM Forum Open APIs and NaaS Framework. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 5 of 28 Introduction The TM Forum's Open Digital Architecture has been designed to enable members to build highly complex, but very flexible solutions by using sets of loosely coupled components, that expose their business functionality via a set of industry agreed Open APIs. This document proposes that every production group (e.g. Transport, IP, access, media, etc.) expose and manage service capabilities (i.e. Network as a Service) in the Open Digital Architecture (ODA) from the Production function block to the Core Commerce function block via the decoupling and integration function block (API) to allow for zero touch automation. Figure 1: Open Digital Architecture Functional Architecture NaaS simplifies the Networks' IT Communication and is fundamental to current Network Evolution architecture. Today most OSS and BSS need to understand how the underlying network works and how each product is designed down to each resource used, which makes change, costly, manual and slow. These systems are also inter-connected using suppliers' custom APIs for each network domain making product additions or modifications, a large project within both IT and Network domains. NaaS enables network capabilities to be exposed as reusable blocks, hiding "How" the capabilities are defined and using standards Open APIs, agnostic of technology and vendor. NaaS is changing the current lengthy processes used from idea to product delivery and maintenance leading to shortened time to market and enhanced customer experience. Some NaaS principles that are applied in this document include: • Reusable simple (atomic) services exposed by production domains • Complex and simple services reused by multiple products and offers • Service abstraction (hiding how the service is created) • Usage of TM Forum APIs as the IT to Network (Core Commerce to Production) decoupling and integration function block IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 6 of 28 Watch the video describing the drivers behind AT&T's catalyst implementation of NaaS. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 7 of 28 1. Functional Architecture & Components The ODA functional architecture has been adapted in Figure 2 to reflect Network as a Service concepts of Operational Domain Management (ODM) , within the ODA Production function block, exposing their services (customer facing services - CFS) to the Core Commerce Management / IT function block, so they become product(s) or exposing to other ODMs, so they become reusable services in complex multi-operational domain services. Depending on the service provider management capabilities and choice, multi-operational domain services can be managed by E2E Service Management domain (via Macro Service Orchestrator) or one Operational Domain Manager can orchestrate across another Operational Domain for example the optical domain orchestrating and consuming the cloud domain CFS for its VNF support. The Intelligence Management function block provides “closed-loop” capabilities and consume data from the Production function block. It relies on analytical data to develop Insights for decision support, or intent-based actions or advice. The Decoupling and Integration function block in ODA Functional Architecture can be leveraged for all the API interactions between the production components and between the Core Commerce Management, the Production and Intelligence Management function blocks. Within Production the service layer components should also interact using APIs with the resource layer using TMF Open APIs or using 3rd party Standards Development Organizations' (SDO) APIs such as MEF LSO, 3GPP, ETSI, etc. Figure 2: NaaS support in TMF ODA IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 8 of 28 With virtualization, cloud, AI and SDN capabilities making the network more agile in scaling and healing, it is now time for operational domain management (ODM) within ODA Production to dynamically manage their services and resources and only expose the minimal characteristics of the service to the product catalog within CCM. This enables the change of network suppliers, the change from physical network function (PNF) to virtual network functions (VNF), or even the change of technology with limited, if any, impact to the product/IT Domain. Today most services are assembled by the IT domain and each operational domain (e.g. transport, wireless, VPN, Media, Unified Communication, etc.) are siloed. Each IT group such as Order to Fulfillment or Assurance or Billing comes with their specific requests and ways of working to each ODM and each of the IT group needs to learn about "how" things work in the ODM. In a NaaS framework, the management of complex services can be done in dedicated End-to-End service management (E2E SM) domain. The E2E SM domain must expose, orchestrate, assure and manage complex services from typically an assembly of customer facing services (CFS) exposed from various ODMs (the ODM CFS can also be referred as atomic service). A dedicated E2E SM domain typically manages only other operational domain CFS while a typical operational domain manages its CFS, Resource Facing Services (RFS) and resources and possibly other ODM CFS e.g. Cloud Services for VNFs. Using rules and policies, ODM should support closed-loop architecture for their services (simple and complex). Where applicable ODM should deliver an enhanced experience for customers (through automated CLA) and Customer Support Representatives (CSR) dealing with customers, by delivering a view of the E2E complex/simple service through a single application. Note that this document's focus is only on service fulfillment. Per the ODA functional architecture, the Decoupling and Integration block is a key function of the NaaS framework and uses an API notification handler as well as an internal API gateway acting as service discovery and routing function within the CSP network. The internal API Gateway abstracts ODM from the API destination, performs security functions and ensures API requests are valid as per TMF630 design guidelines. A best practice is for the internal API gateway to include a master service directory which replaces ODM labels (e.g. IP, NFV, Access, etc.) in the TMF API URLs with the correct operational domain controller to eliminate hard coded addressing and ensures ODM consistency. This enables re-use and easy transformation from the traditional process to an ODM controller when the ODM is ready or when there is a change for the service from one ODM to another ODM without modifying any URL addresses. A good example of the E2E SM domain and its integration with ODMs is found in the Automating NaaS Lambda Services Catalyst (C20.0.01). Figure 3 represents the catalyst's functional architecture. The catalyst features an enterprise wavelength service and a wholesale ROADM service. The enterprise wavelength service is abstracted, exposed and managed from the E2E SM Domain and is composed of multiple ODM services. When the E2E SM domain receives an order from the IT domain, it decomposes this enterprise wavelength service across multiple reusable services that have been exposed by ODM such as ROADM or OROADM domain depending on the locations, the tail service domain that defines the connection services between the transponders and the customer equipment (e.g., routers) at the A- and Z- locations, and a Link Aggregation Group (LAG) domain for the E2E LAG service. The wholesale ROADM service reuses the existing ROADM atomic service that is exposed directly to the IT Product Catalog and converted into a sellable product. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 9 of 28 This catalyst functional architecture also makes use of an internal API gateway with its master service directory, and a notification handler. For more detailed information on this architecture and its components, please refer to the reference material section. Figure 3: Automating NaaS Lambda Services Catalyst - Functional Architecture IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 10 of 28 2. Guideline Scenario This NaaS Service Fulfillment guidelines will go through the following scenario: • Design Time o Service decomposition, reusability & abstraction o Service modeling o Service specification o Selection of fulfillment APIs • Run Time o Roles of E2E Service Domain o Sequence flows from product ordering to service activation o Order Management o Inventory IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 11 of 28 3. Service Design Time 3.1. Service Decomposition The keys to successful NaaS implementation are to • Create reusable services • Use consistent target service model • Enable production network domains to control how resources are used • Expose abstracted service models The journey starts with identifying, understanding, and digesting the concept of service. It is easy to look at what was implemented in the OSS/BSS today and duplicate these services, attributes and concepts as is, similar to when suppliers took their original code and ported it to "white boxes" without the concept of decomposition and micro-services. Instead, IT and Production/Network domains need to understand the true nature of network abstraction and reusability (see Figure 4) so that digital experiences for end customers and networks can evolve in a decoupled and modular fashion. Figure 4: Two key principles of NaaS are abstraction and reusability. The first best practice when transforming to a NaaS framework is to take an inventory of products with a mapping of services and resources. Looking at each service, the key is to decompose the current service definition into a set of atomic services that can be reused by other services. There are no right or wrong, and the reusable “atomic” services will vary by service providers depending on the services they have, along with their current systems and processes. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 12 of 28 While each atomic service can be orchestrated from the Service Order Management (SOM) in the IT domain, the advantages of using an E2E SM for the orchestration are • Abstraction of the complex service - OSS/BSS don't even know the atomic services exist • Single domain responsible for the service - removing domain silos with a single place to perform trouble to resolve if problems occur • Closed-loop architecture - each ODM including E2E SM are responsible for maintaining the service in proper state and taking action (e.g. via closed-loop) in case of problems. 3.1.1. Catalyst Example: NaaS Wavelength Service Decomposition In the Automating NaaS Lambda service catalyst, the process above was used and the wavelength product sold to enterprises was decomposed into a “complex” wavelength service which was exposed and managed by the E2E SM domain. This enterprise wavelength service was then decomposed further into a set of reusable services orchestrated by the E2E SM across multiple domains including a ROADM connection service (or OROADM connection depending on locations), client tail services for locations A and Z connecting the customer routers (MPCIO) to the transponders, and a Link Aggregation Group (LAG) service as per Figure 5. Figure 5: Enterprise Wavelength Service Composition When the CSP product manager received a request to sell a wavelength product to wholesaler, the decision was to reuse the existing ROADM connection service exposed by the ROADM domain on its own saving lots of time and money for development, integration, and testing. See Figure 6. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 13 of 28 Figure 6: Wholesale Wavelength ROADM Service 3.2. Service Modeling As ODMs expose services, each service idea can be transformed into a business definition which includes business requirements the service will need to support such that product managers understand the type of commercial offers they can create. Figure 7: Service Idea to Definition to Specification IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 14 of 28 Product manager(s) and ODM lead(s) need to review services that can be reused and the policies across each domain to ensure the end user SLA for that new service can be supported. The new service specification should be defined using common language, known implementation commitments and agreed data model for each lifecycle functions see Figure 7. TMF specifications are technology agnostic hence very generic. Consequently, best practices are achieved when consistency across IT and ODMs for service specifications is used, with terminology, rules and references agreed and written down to be used across catalog, URL patterns, notification and event paradigms, payload definition, error codes, lifecycle states, etc. See figure 8. Figure 8: Consistency across Service Specification 3.3. Service Specification The service specification exposed by ODMs should reflect an abstraction of the actual service or even resources in some cases. For example, if device/network termination unit is provided as part of the service, exposing a generic "NTU" model/service with or without an attribute for specifying the “brand” enables the telco domain to change the supplier without requiring a change at the product layer. For enterprise services, service providers may want to offer "granular" access to device features from their suppliers e.g. the customer can order "technology specific" capabilities across DSLAM vendors. A consequence of exposing supplier's Resource Function Service (RFS) i.e. features/capabilities upward to the customer order portal is that any change in supplier and/or technology and/or feature/capability requires a realignment with the order portal to the new RFS templates and rewrite code (and perform testing, align releases, etc.) from order IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 15 of 28 to activation. So, a best practice would be to review what can be exposed in an abstracted fashion or use an attribute with toggle on/off that would provide the intent of the request that the domain needs to fulfill. 3.3.1. Catalyst Example: NaaS Wavelength Service Specification In the catalyst, the enterprise wavelength service specification was originally defined leveraging the OSS/BSS specification and reviewing what each ODM required as minimum attributes. See Figure 9. Figure 9: Original Enterprise wavelength service and ODM service specifications This generated a lot of attribute duplication. A best practice was derived to review and categorize the list of attributes. For example, separating the data relating to customer context, the service context or common context and review the data that each domain really requires. Refer to Figure 10. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 16 of 28 Figure 10: Service Context Example Every application should only persist the attributes that they really need to avoid synchronizing and sending updates to each ODM. For example, if the customer contact email address was to change the tail and ROADM domains should not need to be updated. During run-time some attributes could be accessed via API schema references. Figure 11 below is an updated diagram of the wavelength service model. Other categories such as SLO/SLS and KQI/KPIs, service tests, etc. will be added in future version of this document. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 17 of 28 Updated Wavelength Service Model Figure 11: Updated Enterprise wavelength service and ODM service specifications 3.4. Service Catalog The service catalog and the runtime API data model are a good source for guiding the definition of objects. The best practice is to use Place for address information and RelatedParty for customer information in the provisioning APIs i.e. TMF641, TMF640, TMF633, etc. The CatalystExample:NaaSWavelengthServiceSpecification model have used Service Characteristics to represent address and customer information to meet the short term requirements of the catalyst. Once the service specification is defined, it is persisted in the Service Catalog providing a centralized repository of all the service definitions offered by operational (or partner) domain(s). Service specification is published in the centralized Service Catalog by all the domains (operational and partner domains, including E2E service domain) for the purpose of discovery and reference. The Service Catalog Management allows the management of the entire lifecycle of the Service Catalog elements and the consultation of service catalog elements during several processes such as service activation, service assurance, etc. During runtime, the service catalog is only used to retrieve service definitions i.e. specifications. During the design time, it is used to retrieve, create and update the service specification. Figure 12 below shows the service specification schema used to derive each individual (complex and atomic) service definition. For the definition of each attribute please review TMF633 Service Catalog API. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 18 of 28 Figure 12: Service Specification Definition Each ODM should support their own catalog and expose (via TMF633 service catalog notifications) their customer facing services (or private services if these can only be used by another ODM) as they become available. Listeners such as IT Product Catalog and E2E SM domains would then automatically receive notification (via TMF633 notification) of any new available services. E2E SM domain would also expose its customer facing services via TMF633 service catalog notifications without exposing any definition of the reusable CFS and/or RFS it uses to compose that service. Figure 13 below shows all of the service specifications used in the catalyst wavelength service that the E2E SM domain holds. IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 19 of 28 Figure 13: Example from Automating NaaS Lambda Service Catalyst - Wavelength service from E2E Service Management Domain Service Catalog 3.5. Considerations in selecting service fulfillment APIs We have looked at the services, decomposed them into complex and reusable atomic services, reviewed the data models and service specifications, now we need to select the API to perform the service fulfillment. The service fulfillment APIs within the scope of this document are TMF641 Service Ordering Management and TMF640 Service Activation and Configuration. There can be many patterns in the service provisioning, the most used patterns are given below: • Type 1 : Physical infrastructure deployment required for the provisioning of service. This involves complex orchestration process with a long lead time. This provisioning may require manual tasks, integration with third party via order management process, including email, calls etc. TMF641 is better suited to support this type of provisioning. • Type 2 : Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2. • Type 2a : Rapid activation : The provisioning is performed by zero touch orchestration. This may also include seamless integration with third parties’ providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous). TMF640 is found best suited to support this type of provisioning. • Type 2b: Complex activation : The provisioning may include complex orchestration with long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies. This provisioning may also require manual tasks and integration with third party via order management process, including email, calls etc. TMF641 is found best suited to support this type of provisioning. For services provisioned using TMF641 following Type 1 and Type 2b pattern, there is an option to use TMF640 to perform modifications. This enables rapid provisioning of simple modifications, where there is no need for additional infrastructure and where there are no IG1224 NaaS Service Fulfillment Guidelines © TM Forum 2020. All Rights Reserved. Page 20 of 28 commercial impact. Using TMF640 simplifies the lifecycle management of services when using assurance portals and external partners. However following aspects should also be taken into consideration: • Are there scenarios where changes in certain attributes result in complex ordering process or additional infrastructure, whereas change in other attributes will be simple activation? For e.g. Upgrading bandwidth may require upgrade in physical infrastructure, however configuring new Management IP addresses will be simple provisioning. • Are there scenarios where changes in some attribute values result in complex ordering process or additional infrastructure, whereas other values can be easily updated with simple provisioning? E.g. Upgrading bandwidth up to 20 Mbps can be a simple activation and configuration on an existing infrastructure, however any bandwidth value above will need a new infrastructure. It is important that such complexities are abstracted from the consumer. If such complexities exists in the modification of the service, TMF641 is better suited for lifecycle management. The ideal implementation is to define policies related to API selection within the service definition. The consumers will choose the API by a catalog driven process and thereby all these complexities will be resolved & driven by catalog policies. This may require enhancements in the current TMF service catalog architecture. Refer to section 7. References for the slide pack on the TMF640 and TMF641 Service Provisioning document. Figure 14: Considerations in selecting service fulfillment APIs - TMF640/TMF641