draft-ietf-supa-policy-based-management-framework-02.txt   draft-ietf-supa-policy-based-management-framework-03.txt 
Network Working Group W. Liu Network Working Group W. Liu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational C. Xie Intended status: Informational C. Xie
Expires: January 4, 2018 China Telecom Beijing Research Institute Expires: January 18, 2018 China Telecom Beijing Research Institute
J. Strassner J. Strassner
G. Karagiannis G. Karagiannis
Huawei Technologies Huawei Technologies
M. Klyus M. Klyus
NetCracker NetCracker
J. Bi J. Bi
Tsinghua University Tsinghua University
July 3, 2017 July 17, 2017
SUPA Policy-based Management Framework SUPA Policy-based Management Framework
draft-ietf-supa-policy-based-management-framework-02 draft-ietf-supa-policy-based-management-framework-03
Abstract Abstract
Simplified Use of Policy Abstractions (SUPA) defines base YANG data Simplified Use of Policy Abstractions (SUPA) defines base YANG data
models to encode policy, which point to device-, technology-, and models to encode policy, which point to device-, technology-, and
service-specific YANG models developed elsewhere. Policy rules service-specific YANG models developed elsewhere. Policy rules
within an operator's environment can be used to express high-level, within an operator's environment can be used to express high-level,
possibly network-wide policies to a network management function possibly network-wide policies to a network management function
(within a controller, an orchestrator, or a network element). The (within a controller, an orchestrator, or a network element). The
network management function can then control the configuration and/or network management function can then control the configuration and/or
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 Internet- working documents as Internet-Drafts. The list of current 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 months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Framework for Generic Policy-based Management . . . . . . . . 4 3. Framework for Generic Policy-based Management . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 10
3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 10 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Traffic flow over increasingly complex enterprise and service Traffic flows over increasingly complex enterprise and service
provider network becomes more and more important. Meanwhile, the provider networks become more and more important. Meanwhile, the
rapid growth of the variety makes the task of network operations and rapid growth of the variety makes the task of network operations and
management applications deploying new services much more difficult. management applications deploying new services much more difficult.
Moreover, network operators want to deploy new services quickly and Moreover, network operators want to deploy new services quickly and
efficiently. efficiently. Two possible mechanisms for dealing with this growing
difficulty are the use of software abstractions to simplify the
design and configuration of monitoring and control operations, and
the use of programmatic control over the configuration and operation
of such networks. Policy-based management can be used to combine
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 are a set of rules that
high-level, possibly network-wide policies to a network management define how services are designed, delivered, and operated. The SUPA
function (within a controller, an orchestrator, or a network (Simplified Use of Policy Abstractions) data model represents high-
element). The network management function can then control the level, possibly network-wide policy, which can be input to a network
configuration and/or monitoring of network elements and services. 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
according to such policies.
Simplified Use of Policy Abstractions (SUPA) defines a generic policy SUPA defines a generic policy information model (GPIM) [I-D.ietf-
information model (GPIM) [I-D.ietf-supa-generic-policy-info-model] supa-generic-policy-info-model] for use in network operations and
for use in network operations and management applications. The GPIM management applications. The GPIM defines concepts and terminology
defines concepts and terminology needed by policy management needed by policy management independent of the form and content of
independent of the form and content of the policy rule. The Event- the policy rule. The Event-Condition-Action (ECA) Policy Rule
Condition-Action (ECA) Policy Rule Information Model (EPRIM) [I- Information Model (EPRIM) [I-D.ietf-supa-generic-policyinfo-model]
D.ietf-supa-generic-policyinfo- model] extends the GPIM by defining extends the GPIM by defining how to build policy rules according to
how to build policy rules according to the event-condition-action the event-condition-action paradigm.
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
can both be translated into corresponding YANG [RFC6020][RFC6020bis] can 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 be generic and interoperable manner; additional YANG modules may also be
derived from the GPIM and/or EPRIM to manage specific functions. derived 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 configuration scalable and consistent programmatic control over the configuration
and monitoring of network elements and services. and monitoring of network elements and services.
Some typical and useful instances, for authors to understand the
applicability of SUPA, such as SNMP blocking upon load of link
reaching a threshold, virtual maching migration upon the changinng of
user location, are written in [I-D.cheng-supa-applicability].
2. Terminology 2. Terminology
SUPA: Simplified Use of Policy Abstractions, is the working group SUPA: Simplified Use of Policy Abstractions, is the working group
name, which defines a data model, to be used to represent high-level, name, which defines a data model, to be used to represent high-level,
possibly network-wide policies, which can be input to a network possibly network-wide policies, which can be input to a network
management function (within a controller, an orchestrator, or a management function (within a controller, an orchestrator, or a
network element). network element).
YANG: an acronym for "Yet Another Next Generation". YANG is a data YANG: an acronym for "Yet Another Next Generation". YANG is a data
modeling language used to model configuration and state data modeling language used to model configuration and state data
manipulated by the Network Configuration Protocol (NETCONF), NETCONF manipulated by the Network Configuration Protocol (NETCONF), NETCONF
remote procedure calls, and NETCONF notifications.[RFC6020] remote procedure calls, and NETCONF notifications.[RFC6020]
ECA: Event-Condition-Action, is a short-cut for referring to the ECA: Event-Condition-Action, is a short-cut for referring to the
structure of active rules in event driven architecture and active structure of active rules in event driven architecture and active
database systems. database systems.
EMS:Element Management System, software to monitor and control EMS: Element Management System, software to monitor and control
network elements (devices) in telecommunications. network elements (devices) in telecommunications.
NMS:Network Management System, a set of hardware and/or software NMS: Network Management System, a set of hardware and/or software
tools that allow an IT professional to supervise the individual tools that allow an IT professional to supervise the individual
components of a network within a larger network management framework. components of a network within a larger network management framework.
OSS:Operations/Operational Support System, are computer systems used OSS: Operations/Operational Support System, are computer systems used
by telecommunications service providers to manage their networks by telecommunications service providers to manage their networks
(e.g., telephone networks). (e.g., telephone networks).
BSS:Business Support Systems, are used to support various end-to-end BSS: Business Support Systems, are used to support various end-to-end
telecommunication services. telecommunication services.
GPIM: Generic Policy Information Model, which defines concepts and GPIM: Generic Policy Information Model, which defines concepts and
terminology needed by policy management independent of the form and terminology needed by policy management independent of the form and
content of the policy rule. content of the policy rule.
EPRIM: ECA Policy Rule Information Model, which extends the GPIM by EPRIM: ECA Policy Rule Information Model, which extends the GPIM by
defining how to build policy rules according to the event-condition- defining how to build policy rules according to the event-condition-
action paradigm. action paradigm.
skipping to change at page 5, line 49 skipping to change at page 6, line 37
| \|/ | | \|/ |
| +-------+--------+ | | +-------+--------+ |
| | 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 can interact with Figure 1 is exemplary. The Operator actor can interact with SUPA in
SUPA in other ways not shown in Figure 1. In addition, other actors other ways not shown in Figure 1. In addition, other actors (e.g.,
(e.g., an application developer) that can interact with SUPA are not an application developer) that can interact with SUPA are not shown
shown for simplicity. for simplicity.
The EPRIM defines an ECA policy as an example of imperative policies. The EPRIM defines an ECA policy as an example of imperative policies.
An ECA policy rule is activated when its event clause is true; the An ECA policy rule is activated when its event clause is true; the
condition clause is then evaluated and, if true, signals the condition clause is then evaluated and, if true, signals the
execution of one or more actions in the action clause. This type of execution of one or more actions in the action clause. This type of
policy explicitly defines the current and desired states of the policy explicitly defines the current and desired states of the
system being managed. Imperative policy rules require additional system being managed. Imperative policy rules require additional
management functions, which are explained in section 2.2 below. management functions, which are explained in section 3.2 below.
Figure 2 shows how the SUPA Policy Model is used to create policy Figure 2 shows how the SUPA Policy Model is used to create policy
data models step by step and how the policy rules are used to data models step by step and how the policy rules are used to
communicate among various network management functions located on communicate among various network management functions located on
different layers. different layers.
The Generic Policy Information Model (GPIM) is 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.
skipping to change at page 9, line 16 skipping to change at page 9, line 41
(1:1..n) (1:1..n)
(3) resource hosts service; changing resources may change service (3) resource hosts service; changing resources may change service
behavior as necessary behavior as necessary
Policies are used to control the management of resources and Policies are used to control the management of resources and
services, while data from resources and services are used to select services, while data from resources and services are used to select
and/or modify policies during runtime. More importantly, policies and/or modify policies during runtime. More importantly, policies
can be used to manage how resources are allocated and assigned to can be used to manage how resources are allocated and assigned to
services. This enables a single policy to manage one or multiple services. This enables a single policy to manage one or multiple
services and resources as well as their dependencies. (1:1..n) in (1) 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 and (2) below figure 3 show one policy rule is able to manages and
can adjust one or multiple services/resources. Line (1) and (2) can adjust one or multiple services/resources. Line (1) and (2)
connecting policy to resource and policy to service are the same, and connecting policy to resource and policy to service are the same, and
line (3) connecting resource to service is different as it's line (3) connecting resource to service is different as it's
navigable only from resource to service. navigable only from resource to service.
3.2. Operation 3.2. Operation
SUPA can be used to define various types of policies, including SUPA can be used to define various types of policies, including
policies that affect services and/or the configuration of individual policies that affect services and/or the configuration of individual
or groups of network elements. SUPA can be used by a centralized or groups of network elements. SUPA can be used by a centralized
skipping to change at page 13, line 24 skipping to change at page 13, line 48
8.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[I-D.cheng-supa-applicability]
Cheng, Y., Liu, D., Fu, B., Zhang, D., and N. Vadrevu,
"Applicability of SUPA", draft-cheng-supa-applicability-01
(work in progress), March 2017.
[I-D.ietf-supa-generic-policy-data-model] [I-D.ietf-supa-generic-policy-data-model]
Halpern, J. and J. Strassner, "Generic Policy Data Model Halpern, J. and J. Strassner, "Generic Policy Data Model
for Simplified Use of Policy Abstractions (SUPA)", draft- for Simplified Use of Policy Abstractions (SUPA)", draft-
ietf-supa-generic-policy-data-model-04 (work in progress), ietf-supa-generic-policy-data-model-04 (work in progress),
June 2017. June 2017.
[I-D.ietf-supa-generic-policy-info-model] [I-D.ietf-supa-generic-policy-info-model]
Strassner, J., Halpern, J., and S. Meer, "Generic Policy Strassner, J., Halpern, J., and S. Meer, "Generic Policy
Information Model for Simplified Use of Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
 End of changes. 21 change blocks. 
35 lines changed or deleted 52 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/