< draft-klyus-supa-proposition-01.txt   draft-klyus-supa-proposition-02.txt >
Network Working Group M. Klyus Network Working Group M. Klyus
Internet Draft NetCracker Internet Draft NetCracker
Intended status: Standard Track J. Strassner Intended status: Standard Track J. Strassner
Expires: December 9, 2015 Huawei Technologies Expires: January 4, 2016 Huawei Technologies
June 9, 2015 July 4, 2015
SUPA Proposition SUPA Value Proposition
draft-klyus-supa-proposition-01 draft-klyus-supa-proposition-02
Abstract Abstract
The rapid growth in the variety and importance of traffic flowing The rapid growth in the variety and importance of traffic flowing
over increasingly complex enterprise and service provider network over increasingly complex enterprise and service provider network
architectures makes the task of network operations and management architectures makes the task of network operations and management
applications and deploying new services much more difficult. applications and deploying new services much more difficult.
Simplified Use of Policy Abstractions (SUPA) defines an interface Simplified Use of Policy Abstractions (SUPA) defines an interface
to a network management function that takes high-level, possibly to a network management function that takes high-level, possibly
network-wide policies as input and creates element configuration network-wide policies as input and creates element configuration
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Problem Statement.........................................4 1.1. Problem Statement.........................................4
1.2. Proposed Solution.........................................4 1.2. Proposed Solution.........................................4
1.3. Value of the SUPA Approach ...............................5 1.3. Value of the SUPA Approach ...............................5
2. Framework for Generic Policy-based Management..................6 2. Framework for Generic Policy-based Management..................6
2.1. Overview..................................................6 2.1. Overview..................................................6
2.2. Operation.................................................8 2.2. Operation.................................................8
2.3. Generic Policy Information Model..........................9 2.3. Generic Policy Information Model..........................9
2.4. Refinement of the GPIM...................................10 2.4. Refinement of the GPIM....................................9
2.4.1. Event-Condition-Action Policy Information Model.....10 2.4.1. Event-Condition-Action Policy Information Model.....10
2.4.2. Declarative Policy Information Model................10 2.4.2. Declarative Policy Information Model................10
3. Application of Generic Policy-based Management................10 3. Application of Generic Policy-based Management................10
3.1. Declarative Examples.....................................11 3.1. Declarative Examples.....................................10
3.2. ECA Examples.............................................12 3.2. ECA Examples.............................................12
3.3. ECA plus Declarative Example.............................14 3.3. ECA plus Declarative Example.............................13
4. Related Work..................................................15 4. Related Work..................................................14
4.1. Related Work within the IETF.............................15 4.1. Related Work within the IETF.............................14
4.1.1. I2RS Working Group..................................15 4.1.1. I2RS Working Group..................................14
4.1.2. L3SM Working Group..................................15 4.1.2. L3SM Working Group..................................15
4.1.3. ALTO Working Group..................................15 4.1.3. ALTO Working Group..................................15
4.1.4. TEAS Working Group..................................16 4.1.4. TEAS Working Group..................................15
4.1.5. BESS Working Group..................................16 4.1.5. BESS Working Group..................................16
4.1.6. SFC Working Group...................................16 4.1.6. SFC Working Group...................................16
4.1.7. NVO3 Working Group..................................17 4.1.7. NVO3 Working Group..................................16
4.1.8. ACTN Working Group..................................17 4.1.8. ACTN BoF (IETF-90)..................................17
4.1.9. Previous IETF Policy Models.........................17 4.1.9. Previous IETF Policy Models.........................17
4.2. Related Work outside the IETF............................17 4.2. Related Work outside the IETF............................17
4.2.1. TM Forum............................................18 4.2.1. TM Forum............................................17
4.2.2. MEF.................................................18 4.2.2. MEF.................................................18
4.2.3. Open Daylight.......................................19 4.2.3. Open Daylight.......................................18
4.2.4. Open Networking Foundation..........................19 4.2.4. Open Networking Foundation..........................19
4.2.5. OpenStack...........................................20 4.2.5. OpenStack...........................................19
4.2.6. The NEMO Project....................................21 4.2.6. The NEMO Project (Not a BoF Yet)....................20
4.2.7. The Floodlight Project..............................21 4.2.7. The Floodlight Project..............................21
4.2.8. The ONOS Project....................................21 4.2.8. The ONOS Project....................................21
5. Conclusions - Value of SUPA...................................21 5. Conclusions - Value of SUPA...................................21
6. Security Considerations.......................................22 6. Security Considerations.......................................22
7. IANA Considerations...........................................22 7. IANA Considerations...........................................22
8. Acknowledgments...............................................22 8. Acknowledgments...............................................22
9. Additional Authors List.......................................22 9. Additional Authors List.......................................22
10. References...................................................23 10. References...................................................22
10.1. Informative References..................................23 10.1. Informative References..................................22
1. Introduction 1. Introduction
The rapid growth in the variety and importance of traffic The rapid growth in the variety and importance of traffic flowing
flowing over increasingly complex enterprise and service over increasingly complex enterprise and service provider network
provider network architectures makes the task of network architectures makes the task of network operations and management
operations and management applications and deploying new applications and deploying new services much more difficult. In
services much more difficult. In addition, network operators addition, network operators want to deploy new services quickly
want to deploy new services quickly and efficiently. Two and efficiently. Two possible mechanisms for dealing with this
possible mechanisms for dealing with this growing difficulty growing difficulty are the use of software abstractions to
are the use of software abstractions to simplify the design and simplify the design and configuration of monitoring and control
configuration of monitoring and control operations and the use operations and the use of programmatic control over the
of programmatic control over the configuration and operation of configuration and operation of such networks. Policy-based
such networks. Policy-based management can be used to combine management can be used to combine these two mechanisms into an
these two mechanisms into an extensible framework. extensible framework.
Policy statements can be used to express high-level network Policy statements can be used to express high-level network
operator requirements directly, or from a set of management operator requirements directly, or from a set of management
applications, to a network management or element system. The applications, to a network management or element system. The
network management or element system can then interpret those network management or element system can then interpret those
requirements to control the configuration of network elements. requirements to control the configuration of network elements.
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.
Simplified Use of Policy Abstractions (SUPA) will define a Simplified Use of Policy Abstractions (SUPA) will define a
generic policy information model (GPIM) for use in network generic policy information model (GPIM) for use in network
operations and management applications. The GPIM represents operations and management applications. The GPIM represents
different types of policies for controlling the configuration different types of policies for controlling the configuration
of network elements throughout the service development and of network elements throughout the service development and
deployment lifecycle. The GPIM will be translated into deployment lifecycle. The GPIM will be translated into
corresponding YANG data models to define interoperable corresponding YANG data models to define interoperable
implementations that can exchange and modify generic policies implementations that can exchange and modify generic policies
using protocols such as NETCONF/RESTCONF. using protocols such as NETCONF/RESTCONF.
Management applications will benefit from using policy rules Management applications will benefit from using policy rules
that enable scalable and consistent programmatic control over that enable scalable and consistent programmatic control over
the configuration of network elements. the configuration of network elements.
1.1. Problem Statement 1.1. Problem Statement
Network operators are faced with networks of increasing size Network operators are faced with networks of increasing size
and complexity while trying to improve their quality and and complexity while trying to improve their quality and
availability, as more and more business services depend on them. availability, as more and more business services depend on them.
Currently, different technologies and network elements require
different forms of the same policy that governs the production of
network configuration snippets. The power of policy management is
its applicability to many different types of systems. This provides
significant improvements in configuration agility, error detection,
and uptime for operators.
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.
1.2. Proposed Solution 1.2. Proposed Solution
SUPA enables network operators to express policies to control SUPA enables network operators to express policies to control
network configuration data models. SUPA provides a generic network configuration data models. SUPA provides a generic
infrastructure that defines policies to control the configuration infrastructure that defines policies to control the configuration
of network elements. The configuration process is independent of of network elements. The configuration process is independent of
domain or type of application, and results in configuration domain or type of application, and results in configuration
according to YANG data models. according to YANG data models.
The power of policy management is its applicability to many
different types of systems. This provides significant
improvements in configuration agility, error detection, and
uptime for operators. 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 of the above examples can be referred to as "policy rules", Both of the above examples can be referred to as "policy rules",
but they take very different forms, since they are at different but they take very different forms, since they are at different
levels of abstraction and likely authored by different actors. levels of abstraction and likely authored by different actors.
The first example described a very abstract policy rule, and The first example described a very abstract policy rule, and
did not contain any technology-specific terms, while the second did not contain any technology-specific terms, while the second
example included a more concrete policy rule and likely used example included a more concrete policy rule and likely used
technical terms of a general (e.g., IP address range and port technical terms of a general (e.g., IP address range and port
numbers) as well as vendor-specific nature (e.g., specific numbers) as well as vendor-specific nature (e.g., specific
algorithms implemented in a particular device). Furthermore, algorithms implemented in a particular device). Furthermore,
these two policy rules could affect each other. For example, these two policy rules could affect each other. For example,
skipping to change at page 6, line 15 skipping to change at page 6, line 8
SUPA defines policy independent of where it is located. Other SUPA defines policy independent of where it is located. Other
WGs are working on embedding policy in the configuration of a WGs are working on embedding policy in the configuration of a
network element; SUPA is working on defining policies that network element; SUPA is working on defining policies that
can be interpreted external to network elements. Hence, SUPA can be interpreted external to network elements. Hence, SUPA
policies can be used to define the behavior of and policies can be used to define the behavior of and
interaction between embedded policies. interaction between embedded policies.
SUPA can also be used to derive a (more abstract) information SUPA can also be used to derive a (more abstract) information
model from a (more specific) data model. This extracts data model from a (more specific) data model. This extracts data
that is part of a particular technology and/or application that is part of a particular technology and/or application
and makes it reusable, so that it can be applied to multiple and makes it reusable, so that these data can be applied to
technologies and/or domains. multiple technologies and/or domains.
The SUPA policy framework defines a set of consistent, flexible, The SUPA policy framework defines a set of consistent, flexible,
and scalable mechanisms for monitoring and controlling resources and scalable mechanisms for monitoring and controlling resources
and services. It may be used to create a management and and services. It may be used to create a management and
operations interface that can enable existing IETF data models, operations interface that can enable existing IETF data models,
such as those from I2RS and L3SM, to be managed in a unified way such as those from I2RS and L3SM, to be managed in a unified way
that is independent of application domain, technology and vendor. that is independent of application domain, technology and vendor.
Resource and service management become more effective, because Resource and service management become more effective, because
policy defines the context that different operations, such as policy defines the context that different operations, such as
configuration, are applied to. configuration, are applied to.
2. Framework for Generic Policy-based Management 2. Framework for Generic Policy-based Management
This section briefly describes the design and operation of the This section briefly describes the design and operation of the
SUPA policy-based management framework. SUPA policy-based management framework.
2.1. Overview 2.1. Overview
Figure 1 shows a Service Management application creating and Figure 1 shows a simplified functional architecture of how SUPA is
communicating policy rules to two different Network Manager and used to define policies for creating network element configuration
Network Controller elements. snippets. SUPA uses the Generic Policy Information Model (GPIM) to
define a consensual vocabulary that different actors can use to
interact with network elements. The GPIM defines a generic
structure for imperative and declarative policies. This is
converted to generic YANG data models. The IETF produces the
models, and IANA is used to register the model and changes.
The Service Management application uses the Generic Policy In the preferred approach, SUPA generic policy data models are
Information Model (GPIM) to construct policies. The GPIM defines then used to create vendor- and technology-specific data models.
generic policy concepts, as well as two types of policies: ECA These define the specific elements that will be controlled by
policy rules and declarative policy statements. policies. The Policy Interface uses this information to create
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 the
policy interface is NOT being designed in SUPA.
An ECA policy rule is activated when its event clause is true; In one of possibly several alternate approaches (shown with
the condition clause is then evaluated and, if true, signals the asterisks in Figure 1), the SUPA generic policy YANG data models
execution of one or more actions in the action clause. This type contain enough information for the Policy Interface to create
of policy explicitly defines the current and desired states of appropriate input mechanisms for the operator to define policies.
the system being managed. In contrast, a declarative policy This transfers the work of building vendor- and technology-
defines what actions to take, but not how to execute them. specific data models to the SUPA Data Model-Specific Translation
Declarative policies in SUPA take the form of a set of statements Function.
that present facts, and a conclusion of those facts.
A set of Generic Policy Data Models are then created from the GPIM. +---------------------+
These YANG data model policies are then used to control the +----------+ \| SUPA Generic Policy |
configuration of network elements that model the service(s) to | IETF |---+----| Information Model |
be managed using policy. +----------+ | /| |
| +---------+-----------+
| |
Assignments | | Defines Policy Concepts
and Manage | |
Content | \|/
| +---------+-----------+ Preferred
| \| SUPA Generic Policy | Approach
+----| YANG Data Models |------------+
/| | |
+---------+-----------+ |
* |
* |
+--------------------------------+------------------------+---------+
| * | |
| * | |
| A Possible * \|/ |
| Approach * +-------+-------+ |
| * |Technology and | |
| * |Vendor-specific| |
| * | Data Models | |
| \*/ +-------+-------+ |
| Fills +----------+----------+ | |
| +--------+ Forms \| Policy Interface |/ | |
| |Operator|----------| (locally defined +-------------+ |
| +--------+ Runs /| forms, scripts,...) |\ |
| Scripts +----------+----------+ |
| | |
| | Produces Policy Rules |
| | |
| \|/ |
| +------------+--------+ +----------------+ |
| Local SUPA | SUPA Data Model- | \| Local Devices | |
| Execution |Specific Translation +------| and Management | |
| Environment | Functions | /| Systems | |
| +---------------------+ +----------------+ |
| |
+-------------------------------------------------------------------+
+-----------------------------------------------------------------+ Figure 1. SUPA Framework
| 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 | |
| +--------------------+ | | +---------------------+ |
+---+---+---+----------------+ +-----+---+---+--------------+
/ \ / \ / \ / \ / \ / \
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 Figure 1 is meant to be exemplary. The Operator actor shown in
In Figure 1: Figure 1 can interact with SUPA in other ways not shown in the
Figure. In addition, other actors that can interact with SUPA were
not shown for simplicity. For example, an application developer
could build an application that uses the SUPA information and data
models to directly output configuration snippets. In addition,
other actors can use the SUPA framework.
A double-headed arrow with Cs means communication; SUPA defines an Event-Condition-Action (ECA) policy as an example
A double-headed arrow with Ds means derived from; of imperative policies; it also defines two forms of declarative
A double-headed arrow with Rs means references (i.e., the policies using simple Propositional Logic and First Order Logic.
information model is used by the system to instantiate An ECA policy rule is activated when its event clause is true;
the data model). the condition clause is then evaluated and, if true, signals the
execution of one or more actions in the action clause.
An overview of the SUPA framework is shown in Figure 1. The In contrast, a declarative policy defines what actions to take,
network elements used in this framework are: but not how to execute them. Declarative policies in SUPA take the
form of a set of statements that present facts, and a conclusion
of those facts.
SM: Service Management, which represents one or more network 2.2. Operation
entities that are running and controlling network services.
This model contains the following entities:
Generic Policy Information Model: a model for defining policy SUPA can be used to define various types of policies, including
rules that are independent of data repository, data definition, policies that affect services and/or the configuration of
query, and implementation languages, and protocol. individual or groups of network elements. SUPA can be used by a
centralized and/or distributed set of entities that for creating,
managing, interacting with, and retiring policy rules. The Policy
Interface and SUPA Translation Function are two entities that make
up the Policy Management (PM) function.
Generic Policy Data Model: a model of policy rules for that The duties of the PM function depend on the type and nature of
are dependent of data repository, data definition, query, and policies being used. For example, imperative (e.g., ECA) policies
implementation languages, and protocol. require conflict detection and resolution, while declarative
policies do not. A short exemplary list of functions that are
common to both types of policies include:
Service Management Data Model: a model of a network service o policy creation, update, delete, and view functions
(e.g., a VPN) and resources (e.g., a device interface) (typically in conjunction with policy repositories)
required by the network service to be correctly deployed o policy storage, search, and retrieval (typically uses
and executed on the physical and/or virtual topology. distributed repositories that the PM communicates with)
o policy distribution (typically uses a message bus; note that
this involves requesting and responding to requests for
policy decisions as well as distributing policies and
inforing interested entities of policy results)
o making policy decisions (this SHOULD include more than
the simple Policy Decision Point functions defined in
[RFC3198])
o executing policy decisions (this SHOULD include more than
the simple Policy Enforcement Point functions defined in
[RFC3198])
o validating that the execution of the policy produced what
was expected (this is NOT defined in [RFC3198]).
NM/NC: Network Manager / Controller, which represents one or An exemplary architecture that illustrates these concepts is shown
more entities that are able to control the operation and in [TR235].
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 The SUPA scope is limited to policy information and data models.
virtual network topology including the resource attributes SUPA will not define network resource data models, which is out
(e.g., data rate or latency of links) and operational of scope. Similarly, SUPA will not define network service data
parameters needed to support service deployment over the models, which is also out of scope. Instead, SUPA will make use
network topology. An example of a network resource data model of network resource data models defined by other WGs or SDOs.
can be found in [ID.draft-contreras-supa-yang-network-topo].
Network Element (NE), which can interact with local or remote 2.3. Generic Policy Information Model
NM/NC in order to exchange information, such as configuration
information, policy enforcement capabilities, and network status.
2.2. Operation The GPIM provides a common vocabulary for representing concepts
that are common to expressing different types of policy, but
which are independent of language, protocol, repository, and
level of abstraction.
There can be various types of policies, including policies that This enables different policies at different levels of abstraction
affect services and/or the configuration of individual or groups to form a continuum, where more abstract policies can be translated
of network elements. There can be a centralized and/or into more concrete policies, and vice-versa. For example, the
distributed entity or set of entities that are responsible for information model can be extended by generalizing concepts from an
the creation, management, and retirement of policy rules, which existing data model into the GPIM; the GPIM extensions can then be
is known as a policy manager. It is not shown in Figure 1, since used by other data models.
it can be located in the SM or in a separate location.
SUPA will develop an information model for expressing policy at SUPA will develop an information model for expressing policy at
different levels of abstraction. Specifically, three information different levels of abstraction. Specifically, three information
model fragments are envisioned: (i) a generic policy information model fragments are envisioned: (i) a generic policy information
model (GPIM) that defines concepts needed by policy management model (GPIM) that defines concepts needed by policy management
independent of the form and content of the policy, (ii) a more independent of the form and content of the policy, (ii) a more
specific information model that refines the GPIM to specify how specific information model that refines the GPIM to specify how
to build policy rules of the event-condition-action paradigm, and to build policy rules of the event-condition-action paradigm, and
(iii) a more specific information model that refines the GPIM to (iii) a more specific information model that refines the GPIM to
specify how to build policy rules that declaratively specify what specify how to build policy rules that declaratively specify what
goals to achieve (but not how to achieve those goals); this is goals to achieve (but not how to achieve those goals); this is
often called "intent-based" policy. These are all contained in often called "intent-based" policy. These are all contained in
the Generic Policy Information Model block in Figure 1. the Generic Policy Information Model block in Figure 1.
SUPA will translate the GPIM into concrete YANG data models that
define how to manage and communicate policies between systems.
Any number of ECA and/or declarative policy YANG data models may
be instantiated from the GPIM. Providing a common foundation for
defining two very different types of policies is a key benefit of
SUPA.
SUPA will not define network resource data models, which is out
of scope. Instead, SUPA will make use of network resource data
models defined by other WGs or SDOs.
Service Management (SM) will send policy rules and associated
data (e.g., service management data), to the NM/NC. The NM/NC
will (in conjunction with network resource data models) then
produce NE configurations. The 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 also the
capabilities and status of NEs, which will be stored in network
resource data models. It can use existing network management and
signaling protocols, such as I2RS [I2RS], NETCONF [NETCONF], and
RESTCONF [ID.draft-ietf-netconf-restconf].
2.3. Generic Policy Information Model
The GPIM provides a common vocabulary for representing concepts
that are common to expressing different types of policy, but
which are independent of language, 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. For example, new model requirements can be
derived by taking an existing data model and translate it into
the GPIM with extensions to define the new concepts from the
translated data model.
2.4. Refinement of the GPIM 2.4. Refinement of the GPIM
An information model is abstract. As such, it cannot be directly An information model is abstract. As such, it cannot be directly
instantiated (i.e., objects cannot be created directly from it). instantiated (i.e., objects cannot be created directly from it).
Therefore, SUPA translates its information model to two Therefore, SUPA translates its information model to two
different data models (which can be instantiated). different data models (which can be instantiated).
SUPA will translate the GPIM into concrete YANG data models that
define how to manage and communicate policies between systems.
Any number of imperative and/or declarative policy YANG data models
may be instantiated from the GPIM, and may be used separately or
in combination. This is enabled by the SUPA GPIM.
The two data models differ in how they represent policies. The two data models differ in how they represent policies.
However, they share common characteristics and behavior. However, they share common characteristics and behavior.
Therefore, it is easier to define a set of three information Therefore, it is easier to define a set of three information
models to represent the common, ECA, and declarative parts of a models to represent the common, ECA, and declarative parts of a
policy. These three information models are then translated into policy. These three information models are then translated into
either a YANG ECA data model or a YANG declarative data model. either a YANG ECA data model or a YANG declarative data model.
Note that because they share a common information model, they Note that because they share a common information model, they
can be used separately or together (e.g., a declarative policy can be used separately or together (e.g., a declarative policy
could call an ECA policy). This provides two different types could call an ECA policy). This provides two different types
of abstractions that serve different use cases. It also helps of abstractions that serve different use cases. It also helps
prove the genericity of the GPIM. prove the genericity of the GPIM.
2.4.1. Event-Condition-Action Policy Information Model 2.4.1. Event-Condition-Action Policy Information Model
The SUPA ECA Policy Rule Information Model (EPRIM) represents a The SUPA ECA Policy Rule Information Model (EPRIM) represents a
policy rule as a statement that consists of an event clause, a policy rule as a statement that consists of an event clause, a
condition clause, and an action clause. This type of Policy condition clause, and an action clause. An ECA policy rule is
Rule explicitly defines the current and desired states of the activated when its event clause is true; the condition clause is
system being managed. then evaluated and, if true, signals the execution of one or more
actions in the action clause. This type of Policy Rule explicitly
defines the current and desired states of the system being managed.
2.4.2. Declarative Policy Information Model 2.4.2. Declarative Policy Information Model
The SUPA Logic Statement Information Model (SLSIM) is a set of The SUPA Logic Statement Information Model (LSIM) is a set of
(logic-based) propositions that form a (single) conclusion. A (logic-based) propositions that form a (single) conclusion. A
proposition is a type of statement that is either TRUE or FALSE. proposition is a type of statement that is either TRUE or FALSE.
A proposition can be created from simpler propositions. This A proposition can be created from simpler propositions. This
version of the SLSIM defines two forms of SUPA Logic Statements: version of the LSIM defines two forms of SUPA Logic Statements:
one using propositional logic, and one using first order logic. one using propositional logic, and one using first order logic.
3. Application of Generic Policy-based Management 3. Application of Generic Policy-based Management
This section provides examples of how SUPA can be used to This section provides examples of how SUPA can be used to
define different types of policies. Examples applied to various define different types of policies. Examples applied to various
domains, including system management, operations management, domains, including system management, operations management,
access control, routing, and service function chaining, are access control, routing, and service function chaining, are
also included. also included.
skipping to change at page 12, line 10 skipping to change at page 12, line 5
that the policy did not specify which particular VM to move that the policy did not specify which particular VM to move
the workload on the source VM to; that is part of the the workload on the source VM to; that is part of the
search and optimization algorithms that are implied, but search and optimization algorithms that are implied, but
not specified, by this policy. not specified, by this policy.
Service Management Examples Service Management Examples
Proactively monitor Gold Service users to ensure their SLAs Proactively monitor Gold Service users to ensure their SLAs
are not violated. are not violated.
In the above policy, Gold Service is an aggregation of Gold Service is an aggregation of different traffic types, each
different traffic types, each with different constraints. with different constraints. The policy will dynamically create
The policy will dynamically create a service function chain a service function chain based on the current context to ensure
based on the current context to ensure that the customer's that the customer's SLA is not violated.
SLA is not violated.
Gold and Platinum Service Users must have WAN optimization Gold and Platinum Service Users must have WAN optimization
applied to multimedia applications. applied to multimedia applications.
The above policy applies only to users whose SLA types are The above policy applies only to multimedia applications for
either Gold or Platinum, and only for their multimedia users whose SLA types are either Gold or Platinum. It installs
applications. It installs a service chain that performs a service chain that performs WAN optimization (and likely
WAN optimization (and likely content caching and other content caching and other services) to ensure that the SLAs of
services) to ensure that the SLAs of these users are not these users are not violated.
violated.
3.2. ECA Examples 3.2. ECA Examples
ECA policies are statements that consist of an event clause, a ECA policies are statements that consist of an event clause, a
condition clause, and an action clause. condition clause, and an action clause.
Network Service Management Example Network Service Management Example
Event: too many interface alarms received from an Event: too many interface alarms received from an
L3VPN service L3VPN service
skipping to change at page 15, line 19 skipping to change at page 15, line 5
4.1.1. I2RS Working Group 4.1.1. I2RS Working Group
I2RS defines an interface that interacts with the routing I2RS defines an interface that interacts with the routing
system using a collection of protocol-based control or system using a collection of protocol-based control or
management interfaces. Users of I2RS interfaces are typically management interfaces. Users of I2RS interfaces are typically
management applications and controllers. SUPA does not directly management applications and controllers. SUPA does not directly
interface to the routing system. Rather, SUPA uses data interface to the routing system. Rather, SUPA uses data
produced by I2RS (e.g., topological information) to construct produced by I2RS (e.g., topological information) to construct
its policies. its policies.
It is envisioned that SUPA will use work produced by I2RS. This
in particular applies to the topology work done in the I2RS
working group, since topology information is often necessary for
the interpretation of SUPA policies.
4.1.2. L3SM Working Group 4.1.2. L3SM Working Group
L3SM defines an L3 VPN service model that can be used for L3SM defines an L3 VPN service model that can be used for
communication between customers and network operators. This communication between customers and network operators. This
model enables an orchestration application or customers to model enables an orchestration application or customers to
request network services provided by L3 VPN technologies. The request network services provided by L3 VPN technologies. The
implementation of network services is often guided by specific implementation of network services is often guided by specific
policies, and SUPA provides a tool that can help with the policies, and SUPA provides a tool that can help with the
mapping of L3 VPN service requests to L3 VPN configurations of mapping of L3 VPN service requests to L3 VPN configurations of
network elements. network elements.
4.1.3. ALTO Working Group 4.1.3. ALTO Working Group
The ALTO working group defined an architecture for exposing The ALTO working group defined an architecture for exposing
topology information, more specifically the cost of paths topology information, more specifically the cost of paths
through an infrastructure, as defined in [RFC7285]. ALTO through an infrastructure, as defined in [RFC7285]. ALTO
services are able to provide network maps defined as groups of services are able to provide network maps defined as groups of
endpoints. Endpoints are provider-defined entities, and can endpoints, and can therefore represent any granularity of network,
therefore represent any granularity of network, from the from the physical to groups of networks following similar paths or
physical to groups of networks following similar paths or restraints. Although this model can represent different levels of
restraints. Although this model can represent different levels granularities, it is not clear if it could be adapted easily for
of granularities, it is not clear if it could be adapted easily other purposes than providing cost maps in the context of ALTO.
for other purposes than providing cost maps in the context of The ALTO model is meant to be used outside of the trust domain of
ALTO. The ALTO model is meant to be used outside of the trust an ISP by external clients.
domain of an ISP by external clients.
SUPA does not generate data that is similar to ALTO. Rather, SUPA does not generate data that is similar to ALTO. Rather,
SUPA could use ALTO data as part of its policies to configure SUPA could use ALTO data as part of its policies to configure
services and/or resources. services and/or resources.
4.1.4. TEAS Working Group 4.1.4. TEAS Working Group
The Traffic Engineering Architecture and Signaling (TEAS) The Traffic Engineering Architecture and Signaling (TEAS)
working group is responsible for defining MPLS- and GMPLS-based working group is responsible for defining MPLS- and GMPLS-based
Traffic Engineering architectures that enable operators to Traffic Engineering architectures that enable operators to
control how specific traffic flows are treated within their control how specific traffic flows are treated within their
networks. It covers YANG models for a traffic engineering networks. It covers YANG models for a traffic engineering
database. In coordination with other working groups (I2RS) database. In coordination with other working groups (I2RS)
providing YANG models for network topologies. providing YANG models for network topologies.
Both TEAS and SUPA use YANG data models. SUPA does not generate Both TEAS and SUPA use YANG data models. SUPA does not generate
traffic engineering (TE) data. However, SUPA could use TE data traffic engineering (TE) data. However, SUPA could use TE data
as part of its policies for configuring resources and/or as part of its policies for configuring resources and/or
services. services. SUPA could also define policies that define which
service, path, and link properties to use for a given customer,
SUPA could also define policies that define which service, and consequently, which protocol extensions to use. TEAS data
path, and link properties to use for a given customer, and could also be used to enable operators to define how particular
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 traffic flows are treated in a more abstract (but still
consistent) manner. consistent) manner.
4.1.5. BESS Working Group 4.1.5. BESS Working Group
The BGP Enabled Services (BESS) working group defines and The BGP Enabled Services (BESS) working group defines and
extends network services that are based on BGP. This includes extends network services that are based on BGP. This includes
BGP/MPLS IP provider-provisioned L3VPNs, L2VPNs, BGP-enabled BGP/MPLS IP provider-provisioned L3VPNs, L2VPNs, BGP-enabled
VPN solutions for use in data center networking, and extensions VPN solutions for use in data center networking, and extensions
to BGP-enabled solutions to construct virtual topologies in to BGP-enabled solutions to construct virtual topologies in
skipping to change at page 17, line 28 skipping to change at page 17, line 5
for data centers in order to be able to move virtual instances for data centers in order to be able to move virtual instances
without impacting their network configuration. This is realized without impacting their network configuration. This is realized
through a centrally controlled overlay layer-3 network. The through a centrally controlled overlay layer-3 network. The
NVO3 work is not about defining policy information; rather, it NVO3 work is not about defining policy information; rather, it
uses policy information to perform some functions. Both NVO3 and uses policy information to perform some functions. Both NVO3 and
SUPA use YANG data models. SUPA could define policies that define SUPA use YANG data models. SUPA could define policies that define
how the logically centralized network virtualization management how the logically centralized network virtualization management
entity (or entities) of NVO3 behave (e.g., the functions in the entity (or entities) of NVO3 behave (e.g., the functions in the
network virtualization control plane). network virtualization control plane).
4.1.8. ACTN Working Group 4.1.8. ACTN BoF (IETF-90)
The ACTN proposed work, as described in [actn] framework, has The ACTN proposed work, as described in [actn] framework, has
two main goals, the abstraction of multiple optical transport two main goals, the abstraction of multiple optical transport
domains into a single controller offering a common abstract domains into a single controller offering a common abstract
topology, and the splitting of that topology into abstract topology, and the splitting of that topology into abstract
client views that are usually a fraction of the complete client views that are usually a fraction of the complete
network. The ACTN work is therefore about unification of network. The ACTN work is therefore about unification of
several physical controllers into a virtual one, and also about several physical controllers into a virtual one, and also about
the segmentation, isolation and sharing of network resources. the segmentation, isolation and sharing of network resources.
The ACTN work is not about defining policy information. Both ACTN The ACTN work is not about defining policy information. Both ACTN
skipping to change at page 18, line 29 skipping to change at page 18, line 9
Within ZOOM, the Foundational Studies project contains work on Within ZOOM, the Foundational Studies project contains work on
an information model and management architecture that are an information model and management architecture that are
directly relevant to SUPA. The TMF Information Model, Policy, directly relevant to SUPA. The TMF Information Model, Policy,
and Security working groups are involved in this work. and Security working groups are involved in this work.
The ZOOM information model updates the existing Shared The ZOOM information model updates the existing Shared
Information and Data (SID) information model to add support for Information and Data (SID) information model to add support for
the management of physical and virtual infrastructure, event- the management of physical and virtual infrastructure, event-
and data-driven systems, policy management (architecture and and data-driven systems, policy management (architecture and
model), metadata for describing and prescribing behavior that model), metadata for describing and prescribing behavior that can
can support changes at runtime, and access control. support changes at runtime, and access control. The policy
information model defines imperative (ECA), declarative (intent-
The policy information model defines event-condition-action based), utility function, and promise policies. The work in
(ECA), declarative (intent-based), utility function, and [ID.draft-strassner-supa-generic-policy-info-model] is based on
promise policies. The work in [ID.draft-strassner-supa-generic- this work. It currently extends the ZOOM ECA model and provides
policy-info-model] is based on this work. It currently extends additional detail not currently present in ZOOM; the next version
the ZOOM ECA model and provides additional detail not currently of this draft will do the same for declarative policies.
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 There is currently no plan to use the utility function and
promise policies of ZOOM. Finally, it should be noted that promise policies of ZOOM in SUPA. Finally, it should be noted
the data model work planned for SUPA is not currently planned that the data model work planned for SUPA is not currently
for the ZOOM project. planned for the ZOOM project.
4.2.2. MEF 4.2.2. MEF
The MEF (originally named the Metro Ethernet Forum) develops The MEF (originally named the Metro Ethernet Forum) develops
architecture, service and management specifications related to architecture, service and management specifications related to
Carrier Ethernet (CE). The CE architecture includes the Carrier Ethernet (CE). The CE architecture includes the
definition of several interfaces specific to CE like the User definition of several interfaces specific to CE like the User
Network Interface (UNI) and External Network Network Interface Network Interface (UNI) and External Network Network Interface
(ENNI). Specifications developed in this space include the (ENNI). Specifications developed in this space include the
definitions of CE services, CE service attributes, Ethernet definitions of CE services, CE service attributes, Ethernet
skipping to change at page 19, line 24 skipping to change at page 18, line 50
The MEF has developed a number of Information and Data Models, The MEF has developed a number of Information and Data Models,
and has recently started a project that used YANG to model and and has recently started a project that used YANG to model and
manage the services defined by the MEF. While the MEF has created manage the services defined by the MEF. While the MEF has created
rigorous definitions of these services, they are specific to rigorous definitions of these services, they are specific to
transport technology, and they do not include and rely on policies. transport technology, and they do not include and rely on policies.
4.2.3. Open Daylight 4.2.3. Open Daylight
Open Daylight network controller implements a number of models Open Daylight network controller implements a number of models
through its service abstraction Layer (MD-SAL) based on draft through its service abstraction Layer (MD-SAL) based on draft
IETF Yang models. Open Daylight is an open source project. IETF Yang models. Open Daylight is an open source project. Two of
these are relevant to SUPA, and are described below.
4.2.3.1. Network Intent Composition (NIC) 4.2.3.1. Network Intent Composition (NIC)
The Network Intent Composition project aims at providing better The Network Intent Composition project aims at providing better
flexibility by using declarative policies. It does not cover flexibility by using declarative policies. It does not cover
other types of policies, such as ECA policy rules. The intent- other types of policies, such as ECA policy rules. The intent-
based interface aims to provide a high level of abstraction, based interface aims to provide a high level of abstraction,
primarily for use by an application developer. Its progress primarily for use by an application developer. Its progress
has recently stalled. has recently stalled.
skipping to change at page 21, line 5 skipping to change at page 20, line 31
The declarative policies of SUPA are similar to those in Congress; The declarative policies of SUPA are similar to those in Congress;
the primary difference relies in the characteristics and behavior the primary difference relies in the characteristics and behavior
(in the sense of restrictions) of the underlying logic for (in the sense of restrictions) of the underlying logic for
Congress vs. SUPA. SUPA's propositional logic statements are Congress vs. SUPA. SUPA's propositional logic statements are
simpler but more limited than Congress, while SUPA's first-order simpler but more limited than Congress, while SUPA's first-order
logic statements are more complex but more powerful than those logic statements are more complex but more powerful than those
of Congress. If desired, a Congress model could be easily added of Congress. If desired, a Congress model could be easily added
to SUPA. to SUPA.
4.2.6. The NEMO Project 4.2.6. The NEMO Project (not a BoF yet)
The NEMO project is a research activity aiming at defining a The NEMO project is a research activity aimed at defining a
simple declarative framework for networking. The NEMO syntax is simple framework for "intent-based" networking. This project
not based on an existing language and covers the basic elements concentrates on creating a domain-specific language and associated
for network manipulation such as nodes, links and flows. The API, not a model or even a rigorous definition of what a policy
NEMO project has been successfully demonstrated at IETF-91, rule is.
along with a companion graphical user interface. This work is
organized in the Intent-Based NEMO (IBNEMO) mail list within The NEMO syntax defines a very simple information model that has
the IETF. three basic elements for network manipulation: nodes, links, and
flows. A policy rule is NOT defined in this model. Rather, policy
is defined as a command. The NEMO project has been successfully
demonstrated at IETF-91, along with a companion graphical user
interface.
NEMO declarative policies are different than SUPA declarative NEMO declarative policies are different than SUPA declarative
policies. NEMO uses a flatter, simpler object model with fewer policies. NEMO uses a flatter, simpler object model with fewer
objects, does not support ECA policies, and emphasizes the use objects to represent targets of policy. NEMO does not define a
of a language. SUPA uses a richer class model that offers both policy model, and does not support ECA policies. NEMO uses a
ECA and declarative policies. SUPA has not proposed a language. condition-action paradigm to execute its declarative policies. In
contrast, SUPA uses a richer class model to represent ECA and
declarative policies. SUPA declarative policies are executed using
formal logic. SUPA has not proposed a language.
4.2.7. The Floodlight Project 4.2.7. The Floodlight Project
The Floodlight is an OpenFlow-enabled SDN controller. It uses The Floodlight is an OpenFlow-enabled SDN controller. It uses
another open source project called Indigo to support OpenFlow another open source project called Indigo to support OpenFlow
and manage southbound devices. The Indigo agent also supports and manage southbound devices. The Indigo agent also supports
an abstraction layer to make it easy to integrate with physical an abstraction layer to make it easy to integrate with physical
and virtual switches. It supports configuration of an abstraction and virtual switches. It supports configuration of an abstraction
layer so that it can configure OpenFlow in hybrid mode. layer so that it can configure OpenFlow in hybrid mode.
skipping to change at page 22, line 38 skipping to change at page 22, line 23
8. Contributors 8. Contributors
The following people all contributed to creating this document: The following people all contributed to creating this document:
Jun Bi, Tsinghua University Jun Bi, Tsinghua University
Vikram Choudhary, Huawei Technologies Vikram Choudhary, Huawei Technologies
Luis M. Contreras, Telefonica I+D Luis M. Contreras, Telefonica I+D
Georgios Karagiannis, Huawei Technologies Georgios Karagiannis, Huawei Technologies
Hosnieh Rafiee, Huawei Technologies Duesseldorf GmbH Hosnieh Rafiee, Huawei Technologies Duesseldorf GmbH
Dan Romascanu, Avaya Dan Romascanu, Avaya
Jon Saperia, JDS Consulting
J. Schoenwaelder, Jacobs University, Germany J. Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom Qiong Sun, China Telecom
Parviz Yegani, Juniper Networks Parviz Yegani, Juniper Networks
Cathy Zhou, Huawei Technologies Cathy Zhou, Huawei Technologies
9. Acknowledgments 9. Acknowledgments
This document has benefited from reviews, suggestions, comments This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in and proposed text provided by the following members, listed in
alphabetical order: J. Bi, Luis M. Contreras, G. Karagiannis, D. alphabetical order: J. Bi, Luis M. Contreras, G. Karagiannis, D.
Romascanu, J. Schoenwaelder, Q. Sun, P. Yegani, and C. Zhou. Romascanu, J. Saperia, J. Schoenwaelder, Q. Sun, P. Yegani, and
C. Zhou.
10. References 10. References
10.1. Informative References 10.1. 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 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
[SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P. [SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P.
Yegani, " The Framework of Simplified Use of Policy Yegani, " The Framework of Simplified Use of Policy
Abstractions (SUPA) ", IETF Internet draft, draft-zhou-supa- Abstractions (SUPA) ", IETF Internet draft, draft-zhou-supa-
framework, February 2015. framework, February 2015.
[SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M. [SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M.
Contreras, P. Yegani, JF Tremblay and J. Bi, "Problem Statement Contreras, P. Yegani, JF Tremblay and J. Bi, "Problem Statement
for Simplified Use of Policy Abstractions (SUPA)", IETF for Simplified Use of Policy Abstractions (SUPA)", IETF
Internet draft, draft-karagiannis-supa-problem-statement, Internet draft, draft-karagiannis-supa-problem-statement,
January 2015. January 2015.
skipping to change at page 23, line 38 skipping to change at page 23, line 42
[RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal [RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal
Specification of DomainSpecific ECA Policy Models", in Proc. Specification of DomainSpecific ECA Policy Models", in Proc.
2011 Fifth IEEE International Conference on Theoretical Aspects 2011 Fifth IEEE International Conference on Theoretical Aspects
of Software Engineering, 2011 of Software Engineering, 2011
[Stras02] John Strassner, "DEN-ng: Achieving Business-Driven [Stras02] John Strassner, "DEN-ng: Achieving Business-Driven
Network Management" in Proc. IEEE Network Operations and Network Management" in Proc. IEEE Network Operations and
Management Symposium (NOMS), 2002. Management Symposium (NOMS), 2002.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for [TR235] John Strassner, ed., "ZOOM Policy Architecture and
the Network Configuration Protocol (NETCONF)", RFC 6020, Information Model Snapshot", TR245, part of the TM Forum ZOOM
October 2010. project, October 26, 2014
[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
Authors' Addresses Authors' Addresses
Maxim Klyus, Ed. Maxim Klyus, Ed.
NetCracker NetCracker
Kozhevnicheskaya str.,7 Bldg. #1 Kozhevnicheskaya str.,7 Bldg. #1
Moscow, Russia Moscow, Russia
Phone: +7-916-8575717 Phone: +7-916-8575717
E-mail: klyus@netcracker.com E-mail: klyus@netcracker.com
 End of changes. 56 change blocks. 
259 lines changed or deleted 277 lines changed or added

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