Network Working Group                                          M. Klyus
Internet Draft                                               NetCracker
Intended status: Standard Track                            J. Strassner
Expires: December 2015                              Huawei Technologies


                                                           June 6, 2015

                           SUPA Proposition
                    draft-klyus-supa-proposition-00

Abstract

   The rapid increase in enterprise and service provider network
   architecture complexity makes operating and managing services
   much more difficult. Simplified Use of Policy Abstractions
   (SUPA) defines a generic policy information model, and
   associated generic YANG data models, for different types of
   policy rules that control managed entities throughout the
   service development and deployment lifecycle. It also defines a
   mapping by which the management and monitoring of network
   services can be done using standardized policy rules.

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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current
   Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."



Klyus, et al.          Expires September 6, 2015               [Page 1]


Internet-Draft            SUPA - Proposition                  June 2015

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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.

Table of Contents

   1. Introduction .................................................. 3
      1.1. Problem Statement ........................................ 4
      1.2. Requirements ............................................. 6
   2. Terminology ................................................... 7
   3. Framework for Generic Policy-based Management ................. 9
      3.1. Overview ................................................. 9
      3.2. Functional Entities ..................................... 12
         3.2.1. Service Management ................................. 12
         3.2.2. Network Manager/Controller ......................... 12
         3.2.3. Network Elements ................................... 14
      3.3. Generic Management Policy Information Model ............. 14
      3.4. Refinement of the SGPIM ................................. 15
         3.4.1. Event-Condition-Action Policy Information Model .... 15
         3.4.2. Declarative Policy Information Model ............... 15
         3.4.3. Data Model Mappings ................................ 15
   4. Application of Generic Policy-based Management ............... 15
      4.1. Declarative Example ..................................... 16
      4.2. ECA Example ............................................. 16
      4.3. ECA plus Declarative Example ............................ 17
   5. Related Work ................................................. 18
      5.1. Related Work within the IETF ............................ 18
         5.1.1. I2RS Working Group ................................. 18
         5.1.2. L3SM Working Group ................................. 18
         5.1.3. ALTO Working Group ................................. 18
         5.1.4. TEAS Working Group ................................. 19
         5.1.5. BESS Working Group ................................. 19
         5.1.6. SFC Working Group .................................. 20
         5.1.7. NVO3 Working Group ................................. 20
         5.1.8. ACTN Working Group ................................. 20


Klyus, et al.           Expires December 6, 2015               [Page 2]


Internet-Draft            SUPA - Proposition                  June 2015


      5.2. Related Work outside the IETF ........................... 21
         5.2.1. TM Forum ........................................... 21
         5.2.2. MEF ................................................ 22
         5.2.3. Open Daylight ...................................... 23
         5.2.4. Open Networking Foundation ......................... 23
         5.2.5. OpenStack .......................................... 23
         5.2.6. The NEMO Project ................................... 24
         5.2.7. The Floodlight Project ............................. 25
         5.2.8. The ONOS Project ................................... 25
      5.3. Technical Implementation Scenarios ...................... 25
   6. Framework Summary ? Features and Benefits .................... 25
   7. Security Considerations ...................................... 26
   8. IANA Considerations........................................... 26
   9. Acknowledgments .............................................. 26
   10. References .................................................. 26
      10.1. Normative References ................................... 26
      10.2. Informative References ................................. 26

1. Introduction

   Network operators, including Internet Service Providers,
   Datacenters operators and others, are under constant pressure
   to optimize the usage of their installed network resources
   while maintaining high availability, complexity and deploying
   new services at an ever-increasing pace. The introduction of
   new paradigms aims at reducing these efforts, optimized network
   resource usage and minimize operational overhead. Such a new
   paradigm is the deployment of automated network configuration
   and optimization through the use of two complementary
   mechanisms that are software abstractions to simplify
   monitoring and control operations and the increase in
   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.

   Management applications would benefit from a view of the
   network that is adapted to their needs and from a policy
   framework that is efficient and simple to use. Several
   organizations have started working on protocols and models to
   be used between controllers and network devices, either
   physical ones or virtualized. This work started some years ago
   in a number of different organizations and has spawned a large
   amount of interest in the networking community.

   However the definition of interfaces between controllers and
   applications, the so-called "northbound" side, has seen a lot
   less progress during the same time. There's a need for
   management applications to interface with controllers in a


Klyus, et al.           Expires December 6, 2015               [Page 3]


Internet-Draft            SUPA - Proposition                  June 2015


   simple and elegant way. For this purpose, applications require
   a way to express their requirements in the form of simple
   policy statements applied to network elements. These network
   elements should be as simplified (abstracted) as possible for
   their manipulation by the application.

   The responsibility of providing an abstract and simple view
   adapted to each application need is the burden of the
   controller. The goal of the Simplified Use of Policy
   Abstractions (SUPA) group is to develop a methodology by which
   network services can be managed and automated by using a set of
   information policy model and how these model can map to YANG-
   based service and policy data models. It also focus on how to
   communicate these policy models. SUPA will focus in the first
   phase on inter-datacenter traffic management as part of the
   distributed data center use case, including the set of
   information models required to construct an extensible, policy-
   based framework.

   These information models will lead to a set of core YANG data
   models for a policy-based management framework to monitor and
   control network services.

1.1. Problem Statement

   Network operators are faced with networks of increasing size
   and complexity while trying to improve their quality and
   availability, as more and more business services depend on them.
   Software abstractions simplify the design and configuration of
   monitoring and control operations, and enable more powerful
   programmatic control (often called software-defined) to be
   exerted. These are considered by many network operators as an
   essential tool toward the management of that complexity.

   Providing means to network operators to (1) express policies on
   top of arbitrary configuration data models and (2) represent
   and use multiple types of policy rules, enable significant
   improvements in configuration agility, error detection and
   uptime for operators.

   This section describes the problems that need to be addressed
   in order to equip service providers with a generic policy-based
   management model that can represent multiple types of policy
   rules to quickly and dynamically manage their offering of
   network services.

   The rapid growth in the variety and importance of traffic
   flowing over increasingly complex enterprise and service


