--- 1/draft-liu-supa-policy-based-management-framework-01.txt 2016-07-21 17:16:15.758543081 -0700 +++ 2/draft-liu-supa-policy-based-management-framework-02.txt 2016-07-21 17:16:15.790543881 -0700 @@ -1,24 +1,24 @@ SUPA W.Liu Internet Draft J. Strassner Intended status: Informational G. Karagiannis Expires: January 2017 Huawei Technologies M. Klyus NetCracker J.Bi Tsinghua University C. Xie China Telecom - July 8, 2016 + July 22, 2016 SUPA policy-based management framework - draft-liu-supa-policy-based-management-framework-01.txt + draft-liu-supa-policy-based-management-framework-02 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -46,77 +46,82 @@ (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract - Simplified Use of Policy Abstractions (SUPA) defines a set of rules - that define how services are designed, delivered, and operated - within an operator's environment independent of any one particular - service or networking device. This document describes the SUPA basic - architecture, its elements and interfaces. + 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 1. Introduction ................................................ 2 2. Framework for Generic Policy-based Management ............... 3 2.1. Overview ............................................... 3 2.2. Operation .............................................. 8 2.3. The GPIM and the EPRIM ................................. 9 2.4. Creation of Generic YANG Modules ....................... 9 3. Security Considerations .................................... 10 4. IANA Considerations ........................................ 10 5. Contributors ............................................... 10 6. Acknowledgments ............................................ 10 7. References ................................................. 12 7.1. Normative References .................................. 12 7.2. Informative References ................................ 12 + Authors' Addresses ............................................ 14 1. Introduction The rapid growth in the variety and importance of traffic flowing over increasingly complex enterprise and service provider network architectures makes the task of network operations and management applications and deploying new services much more difficult. In addition, network operators want to deploy new services quickly and 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 + 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 can be used to express high-level network operator - requirements directly, or from a set of management applications, to - a network management or element system. The network management or - element system can then control the configuration and/or monitoring - of network elements and services. + 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. Simplified Use of Policy Abstractions (SUPA) will define a generic policy information model (GPIM) [SUPA-info-model] for use in network operations and management applications. The GPIM defines concepts and terminology needed by policy management indepednent of the form and content of the policy rule. The ECA Policy Rule Information Model (EPRIM) [SUPA-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 configuration and monitoring of network elements throughout the service development and deployment lifecycle. The GPIM and the EPRIM - will both be translated into corresponding YANG [RFC6020] modules - that define policy concepts, terminology, and rules in a generic and - interoperable manner; additional YANG modules may also be defined - from the GPIM and/or EPRIM to manage specific functions. + will both be translated into corresponding YANG [RFC6020][RFC6020bis] + modules that define policy concepts, terminology, and rules in a + generic and interoperable manner; additional YANG modules may also + be defined from the GPIM and/or EPRIM to manage specific functions. The key benefit of policy management is that it enables different network elements and services to be instructed to behave the same way, even if they are programmed differently. Management applications will benefit from using policy rules that enable scalable and consistent programmatic control over the configuration and monitoring of network elements and services. 2. Framework for Generic Policy-based Management @@ -124,78 +129,69 @@ policy-based management framework. 2.1. Overview Figure 1 shows a simplified functional architecture of how SUPA is used to define policies for creating network element configuration and monitoring snippets. SUPA uses the GPIM to define a consensual vocabulary that different actors can use to interact with network elements and services. The EPRIM defines a generic structure for imperative policies. The GPIM, as well as the combination of the - GPIM and EPRIM, are converted to generic YANG data modules. The - IETF produces the modules, and IANA is used to register the module - and changes to it. + GPIM and EPRIM, are converted to generic YANG data modules. In one possible approach, SUPA Generic & ECA Policy YANG Data modules together with the Resource and Service YANG data models specified in IETF (which define the specific elements that will be controlled by policies) are used by the Service Interface Logic. This Service Interface Logic creates appropriate input mechanisms for the operator to define policies (e.g., a web form or a script) for creating and managing the network configuration. The operator interacts with the interface, which is then translated to configuration snippets. 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 YANG data models for the Service Interface Logic to create appropriate input mechanisms for the operator to define policies. This transfers the work specified by the Resource and Service YANG data models specified in IETF into the Service Interface Logic, which is then translated to configuration snippets. +---------------------+ - +----------+ \| SUPA Generic Policy | - | IETF |---+----+ Information Model | - +----------+ | /| | + +----------+ \| SUPA | + | IETF |---+----+ Information Models | + +----------+ | /| GPIM and EPRIM | | +---------+-----------+ - | | Assignments | | Defines Policy Concepts - and Manage | | - Content | \|/ - | +---------+-----------+ - | \| SUPA GPIM and EPRIM | - +----+ Generic YANG | - /| Data Modules | + and Manage | \|/ + Content | +---------+-----------+ + | \| SUPA Generic | + +----+ & ECA Policy | + /| YANG Data modules | +---------+-----------+ - * - * Possible - * Approach - * - +--------------------------------*----------------------------------+ + * Possible Approach + +-----------------------------*-----------------------------+ | Management System * | - | * | | \*/ | - | Fills +----------+----------+ +---------------+ | - | +--------+ Forms \| Service Interface |/ | Resource and |/ | +------+ - | |Operator|----------+ Logic +----| Service YANG |------| IETF | - | +--------+ Runs /| (locally defined |\ | Data Models |\ | +------- - | Scripts | forms, scripts,...) | +---------------+ | - | +----------+----------+ | - | | | + | Fills +---------+---------+ +-------------+ | + | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ + | |Operator|--------+ Logic +--|Service YANG |----|IETF| + | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+ + | scripts |forms, scripts,...)| +-------------+ | + | +---------+---------+ | | \|/ | | +-------+--------+ | | | Local Devices | | | | and Management | | | | Systems | | | +----------------+ | - +-------------------------------------------------------------------+ + +-----------------------------------------------------------+ Figure 1 SUPA Framework 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, other actors (e.g., an application developer) that can interact with SUPA are not shown for simplicity. The EPRIM defines an Event-Condition-Action (ECA) policy as an example of imperative policies. An ECA policy rule is activated @@ -218,64 +214,56 @@ condition clause is then evaluated and, if true, signals 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 managed using policy. - +-----------------------------------------------------------------+ + OSS/BSS/Orchestrator + / \ + C + \ / + +------------------------------+----------------------------------+ | SUPA Policy Model | - | | | +----------------------------------+ | | | Generic Policy Information Model | | | +----+------------------------+----+ | - | D D | - | D \ / | + | D \D/ | | D +------------+--------------+ | | D | ECAPolicyRule Information | | | D | Model (EPRIM) | | | D +------------+--------------+ | | +----------------D------------------------D----------------+ | - | | D SUPA Policy Data Model D | | - | | \ / D | | + | | \D/ SUPA Policy DM D | | | |+---------------+-----------+ D | | | || Generic Policy Data Model | D | | | |+-------------------+-------+ D | | - | | D D | | - | | \ / \ / | | + | | \D/ \D/ | | | | +--+--------------------+--------------+ | | | | | ECA PolicyRule Data Model | | | | | +--------------------------------------+ | | | +------------------------------+---------------------------+ | - | | | - | | | +---------------------------------|-------------------------------+ - | - | NETCONF/RESTCONF +-------------+--------+ - C C - C C - \ / \ / + \C/ \C/ NETCONF/RESTCONF +----------------+-----------+ +-------+--------------------+ - | Network Manager/Controller | | Network Manager/Controller | - | +--------------------+ | | +---------------------+ | - | | Network Resource | | | | Network Resource | | - | | Data Model | | | | Data Model | | - | +--------------------+ | | +---------------------+ | + | EMS/NMS/Controller | | EMS/NMS/Controller | + | +---------------------+ | | +---------------------+ | + | | Network Service & | | | | Network Service & | | + | | Resource Data Models| | | | Resource Data Models| | + | +---------------------+ | | +---------------------+ | +---+---+---+----------------+ +-----+---+---+--------------+ / \ / \ / \ / \ / \ / \ C C C C C C - C C C C C C - C C C C C C \ / \ / \ / \ / \ / \ / NE1 NE2 NEn NE1 NE2 NEn Figure 2 SUPA Policy Model Framework 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: @@ -297,63 +285,67 @@ rule as a statement that consists of an event clause, a condition clause, and an action clause. This type of Policy Rule explicitly defines the current and desired states of the system being managed. This model is abstract and is used for design; it MUST be turned into a data model for implementation. ECA Policy Rule Data Model: a model of policy rules derived from EPRIM, consist of an event clause, a condition clause, and an action clause. - NM/NC: Network Manager / Controller, which represents one or more - entities that are able to control the operation and management of a - network infrastructure (e.g., a network topology that consists of - Network Elements). + EMS/NMS/Controller: represents one or more entities that are able + to control the operation and management of a network infrastructure + (e.g., a network topology that consists of Network Elements). - Network Resource Data Model: a model of the physical and virtual - network topology including the resource attributes (e.g., data rate - or latency of links) and operational parameters needed to support - service deployment over the network topology. An example of a - network resource data model can be found in [ID.draft-contreras- - supa-yang-network-topo]. + Network Service & Resource Data Models: models of the service as + well as physical and virtual network topology including the resource + attributes (e.g., data rate or latency of links) and operational + parameters needed to support service deployment over the network + topology. - Network Element (NE), which can interact with local or remote NM/NC - in order to exchange information, such as configuration information, - policy enforcement capabilities, and network status. + Network Element (NE), which can interact with local or remote + EMS/NMS/Controller in order to exchange information, such as + configuration information, policy enforcement capabilities, and + network status. Relationship among Policy, Service and Resource models can be 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 relies on and is able to adjust service - (2) policy relies on network ability provided by resource and is - able to adjust resource - (3) resource relies on network ability and is able to reserve and - consume/occupy resource + (1) policy manages and can adjust service behavior as necessary + (2) policy manages and can adjust resource behavior as necessary + (3) resource hosts service; changing resources may change service + behavior as necessary + + Policies are used to manage behavior. Policies can be applied to + 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 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 SUPA scope is limited to policy information and data models. @@ -421,40 +413,52 @@ Implementation; (3')= update of YANG data models; (2')=update of EPRIM; (1') = update of GPIM The YANG module derived from the GPIM contains concepts and terminology for the common operation and administration of policy- based systems, as well as an extensible structure for policy rules of different paradigms. The YANG module derived from the EPRIM extends the generic nature of the GPIM to represent policies using an event-condition-action structure. + The above sequence allows for the addition of new, as well as editing + of existing model elements in the GPIM and EPRIM. In practice, the + implementation sequence may be much simpler. Specifically, it is + unlikely that the GPIM will need to be changed. In addition, changes + to the EPRIM will likely be focused on fine-tuning the behavior + offered by a specific set of model elements. + 3. Security Considerations TBD 4. IANA Considerations This document has no actions for IANA. 5. Contributors The following people all contributed to creating this document, listed in alphabetical order: - TBD. + Ying Chen, China Unicom + Luis M. Contreras, Telefonica I+D + Dan Romascanu, Avaya + J. Schoenwaelder, Jacobs University, Germany + Qiong Sun, China Telecom 6. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in - alphabetical order: Andy Bierman. + alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern, Bert + Wijnen, Tianran Zhou. Part of the initial draft of this document was picked up from previous documents, and this section lists the acknowledgements from them. From "SUPA Value Proposition" [Klyus2016] The following people all contributed to creating this document, listed in alphabetical order: @@ -535,31 +539,34 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., Waldbusser, S., "Terminology for Policy-Based Management", RFC 3198, November, 2001 - [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. + [RFC6020bis] M. Bjorklund, "The YANG 1.1 Data Modeling Language", + IETF Internet draft, draft-ietf-netmod-rfc6020bis-14, June 2016. + [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy "Application-Layer Traffic Optimization (ALTO) Protocol", September 2014 - [SUPA-info-model] J. Strassner, J. Halpern, J. Coleman, "Generic + [SUPA-info-model] J. Strassner, J. Halpern, S. van der Meer, "Generic Policy Information Model for Simplified Use of Policy Abstractions - (SUPA)", IETF Internet draft, draft-strassner-supa-generic-policy- - info-model-04, February 2016 + (SUPA)", IETF Internet draft, + draft-ietf-supa-generic-policy-info-model-01, July 2016 [TR235] J. Strassner, ed., "ZOOM Policy Architecture and Information Model Snapshot", TR245, part of the TM Forum ZOOM project, October 26, 2014 [Karagiannis2015] G. Karagiannis, ed., "Problem Statement for Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft, draft-karagiannis-supa-problem-statement-07, June 5, 2015 [Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet @@ -567,47 +574,42 @@ [Zhou2015] C. Zhou, ed., "The Framework of Simplified Use of Policy Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015 Authors' Addresses Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District, Shenzhen 518129 P.R. China - Email: liushucheng@huawei.com John Strassner Huawei Technologies 2330 Central Expressway Santa Clara, CA 95138 USA - - Email: john.sc.strassner@huawei.com + Email: strazpdj@gmail.com Georgios Karagiannis Huawei Technologies Hansaallee 205, 40549 Dusseldorf Germany - Email: Georgios.Karagiannis@huawei.com Maxim Klyus NetCracker Kozhevnicheskaya str.,7 Bldg. #1 Moscow, Russia - E-mail: klyus@netcracker.com Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 P.R. China - Email: junbi@tsinghua.edu.cn Chongfeng Xie 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