ETSI GR ENI 003 V1.1.1 (2018-05)

Experiential Networked Intelligence (ENI); Context-Aware Policy Management Gap Analysis

DGR/ENI-003_context_aware_mgt

General Information

• Status: Published
• Publication Date: 02-May-2018
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 14-May-2018
• Completion Date: 03-May-2018

Standards Content (Sample)

ETSI GR ENI 003 V1.1.1 (2018-05)






GROUP REPORT
Experiential Networked Intelligence (ENI);
Context-Aware Policy Management Gap Analysis
Disclaimer
The present document has been produced and approved by the Experiential Networked Intelligence (ENI) 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.

---------------------- Page: 1 ----------------------
2 ETSI GR ENI 003 V1.1.1 (2018-05)



Reference
DGR/ENI-003
Keywords
management, network, policy management

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
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 2018.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GR ENI 003 V1.1.1 (2018-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 10
4 Introduction and Approach . 11
4.1 Base Assumptions . 11
4.2 Introduction to Policy Management . 11
4.2.1 Policy Definition . 11
4.2.2 Uses of Policy Management . 11
4.2.3 Managing and Controlling Behaviour Using Policy . 13
4.3 The Policy Continuum . 13
4.4 Types of Policy Paradigms . 15
4.4.1 Considered Policy Paradigms . 15
4.4.2 Imperative Policies . 15
4.4.3 Declarative Policies . 16
4.4.4 Intent Policies . 17
4.5 Policy Translation. 17
4.6 Model-Driven DSL. 18
4.7 Policy Conflict Detection and Remediation . 18
4.8 Types of Logic Supported by Policies . 19
4.9 The Ramifications of Changing Policies . 19
4.10 Other Types of Policies . 20
4.11 The MEF Policy-Driven Orchestration Project . 20
4.11.1 Introduction to MEF PDO . 20
4.11.2 The MEF PDO Information Model . 20
4.11.3 The MEF PDO Data Models. 22
4.11.4 The MEF PDO Architecture . 22
4.12 Approach Going Forward . 23
4.13 Key Features to be Compared in the Gap Analysis . 24
5 Analysis of the MEF PDO Model . 25
5.1 Characteristics of the MEF PDO Model . 25
5.1.1 Comprehensive Policy Information Model . 25
5.1.2 YANG Data Model . 26
5.1.3 Design Patterns Used in the MEF PDO . 26
5.1.4 Use of the Policy Continuum . 26
5.1.5 Extension of the MEF LSO RA . 27
5.2 Supported Policy Paradigms. 27
5.2.1 Imperative Policy . 27
5.2.1.1 Description . 27
5.2.1.2 Formal Model . 28
5.2.2 Declarative Policy . 28
5.2.2.1 Description . 28
5.2.2.2 Formal Model . 28
5.2.3 Intent Policy . 29
5.2.3.1 Description . 29
5.2.3.2 Formal Model . 29
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR ENI 003 V1.1.1 (2018-05)
5.2.3.3 Example 1: Application Developer . 29
5.2.3.4 Example 2: Application Developer/Architect/Business Level . 30
5.2.3.5 Business Level . 30
5.3 MEF PDO Model Features Comparison . 30
6 Analysis of the IETF SUPA Policy Model . 32
6.1 Characteristics of the IETF SUPA Policy Model . 32
6.1.1 Overview . 32
6.1.2 Support for the Policy Continuum . 33
6.1.3 Policy Entities . 33
6.1.3.1 Policy Entity Overview . 33
6.1.3.2 Policy Rule Structure Entities . 33
6.1.3.3 Policy Rule Component Structure Entities . 33
6.1.3.4 Policy Rule Metadata Entities . 33
6.1.4 Design Patterns . 34
6.2 Supported Policy Paradigms. 34
6.3 IETF SUPA Model Features Comparison . 34
7 Analysis of the TM Forum SID Policy Model . 35
7.1 Characteristics of the TM Forum SID Policy Model . 35
7.1.1 Overview . 35
7.1.2 Support for the Policy Continuum . 36
7.1.3 Policy Entities . 36
7.1.3.1 Policy Entity Overview . 36
7.1.3.2 Policy Content Entities . 36
7.1.3.3 Policy Specification Entities . 36
7.1.3.4 Policy Application Entities . 36
7.1.4 Design Patterns . 37
7.2 Supported Policy Paradigms. 37
7.2.1 Characteristics of the TM Forum SID Policy Model . 37
7.3 TM Forum SID Model Features Comparison . 37
Annex A: Authors & contributors . 39
Annex B: Bibliography . 40
Annex C: Change History . 41
History . 42


ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR ENI 003 V1.1.1 (2018-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Experiential Networked
Intelligence (ENI).
Modal verbs terminology
In the present document "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.
Introduction
A critical foundation of experiential networked intelligence is context- and situation-awareness. The present document
will analyse work done in various SDOs on policy management in general, and context-aware policy management
specifically, to determine what work can be reused from external SDOs, and what work needs to be developed in ENI.
When gaps are found on existing interfaces that have been developed by other SDOs and ISG ENI needs to reuse, then
the recommendation on how these gaps should be filled will be discussed in co-operation with the SDO that defined
these interfaces within Phase 1 and beyond. The requirements documented in the present document will be considered
during the architecture design work.

ETSI

---------------------- Page: 5 ----------------------
6 ETSI GR ENI 003 V1.1.1 (2018-05)
1 Scope
The present document analyses the work done in various SDOs and open source consortia on policy-based modelling.
This information will be used to develop a specification for a context-aware, policy-based management model and
architecture for enhancing the operator experience through the use of network intelligence.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
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] IETF draft-ietf-supa-generic-policy-info-model-03: "Generic Policy Information Model for
Simplified Use of Policy Abstractions (SUPA)", May 30, 2017.
[i.2] Strassner, J.: "Policy-Based Network Management", Morgan Kaufman, ISBN 978-1558608597,
September 2003.
[i.3] Liskov, B.H.: Wing, J.M., "A Behavioral Notion of subtyping", ACM Transactions on
Programming languages and Systems 16 (6): 1811 - 1841, 1994.
[i.4] Martin, R.C.: "Agile Software Development, Principles, Patterns, and Practices", Prentice-Hall,
2002, ISBN: 0-13-597444-5.
[i.5] Strassner, J.: editor: "MEF Technical Specification: Policy-Driven Orchestration", Call for
Comments v0.7, August 2017.
[i.6] Riehle, D.: "Composite Design Patterns", Proceedings of the 1997 Conference on Object-Oriented
Programming Systems, Languages and Applications (OOPSLA '97), ACM Press, 1997,
pages 218-228.
nd
[i.7] Davy, S., Jennings, B., Strassner, J.: "The Policy Continuum - A Formal Model", Proc. of the 2
Intl. IEEE Workshop on Modeling Autonomic Communication Environments (MACE), Multicon
Lecture Notes, No. 6, Multicon, Berlin, 2007, pages 65-78.
[i.8] Gamma, E., Helm, R., Johnson, R., Vlissides, J.: "Design Patterns - Elements of Reusable Object-
Oriented Software", Addison-Wesley, 1994, ISBN 0-201-63361-2.
[i.9] Strassner, J., de Souza, J.N., Raymer, D., Samudrala, S., Davy, S., Barrett, K.: "The Design of a
Novel Context-Aware Policy Model to Support Machine-Based Learning and Reasoning", Journal
of Cluster Computing, Vol 12, Issue 1, pages 17-43, March, 2009.
[i.10] MEF: "Lifecycle Service Orchestration Architecture: Reference Architecture and Framework",
MEF 55, March, 2016.
[i.11] MEF: "Service Orchestration Functionality", Call for Comments v0.7, August 2017.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR ENI 003 V1.1.1 (2018-05)
[i.12] MEF: "Policy Driven Orchestration Kickoff v3".
NOTE: Available at https://wiki.mef.net/display/MTA/PDO+Contributions.
[i.13] Dey, A.: "Providing architectural support for building context-aware applications". Ph.D. Thesis
(2000).
[i.14] MEF: "MEF Core Model", Call for Comments v0.95, January 2018.
[i.15] ETSI ISG ENI(17)0002-014r3: "Improved Operator Experience through Experiential Networked
Intelligence (ENI)", first edition, May 2017.
[i.16] IETF draft-ietf-supa-generic-policy-data-model-04: "Generic Policy Data Model for Simplified
Use of Policy Abstractions (SUPA)", June 18, 2017.
[i.17] Standford Encyclopedia of Philosophy: "Deontic Logic".
NOTE: Available at https://plato.stanford.edu/entries/logic-deontic/.
[i.18] Standford Encyclopedia of Philosophy: "Modal Logic".
NOTE: Available at https://plato.stanford.edu/entries/logic-modal/.
[i.19] IEFT: "Simplified Use of Policy Abstractions (supa)".
NOTE: Available at https://datatracker.ietf.org/wg/supa/about/.
[i.20] IETF draft-ietf-supa-policy-based-management-framework-03: "SUPA Policy-based Management
Framework", July 2017.
[i.21] IETF draft-cheng-supa-applicability-01: "Applicability of SUPA", March 2017.
[i.22] TM Forum: "Information Framework (SID); Common Business Entities - Policy", GB922 Policy,
Release 14.5.1, March 2015 (part of Release 17.0).
[i.23] TM Forum: "Information Framework (SID); Common Business Entities - Root Business Entities",
GB922 Root, Release 17.0.0, June 2017 (part of Release 17.0).
[i.24] Strassner, J.: "Using the MEF Core Model in ONAP", December 2017.
[i.25] MEF PDO CfC: "Policy-Driven Orchestration", v0.8, February 2018.
[i.26] MEF: "Lifecycle Service Orchestration (LSO): Reference Architecture and Framework", MEF 55,
March 2016.
[i.27] IETF RFC 3060: "Policy Core Information Model -- Version 1 Specification".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
abstraction: process of focusing on the important characteristics and behaviour of a concept, and realizing this as a set
of one or more elements in an information or data model
NOTE: When applied to modelling, it defines a generic set of characteristics and behaviours for a class that all of
its subclasses inherit.
action: set of operations that may be performed on a set of managed entities. It represents a transformation or
processing in the system being modelled
NOTE: An Action either maintains the state, or transitions to a new state, of the targeted managed entities. The
execution of an Action may be influenced by applicable attributes and metadata [i.25].
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR ENI 003 V1.1.1 (2018-05)
capability: set of features that are available from a component
NOTE: These features may, but do not have to, be used. All Capabilities should be announced through a
dedicated Interface.
condition: set of attributes, features, and/or values that are to be compared with a set of known attributes, features,
and/or values in order to determine what decision to make
data model: representation of concepts of interest to an environment in a form that is dependent on data repository,
data definition language, query language, implementation language, and/or protocol (typically, but not necessarily, all
five)
declarative policy: type of policy that uses statements to express the goals of the policy, but not how to accomplish
those goals
NOTE 1: State is not explicitly manipulated, and the order of statements that make up the policy is irrelevant.
NOTE 2: In the present document, Declarative Policy will refer to policies that execute as theories of a formal logic
[i.25].
event: anything of importance to the management system (e.g. a change in the system being managed and/or its
environment) occurring on a time-axis
formal logic: use of inference applied to the form, or content, of a set of statements
NOTE: The logic system is defined by a grammar that can represent the content of its sentences, so that
mathematical rules may be applied to prove whether the set of statements is true or false [i.25].
formal methods: set of mathematical theories, such as logic, automata, graph or set theory, and provide associated
notations for describing and analysing systems
functional block: modular unit that defines the properties, behaviour, and relationships of a part of a system. Some
functional blocks may also define relationships to other functional blocks outside of its enclosing system
imperative policy: type of policy that uses statements to explicitly change the state of a set of targeted objects
NOTE 1: The order of statements that make up the policy is explicitly defined.
NOTE 2: In the present document, Imperative Policy will refer to policies that are made up of Events, Conditions,
and Actions [i.25].
information model: information model is a representation of concepts of interest to an environment in a form that is
independent of data repository, data definition language, query language, implementation language, and protocol
intent policy: type of policy that uses statements in a natural language to express the goals of the policy, but not how to
accomplish those goals
NOTE 1: Each statement in an Intent Policy may require the translation of one or more of its terms to a form that
another managed functional entity can understand [i.25].
NOTE 2: In the present document, Intent Policy will refer to policies that do not execute as theories of a formal
logic. They typically are expressed in a restricted natural language and require a mapping to a form
understandable by other managed functional entities.
Lifecycle Service Orchestration (LSO): open and interoperable automation of management operations over the entire
lifecycle of Layer 2 and Layer 3 Connectivity Services
NOTE: This includes fulfilment, control, performance, assurance, usage, security, analytics and policy
capabilities, over all the network domains that require coordinated management and control, in order to
deliver the offered Service [i.26].
LSO reference architecture: high-level functional architecture that characterizes the management and control domains
and entities that make up a system, and the interfaces among them, to enable cooperative orchestration of offered
Services
managedEntity: manageable object that may be related to a Product, Service, and/or Resource
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GR ENI 003 V1.1.1 (2018-05)
NOTE: A ManagedEntity has the following common semantics:
1) each has the potential to be managed;
2) each can be associated with at least one ManagementDomain;
3) each is related to Products, Resources, and/or Services of the system being managed [i.14].
management: set of procedures that are responsible for describing, organizing, controlling access to, and managing the
lifecycle needs of information and entities of an organization
management abstraction: abstraction used for management purposes
managementDomain: domain whose contents are governed using a common set of management mechanisms
NOTE: A ManagementDomain is a type of ManagedEntity that has 3 key characteristics:
1) it has a set of administrators defined to perform management operations on the ManagedEntities
that it contains;
2) it defines a set of applications that are responsible for different governance operations, such as
monitoring, configuration, and so forth;
3) it defines a common set of management mechanisms, such as policy rules, that are used to govern
the behaviour of ManagedEntities contained in the ManagementDomain [i.14].
metadata: set of objects that contains prescriptive and/or descriptive informat
...