Klyus, et al.           Expires December 6, 2015               [Page 4]


Internet-Draft            SUPA - Proposition                  June 2015


   provider network makes the task of network operations and
   management applications and of deploying new services much more
   difficult.

   This is a significant challenge that network operators (service
   providers, SME, etc) face today.

   Several mechanisms can be used to deal with this challenge. The
   main ones are: (1) the use of software abstractions to simplify
   the design and configuration of monitoring and control
   operations and (2) the use of programmatic control over the
   configuration and operation of such networks. The combination
   of these mechanisms can (1) provide additional and significant
   benefits in design and deployment agility and (2) be used to
   define a generic policy-based management model.

   In particular, the power of policy management is its
   applicability to many different types of systems. Many
   different types of actors can be identified that can use a
   policy management system, including applications, end-users,
   developers, network administrators and operators. Each of these
   actors, typically, has different skills and uses different
   concepts and terminologies. For example, an operator may want
   to express that only Platinum and Gold users can use streaming
   and interactive multimedia applications. As a second example,
   an operator may want to define a more concrete policy rule that
   looks at the number of dropped packets. If, for example, this
   number exceeds a certain threshold value, then the applied
   queuing, dropping and scheduling algorithms could be changed in
   order to reduce the number of dropped packets.

   Both examples can be referred to as "policy rules", but they
   take very different forms, since they are at very different
   levels of abstraction and likely authored by different actors.
   The first example described a very abstract policy rule, and
   did not contain any technology-specific terms, while the second
   example included a more concrete policy rule and likely used
   technical terms of a general (e.g., IP address range, port
   numbers) as well as vendor-specific nature (e.g., specific
   algorithms implemented in a particular device). Furthermore,
   these two policy rules could affect each other. For example,
   Gold and Platinum users might need different device
   configurations to give the proper QoS markings to their
   streaming multimedia traffic. This is very difficult to do if a
   common policy framework does not exist.

   It needs to be mentioned that there are ongoing policy modeling
   efforts in IETF. However, all these policy modeling efforts can


Klyus, et al.           Expires December 6, 2015               [Page 5]


Internet-Draft            SUPA - Proposition                  June 2015


   be characterized as being technology-specific. This means that
   the IETF needs to reinvent the wheel in different colors (i.e.,
   policy models that apply for a specific technology) several
   times.

   SUPA will address these challenges by:

    (1) developing an information model fragment for defining
        standardized policy rules at different levels of abstraction,
    (2) specifying how to map this information fragment into
        corresponding YANG [RFC6020] and [RFC6991], data models to
        define interoperable implementations that can exchange and
        modify generic policies using protocols such as
        NETCONF/RESTCONF on the interface north of the controller
        (or other similar management entity) and south of the
        service manager.

   Specifically, three information model fragments are envisioned:

     (a) a generic policy information model (GPIM) that defines
      concepts needed by policy management independent of the form
      and content of the policy

     (b) a more specific information model that refines the
      generic information model to specify how to build policy
      rules of the event-condition-action (ECA) paradigm

     (c) a more specific information model that refines the
      generic information model to specify how to build policy
      rules that declaratively specify what goals to achieve (but
      not how to achieve those goals); this is often called
      "intent-based" policy

1.2. Requirements

   In order to satisfy the challenges mentioned in Section 1.1 and
   the goal of the DDC use case briefly described in section 5.3,
   the following requirements need to be addressed:

      o) Specify a generic and non-technology specific policy
      information model.

      o) Specify a more specific information model that defines
      how to build policy rules of the event-condition-action
     (ECA) paradigm.

      o) Specify a more specific information model that defines
      how to build policy rules that declaratively specify what


Klyus, et al.           Expires December 6, 2015               [Page 6]


Internet-Draft            SUPA - Proposition                  June 2015


      goals (what intents) to achieve using the Goal (Intent)
      policy paradigm.

      o) Specify how to map the above mentioned information models
      into corresponding YANG standardized data models to define
      interoperable implementations that can exchange and modify
      generic policies using protocols such as NETCONF/RESTCONF on
      the interface north of the controller (or other similar
      management entity) and south of the service manager.


2. Terminology

   This section defines acronyms and terms used in the rest of
   this document.

   NE                     Network Element
   NC                     Network Controller
   NM                     Network Manager
   NS                     Network Service

   Some of definitions are based on [RaBe11] and/or [Stras02].

   Network Service: the composition of network functions as
   defined by its functional and behavioral specification. A
   network service is characterized by performance, dependability,
   and security specifications. Furthermore, a network service is
   delivered by network service endpoints, which may be
   aggregations of multiple lower-layer technology specific
   endpoints.

   Network Element: a physical or virtual entity that implements
   one or more network function(s). NEs can interact with local or
   remote network controllers in order to exchange information,
   such as configuration information and status.

   Service specific abstraction: an abstract view of the service
   topology, associated with a specific network service type, e.g.,
   inter-datacenter communication services

   Policy: a definite goal, course, or method of action to guide
   and determine present and future decisions. Policies are
   implemented or executed within a particular context.

   SUPA policy: a means to monitor and control the changing and/or
   maintaining of the state of one or more managed entities.




Klyus, et al.           Expires December 6, 2015               [Page 7]


