Gs ZSM008v010101p

ETSI GS ZSM 008 V1.1.
1 (2022-07)
GROUP SPECIFICATION
Zero-touch network and Service Management (ZSM);

Cross-domain E2E service lifecycle management
Disclaimer
The present document has been produced and approved by the Zero-touch network and Service Management (ZSM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.
2 ETSI GS ZSM 008 V1.1.1 (2022-07)
Reference
DGS/ZSM-008ed111_CrossDomE2eS
Keywords
management, network, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B

Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability

The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GS ZSM 008 V1.1.1 (2022-07)
Contents
Intellectual Property Rights ................................................................................................................................5
Foreword.............................................................................................................................................................5
Modal verbs terminology....................................................................................................................................5
1 Scope ........................................................................................................................................................6
2 References ................................................................................................................................................6
2.1 Normative references ......................................................................................................................................... 6
2.2 Informative references ........................................................................................................................................ 8
3 Definition of terms, symbols and abbreviations .....................................................................................10
3.1 Terms................................................................................................................................................................ 10
3.2 Symbols ............................................................................................................................................................ 10
3.3 Abbreviations ................................................................................................................................................... 10
4 Overview of cross-domain E2E service lifecycle management .............................................................11
5 Cross-domain E2E service lifecycle management processes .................................................................14
5.1 Overview .......................................................................................................................................................... 14
5.2 Service onboarding ........................................................................................................................................... 14
5.2.1 Overview .................................................................................................................................................... 14
5.2.2 Process: Service onboarding ....................................................................................................................... 14
5.2.2.1 Description ............................................................................................................................................ 14
5.2.2.2 Procedure flow ...................................................................................................................................... 15
5.2.2.3 Related management services ............................................................................................................... 17
5.3 Service fulfilment ............................................................................................................................................. 17
5.3.1 Overview .................................................................................................................................................... 17
5.3.2 Process: Service instantiation ..................................................................................................................... 17
5.3.2.1 Description ............................................................................................................................................ 17
5.3.2.2 Procedure flow ...................................................................................................................................... 18
5.3.3 Process: Service activation ......................................................................................................................... 21
5.3.3.1 Description ............................................................................................................................................ 21
5.3.3.2 Procedure flow ...................................................................................................................................... 22
5.3.4 Process: Service configuration .................................................................................................................... 23
5.3.4.1 Description ............................................................................................................................................ 23
5.3.4.2 Procedure flow ...................................................................................................................................... 24
5.3.5 Process: Service deactivation...................................................................................................................... 25
5.3.5.1 Description ............................................................................................................................................ 25
5.3.5.2 Procedure flow ...................................................................................................................................... 26
5.3.6 Process: Service decommissioning ............................................................................................................. 27
5.3.6.1 Description ............................................................................................................................................ 27
5.3.6.2 Procedure flow ...................................................................................................................................... 28
5.3.7 Process: Update E2E inventory / topology ................................................................................................. 30
5.3.7.1 Description ............................................................................................................................................ 30
5.3.7.2 Procedure flow ...................................................................................................................................... 31
5.4 Service assurance ............................................................................................................................................. 34
5.4.1 Overview .................................................................................................................................................... 34
5.4.2 Process: Service assurance set-up ............................................................................................................... 34
5.4.2.1 Description ............................................................................................................................................ 34
5.4.2.2 Procedure flows..................................................................................................................................... 35
5.4.2.2.1 Producer-initiated set-up of information collection related to domain service instance .................. 35
5.4.2.2.2 Consumer-initiated set-up of collecting "E2E-service specific" information related to domain
service instances .............................................................................................................................. 37
ETSI
4 ETSI GS ZSM 008 V1.1.1 (2022-07)

5.4.3 Process: Service quality management ......................................................................................................... 39
5.4.3.1 Description ............................................................................................................................................ 39
5.4.3.2 Procedure flows..................................................................................................................................... 40
5.4.3.2.1 Main service quality management flow ........................................................................................... 40
5.4.3.2.2 Auxiliary process to collect additional domain performance data ................................................... 43
5.4.4 Process: Service problem management....................................................................................................... 47
5.4.4.1 Description ............................................................................................................................................ 47
5.4.4.2 Procedure flow ...................................................................................................................................... 48
5.4.5 Process: Service assurance tear-down......................................................................................................... 51
5.4.5.1 Description ............................................................................................................................................ 51
5.4.5.2 Procedure flows..................................................................................................................................... 52
5.4.5.2.1 Producer-initiated tear-down of information collection related to domain service instances .......... 52
5.4.5.2.2 Consumer-initiated tear-down of collecting "E2E-service specific" information related to
domain service instances ................................................................................................................. 54
6 Management domain support for cross-domain E2E service lifecycle management .............................56
6.1 Overview .......................................................................................................................................................... 56
6.2 3GPP Core domain and 3GPP RAN domain.................................................................................................... 56
6.3 Fixed access domain ......................................................................................................................................... 63
6.4 Transport domain ............................................................................................................................................. 67
6.4.1 Overview .................................................................................................................................................... 67
6.4.2 Optical transport domain with IETF-based NBI ......................................................................................... 67
6.4.3 Optical transport domain with TAPI as NBI .............................................................................................. 71
6.4.4 Transport domain based on Layer 2 / Layer 3 VPNs .................................................................................. 79
6.4.5 Transport slices ........................................................................................................................................... 83
6.5 Cloud domain ................................................................................................................................................... 87
7 Gaps and commonalities ........................................................................................................................91
Annex A (normative): Management services.....................................................................................95
A.1 Overview ................................................................................................................................................95
A.2 Additional services .................................................................................................................................95
A.2.1 E2E services topology management service..................................................................................................... 95
A.3 Additional service capabilities ...............................................................................................................95
A.3.1 Domain inventory information service ............................................................................................................. 95
A.3.2 Domain topology information service .............................................................................................................. 96
A.3.3 Managed services catalogue management service ........................................................................................... 96
Annex B (informative): Further northbound interfaces .....................................................................97

B.1 Domain northbound interfaces specified by TMF Open API.................................................................97
Annex C (informative): Change History ............................................................................................100
History ............................................................................................................................................................105
ETSI
5 ETSI GS ZSM 008 V1.1.1 (2022-07)
Intellectual Property Rights

Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the
oneM2M Partners. GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Zero-touch network and
Service Management (ZSM).
Modal verbs terminology

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI GS ZSM 008 V1.1.1 (2022-07)
1 Scope
The present document investigates the management of End to End (E2E) services across Management Domains (MDs).
It defines the management processes during the lifecycle of E2E services (covering onboarding processes, fulfilment
processes and assurance processes) and describes the interactions between E2E service management domain and
management domains during these processes.
Furthermore, it maps the management services used in the management processes to the northbound interfaces of
selected technology domains and references the underlying specifications of these interfaces. These mappings enable
the automation of lifecycle management across domains.
2 References
2.1 Normative references

References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS ZSM 002: "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[2] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
[3] ETSI GS NFV-IFA 013: "Network Functions Virtualisation (NFV) Release 3; Management and
Orchestration; Os-Ma-nfvo reference point - Interface and Information Model Specification".
[4] ETSI GS NFV-IFA 031: "Network Functions Virtualisation (NFV) Release 3; Management and
Orchestration; Requirements and interfaces specification for management of NFV-MANO".
[5] ETSI GS NFV-SOL 005: "Network Functions Virtualisation (NFV) Release 3; Protocols and Data
Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point".
[6] ETSI TS 128 532: "5G; Management and orchestration; Generic management services (3GPP
TS 28.532 Release 16)".
[7] ETSI TS 128 531: "5G; Management and orchestration; Provisioning (3GPP TS 28.531
Release 16)".
[8] ETSI TS 128 541: "5G; Management and orchestration; 5G Network Resource Model (NRM);
Stage 2 and stage 3 (3GPP TS 28.541 Release 17)".
[9] ETSI TS 128 632: "Universal Mobile Telecommunications System (UMTS); LTE;
Telecommunication management; Inventory Management (IM) Network Resource Model (NRM)
Integration Reference Point (IRP); Information Service (IS) (3GPP TS 28.632 Release 16)".
[10] ETSI TS 128 552: "5G; Management and orchestration; 5G performance measurements (3GPP
TS 28.552 Release 16)".
[11] ETSI TS 128 554: "5G; Management and orchestration; 5G end to end Key Performance
Indicators (KPI) (3GPP TS 28.554 Release 16)".
ETSI
7 ETSI GS ZSM 008 V1.1.1 (2022-07)
[12] ETSI TS 128 622: "Universal Mobile Telecommunications System (UMTS); LTE; 5G;
Telecommunication management; Generic Network Resource Model (NRM) Integration
Reference Point (IRP); Information Service (IS) (3GPP TS 28.622 Release 16)".
Telecommunication management; Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) Network Resource Model (NRM) Integration Reference Point (IRP); Information
Service (IS) (3GPP TS 28.658 Release 16)".
Telecommunication management; Evolved Packet Core (EPC) Network Resource Model (NRM)
Integration Reference Point (IRP); Information Service (IS) (3GPP TS 28.708 Release 16)".
[15] ETSI TS 132 425: "LTE; Telecommunication management; Performance Management (PM);
Performance measurements Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
(3GPP TS 32.425 Release 16)".
[16] ETSI TS 132 426: "LTE; Telecommunication management; Performance Management (PM);
Performance measurements Evolved Packet Core (EPC) network (3GPP TS 32.426 Release 16)".
[17] ETSI TS 128 527: "LTE; Telecommunication management; Life Cycle Management (LCM) for
mobile networks that include virtualized network functions; Stage 2 (3GPP TS 28.527
Release 16)".
[18] BBF TR-384: "Cloud Central Office Reference Architectural Framework", Technical Report,
Broadband Forum, January 2018.
[19] BBF TR-411: "Definition of interfaces between CloudCO Functional Modules", Technical Report,
Broadband Forum, April 2021.
[20] BBF TR-454: "YANG Modules for Network Map & Equipment Inventory", Technical Report,
Broadband Forum, July 2021.
[21] TMF628 (Version 2.0.1): "Performance Management API REST Specification", TM Forum
Specification.
[22] TMF633 (Version 4.0.0): "Service Catalog Management API REST Specification", TM Forum
Specification.
[23] TMF638 (Version 4.0.1): "Service Inventory Management API User Guide", TM Forum
Specification.
[24] TMF639 (Version 4.0.1): "Resource Inventory Management API User Guide", TM Forum
Specification.
[25] TMF640 (Version 4.0.1): "Service Activation and Configuration API User Guide", TM Forum
Specification.
[26] TMF641 (Version 4.1.0): "Service Ordering Management API User Guide", TM Forum
Specification.
[27] TMF642 (Version 4.0.1): "Alarm Management API User Guide", TM Forum Specification.
[28] TMF645 (Version 4.0.1): "Service Qualification Management API User Guide", TM Forum
Specification.
[29] TMF653 (Version 4.1.0): "Service Test Management API User Guide", TM Forum Specification.
[30] TMF657 (Version 4.0.1): "Service Quality Management API User Guide", TM Forum
Specification.
[31] TMF664 (Version 4.0.1): "Resource Function Activation and Configuration API User Guide", TM
Forum Specification.
ETSI
8 ETSI GS ZSM 008 V1.1.1 (2022-07)
[32] ONF TR-547: "TAPI Reference Implementation Agreement", Version 1.1.
NOTE: Available at https://opennetworking.org/wp-content/uploads/2021/12/TR-547-

TAPI_ReferenceImplementationAgreement_v1.1.pdf.
[33] ONF TR-548: "TAPI Reference Implementation Agreement for Streaming", Version 1.1.
NOTE: Available at https://opennetworking.org/wp-content/uploads/2021/12/TR-548-

TAPI_ReferenceImplementationAgreement-Streaming_v1.1.pdf.
[34] ONF Transport API SDK Version 2.1.3.
NOTE: Available at https://github.com/OpenNetworkingFoundation/TAPI/releases/tag/v2.1.3.
[35] IETF RFC 6020: "YANG - A Data Modeling Language for the Network Configuration Protocol
(NETCONF)".
[36] IETF RFC 6241: "Network Configuration Protocol (NETCONF)".
[37] IETF RFC 7950: "The YANG 1.1 Data Modeling Language".
[38] IETF RFC 8040: "RESTCONF Protocol".
[39] IETF RFC 8299: "YANG Data Model for L3VPN Service Delivery".
[40] IETF RFC 8345: "A YANG Data Model for Network Topologies".
[41] IETF RFC 8346: "A YANG Data Model for Layer 3 Topologies".
[42] IETF RFC 8466: "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service
Delivery".
[43] IETF RFC 8639: "Subscription to YANG Notifications".
[44] IETF RFC 8641: "Subscription to YANG Notifications for Datastore Updates".
[45] IETF RFC 8650: "Dynamic Subscription to YANG Events and Datastores over RESTCONF".
[46] IETF RFC 8795: "YANG Data Model for Traffic Engineering (TE) Topologies".
[47] IETF RFC 8944: "A YANG Data Model for Layer 2 Network Topologies".
[48] IETF RFC 9094: "A YANG Data Model for Wavelength Switched Optical Networks (WSONs)".
[49] IETF RFC 9182: "A YANG Network Data Model for Layer 3 VPNs".
2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document, but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS ZSM 009-1: "Zero-touch network and Service Management (ZSM); Closed-loop
automation; Part 1: Enablers".
[i.2] ETSI TS 123 288: "5G; Architecture enhancements for 5G System (5GS) to support network data
analytics services (3GPP TS 23.288 Release 16)".
ETSI
9 ETSI GS ZSM 008 V1.1.1 (2022-07)
[i.3] 3GPP TS 28.104: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Management and orchestration; Management Data Analytics (MDA)",
Release 17.
[i.4] draft-openconfig-rtgwg-gnmi-spec: Shakir, R. et al.: "gRPC Network Management Interface

(gNMI)", Internet draft, Version 01, expired, March 2018.
NOTE: Available at https://datatracker.ietf.org/doc/html/draft-openconfig-rtgwg-gnmi-spec-01.
[i.5] "gRPC®: A high performance, open source universal RPC framework", Invoked 2021-12-10.
NOTE: Available at http://grpc.io.
[i.6] draft-ietf-teas-ietf-network-slices: "Framework for IETF Network Slices", Internet draft,

Version 10, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/.
[i.7] draft-ietf-teas-ietf-network-slice-nbi-yang: "IETF Network Slice Service YANG Model", Internet

draft, Version 01, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/.
[i.8] draft-ietf-teas-yang-te: "A YANG Data Model for Traffic Engineering Tunnels, Label Switched
Paths and Interfaces", Internet draft, Version 29, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/.
[i.9] draft-ietf-teas-yang-path-computation: "YANG Data Model for requesting Path Computation",

Internet draft, Version 18, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation/.
[i.10] draft-ietf-ccamp-otn-tunnel-model: "YANG data model for tunnels in OTN TE Networks",

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-tunnel-model/.
[i.11] draft-ietf-ccamp-wson-tunnel-model: "A Yang Data Model for WSON Tunnel", Internet draft,
Version 06, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-tunnel-model/.
[i.12] draft-ietf-ccamp-client-signal-yang: "A YANG Data Model for Transport Network Client
Signals", Internet draft, Version 06, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-client-signal-yang/.
[i.13] draft-ietf-ccamp-otn-topo-yang: "A YANG Data Model for Optical Transport Network Topology",
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/.
[i.14] draft-ietf-ccamp-eth-client-te-topo-yang: "A YANG Data Model for Ethernet TE Topology",

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-eth-client-te-topo-yang/.
[i.15] draft-ietf-opsawg-l2nm: " A Layer 2 VPN Network YANG Model ", Internet draft, Version 15,
work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/.
[i.16] draft-ietf-opsawg-sap: "A Network YANG Model for Service Attachment Points (SAPs)", Internet
draft, Version 04, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/.
ETSI
10 ETSI GS ZSM 008 V1.1.1 (2022-07)
[i.17] draft-ietf-opsawg-yang-vpn-service-pm: "A YANG Model for Network and VPN Service
Performance Monitoring", Internet draft, Version 07, work in progress.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ZSM 007 [2] and the following apply:
domain service: service that is managed by a management domain
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [2] and the following apply:
5G 5th Generation
API Application Programming Interface
BBF Broadband Forum
CCAMP Common Control and Measurement Plane
CCO Cloud Central Office
CCO DO Cloud Central Office Domain Orchestrator
CloudCO Cloud Central Office
CRUD Create, Read, Update, Delete
CRUD-N CRUD plus Notify
E2E End-to-End
E-UTRAN Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network
EPC Evolved Packet Core
ETSI European Telecommunications Standards Institute
FM Fault Management
gNMI gRPC Network Management Interface
gRPC Google Remote Procedure Call
IETF Internet Engineering Task Force
IFA InterFaces and Architecture
IOC Information Object Class
KPI Key Performance Indicator
L2 Layer 2
L2NM Layer 2 Network Model
L2SM Layer 2 Service Model
L2VPN Layer 2 VPN
L3 Layer 3
L3NM Layer 3 Network Model
L3SM Layer 3 Service Model
L3VPN Layer 3 VPN
LCM LifeCycle Management
LTE Long-Term Evolution
MD Management Domain
MDA Management Data Analytics
MDAS Management Data Analytics Service
MnF Management Function
MnS Management Service
MOI Managed Object Instance
ETSI
11 ETSI GS ZSM 008 V1.1.1 (2022-07)
n/a not applicable

NBI NorthBound Interface
NFV Network Functions Virtualisation
NFVO NFV Orchestrator
NRM Network Resource Model
NSC Network Slice Controller
NWDAF Network Data Analytics Function
ONF Open Networking Foundation
OTN Optical Transport Network
PM Performance Management
SDK Software Development Kit
SOL SOLutions
TAPI Transport Application Programming Interfaces
TEAS Traffic Engineering Architecture and Signaling
TMF TM Forum
TR Technical Report
UC Use Case
VNF Virtualised Network Function
VPN Virtual Private Network
WG Working group
XML eXtensible Markup Language
YANG Yet Another Next Generation
4 Overview of cross-domain E2E service lifecycle

management
The E2E service lifecycle is managed using different processes.
Roughly, the processes can be divided into:
• onboarding processes that ingest a service model that was created during an out-of-scope service design phase
into the ZSM framework;
• fulfilment processes that bring up a service instance based on an onboarded service model, configure the
service instance, activate it for use and finally terminate it;
• assurance processes that ensure a service is free of faults (service problem management) and meets its SLSs
(service quality management).
Onboarding and fulfilment processes are typically finite and are executed per request. Assurance processes typically
execute continuously once set up, ideally in closed loops. ETSI GS ZSM 009-1 [i.1] defines enablers for closed loops.
The present document focuses on the cross-domain aspects of these management processes and what management
services can be used to implement those processes.
Figure 4-1 illustrates the management processes during the E2E service lifecycle. Furthermore, the figure indicates as
example the groups of management services introduced in ETSI GS ZSM 002 [1] that can be used to implement the
processes. Apart from the processes that start the lifecycle of a service instance (service instantiation and assurance
set-up) and end it (service decommissioning and assurance tear-down), the figure depicts sets of processes with no
particular order. The processes are further detailed in clause 5.
ETSI
12 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 4-1: Management processes during the lifecycle of E2E services
Each management process during the E2E service lifecycle requires that the E2E service management domain
consumes management services from the management domains. For example, a fulfilment process might use
Orchestration services for service configuration, and Data Collection services to validate if the service quality
requirements are met initially. As another example, an assurance process might be realized as a closed loop using Data
Collection services, Data Analytics Services, Intelligence services together with Orchestration services to improve the
configuration in order to maintain the desired service quality.
A large set of these management services depends on the technology used in the underlying management domain. The
E2E service management domain needs to be able to consume the various management services from the management
domains via the endpoints that make up the northbound interface of the domain.
Figure 4-2 illustrates the set of technology domains considered in the present document. In deployments, there may be
additional technology domains. Clause 6 documents the northbound interfaces of management domains based on
different technologies.
In the present document, the NBIs of the E2E service management domain are defined in terms of ZSM management
services (see ETSI GS ZSM 002 [1] with extensions defined in Annex A of the present document). The technology
mapping of these NBIs is out of scope of the present document.
ETSI
13 ETSI GS ZSM 008 V1.1.1 (2022-07)
NOTE 1: NBIs depicted in figure 4-2 are neither mandatory nor exhaustive ones, but examples to be utilized.
NOTE 2: The cross-domain integration fabric is not depicted in figure 4-2 for simplicity.
Figure 4-2: Domain NBIs consumed during the management of the lifecycle of E2E services
Clause 7 documents gaps and commonalities between the different technology domains with respect to their northbound
interfaces.
ETSI
14 ETSI GS ZSM 008 V1.1.1 (2022-07)
5 Cross-domain E2E service lifecycle management

processes
5.1 Overview
Clause 5 introduces typical lifecycle management processes that the E2E service management domain performs to
manage E2E services throughout their lifespan and during which it interacts with the underlying management domains
that manage resources and domain services which are needed for the E2E service.
In deployments, processes may be combined or split.
For each process, a description, a process flow and a list of related management services are provided. The description
explains the overall purpose and task of the process. The procedure flow provides a graphical and a textual
representation of the individual steps of the process. For simplicity's sake, only requests are shown in the flows and
responses and acknowledgements are omitted. Furthermore, for the unsuccessful execution of the procedures, only error
conditions are defined, but no detailed error flows are specified. The list of related management services includes
management services that are produced or consumed by the E2E service management domain and therefore represent a
cross-domain integration point. Management services that are invoked internally by the management domain or E2E
service management domain (i.e. where producer and consumer are in the same domain) are not listed as these do not
require cross-domain integration or coordination.
In the following, the term "domain service" is used as shorthand for "a service that is managed by a management
domain".
The processes are split into three categories: Service onboarding, Service fulfilment and Service assurance, as depicted
in figure 4-1.
5.2 Service onboarding

