draft-ietf-supa-policy-based-management-framework-00.txt   draft-ietf-supa-policy-based-management-framework-01.txt 
Network Working Group W. Liu
Internet-Draft J. Strassner
Intended status: Informational G. Karagiannis
Expires: February 2017 Huawei Technologies
M. Klyus
NetCracker
J. Bi
Tsinghua University
C. Xie
China Telecom
August 29, 2016
SUPA policy-based management framework Network Working Group W. Liu
draft-ietf-supa-policy-based-management-framework-00 Internet-Draft Huawei Technologies
Intended status: Informational C. Xie
Expires: September 14, 2017 China Telecom Beijing Research Institute
J. Strassner
G. Karagiannis
Huawei Technologies
M. Klyus
NetCracker
J. Bi
Tsinghua University
March 13, 2017
Status of this Memo SUPA Policy-based Management Framework
draft-ietf-supa-policy-based-management-framework-01
Abstract
Simplified Use of Policy Abstractions (SUPA) defines base YANG data
models to encode policy, which will point to device-, technology-,
and service-specific YANG models developed in other working groups.
Policy rules within an operator's environment can be used to express
high-level, possibly network-wide policies to a network management
function (within a controller, an orchestrator, or a network
element). The network management function can then control the
configuration and/or monitoring of network elements and services.
This document describes the SUPA basic framework, its elements and
interfaces.
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
This Internet-Draft will expire on February 28, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
Simplified Use of Policy Abstractions (SUPA) defines base YANG data
models to encode policy, which will point to device-, technology-,
and service-specific YANG models developed in other working groups.
Policy rules within an operator's environment can be used to express
high-level, possibly network-wide policies to a network management
function (within a controller, an orchestrator, or a network element).
The network management function can then control the configuration
and/or monitoring of network elements and services. This document
describes the SUPA basic framework, its elements and interfaces.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Framework for Generic Policy-based Management ............... 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview ............................................... 3 3. Framework for Generic Policy-based Management . . . . . . . . 4
2.2. Operation .............................................. 8 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. The GPIM and the EPRIM ................................. 9 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Creation of Generic YANG Modules ....................... 9 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9
3. Security Considerations .................................... 10 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 9
4. IANA Considerations ........................................ 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Contributors ............................................... 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements ........................................... 10 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References ................................................. 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References .................................. 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References ................................ 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses ............................................ 14 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The rapid growth in the variety and importance of traffic flowing The rapid growth in the variety and importance of traffic flowing
over increasingly complex enterprise and service provider network over increasingly complex enterprise and service provider network
architectures makes the task of network operations and management architectures makes the task of network operations and management
applications and deploying new services much more difficult. In applications deploying new services much more difficult. In
addition, network operators want to deploy new services quickly and addition, network operators want to deploy new services quickly and
efficiently. Two possible mechanisms for dealing with this growing efficiently. Two possible mechanisms for dealing with this growing
difficulty are the use of software abstractions to simplify the difficulty are the use of software abstractions to simplify the
design and configuration of monitoring and control operations, and design and configuration of monitoring and control operations, and
the use of programmatic control over the configuration and operation the use of programmatic control over the configuration and operation
of such networks. Policy-based management can be used to combine of such networks. Policy-based management can be used to combine
these two mechanisms into an extensible framework. these two mechanisms into an extensible framework.
Policy rules within an operator's environment can be used to express Policy rules within an operator's environment can be used to express
high-level, possibly network-wide policies to a network management high-level, possibly network-wide policies to a network management
function (within a controller, an orchestrator, or a network element). function (within a controller, an orchestrator, or a network
The network management function can then control the configuration element). The network management function can then control the
and/or monitoring of network elements and services. configuration and/or monitoring of network elements and services.
Simplified Use of Policy Abstractions (SUPA) will define a generic Simplified Use of Policy Abstractions (SUPA) will define a generic
policy information model (GPIM) [SUPA-info-model] for use in network policy information model (GPIM) [I-D.ietf-supa-generic-policy-info-
operations and management applications. The GPIM defines concepts model] for use in network operations and management applications.
and terminology needed by policy management indepednent of the form The GPIM defines concepts and terminology needed by policy management
and content of the policy rule. The ECA Policy Rule Information independent of the form and content of the policy rule. The ECA
Model (EPRIM) [SUPA-info-model] extends the GPIM to define how to Policy Rule Information Model (EPRIM) [I-D.ietf-supa-generic-policy-
build policy rules according to the event-condition-action paradigm. info-model] extends the GPIM to define how to build policy rules
according to the event-condition-action paradigm.
Both the GPIM and the EPRIM are targeted at controlling the Both the GPIM and the EPRIM are targeted at controlling the
configuration and monitoring of network elements throughout the configuration and monitoring of network elements throughout the
service development and deployment lifecycle. The GPIM and the EPRIM service development and deployment lifecycle. The GPIM and the EPRIM
will both be translated into corresponding YANG [RFC6020][RFC6020bis] will both be translated into corresponding YANG [RFC6020][RFC6020bis]
modules that define policy concepts, terminology, and rules in a modules that define policy concepts, terminology, and rules in a
generic and interoperable manner; additional YANG modules may also generic and interoperable manner; additional YANG modules may also be
be defined from the GPIM and/or EPRIM to manage specific functions. defined from the GPIM and/or EPRIM to manage specific functions.
The key benefit of policy management is that it enables different The key benefit of policy management is that it enables different
network elements and services to be instructed to behave the same network elements and services to be instructed to behave the same
way, even if they are programmed differently. Management way, even if they are programmed differently. Management
applications will benefit from using policy rules that enable applications will benefit from using policy rules that enable
scalable and consistent programmatic control over the scalable and consistent programmatic control over the configuration
configuration and monitoring of network elements and services. and monitoring of network elements and services.
2. Framework for Generic Policy-based Management 2. Terminology
GPIM: Generic Policy Information Model, which defines concepts and
terminology needed by policy management independent of the form and
content of the policy rule.
EPRIM: ECA Policy Rule Information Model, which extends the GPIM to
define how to build policy rules according to the event-condition-
action paradigm.
GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data-
model], are created from the GPIM. These YANG data model policies
are used to control the configuration of network elements that model
the service(s) to be managed using policy.
3. Framework for Generic Policy-based Management
This section briefly describes the design and operation of the SUPA This section briefly describes the design and operation of the SUPA
policy-based management framework. policy-based management framework.
2.1. Overview 3.1. Overview
Figure 1 shows a simplified functional architecture of how SUPA is Figure 1 shows a simplified functional architecture of how SUPA is
used to define policies for creating network element configuration used to define policies for creating network element configuration
and monitoring snippets. SUPA uses the GPIM to define a consensual snippets. (Note from Editor: a "snippet" is a small piece of
vocabulary that different actors can use to interact with network information (e.g., part of a sentence that was cut out).) SUPA uses
elements and services. The EPRIM defines a generic structure for the GPIM to define a consensual vocabulary that different actors can
imperative policies. The GPIM, as well as the combination of the use to interact with network elements and services. The EPRIM
GPIM and EPRIM, are converted to generic YANG data modules. defines a generic structure for imperative policies. The GPIM, and/
or the combination of the GPIM and the EPRIM, is converted to generic
YANG data modules.
In one possible approach, SUPA Generic & ECA Policy YANG Data In one possible approach, SUPA Generic Policy and SUPA ECA Policy
modules together with the Resource and Service YANG data models YANG data modules together with the Resource and Service YANG data
specified in IETF (which define the specific elements that will be models specified in IETF (which define the specific elements that
controlled by policies) are used by the Service Interface Logic. will be controlled by policies) are used by the Service Interface
This Service Interface Logic creates appropriate input mechanisms Logic. This Service Interface Logic creates appropriate input
for the operator to define policies (e.g., a web form or a script) mechanisms for the operator to define policies (e.g., a web form or a
for creating and managing the network configuration. The operator script) for creating and managing the network configuration. The
interacts with the interface, which is then translated to operator interacts with the interface, which is then translated to
configuration snippets. configuration snippets.
Note that YANG models may not exist. In this case, the SUPA generic Note that YANG models may not exist. In this case, the SUPA generic
policy YANG data modules serve as an extensible basis to develop new policy YANG data modules serve as an extensible basis to develop new
YANG data models for the Service Interface Logic to create YANG data models for the Service Interface Logic to create
appropriate input mechanisms for the operator to define policies. appropriate input mechanisms for the operator to define policies.
This transfers the work specified by the Resource and Service YANG This transfers the work specified by the Resource and Service YANG
data models specified in IETF into the Service Interface Logic, data models specified in IETF into the Service Interface Logic, which
which is then translated to configuration snippets. is then translated to configuration snippets.
+---------------------+ +---------------------+
+----------+ \| SUPA | +----------+ \| SUPA |
| IETF |---+----+ Information Models | | IETF |---+----+ Information Models |
+----------+ | /| GPIM and EPRIM | +----------+ | /| GPIM and EPRIM |
| +---------+-----------+ | +---------+-----------+
Assignments | | Defines Policy Concepts Assignments | | Defines Policy Concepts
and Manage | \|/ and Manage | \|/
Content | +---------+-----------+ Content | +---------+-----------+
| \| SUPA Generic | | \| SUPA Generic |
+----+ & ECA Policy | +----+ & ECA Policy |
/| YANG Data modules | /| YANG Data modules |
+---------+-----------+ +---------+-----------+
* Possible Approach * Possible Approach
+-----------------------------*-----------------------------+ +-----------------------------*-----------------------------+
| Management System * | | Management System * |
| \*/ | | \*/ |
| Fills +---------+---------+ +-------------+ | | Fills +---------+---------+ +-------------+ |
| +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+
| |Operator|--------+ Logic +--|Service YANG |----|IETF| | |Operator|--------+ Logic +--|Service YANG |----|IETF|
| +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+ | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+
| scripts |forms, scripts,...)| +-------------+ | | scripts |forms, scripts,...)| +-------------+ |
| +---------+---------+ | | +---------+---------+ |
| \|/ | | \|/ |
| +-------+--------+ | | +-------+--------+ |
| | Local Devices | | | | Local Devices | |
| | and Management | | | | and Management | |
| | Systems | | | | Systems | |
| +----------------+ | | +----------------+ |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 1 SUPA Framework Figure 1: SUPA Framework
Figure 1 is exemplary. The Operator actor shown in Figure 1 can Figure 1 is exemplary. The Operator actor shown in Figure 1 can
interact with SUPA in other ways not shown in Figure 1. In addition, interact with SUPA in other ways not shown in Figure 1. In addition,
other actors (e.g., an application developer) that can interact with other actors (e.g., an application developer) that can interact with
SUPA are not shown for simplicity. SUPA are not shown for simplicity.
The EPRIM defines an Event-Condition-Action (ECA) policy as an The EPRIM defines an Event-Condition-Action (ECA) policy as an
example of imperative policies. An ECA policy rule is activated example of imperative policies. An ECA policy rule is activated when
when its event clause is true; the condition clause is then its event clause is true; the condition clause is then evaluated and,
evaluated and, if true, signals the execution of one or more if true, signals the execution of one or more actions in the action
actions in the action clause. Imperative policy rules require clause. This type of policy explicitly defines the current and
additional management functions, which are explained in section 2.2 desired states of the system being managed. Imperative policy rules
below. require additional management functions, which are explained in
section 2.2 below.
Figure 2 shows a SUPA Policy Model creating and communicating policy Figure 2 shows how the SUPA Policy Model is used to create policy
rules to two different Network Manager and Network Controller data models step by step and how the policy rules are used to
elements. communicate among various network management functions located on
different layers.
The Generic Policy Information Model (GPIM) was used to construct The Generic Policy Information Model (GPIM) is used to construct
policies. The GPIM defines generic policy concepts, as well as two policies. The GPIM defines generic policy concepts, as well as two
types of policies: ECA policy rules and declarative policy types of policies: ECA policy rules and declarative policy
statements. statements.
An ECA policy rule is activated when its event clause is true; the A set of Generic Policy Data Models (GPDM) are then created from the
condition clause is then evaluated and, if true, signals the GPIM. These YANG data model policies are then used to control the
execution of one or more actions in the action clause. This type of
policy explicitly defines the current and desired states of the
system being managed.
A set of Generic Policy Data Models are then created from the GPIM.
These YANG data model policies are then used to control the
configuration of network elements that model the service(s) to be configuration of network elements that model the service(s) to be
managed using policy. managed using policy.
OSS/BSS/Orchestrator SUPA designed YANG data models can be the input for management
/ \ functions, and automatically generate interfaces and data stores.
C During the run time, components communicate with the data instances
\ / for management and monitoring.
+------------------------------+----------------------------------+
| SUPA Policy Model |
| +----------------------------------+ |
| | Generic Policy Information Model | |
| +----+------------------------+----+ |
| D \D/ |
| D +------------+--------------+ |
| D | ECAPolicyRule Information | |
| D | Model (EPRIM) | |
| D +------------+--------------+ |
| +----------------D------------------------D----------------+ |
| | \D/ SUPA Policy DM D | |
| |+---------------+-----------+ D | |
| || Generic Policy Data Model | D | |
| |+-------------------+-------+ D | |
| | \D/ \D/ | |
| | +--+--------------------+--------------+ | |
| | | ECA PolicyRule Data Model | | |
| | +--------------------------------------+ | |
| +------------------------------+---------------------------+ |
+---------------------------------|-------------------------------+
+-------------+--------+
\C/ \C/ NETCONF/RESTCONF
+----------------+-----------+ +-------+--------------------+
| EMS/NMS/Controller | | EMS/NMS/Controller |
| +---------------------+ | | +---------------------+ |
| | Network Service & | | | | Network Service & | |
| | Resource Data Models| | | | Resource Data Models| |
| +---------------------+ | | +---------------------+ |
+---+---+---+----------------+ +-----+---+---+--------------+
/ \ / \ / \ / \ / \ / \
C C C C C C
\ / \ / \ / \ / \ / \ /
NE1 NE2 NEn NE1 NE2 NEn
Figure 2 SUPA Policy Model Framework +
| SUPA Policy Model
|
| +----------------------------------+
| | Generic Policy Information Model |
| +----------------------------------+
| D D
| D +-------------v-------------+
+----------------------+ | D | ECAPolicyRule Information |
| OSS/BSS/Orchestrator <--+ | D | Model |
+----------^-----------+ | | D +---------------------------+
C | | D D
C | | +----+D+------------------------+D+---+
C +-----+ D SUPA Policy Data Model D |
+----------v-----------+ | | ----v-----------------------+ D |
| EMS/NMS/Controller <--------+ | Generic Policy Data Model | D |
+----------^-----------+ | | ----------------------------+ D |
C +-----+ D D |
C | | | +--------v-----------------v--+ |
+----------v-----------+ | | | | ECA PolicyRule Data Model | |
| Network Element <--+ | | +-----------------------------+ |
+----------------------+ | +-------------------------------------+
|
|
Figure 2: SUPA Policy Model Framework
In Figure 2: In Figure 2:
A double-headed arrow with Cs means communication;
A double-headed arrow with Ds means derived from.
The network elements used in this framework are: The double-headed arrow with Cs means communication;
SUPA Policy Model: represents one or more policy modules that The arrow with Ds means derived from.
contain the following entities:
Generic Policy Information Model: a model for defining policy The components within this framework are:
rules that are independent of data repository, data definition,
query, and implementation languages, and protocol. This model is
abstract and is used for design; it MUST be turned into a data model
for implementation.
Generic Policy Data Model: a model of policy rules for that are SUPA Policy Model: represents one or more policy modules that contain
dependent of data repository, data definition, query, and the following entities:
implementation languages, and protocol.
Generic Policy Information Model: a model for defining policy rules
that are independent of data repository, data definition, query,
implementation languages, and protocol. This model is abstract and
is used for design; it MUST be turned into a data model for
implementation.
Generic Policy Data Model: a model of policy rules that are dependent
on data repository, data definition, query, implementation languages,
and protocol.
ECA Policy Rule Information Data Model (EPRIM): represents a policy ECA Policy Rule Information Data Model (EPRIM): represents a policy
rule as a statement that consists of an event clause, a condition rule as a statement that consists of an event clause, a condition
clause, and an action clause. This type of Policy Rule explicitly clause, and an action clause. This type of Policy Rule explicitly
defines the current and desired states of the system being managed. defines the current and desired states of the system being managed.
This model is abstract and is used for design; it MUST be turned This model is abstract and is used for design; it MUST be turned into
into a data model for implementation. a data model for implementation.
ECA Policy Rule Data Model: a model of policy rules derived from ECA Policy Rule Data Model: a model of policy rules, derived from
EPRIM, consist of an event clause, a condition clause, and an action EPRIM, that consist of an event clause, a condition clause, and an
clause. action clause.
EMS/NMS/Controller: represents one or more entities that are able EMS/NMS/Controller: represents one or more entities that are able to
to control the operation and management of a network infrastructure control the operation and management of a network infrastructure
(e.g., a network topology that consists of Network Elements). (e.g., a network topology that consists of Network Elements).
Network Service & Resource Data Models: models of the service as Network Service and Resource Data Models: models of the service as
well as physical and virtual network topology including the resource well as physical and virtual network topology including the resource
attributes (e.g., data rate or latency of links) and operational attributes (e.g., data rate or latency of links) and operational
parameters needed to support service deployment over the network parameters needed to support service deployment over the network
topology. topology.
Network Element (NE), which can interact with local or remote Network Element (NE), which can interact with local or remote
EMS/NMS/Controller in order to exchange information, such as EMS/NMS/Controller in order to exchange information, such as
configuration information, policy enforcement capabilities, and configuration information, policy enforcement capabilities, and
network status. network status.
Relationship among Policy, Service and Resource models can be illustrated by the Relationship between Policy, Service and Resource models can be
figure below. illustrated by the figure below.
+---------------+ +----------------+
| Policy | (1) | Service |
| |*******************| |
| ( SUPA ) | | ( L3SM, ... ) |
+---------------+ +----------------+
** **
** **
** **
(2) ** ** (3)
** **
** **
** **
+-------------------+
| Resource |
| |
| (Inventory, ... ) |
+-------------------+
Figure 3 Relationship among Policy, Service and Resource
In Figure 3: +---------------+ +----------------+
(1) policy manages and can adjust service behavior as necessary | Policy | (1) | Service |
(2) policy manages and can adjust resource behavior as necessary | |*******************| |
(3) resource hosts service; changing resources may change service | ( SUPA ) |*******************| ( L3SM, ... ) |
behavior as necessary +---------------+ +----------------+
** /*\
** *
** *
(2) ** * (3)
** *
** *
** *
+-------------------+
| Resource |
| |
| (Inventory, ... ) |
+-------------------+
Policies are used to manage behavior. Policies can be applied to Figure 3: Relationship between Policy, Service and Resource models
services and resources. More importantly, policies can be used to
manage how resources are allocated and assigned to services. This
enables a single policy to manage one or multiple services and
resources as well as their dependencies.
2.2. Operation In Figure 3:
SUPA can be used to define various types of policies, including (1) policy manages and can adjust service behavior as necessary
policies that affect services and/or the configuration of (1:1..n)
individual or groups of network elements. SUPA can be used by a (2) policy manages and can adjust resource behavior as necessary
centralized and/or distributed set of entities for creating, (1:1..n)
managing, interacting with, and retiring policy rules. (3) resource hosts service; changing resources may change service
behavior as necessary
The SUPA scope is limited to policy information and data models. Policies are used to control the management of resources and
SUPA will not define network resource data models or network services, while data from resources and services are used to select
service data models; both are out of scope. Instead, SUPA will make and/or modify policies during runtime. More importantly, policies
use of network resource data models defined by other WGs or SDOs. can be used to manage how resources are allocated and assigned to
services. This enables a single policy to manage one or multiple
services and resources as well as their dependencies. (1:1..n) in (1)
and (2) below figure 3 shows one policy rule is able to manages and
can adjust one or multiple services/resources. Line (1) and (2)
connecting policy to resource and policy to service are same, and
line (3) connecting resource to service is different as it's
navigable only from resource to service.
Declarative policies that specify the goals to achieve but not how 3.2. Operation
to achieve those goals (also called "intent-based" policies) are out
of scope for the initial phase of SUPA.
2.3. The GPIM and the EPRIM SUPA can be used to define various types of policies, including
policies that affect services and/or the configuration of individual
or groups of network elements. SUPA can be used by a centralized
and/or distributed set of entities for creating, managing,
interacting with, and retiring policy rules.
The GPIM provides a common vocabulary for representing concepts The SUPA scope is limited to policy information and data models.
that are common to expressing different types of policy, but which SUPA will not define network resource data models or network service
are independent of language, protocol, repository, and level of data models; both are out of scope. Instead, SUPA will make use of
abstraction. network resource data models defined by other WGs or SDOs.
This enables different policies at different levels of abstraction Declarative policies that specify the goals to be achieved but not
to form a continuum, where more abstract policies can be translated how to achieve those goals (also called "intent-based" policies) are
into more concrete policies, and vice-versa. For example, the out of scope for the initial phase of SUPA.
information model can be extended by generalizing concepts from an
existing data model into the GPIM; the GPIM extensions can then be
used by other data models.
The SUPA working group develops models for expressing policy at 3.3. The GPIM and the EPRIM
different levels of abstraction. Specifically, two models are
envisioned (both of which are contained in the Generic Policy
Information Model block in Figure 1:
1. a generic model (the GPIM) that defines concepts and vocabulary The GPIM provides a common vocabulary for representing concepts that
needed by policy management systems independent of the form and are common to expressing different types of policy, but which are
content of the policy independent of language, protocol, repository, and level of
abstraction. Hence, the GPIM defines concepts and vocabulary needed
by policy management systems independent of the form and content of
the policy. The ERPIM is a more specific model that refines the GPIM
to specify policy rules in an event-condition-action form.
2. a more specific model (the EPRIM) that refines the GPIM to This enables different policies at different levels of abstraction to
specify policy rules in an event-condition-action form form a continuum, where more abstract policies can be translated into
more concrete policies, and vice-versa. For example, the information
model can be extended by generalizing concepts from an existing data
model into the GPIM; the GPIM extensions can then be used by other
data models.
2.4. Creation of Generic YANG Modules 3.4. Creation of Generic YANG Modules
An information model is abstract. As such, it cannot be directly An information model is abstract. As such, it cannot be directly
instantiated (i.e., objects cannot be created directly from it). instantiated (i.e., objects cannot be created directly from it).
Therefore, both the GPIM, as well as the combination of the GPIM Therefore, both the GPIM and the combination of the GPIM and the
and the EPRIM, are translated to generic YANG modules. EPRIM, are translated to generic YANG modules.
SUPA will provide guidelines for translating the GPIM (or the SUPA will provide guidelines for translating the GPIM (or the
combination of the GPIM and the EPRIM) into concrete YANG data combination of the GPIM and the EPRIM) into concrete YANG data models
models that define how to manage and communicate policies between that define how to manage and communicate policies between systems.
systems. Multiple imperative policy YANG data models may be Multiple imperative policy YANG data models may be instantiated from
instantiated from the GPIM (or the combination of the GPIM and the the GPIM (or the combination of the GPIM and the EPRIM). In
EPRIM). In particular, SUPA will specify a set of YANG data models particular, SUPA will specify a set of YANG data models that will
that will consist of a base policy model for representing policy consist of a base policy model for representing policy management
management concepts independent of the type or structure of a concepts independent of the type or structure of a policy, and as
policy, and as well, an extension for defining policy rules well, an extension for defining policy rules according to the ECA
according to the ECA paradigm. paradigm.(Note from Editor: This means that policies can be defined
using the GPIM directly, or using the combination of the GPIM and the
EPRIM. If you use only the GPIM, you get a technology- and vendor-
independent information model that you are free to map to the data
model of your choice; note that the structure of a policy is NOT
defined. If you use the GPIM and the EPRIM, you get a technology-
and vendor-independent information model that defines policies as an
event-condition-action (i.e., imperative) rule.)
The process of developing the GPIM, EPRIM and the derived/translated The process of developing the GPIM, EPRIM and the derived/translated
YANG data models is realized following the sequence shown below. YANG data models is realized following the sequence shown below.
After completing this process and if the implementation of the YANG After completing this process and if the implementation of the YANG
data models requires it, the GPIM and EPRIM and the data models requires it, the GPIM and EPRIM and the derived/
derived/translated YANG data models are updated and synchronized. translated YANG data models are updated and synchronized.
(1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1')
Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)= Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)=
Implementation; (3')= update of YANG data models; (2')=update of Implementation; (3')= update of YANG data models; (2')=update of
EPRIM; (1') = update of GPIM EPRIM; (1') = update of GPIM
The YANG module derived from the GPIM contains concepts and The YANG module derived from the GPIM contains concepts and
terminology for the common operation and administration of policy- terminology for the common operation and administration of policy-
based systems, as well as an extensible structure for policy rules based systems, as well as an extensible structure for policy rules of
of different paradigms. The YANG module derived from the EPRIM different paradigms. The YANG module derived from the EPRIM extends
extends the generic nature of the GPIM to represent policies using the generic nature of the GPIM to represent policies using an event-
an event-condition-action structure. condition-action structure.
The above sequence allows for the addition of new, as well as editing The above sequence allows for the addition of new, as well as the
of existing model elements in the GPIM and EPRIM. In practice, the editing of existing model elements in the GPIM and EPRIM. In
implementation sequence may be much simpler. Specifically, it is practice, the implementation sequence may be much simpler.
unlikely that the GPIM will need to be changed. In addition, changes Specifically, it is unlikely that the GPIM will need to be changed.
to the EPRIM will likely be focused on fine-tuning the behavior In addition, changes to the EPRIM will likely be focused on fine-
offered by a specific set of model elements. tuning the behavior offered by a specific set of model elements.
3. Security Considerations 4. Security Considerations
TBD TBD
4. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
5. Contributors 6. Contributors
The following people all contributed to creating this document, The following people all contributed to creating this document,
listed in alphabetical order: listed in alphabetical order:
Ying Chen, China Unicom Ying Chen, China Unicom
Luis M. Contreras, Telefonica I+D Luis M. Contreras, Telefonica I+D
Dan Romascanu, Avaya Dan Romascanu, Avaya
J. Schoenwaelder, Jacobs University, Germany J. Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom Qiong Sun, China Telecom
6. Acknowledgements 7. Acknowledgements
This document has benefited from reviews, suggestions, comments and This document has benefited from reviews, suggestions, comments and
proposed text provided by the following members, listed in proposed text provided by the following members, listed in
alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern, Bert alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern,
Wijnen, Tianran Zhou. Jonathan Hansford, Bert Wijnen, Tianran Zhou.
Part of the initial draft of this document was picked up from Part of the initial draft of this document was picked up from
previous documents, and this section lists the acknowledgements from previous documents, and this section lists the acknowledgements from
them. them.
From "SUPA Value Proposition" [Klyus2016] From "SUPA Value Proposition" [I-D.klyus-supa-value-proposition]
The following people all contributed to creating this document, The following people all contributed to creating this document,
listed in alphabetical order: listed in alphabetical order:
Vikram Choudhary, Huawei Technologies Vikram Choudhary, Huawei Technologies
Luis M. Contreras, Telefonica I+D Luis M. Contreras, Telefonica I+D
Dan Romascanu, Avaya Dan Romascanu, Avaya
J. Schoenwaelder, Jacobs University, Germany J. Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom Qiong Sun, China Telecom
Parviz Yegani, Juniper Networks Parviz Yegani, Juniper Networks
This document has benefited from reviews, suggestions, comments and This document has benefited from reviews, suggestions, comments and
proposed text provided by the following members, listed in proposed text provided by the following members, listed in
alphabetical order: H. Rafiee, J. Saperia and C. Zhou. alphabetical order: H. Rafiee, J. Saperia and C. Zhou.
The authors of "SUPA Value Proposition" [Klyus2016] were: The authors of "SUPA Value Proposition" [I-D.klyus-supa-value-
proposition] were:
Maxim Klyus, Ed. , NetCracker Maxim Klyus, Ed. , NetCracker
John Strassner, Ed. , Huawei Technologies John Strassner, Ed. , Huawei Technologies
Will(Shucheng) Liu, Huawei Technologies Will(Shucheng) Liu, Huawei Technologies
Georgios Karagiannis, Huawei Technologies Georgios Karagiannis, Huawei Technologies
Jun Bi, Tsinghua University Jun Bi, Tsinghua University
The initial draft of this document merged one document, and this The initial draft of this document merged one document, and this
section lists the acknowledgements from it. section lists the acknowledgements from it.
From "Problem Statement for Simplified Use of Policy Abstractions From "Problem Statement for Simplified Use of Policy Abstractions
(SUPA)" [Karagiannis2015] (SUPA)" [I-D.karagiannis-supa-problem-statement]
The authors of this draft would like to thank the following persons The authors of this draft would like to thank the following persons
for the provided valuable feedback and contributions: Diego Lopez, for the provided valuable feedback and contributions: Diego Lopez,
Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon
Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas
Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott
Scott O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. Tina
Tina Tsou, Will Liu and Jean-Francois Tremblay contributed to an Tsou, Will Liu and Jean-Francois Tremblay contributed to an early
early version of this draft. version of this draft.
The authors of "Problem Statement for Simplified Use of Policy The authors of "Problem Statement for Simplified Use of Policy
Abstractions (SUPA)" [Karagiannis2015] were: Abstractions (SUPA)" [I-D.karagiannis-supa-problem-statement] were:
Georgios Karagiannis, Huawei Technologies Georgios Karagiannis, Huawei Technologies
Qiong Sun, China Telecom Qiong Sun, China Telecom
Luis M. Contreras, Telefonica Luis M. Contreras, Telefonica
Parviz Yegani, Juniper Parviz Yegani, Juniper
John Strassner, Huawei Technologies John Strassner, Huawei Technologies
Jun Bi, Tsinghua University Jun Bi, Tsinghua University
From "The Framework of Simplified Use of Policy Abstractions (SUPA)" From "The Framework of Simplified Use of Policy Abstractions (SUPA)"
[Zhou2015] [I-D.zhou-supa-framework]
The authors of this draft would like to thank the following persons The authors of this draft would like to thank the following persons
for the provided valuable feedback: Diego Lopez, Jose Saldana, for the provided valuable feedback: Diego Lopez, Jose Saldana,
Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed
Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios
Georgios Karagiannis, John Strassner, Raghav Rao, Jing Huang. Karagiannis, John Strassner, Raghav Rao, Jing Huang.
Early version of this draft can be found here:
https://tools.ietf.org/html/draft-zhou-supa-architecture-00
At the early stage of SUPA, we think quite some issues are left open,
it is not so suitable to call this draft as "architecture". We would
like to rename it to "framework". Later there may be a dedicated
architecture document.
The authors of "The Framework of Simplified Use of Policy The authors of "The Framework of Simplified Use of Policy
Abstractions (SUPA)" [Zhou2015] were: Abstractions (SUPA)" [I-D.zhou-supa-framework] were:
Cathy Zhou, Huawei Technologies
Luis M. Contreras, Telefonica
Qiong Sun, China Telecom
Parviz Yegani, Juniper
7. References Cathy Zhou, Huawei Technologies
Luis M. Contreras, Telefonica
Qiong Sun, China Telecom
Parviz Yegani, Juniper
This section defines normative and informative references for this 8. References
document.
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References 8.2. Informative References
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., [I-D.ietf-supa-generic-policy-data-model]
Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, Halpern, J. and J. Strassner, "Generic Policy Data Model
J., Waldbusser, S., "Terminology for Policy-Based Management", RFC for Simplified Use of Policy Abstractions (SUPA)", draft-
3198, November, 2001 ietf-supa-generic-policy-data-model-02 (work in progress),
October 2016.
[RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the [I-D.ietf-supa-generic-policy-info-model]
Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. Strassner, J., Halpern, J., and S. Meer, "Generic Policy
Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-02 (work in progress), January 2017.
[RFC6020bis] M. Bjorklund, "The YANG 1.1 Data Modeling Language", [I-D.karagiannis-supa-problem-statement]
IETF Internet draft, draft-ietf-netmod-rfc6020bis-14, June 2016. Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L.,
Yegani, P., and J. Bi, "Problem Statement for Simplified
Use of Policy Abstractions (SUPA)", draft-karagiannis-
supa-problem-statement-07 (work in progress), June 2015.
[RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. [I-D.klyus-supa-value-proposition]
Roome, S. Shalunov, R. Woundy "Application-Layer Traffic Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and
Optimization (ALTO) Protocol", September 2014 J. Bi, "SUPA Value Proposition", draft-klyus-supa-value-
proposition-00 (work in progress), March 2016.
[SUPA-info-model] J. Strassner, J. Halpern, S. van der Meer, "Generic [I-D.zhou-supa-framework]
Policy Information Model for Simplified Use of Policy Abstractions Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
(SUPA)", IETF Internet draft, Framework of Simplified Use of Policy Abstractions
draft-ietf-supa-generic-policy-info-model-01, July 2016 (SUPA)", draft-zhou-supa-framework-02 (work in progress),
May 2015.
[TR235] J. Strassner, ed., "ZOOM Policy Architecture and [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
Information Model Snapshot", TR245, part of the TM Forum ZOOM M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
project, October 26, 2014 J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, DOI 10.17487/RFC3198, November
2001, <http://www.rfc-editor.org/info/rfc3198>.
[Karagiannis2015] G. Karagiannis, ed., "Problem Statement for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft, the Network Configuration Protocol (NETCONF)", RFC 6020,
draft-karagiannis-supa-problem-statement-07, June 5, 2015 DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
draft, draft-klyus-supa-value-proposition-00, Mar 21, 2016 Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>.
[Zhou2015] C. Zhou, ed., "The Framework of Simplified Use of Policy [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015 RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>.
Authors' Addresses Authors' Addresses
Will(Shucheng) Liu Will(Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District, Shenzhen 518129 Bantian, Longgang District
Shenzhen 518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
Chongfeng Xie
China Telecom Beijing Research Institute
China Telecom Information Technology Innovation Park
Beijing 102209
P.R. China
Email: xiechf.bri@chinatelecom.cn
John Strassner John Strassner
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95138 USA Santa Clara 95138
Email: strazpdj@gmail.com CA USA
Email: john.sc.strassner@huawei.com
Georgios Karagiannis Georgios Karagiannis
Huawei Technologies Huawei Technologies
Hansaallee 205, 40549 Dusseldorf Hansaallee 205
Dusseldorf 40549
Germany Germany
Email: Georgios.Karagiannis@huawei.com Email: Georgios.Karagiannis@huawei.com
Maxim Klyus Maxim Klyus
NetCracker NetCracker
Kozhevnicheskaya str.,7 Bldg. #1 Kozhevnicheskaya str.,7 Bldg. #1
Moscow, Russia Moscow
E-mail: klyus@netcracker.com Russia
Email: klyus@netcracker.com
Jun Bi Jun Bi
Tsinghua University Tsinghua University
Network Research Center, Tsinghua University Network Research Center, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Email: junbi@tsinghua.edu.cn
Chongfeng Xie Email: junbi@tsinghua.edu.cn
China Telecom Beijing Research Institute
China Telecom Beijing Information Science&Technology Innovation Park
Beiqijia Town Changping District Beijing 102209 China
Email: xiechf@ctbri.com.cn
 End of changes. 106 change blocks. 
386 lines changed or deleted 429 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/