Internet-Draft            SUPA - Proposition                  June 2015


   Policy-based management: the usage of policy rules to manage
   one or more entities.

   Information Model: a representation of managed objects and
   their relationships that is independent of data repository,
   language, and protocol.

   Data Model: a representation of managed objects and their
   relationships that is dependent on data repository, language,
   and/or protocol (typically all three).

   Policy Rule: A container that uses metadata to define how the
   content is interpreted, and hence, how the behavior that it
   governs is defined separates the content of the policy from its
   representation provides a convenient control point for OAMP
   operations.

   Policy condition: a representation of the necessary state
   and/or prerequisites that define whether a policy rule?s
   actions should be performed.

   Policy action: defines what is to be done to enforce a policy
   rule when its conditions are met.

   Event Condition Action policy: reactive behavior of a system
   that correlates a set of events, a set of conditions, and a set
   of actions. Conditions are evaluated on the occurrence of an
   event and which determine whether the policy is applicable or
   not for that particular situation. Furthermore, the actions are
   only executed only if the conditions are met.

   Goal (Intent) policy rule (also called a declarative policy
   rule, or an intent-based policy rule): a declarative statement
   that defines what the policy should do, but not how to
   implement the policy.

   Model Mapping: a translation from one type of model to another
   type of model. Model mapping changes the representation and/or
   level of abstraction used to another representation and/or
   level of abstraction. The most common form of model mapping is
   from an information model to a data model; another important
   form is from a vendor-neutral data model to a vendor-specific
   data model.







Klyus, et al.           Expires December 6, 2015               [Page 8]


Internet-Draft            SUPA - Proposition                  June 2015


3. Framework for Generic Policy-based Management

   The SUPA policy framework defines a set of consistent,
   flexible, and scalable mechanisms for monitoring and
   controlling resources and services. It may be used to create a
   management and operations interface that can enable existing
   IETF frameworks, including but not limited to I2RS and L3SM. It
   allows resources and services to be controlled and monitored in
   a unified way that is independent of technology and vendor.
   Resource and service management become more effective, because
   policy defines the context that different operations, such as
   configuration, are applied to.

3.1. Overview

   <insert explanation of Figure 1>

  +-----------------------------------------------------------------
  |                       Service Management                        |
  |              +----------------------------------+               |
  |              | Generic Policy Information Model |               |
  |              +----+------------------------+----+               |
  |                   D                        R                    |
  |                   D                        R                    |
  |                  \ /                      \ /                   |
  | +---------------------------+ +-------------------------------+ |
  | | Generic Policy Data Model | | Service Management Data Model | |
  | +---------------------------+ +---------------+---------------+ |
  |             / \                              / \                |
  |              |                                |                 |
  |              |        NETCONF/RESTCONF        |                 |
  |              +----+----------------------+----+                 |
  |                   C                      C                      |
  |                   C                      C                      |
  |                  \ /                    \ /                     |
  |  +----------------+-----------+  +-------+--------------------+ |
  |  | Network Manager/Controller |  | Network Manager/Controller | |
  |  |   +--------------------+   |  |   +---------------------+  | |
  |  |   |  Network Resource  |   |  |   |    Network Resource |  | |
  |  |   |     Data Model     |   |  |   |       Data Model    |  | |
  |  |   +--------------------+   |  |   +---------------------+  | |
  |  +----------------------------+  +----------------------------+ |
  +------+---+---+-------------------------+---+---+----------------+
        / \ / \ / \                       / \ / \ / \


Klyus, et al.           Expires December 6, 2015               [Page 9]


Internet-Draft            SUPA - Proposition                  June 2015


         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 1 SUPA Framework
   In Figure 1:
     A double-headed arrow with Cs means communication;
     A double-headed arrow with Ds means derived from;
     A double-headed arrow with Rs means references;

   An overview of the SUPA framework is shown in Figure 1. The
   network entities used in this framework are:

     SM: Service Management, which represents one or more network
     entities that are running and controlling network services. This
     model contains the following entities:

      Generic Policy Information Model: a model for defining policy
      rules that are independent of data repository, data definition,
      query, and implementation languages, and protocol.

      Generic Policy Data Model: a model of policy rules for that
      are dependent of data repository, data definition, query, and
      implementation languages, and protocol.

      Examples of policy information models can be found in
      [ID.draft-strassner-supa-generic-policy-info-model] and
      [ID.draft-bi-supa-policy-model].

      There can be various types of policies, including service
      specific policies and network-wide policies. There can be a
      centralized and/or distributed entity or set of entities that
      are responsible for the creation, management, and retirement
      policy rules, which is known as a policy manager. The policy
      manager can be located in the SM or in a separate location.

      Policy data models now considered by SUPA take two forms:
      (1) ECA (event, condition, action) and (2) declarative (also
      known as intent-based), as described in
      [ID.draft-strassner-supa-generic-policy-info-model]. This may



Klyus, et al.           Expires December 6, 2015              [Page 10]


Internet-Draft            SUPA - Proposition                  June 2015


      be extended in the future.

      Service Management Data Model: a model of the network service
      (e.g., VPNs) and resources (e.g., a device interface) required
      by the network service to be correctly deployed and executed
      on the physical and/or virtual topology.

      An example of a service management data model can be found in
      [ID.draft-zaalouk-supa-vpn-service-management-model].

      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 (NEs)).

      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].

      SUPA will not define network resource data models, which is
      out of the scope of SUPA. SUPA will make use of network
      resource data models defined by other WGs or SDOs.

      Network Element (NE), which handles packets based on the network
      management and controlling procedures. NEs can interact with
      local or remote NM/NC in order to exchange information, such as
      configuration information, policy enforcement capabilities, and
      network status.


   Service Management (SM) communicates with the NM/NC using an
   appropriate protocol, such as NETCONF [RFC6241] or RESTCONF
   [ID.draft-ietf-netconf-restconf].

   NM/NC exchanges configuration information with NEs and derives the
   current network topology that contains the NEs, and also the
   capabilities and status of NEs, which will be stored in network