5.2.1 Overview
The following sub-clauses introduce typical onboarding processes, i.e. processes that the E2E service management
domain performs to obtain E2E service models from service design (which is out of scope of the present document) and
that prepare the E2E service management domain and the management domains for the instantiation of such services.
5.2.2 Process: Service onboarding
5.2.2.1 Description
The "Service onboarding" process imports a new service model into the service catalogue of the E2E service
management domain, following the service design phase that is outside the scope of the present document. The E2E
service model is introduced in clause 6.6.5.2.3 of ETSI GS ZSM 002 [1].
Onboarding may optionally include the importing of a service template that allows to parameterize the service model
when a subsequent service instance creation is requested. A service template contains a customer-facing part and a
resource-facing part. The customer facing part, called the service offer descriptor, defines a set of parameters with their
allowed values or value ranges which can be used by the ZSM framework consumers to configure the characteristics of
the service they request to instantiate. The resource-facing part defines how to map the parameters in the service offer
descriptor to the realization of the service.
ETSI
15 ETSI GS ZSM 008 V1.1.1 (2022-07)
5.2.2.2 Procedure flow
Figure 5.2.2.2-1: Service onboarding
PRECONDITIONS:
• None.
The procedure, as illustrated in figure 5.2.2.2-1, consists of the following steps:
1. The ZSM framework consumer requests the creation of a service model and its import into the service
catalogue managed by the E2E service management domain by consuming the "Manage service models"
capability of the "Managed services catalogue management service".
2. Optionally, the ZSM framework consumer also requests the creation of a related service template and its
import into the service catalogue, consuming the same service.
ETSI
16 ETSI GS ZSM 008 V1.1.1 (2022-07)
3. The E2E service management domain validates the service model and, if it has been provided, the service
template.
4. The E2E service management domain determines the domain services that are necessary to provide the E2E
service.
5. To determine the missing domain service models (if any), the E2E service management domain queries from
the involved management domains the service catalogue entries of those domain service models that are
needed as components of the E2E service, using the "Manage service models" capability of the "Managed
services catalogue management service".
If domain service models are missing that are needed by the E2E service, steps 6 to 8 are performed:
6. Optionally, in special cases if the E2E service management domain is able to provide certain domain service
models to the management domains, it onboards them into the relevant management domains, using the
"Manage service models" capability of the "Managed services catalogue management service".
7. Optionally, if management domains support being informed about the need to provide certain domain services
that are currently missing, the E2E service management domain informs them using the "Request missing
service catalogue entry" capability of the "Managed services catalogue management service".
NOTE: This allows the E2E service management domain to express towards a management domain the need for
adding a particular domain service model to the domain's service catalogue and preparing the
management domain for instantiating the service.
8. If the E2E service management domain intends to receive notifications about catalogue changes, it subscribes
to these notifications towards the integration fabric, using the "Manage subscriptions" capability of the
"Management communication service".
In a loop over steps 9 to 12, the E2E service management domain waits until all needed domain service models are
available:
9. As first alternative, the E2E service management domain queries from the involved management domains the
service catalogue entries of those domain service models that were missing, to check whether they have
become available, using the "Manage service models" capability of the "Managed services catalogue
management service".
10. As second alternative, the management domains send notifications towards the integration fabric to inform
subscribers about changes in the service catalogue, using the "Provide notifications" capability of the
"Managed services catalogue management service".
11. Further as part of the second alternative, the integration fabric receives these notifications and forwards them
to the subscribers, including the E2E service management domain, using the using the "Receive data" and
"Provide data" capabilities of the "Managed services catalogue management service".
12. If some needed domain service models are still unavailable, the loop waits until one or more further changes in
the availability of service models occur. In order to continue the process, information that a particular domain
service is now available may either be polled or may be provided using the "Provide catalogue change
notifications" capability of the "Managed services catalogue management service". Alternatively, the loop may
fail at the first error or after a time-out. See "ERROR CONDITIONS" for more information.
13. If the E2E service management domain has created a subscription to catalogue change notifications in step 8, it
terminates that subscription, using the "Manage subscriptions" capability of the "Management communication
service".
14. The E2E service management domain stores the related data in the service catalogue in the Domain Data
Services or Cross-domain Data Services using the "Store data" capability of the "Data persistence service".
POSTCONDITIONS:
• The E2E service model has been onboarded.
• The individual management domains have available in their catalogues the service models of the component
services from which the E2E service is composed.
ETSI
17 ETSI GS ZSM 008 V1.1.1 (2022-07)
ERROR CONDITIONS:
• In case the validation of the service model / service template fails in step 3, the procedure terminates with an
error.
• In case not all needed domain service models are available and the loop cannot wait in step 11 for these
becoming available or the waiting has timed out, the procedure terminates with an error.
5.2.2.3 Related management services

The management services groups and the actual management services (see ETSI GS ZSM 002 [1] and Annex A of the
present document) involved in the procedure are summarized below.
The following management services are produced by the E2E service management domain in this procedure:
• E2E service orchestration: "Manage service models" capability of the "Managed services catalogue
management service".
The following management services produced by the management domains are used in this procedure:
• Domain orchestration: "Manage service models", "Provide catalogue change notifications" and "Request
missing service catalogue entry" capabilities of the "Managed services catalogue management service".
The following additional management services are used in this procedure:
• ZSM Integration Fabric: "Manage subscriptions", "Provide data" and "Receive data" capabilities of the
NOTE 1: It is up to each deployment to decide whether to use the cross-domain integration fabric or the domain
integration fabric or a combination of both.
• ZSM Data Services: "Store data" capability of the "Data persistence service".
NOTE 2: It is up to each deployment to decide whether to use the cross-domain data services or the domain data
services to store the information. Therefore, the use of the "Data persistence service" cross-domain is
optional.
5.3 Service fulfilment

5.3.1 Overview
The following clauses introduce typical fulfilment processes, i.e. processes that the E2E service management domain
performs to manage E2E service instances from their creation (also known as instantiation) until their termination (aka
decommissioning).
5.3.2 Process: Service instantiation
5.3.2.1 Description
This process creates an E2E service instance by requesting the orchestration of the domain service instances that make
up the E2E service from one or more management domains. This means that all the necessary service instances in the
management domains exist, and the necessary resources have been allocated by the management domains. It also
performs service feasibility check, service configuration and testing. If a service template was onboarded with the
service model (see clause 5.2.2), the service instantiation request from the ZSM framework consumer contains values to
assign to the parameters defined in the service template.
ETSI
18 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.3.2.2-1: Service instantiation
ETSI
19 ETSI GS ZSM 008 V1.1.1 (2022-07)
PRECONDITIONS:
• The E2E service model has been onboarded.
• The individual management domains need to have available in their catalogues the service models of the
component services from which the E2E service is composed.
1. The ZSM framework consumer requests the instantiation of an E2E service, using the "Manage service
lifecycle" capability of the "E2E service orchestration service".
2. The E2E service management domain retrieves the orchestration flow and service policies from the service
model stored in the service catalogue in the Domain Data Services or Cross-domain Data Services using the
"Query data" capability of the "Data persistence service".
3. Based on this information, the E2E service management domain determines the applicable policies and KPIs.
4. The E2E service management domain queries information from its inventory database locally, using the
"Query inventory information" capability of the "E2E services inventory information service" or the "Query
data" capability of the "Data persistence service".
5. The E2E service management domain queries information from its topology database locally, using the "Query
topology information" capability of the "E2E services topology information service" or the "Query data"
capability of the "Data persistence service".
6. The E2E service management domain requests an E2E service feasibility check by requesting the management
domains to perform feasibility checks of those of the individual domain services that require such a check and
that are components of the E2E service, using the "Check deployment feasibility" capability of the "Feasibility
Check Service" of the involved management domains.
7. As an alternative, it may use the optional "Check and reserve" capability of the "Feasibility Check Service" to
request a check with the reservation of the needed resources.
8. The E2E service management domain determines the feasibility of the requested E2E service based on the
information obtained in steps 3 to 7.
The following steps 9 to 16 are executed for all individual domain service instances from which the E2E service
instance is composed.
NOTE 1: It is up to the E2E service management domain to decide whether a domain service instance "owned" by
it is shared by more than one E2E service instance.
If the E2E service management domain decides that a new domain service instance needs to be created to support the
newly-created E2E service instance, steps 9 to 12 are performed.
9. The E2E service management domain requests the instantiation of a new domain service instance, using the
"Manage service lifecycle" capability of the "Domain Orchestration Service" of the involved management
domains.
10. The management domain handles the request and instantiates a new domain service instance. It allocates the
necessary resources (possibly taking previous reservations into account) and initially configures them ("Day 0
configuration").
11. If supported by the management domain, the E2E service management domain configures notifications about
inventory / topology changes related to the new domain service instance, using the "Configure notifications"
capability of the "Domain inventory information service" and "Domain topology information service".
12. If supported by the management domain, the E2E service management domain subscribes to notifications
about lifecycle changes related to the new domain service instance, using the "Manage subscription to lifecycle
changes" capability of the "Domain orchestration service".
If the E2E service management domain decides to share a pre-existing domain service instance between the newly-
created E2E service instance and another pre-existing E2E service instance, steps 13 and 14 are performed.
ETSI
20 ETSI GS ZSM 008 V1.1.1 (2022-07)
13. If there is the need to increase the capacity, the E2E service management domain requests the scaling of the
shared domain service instance, using the "Manage service lifecycle" capability of the "Domain Orchestration
Service" of the involved management domain.
14. The management domain handles the request and scales the domain service instance. If necessary, the
management domain allocates resources (possibly taking previous reservations into account) or scales them,
and initially configures them ("Day 0 configuration").
If the E2E service management domain decides to (re)configure the domain service instance, steps 15and 16 are
performed.
15. If necessary, the E2E service management domain requests the (re)configuration of the domain service
instance, using the "Manage service lifecycle" capability of the "Domain Orchestration Service" of the
involved management domain.
16. The management domain configures the domain service instance and related resources.
17. The E2E service management domain initially configures the E2E service instance ("Day 0 configuration").
The following two steps are typically executed to ensure the new service instance is functioning, but the ZSM
framework consumer can indicate in the instantiation request to omit the test, for example if speed of instantiation is
prioritized over reliability.
18. The E2E service management domain requests testing the resources of the domain service instances that are
involved in the E2E service instance by consuming the "Testing service" from those of the involved
management domains that expose this service. This includes managing the test models, initiating the tests and
obtaining the test results using the "Manage test specifications", "Test resources" and "Query tests" service
capabilities.
NOTE 2: It is optional for the management domains to expose the testing service.
19. The E2E service management domain tests the E2E service instance.
20. Subsequently, the E2E service management domain executes the procedure to set up the collection of
information specific to the newly created E2E service instance, as defined in clause 5.4.2.2.2, for parts of this
procedure that will not be executed as part of the service activation process (see clause 5.3.3).
21. At the end of the flow, the E2E service management domain triggers an internal event to update the E2E
service inventory / topology, as defined in clause 5.3.7.
POSTCONDITIONS:
• The E2E service has been instantiated.
ERROR CONDITIONS:
• Failing individual steps of this procedure will terminate the procedure with an error, except for the testing
steps.
• If a testing step fails, it is up to operator policy whether a test failure can be ignored and the procedure can still
finish successfully. In such a case, it might be up to a subsequent assurance procedure to repair or optimize the
E2E service instance.

• E2E service orchestration: "Manage service lifecycle" capability of the "E2E service orchestration service".
• Domain orchestration: "Check deployment feasibility" and "Check and reserve" (if supported) capabilities of
the "Feasibility check service".
ETSI
21 ETSI GS ZSM 008 V1.1.1 (2022-07)
• Domain orchestration: "Manage service lifecycle" capability of the "Domain orchestration service", including
functionality to instantiate, scale and configure the domain service.
• Domain orchestration: "Manage subscription to lifecycle changes" capability of the "Domain orchestration
service" (if exposed).
• Domain orchestration: "Configure notifications" capability of the "Domain inventory information service", if
supported.
• Domain orchestration: "Configure notifications" capability of the "Domain topology information service", if
supported.
• Domain orchestration: "Manage test specifications", "Test resources" and "Query tests" capabilities of the
"Testing service".
• ZSM Data Services: "Query data" capability of the "Data persistence service".
NOTE: It is up to each deployment to decide whether to use the cross-domain data services or the domain data
optional.
5.3.3 Process: Service activation
5.3.3.1 Description
This process activates an E2E service instance. After activation, the service instance is able to provide its services.
ETSI
22 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.3.3.2-1: Service activation
PRECONDITIONS:
• The E2E service instance has been instantiated and configured.
1. The ZSM framework consumer requests the activation of an E2E service instance, using the "Manage service
lifecycle" capability of the "E2E service orchestration service".
The following steps 2 to 7 are executed for all domain service instances that are consumed by the E2E service instance
being activated.
If the domain service instance is not yet activated, steps 2 and 3 are executed:
2. The E2E service management domain requests the orchestration (activation) of the individual domain service
instance consumed by the E2E service instance, using the "Manage service lifecycle" capability of the
"Domain Orchestration Service" of the involved management domain.
3. The management domain handles the activation request. First, the management domain activates the domain
service instance. Further, the management domain might apply changes such as scaling or reconfiguring of
resources to reflect that they are now consumed by the activated service instance.
ETSI
23 ETSI GS ZSM 008 V1.1.1 (2022-07)
If necessary, typically because the domain service instance is shared and adding another E2E service instance needs
more capacity of that domain service instance, steps 4 and 5 are executed:
4. The E2E service management domain requests to scale out / up the domain service instance, using the
domain.
5. The management domain handles the scaling request. First, the management domain scales the domain service
instance. Further, depending on the type of resource, the resources used by the domain service instance are
scaled or reconfigured to increase their capacity.
If necessary, steps 6 and 7 are executed:

6. The E2E service management domain requests the (re)configuration of the domain service instance, using the
domain.
7. Further in that case, the management domain (re)configures the domain service instance and the related
resources.
Further, the following steps are executed:

8. Subsequently, the E2E service management domain executes the procedure to set up the collection of
information specific to the E2E service instance to be activated, as defined in clause 5.4.2.2.2, for parts of this
procedure that were not executed as part of the service instantiation process (see clause 5.3.2).
9. The E2E service management domain activates the E2E service instance by updating its state to reflect that the
managed service instance is now active, i.e. available for consumption.
POSTCONDITIONS:
• The E2E service instance has been activated.
ERROR CONDITIONS:
• The procedure fails if any of the individual steps fails, unless the E2E service management domain is able to
recover from the process step failure / failures.

functionality to activate and configure the managed service.
5.3.4 Process: Service configuration
5.3.4.1 Description
This process modifies the configuration of an E2E service instance.
ETSI
24 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.3.4.2-1: Service configuration
PRECONDITIONS:
• The E2E service has been instantiated.
NOTE: Service configuration can be invoked for an activated as well as for a non-activated E2E service instance.
1. The ZSM framework consumer requests to modify the configuration of an E2E service instance, using the
"Manage service lifecycle" capability of the "E2E service orchestration service".
In a loop, steps 2 to 4 are executed the individual domain service instances from which the E2E service is composed
that are affected by the configuration change:
2. The E2E service management domain requests the domain orchestration service to change the configuration of
the domain service instance, using the "Manage service lifecycle" capability of the "Domain Orchestration
Service".
3. The management domain configures the necessary resources and / or domain service instances.
4. Optional: The E2E service management domain requests executing a test to validate the configuration and the
related domain service instance from the domain perspective, using the "Manage test specifications", "Test
resources" and "Query tests" capabilities of the "Testing service" in the management domain.
ETSI
25 ETSI GS ZSM 008 V1.1.1 (2022-07)
5. The E2E service management domain changes configuration parameters that are associated with the E2E
service instance.
6. Optional: The E2E service management domain executes a test to validate the configuration and related E2E
service from the E2E perspective.
POSTCONDITIONS:
• The configuration of the E2E service instance has been modified.
ERROR CONDITIONS:

functionality to configure the domain service.
• Domain orchestration: "Manage test specifications", "Test resources" and "Query tests" capabilities of the
"Testing service".
5.3.5 Process: Service deactivation
5.3.5.1 Description
This process deactivates an E2E service instance. After deactivation, the E2E service instance is no longer able to
provide its services.
ETSI
26 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.3.5.2-1: Service deactivation
PRECONDITIONS:
• The E2E service instance has been activated.
1. The ZSM framework consumer requests the deactivation of an E2E service instance, using the "Manage
service lifecycle" capability of the "E2E service orchestration service".
2. The E2E service management domain deactivates the E2E service instance by updating its state to reflect that
the managed service instance is now inactive, i.e. not available for consumption.
3. Subsequently, the E2E service management domain executes the procedure to tear down the collection of
information specific to the deactivated E2E service instance, as defined in clause 5.4.5.2.2, for parts of this
procedure that will not be executed as part of the service decommissioning process (see clause 5.3.6).
being deactivated.
ETSI
27 ETSI GS ZSM 008 V1.1.1 (2022-07)
If the domain service instance is active and not used by other active E2E service instances, steps 4 and 5 are executed:
4. The E2E service management domain requests the orchestration (deactivation) of the individual domain
service instance consumed by the E2E service instance being deactivated, using the "Manage service lifecycle"
capability of the "Domain Orchestration Service" of the involved management domains.
5. The management domain handles the deactivation request. First, the management domain deactivates the
domain service instance. Further, the management domain might apply changes, such as scaling or
reconfiguring of resources to reflect that they are no longer consumed by the deactivated service instance.
6. If necessary, typically because the domain service instance is shared and deactivating an E2E service instance
needs less capacity of that domain service instance, the E2E service management domain requests to scale in /
down the domain service instance, using the "Manage service lifecycle" capability of the "Domain
Orchestration Service" of the involved management domain.
7. Further in that case, the management domain handles the scaling request. First, the management domain scales
the domain service instance. Further, depending on the type of resource, the resources used by the domain
service instance are scaled or reconfigured to decrease their capacity.
9. Further in that case, the management domain (re)configures the domain service instance and the related
resources.
POSTCONDITIONS:
• The E2E service instance has been deactivated.
ERROR CONDITIONS:

functionality to deactivate, scale and configure the managed service.
5.3.6 Process: Service decommissioning
5.3.6.1 Description
This process decommissions an E2E service instance, i.e. it removes it and frees the resources and domain service
instances that were used by this E2E service instance.
ETSI
28 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.3.6.2-1: Service decommissioning
PRECONDITIONS:
• The E2E service instance has been instantiated and is not activated.
1. The ZSM framework consumer requests the decommissioning of an E2E service instance, using the "Manage
service lifecycle" capability of the "E2E service orchestration service".
2. Subsequently, the E2E service management domain executes the procedure to tear down the collection of
information specific to the E2E service instance being decommissioned, as defined in clause 5.4.5.2.2, for
parts of this procedure that were not executed as part of the service deactivation process (see clause 5.3.5).
being decommissioned.
ETSI
29 ETSI GS ZSM 008 V1.1.1 (2022-07)
If the domain service instance is no longer needed (i.e. it is only used by the decommissioned E2E service instance),
steps 3 to 6 are executed:
3. The E2E service management domain requests the orchestration (termination) of the domain service instance,
using the "Manage service lifecycle" capability of the "Domain Orchestration Service" of the involved
management domain.
4. The management domain handles the termination request. First, the management domain terminates the
domain service instance. Further, the management domain might apply changes such as scaling or
reconfiguring of resources to reflect that they are no longer consumed by the terminated domain service
instance.
5. If supported by the management domain, the E2E service management domain undoes the configuration of
notifications about inventory / topology changes related to the terminated domain service instance, using the
"Configure notifications" capability of the "Domain inventory information service" and "Domain topology
information service".
6. If supported by the management domain, the E2E service management domain terminates subscriptions to
notifications about lifecycle changes related to the terminated domain service instance, using the "Manage
subscriptions to lifecycle changes" capability of the "Domain orchestration service".
If the E2E service instance to be decommissioned shares the domain service instance with other E2E service instances,
steps 7 to 10 are executed:
7. If there is the need to decrease the capacity, the E2E service management domain requests the scaling of the
shared domain service instance, using the "Manage service lifecycle" capability of the "Domain Orchestration
Service" of the involved management domain.
8. Further in that case, the management domain handles the scaling request. First, the management domain scales
the domain service instance. Further, the management domain might apply changes such as scaling or
reconfiguring of resources to reflect the changes in capacity.
10. Further in that case, the management domain configures the domain service instance and the related resources.
11. The E2E service management domain terminates the E2E service instance.
POSTCONDITIONS:
• The E2E service instance has ceased to exist.
ERROR CONDITIONS:

functionality to terminate, scale and configure a domain service.
ETSI
30 ETSI GS ZSM 008 V1.1.1 (2022-07)
• Domain orchestration: "Manage subscription to lifecycle changes" capability of the "Domain orchestration
• Domain orchestration: "Configure notifications" capability of the "Domain inventory information service", if
supported.
• Domain orchestration: "Configure notifications" capability of the "Domain topology information service", if
supported.
5.3.7 Process: Update E2E inventory / topology
5.3.7.1 Description
This auxiliary process keeps up to date the information held by the E2E service management domain regarding the
inventories of domain service instances and resources (if exposed), as well as the related topologies in the management
domains.
Update E2E inventory / topology is an asynchronous process triggered by internal or external events which indicate
potential modifications to the inventory and / or topology information held by the E2E service management domain.
While the E2E service management domain is aware of internal events, it needs to receive notification messages from
the management domains to be informed about external events.
When an event occurs, the E2E service management domain discovers the related changes and reconciles these in its
inventory. This way, the consolidated inventory of the E2E service management domain provides it with a view of the
underlying management domains, and its own service instances, which it can for example use in closed loops or as part
of feasibility checks.
Internal events that can be assumed to indicate an inventory or topology change include but are not limited to:
• The E2E service management domain has requested orchestration actions from a management domain which
have likely affected topology and / or inventory.
• The E2E service management domain intends to instantiate a service and therefore needs to check whether the
needed component service instances are available in the underlying management domains.
• A timer for a time-based regular update check has expired.
External events include changes of the inventory or topology of a management domain, as well as events related to the
lifecycle management of domain service instances or externally visible resources of the domain. Notification messages
related to such external events are supported by certain management domains.
NOTE: Notifications regarding inventory / topology changes are supported by some types of management
domains (such as 3GPP- NFV- or IETF-based management domains). As these capabilities are not
modelled in ETSI GS ZSM 002 [1], Annex B provides the definitions of these capabilities as an update of
the related management services defined in [1].
ETSI
31 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.3.7.2-1: Inventory / topology update
ETSI
32 ETSI GS ZSM 008 V1.1.1 (2022-07)
PRECONDITIONS:
• An internal or external event has occurred that indicates a possible change to the inventory or topology.
An internal event triggers the following discovery steps:
1. The E2E service management domain queries inventory information from management domains that may be
affected by the change indicated by the internal event, using the "Query inventory of available resources"
capability of the "Domain inventory information service". Such query can be selective based on information
about the event, if applicable.
2. The E2E service management domain queries topology information from management domains that may be
affected by the change indicated by the internal event, using the "Query topology information" capability of
the "Domain topology information service". Such query can be selective based on information about the event,
if applicable.
An external event triggers the execution of the following discovery steps:
3. The E2E service management domain receives notifications related to changes of inventory / topology from
the affected management domains directly, using the "Provide notifications about lifecycle changes" capability
of the "Domain orchestration service" or the "Provide notifications about lifecycle changes" capability of
services derived from the "Generic resource lifecycle management service", such as the "Virtualised resource
lifecycle management service" (if exposed). Alternatively (not depicted), the E2E service management domain
receives these notifications indirectly via the integration fabric. Such notifications may merely inform that a
change has occurred or may include detailed information about the modified entities.
4. If the notification has merely informed that an inventory change has occurred, the E2E service management
domain obtains the changed inventory information from the management domain that has originated the
notification, using the "Query inventory of available resources" capability of the "Domain inventory
5. Further, if the notification has merely informed that a topology change has occurred, the E2E service
management domain obtains the changed topology information from the management domain that has
originated the notification, using the "Query topology information" capability of the "Domain topology
Subsequently, the following steps are executed for both internal and external events:
6. The E2E service management domain queries information from its inventory database using the "Query
inventory of available services" capability of the "E2E services inventory information service" or the "Query
data" capability of the "Data persistence service".
7. The E2E service management domain queries information from its topology database using the "Query
topology information" capability of the "E2E services topology information service" or the "Query data"
capability of the "Data persistence service".
8. The E2E service management domain processes the inventory / topology data it has received from the
management domains in the previous steps and reconciles its own inventory / topology data with that received
data.
If the reconciliation process has detected changes to the inventory / topology data managed by the E2E service
management domain, the following steps 9 to 14 are executed:
If the E2E service management domain updates its inventory database using a management service, the following steps
are executed:
9. The E2E service management domain invokes its management service for managing inventory information.
10. That service performs the update to the information stored in the inventory database managed by the E2E
service management domain, using the "Store data" capability of the "Data persistence service".
ETSI
33 ETSI GS ZSM 008 V1.1.1 (2022-07)
Alternatively, if the E2E service management domain updates its inventory database directly, the following step is
executed:
11. The E2E service management domain directly updates the information stored in the inventory database
managed by the E2E service management domain, using the "Store data" capability of the "Data persistence
service".
If the E2E service management domain updates its topology database using a management service, the following steps
are executed:
12. The E2E service management domain invokes its management service for managing topology information.
13. That service performs the update to the information stored in the topology database managed by the E2E
service management domain, using the "Store data" capability of the "Data persistence service".
Alternatively, if the E2E service management domain updates its topology database directly, the following step is
executed:
14. The E2E service management domain directly updates the information stored in the topology database
managed by the E2E service management domain, using the "Store data" capability of the "Data persistence
service".
POSTCONDITIONS:
• The inventory and topology information held by the E2E service management domain is in sync with the
information available in the underlying management domains.
ERROR CONDITIONS:

• None.
• Domain orchestration: "Query inventory of available resources" capability of "Domain inventory information
• Domain orchestration: "Query topology information" capability of "Domain topology information service" (if
exposed).
• Domain orchestration: "Provide notifications about lifecycle changes" capability of the "Domain orchestration
service".
• Domain control: "Provide notifications about lifecycle changes" capability of services derived from the
"Generic resource lifecycle management service", such as the "Virtualised resource lifecycle management
• ZSM Data Services: "Store data" and "Query data" capability of the "Data persistence service"
NOTE: It is up to each deployment to decide whether to use the cross-domain data services or the domain data
optional.
ETSI
34 ETSI GS ZSM 008 V1.1.1 (2022-07)
5.4 Service assurance

5.4.1 Overview
The following clauses introduce typical assurance processes, including those that the E2E service management domain
performs to manage service quality and mitigate service problems of E2E service instances during their lifespan.
Service assurance processes make heavy use of notifications for which the ZSM framework reference architecture
(ETSI GS ZSM 002 [1]) foresees two ways of delivery:
1) direct delivery from service producer to service consumer; and
2) delivery via the management communication service in the integration fabric.
Some service producers allow service consumers to subscribe to notifications and receive the subscribed notifications
directly from them, whereas other service producers only support pushing notifications into a channel on the integration
fabric to which the service consumer needs to subscribe in order to obtain the notifications. When setting up the
collection of information (see clauses 5.4.2.2.1, 5.4.2.2.2 and 5.4.3.2.2) and during notification delivery itself,
deployments need to consider these different choices accordingly, depending on the subscription and notification
delivery mechanisms supported by the service producers. Delivery via the integration fabric is the recommended
variant, and the only possible variant in case of producer-initiated set-up of information collection (see clause 5.4.2.2.1).
5.4.2 Process: Service assurance set-up
5.4.2.1 Description
The processes defined in this clause fulfil preconditions to assure an E2E service. The preparation consists of two
separate auxiliary processes:
1) Producer-initiated: Based on management domain policy, this auxiliary process prepares to collect and provide
information related to domain service instances, initiated by the producing management domains. The
production of such information is based entirely on the fact that a service instance is provided by a
management domain, independent from whether or not this service instance is consumed by any E2E service
instance.
2) Consumer-initiated: Based on knowledge about the E2E service as available in the E2E service model, this
auxiliary process prepares to collect and provide "E2E-service specific" information related to domain service
instances provided by the management domains. Such "E2E service specific" information is necessary to
assure a particular E2E service instance.
ETSI
35 ETSI GS ZSM 008 V1.1.1 (2022-07)
5.4.2.2 Procedure flows
5.4.2.2.1 Producer-initiated set-up of information collection related to domain service