Klyus, et al.           Expires December 6, 2015              [Page 11]


Internet-Draft            SUPA - Proposition                  June 2015


   resource data model. NM/NC may also communication with a network
   management system to retrieve the above information. It can use
   existing network management and signaling protocols, such as I2RS
   [I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf-
   restconf], etc.

   Service Management (SM) will send policy rules and associated data
   (e.g., service management data), both in the form of a data model,
   To the NM/NC. The NM/NC will (in conjunction with network resource
   data models) then produce NE configurations.

3.2. Functional Entities

3.2.1. Service Management

    There are a wide variety of communication services offered by
    service providers.

    The Service Management (SM) is a functional entity, residing at
    the Application layer, which enables network services, such as:
          o) Network services (e.g., L2VPN, L3VPN, etc.)
          o) application-specific policies

    SM will push service management data model and policy data model
    to NM/NC for service deployment.


3.2.2. Network Manager/Controller

                           |
                           | to/from Service Management
                           |
+--------------------------+----------------------------------------+
|  Network Manager/Controller Functional Block                      |
|  +-------------------------------+  +---------------------------+ |
|  |    NM/NC to SM Interface      |  | mapping: Policy Data      | |
|  +-------------------------------+  | Model + Network Resource  | |
|                                     | Data Model to Service     | |
|  +-------------------------------+  | Specific Topology         | |
|  |                               |  +---------------------------+ |
|  |  Network Resource Data Model  |                                |
|  |                               |  +---------------------------+ |
|  +-------------------------------+  | mapping: Service Data     | |



Klyus, et al.           Expires December 6, 2015              [Page 12]


Internet-Draft            SUPA - Proposition                  June 2015


|                                     | Model + Service Specific  | |
|  +-------------------------------+  | Topology to Detail NEs'   | |
|  |    NM/NC to NE Interface      |  | Configurations            | |
|  +-------------------------------+  +---------------------------+ |
+-------------------------------------------------------------------+
             Figure 2   NM/NC Functional Blocks

   Network Manager/Controller (NM/NC) is a functional entity that is
   able to generate and maintain desired and current topologies of
   the network infrastructure. As part of this process, it is also
   responsible for reserving and releasing network resources that are
   required to support network services in a given network
   infrastructure.

   The NM/NC contains a set of data models, functions and APIs,
   including:

   o) Network Resource Data Model
    Maintain an up to date topology of the network infrastructure,
    including capabilities and current status of NEs.

   o) Mapping: service specific topology
    This mapping procedure will combine the policy data model and
    service management data model and generate a specific topology.

   o) Mapping: target NE(s) detail configurations
    This mapping procedure will use the service specific topology
    generated in the previous procedure and the service management
    data model to generate detail NE(s) configurations.

   o) NM/NC to traditional network management system interface:
    provides the interface with existing network management system
    protocols (e.g., I2RS [I2RS], NETCONF, etc.) to request
    configuration and status information, and push configuration
    changes to NEs.

   o) NM/NC to SM interface: used to support the communication
    between the SM and NM/NC. The candidate protocols used for this
    purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft-
    ietf-netconf-restconf].





Klyus, et al.           Expires December 6, 2015              [Page 13]


Internet-Draft            SUPA - Proposition                  June 2015


   An example of the mapping procedures can be that, a service
   requires that a link from A to B is created; and the policy
   requires that the hops of this link should not exceed N. Then when
   NM/NC receives the policy data model and service management data
   model from SM, it will first apply the policy data model to the
   network resource data model and get a sub-set topology which can
   fulfill the hops limit requirements. Then NM/NC will further
   generate detail configurations for target NE(s). The mapping
   procedures can be enforced by functional entity called policy
   agent.

   After the service is deployed, if there is a network topology
   change, network configurations for this service may need to be
   updated accordingly. A possible solution is to repeat the mapping
   procedures, and generate configurations for NEs (maybe another set
   of NEs). This requires that NM/NC maintains a copy of the service
   management data models and policy data models.

   For more detail about mapping mechanisms, please refer to
   [ID.draft-pentikousis-supa-mapping].


3.2.3. Network Elements

   The Network Element (NE) responds to requests and commands from
   the NM/NC and makes corresponding configuration changes. An NE may
   be a physical or a virtual entity, and is locally managed (e.g.,
   via CLI, SNMP, or NETCONF).

   SUPA will specify mechanisms, in order to enable the NEs to
   interact with either local or remote network management systems.
   The interaction may include the exchange of information, such as
   configuration and status information. The NEs will be able to push
   this information in an event that the NM/NC can subscribe to,
   and/or provide this information after receiving a request from the
   NM/NC.

3.3. Generic Management Policy Information Model

   The purpose of the SUPA Generic Policy Information Model (SGPIM)
   is to define a common framework for expressing policies at
   different levels of abstraction. SUPA uses the SGPIM as a
   common vocabulary for representing concepts that are common to
   expressing policy, but which are independent of language,


Klyus, et al.           Expires December 6, 2015              [Page 14]


Internet-Draft            SUPA - Proposition                  June 2015


   protocol, repository, and level of abstraction. This enables
   different policies at different levels of abstraction to form a
   continuum, where more abstract policies can be translated into
   more concrete policies, and vice-versa.

3.4. Refinement of the SGPIM

   An information model is abstract. As such, it cannot be
   instantiated (i.e., objects cannot be created directly from
   it).
   Therefore, SUPA defines a mapping from its information model to
   two different data models (which can be instantiated). These
   two data models represent two different forms of policy rules,
   with two different sets of semantics. One is an event-
   condition-action (ECA) form, while the other is a declarative,
   or logic-based, form. This provides two different types of
   abstractions that serve different use cases. It also helps
   prove the genericity of the SGPIM.

3.4.1. Event-Condition-Action Policy Information Model

   The SUPA ECA Policy Rule Information Model (EPRIM) represents a
   policy 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.

3.4.2. Declarative Policy Information Model

   The SUPA Logic Statement Information Model (SLSIM) is a set of
   (logic-based) propositions that form a (single) conclusion. A
   proposition is either TRUE or FALSE. A proposition be created
   from simpler propositions. This version of the SGPIM defines
   two forms of SUPA Logic Statements: one using propositional
   logic, and one using first order logic.

3.4.3. Data Model Mappings

   The SGPIM defines concepts common to any type of policy rule or
   statement. It is used in combination with the EPRIM or the
   SLSIM to create a reusable model of a policy. This combined
   information model is then mapped to a YANG data model.

4. Application of Generic Policy-based Management

   This section provides examples of how SUPA can be used to
   define different types of policies. Examples applied to various



Klyus, et al.           Expires December 6, 2015              [Page 15]


Internet-Draft            SUPA - Proposition                  June 2015


   domains, including access control, routing, and service
   function chaining, are also included.

4.1. Declarative Example

   Declarative policies are policies that describe what to do, but
   not how to do it. Declarative policies can apply to services
   and/or resources. Here are some simple examples:

      Access to source code servers is limited to Intranet users.

   The above policy does not specify ports, protocols, IP addresses,
   or other specific technology. Furthermore, it is not limited to
   any one specific user or application.

      Periodically perform workload consolidation if average CPU
      utilization falls below X%.

   Again, note the lack of technology-specific references in the
   policy.

      Proactively monitor Gold Service users to ensure their SLAs
      are not violated.

   In the above policy, Gold Service is an aggregation of different
   traffic types, each with different constraints. The policy will
   dynamically create a service function chain based on the current
   context to ensure that the customer's SLA is not violated.

4.2. ECA Example

   ECA equivalents to the above three examples follow.

      Access to source code servers is limited to Intranet users.

         Event:     access request to code server received
         Condition: is connection type intranet based
         Action:    no: deny; yes: accept

      Periodically perform workload consolidation if average CPU
      utilization falls below X%.

         Event:     alarm or periodic time period check
         Condition: CPU utilization level comparison
         Action:    no violation: no action
                    violation:
                      1) determine workload profile in time interval
                      2) determine complementary workloads (e.g.,


Klyus, et al.           Expires December 6, 2015              [Page 16]


Internet-Draft            SUPA - Proposition                  June 2015


                         whose peaks are at different times in day)
                      3) combine workloads (e.g., using integer
                         programming)

      Proactively monitor Gold Service users to ensure their SLAs
      are not violated.

         Event:     alarm or periodic time check
         Condition: is SLA metric set in danger of being violated
         Action:    no: no action
                    yes: based on metric(s) being violated, take
                    one or more actions such as remark, change
                    queuing, dropping, and/or scheduling parameters
                    (or even the algorithm), create new service to
                    offload traffic, etc.

   In the above examples, the event, condition, and/or action
   clauses are typically expressed using technology-specific
   concepts. This is in direct contrast to their declarative
   equivalents.

4.3. ECA plus Declarative Example

   The fundamental reason that SUPA defines two different types of
   policy rules is to enable different actors to express policy in
   a manner conducive to their role. The SGPIM defines concepts
   that are common to both the EPRIM and the SLSIM. This enables
   these two types of policies to be used together to provide a
   more powerful description.

   For example, consider the second example above. The declarative
   policy is conceptually more abstract than its ECA counterpart,
   since the declarative version expresses intent without defining
   which specific managed entities are affected. The execution of
   the declarative example could result in one or more ECA policy
   rules being triggered. Similarly, an ECA policy rule could
   trigger additional ECA policy rules to be evaluated.

   The advantage of this approach is that policy, along with
   metadata, can be used to dynamically decide which service
   functions to insert into a path (instead of being restricted to
   a fixed, linear set of service functions).








Klyus, et al.           Expires December 6, 2015              [Page 17]


Internet-Draft            SUPA - Proposition                  June 2015


5. Related Work

5.1. Related Work within the IETF