instance
Figure 5.4.2.2.1-1: Producer-initiated set-up of information collection

related to domain service instance
Using the procedure illustrated in figure 5.4.2.2.1-1, the producer management domain sets up measurements for a
newly instantiated or activated produced domain service instance and (optionally) the externally visible resources
associated with this instance managed by the management domain. In the steps below, the shorthand "produced service
instance / associated resources" is used for these. Decision about the information collected can be made inside the
management domain and is typically controlled by policy. This procedure is triggered either during service instantiation
or service activation, or during both of these processes if it is intended to split the procedure into two parts that
complement each other.
PRECONDITIONS:
• New domain service is instantiated or domain service instance is activated.
ETSI
36 ETSI GS ZSM 008 V1.1.1 (2022-07)
The procedure, as illustrated in figure 5.4.2.2.1-1, consists of the following steps:
1. The management domain creates channels in the integration fabric through which the performance-related
information can later be provided, using the "Manage channels" capability of the "Management
communication service".
2. The management domain configures the collection of streaming measurements related to the produced service
instance / associated resources, using the "Configure measurements" capability of the "Performance
measurements streaming service".
3. The management domain configures the collection of batch measurements related to the produced service
instance / associated resources, using the "Configure batch measurements" capability of the "Performance
measurements collection service".
4. The management domain configures the monitoring of the performance and creation of performance events
(threshold crossings) related to the produced service instance / associated resources, using the "Configure
monitoring" capability of the "Performance events service".
5. The management domain creates channels in the integration fabric through which the problem-related
information can later be provided, using the "Manage channels" capability of the "Management
6. The management domain configures the monitoring of faults related to the produced service instance /
associated resources, using the "Configure monitoring" capability of the "Fault events service".
7. The management domain configures the monitoring of security events related to the produced service instance
/ associated resources, using the "Configure monitoring" capability of the "Security events service".
8. The management domain configures the health issue reporting service related to the produced service instance,
using the "Configure service" capability of the "Health issue reporting service".
NOTE: Any combination of steps 2, 3, 4 and 6, 7, 8 may be executed in any order.
POSTCONDITIONS:
• Notifications related to issues and performance, as well as streaming and batch measurements that the producing
management domain intends to expose for the domain service instance, are produced.
ERROR CONDITIONS:
• The procedure fails if any of the individual steps fails, unless the management domain is able to recover from
the process step failure / failures.
ETSI
37 ETSI GS ZSM 008 V1.1.1 (2022-07)
5.4.2.2.2 Consumer-initiated set-up of collecting "E2E-service specific" information related

to domain service instances
Figure 5.4.2.2.2-1: Consumer-initiated set-up of information collection

related to domain service instances
ETSI
38 ETSI GS ZSM 008 V1.1.1 (2022-07)
Using the procedure as illustrated in figure 5.4.2.2.2-1, based on knowledge of the composition of the E2E service, the
E2E service management domain as consumer sets up the collection of information from the MDs related to domain
service instances consumed by the particular E2E service instance and (optionally) externally visible resources
associated with these domain service instances. In the steps below, the shorthand "consumed domain service instances /
associated resources" is used for these. As this requires cross-domain knowledge, the decision is made by the E2E
service management domain, typically controlled by policy, e.g. defined in the E2E service model. This procedure is
triggered either during E2E service instantiation or E2E service activation, or during both of these processes if it is
intended to split the procedure into two parts that complement each other.
PRECONDITIONS:
• New E2E service is instantiated or E2E service instance is activated.
1. If the E2E service management domain intends to obtain performance-related information via the integration
fabric (default assumption), it creates channels in the integration fabric through which the information can later
be provided, using the "Manage channels" capability of the "Management communication service".
NOTE 1: Alternatively, this step can be omitted which means that in the subsequent steps 2 to 4, the management
domains need to be configured to provide the notifications directly to the E2E service management
domain, bypassing the integration fabric.
2. The E2E service management domain configures in the management domains the collection of streaming
measurements related consumed domain service instances / associated resources, using the "Configure
measurements" capability of the "Performance measurements streaming service".
3. The E2E service management domain configures the collection of batch measurements related to consumed
domain service instances / associated resources, using the "Configure batch measurements" capability of the
"Performance measurements collection service".
4. The E2E service management domain configures the monitoring of the performance and creation of
performance events (threshold crossings) related to consumed domain service instances / associated resources,
using the "Configure monitoring" capability of the "Performance events service".
5. The E2E service management domain configures the collection of performance measurements related to the
E2E service instance.
6. If the E2E service management domain intends to obtain problem-related information via the integration fabric
(default assumption), it creates channels in the integration fabric through which the information can later be
provided, using the "Manage channels" capability of the "Management communication service".
domains need to be configured to provide the information directly to the E2E service management
7. The E2E service management domain configures in the management domains the monitoring of faults related
to the consumed domain service instances / associated resources, using the "Configure monitoring" capability
of the "Fault events service".
8. The E2E service management domain configures the monitoring of security events related to the consumed
domain service instances / associated resources, using the "Configure monitoring" capability of the "Security
events service".
9. If the health issue reporting service is exposed by the management domain, the E2E service management
domain configures this service related to the consumed domain service instances, using the "Configure
service" capability of the "Health issue reporting service".
10. The E2E service management domain configures its own health issue reporting service related to the E2E
service instance, using the "Configure service" capability of the "Health issue reporting service".
NOTE 3: Any combination of steps 2, 3, 4 and 7, 8, 9 may be executed in any order.
ETSI
39 ETSI GS ZSM 008 V1.1.1 (2022-07)
11. The ZSM framework consumer discovers the available channels and subscribes to selected channels which
carry service quality violation notifications and health issue notifications using the "Manage channels" and
"Manage subscriptions" capabilities of the "Management communication service" in the integration fabric.
12. If the E2E service management domain intends to obtain performance-related or problem-related information
via the integration fabric (default assumption), it discovers the available channels and subscribes to selected
channels which carry performance event notifications, streaming performance measurements, notifications
related to the availability of batches of performance measurements or notifications related to fault and security
events, using the "Manage channels" and "Manage subscriptions" capabilities of the "Management
communication service" in the integration fabric.
NOTE 4: Steps 11 and 12 may be executed in any order.
POSTCONDITIONS:
• Notifications related to issues and performance, as well as streaming and batch measurements that the E2E
service management has requested from the management domains to assure an E2E service instance, are
produced by the management domains.
ERROR CONDITIONS:

• None.
• Domain data collection: "Configure monitoring" capability of the "Performance events service".
• Domain data collection: "Configure measurements" capability of the "Performance measurements streaming
service".
• Domain data collection: "Configure batch measurements" capability of the "Performance measurements
collection service".
• Domain data collection: "Configure monitoring" capability of the "Fault events service".
• Domain data collection: "Configure monitoring" capability of the "Security events service".
• Domain intelligence: "Configure service" capability of the "Health issue reporting service" (if exposed).
• ZSM integration fabric: "Manage channels" and "Manage subscriptions" capabilities of the "Management
NOTE: It is up to each deployment to decide whether to use the cross-domain integration fabric or the domain
5.4.3 Process: Service quality management
5.4.3.1 Description
Typically, this process runs in a loop and assures that the E2E service instance meets its service level specification. If
the E2E service management domain cannot fix a detected service quality issue or if intervention is needed, it escalates
the problem by reporting a service quality violation to the ZSM framework consumer.
ETSI
40 ETSI GS ZSM 008 V1.1.1 (2022-07)
This process is also able to perform cross-domain investigation of quality issues. As part of the procedure, the necessary
analytics methods to be performed by the domains, or additional performance information to be collected by the
domains, are determined and discovered by the E2E service management domain. This process allows to perform E2E
service analytics based on analytics results generated by domain analytics services in multiple domains or based on
additional performance information collected by multiple domains, as triggered by the E2E service management domain
5.4.3.2.1 Main service quality management flow

This procedure represents the main E2E service quality management process.
ETSI
41 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.4.3.2.1-1: Managing service quality
ETSI
42 ETSI GS ZSM 008 V1.1.1 (2022-07)
PRECONDITIONS:
• The "Service assurance set-up" procedures defined in clause 5.4.2.2 have been executed.
The procedure, as illustrated in figure 5.4.3.2.1-1, consists of the following steps.
The following groups of steps 1 and 2; steps 3 and 4; and steps 5 to 7 are executed in any order, using the "Management
communication service" in the integration fabric unless otherwise specified:
1. Via the "Provide notifications" capability of the "Performance events service", the management domains
provide notifications on performance events (such as threshold crossings) to the integration fabric, using the
"Receive data" capability of the "Management communication service".
2. The integration fabric forwards the notifications on performance events to the management functions in the
E2E service management domain that have subscribed to the related channels, using the "Provide data"
capability of the "Management communication service".
3. Via the "Provide streaming measurements" capability of the "Performance measurements streaming service",
the management domains provide streaming measurements to the integration fabric, using the "Receive data"
4. The integration fabric forwards the streaming measurements to the management functions in the E2E service
management domain that have subscribed to the related channels, using the "Provide data" capability of the
5. Via the "Provide batch availability notifications" capability of the "Performance measurements collection
service", the management domains provide notifications related to the availability of batches of performance
measurements to the integration fabric, using the "Receive data" capability of the "Management
6. The integration fabric forwards the notifications related to the availability of batches of performance
measurements to the management functions in the E2E service management domain that have subscribed to
the related channels, using the "Provide data" capability of the "Management communication service".
7. The E2E service management domain obtains the collected batches of measurements from the management
domain using the "Get batch measurements" capability of the "Performance measurements collection service".
8. Based on the performance information received, the E2E service management domain determines whether
there is the need for additional analytics to be performed by the MDs.
If additional analytics is needed, the following steps are performed:
9. The E2E service management domain discovers the analytics services that are exposed by the management
domains, using the "Query service list" and "Get service info" capabilities of the "Management services
discovery service" in the cross-domain integration fabric.
In a loop over all needed analytics services, the following steps are performed:
10. The E2E service management domain configures the management domains to perform such analytics, using
the "Configure analytics" capability of the needed analytics services.
11. Further in this case, the E2E service management domain requests the analytics results from the management
domains, using the "Request analysis result" capability of the needed analytics services.
The following further steps are performed:
12. The E2E service management domain determines the need for additional performance data to be collected
from the MDs.
13. If additional performance data are needed, the E2E service management domain performs the "Collect
additional domain performance data" auxiliary process as defined in clause 5.4.3.2.
14. Optionally and if exposed by the management domains, the E2E service management domain queries the logs
of the management domain, using the "Query logs" capability of the "Log collection service" in the
management domains.
ETSI
43 ETSI GS ZSM 008 V1.1.1 (2022-07)
15. Optionally, if E2E inventory information is needed by the following analytics steps, the E2E service
management domain queries the E2E inventory, using the "Query inventory of available services" capability of
the "E2E services inventory information service" or the "Query data" capability of the "Data persistence
service".
16. Optionally, if E2E topology information is needed by the following analytics steps, the E2E service
management domain queries the E2E topology database, using the "Query topology information" capability of
the "E2E services topology information service" or the "Query data" capability of the "Data persistence
service".
The received performance information is analysed in the following steps by a set of one or more performance analysis
services that depend on the E2E service management domain, such as the following:
17. The performance information is analysed using the "Performance analysis service".
18. The performance information is analysed by the "Condition detection service".
If a performance issue is detected, the following steps are executed:
19. Local processing in the E2E service management domain makes decisions regarding how the performance
issue can be mitigated.
20. For the affected management domains, the execution of orchestration workflows or the modification of the
configuration of domain service instances is triggered using the "Execute workflow" or "Manage service
lifecycle" capabilities of the "Domain orchestration service" to attempt resolving the performance issue.
21. If necessary, the affected management domains modify the configuration of resources, using the "Manage
resource configuration" capability of the "Resource configuration management service" locally.
22. If necessary, the affected management domains manage the resource lifecycle (such as scaling, instantiating or
terminating resources) using the "Manage resource lifecycle" capability of services derived from the "Generic
Resource lifecycle management service" locally.
23. The E2E service management domain triggers an internal event to update the E2E service inventory /
topology, as defined in clause 5.3.7.
If the performance issue cannot be fixed, the problem is escalated to the ZSM framework consumers by the following
steps:
24. Via the "Provide violation notifications" capability of the "E2E service quality management service", the E2E
service management domain provides a service quality violation notification to the integration fabric, using the
25. The integration fabric forwards the notification to the ZSM framework consumers that have subscribed to the
related channels, using the "Provide data" capability of the "Management communication service".
POSTCONDITIONS:
• The performance issue was fixed or escalated.
ERROR CONDITIONS:
• The procedure fails and the issue is escalated to the ZSM framework consumers if any of the individual steps
fails, unless the E2E service management domain is able to recover from the process step failure / failures.
5.4.3.2.2 Auxiliary process to collect additional domain performance data

This auxiliary process allows the E2E service management domain to collect on demand additional performance data
from the management domains to allow E2E service analytics processes to further analyse a service quality issue. It is
triggered as part of the main service quality management flow (see clause 5.4.3.2.1) and has been separated from that
flow for the purpose of modularization.
ETSI
44 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.4.3.2.2-1: Collecting additional domain performance data
ETSI
45 ETSI GS ZSM 008 V1.1.1 (2022-07)
PRECONDITIONS:
• None.
The procedure, as illustrated in figure 5.4.3.2.2-1, consists of the following steps.
fabric (default assumption), it creates channels in the integration fabric through which the information can later
be provided, using the "Manage channels" capability of the "Management communication service".
domains need to be configured to provide the notifications directly to the E2E service management
2. The E2E service management domain discovers from the integration fabric the data collection services that are
exposed by the management domains, using the "Query service list" and "Get service info" capabilities of the
"Management services discovery service" in the integration fabric.
3. If streaming measurements are needed, the E2E service management domain configures in the management
domains the collection of streaming measurements related to the consumed domain service instances /
associated resources, using the "Configure measurements" capability of the "Performance measurements
streaming service".
4. If batch measurements are needed, the E2E service management domain configures the collection of batch
measurements related to the consumed domain service instances / associated resources, using the "Configure
batch measurements" capability of the "Performance measurements collection service".
5. If performance events are needed, the E2E service management domain configures the monitoring of the
performance and creation of performance events (threshold crossings) related to the consumed domain service
instances / associated resources, using the "Configure monitoring" capability of the "Performance events
service".
NOTE 2: Any combination of steps 3, 4 and 5 may be executed in any order.
fabric (default assumption), it discovers the available channels and subscribes to selected channels which carry
performance event notifications, streaming performance measurements, notifications related to the availability
of batches of performance measurements or notifications related to fault and security events, using the
"Manage channels" and "Manage subscriptions" capabilities of the "Management communication service" in
the integration fabric.
Any combination of the following groups of steps 7 and 8; steps 9 and 10; and steps 11 to 13 is executed in any order,
using the "Management communication service" in the integration fabric unless otherwise specified:
7. Via the "Provide notifications" capability of the "Performance events service", the management domains
provide notifications on performance events (such as threshold crossings) to the integration fabric, using the
8. The integration fabric forwards the notifications on performance events to the management functions in the
E2E service management domain that have subscribed to the related channels, using the "Provide data"
9. Via the "Provide streaming measurements" capability of the "Performance measurements streaming service",
the management domains provide streaming measurements to the integration fabric, using the "Receive data"
10. The integration fabric forwards the streaming measurements to the management functions in the E2E service
management domain that have subscribed to the related channels, using the "Provide data" capability of the
ETSI
46 ETSI GS ZSM 008 V1.1.1 (2022-07)
11. Via the "Provide batch availability notifications" capability of the "Performance measurements collection
service", the management domains provide notifications related to the availability of batches of performance
measurements to the integration fabric, using the "Receive data" capability of the "Management
12. The integration fabric forwards the notifications related to the availability of batches of performance
measurements to the management functions in the E2E service management domain that have subscribed to
the related channels, using the "Provide data" capability of the "Management communication service".
13. The E2E service management domain obtains the collected batches of measurements from the management
domain using the "Get batch measurements" capability of the "Performance measurements collection service".
The following steps are executed to stop the collection of performance-related information:
14. If the E2E service management domain has executed step 3 to configure in the MDs the collection of
streaming measurements related to consumed domain service instances / associated resources, it reverts this
configuration using the "Configure measurements" capability of the "Performance measurements streaming
service".
15. If the E2E service management domain has executed step 4 to configure in the MDs the collection of batch
measurements related to consumed domain service instances / associated resources, it reverts this
configuration using the "Configure batch measurements" capability of the "Performance measurements
16. If the E2E service management domain has executed step 5 to configure in the MDs the monitoring of
performance events (threshold crossings) related to consumed domain service instances / associated resources,
it reverts this configuration using the "Configure monitoring" capability of the "Performance events service".
17. If the E2E service management domain has executed step 6 to subscribe to channels related to the collection of
information about consumed domain service instances / associated resources, it unsubscribes with the
integration fabric from those channels using the "Manage subscriptions" capability of the "Management
18. If the E2E service management domain has executed step 1 to create channels in the integration fabric related
to the assurance of the E2E service instance, it deletes these channels using the "Manage channels" capability
of the "Management communication service".
POSTCONDITIONS:
• Additional performance-related information is available to the E2E service management domain.
ERROR CONDITIONS:

• E2E service analytics: "Provide violation notifications" capability of the "E2E service quality management
service".
• Domain data collection: "Configure monitoring" and "Provide notifications" capabilities of the "Performance
events service".
• Domain data collection: "Configure measurements" and "Provide streaming measurements" capabilities of the
"Performance measurements streaming service".
ETSI
47 ETSI GS ZSM 008 V1.1.1 (2022-07)
• Domain data collection: "Configure batch measurements", "Provide batch availability notifications" and "Get
batch measurements" capabilities of the "Performance measurements collection service".
• Domain data collection: "Query logs" capability of the "Log collection service" (if exposed).
• Domain analytics: "Configure analytics" and "Request analysis result" capabilities of specific domain analytics
services derived from the "Generic analytics service".
• Domain orchestration: "Execute workflow" and "Manage service lifecycle (configure)" capabilities of the
"Domain orchestration service".
• ZSM integration fabric: "Manage channels", "Manage subscriptions", "Receive Data" and "Provide data"
capabilities of the "Management communication service".
• ZSM integration fabric: "Query service list" and "Get service info" capabilities of the "Management services
discovery service".
NOTE 1: It is up to each deployment to decide whether to use the cross-domain integration fabric or the domain
• ZSM Data Services: "Query data" capability of the "Data persistence service".
NOTE 2: It is up to each deployment to decide whether to use the cross-domain data services or the domain data
optional.
5.4.4 Process: Service problem management
5.4.4.1 Description
Typically, this process runs in a loop and assures that the E2E service instance is free of faults and issues. Sometimes,
the fixing of detected issues is also termed "service healing". If the E2E service management domain cannot fix a
detected issue or if intervention is needed, it escalates the problem by reporting an E2E service health issue.
This process is also able to perform cross-domain investigation of problems. As part of the procedure, the necessary
analytics methods to be performed by the domains are determined and discovered by the E2E service management
domain. This process allows performing E2E service analytics based on analytics results generated by domain analytics
services in multiple domains as triggered by the E2E service management domain.
ETSI
48 ETSI GS ZSM 008 V1.1.1 (2022-07)
Figure 5.4.4.2-1: Managing service problems
ETSI
49 ETSI GS ZSM 008 V1.1.1 (2022-07)
PRECONDITIONS:
• The "Service assurance set-up " auxiliary processes as defined in clause 5.4.2.2 have been executed.
If a fault or security problem occurs in a management domain related to a domain service instance, the following steps
are executed:
1. In case reporting the event outside the management domain is configured, an event notification is provided by
the management domain via the "Provide notification" capability of the "Fault events service" or "Security
events service" to the integration fabric, using the "Receive data" capability of the "Management
2. Further in this case, the integration fabric forwards the notification in a channel to the E2E service
management domain using the "Provide data" capability of the "Management communication service",
assuming the E2E service management domain has a subscription for that channel.
3. The management domain tries to fix the fault locally, e.g. using a closed loop (see ETSI GS ZSM 009-1 [i.1]).
4. If the issue cannot be fixed, the management domain tracks the problem as a health issue. If the "Health issue
reporting service" is exposed, the management domain provides, via the "Provide health issue notification"
capability of the "Health issue reporting service", a health issue notification to the integration fabric, using the
5. Further in this case, the integration fabric forwards the notification in a channel to the E2E service
management domain, using the "Provide data" capability of the "Management communication service",
assuming the E2E service management domain has subscribed for that channel.
If a service quality violation in the E2E service management domain has been detected (see clause 5.4.3) or a health
issue has been notified related to a domain service instance that is used by the E2E service, the following steps are
executed:
6. Based on the information received from the management domains, the E2E service management domain
determines whether there is the need for additional analytics to be performed by the MDs.
If additional analytics is needed, the following steps are performed:
7. The E2E service management domain discovers the analytics services that are exposed by the management
domains, using the "Query service list" and "Get service info" capabilities of the "Management services
discovery service" in the cross-domain integration fabric. Services used can include the "Reactive incident
analysis service" if exposed.
In a loop over all needed analytics services, the following is performed:
8. The E2E service management domain configures the management domains to perform such analytics, using
the "Configure analytics" capability of the needed analytics services.
9. Further in this case, the E2E service management domain requests the analytics results from the management
domains, using the "Request analysis result" capability of the needed analytics services.
The following further steps are performed:
10. Optionally and if exposed by the management domains, the E2E service management domain queries the logs
of the management domain, using the "Query logs" capability of the "Log collection service" in the
management domains.
11. Optionally, if E2E inventory information is needed by the following analytics steps, the E2E service
management domain queries the E2E inventory, using the "Query inventory of available services" capability of
the "E2E services inventory information service" or the "Query data" capability of the "Data persistence
service".
12. Optionally, if E2E topology information is needed by the following analytics steps, the E2E service
management domain queries the E2E topology database, using the "Query topology information" capability of
the "E2E services topology information service" or the "Query data" capability of the "Data persistence
service".
ETSI
50 ETSI GS ZSM 008 V1.1.1 (2022-07)
13. Optionally, for selected management domains involved in providing the E2E service, the E2E management
domain queries detailed information regarding health issues, using the "Query health issues" capability of the
"Health issue reporting service".
14. The E2E service management domain performs analytics locally, using services that have been derived from
the "Generic analytics service", optionally including the "Root cause analysis service" and "Security analytics
service".
If the analytics result indicates that there is a service problem to be fixed, the following steps are executed:
15. Local processing in the E2E service management domain makes decisions regarding how the issue can be
mitigated.
16. For the affected management domains, the execution of orchestration workflows or the modification of the
configuration of domain service instances is triggered using the "Execute workflow" or "Manage service
lifecycle" capabilities of the "Domain orchestration service" to attempt resolving the issue.
17. If necessary, the affected management domains modify the configuration of resources using the "Manage
resource configuration" capability of the "Resource configuration management service" locally.
18. If necessary, the affected management domains manage the resource lifecycle (such as scaling, instantiating or
terminating resources) using the "Manage resource lifecycle" capability of services derived from the "Generic
Resource lifecycle management service" locally.
19. After performing changes, the E2E service management domain triggers an internal event to update the E2E
service inventory, as defined in clause 5.3.7.
If the service problem cannot be fixed, it is tracked as a health issue and escalated to the ZSM framework consumers by
the following steps:
20. Via the "Provide violation notifications" capability of the "E2E Health issue reporting service", the E2E
service management provides a health issue notification to the integration fabric, using the "Receive data"
21. The integration fabric forwards the notification to the ZSM framework consumers that have subscribed to the
related channels, using the "Provide data" capability of the "Management communication service".
POSTCONDITIONS:
• The service issue was fixed or escalated.
ERROR CONDITIONS:
• The procedure fails and the issue is escalated to the ZSM framework consumers if any of the individual steps
fails, unless the E2E service management domain is able to recover from the process step failure / failures.

• E2E service intelligence: "Provide health issue notifications capability of the "E2E service health issue
reporting service".
• Domain data collection: "Provide notifications" capability of "Fault events service" and "Security events
service".
• Domain data collection: "Query logs" capability of the "Log collection service" (if exposed).
ETSI
51 ETSI GS ZSM 008 V1.1.1 (2022-07)
• Domain analytics: "Configure analytics" and "Request analysis result" capabilities of specific domain analytics
services derived from the "Generic analytics service", optionally including the Reactive incident analysis
service (if exposed).
• Domain intelligence: "Provide health issue notifications" of the "Health issue reporting service" (if exposed).
• Domain orchestration: "Execute workflow" and "Manage service lifecycle (configure)" capabilities of the
"Domain orchestration service".
• ZSM integration fabric: "Provide data" capability of the "Management communication service".
• ZSM integration fabric: "Query service list" and "Get service info" capabilities of the "Management services
discovery service".
integration fabric or a mix of both.
5.4.5 Process: Service assurance tear-down
5.4.5.1 Description
In analogy to the two different assurance set-up auxiliary processes defined clause 5.4.2, this clause defines auxiliary
processes to tear down the collection of information set up by those processes. The tear-down consists of two separate
processes:
1) Producer-initiated: This auxiliary process tears down the collection and provisioning of information related to
domain service instances that cease to exist or are deactivated, initiated by the management domains that are
producing these services. The tear-down is based entirely on the fact that a service instance ceases to be
provided by a management domain due to it being decommissioned or deactivated. The procedure undoes the
steps that were executed during "producer-initiated set- up of information collection related to domain service
instances" (see clause 5.4.2.2.1).
2) Consumer-initiated: This auxiliary process is executed by the E2E service management domain when an E2E
service instance is decommissioned or deactivated. It undoes the steps that were executed for this service
instance during "consumer-initiated set-up of collecting 'E2E-service specific' information related to domain
service instances" (see clause 5.4.2.2.2).
ETSI
52 ETSI GS ZSM 008 V1.1.1 (2022-07)
5.4.5.2.1 Producer-initiated tear-down of information collection related to domain service

instances
Figure 5.4.5.2.1-1: Producer-initiated tear-down of information collection

When a domain service instance ceases to exist or is deactivated, the producing management domain tears down the
collection of information that it has previously set up related to that produced domain service instance and (optionally)
the externally visible resources associated with this instance. In the steps below, the shorthand "produced service
instance / associated resources" is used for these. This procedure, which is illustrated in figure 5.4.5.2.1-1, is triggered
either during service decommissioning or service deactivation, or during both of these processes if it is intended to split
the procedure into two parts that complement each other.
PRECONDITIONS:
• A domain service instance ceases to exist or is deactivated.
ETSI
53 ETSI GS ZSM 008 V1.1.1 (2022-07)
1. If the management domain has configured the collection of streaming measurements related to the produced
service instance / associated resources, it reverts this configuration using the "Configure measurements"
capability of the "Performance measurements streaming service".
2. If the management domain has configured the collection of batch measurements related to the produced
service instance / associated resources, it reverts this configuration using the "Configure batch measurements"
capability of the "Performance measurements collection service".
3. If the management domain has configured the monitoring of performance events (threshold crossings) related
to the produced service instance / associated resources, it reverts this configuration using the "Configure
monitoring" capability of the "Performance events service".
4. If the management domain has configured the monitoring of faults related to the produced service instance /
associated resources, it reverts this configuration using the using the "Configure monitoring" capability of the
"Fault events service".
5. If the management domain has configured the monitoring of security events related to the produced service
instance / associated resources, it reverts this configuration using the "Configure monitoring" capability of the
"Security events service".
6. If the management domain has configured the reporting of health issues related to the produced service
instance, it reverts this configuration using the "Configure service" capability of the "Health issue reporting
service".
NOTE: Any combination of steps 1, 2, 3, 4, 5 and 6 may be executed in any order.
7. If the management domain has created channels in the integration fabric through which the collected
information has been provided, it deletes these channels using the "Manage channels" capability of the
POSTCONDITIONS:
• Notifications related to issues and performance, as well as streaming and batch measurements that the producing
management domain has exposed for a domain service instance, are no longer produced.
ERROR CONDITIONS:
• The procedure fails if any of the individual steps fails, unless the management domain is able to recover from
the process step failure / failures.
ETSI
54 ETSI GS ZSM 008 V1.1.1 (2022-07)
5.4.5.2.2 Consumer-initiated tear-down of collecting "E2E-service specific" information

Figure 5.4.5.2.2-1: Consumer-initiated tear-down of collecting "E2E-service specific"

information related to domain service instances
When an E2E service instance ceases to exist or is deactivated, the E2E service management domain tears down the
collection of information from the MDs related to domain service instances consumed by that particular E2E service
instance and (optionally) externally visible resources associated with these domain service instances. In the steps below,
the shorthand "consumed domain service instances / associated resources" is used for these. Such information collection
for a particular E2E service instance has previously been set up when the E2E service was instantiated or activated. This
procedure, which is illustrated in figure 5.4.5.2.2-1, is triggered either during E2E service decommissioning or E2E
service deactivation, or during both of these processes if it is intended to split the procedure into two parts that
complement each other.
PRECONDITIONS:
• An E2E service instance is being decommissioned or deactivated.
ETSI
55 ETSI GS ZSM 008 V1.1.1 (2022-07)
1. If the E2E service management domain has configured in the MDs the collection of streaming measurements
related to consumed domain service instances / associated resources, it reverts this configuration using the
"Configure measurements" capability of the "Performance measurements streaming service".
2. If the E2E service management domain has configured in the MDs the collection of batch measurements
related to consumed domain service instances / associated resources, it reverts this configuration using the
"Configure batch measurements" capability of the "Performance measurements collection service".
3. If the E2E service management domain has configured in the MDs the monitoring of performance events
(threshold crossings) related to consumed domain service instances / associated resources, it reverts this
configuration using the "Configure monitoring" capability of the "Performance events service".
4. The E2E service management domain reverts its own configuration of collecting performance measurements
related to the E2E service instance.
5. If the E2E service management domain has configured in the MDs the monitoring of faults related to
consumed domain service instances / associated resources, it reverts this configuration using the "Configure
monitoring" capability of the "Fault events service".
6. If the E2E service management domain has configured in the MDs the monitoring of security events related to
consumed domain service instances / associated resources, it reverts this configuration using the "Configure
monitoring" capability of the "Security events service".
7. If the E2E service management domain has configured in the MDs the reporting of health issues related to
consumed domain service instances, it reverts this configuration using the "Configure service" capability of the
"Health issue reporting service" (if exposed).
8. The E2E service management domain removes its own configuration of the health issue reporting service
related to the E2E service instance, using the "Health issue reporting service".
NOTE: Any combination of steps 1, 2, 3 and steps 5, 6, 7 may be executed in any order.
9. If the E2E service management domain has subscribed previously to channels related to the collection of
information about consumed domain service instances / associated resources, it unsubscribes with the
integration fabric from those channels using the "Manage subscriptions" capability of the "Management
10. If the E2E service management domain has created channels in the integration fabric related to the assurance
of the E2E service instance, it deletes these channels using the "Manage channels" capability of the
POSTCONDITIONS:
• Notifications related to issues and performance, as well as streaming and batch measurements that the E2E
service management has requested from the management domains to assure an E2E service instance, are no
longer produced by the management domains.
ERROR CONDITIONS:

• None.
ETSI
56 ETSI GS ZSM 008 V1.1.1 (2022-07)
• Domain data collection: "Configure monitoring" capability of the "Performance events service".
• Domain data collection: "Configure measurements" capability of the "Performance measurements streaming
service".
• Domain data collection: "Configure batch measurements" capability of the "Performance measurements
• Domain data collection: "Configure monitoring" capability of the "Fault events service".
• Domain data collection: "Configure monitoring" capability of the "Security events service".
• Domain intelligence: "Configure service" capability of the "Health issue reporting service" (if exposed).
• ZSM integration fabric: "Manage channels" and "Manage subscriptions" capabilities of the "Management
6 Management domain support for cross-domain E2E

service lifecycle management
6.1 Overview
The following clauses define mappings of the management services referenced in the management processes in clause 5
to the NorthBound Interfaces (NBIs) of different technology domains. A detailed definition of the referenced
management services is provided in ETSI GS ZSM 002 [1]. Additions to these service definitions are defined in
Annex A of the present document.
6.2 3GPP Core domain and 3GPP RAN domain

This clause defines the mapping of the ZSM management services to their 3GPP-defined Core and RAN counterparts.
As 3GPP has unified management procedures, both types of domains are documented in the same clause. The only
difference are the data models used and these differences are called out in table 6.2-1 where applicable.
Table 6.2-1: Mapping of ZSM MnSs and 3GPP management services

in 3GPP Core and 3GPP RAN domains
Referenced ZSM MnS + Specification External organizations' Description / Comment
capability reference APIs / operations
Domain orchestration: Managed services catalogue management service
Manage service models n/a
Provide catalogue change n/a
notifications
Request missing service n/a
catalogue entry
ETSI
57 ETSI GS ZSM 008 V1.1.1 (2022-07)
Domain orchestration: Feasibility check service

Check deployment ETSI TS 128 531 [7] Use case and procedure Clauses 5.1.21 and 7.14 of ETSI
feasibility of network slice subnet TS 128 531 [7] define a use case
ETSI TS 128 541 [8] feasibility check [7] and a flow for a feasibility check with
reservation that is geared towards
FeasibilityCheckAnd- network slice subnets.
ReservationJob IOC [8]
Additionally, ETSI TS 128 541 [8]
Check and reserve (if ETSI TS 128 531 [7] Use case and procedure defines a "FeasibilityCheckAnd-
supported) of network slice subnet ReservationJob" IOC. This IOC
ETSI TS 128 541 [8] feasibility check [7] allows the creation of feasibility
check jobs with and without resource
FeasibilityCheckAnd- reservation.
ReservationJob IOC [8]
Domain orchestration: Domain orchestration service
Manage service lifecycle ETSI TS 128 532 [6] createMOI
(instantiate service)
Manage service lifecycle ETSI TS 128 532 [6] modifyMOIAttributes
(scale service)
(configure service)
(activate service)
(deactivate service)
Manage service lifecycle ETSI TS 128 532 [6] deleteMOI
(terminate service)
Execute workflow n/a
Manage subscriptions to ETSI TS 128 532 [6] createMOI The subscription NRM control
lifecycle changes (if fragment is defined in ETSI
exposed) modifyMOIAttributes TS 128 622 [12] as
"NtfSubscriptionControl" information
deleteMOI element.
Provide notifications about ETSI TS 128 532 [6] notifyMOICreation Subscriptions are needed to receive
lifecycle changes notifications.
notifyMOIDeletion
"notifyMOICreation" notifies about
notifyMOIAttributeValueCh the creation of a new MOI instance.
anges
"notifyMOIDeletion" notifies about the
notifyEvent deletion of an MOI instance.
notifyMOIChanges "notifyMOIAttributeValueChanges"
notifies about the modification of
attribute values in an MOI instance.
"notifyEvent" notifies about certain

network events with potential service
impact, e.g. system restart.
"notifyMOIChanges" is a composite
notification that notifies about
multiple updates of MOIs (creation,
deletion, attribute value change).
The management service producer

decides whether to send separate
"notifyMOICreation",
"notifyMOIDeletion" and
"notifyMOIAttributeValueChanges"
notifications, or an aggregate
"notifyMOIChanges" notification.
Domain orchestration: Testing service
Manage test specifications n/a
Test resources n/a
Query tests n/a
ETSI
58 ETSI GS ZSM 008 V1.1.1 (2022-07)
Domain orchestration: Domain inventory information service

Query inventory of ETSI TS 128 532 [6] getMOIAttributes ETSI TS 128 532 [6] defines the
available resources (if provisioning service to access the
exposed) ETSI TS 128 622 [12] NRM (network resource model)
which is a federated model spanning
ETSI TS 128 541 [8] multiple specifications that includes a
large set of information, including
ETSI TS 128 632 [9] inventory information.
ETSI TS 128 658 [13] The model consists of parts defined

in the following specifications: ETSI
ETSI TS 128 708 [14] TS 128 622 [12] defines the 3GPP
root model. ETSI TS 128 541 [8]
defines the 5G-specific model for
RAN and Core. ETSI TS 128 632 [9]
defines the pre-5G legacy inventory
model for hardware. ETSI
TS 128 658 [13] defines the LTE
radio (E-UTRAN) model and ETSI
TS ETSI TS 128 708 [14] specifies
the LTE core (EPC) model.
Configure notifications (if ETSI TS 128 532 [6] createMOI The subscription NRM control
supported) fragment is defined in ETSI
ETSI TS 128 622 [12] modifyMOIAttributes TS 128 622 [12] as
"NtfSubscriptionControl" IOC.
deleteMOI
Provide notifications about ETSI TS 128 532 [6] notifyMOIAttributeValueCh Subscriptions are needed to receive
inventory changes (if anges notifications.
supported)
contains a list of changed attributes
notifyMOIDeletion with the changes performed for a
single MOI.
"notifyMOIChanges" notifies about

changes performed on multiple
MOIs.

deletion of an MOI.
Domain orchestration: Domain topology information service
Query topology ETSI TS 128 532 [6] getMOIAttributes ETSI TS 128 532 [6] defines the
information (if exposed) provisioning service to access the
ETSI TS 128 622 [12] NRM (Network Resource Model)
which is a federated model spanning
ETSI TS 128 541 [8] multiple specifications that includes a
large set of information, including
ETSI TS 128 632 [9] topology information.
ETSI TS 128 658 [13] Two aspects of topology are defined

in the NRM.
ETSI TS 128 708 [14]
"Logical topology" is modelled by the
so-called name-containment,
defining a hierarchy of managed
objects, and used as a central
concept all over the NRM).
"Network topology" is modelled as

End-Points (EPs) each of which can
reference another EP, defining which
network node communicates with
which other network node using
which interfaces. Interfaces are
modelled as endpoints which are
name-contained within the managed
functions.
ETSI
59 ETSI GS ZSM 008 V1.1.1 (2022-07)
For instance, in ETSI TS 128 541 [8],

the "EP_x" IOCs represent the
different endpoint types. Examples
for logical topology can be found in
figure 4.2.1.1-1 of ETSI
TS 128 541 [8] and for network
topology in figure 4.2.1.1-2 of ETSI
TS 128 541 [8].
The relevant model parts are the

same as the ones defined for "Query
inventory of available resources".
Configure notifications ETSI TS 128 532 [6] createMOI The subscription NRM control
(if supported) fragment is defined in ETSI
modifyMOIAttributes TS 128 622 [12] as
"NtfSubscriptionControl" information
deleteMOI element.
Provide notifications about ETSI TS 128 532 [6] notifyMOIAttributeValueCh Subscriptions are needed to receive
topology changes (if anges notifications.
supported)
contains a list of changed attributes
notifyMOIDeletion with the changes performed for a
single MOI.
"notifyMOIChanges" notifies about

changes performed on multiple
MOIs.

deletion of an MOI.
Domain control: Virtualised resource lifecycle management service
Manage subscription to ETSI TS 128 527 [17] See clause 6.5 3GPP is re-using the specifications
lifecycle changes (if of ETSI NFV for the management of
exposed) NFV network services and VNFs.
ETSI TS 128 527 [17] provides
references to these specifications.
The relevant functionality is therefore
the same as those defined for
"Configure notifications" of this
service in clause 6.5.
Provide notifications about ETSI TS 128 527 [17] See clause 6.5 3GPP is re-using the specifications
lifecycle changes (if of ETSI NFV for the management of
exposed) NFV network services and VNFs.
ETSI TS 128 527 [17] provides
references to these specifications.
The relevant notifications are
therefore the same as those defined
for "Provide notifications about
lifecycle changes" in clause 6.5.
Domain data collection: Performance events service
Configure monitoring ETSI TS 128 532 [6] createMOI Three types of control fragments are
provisioned as MOIs, using
ETSI TS 128 622 [12] modifyMOIAttributes operations defined in ETSI
TS 128 532 [6], to configure the
ETSI TS 128 552 [10] deleteMOI monitoring.
ETSI TS 132 425 [15]
ETSI TS 132 426 [16]
ETSI
60 ETSI GS ZSM 008 V1.1.1 (2022-07)
Performance metrics jobs are based

on the "PerfMetricJob" NRM control
fragment defined in ETSI
TS 128 622 [12]. They produce
measurements for which the
following definitions apply: For 5G,
RAN and Core measurements are
defined in ETSI TS 128 552 [10]. For
LTE, E-UTRAN measurements are
defined in ETSI TS 132 425 [15] and
EPC measurements are defined in
ETSI TS 132 426 [16].
Threshold monitors are based on the

"ThresholdMonitor" NRM control
TS 128 622 [12]. They generate
notifications if a metric that is
produced by a performance metric
job crosses a threshold.
Subscriptions are based on the

"NtfSubscriptionControl" NRM control
TS 128 622 [12]. They route the
generated notifications to the
subscribers.
A management domain may

pre-create a default set of
performance metrics job, threshold
monitor and subscription control
fragments.
Provide notifications ETSI TS 128 532 [6] notifyThresholdCrossing Subscriptions are needed to receive
notifications.
"notifyThresholdCrossing" informs a
subscriber that a threshold monitor
has detected a threshold crossing.
Domain data collection: Performance measurements streaming service
Configure measurements ETSI TS 128 532 [6] createMOI Performance metrics jobs are
provisioned as MOIs, using
ETSI TS 128 622 [12] modifyMOIAttributes operations defined in ETSI
TS 128 532 [6], based on the
ETSI TS 128 552 [10] deleteMOI "PerfMetricJob" NRM control
ETSI TS 128 554 [11] TS 128 622 [12].
ETSI TS 132 425 [15] They produce measurements and

KPIs for which the following
ETSI TS 132 426 [16] definitions apply: For 5G, RAN and
Core measurements are defined in
ETSI TS 128 552 [10] and related
KPIs are specified in ETSI
TS 128 554 [11]. For LTE, E-UTRAN
measurements are defined in ETSI
TS 132 425 [15] and EPC
TS 132 426 [16]. No KPIs have been
standardized for LTE.
The reporting control properties

("ReportingCtrl") of the
PerfMetricsJob control fragments are
set to choose streaming delivery of
the metrics.
ETSI
61 ETSI GS ZSM 008 V1.1.1 (2022-07)
A management domain may

pre-create a default set of
performance metrics job control
fragments.
Provide streaming ETSI TS 128 532 [6] establishStreamingConne
measurements ction
reportStreamData
addStream
deleteStream
terminateStreamingConne
ction
Domain data collection: Performance measurements collection service
Configure batch ETSI TS 128 532 [6] createMOI Two types of control fragments are
measurements provisioned as MOIs, using
ETSI TS 128 622 [12]. modifyMOIAttributes operations defined in ETSI
TS 128 532 [6], to configure the
ETSI TS 128 552 [10] deleteMOI collection of metrics and KPIs.
ETSI TS 128 554 [11] Performance metrics jobs are based

on the "PerfMetricJob" NRM control
ETSI TS 132 425 [15] fragment defined in ETSI
TS 128 622 [12].
ETSI TS 132 426 [16]
They produce measurements and
KPIs for which the following
definitions apply: For 5G, RAN and
Core measurements are defined in
ETSI TS 128 552 [10] and related
KPIs are specified in ETSI
TS 128 554 [11]. For LTE, E-UTRAN
TS 132 425 [15] and EPC
TS 132 426 [16]. No KPIs have been
standardized for LTE.
The reporting control properties

("ReportingCtrl") of the
PerfMetricsJob control fragments are
set to choose file delivery of the
metrics.
Subscriptions are based on the

generated notifications about the
availability of batches of collected
measurements to the subscribers.
A management domain may pre-

create a default set of performance
metrics job and subscription control
fragments.
ETSI
62 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide batch availability ETSI TS 128 532 [6] notifyFileReady Subscriptions are needed to receive
notifications notifications.
notifyFilePreparationError
"notifyFileReady" informs that a file
with collected performance
information is available for retrieval.
"notifyFilePreparationError" informs
that the preparation of a file with
collected performance information
has failed.
Get batch measurements ETSI TS 128 532 [6] listAvailableFiles "listAvailableFiles" allows to list
information about the available files
as an alternative to parsing the
notifications.
The file is obtained from the location

(path, URI) signaled in
"notifyFileReady" or
"listAvailableFiles". The actual
means to retrieve the files is not
specified by 3GPP.
Domain data collection: Fault events service
Configure monitoring ETSI TS 128 532 [6] createMOI Subscriptions to alarm notifications
are provisioned as MOIs, using
modifyMOIAttributes operations defined in ETSI
deleteMOI "NtfSubscriptionControl" NRM control
generated alarm notifications to the
subscribers.
A management domain may choose

to pre-create default subscription
control fragments.
Provide notifications ETSI TS 128 532 [6] notifyNewAlarm Subscriptions are needed to receive
notifications.
notifyChangedAlarmGener "notifyNewAlarm" informs about a
al new alarm.
"notifyChangedAlarmGeneral"
notifyChangedAlarm informs about changes in the
perceived severity of an alarm.
"notifyChangedAlarm" specifically
informs about changes in the
perceived severity of an alarm, other
than clearing the alarm.
The set of applicable alarm attributes
is defined in clause 12.2.1.2.2 of [6].
Domain data collection: Security events service
Configure monitoring ETSI TS 128 532 [6] createMOI The security events service uses the
same mechanism as the fault events
modifyMOIAttributes service above.
deleteMOI Subscriptions to alarm notifications

are provisioned as MOIs, using
operations defined in ETSI
generated alarm notifications to the
subscribers.
A management domain may choose

to pre-create default subscription
control fragments.
ETSI
63 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications ETSI TS 128 532 [6] notifyNewAlarm Subscriptions are needed to receive
notifications.
notifyChangedAlarmGener
al "notifyNewAlarm" informs about a
new alarm.
notifyChangedAlarm
"notifyChangedAlarmGeneral"
perceived severity of an alarm.
"notifyChangedAlarm" specifically
perceived severity of an alarm, other
than clearing the alarm.
The set of applicable alarm attributes

for security-related alarms is defined
in clause 12.2.1.2.3 of [6].
Domain data collection: Log collection service (if exposed)
Query logs n/a
Domain analytics: Analytics services derived from Generic analytics service (if exposed)
Configure analytics 3GPP TS 28.104 [i.3] (work in progress) 3GPP Rel.17 includes the definition
Request analysis result 3GPP TS 28.104 [i.3] (work in progress) of the Management Data Analytics
Service (MDAS). 3GPP
TS 28.104 [i.3] defines requirements
and the data consumed for
performing a set of standardized
analytics use cases in the 3GPP
management plane. It can import
data from the Network Data Analytics
Function (NWDAF) (see ETSI
TS 123 288 [i.2]) which allows
requesting a set of pre-defined
analytics for the control plane of the
3GPP Core domain.
Domain intelligence: Health issue reporting service
Configure service n/a
(if exposed)
Provide health issue n/a
notifications (if exposed)
Integration fabric: Management communication service
Manage channels n/a
Manage subscriptions n/a
Receive data n/a
Provide data n/a
Integration fabric: Management services discovery service
Query service list n/a
Get service info n/a
Cross-domain data services: Data persistence service (optional)
Query data n/a
Store data n/a
6.3 Fixed access domain

Broadband Forum (BBF) has defined an architecture framework called "Cloud Central Office (CloudCO)" (see BBF
TR-384 [18]) that supports the zero-touch automation of SDN functionality, the re-use of existing BBF-defined
resources and their migration to the cloud. The CCO DO (Cloud CO Domain Orchestrator) within that architectural
framework produces management services towards consumers, including OSS / BSS, other management domains and
the E2E service management domain, that allows the management and orchestration of the network services provided
by the fixed access domain.
ETSI
64 ETSI GS ZSM 008 V1.1.1 (2022-07)
BBF TR-411 [19] provides a general definition of the interfaces between the CloudCO elements and defines the
protocols and data models to be used on these interfaces by referencing related TM Forum specifications. Therefore,
compared to other domain mappings in the present document that are strictly stage-2, the BBF mapping is closer to the
stage-3.
The "Os-Ma-ccodo" reference point in the CloudCO architecture is the main integration point between the
CloudCO-based fixed access domain and the E2E service management domain.
Table 6.3-1: Mapping of ZSM MnSs and BBF management interfaces in Fixed access domain
Referenced ZSM MnS + Spec ref External organizations' Description / comment
capability APIs / operations
Manage service models BBF Service Catalog Management TMF633 [22] offers the E2E service
TR-411 [19] API (TMF633 [22]) management domain means of
Provide catalogue change BBF Service Catalog Management querying the CCO DO run-time
notifications TR-411 [19] API (TMF633 [22]) Service Catalogue to determine the
Request missing service n/a service types available within the
catalogue entry CCO domain.
In addition, TM633 [22] offers a

complete set of CRUD-N capabilities
to lifecycle manage the content of the
CCO DO run-time Service
Catalogue.
Check deployment BBF Service Qualification TMF645 [28] offers the E2E service
feasibility TR-411 [19] Management API management domain a standard
(TMF645 [28]) means of validating whether specific
service characteristics can be offered
at a geographic location.
Check and reserve (if n/a
supported)
Manage service lifecycle BBF Service Ordering Management TMF641 [26] offers the E2E service
(instantiate service) TR-411 [19] API (TMF641 [26]) management domain a standard
means of ordering services from the
Resource Inventory Management CCO DO, enabling the Network-as-a-
API (TMF639 [24]) Service/Subscriber-as-a-Service
Manage service lifecycle n/a paradigms. Notifications of changes
(scale service) to the order item(s) state and service
Manage service lifecycle BBF Service Ordering Management instance are also offered. Error
(configure service) TR-411 [19] API (TMF641 [26]) handling notifications are exposed
northbound to the E2E service
Resource Inventory Management management domain.
API (TMF639 [24])
Manage service lifecycle BBF Service Ordering Management A service order for resource facing
(activate service) TR-411 [19] API (TMF641 [26]) services can optionally reference
resources that are represented in the
Resource Inventory Management resource inventory (TMF639 [24]).
API (TMF639 [24])
Manage service lifecycle BBF Service Ordering Management
(deactivate service) TR-411 [19] API (TMF641 [26])
Resource Inventory Management

API (TMF639 [24])
Manage service lifecycle BBF Service Ordering Management
(terminate service) TR-411 [19] API (TMF641 [26])

API (TMF639 [24])
ETSI
65 ETSI GS ZSM 008 V1.1.1 (2022-07)
Manage subscriptions to BBF Service Ordering Management

lifecycle changes (if TR-411 [19] API (TMF641 [26])
exposed)
API (TMF639 [24])
Service Inventory Management

API (TMF638 [23])
Provide notifications about BBF Service Ordering Management
lifecycle changes TR-411 [19] API (TMF641 [26])

API (TMF639 [24])

API (TMF638 [23])
Manage test specifications BBF Service Test Management API TMF653 [29] offers the E2E service
TR-411 [19] (TMF653 [29]) management domain standard
Test resources BBF Service Test Management API means of requesting and managing
TR-411 [19] (TMF653 [29]) service tests for services
Query tests BBF Service Test Management API orchestrated by the CCO DO.
TR-411 [19] (TMF653 [29])
Query inventory of BBF Service Inventory Management TMF638 [23] offers the E2E service
available resources TR-411 [19] API (TMF638 [23]) management domain a standard
(if exposed) means of query, updating and
Resource Inventory Management receiving notifications from the CCO
API (TMF639 [24]) DO's Service Inventory including to
service state recorded in the
YANG based equipment catalogue.
inventory / network map (BBF
TR-454 [20]) TMF639 [24] offers the E2E service
Configure notifications BBF Service Inventory Management management domain a standard
(if supported) TR-411 [19] API (TMF638 [23]) means of querying, updating and
receiving notifications from the
Resource Inventory Management CCO DO's Resource Inventory.
API (TMF639 [24])
BBF TR-454 [20] provides a YANG
YANG based equipment based equipment inventory and
inventory / network map (BBF associated infrastructure network
TR-454 [20]) map.
Provide notifications BBF Service Inventory Management
about inventory changes TR-411 [19] API (TMF638 [23])
(if supported)
API (TMF639 [24])
YANG based equipment

TR-454 [20])
Query topology BBF Resource Inventory Management TMF639 [24] offers the E2E service
information (if exposed) TR-411 [19] API (TMF639 [24]) management domain a standard
means of querying, updating and
YANG based equipment receiving notifications from the
inventory / network map (BBF CCO DO's Resource Inventory.
TR-454 [20])
Configure notifications BBF Resource Inventory Management BBF TR-454 [20] provides a YANG
(if supported) TR-411 [19] API (TMF639 [24]) based equipment inventory and
associated infrastructure network
YANG based equipment map.
TR-454 [20])
ETSI
66 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications about BBF Resource Inventory Management

topology changes TR-411 [19] API (TMF639 [24])
(if supported)
YANG based equipment
TR-454 [20])
Manage subscription to BBF Subscribe BBF is re-using the specifications of
lifecycle changes TR-411 [19] ETSI NFV for the management of
(if exposed) Terminate subscription NFV network services and VNFs.
(See clause 6.4.16 of ETSI The relevant notifications are
GS NFV-SOL 005 [5]) therefore the same as those defined
The CloudCO Domain Orchestration

Function provides the capability of
directly exposing the CloudCO
Domain Orchestration NFVO
capabilities defined by the
Os-Ma-nfvo reference point across
the Os-Ma-ccodo reference point as
specified in ETSI
GS NFV-SOL 005 [5].
Provide notifications about BBF Provide notifications about BBF is re-using the specifications of
lifecycle changes TR-411 [19] lifecycle changes (clause 6.6 of ETSI NFV for the management of
(if exposed) ETSI GS NFV-SOL 005 [5]) NFV network services and VNFs.
The relevant notifications are
therefore the same as those defined
The CloudCO Domain Orchestration

Function provides the capability of
directly exposing the CloudCO
Domain Orchestration NFVO
capabilities defined by the
Os-Ma-nfvo reference point across
the Os-Ma-ccodo reference point as
specified in ETSI
GS NFV-SOL 005 [5] including fault
and performance management.
Configure monitoring n/a
Provide notifications n/a
Configure measurements n/a
Provide streaming n/a
measurements
Configure batch n/a
measurements
Provide batch availability n/a
notifications
Get batch measurements n/a
Query logs (if exposed) n/a
Configure analytics n/a
Request analysis result n/a
ETSI
67 ETSI GS ZSM 008 V1.1.1 (2022-07)

(if exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Query data n/a
Store data n/a
6.4 Transport domain

6.4.1 Overview
Within the transport domain, different technologies at different layers are used that need to be managed. Transport
aspects include optical transport, layer 2 and layer 3 VPNs allowing point-to-point and point-to-multipoint connections,
and transport slices.
The subscribe-notify mechanism used in transport domains with IETF-based NBI is based on a combination of two
RFCs: IETF RFC 8639 [43] defines a YANG model and mechanisms that allows subscribing to a publisher's event
streams and accessing these streams in a transport protocol agnostic way. IETF RFC 8641 [44] known as "YANG Push"
extends the subscription model defined in IETF RFC 8639 [43] with capabilities that allow subscribers to define the
triggers to retrieve updates on datastores and control these triggers by filters. Two notification mechanisms are defined
that provide the values of selected sets of nodes in the model tree:
1) periodic notifications which repeatedly send the current values of the subscribed nodes after each period of
configurable length;
2) change notifications which send the current values of those subscribed nodes that have changed. To prevent
notification storms, a dampening period can be configured that restricts the rate of generating notifications.
For subscription, the YANG models that represent the resources and services in the datastore to which the subscription
applies, as well as the data models defined for the subscription to event streams (ietf-subscribed-notifications) and their
augmentation for YANG Push (ietf-yang-push) are relevant. The subscription mechanism defined by IETF
RFC 8639 [43] and IETF RFC 8641 [44] allows to create, modify and delete subscriptions to notifications on a
per-client basis. When subscribing, "stream filters" can be specified with subtree filters or XML Path Language (XPath)
filters related to the resources and services data models, so that only contents of interest will be sent.
The notifications are accessed via a stream resource using the protocol defined in IETF RFC 8650 [45]. The address of
the stream resource is returned upon subscription. The content of the notifications represents a part of the model tree
that has been selected during subscription. Even though IETF RFC 8639 [43] and IETF RFC 8641 [44] are
transport-agnostic, the mappings defined in tables 6.4.2-1 and 6.4.4-1 assume RESTCONF protocol bindings of the
dynamic subscription capability to both publisher's event streams and YANG-Push.
Different management interfaces have been developed to manage these different aspects of transport networks. In the
following clauses, these different transport management interfaces are mapped to the ZSM management services.
6.4.2 Optical transport domain with IETF-based NBI

Optical transport networks provide services of different level, including the client layer, the OTN layer, the wavelength
layer, etc. the information / data model has been aligned with IETF, there are multiple WGs covering the optical
transport network service models which include but not limited to TEAS and CCAMP WG. The models are all
described in the YANG [35] modeling language and support operations via multiple protocols e.g. NETCONF [36] or
RESTCONF [38].
ETSI
68 ETSI GS ZSM 008 V1.1.1 (2022-07)
Table 6.4.2-1: Mapping of ZSM MnSs and IETF management interfaces in Optical transport domain
Referenced ZSM MnS Spec ref External organizations' Description / comment

+ capability APIs / operations
notifications
catalogue entry
Check deployment draft-ietf-teas-yang-te Operation: POST This API can be used for path
feasibility [i.8] computation and check the feasibility
Data model: before service deployment.
draft-ietf-teas-yang- ietf-te-path-computation
path-computation [i.9] [i.9]
supported)
Manage service lifecycle draft-ietf-teas-yang-te Operation: POST In IETF, a TE tunnel or client service
(instantiate service) [i.8] can be instantiated by creating a
Data models: tunnel or client service instance.
draft-ietf-ccamp-otn- ietf-te [i.8]
tunnel-model [i.10] ietf-otn-tunnel [i.10]
ietf-wson-tunnel [i.11]
draft-ietf-ccamp-wson- ietf-trans-client-service
tunnel-model [i.11] [i.12]
draft-ietf-ccamp-client-
signal-yang [i.12]
Manage service lifecycle draft-ietf-teas-yang-te Operation: PATCH In IETF, the reserved TE tunnel
(scale service) [i.8] resources can be modified using the
Data models: patch method.
Manage service lifecycle draft-ietf-teas-yang-te Operation: PATCH Optical transport MD can support TE
(configure service) [i.8] tunnel and client service modification
Data models: by their PATCH method.
ietf-trans-client-service
draft-ietf-ccamp-client- [i.12]
signal-yang [i.12]
Manage service lifecycle draft-ietf-teas-yang-te Operation: PATCH By setting TE tunnel's or client
(activate service) [i.8] service's administrative state to up,
Data models: the TE tunnel or client service would
draft-ietf-ccamp-client- ietf-te [i.8] be activated.
signal-yang [i.12] ietf-trans-client-service
[i.12]
Manage service lifecycle draft-ietf-teas-yang-te Operation: PATCH By setting TE tunnel's or client
(deactivate service) [i.8] service's administrative state to
Data models: down, the TE tunnel or client service
draft-ietf-ccamp-client- ietf-te [i.8] would be deactivated.
[i.12]
Manage service lifecycle draft-ietf-teas-yang-te Operation: DELETE TE tunnel and client service instance
(terminate service) [i.8] can be removed by its DELETE API.
Data models:
draft-ietf-ccamp-client- ietf-te [i.8]
[i.12]
ETSI
69 ETSI GS ZSM 008 V1.1.1 (2022-07)
Manage subscriptions to IETF RFC 8639 [43] Operation: POST / The details of subscribe / notify are
lifecycle changes (if PATCH / DELETE described in clause 6.4.1.
exposed) IETF RFC 8641 [44]
Data models for Subscription to change notifications
IETF RFC 8650 [45] subscription: related to TE tunnels and client
ietf-subscribed- services will allow to receive
draft-ietf-teas-yang-te notifications [43] notifications about new / modified /
[i.8] ietf-yang-push [44] removed TE tunnels and client
service instances.
draft-ietf-ccamp-client- Data models for
signal-yang [i.12] subscribed content:
[i.12]
ietf-te [i.8]
Provide notifications about IETF RFC 8639 [43] Operation: GET The details of subscribe / notify are
lifecycle changes described in clause 6.4.1.
IETF RFC 8641 [44]
IETF RFC 8650 [45] defines how
IETF RFC 8650 [45] notifications related to a subscription
can be obtained using GET from a
stream resource with an address that
has been provided by the service
producer upon subscription.
Manage test n/a
specifications
Test resources n/a
Query tests n/a
Query inventory of draft-ietf-teas-yang-te Operation: GET Information about TE tunnel and
available resources (if [i.8] client service instances can be
exposed) Data models: obtained using the GET method.
ietf-wson-tunnel [i.11]
draft-ietf-ccamp-wson- ietf-trans-client-service
tunnel-model [i.11] [i.12]
draft-ietf-ccamp-client-
signal-yang [i.12]
Configure notifications (if IETF RFC 8639 [43] Operation: POST / The details of subscribe / notify are
supported) PATCH / DELETE described in clause 6.4.1.
IETF RFC 8641 [44]
IETF RFC 8795 [46] subscription: related to TE tunnels and client
ietf-subscribed- services will allow to receive
draft-ietf-teas-yang-te notifications [43] notifications about new / modified /
[i.8] ietf-yang-push [44]] removed TE tunnels and client
service instances.
draft-ietf-ccamp-otn- Data models for
tunnel-model [i.10] subscribed content:
ietf-te [i.8]
draft-ietf-ccamp-wson- ietf-otn-tunnel [i.10]
tunnel-model [i.11] ietf-wson-tunnel [i.11]
draft-ietf-ccamp-client- [i.12]
signal-yang [i.12]
inventory changes (if described in clause 6.4.1.
supported) IETF RFC 8641 [44]
ETSI
70 ETSI GS ZSM 008 V1.1.1 (2022-07)

Query topology IETF RFC 8345 [40] Operation: GET IETF RFC 8795 [46] defines the
information (if exposed) optical transport TE topology model
IETF RFC 8795 [46] Data models: which represents topology
ietf-network [40] information.
draft-ietf-ccamp-otn- ietf-network-topology [40]
topo-yang [i.13] ietf-te-topology [46]
ietf-otn-topology [i.13]
IETF RFC 9094 [48] ietf-wson-topology [48]
ietf-eth-te-topology [i.14]
draft-ietf-ccamp-eth-
client-te-topo-yang
[i.14]
Configure notifications IETF RFC 8639 [43] Operation: POST / The details of subscribe / notify are
(if supported) PATCH / DELETE described in clause 6.4.1.
IETF RFC 8641 [44] Subscriptions to change notifications
Data models for related to topology data stores will
IETF RFC 8650 [45] subscription: allow to receive notifications about
ietf-subscribed- topology changes.
IETF RFC 8345 [40] notifications [43]
ietf-yang-push [44] A service consumer may enable
IETF RFC 8795 [46] "topology data changes" subscription
Data models for by setting the "stream-filter"
draft-ietf-ccamp-otn- subscribed content: (described by "sub-tree" or "xPath"
topo-yang [i.13] ietf-network [40] which contains the concerned
ietf-network-topology [40] topology models) in the subscription
IETF RFC 9094 [48] ietf-te-topology [46] request input.
ietf-otn-topology [i.13]
draft-ietf-ccamp-eth- ietf-wson-topology [48]
client-te-topo-yang ietf-eth-te-topology [i.14]
[i.14]
topology changes described in clause 6.4.1.
(if supported) IETF RFC 8641 [44]
Manage subscription to n/a
lifecycle changes (if
exposed)
Provide notifications about n/a
exposed)
measurements
Configure batch n/a
measurements
notifications
ETSI
71 ETSI GS ZSM 008 V1.1.1 (2022-07)