5.1.1. I2RS Working Group

   I2RS defines an interface that interacts with the routing
   system using a collection of protocol-based control or
   management interfaces. Users of I2RS interfaces are typically
   management applications and controllers. SUPA is an I2RS
   client, and does not directly interface to the routing system.
   Rather, SUPA uses data produced by I2RS (e.g., topological
   information) to construct its policies.

   The SUPA use case involved distributed data center
   interconnection; this use case defines a multi-tenant
   environment, where each tenant may control and monitor its
   network, even if that network may be physically located in a
   different data center. In contrast, I2RS defines interfaces to
   routing system (i.e., the collection of entities, protocols,
   and processes that collectively build the forwarding tables
   that are exported to the network's forwarding plane).

   It is envisioned that SUPA will use work produced by I2RS. SUPA
   may also provide policies that can be used by I2RS to monitor
   and control the routing system. Since both SUPA and I2RS uses
   YANG data models, communication between the two groups is
   facilitated.

5.1.2. L3SM Working Group

   L3SM defines an L3 VPN service model that can be used for
   communication between customers and network operators. This
   model enables customers to configure the network elements via
   L3 VPN technologies. In contrast, SUPA defines policies that
   are independent of a specific type of service, and hence
   conceptually, provides policies that define the configuration
   requirements for L3 VPN models that L3SM then implements. Both
   SUPA and L3SM use YANG data models.

5.1.3. ALTO Working Group

   The ALTO working group defined an architecture for exposing
   topology information, more specifically the cost of paths
   through an infrastructure, as defined in [RFC7285]. ALTO
   services are able to provide network maps defined as groups of
   endpoints. Endpoints are provider-defined entities, and can
   therefore represent any granularity of network, from the


Klyus, et al.           Expires December 6, 2015              [Page 18]


Internet-Draft            SUPA - Proposition                  June 2015


   physical to groups of networks following similar paths or
   restraints. Although this model can represent different levels
   of abstraction at multiple granularities, it is not clear if it
   could be adapted easily for other purposes than providing cost
   maps in the context of ALTO. The ALTO model is meant to be used
   outside of the trust domain of an ISP by external clients.

   SUPA does not generate data that is similar to ALTO. Rather,
   SUPA could use ALTO data as part of its policies to configure
   services and/or resources. SUPA could also interact with ALTO
   by defining policies that tell the host which ALTO server to
   use.

5.1.4. TEAS Working Group

   The Traffic Engineering Architecture and Signaling working
   group is responsible for defining MPLS- and GMPLS-based Traffic
   Engineering architectures that enable operators to control how
   specific traffic flows are treated within their networks. It
   covers YANG models for a traffic engineering database, in
   coordination with other working groups (I2RS) providing YANG
   models for network topologies.

   Both TEAS and SUPA use YANG data models. SUPA does not generate
   traffic engineering (TE) data. However, SUPA could use TE data
   as part of its policies for configuring resources and/or
   services.

   SUPA could also define policies that define which service,
   path, and link properties to use for a given customer, and
   consequently, which protocol extensions to use. TEAS data could
   also be used to enable operators to define how particular
   traffic flows are treated in a more abstract (but still
   consistent) manner.

5.1.5. BESS Working Group

   The BGP Enabled Services defines and extends network services
   that are based on BGP. This includes BGP/MPLS IP provider-
   provisioned L3VPNs, L2VPNs, BGP-enabled VPN solutions for use
   in data center networking, and extensions to BGP-enabled
   solution to construct virtual topologies in support of services
   such as Service Function Chaining. The working group is also
   chartered to work on BGP extensions to YANG models and data
   models for BGP-enabled services.

   Both BESS and SUPA use YANG data models. SUPA does not generate
   BGP configurations. However, SUPA could use data defined by


Klyus, et al.           Expires December 6, 2015              [Page 19]


Internet-Draft            SUPA - Proposition                  June 2015


   BESS as part of its policies for configuring resources and/or
   services.

   SUPA could also define policies that define that govern
   different aspects of services defined by BESS.

5.1.6. SFC Working Group

   The Service Function Chaining (SFC) working group defines a
   mechanism where traffic is classified; that classification is
   then use to select an ordered set of services to pass the
   traffic through.

   Both SFC and SUPA use YANG data models. SUPA could define
   policies that augment the functionality of SFC in several
   different ways, including: (1) path selection based on context,
   (2) which set of mechanisms to use to steer traffic through
   which set of service functions, (3) simplify the definition of
   dynamic service function chains (e.g., service paths that
   change based upon a set of data that is discovered at runtime),
   and (4) scalable mechanisms to monitor and control the
   configuration of SFC components.

5.1.7. NVO3 Working Group

   The NVO3 group proposes a way to virtualize the network edge
   for data centers in order to be able to move virtual instances
   without impacting their network configuration. This is realized
   through a centrally controlled overlay layer-3 network. The
   NVO3 work is not about defining policy information.

   Both NVO3 and SUPA use YANG data models. SUPA could define
   policies that define how the logically centralized network
   virtualization management entity (or entities) of NVO3 behave
   (e.g., the functions in the network virtualization control
   plane).

5.1.8. ACTN Working Group

   The ACTN proposed work, as described in [actn] framework, has
   two main goals, the abstraction of multiple optical transport
   domains into a single controller offering a common abstract
   topology and the splitting of that topology into abstract
   client views, which are usually a fraction of the complete
   network. The ACTN work is therefore about unification of
   several physical controllers in a virtual one and also about
   the segmentation, isolation and sharing of network resources.
   The ACTN work is not explicitly about policies, but some level


Klyus, et al.           Expires December 6, 2015              [Page 20]


Internet-Draft            SUPA - Proposition                  June 2015


   of policing is applied in the creation of a client view and the
   way it interacts with the virtual controller beneath. One point
   where overlap may exist with some of the work proposed in SUPA
   is in the definition of multiple levels of abstract topologies.

   The ACTN proposed work, as described in [actn] framework, has
   two main goals, the abstraction of multiple optical transport
   domains into a single controller offering a common abstract
   topology, and the splitting of that topology into abstract
   client views, which are usually a fraction of the complete
   network. The ACTN work is therefore about unification of
   several physical controllers into a virtual one, and also about
   the segmentation, isolation and sharing of network resources.
   The ACTN work is not about defining policy information.

   Both SFC and SUPA use YANG data models. SUPA could define
   policies that define the behavior of the controller.

5.2. Related Work outside the IETF

5.2.1. TM Forum

   The TM Forum (a.k.a., the TeleManagement Forum) develops
   standards and best practices, research, and collaborative
   programs focused on digital business transformation. It
   consists of three major programs:

   1) Agile Business and IT

   2) Customer Centricity (experience)

   3) Open Digital Ecosystem

   Of these, the ZOOM (Zero-touch Orchestration, Operations, and
   Management) project, located in the Agile Business and IT
   project, is the main sub-project in this area that is of
   interest to SUPA.

   Within ZOOM, the Foundational Studies project contains work on
   an information model and management architecture that are
   directly relevant to SUPA. The Information Model, Policy, and
   Security working groups are involved in this work.

   The ZOOM information model updates the existing Shared
   Information and Data (SID) information model to add support for
   the management of physical and virtual infrastructure, event-
   and data-driven systems, policy management (architecture and



Klyus, et al.           Expires December 6, 2015              [Page 21]


Internet-Draft            SUPA - Proposition                  June 2015


   model), metadata for describing and prescribing behavior that
   can support changes at runtime, and access control.

   The policy information model defines event-condition-action
   (ECA), declarative (intent-based), utility function, and
   promise policies. The work in draft-strassner-supa-generic-
   policy-info-model-01 is based on this work. It currently
   extends the ECA model and provides additional detail not
   currently present in ZOOM; the next version of this draft will
   do the same for declarative policies.

   There is currently no plan to use the utility function and
   promise policies. Finally, it should be noted that the data
   model work planned for SUPA is not currently planned for the
   ZOOM project.