Query logs n/a
Configure service (if n/a
exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Cross-domain data services: Data persistence service(optional)
Query data n/a
Store data n/a
6.4.3 Optical transport domain with TAPI as NBI

The present clause describes the ONF approach of integrating the management of an optical transport domain with
E2E-level management entities. The ONF has defined the Transport Application Programming Interface which allows
an E2E management entity to manage the services of an optical transport domain based on YANG models. These
YANG models have been derived from UML models, both of which are defined in the "ONF Transport API SDK"
specification [34]. The "TAPI Reference Implementation Agreement" specifications ONF TR-547 [32] and
ONF TR-548 [33] define a number of typical Use Cases (UCs). Each Use Case (UC) defines or references a procedure
and includes information which attributes of the YANG data models in [34] are relevant for that use case at the
northbound interface of the optical transport domain. In table 6.4.3-1 the applicable use cases are referenced per each
MnS capability to define the mapping. ONF TR-547 [32] focuses on connectivity management use cases. ONF TR-548
[33] defines streaming support. In the present version, the main uses of streaming are:
1) keeping the client's view consistent with updates to the state of the network; and
2) streaming of alarm notifications.
The support of streaming per ONF TR-548 [33] as an alternative way to deliver notifications is optional in TAPI.
Table 6.4.3-1: Mapping of ZSM MnSs and the ONF Transport API in Optical transport domain
Referenced ZSM MnS Spec ref External organizations' APIs / Description / comment
+ capability operations
Manage service models n/a TAPI does not support a service
catalogue service.
However, the different provisioning

use cases defined in sections 6.2
and 6.3 of ONF TR-547 [32] and
referenced in the row "Domain
orchestration service - Manage
service lifecycle" below reflect the set
of types of managed services that
can be instantiated.
notifications
catalogue entry
ETSI
72 ETSI GS ZSM 008 V1.1.1 (2022-07)

Check deployment n/a
feasibility
supported)
Manage service lifecycle ONF TR-547 UC 1.0 TAPI distinguishes between
(instantiate service) [32] UCs 1a..1h unconstrained and constrained
UCs 2a..2c service provisioning. UC 1.0 defines
UCs 3a..3f the main procedure and the set of
parameters that is shared among all
provisioning use cases.
In unconstrained provisioning, the

service request does not include any
routing constraint, therefore the
service producer uses its routing
capabilities to select the network
resources for the service instance.
The use cases 1a to 1h and 2a to 2c
define additional specific parameters
on top of the general use case 1.0
for services with different
characteristics.
In constrained provisioning, routing

constrains (e.g. constraints with
respect to specific nodes, links,
routes) or policies are included in the
service request. The use cases 3a to
3f define additional specific
parameters on top of the general use
case 1.0 services with different
characteristics.
TAPI defines use cases 5b, 5c, 6a,

6b, 7a, 7b, 8 and 9 related to
resiliency aspects of the services.
Service resilience properties have to
be chosen at service instantiation
time.
Manage service lifecycle n/a
(scale service)
Manage service lifecycle n/a The present version of TAPI does not
(configure service) define use cases for the modification
of service instances.
Manage service lifecycle TAPI SDK [34] Administrative state is represented in
(activate service) the TAPI YANG models. However,
administrative state provisioning is
not covered by a use case in the
present version of TAPI.
Manage service lifecycle TAPI SDK [34] Administrative state is represented in
(deactivate service) the TAPI YANG models. However,
administrative state provisioning is
not covered by a use case in the
present version of TAPI.
Manage service lifecycle ONF TR-547 UC 10 UC 10 defines the procedure for
(terminate service) [32] service deletion.
Manage subscriptions to ONF TR-547 UC 13a UC 13a defines the general
lifecycle changes [32] UCs 14b, 15b, 15c procedure for subscription to
(if exposed) notifications. The remaining use
cases define parameters for the
specific subscriptions.
ETSI
73 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications about ONF TR-547 UC 13a To receive notifications, a prior

lifecycle changes [32] UCs 14b, 15b, 15c subscription based on UC 13a is
required. UC 13a also defines the
procedure for notifications delivery.
The notifications relate to insertion /

removal of connectivity objects aka
services (UC 14b), status changes of
these (15 b) or switching condition of
these (15c).
Test resources n/a
Query tests n/a
Query inventory of ONF TR-547 UCs 4a, 4b UC 4a allows to access external
available resources [32] UC 5a inventory that is not defined as part
(if exposed) UC 0c of TAPI. UC 4b allows access to the
complete inventory for the NBI,
including all devices and physical
equipment. UC 5a allows to discover
the resiliency scheme embedded in
the network.
1) Physical inventory: In TAPI,

inventory use cases 4a, 4b and 5a
reflect the inventory of physical
resources.
2) Logical inventory: Use case 0c

allows to discover connectivity
services and their supporting
connections in the network.
Configure notifications ONF TR-547 TR-547: ONF TR-547 [32]:
(if supported) [32] UC 13a 1) Physical inventory: The present
UCs 14b, 15b, 15c version of ONF TR-547 [32] does not
ONF TR-548 define use cases for subscriptions
[33] TR-548: related to the physical inventory.
UCs ST-0.2, ST-5.1
2) Logical inventory: Subscription to
notifications related to changes to the
service instances (see also domain
orchestration service) can be
performed based on the use cases
13a (generic subscription) and 14b,
15b, 15c (parameters for the specific
subscriptions).
ONF TR-548 [33]:

This specification defines optional
mechanisms in TAPI which allow the
management service producers to
publish streams of any kind of
changes related to the network state.
The definitions in the informative UC
ST-5.1 also apply for changes to the
logical inventory. Streams can be
discovered and selected by the
service consumer as per UC ST-0.2.
ETSI
74 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications about ONF TR-547 TR-547: ONF TR-547 [32]:

inventory changes (if [32] UC 13a 1) Physical inventory: The present
supported) UCs 14b, 15b, 15c version of ONF TR-547 [32] does not
ONF TR-548 define use cases for subscriptions
[33] TR-548: related to the physical inventory.
UCs ST-1.1, ST-1.2
UCs ST-3.1, ST-2.1 2) Logical inventory: Notifications
UC ST-5.1 related to changes to the service
UCs ST-5.2, ST-5.3 instances (see also domain
orchestration service) can be
delivered using the generic
notification mechanism defined in UC
13a. The notifications relate to
insertion / removal of connectivity
objects aka services (UC 14b), status
changes of these (15 b) or switching
condition of these (15c). To receive
notifications, a prior subscription
based on UC 13a is required.
ONF TR-548 [33]:

For some cases, ONF TR-548 [33]
defines concrete informative use
cases how to provide streams of
such changes: UC ST-5.2 relates to
changes triggered by the execution
of provisioning use cases (UCs 1x,
2x, 3x) and UC ST-5.3 relates to
changes triggered by the deletion
Use Case (UC 10). This assumes the
prior set-up of the streams by the
producer as per UC ST-5.1, the
consumer executing UC ST-3.1 to
set up / manage the reception of the
streams and UC ST-2.1 to align with
the streams, and the producer
executing UCs ST-1.1 and ST-1.2 to
manage the production of the
streams.
ETSI
75 ETSI GS ZSM 008 V1.1.1 (2022-07)

Query topology ONF UCs 0a, 0b, 0d The TAPI topology describes nodes
information (if exposed) TR-547 [32] and links. The nodes are logical
entities providing switching
capabilities and typically cover
multiple layer-networks. The links
describe how nodes are connected
at a given layer network. A link in a
layer network is supported by a
connection in the next lower layer
network. Provisioning a connectivity
service leads to the creation of a
connection.
The following use cases allow

together the discovery of topology:
UC 0a (Context & Service Interface
Points discovery), UC 0b (Topology
discovery) and UC 0d (Multi-domain
OTN interdomain links discovery).
The discovered topology can be

mapped to the logical inventory
discovered in UC 0c.
Configure notifications ONF TR-547: ONF TR-547 [32]:
(if supported) TR-547 [32] UC 13a UC 13a defines the general
UCs 14a, 15a procedure for subscription to
ONF notifications. The use cases 14a and
TR-548 [33] TR-548: 15a define parameters for the
UCs ST-0.2, ST-5.1 specific subscriptions.
ONF TR-548 [33]:

The definitions in the informative
UC ST-5.1 also apply for changes to
the topology. Streams can be
discovered and selected by the
service consumer as per UC ST-0.2.
ETSI
76 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications about ONF TR-547: ONF TR-547 [32]:

topology changes TR-547 [32] UC 13a To receive notifications, a prior
(if supported) UCs 14a, 15a subscription based on UC 13a is
ONF required. UC 13a also defines the
TR-548 [33] TR-548: procedure for notifications delivery.
UCs ST-1.1, ST-1.2 The notifications relate to insertion /
UCs ST-3.1, ST-2.1 removal of topology objects (UC 14a)
UC ST-5.1 or status changes of these (15a).
UCs ST-5.2, ST-5.3
ONF TR-548 [33]:
For some cases, ONF TR-548 [33]
defines concrete informative use
cases how to provide streams of
such changes: UC ST-5.2 relates to
changes triggered by the execution
of provisioning use cases (UCs 1x,
2x, 3x) and UC ST-5.3 relates to
changes triggered by the deletion
Use Case (UC 10). This assumes the
prior set-up of the streams by the
consumer executing UC ST-3.1 to
set up / manage the reception of the
streams and UC ST-2.1 to align with
the streams, and the producer
executing UCs ST-1.1 and ST-1.2 to
manage the production of the
streams.
lifecycle changes
(if exposed)
lifecycle changes
(if exposed)
Configure monitoring ONF TR-547 [32] UC 13a defines the general
TR-547 [32] UCs 13a, 13c procedure for subscription to
notifications.
ONF TR-548 [33]
TR-548 [33] see definition of fault events ONF TR-547 [32]:
service UC13c defines parameters for the
subscription to threshold crossing
alerts. The present version of TAPI
does not define how to configure the
actual thresholds. These additional
use cases will be available in the
next version of ONF TR-547 [32].
ONF TR-548 [33]:

It supports the streaming of threshold
crossing notifications as alarms (see
the definition of alarm streaming in
the fault events service).
ETSI
77 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications ONF TR-547 [32] ONF TR-547 [32]:

TR-547 [32] UCs 13a, 13c To receive notifications, a prior
UC 16b subscription based on UC 13a / UC
ONF 13c is required. UC 13a also defines
TR-548 [33] TR-548 [33] the procedure for notifications
see definition of fault events delivery. UC 16b defines notifications
service for threshold crossing alerts without
specifying the actual thresholds. In
other words, the PM metrics and
their threshold values are not
configurable in the present TAPI
version, while the threshold crossing
notification parameters can include
the PM metric and its value, which
crossed the threshold configured
outside TAPI.
ONF TR-548 [33]:

It supports the streaming of threshold
crossing notifications as alarms (see
the definition of alarm streaming in
the fault events service).
Provide streaming n/a The present version of TAPI does not
measurements define measurements streaming but
mentions live measurements and
periodic measurements as future
work in clauses 3.9.2.4 and 3.9.2.6 of
ONF TR-548 [33].
Configure batch n/a Use case mappings for performance
measurements data collection are not defined in the
present version of TAPI but will be
available in the next version of ONF
TR-547 [32].
Provide batch availability n/a The present version of TAPI does not
notifications define streaming of bulk
measurements but mentions it as
future work in clause 3.9.2.7 of
ONF TR-548 [33].
Get batch measurements TAPI SDK [34] Performance data are represented
as nodes embedded in the TAPI
YANG models [34].
Use case mappings for performance

data collection are not defined in the
present version of TAPI but will be
available in the next version of
ONF TR-547 [32].
Configure monitoring ONF TR-547: ONF TR-547 [32]:
TR-547 [32] UCs 13a, 13b UC 13a defines the general
procedure for subscription to
ONF TR-548: notifications. UC13b defines
TR-548 [33] UCs ST-0.2, ST-5.1 parameters for the subscription to
alarm event notifications.
ETSI
78 ETSI GS ZSM 008 V1.1.1 (2022-07)
ONF TR-548 [33]:

It allows the management service
producer to publish streams of
alarms as per informative UC ST-5.1.
These can be discovered and
selected by the service consumer as
per UC ST-0.2.
Provide notifications ONF TR-547: ONF TR-547 [32]:
TR-547 [32] UC 16a To receive notifications, a prior
subscription based on UC 13a /
ONF TR-548: UC13b is required. UC 13a also
TR-548 [33] UCs ST-3.2, ST-2.1 defines the procedure for
UC ST-5.1 notifications delivery. UC 16a defines
UCs ST-1.1, ST-1.2 notifications for alarm events.
ONF TR-548 [33]:

It defines in informative use case
ST-3.2 how to provide streams of
alarms. This assumes the prior
set-up of the streams by the
consumer executing UC 3.2 to set
up / manage the reception of the
alarm streams and UC ST-2.1 to
align with the streams, and the
producer executing UCs ST-1.1 and
ST-1.2 to manage the production of
the streams.
Query logs n/a
(if exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Query data n/a
Store data n/a
ETSI
79 ETSI GS ZSM 008 V1.1.1 (2022-07)
6.4.4 Transport domain based on Layer 2 / Layer 3 VPNs

The work done around L2 and L3 services within IETF is under the scope of the Operations and Management Area
Working Group.
For L2 VPNs, there are two main models: L2VPN Service Model (L2SM) and Layer 2 Virtual Private Network
(L2VPN) services. IETF RFC 8466 [42] defines an L2VPN Service Model (L2SM) YANG data model that can be used
between customers and service providers for ordering Layer 2 Virtual Private Network (L2VPN) services. L2NM
(draft-ietf-opsawg-l2nm [i.15]) complements the L2SM by creating a network-centric view of the service.
For L3 VPNs, there are also two main models: L3VPN Service Model (L3SM) and Layer 3 Virtual Private Network
(L3VPN) services. IETF RFC 8299 [39] defines an L3VPN Service Model (L3SM) YANG data model that can be used
between customers and service providers for ordering Layer 3 Virtual Private Network (L3VPN) services. L3NM (IETF
RFC 9182 [49]) complements the L3SM by creating a network-centric view of the service.
The "Operation" entries in table 6.4.4-1 assume that the RESTCONF protocol (see IETF RFC 8040 [38]) is used. The
path and JSON payload of the operation depend on the actual YANG model.
Table 6.4.4-1: Mapping of ZSM MnSs and IETF management interfaces for Layer 2 / Layer 3 VPNs
Referenced ZSM MnS Spec ref External organizations' Description / comment

+ capability APIs / operations
notifications
catalogue entry
Check deployment n/a
feasibility
Check and reserve n/a
(if supported)
Manage service lifecycle draft-ietf-opsawg-l2nm Operation: POST These models enable the
(instantiate service) [i.15] instantiation of L2NM, L2SM, L3NM
Data models: or L3SM services.
IETF RFC 8466 [42] L2NM: ietf-l2vpn-ntw [i.15]
L2SM: ietf-l2vpn-svc [42] Status fields allow to check the
IETF RFC 9182 [49] L3NM: ietf-l3vpn-ntw [49] administrative and operational
L3SM: ietf-l3vpn-svc [39] status of the service to validate if
IETF RFC 8299 [39] the service was created and what
is its status.
Manage service lifecycle draft-ietf-opsawg-l2nm Operation: PATCH Svc-bandwidth, svc-pe-to-ce-
(scale service) [i.15] bandwidth and svc-ce-to-pe-
Data models: bandwidth allow the definition of
IETF RFC 8466 [42] L2NM: ietf-l2vpn-ntw [i.15] the bandwidth in L2NM or L2SM
L2SM: ietf-l2vpn-svc [42] services.
IETF RFC 9182 [49] L3NM: ietf-l3vpn-ntw [49]
L3SM: ietf-l3vpn-svc [39] Svc-output-bandwidth, svc-input-
IETF RFC 8299 [39] bandwidth, svc-pe-to-ce-bandwidth
and svc-ce-to-pe-bandwidth allow
the definition of the bandwidth in
L3NM or L3SM services.
Manage service lifecycle draft-ietf-opsawg-l2nm Operation: PATCH
(configure service) [i.15]
Data models:
L2SM: ietf-l2vpn-svc [42]
IETF RFC 8299 [39]
ETSI
80 ETSI GS ZSM 008 V1.1.1 (2022-07)
Manage service lifecycle draft-ietf-opsawg-l2nm Operation: PATCH The admin-status parameter allows
(activate service) [i.15] to activate the service.
Data models:
L3NM: ietf-l3vpn-ntw [49]
Manage service lifecycle draft-ietf-opsawg-l2nm Operation: PATCH The admin-status parameter allows
(deactivate service) [i.15] to deactivate the service.
Data models:
L2NM: ietf-l2vpn-ntw [i.15]
L3NM: ietf-l3vpn-ntw [49]
Manage service lifecycle draft-ietf-opsawg-l2nm Operation: DELETE
(terminate service) [i.15]
Data models:
IETF RFC 8299 [39]
Manage subscriptions to IETF RFC 8639 [43] Operation: POST / PATCH / The details of subscribe / notify are
lifecycle changes DELETE described in clause 6.4.1.
(if exposed) IETF RFC 8641 [44]
IETF RFC 8650 [45] subscription: related to network resources and
ietf-subscribed-notifications services will allow to receive
draft-ietf-opsawg-l2nm [43] notifications about new / modified /
[i.15] ietf-yang-push [44] removed service instances and
resources.
IETF RFC 8466 [42] Data models for subscribed
content:
lifecycle changes described in clause 6.4.1.
IETF RFC 8641 [44]
IETF RFC 8650 [45] notifications related to a
subscription can be obtained using
GET from a stream resource with
an address that has been provided
by the service producer upon
subscription.
Test resources n/a
Query tests n/a
ETSI
81 ETSI GS ZSM 008 V1.1.1 (2022-07)

Query inventory of draft-ietf-opsawg-l2nm Operation: GET Information about the service
available resources (if [i.15] instances can be obtained using
exposed) Data models: the GET method.
IETF RFC 8299 [39]
Configure notifications (if IETF RFC 8639 [43] Operation: POST / PATCH / The details of subscribe / notify are
supported) DELETE described in clause 6.4.1.
IETF RFC 8641 [44]
IETF RFC 8650 [45] subscription: related to network resources and
ietf-subscribed-notifications services will allow to receive
draft-ietf-opsawg-l2nm [43] notifications about new / modified /
[i.15] ietf-yang-push [44] removed service instances and
resources.
IETF RFC 8466 [42] Data models for subscribed
content:
inventory changes (if described in clause 6.4.1.
subscription.
Query topology IETF RFC 8944 [47] Operation: GET IETF RFC 8944 [47] defines a data
information (if exposed) model for Layer 2 network
IETF RFC 8346 [41] Data models: topologies.
ietf-l2-topology [47]
draft-ietf-opsawg-sap ietf-l3-unicast-topology [41] IETF RFC 8346 [41] defines a data
[i.16] ietf-sap-ntw [i.16] model for Layer 3 network
topologies.
Draft-ietf-opsawg-sap [i.16] defines

the Service Attachment Points that
are the network reference points to
network services (L2SM, L2NM,
L3SM, L3NM).
Configure notifications (if IETF RFC 8639 [43] Operation: POST / PATCH / The details of subscribe / notify are
supported) DELETE described in clause 6.4.1.
IETF RFC 8641 [44]
Data models for Subscriptions to change
IETF RFC 8650 [45] subscription: notifications related to topology
ietf-subscribed-notifications data stores will allow to receive
IETF RFC 8944 [47] [43] notifications about topology
ietf-yang-push [44] changes.
IETF RFC 8346 [41]
Data models for subscribed
draft-ietf-opsawg-sap content:
[i.16] ietf-l2-topology [47]
ietf-l3-unicast-topology [41]
ietf-sap-ntw [i.16]
ETSI
82 ETSI GS ZSM 008 V1.1.1 (2022-07)
topology changes (if described in clause 6.4.1.
subscription creation.
exposed)

exposed)
Configure monitoring n/a IETF RFC 8641 [44] only supports
periodic and change notifications,
but no threshold crossing
notifications.
Configure measurements IETF RFC 8639 [43] Operation: POST / PATCH / Draft-ietf-opsawg-yang-vpn-
DELETE service-pm [i.17] defines a model
IETF RFC 8641 [44] for Performance Monitoring (PM) of
Data models for both networks and VPN services
IETF RFC 8650 [45] subscription: that can be used to monitor and
ietf-subscribed-notifications manage network performance on
draft-ietf-opsawg- [43] the topology at higher layer or the
yang-vpn-service-pm ietf-yang-push [44] service topology between VPN
[i.17] sites.
content: The details of subscribe / notify are
ietf-network-vpn-pm [i.17] described in clause 6.4.1.
Subscriptions to periodic
notifications related to the PM
model elements in [i.17] will allow
to receive at regular intervals
notifications that carry the current
values of a set of performance
metrics selected at the time of
subscription.
Provide streaming IETF RFC 8639 [43] Operation: GET The details of subscribe / notify are
measurements described in clause 6.4.1.
IETF RFC 8641 [44]
subscription.
Configure batch n/a
measurements
ETSI
83 ETSI GS ZSM 008 V1.1.1 (2022-07)

notifications
Get batch measurements draft-ietf-opsawg- Operation: GET IETF does not provide a
yang-vpn-service-pm mechanism for batch measurement
[i.17] Data model: collection.
ietf-network-vpn-pm [i.17]
However, the current value of all
PM metrics defined in [i.17] can be
fetched at any time.
Configure monitoring IETF RFC 8639 [43] Operation: POST / PATCH / IETF RFC 8466 [42] defines an
DELETE object called "fault-alarm-defect-
IETF RFC 8641 [44] type" to monitor the errors in the
Data models for Layer 2 VPN. For Layer 3 VPNs,
IETF RFC 8650 [45] subscription: no alarm mechanism has been
ietf-subscribed-notifications defined.
IETF RFC 8466 [42] [43]
ietf-yang-push [44] The details of subscribe / notify are
described in clause 6.4.1.
content: Subscriptions to change
L2SM: ietf-l2vpn-svc notifications related to the "fault-
alarm-defect-type" object allow to
receive alarm-related notifications.
Provide notifications IETF RFC 8639 [43] Operation: GET The details of subscribe / notify are
described in clause 6.4.1.
IETF RFC 8641 [44]
subscription creation.
Query logs n/a
exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Query data n/a
Store data n/a
6.4.5 Transport slices

The present clause describes the IETF approach of integrating the management of transport slices (also known as IETF
network slices) with E2E-level management entities. Transport slices are integrated with other network domains, based
data models specified by the IETF. The protocols that work on data instances based on the model are typically not
tightly specified.
ETSI
84 ETSI GS ZSM 008 V1.1.1 (2022-07)
With the increase of dynamism and complexity introduced into transport by network slice management, standards are
being under development in the IETF to manage transport slices (called "IETF network slices") using interfaces defined
in draft-ietf-teas-ietf-network-slices [i.6]. IETF is defining the NSC-NBI, a north-bound interface exposed by the IETF
Network Slice Controller (NSC) towards E2E management entities such as the ZSM E2E service management domain.
That interface allows to request and monitor IETF Network Slices. IETF is taking a model-driven approach (see draft-
ietf-teas-ietf-network-slice-nbi-yang [i.7]) for that interface relying on YANG ([35] and [37]) where the data model for
the domain NBI is specified. The protocol used to communicate the data structures is left unspecified, but some possible
protocols including NETCONF [36], RESTCONF [38] and gRPC [i.5] / gNMI [i.4] are mentioned.
The main focus in the model is on the orchestration (create, read, update, delete) of IETF slices based on the instances
of the IETF slice data model in [i.7] and on monitoring of a limited set of performance measurements. The monitoring
of changes to nodes in the model is implementation specific.
Table 6.4.5-1: Mapping of ZSM MnSs and IETF management interfaces for transport slices
Referenced ZSMMnS + Spec ref External organizations' Description / comment

notifications
catalogue entry
Check deployment n/a Support for feasibility check is not
feasibility defined in [i.6] but listed as an open
Check and reserve n/a issue.
(if supported)
Manage service lifecycle draft-teas-ietf- Creation of a model node Creation of a new transport slice
(instantiate service) network-slice- node according to the defined data
nbi-yang [i.7] model instantiates a new IETF slice
service instance. The protocol used
for this request is unspecified.
(scale service)
Manage service lifecycle draft-teas-ietf- Update of a model node Updating of a transport slice node
(configure service) network-slice- according to the defined data model
nbi-yang [i.7] configures an IETF slice service
instance. The protocol used for this
request is unspecified.
Manage service lifecycle draft-teas-ietf- Update of the "admin-enabled" Setting the "admin-enabled" property
(activate service) network-slice- property of a model node of a transport slice node to "true"
nbi-yang [i.7] activates an IETF slice service
Manage service lifecycle draft-teas-ietf- Update of the "admin-enabled" Setting the "admin-enabled" property
(deactivate service) network-slice- property of a model node of a transport slice node to "false"
nbi-yang [i.7] deactivates an IETF slice service
Manage service lifecycle draft-teas-ietf- Deletion of a model node Deletion of a transport slice node
(terminate service) network-slice- according to the defined data model
nbi-yang [i.7] terminates an IETF slice service
Manage subscriptions to draft-teas-ietf- Subscribe model changes Using a protocol that is not specified
lifecycle changes (if network-slice- in draft-ietf-teas-ietf-network-slices
exposed) nbi-yang [i.7] [i.6] and optional to implement, the
E2E service management domain
can subscribe to notifications related
to the content of model nodes that
represent transport slice instances.
See note.
ETSI
85 ETSI GS ZSM 008 V1.1.1 (2022-07)
Provide notifications about draft-teas-ietf- Notify model changes Using a protocol that is not specified
lifecycle changes network-slice- in draft-ietf-teas-ietf-network-slices
nbi-yang [i.7] [i.6] and optional to implement, the
can receive notifications related to
the content of model nodes. See
note.
Receiving notifications requires a

prior subscription.
Test resources n/a
Query tests n/a
Query inventory of draft-teas-ietf- Query the model Querying the content of nodes in the
available resources (if network-slice- data model that represent transport
exposed) nbi-yang [i.7] slices, including "network-slice"
nodes. The protocol used for
querying is unspecified.
Configure notifications (if draft-teas-ietf- Subscribe model changes Using a protocol that is not specified
supported) network-slice- in draft-ietf-teas-ietf-network-slices
represent transport slices, including
"network-slice" nodes. See note.
inventory changes (if network-slice- in draft-ietf-teas-ietf-network-slices
supported) nbi-yang [i.7] [i.6] and optional to implement, the
the change of model nodes that
represent transport slices, including
"network-slice" nodes. See note.

prior subscription.
Query topology draft-teas-ietf- Query the model Querying the content of nodes in the
information (if exposed) network-slice- data model that represent transport
nbi-yang [i.7] slice topology, including
"ns-endpoint" and "ns-connection"
nodes. The protocol used for
querying is unspecified.
Configure notifications draft-teas-ietf- Subscribe model changes Using a protocol that is not specified
(if supported) network-slice- in draft-ietf-teas-ietf-network-slices
represent transport slice topology,
including "ns-endpoint" and
"ns-connection" nodes. See note.
topology changes network-slice- in draft-ietf-teas-ietf-network-slices
(if supported) nbi-yang [i.7] [i.6] and optional to implement, the
the change of model nodes that
represent transport slice topology,
including "ns-endpoint" and "ns-
connection" nodes. See note.

prior subscription.
ETSI
86 ETSI GS ZSM 008 V1.1.1 (2022-07)

lifecycle changes
(if exposed)
lifecycle changes
(if exposed)
Configure measurements draft-teas-ietf- Subscribe model content Using a protocol that is not specified
network-slice- in draft-ietf-teas-ietf-network-slices
represent monitored performance
measurements. See note.
Provide streaming draft-teas-ietf- Notify model content Using a protocol that is not specified
measurements network-slice- in draft-ietf-teas-ietf-network-slices
the content of model nodes that
represent monitored performance
measurements.
Receiving streaming measurements

requires a prior subscription.
Configure batch n/a
measurements
notifications
Query logs n/a
exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Cross-domain data services: Data persistence service
Query data n/a
Store data n/a
NOTE: By design the model can support subscriptions and notifications related to the content of every model node.
ETSI
87 ETSI GS ZSM 008 V1.1.1 (2022-07)
6.5 Cloud domain

Table 6.5-1: Mapping of ZSM MnSs and NFV MANO interfaces in Cloud domain
Referenced ZSMMnS + Spec ref External Description / comment
capability organizations'
APIs / operations
Manage service models ETSI GS NFV-IFA 013 [3] Query NSD Info
Upload NSD
Query VNF Package

Info
Upload VNF Package
Query PNFD Info
Upload PNFD
Provide catalogue change ETSI GS NFV-IFA 013 [3] NsdOnBoardingNotific Subscriptions are needed to
notifications ation receive notifications.
NsdChangeNotification "NsdOnBoardingNotification",
"PnfdOnBoardingNotification" and
NsdDeletionNotificatio "VnfPackageOn-
n BoardingNotification" provide infor-
mation related to a PNFD / NSD /
PnfdOnBoardingNotific VNF package that has been
ation onboarded.
PnfdDeletionNotificatio "NsdChangeNotification" and "Vnf-

n PackageChangeNotification"
provide information about changes
VnfPackageOnBoardin to an NSD or VNF Package, or the
gNotification deletion of a VNF package.
"PnfdDeletionNotification" and
VnfPackageChangeNo "NsdDeletionNotification" provide
tification information about the deletion of an
NSD or PNFD Package.
catalogue entry
Check deployment ETSI GS NFV-IFA 013 [3] Create NS Identifier When feasibility check is
feasibility performed, Instantiate NS uses the
Instantiate NS ID of a (temporary) NS instance
Check and reserve ETSI GS NFV-IFA 013 [3] Create NS Identifier created by Create NS Identifier, so
(if supported) Instantiate NS is used with Create
Instantiate NS NS Identifier.
Instantiate NS allows to request a

feasibility check with or without
reservation.
Manage service lifecycle ETSI GS NFV-IFA 013 [3] Instantiate NS
(instantiate service)
Manage service lifecycle ETSI GS NFV-IFA 013 [3] Scale NS Even though Update NS can also
(scale service) be used for NS scaling, the use of
Update NS Scale NS is preferred for that
purpose.
Manage service lifecycle ETSI GS NFV-IFA 013 [3] Update NS
(configure service)
(activate service)
(deactivate service)
ETSI
88 ETSI GS ZSM 008 V1.1.1 (2022-07)
Manage service lifecycle ETSI GS NFV-IFA 013 [3] Terminate NS

(terminate service)
Execute workflow ETSI GS NFV-IFA 013 [3] Scale NS
Update NS
Heal NS
Manage subscriptions to ETSI GS NFV-IFA 013 [3] Subscribe (NS LCM
lifecycle changes (if interface)
exposed)
Terminate subscription
(NS LCM interface)
Provide notifications about ETSI GS NFV-IFA 013 [3] NsLcmOperationOccur Subscriptions are needed to
lifecycle changes renceNotification receive notifications.
"NsLcmOperationOccurrenceNotifi
cation" provides information about
an NS LCM operation and the
changes it has performed on the
NS instance.
Test resources n/a
Query tests n/a
Query inventory of ETSI GS NFV-IFA 013 [3] Query NS "Query NS" allows to read
available resources (if information related to the current
exposed) Get Operation Status inventory.
"Get Operation Status" allows to

read inventory changes by an
operation.
Configure notifications (if ETSI GS NFV-IFA 013 [3] Subscribe (NS LCM
supported) interface)
(NS LCM interface)
Provide notifications ETSI GS NFV-IFA 013 [3] NsLcmOperationOccur Subscriptions are needed to
about inventory changes renceNotification receive notifications.
(if supported)
cation" provides information of
inventory changes performed by a
finished NS LCM operation.
Query topology ETSI GS NFV-IFA 013 [3] Query NS "Query NS" allows to read
information (if exposed) information related to the current
Get Operation Status topology.
"Get Operation Status" allows to

read topology changes performed
by an operation.
Configure notifications (if ETSI GS NFV-IFA 013 [3] Subscribe (NS LCM
supported) interface)
(NS LCM interface)
topology changes (if renceNotification receive notifications.
supported)
cation" provides information of
topology changes performed by a
finished NS LCM operation.
ETSI
89 ETSI GS ZSM 008 V1.1.1 (2022-07)

Manage subscription to ETSI GS NFV-IFA 013 [3] Subscribe (NS LCM
lifecycle changes (if interface)
exposed)
(NS LCM interface)
lifecycle changes renceNotification receive notifications.
(if exposed)
NsChangeNotification "NsLcmOperationOccurrenceNotifi
cation" provides information about
an NS LCM operation and the
changes it has performed on the
NS instance.
"NsChangeNotification" provides
information that a component of an
NS instance (VNF instance, PNF
instance, nested NS instance) is
being changed or has been
changed.
Configure monitoring ETSI GS NFV-IFA 013 [3] Create Threshold
Subscribe
(PM interface)
(PM interface)
Delete Threshold
Provide notifications ETSI GS NFV-IFA 013 [3] ThresholdCrossedNotif Subscriptions are needed to
ication receive notifications.
"ThresholdCrossedNotification"
provides information that a
performance measurement has
crossed a threshold.
measurements
Configure batch ETSI GS NFV-IFA 013 [3] Create PM Job
measurements
Subscribe (PM
interface)
(PM interface)
Delete PM Job
Provide batch availability ETSI GS NFV-IFA 013 [3] PerformanceInformatio Subscriptions are needed to
notifications nAvailableNotification receive notifications.
"PerformanceInformationAvailable
Notification" provides information
that a new batch of collected
performance information is
available and how it can be
retrieved.
ETSI
90 ETSI GS ZSM 008 V1.1.1 (2022-07)
Get batch measurements ETSI GS NFV-SOL 005 [5] PerformanceReport ETSI GS NFV-IFA 013 [3] does not
define the delivery of the
performance report. That can be
mapped with the GET operation on
the "Individual performance report"
resource as defined in the stage 3
(see clause 7.4.4 of ETSI
GS NFV-SOL 005 [5])
Configure monitoring ETSI GS NFV-IFA 013 [3] Subscribe
(FM interface)
(FM interface)
Provide notifications ETSI GS NFV-IFA 013 [3] AlarmNotification Subscriptions are needed to
receive notifications.
"AlarmNotification" provides
information related to an alarm.
Query logs ETSI GS NFV-IFA 031 [4] Service capability not ETSI GS NFV-IFA 031 [4] supports
mappable log collection, but it does not allow
to retroactively query logs.
Instead, it is assumed that log

collection is requested by the
service consumer in a subscribe /
notify pattern. This means that if
the E2E service management
domain is interested in obtaining
logging information, it needs to set
up log collection jobs during
service assurance set-up, and
proactively receive and store log
information once it is notified.
exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Query data n/a
Store data n/a
ETSI
91 ETSI GS ZSM 008 V1.1.1 (2022-07)
7 Gaps and commonalities

Table 7-1 provides a comparison of the different management domain NBIs, plus the TMF mapping, with respect to the
supported ZSM services / ZSM service capabilities. The entry "x" means the capability is supported, "-" means the
capability is not supported, and a number in parentheses means the capability is partially supported and details are given
in a note. The reader is reminded that this overview relates to management services that are exposed at the NBI of the
management domains towards the E2E service management domain. Absence of an MnS from this overview does not
necessarily mean that the related functionality is not available inside the domain, only that it is not exposed at the NBI.
Service catalogue management is supported in NFV, TMF and Fixed access which is derived from TMF. 3GPP and
Transport domains do not support it. In transport, the set of possible services is very limited; therefore, it is typically
"hardcoded" in the model itself.
Feasibility checking is enabled in NFV, TMF and Fixed access which is derived from TMF.
All types of management domains support the domain orchestration service, with the minimum set of creating and
terminating service instances supported in TAPI, and a larger variety of functionality supported in the other domain
types.
Service testing is only supported by TMF and Fixed access which is derived from TMF.
Obtaining inventory information is supported by all types of management domains. Obtaining topology information is
also widely supported, with the exception of TMF.
Virtualised resources lifecycle management is supported in NFV, in 3GPP and Fixed access which refer to NFV, and in
TMF (for any kind of resources).
For performance management the landscape is diverse. In most transport domain NBIs, basic support is available to
read performance information and to stream the values of performance measurements. The most complete PM support
is available in 3GPP, NFV and TMF support a subset. Fixed access and IETF-based OTN currently have no NBI
support for PM.
Fault management is also supported only in a subset of the domain NBIs, namely 3GPP, ONF-based OTNs, NFV and
TMF. L2 transport networks support FM in the NBI, but not L3 transport networks, IETF-based OTNs, transport slices
and Fixed access networks. In some domain types, security evets are supported that are reported using the same
mechanisms as reporting faults.
Log collection is not supported by standardized MnSs at the NBI, with the exception of some rudimentary support in
NFV. In current deployments, logging is the domain of software solutions rather than standards.
The management of service health issues is not supported in any of the NBIs analysed. This can be seen as an
automation-specific evolution of fault management.
Analytics is an area of ongoing standardization activities. First results of these activities are available in 3GPP.
The integration fabric services are strictly speaking not part of the domain NBIs but they allow the cross-domain
service communication and integration. De-facto software solutions dominate in this field, such as messaging
frameworks and service meshes. The same applies to the data persistence service. Different kinds of open-source
databases optimized for different use cases such as big data and time series are used in deployments to persist data of
different types.
Some of the gaps are in the process of being filled by work in progress in the different SDOs.
ETSI
92 ETSI GS ZSM 008 V1.1.1 (2022-07)
Table 7-1: Comparison of the services and capabilities provided by the different domain NBIs
Group Service Capability 3GPP Fixed Transport (6.4) NFV TMF

(6.2) (6.3) (6.5) (B.1)
OTN IETF OTN ONF L2 / L3 VPN T-Slices
Managed services catalogue Manage service models - x - (3) - - x x
management service
Provide catalogue change notifications - x - - - - x x
Request missing service catalogue entry - - - - - - - -
Feasibility check service Check deployment feasibility (1) x x - - - x x
Check and reserve (if supported) (1) - - - - - x -
Domain orchestration service Manage service lifecycle (instantiate) x x x x x x x x
Manage service lifecycle (scale) x - x - x - x x
Manage service lifecycle (configure) x x x - x x x x
Manage service lifecycle (activate) x x x (4) x x - x
Domain Orchestration
Manage service lifecycle (deactivate) x x x (4) x x - x

Manage service lifecycle (terminate) x x x x x x x x
Execute workflow - - - - - - x (9)
Manage subscriptions to lifecycle changes x x x x x x x x
Provide notifications about lifecycle changes x x x x x x x x
Testing service Manage test specifications - x - - - - - x
Test resources - x - - - - - x
Query tests - x - - - - - x
Domain inventory information Query inventory of available resources x x x x x x x x
service
Configure notifications x x x x x x x x
Provide notifications about inventory changes x x x x x x x x
Domain topology information Query topology information x x x x x x x -
service
Configure notifications x x x x x x x -
Provide notifications about topology changes x x x x x x x -
ETSI
93 ETSI GS ZSM 008 V1.1.1 (2022-07)

(6.2) (6.3) (6.5) B.1)
Virtualised resource lifecycle Manage subscriptions to lifecycle changes x x - - - - x x
Domain
Control
management service
Provide notifications about lifecycle changes x x - - - - x x
Performance events service Configure monitoring x - - x - - x x

Provide notifications x - - x - - x x
Performance measurements Configure measurements x - - - x x - -
streaming service
Domain Data Collection
Provide streaming measurements x - - - x x - -

Performance measurements Configure batch measurements x - - - - - x x
collection service
Provide batch availability notifications x - - - - - x x
Get batch measurements x - - (5) (6) - x x
Fault events service Configure monitoring x - - x (7) - x x
Provide notifications x - - x (7) - x x
Security events service Configure monitoring x - - - - - - x
Provide notifications x - - - - - - x
Log collection service Query logs - - - - - - (8) -
Analytics services derived from Configure analytics (2) - - - - - - -
Intelligence
Generic analytics service

Domain
Request analysis result (2) - - - - - - -

Health issue reporting service Configure service - - - - - - - -
Provide health issue notifications - - - - - - - -
ETSI
94 ETSI GS ZSM 008 V1.1.1 (2022-07)

(6.2) (6.3) (6.5) (B.1)
Management communication Manage channels - - - - - - - -
service
Integration Fabric
Manage subscriptions - - - - - - - -
Receive data - - - - - - - -
Provide data - - - - - - - -
Management services discovery Query service list - - - - - - - -
service
Get service info - - - - - - - -
Data persistence service Query data - - - - - - - -
CDS
Store data - - - - - - - -
NOTE 1: A use case and procedure of network slice subnet feasibility check with reservation are defined in clauses 5.1.21 and 7.14 of ETSI TS 128 531 [7]. There is no related
management service / API defined yet.
NOTE 2: This is work in progress. 3GPP Rel.17 includes the definition of the Management Data Analytics Service (MDAS). 3GPP TS 28.104 [i.3] defines requirements and the data
consumed for performing a set of standardized analytics use cases in the 3GPP management plane. It can import data from the Network Data Analytics Function (NWDAF)
(see ETSI TS 123 288 [i.2]) which allows requesting a set of pre-defined analytics for the control plane of the 3GPP Core domain.
NOTE 3: TAPI does not support a service catalogue service. However, the different provisioning use cases defined in sections 6.2 and 6.3 of ONF TR-547 [32] reflect the set of types
of managed services that can be instantiated.
NOTE 4: Administrative state is represented in the TAPI YANG models. However, administrative state provisioning is not covered by a use case in the present version of TAPI.
NOTE 5: Performance data are represented as nodes embedded in the TAPI YANG models [34]. Use case mappings for performance data collection are not defined in the present
version of TAPI but will be available in the next version of ONF TR-547 [32].
NOTE 6: IETF does not provide a mechanism for batch measurement collection. However, the current value of all PM metrics defined in IETF RFC 9182 [49] can be fetched at any
time.
NOTE 7: Only for L2, not for L3.
NOTE 8: ETSI GS NFV-IFA 031 [4] supports log collection, but it does not allow to retroactively query logs. Instead, it is assumed that log collection is requested by the service
consumer in a subscribe / notify pattern. This means that if the E2E service management domain is interested in obtaining logging information, it needs to set up log
collection jobs during service assurance set-up, and proactively receive and store log information once it is notified.
NOTE 9: With the operation of "Create service order" in TMF641 [26], service order entity which is used to fulfil the workflow execution is created. The "execute workflow" ZSM service
capability is applicable during the complete lifecycle of the service instance whereas TMF641 [26] is only applicable during service creation.
ETSI
95 ETSI GS ZSM 008 V1.1.1 (2022-07)
Annex A (normative):
Management services
A.1 Overview
This annex defines additional management services (see clause A.2) and additional capabilities of management services
that were defined in ETSI GS ZSM 002 [1] (see clause A.3).
A.2 Additional services
A.2.1 E2E services topology management service

The E2E services topology management service manages information about the topology of the services managed by
the E2E service management domain. This service is provided only to consumers inside the E2E service management
domain.
Each change to the topology is triggered as a side effect when the composition of the E2E service management domain
is modified.
The service is further detailed in table A.2.1-1.
Table A.2.1-1: Service definition

Service name E2E services topology management service
External visibility OPTIONAL
Service capabilities
Manage topology (M) Manage (create, read, update, delete) topology information.
A.3 Additional service capabilities
A.3.1 Domain inventory information service

This clause extends the domain inventory information service by additional capabilities.
Table A.3.1-1: Additional capabilities definition

Service name Domain inventory information service (see clause 6.5.5.2.5 of ETSI GS ZSM 002 [1])
Additional service capabilities
Configure notifications (C) Configure, optionally with a filter, when notifications about inventory changes are provided
and how they are transmitted. Additionally, it may be possible to select the information to
be provided in the notification. See note.
Shall be supported if the "Provide notifications about inventory changes" capability is

supported.
Provide notifications about Provide notifications about changes to the inventory.
inventory changes (O)
NOTE: If supported, such selection mechanism can be realized at various degrees of flexibility, e.g. selecting from
predefined sets of information items, or individually selecting the information items to include.
ETSI
96 ETSI GS ZSM 008 V1.1.1 (2022-07)
A.3.2 Domain topology information service

This clause extends the domain topology information service by additional capabilities.

Service name Domain topology information service (see clause 6.5.5.2.7 of ETSI GS ZSM 002 [1])
Configure notifications (C) Configure, optionally with a filter, when notifications about topology changes are provided
and how they are transmitted. Additionally, it may be possible to select the information to
be provided in the notification. See note.
Shall be supported if the "Provide notifications about topology changes" capability is

supported.
Provide notifications about Provide notifications about changes to the topology.
topology changes (O)
NOTE: If supported, such selection mechanism can be realized at various degrees of flexibility, e.g. selecting from
predefined sets of information items, or individually selecting the information items to include.
A.3.3 Managed services catalogue management service

This clause extends the Managed services catalogue management service in the management domain by additional
capabilities.

Service name Managed services catalogue management service
(see clause 6.5.5.2.3 of ETSI GS ZSM 002 [1])
Request missing service Inform the management domain that a service consumer is intending to consume a
catalogue entry (O) particular managed service from it, for which no entry in the service catalogue exists. If the
management domain or its owner reacts to this request it is expected that a service
catalogue entry related to the managed service mentioned in the request will be made
available, and the management domain will be enabled to create instances of that service.
ETSI
97 ETSI GS ZSM 008 V1.1.1 (2022-07)
Annex B (informative):
Further northbound interfaces
B.1 Domain northbound interfaces specified by TMF

Open API
Table B.1-1 shows the lists of interfaces defined by TMF Open API which can fulfil capabilities of ZSM management
services in Radio access, Core, Transport and Fixed access management domains involved in executing E2E service
lifecycle management procedures defined in clause 5.
Table B.1-1: Mapping of ZSM MnSs and TMF Open API
Referenced ZSMMnS + Spec ref External organizations' Description / comment