5.2.2. MEF

   MEF

   The MEF (originally named the Metro Ethernet Forum) develops
   architecture, service and management specifications related to
   Carrier Ethernet (CE). The CE architecture includes the
   definition of several interfaces specific to CE like the User
   Network Interface (UNI) and External Network Network Interface
   (ENNI). Specifications developed in this space include the
   definitions of CE services, CE service attributes, Ethernet
   Access Services, Class of Service, OAM and Management
   interfaces, Service Activation and Test.

   The more recent vision of the MEF related to the future of
   networking is described as The Third Network and includes plans
   to develop Lifecycle Service Orchestration with APIs for
   existing network, NFV and SDN implementations enabling Agile,
   Assured and Orchestrated Services. This stage of the MEF
   activity is now in early phases with focus on architectural
   work.

   The MEF has developed a number of Information and Data Models,
   and has recently started a project that used YANG to model and
   manage the services covered by the MEF. Although the MEF has
   created quite rigorous definitions of these services, these are
   transport technology specific, and they do not include and rely
   on policies.






Klyus, et al.           Expires December 6, 2015              [Page 22]


Internet-Draft            SUPA - Proposition                  June 2015


5.2.3. Open Daylight

   Open Daylight network controller implements a number of models
   through its service abstraction Layer (MD-SAL) based on draft
   IETF Yang models. Few of the below mentioned Open Daylight
   projects provides policy abstraction and better flexibility to
   the user.

5.2.3.1. Network Intent Composition (NIC)

   Network Intent Composition project aims at providing better
   flexibility and high-level interface for the specification of
   policies. The intents-based interface would provide a high
   level of abstraction easy to formulate by an application
   developer and completely detached from the underlying
   implementation details. By making intents portable and
   composable, the project aims at making intents a more scalable
   approach than existing interfaces.

5.2.3.2. Group Policy

   The group-based policy project defines an application-centric
   policy model for Open Daylight that separates information about
   application connectivity requirements from information about
   the underlying details of the network infrastructure.

5.2.4. Open Networking Foundation

   The ONF created a group responsible of defining northbound
   interfaces, but this hasn't lead to the publication of
   standards in this area so far. A blog entry on the ONF web site
   showed an interest in using the principle of intents at ONF,
   but no details were provided on the status of this project. The
   membership of this group being closed in nature, the status of
   current draft proposals is not known.

5.2.5. OpenStack

   OpenStack software controls large pools of compute, storage,
   and networking resources throughout a datacenter, managed
   through a dashboard or via the OpenStack API. OpenStack works
   with popular enterprise and open source technologies making it
   ideal for heterogeneous infrastructure. Few of the below
   mentioned OpenStack projects provides policy abstraction and
   better flexibility to the user.





Klyus, et al.           Expires December 6, 2015              [Page 23]


Internet-Draft            SUPA - Proposition                  June 2015


5.2.5.1. Group-Based Policies

   The Group-Based Policies project for OpenStack Neutron is built
   around entities assembled in Endpoints Groups (EPG) that
   provide or consume Contracts. Such Contracts are hierarchical
   entities containing policy rules. A first version was released
   in January 2015, based on the Juno release. This type of
   approach is more relational than declarative, but could be used
   to describe a large amount of possible scenarios. It has the
   advantage of providing a relatively simple policy model that
   covers a large applicability. From an OpenStack point of view,
   the scope of GBP is limited to networking within the Neutron
   module.

5.2.5.2. Congress

   The Congress project within OpenStack provides a way to
   formulate complex policies using the Datalog language, a
   derivate of Prolog. Datalog is entirely declarative and first-
   order logic, which gives it interesting properties, such as
   providing the same result no matter the order in which the
   statements are made. The language allows for the definition of
   types and for active enforcement or verification of the
   policies. Using Datalog also allows Congress to take advantage
   of the significant body of knowledge and experience relating to
   declarative languages and their implementation. The Congress
   policies aim at manipulating objects exposed by multiple
   OpenStack modules and is therefore larger in scope than network
   policying only. The only drawback of this approach lies in its
   potentially large computational complexity, which could limit
   its ability to react in real time fast events such as those
   relating to the network.

5.2.6. The NEMO Project

   The NEMO project is a research activity aiming at defining a
   simple declarative framework for networking. The NEMO syntax is
   not based on

   an existing language and covers the basic elements for network
   manipulation such as nodes, links and flows. The NEMO project
   has been successfully demonstrated at IETF-91, along with a
   companion graphical user interface, and this work now being
   proposed as the base for a new group called Intent-Based NEMO
   (IBNEMO) within the IETF.





Klyus, et al.           Expires December 6, 2015              [Page 24]


Internet-Draft            SUPA - Proposition                  June 2015


5.2.7. The Floodlight Project

   The Floodlight is an openflow enabled SDN controller. it uses
   another open source project called Indigo to support openflow
   and manage southbound devices. Indigo agent also supports
   abstraction layer to make it easy to integrate with physical
   and virtual switches. It supports configuration of abstraction
   layer so that it can configure openflow in hybrid mode.

5.2.8. The ONOS Project

   The ONOS is a SDN controller. It supports abstraction for both
   southbound and northbound interfaces. This is because NFV used
   in ONOS can reduce CaPex because each service can be
   virtualized, but it increases OpEx as service providers now
   have to contend with increased management complexity due to the
   management and orchestration of a large numbers of VMs on
   commodity servers, the management of network function software
   on the VMs and how VMs must be interconnected based on
   subscriber's service contract. This is why, ONOS uses Network
   Function as a Service (NFaaS) that not only virtualized the
   components and Virtual Network Functions (VNFs) but also
   introduces an abstractive unit for a collection of VMs and
   their interconnecting network(s). Being able to create and
   manipulate these units, rather than handling individual
   components, significantly simplifies operation. NFaaS
   manipulates these units in the enhanced form of a service.

5.3. Technical Implementation Scenarios

   Large scale Distributed Data Centers (DDCs) can provide various
   services and usually consist of many internal and external
   links where various VPNs are built upon.  The Service
   provisioning and network connectivity configurations could be
   complex and dynamic, for which manual configuration is not
   onerous and error-prone.
   The SUPA generic policy management models can be used to
   support the dynamic and automated resource usage and simplify
   and automate the service/network deployment/configuration of
   various VPN scenarios in the DDC environment. A more detailed
   description of this use case is provided in [ID.draft-cheng-
   supa-ddc-use-cases].

6. Framework Summary ? Features and Benefits




Klyus, et al.           Expires December 6, 2015              [Page 25]


Internet-Draft            SUPA - Proposition                  June 2015


7. Security Considerations

   TBD

8. IANA Considerations

This document has no actions for IANA.

9. Acknowledgments

This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in
alphabetical order: G. Karagiannis, J. Strassner, C. Zhou, Q. Sun,
Luis M. Contreras, Telefonica, P. Yegani, D. Romascanu, J. Bi

10. References

10.1. Normative References

   [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
   Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.

   [RFC6991] J. Schoenwaelder, "Common YANG Data Types", July 2013

   [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman,
   "Network Configuration Protocol (NETCONF)", June 2011

   [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

10.2. Informative References

   [SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P.
   Yegani, " The Framework of Simplified Use of Policy
   Abstractions (SUPA) ", IETF Internet draft, draft-zhou-supa-
   framework, February 2015.

   [SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M.
   Contreras, P. Yegani, JF Tremblay and J. Bi, "Problem Statement
   for Simplified Use of Policy Abstractions (SUPA)", IETF
   Internet draft, draft-karagiannis-supa-problem-statement,
   January 2015.

   [SUPA-gap-analysis] J. Bi, H.Rafiee, V,Choudhary, J.Strassner,
   D.Romascanu "Simplified Use of Policy Abstractions (SUPA) Gap
   Analysis", IETF Internet draft, draft-bi-supa-gap-analysis, May
   2015.


Klyus, et al.           Expires December 6, 2015              [Page 26]


Internet-Draft            SUPA - Proposition                  June 2015


   [SUPA-DDC] Y. Cheng, and JF. Tremblay, "Use Cases for Distributed
   Data Center Applications in SUPA", IETF Internet draft, draft-
   cheng-supa-ddc-use-cases, January 2015

   [RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal Specification of
   DomainSpecific ECA Policy Models", in Proc. 2011 Fifth IEEE
   International Conference on Theoretical Aspects of Software
   Engineering, 2011

   [Stras02] John Strassner, "DEN-ng: Achieving Business-Driven Network
   Management" in Proc. IEEE Network Operations and Management Symposium
   (NOMS), 2002.

Authors' Addresses


   Maxim Klyus, Ed.
   NetCracker
   Kozhevnicheskaya str.,7 Bldg. Nr. 1
   Moscow, Russia
   Phone: +7-916-8575717
   E-mail: klyus@netcracker.com

   John Strassner, Ed.
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA 95138 USA
   Email: john.sc.strassner@huawei.com

   Georgios Karagiannis
   Huawei Technologies
   Hansaallee 205,
   40549 Dusseldorf,
   Germany
   Email: Georgios.Karagiannis@huawei.com





Klyus, et al.           Expires December 6, 2015              [Page 27]

Internet-Draft            SUPA - Proposition                  June 2015

   Qiong Sun
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P.R. China
   Email: sunqiong@ctbri.com.cn

   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, Sur-3 building, 3rd floor
   Madrid  28050
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:http://people.tid.es/LuisM.Contreras/

   Parviz Yegani
   JUNIPER NETWORKS
   1133 Innovation Way
   Sunnyvale, CA 94089
   Email: pyegani@juniper.net

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen 518129
   P.R. China

   Jun Bi
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084
   China
   EMail: junbi@tsinghua.edu.cn

   Hosnieh Rafiee
   Huawei Technologies Duesseldorf GmbH
   Munich, Germany
   Phone: +49 (0)162 204 74 58
   E-mail: ietf@rozanak.com

   Vikram Choudhary
   Huawei Technologies
   E-mail: vikram.choudhary@huawei.com

   Dan Romascanu
   Avaya
   Atidim Technology Park, Bldg. #3
   Tel Aviv 61581, Israel
   Phone: +972-3-6458414
   E-mail: dromasca@avaya.com