Manage service models TMF633 [22] Service Catalog Management
API
Provide catalogue change TMF633 [22] Service Catalog Management
notifications API
catalogue entry
Check deployment TMF645 [28] Service Qualification
feasibility Management API
Check and reserve n/a
Manage service lifecycle TMF641 [26] Service Ordering Management With the operation of "Create service
(instantiate service) TMF640 [25] API order" in TMF641, it is possible to
TMF638 [23] Service Activation and create a service order entity.
Configuration Management API
Service Inventory Management With the "Create Service" in TMF640
API or TMF638, it is possible to create a
new service instance.
Manage service lifecycle TMF640 [25] Service Activation and With the attribute
(scale service) TMF638 [23] Configuration Management API "ServiceCharacteristic" of "Patch
Service Inventory Management Service" in TMF640 or TMF638, it is
API possible to scale the service
instance.
Manage service lifecycle TMF640 [25] Service Activation and With the "Patch Service" in TMF640
(configure service) TMF638 [23] Configuration Management API or TMF638, it is possible to configure
Service Inventory Management the service instance.
API
(activate service) TMF638 [23] Configuration Management API or TMF638, it is possible to activate
API
(deactivate service) TMF638 [23] Configuration Management API or TMF638, it is possible to
Service Inventory Management deactivate the service instance.
API
ETSI
98 ETSI GS ZSM 008 V1.1.1 (2022-07)
Manage service lifecycle TMF640 [25] Service Activation and With the "Delete Service" in TMF640
(terminate service) TMF638 [23] Configuration Management API or TMF638, it is possible to terminate
API
Execute workflow TMF641 [26] Service Ordering Management With the operation of "Create service
API order" in TMF641, service order
entity which is used to fulfill the
workflow execution is created.
The "execute workflow" ZSM service

capability is applicable during the
complete lifecycle of the service
instance whereas TMF641 is only
applicable during service creation.
Manage subscriptions to TMF640 [25] Service Activation and
lifecycle changes (if TMF638 [23] Configuration Management API
exposed) Service Inventory Management
API
Provide notifications about TMF640 [25] Service Activation and
lifecycle changes TMF638 [23] Configuration Management API
API
Manage test specifications TMF653 [29] Service Test Management API
Test resources TMF653 [29] Service Test Management API
Query tests TMF653 [29] Service Test Management API
Query inventory of TMF638 [23] Service Inventory Management
available resources (if API
exposed)
Configure notifications (if TMF638 [23] Service Inventory Management
supported) API
Provide notifications TMF638 [23] Service Inventory Management
about inventory changes API
(if supported)
Query topology n/a
information (if exposed)
Configure notifications (if n/a
supported)
topology changes (if
supported)
Manage subscriptions to TMF664 [31] Resource Function Activation and
lifecycle changes (if Configuration API
exposed)
Provide notifications about TMF664 [31] Resource Function Activation and
lifecycle changes (if Configuration API
exposed)
Configure monitoring TMF642 [27] Alarm Management API TMF657 Service Quality
TMF657 [30] and Management API can manage
Service Quality Management API performance threshold as part of
service level objective.
When quality degradation occurs, it
is notified to the consumer by
TMF642.
Therefore, TMF657 Service Quality

Management API and TMF642 Alarm
Management API are used together.
Provide notifications TMF642 [27] Alarm Management API
measurements
ETSI
99 ETSI GS ZSM 008 V1.1.1 (2022-07)

Configure batch TMF628 [21] Performance Management API
measurements
Provide batch availability TMF628 [21] Performance Management API
notifications
Get batch measurements TMF628 [21] Performance Management API
Configure monitoring TMF642 [27] Alarm Management API
Configure monitoring TMF642 [27] Alarm Management API
Query logs n/a
exposed)
Manage channels n/a
Receive data n/a
Provide data n/a
Query data n/a
Store data n/a
ETSI
100 ETSI GS ZSM 008 V1.1.1 (2022-07)
Annex C (informative):
Change History
Date Version Information about changes
Included contributions:
2019-10-23 0.1.0 - ZSM(19)000491r3_ZSM008_Description_of_optimization_in_LCM
- ZSM(19)000516r1_ZSM008_-_Clause_4__lifecycle_management
2019-12-02 0.1.1 - ZSM(19)000574r2_ZSM008_Proposal_for_Mapping_to_scenarios_and_require
ments
2020-01-21 0.1.3 - ZSM(19)000498r4_ZSM008_5_2_Communication_patterns.docx
- ZSM(19)000497r3_ZSM008_4_2_Relation_to_other_functions.docx
- ZSM(20)000158r1_ZSM008__4_1_Introduction_of_lifecycle_management_ope
rations
rations
- ZSM(20)000160_ZSM008__4_1_Introduction_of_lifecycle_management_opera
tions
- ZSM(20)000163_ZSM008__4_2_3_Relationship_to_fault_management_functi
onaliti (EN included in clause 5.3 as the original clause does not exist anymore
after restructuring)
- ZSM(20)000235r1_ZSM008__Annex_A_Collection_of_ideas_for_ZSM008_topi
cs
- ZSM(20)000248r1_ZSM008_ToC_update
2020-07-15 0.2.0 - ZSM(20)000249r2_ZSM008__4_1_Introduction_of_lifecycle_management_ope
rations
rations
- ZSM(20)000252r2_ZSM008_clause_4_Overview
- ZSM(20)000254_ZSM008__4_3_Mapping_to_scenarios_and_requirements
- ZSM(20)000272_ZSM008_terminology_fixes_
Editorials:
- Aligned the spelling of "cross-domain" and the consistent use of the term
"cross-domain service lifecycle management"
- Dropped empty annexes and renumbered the remaining ones
- Sorted and renumbered the references
- Various paragraph formatting alignments.
- ZSM(20)000280_ZSM008_clause_1_Scope
- ZSM(20)000281r2_ZSM008_Onboarding_process
- ZSM(20)000282r3_ZSM008_Service_instantiation_process
- ZSM(20)000283r2_ZSM008_Service_activation_process
- ZSM(20)000284r2_ZSM008_Service_decommisioning_process
- ZSM(20)000297r2_ZSM008_Service_deactivation_process
- ZSM(20)000298r2_ZSM008_Service_configuration_process
2020-10-07 0.3.0
- ZSM(20)000334_ZSM008_A_3_Collection_of_ideas
- ZSM(20)000335_ZSM008_A_3_Collection_of_ideas
- ZSM(20)000344r2_ZSM008_Add_domain_NBIs_in_figure_4_2
- ZSM(20)000372r1_ZSM008_Fulfilment_Overview_subclause
Editorials:
- Added abbreviation NBI
- Consistent use of term "E2E service management domain"
- ZSM(20)000383r2_ZSM008_Service_inventory
- ZSM(20)000400r4_ZSM008_Service_quality_management
- ZSM(20)000470_ZSM008_Updates_of_flows
2020-11-23 0.4.0 - ZSM(20)000472_ZSM008_align_terminology_for_domain_services
- ZSM(20)000473r1_ZSM008_Moving_onboarding
Editorials:
- Aligned figure numbering
ETSI
101 ETSI GS ZSM 008 V1.1.1 (2022-07)

- ZSM(20)000382r4_ZSM008_Service_problem_management
- ZSM(20)000474r5_ZSM008_change_of_Fig_4-
1_Management_processes_and_related_te
- ZSM(20)000493r2_ZSM008_Service_assurance_tear-down
2021-01-22 0.5.0 - ZSM(20)000516r2_ZSM008_proposal_for_Clause_6_format_and_Annex
- ZSM(21)000032r2_ZSM008_Include_Mgmt_Service_Groups
Editorials:
- Numbering, references, typos.
- Removed duplicated paragraphs in clause 5.1.
- ZSM(21)000008r2_ZSM008_revised_service_deactivation_procedure
- ZSM(21)000041r1_ZSM008_applying_pattern_from_contribution_00032r2
2021-02-08 0.5.1
Editorials:
- Fixing Symbols and Terms clauses (clause 3)
- Replacing "NOT … nor" by "neither … nor" (clause 4)
- Fixing commas
- ZSM(21)000106_ZSM008_Rapporteur_s_clean-up_of_V_0_5_1
- ZSM(21)000040r1_ZSM008_service_producer-
2021-03-30 0.6.0 initiated_assurance_procedures_align.docx
Editorials:
- consistent formatting and use of plural in Preconditions / Postconditions
- ZSM(21)000037r1_ZSM008_removal_of_ENs
- ZSM(21)000105r1_ZSM008_inventory_alignment
- ZSM(21)000116r2_ZSM008_Add_mapping_to_clause_6_based_on_5_4_3_2_
and_5_4_4_2
- ZSM(21)000137r1_ZSM008_addressing_EN_regarding_assurance_set-
up_tear-down_on
2021-04-19 0.6.5 ZSM(21)000144r1_ZSM008_clause_6_update_template_with_services
- ZSM(21)000148_ZSM008_Modification_to_5_4_3
- ZSM(21)000149_ZSM008_Additional_Change_to_5_4_4
Editorials:
- Included PlantUML sources from the resources folder into this document for
processing with the PlantUML Word plugin V 3.4, see
https://plantuml.com/word
- ZSM(21)000115r4_ZSM008_Add_mapping_to_clause_6_based_on_5_4_2_2_
2_and_5_4_5
- ZSM(21)000136r1_ZSM008_addressing_EN_regarding__disassociation
- ZSM(21)000157r3_ZSM008_Additional_management_services
- ZSM(21)000158r2_ZSM008_onboarding_updates
- ZSM(21)000168_ZSM008_clean_up_notifications_in_clause_6
- ZSM(21)000177_ZSM008_testing_optional
- ZSM(21)000180_ZSM008_Add_TMF_mapping_on_sequences_related_to_dat
a_collecti
2021-06-07 0.7.0
- ZSM(21)000181_ZSM008_Add_TMF_mapping_on_sequences_related_to_ser
vice_PM_an
- ZSM(21)000182r2_ZSM008_Resolve_an_EN_of_clause_6
- ZSM(21)000193_ZSM008_global_of_use_of_term_service_instance
- ZSM(21)000200r2_ZSM008_Add_Deactivation_related_to_the_TMF_mapping
- ZSM(21)000201_ZSM008_Add_TMF_mapping_on_sequences_related_to_ser
vice_PM_an
Editorials:
- fixed a repetition of "the management domain" in bullet 9 of clause 5.3.2.2
ETSI
102 ETSI GS ZSM 008 V1.1.1 (2022-07)

- ZSM(21)000205r2_ZSM008_fixing_issue_introduced_by_136r1
- ZSM(21)000212r5_ZSM008_Add_NFV_mapping_on_onboarding_process
- ZSM(21)000213r3_ZSM008_Add_NFV_mapping_on_service_LCM
- ZSM(21)000214r3_ZSM008_Add_NFV_mapping_on_inventory_topology_man
agement
2021-07-21 0.7.5
- ZSM(21)000215r4_ZSM008_Add_NFV_mapping_on_information_collection_pr
ocess
- ZSM(21)000221r1_ZSM008_Apply_latest_table_format_to_6_3_to_6_6
- ZSM(21)000223_ZSM008__Text_modification_proposal_concerning_section_5
_3_3
- ZSM(21)000261_ZSM008_Modify_the_description_of_Table_6_6-1
- ZSM(21)000268_ZSM008_add_step_to_onboarding
- ZSM(21)000272_ZSM008_Editorial_Change_to_5_3_6
2021-09-13 0.8.0 - ZSM(21)000274r2_ZSM008_Additional_Change_to_5_3_7_and_Annex
- ZSM(21)000300_ZSM008_fixing_references
- ZSM(21)000301r2_ZSM008_NFV_mapping_fixes
- ZSM(21)000302r1_ZSM008_Completing_the_NFV_mapping
- ZSM(21)000307_ZSM008_addressing_NFV_domain_editor_s_note_on_notific
ations
2021-09-24 0.8.5
Editorials:
- Fixed wrong numbering in onboarding flow
- ZSM(21)000273r1_ZSM008_Modify_NFV_mapping_about_unsubscribe_opera
tion
- ZSM(21)000319r3_ZSM008_Clause_6_3GPP_mapping
- ZSM(21)000321_ZSM008_Fixes_to_NFV_mapping
- ZSM(21)000325r1_ZSM008_Fixes_to_Fig_4-
2_and_removal_of_some_ENs_in_clause_4
- ZSM(21)000329r1_ZSM008_Fixes_to_inventory_update_procedure
- ZSM(21)000339r4_ZSM008_Additional_Change_to_Service_deactivation
- ZSM(21)000341r4_ZSM008_Additional_Change_to_Service_activation
2021-11-22 0.9.0
- ZSM(21)000386_ZSM008_fix_condition_of_service_instantiation
- ZSM(21)000392r1_ZSM008_Add_NFV_mapping
- ZSM(21)000408_ZSM008_fixing_step_12_in_5_4_2_2_2
Editorials:
- Removed NOTEs in the references and merged statements with reference to
the related 3GPP spec directly into reference text for improved readability.
- Aligned use of "n/a" in clause 6.
- Minor editorial (missing blanks, wrong numbering, activate -> activated) in the
flows in 5.3.3 and 5.3.5.
- ZSM(21)000401r1_ZSM008_adding_cross-domain_aspect_to_analytics
- ZSM(21)000407r1_ZSM008_removing_Annex_A
- ZSM(21)000411r1_ZSM008_delete_ENs
ZSM(21)000415_ZSM008_resolve_EN_on_too_strict_error_condition
- ZSM(21)000416_ZSM008_provide_content_for_clause_6_1
2021-12-03 0.9.5 Editorials

- Swapped Annexes A and B to have stable references, as Annex A will be
deleted one day.
- Applied the following pattern consistently: In the flows clauses, all flow step
descriptions end with a dot and all entries in the list of services do not end with
a dot.
- Added step numbers for "Update E2E inventory" in clause 5.4.4.2 which was
the only place where it did not exist.
ETSI
103 ETSI GS ZSM 008 V1.1.1 (2022-07)

- ZSM(21)000409r2_ZSM008_Clause_6_BBF_mapping
- ZSM(21)000412r1_ZSM008_Revise_on_AnnexB_1
- ZSM(21)000413_ZSM008_address_EN_on_service_template
- ZSM(21)000414_ZSM008_resolving_EN_on_service_state
- ZSM(21)000421_ZSM008_fixes_to_flow_5_3_3_2
- ZSM(21)000422_ZSM008_remove_empty_models_clause
- ZSM(21)000425_ZSM008_resolving_ENs_on_NFV_mapping
2021-12-20 0.10.0 - ZSM(21)000439r1_ZSM008_deletion_of_further_ENs
- ZSM(21)000440_ZSM008_resolve_En_on_data_services
- ZSM(21)000442r1_ZSM008_resolve_EN_on_use_of_IF
Editorials:
- Added abbreviations "IFA", "API"
- Fixed the broken formatting in clauses 5.x
- Removed the placeholder for terms in clause 3.1
- Removed duplicate occurrence of the word "service" (multiple places)
- ZSM(21)000424_ZSM008_update_scope
- ZSM(22)000006_ZSM008_addressing_editorial_ENs
2022-01-25 0.11.0 - ZSM(22)000058r1_ZSM008_Resolving_of_Editors_Note_in_5_3_4
Editorials:
- changed year to 2022
- ZSM(22)000004_ZSM008_Clause_6_x_Transport_slice_mapping
- ZSM(22)000013r3_ZSM008_Update_TMF_Open_API_mapping_table
- ZSM(22)000053r4_ZSM008_updating_Section_6_4_Transport_Domain
- ZSM(22)000059_ZSM008_adding_missing_subscriptions
- ZSM(22)000074_ZSM008_EN_removal
ZSM(22)000079_ZSM008_Transport_clause_structure_update
2022-02-23 0.12.0
Editorials:
- Minor formatting changes and edits for consistency
- Added IETF RFC 9094 to the list of references as it was missing there, but
referenced from the text in CR 053r4
- Added "TBD" in all table cells in 6.4.2 not filled by CR 053r4
- Changes for consistency of references
- Added abbreviations OTN, TEAS, CCAMP, WG
- Added version, "work in progress" statement and URI to internet drafts
- ZSM(22)000100_ZSM008_Clause_6_Transport_Mapping_L2_L3
- ZSM(22)000101_ZSM008_Replacing_TBDs_fixed_access
- ZSM(22)000108_ZSM008_Clause_6_4_2_Minor_change_for_notification_API
_descri
- ZSM(22)000112_ZSM008_Replacing_TBDs_optical_transport
- ZSM(22)000113r1_ZSM008_Replacing_TBDs_3GPP
- ZSM(22)000114r1_ZSM008_Clause_6_Transport_mapping_TAPI
2022-03-21 0.13.0 - ZSM(22)000116_ZSM008_editorial_revise
- ZSM(22)000121_ZSM008_TMF633_domain_tables_fix
- ZSM(22)000122_ZSM008_Address_EN_in_NFV_table
- ZSM(22)000123_ZSM008_Removing_feasibility_check_in_6_4_3
Editorials:
- Removed clause 6.4.x which has provided a template for transport NBI. As the
set of transport NBIs is complete the template is no longer needed.
- Reordered the references
Proposed Stable draft.
2022-03-28 0.14.0
- ZSM(22)000002_ZSM008_clause_7_Gap_analysis
2022-04-30 0.14.1 Clean-up done by editHelp! and editorial changes by rapporteur.
Stable draft.
2022-05-03 0.15.0
ETSI
104 ETSI GS ZSM 008 V1.1.1 (2022-07)

- ZSM(22)000137_ZSM008_review_clause_6_4_2_OTN_IETF_address_EN_on
_eth_topolo
- ZSM(22)000138_ZSM008_review_clause_6_4_align_IETF_notifications
- ZSM(22)000140_ZSM008_review_update_references
- ZSM(22)000146_ZSM008_review_clause_6_4_2_OTN_IETF_remove_path
- ZSM(22)000147_ZSM008_review_clause_1
- ZSM(22)000148r1_ZSM008_review_clause_4
- ZSM(22)000149r1_ZSM008_review_clause_5_1
- ZSM(22)000150_ZSM008_review_clause_5_2
- ZSM(22)000155r1_ZSM008_review_clause_6_4_2_OTN_IETF_update_on_inv
entory
- ZSM(22)000159_ZSM008_review_clause_5_3_2
Editorials:
- Corrected wrong step number and wrong use of plural in 5.4.3.2.2
- Corrected wrong use of singular in 5.4.3.2.1
- Aligned the start of all text lines flow diagrams to be lowercase
Final draft
- ZSM(22)000156r2_ZSM008_review_clause_6
- ZSM(22)000157_ZSM008_review_clause_7
- ZSM(22)000160_ZSM008_review_annex_B
- ZSM(22)000161_ZSM008_review_clause_5_3_3_to_5_3_6
- ZSM(22)000163r2_ZSM008_review_clause_5_4_1_and_5_4_2
- ZSM(22)000165r1_ZSM008_review_clause_5_4_4
- ZSM(22)000166r1_ZSM008_review_clause_5_4_5
- ZSM(22)000186_ZSM008_addressing_rapporteur_s_note
- ZSM(22)000190_ZSM008_adding_missing_scale
2022-05-18 0.16.0 - ZSM(22)000191r2_ZSM008_small_changes
- ZSM(22)000196_ZSM008_Fixes_to_service_quality_management_and_servic
e_probl
- ZSM(22)000207_ZSM008_consistent_naming_of_integration_fabric
- ZSM(22)000219_ZSM008_align_clause_5_4_3_with_changes_in_5_4_4_intro
duced_b
- ZSM(22)000220_ZSM008_error_handling_general_statement
- ZSM(22)000221_ZSM008_3GPP_feasibility_checks
- ZSM(22)000222_ZSM008_Preconditions_consistency
Editorials:
- Updated Internet Drafts to latest version
- Removed yellow mark-up
- Added "skin rose" to all UML diagrams to cater for new PlantUML version
- Reformatted selected UML diagrams to optimize font size
ETSI
105 ETSI GS ZSM 008 V1.1.1 (2022-07)
History
Document history
V1.1.1 July 2022 Publication
ETSI

Gs ZSM008v010101p

Uploaded by

Copyright:

Available Formats

Gs ZSM008v010101p

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gs ZSM008v010101p

Uploaded by

Copyright:

Available Formats

ETSI GS ZSM 008 V1.1.

Zero-touch network and Service Management (ZSM);

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B

Notice of disclaimer & limitation of liability

5.4.2.3 Related management services ............................................................................................................... 39

Annex B (informative): Further northbound interfaces .....................................................................97

Intellectual Property Rights

Modal verbs terminology

2.1 Normative references

[32] ONF TR-547: "TAPI Reference Implementation Agreement", Version 1.1.

NOTE: Available at https://opennetworking.org/wp-content/uploads/2021/12/TR-547-

NOTE: Available at https://opennetworking.org/wp-content/uploads/2021/12/TR-548-

[34] ONF Transport API SDK Version 2.1.3.

NOTE: Available at https://github.com/OpenNetworkingFoundation/TAPI/releases/tag/v2.1.3.

[36] IETF RFC 6241: "Network Configuration Protocol (NETCONF)".

[38] IETF RFC 8040: "RESTCONF Protocol".

[43] IETF RFC 8639: "Subscription to YANG Notifications".

2.2 Informative references

[i.4] draft-openconfig-rtgwg-gnmi-spec: Shakir, R. et al.: "gRPC Network Management Interface

NOTE: Available at https://datatracker.ietf.org/doc/html/draft-openconfig-rtgwg-gnmi-spec-01.

NOTE: Available at http://grpc.io.

[i.6] draft-ietf-teas-ietf-network-slices: "Framework for IETF Network Slices", Internet draft,

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/.

[i.7] draft-ietf-teas-ietf-network-slice-nbi-yang: "IETF Network Slice Service YANG Model", Internet

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/.

[i.9] draft-ietf-teas-yang-path-computation: "YANG Data Model for requesting Path Computation",

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation/.

[i.10] draft-ietf-ccamp-otn-tunnel-model: "YANG data model for tunnels in OTN TE Networks",

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-tunnel-model/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-tunnel-model/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-client-signal-yang/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/.

[i.14] draft-ietf-ccamp-eth-client-te-topo-yang: "A YANG Data Model for Ethernet TE Topology",

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-ccamp-eth-client-te-topo-yang/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/.

NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/.

3 Definition of terms, symbols and abbreviations

domain service: service that is managed by a management domain

n/a not applicable

4 Overview of cross-domain E2E service lifecycle

Roughly, the processes can be divided into:

Figure 4-1: Management processes during the lifecycle of E2E services

5 Cross-domain E2E service lifecycle management

In deployments, processes may be combined or split.

5.2 Service onboarding

5.2.2 Process: Service onboarding

5.2.2.2 Procedure flow

Figure 5.2.2.2-1: Service onboarding

The procedure, as illustrated in figure 5.2.2.2-1, consists of the following steps:

• The E2E service model has been onboarded.

5.2.2.3 Related management services

The following additional management services are used in this procedure:

5.3 Service fulfilment

5.3.2 Process: Service instantiation

5.3.2.2 Procedure flow

Figure 5.3.2.2-1: Service instantiation