Network Working Group M. Klyus
Internet Draft NetCracker
Intended status: Standard Track J. Strassner
Expires: December 9, 2015 Huawei Technologies
June 9, 2015
SUPA Proposition
draft-klyus-supa-proposition-01
Abstract
The rapid growth in the variety and importance of traffic flowing
over increasingly complex enterprise and service provider network
architectures makes the task of network operations and management
applications and deploying new services much more difficult.
Simplified Use of Policy Abstractions (SUPA) defines an interface
to a network management function that takes high-level, possibly
network-wide policies as input and creates element configuration
snippets as output. SUPA expresses policies using a generic policy
information model, and outputs generic YANG data models.
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."
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Klyus, et al. Expires December 9, 2015 [Page 1]
Internet-Draft SUPA - Proposition June 2015
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. Proposed Solution.........................................4
1.3. Value of the SUPA Approach ...............................5
2. Framework for Generic Policy-based Management..................6
2.1. Overview..................................................6
2.2. Operation.................................................8
2.3. Generic Policy Information Model..........................9
2.4. Refinement of the GPIM...................................10
2.4.1. Event-Condition-Action Policy Information Model.....10
2.4.2. Declarative Policy Information Model................10
3. Application of Generic Policy-based Management................10
3.1. Declarative Examples.....................................11
3.2. ECA Examples.............................................12
3.3. ECA plus Declarative Example.............................14
4. Related Work..................................................15
4.1. Related Work within the IETF.............................15
4.1.1. I2RS Working Group..................................15
4.1.2. L3SM Working Group..................................15
4.1.3. ALTO Working Group..................................15
4.1.4. TEAS Working Group..................................16
4.1.5. BESS Working Group..................................16
4.1.6. SFC Working Group...................................16
4.1.7. NVO3 Working Group..................................17
4.1.8. ACTN Working Group..................................17
4.1.9. Previous IETF Policy Models.........................17
4.2. Related Work outside the IETF............................17
4.2.1. TM Forum............................................18
4.2.2. MEF.................................................18
4.2.3. Open Daylight.......................................19
4.2.4. Open Networking Foundation..........................19
4.2.5. OpenStack...........................................20
Klyus, et al. Expires December 9, 2015 [Page 2]
Internet-Draft SUPA - Proposition June 2015
4.2.6. The NEMO Project....................................21
4.2.7. The Floodlight Project..............................21
4.2.8. The ONOS Project....................................21
5. Conclusions - Value of SUPA...................................21
6. Security Considerations.......................................22
7. IANA Considerations...........................................22
8. Acknowledgments...............................................22
9. Additional Authors List.......................................22
10. References...................................................23
10.1. Informative References..................................23
1. Introduction
The rapid growth in the variety and importance of traffic
flowing over increasingly complex enterprise and service
provider network architectures makes the task of network
operations and management applications and deploying new
services much more difficult. In addition, network operators
want to deploy new services quickly and efficiently. Two
possible mechanisms for dealing with this growing difficulty
are the use of software abstractions to simplify the design and
configuration of monitoring and control operations and the use
of programmatic control over the configuration and operation of
such networks. Policy-based management can be used to combine
these two mechanisms into an extensible framework.
Policy statements can be used to express high-level network
operator requirements directly, or from a set of management
applications, to a network management or element system. The
network management or element system can then interpret those
requirements to control the configuration of network elements.
Simplified Use of Policy Abstractions (SUPA) will define a
generic policy information model (GPIM) for use in network
operations and management applications. The GPIM represents
different types of policies for controlling the configuration
of network elements throughout the service development and
deployment lifecycle. The GPIM will be translated into
corresponding YANG data models to define interoperable
implementations that can exchange and modify generic policies
using protocols such as NETCONF/RESTCONF.
Management applications will benefit from using policy rules
that enable scalable and consistent programmatic control over
the configuration of network elements.
Klyus, et al. Expires December 9, 2015 [Page 3]
Internet-Draft SUPA - Proposition June 2015
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.
1.2. Proposed Solution
SUPA enables network operators to express policies to control
network configuration data models. SUPA provides a generic
infrastructure that defines policies to control the configuration
of network elements. The configuration process is independent of
domain or type of application, and results in configuration
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",
but they take very different forms, since they are at 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 and 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.
Klyus, et al. Expires December 9, 2015 [Page 4]
Internet-Draft SUPA - Proposition June 2015
Note that SUPA is not limited to any one type of technology.
While the above two policies could be considered "QoS"
policies, other examples include:
- network elements must not accept passwords for logins
- all SNMP agents in this network must drop all SNMP traffic
unless it is originating from, or targeting, the
management network
- Periodically perform workload consolidation if average CPU
utilization falls below X%
The above three examples are not QoS related, and will be
explained more in Sections 4.1 and 4.2. This emphasizes the
utility of the SUPA approach in being able to provide policies
to control different types of network element configuration
snippets.
There are many types of policies. SUPA differentiates between
"management policies" and "embedded policies". Management
policies are used to control the configuration of network
elements. Management policies can be interpreted externally to
network elements, and the interpretation typically results in
configuration changes of collections of network elements. In
contrast, "embedded policies" are policies that are embedded
in the configuration of network elements, and are usually
interpreted on network elements in isolation. Since embedded
policies are interpreted in the network device, they are
typically composed in a very specific fashion to run at
near-realtime timescales.
1.3. Value of the SUPA Approach
SUPA will achieve an optimization and reduction in the amount
of work required to define and implement policy-based data
models in the IETF. Part of this is due to the generic and
extensible framework of SUPA, which models concepts common to
any type of policy as well as provides two information models
(ECA and declarative), along with the associated YANG data
models.
Klyus, et al. Expires December 9, 2015 [Page 5]
Internet-Draft SUPA - Proposition June 2015
SUPA defines policy independent of where it is located. Other
WGs are working on embedding policy in the configuration of a
network element; SUPA is working on defining policies that
can be interpreted external to network elements. Hence, SUPA
policies can be used to define the behavior of and
interaction between embedded policies.
SUPA can also be used to derive a (more abstract) information
model from a (more specific) data model. This extracts data
that is part of a particular technology and/or application
and makes it reusable, so that it can be applied to multiple
technologies and/or domains.
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 data models,
such as those from I2RS and L3SM, to be managed in a unified way
that is independent of application domain, technology and vendor.
Resource and service management become more effective, because
policy defines the context that different operations, such as
configuration, are applied to.
2. Framework for Generic Policy-based Management
This section briefly describes the design and operation of the
SUPA policy-based management framework.
2.1. Overview
Figure 1 shows a Service Management application creating and
communicating policy rules to two different Network Manager and
Network Controller elements.
The Service Management application uses the Generic Policy
Information Model (GPIM) to construct policies. The GPIM defines
generic policy concepts, as well as two types of policies: ECA
policy rules and declarative policy statements.
An ECA policy rule is activated when its event clause is true;
the condition clause is then evaluated and, if true, signals the
execution of one or more actions in the action clause. This type
of policy explicitly defines the current and desired states of
the system being managed. In contrast, a declarative policy
defines what actions to take, 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.
Klyus, et al. Expires December 9, 2015 [Page 6]
Internet-Draft SUPA - Proposition June 2015
A set of Generic Policy Data Models are then created from the GPIM.
These YANG data model policies are then used to control the
configuration of network elements that model the service(s) to
be managed using policy.
+-----------------------------------------------------------------+
| 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
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 (i.e., the
information model is used by the system to instantiate
the data model).
Klyus, et al. Expires December 9, 2015 [Page 7]
Internet-Draft SUPA - Proposition June 2015
An overview of the SUPA framework is shown in Figure 1. The
network elements 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.
Service Management Data Model: a model of a network service
(e.g., a VPN) 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.
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).
Network Resource Data Model: a model of the physical and
virtual network topology including the resource attributes
(e.g., data rate or latency of links) and operational
parameters needed to support service deployment over the
network topology. An example of a network resource data model
can be found in [ID.draft-contreras-supa-yang-network-topo].
Network Element (NE), which can interact with local or remote
NM/NC in order to exchange information, such as configuration
information, policy enforcement capabilities, and network status.
2.2. Operation
There can be various types of policies, including policies that
affect services and/or the configuration of individual or groups
of network elements. There can be a centralized and/or
distributed entity or set of entities that are responsible for
the creation, management, and retirement of policy rules, which
is known as a policy manager. It is not shown in Figure 1, since
it can be located in the SM or in a separate location.
Klyus, et al. Expires December 9, 2015 [Page 8]
Internet-Draft SUPA - Proposition June 2015
SUPA will develop an information model for expressing policy at
different levels of abstraction. Specifically, three information
model fragments are envisioned: (i) a generic policy information
model (GPIM) that defines concepts needed by policy management
independent of the form and content of the policy, (ii) a more
specific information model that refines the GPIM to specify how
to build policy rules of the event-condition-action paradigm, and
(iii) a more specific information model that refines the GPIM 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. These are all contained in
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.
Klyus, et al. Expires December 9, 2015 [Page 9]
Internet-Draft SUPA - Proposition June 2015
2.4. Refinement of the GPIM
An information model is abstract. As such, it cannot be directly
instantiated (i.e., objects cannot be created directly from it).
Therefore, SUPA translates its information model to two
different data models (which can be instantiated).
The two data models differ in how they represent policies.
However, they share common characteristics and behavior.
Therefore, it is easier to define a set of three information
models to represent the common, ECA, and declarative parts of a
policy. These three information models are then translated into
either a YANG ECA data model or a YANG declarative data model.
Note that because they share a common information model, they
can be used separately or together (e.g., a declarative policy
could call an ECA policy). This provides two different types
of abstractions that serve different use cases. It also helps
prove the genericity of the GPIM.
2.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.
2.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 a type of statement that is either TRUE or FALSE.
A proposition can be created from simpler propositions. This
version of the SLSIM defines two forms of SUPA Logic Statements:
one using propositional logic, and one using first order logic.
3. 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
domains, including system management, operations management,
access control, routing, and service function chaining, are
also included.
Klyus, et al. Expires December 9, 2015 [Page 10]
Internet-Draft SUPA - Proposition June 2015
3.1. Declarative Examples
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:
System and Operations Management Examples
All routers and switches must have password login disabled.
The above policy first resolves 'routers and switches' to a
set of network elements, and then pushes the appropriate
configuration to those network elements.
All SNMP agents must enable SNMPv3 and must disable all other
versions of SNMP.
The above policy can be mapped to the leafs v1, v2c, and v3
in the ietf-snmp YANG data model (RFC 7407).
All SNMP traffic is dropped unless it originates from, or
is directed to, an interface of a management system.
The above policy first resolves a management system interface
to a list of IP addresses, and then creates a set of suitable
ACL rules that are configured on all network elements.
Access to source code servers is limited to authorized
Intranet users.
The above policy assumes that the user is authenticated and
authorized to access the code server. It places an additional
constraint of requiring Intranet acces before granting access
to the resource. Note that this rule is not limited to any
one specific user or type of application.
Periodically perform workload consolidation if average CPU
utilization falls below X%.
This policy moves workloads on a set of source VMs to a
common target VM if the average CPU utilization for the CPUs
on the source VM is less than a predefined threshold. Note
that the policy did not specify which particular VM to move
the workload on the source VM to; that is part of the
search and optimization algorithms that are implied, but
not specified, by this policy.
Klyus, et al. Expires December 9, 2015 [Page 11]
Internet-Draft SUPA - Proposition June 2015
Service Management Examples
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.
Gold and Platinum Service Users must have WAN optimization
applied to multimedia applications.
The above policy applies only to users whose SLA types are
either Gold or Platinum, and only for their multimedia
applications. It installs a service chain that performs
WAN optimization (and likely content caching and other
services) to ensure that the SLAs of these users are not
violated.
3.2. ECA Examples
ECA policies are statements that consist of an event clause, a
condition clause, and an action clause.
Network Service Management Example
Event: too many interface alarms received from an
L3VPN service
Condition: alarms resolve to the same interface within a
specified time period
Action: if error rate exceeds x% then put L3VPN service
to Error State and migrate users to one or more
new L3VPNs
Security Management Example
Event: anomalous traffic detected in network
Condition: determine the severity of the traffic
Action: apply one or more actions to affected NEs based
on the type of the traffic detected (along with
other factors, such as the type of resource
being attacked if the traffic is determined to
be an attack)
Klyus, et al. Expires December 9, 2015 [Page 12]
Internet-Draft SUPA - Proposition June 2015
Traffic Management Examples
Event: edge link close to being overloaded by
incoming traffic
Condition: if link utilization exceeds Y% or if link
utilization average is increasing over a
specified time period
Action: change routing configuration to other peers
that have better metrics
Event: edge link close to be overloaded by
outgoing traffic
Condition: if link utilization exceeds Z% or if link
utilization average is increasing over a
specified time period
Action: reconfigure affected nodes to use source-based
routing to balance traffic across multiple links
Service Management Examples
Event: alarm received 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.,
whose peaks are at different times in day)
3) combine workloads (e.g., using integer
programming)
Event: alarm received or periodic time check
Condition: if DSCP == AFxy and
throughput < T% or packet loss > P%
Action: no: no action
yes: remark to AFx'y'; reconfigure queuing;
configure shaping to S pps; ...
Note: it is possible to construct an ECA policy rule that is
directly tied to configuration parameters; this is in general
not possible for declarative policy. The value of declarative
policy is in expression of the goal of the policy, and the
freedom in implementing that goal. The value of ECA is in more
clearly specifying what needs to be done.
Klyus, et al. Expires December 9, 2015 [Page 13]
Internet-Draft SUPA - Proposition June 2015
3.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 roles. 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 definition of the goals of the policy as well as
how to implement those goals.
For example, compare the ECA and declarative forms of the SLA
Service Management Policy:
Declarative form:
Proactively monitor Gold Service users to ensure their SLAs
are not violated.
ECA form:
Event: alarm received or periodic time check
Condition: if DSCP == AFxy and
throughput < T% or packet loss > P%
Action: no: no action
yes: remark to AFx'y'; reconfigure queuing;
configure shaping to S pps; ...
The declarative policy is more abstract than its ECA counterpart,
since the declarative version expresses intent without defining
which specific network elements are affected and how the
configuration of those network elements should be changed. The
above ECA policy rule is written in a high-level form, but note
that it still is specifying how to monitor the Gold Service, how
to determine if the SLA is being violated, and which actions to
take.
The execution of the declarative example could result in one or
more ECA policy rules being triggered, such as the one above.
Similarly, an ECA policy rule could trigger additional ECA policy
rules to be evaluated. For example, the above ECA rule could be
rewritten so that if the condition was satisfied, then each of
the actions shown could be their own policy rules. This provides
additional flexibility through reusing policy rules and the
components of policy rules.
Klyus, et al. Expires December 9, 2015 [Page 14]
Internet-Draft SUPA - Proposition June 2015
4. Related Work
4.1. Related Work within the IETF
4.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 does not directly
interface to the routing system. Rather, SUPA uses data
produced by I2RS (e.g., topological information) to construct
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
L3SM defines an L3 VPN service model that can be used for
communication between customers and network operators. This
model enables an orchestration application or customers to
request network services provided by L3 VPN technologies. The
implementation of network services is often guided by specific
policies, and SUPA provides a tool that can help with the
mapping of L3 VPN service requests to L3 VPN configurations of
network elements.
4.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
physical to groups of networks following similar paths or
restraints. Although this model can represent different levels
of 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.
Klyus, et al. Expires December 9, 2015 [Page 15]
Internet-Draft SUPA - Proposition June 2015
4.1.4. TEAS Working Group
The Traffic Engineering Architecture and Signaling (TEAS)
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.
4.1.5. BESS Working Group
The BGP Enabled Services (BESS) working group 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 solutions 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 could generate
BGP configurations by using data defined by BESS as part of
its policies for configuring resources and/or services.
SUPA could also define policies that govern different aspects
of services defined by BESS.
4.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.
Klyus, et al. Expires December 9, 2015 [Page 16]
Internet-Draft SUPA - Proposition June 2015
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.
4.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; rather, it
uses policy information to perform some functions. 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).
4.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 that 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 ACTN
and SUPA use YANG data models. SUPA could define policies that
define the behavior of the controller.
4.1.9. Previous IETF Policy Models
SUPA is technology-neutral, previous RFCs weren't. SUPA defines a
common structure from which both ECA and declarative policies can
be defined and combined; this was not possible in previous RFCs.
Previous RFCs do NOT define metadata, and do NOT enable policies
to formally define obligation, permission, and related concepts.
Finally, SUPA uses software patterns, which previous RFCs didn't.
4.2. Related Work outside the IETF
Klyus, et al. Expires December 9, 2015 [Page 17]
Internet-Draft SUPA - Proposition June 2015
4.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 TMF 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
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 [ID.draft-strassner-supa-generic-
policy-info-model] is based on this work. It currently extends
the ZOOM 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 of ZOOM. Finally, it should be noted that
the data model work planned for SUPA is not currently planned
for the ZOOM project.
4.2.2. 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
Klyus, et al. Expires December 9, 2015 [Page 18]
Internet-Draft SUPA - Proposition June 2015
(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 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 defined by the MEF. While the MEF has created
rigorous definitions of these services, they are specific to
transport technology, and they do not include and rely on policies.
4.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. Open Daylight is an open source project.
4.2.3.1. Network Intent Composition (NIC)
The Network Intent Composition project aims at providing better
flexibility by using declarative policies. It does not cover
other types of policies, such as ECA policy rules. The intent-
based interface aims to provide a high level of abstraction,
primarily for use by an application developer. Its progress
has recently stalled.
4.2.3.2. Group Based 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. The model
is positioned as declarative, but uses a relational approach to
specifying policy.
4.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. A
members-only whitepaper was recently published.
Klyus, et al. Expires December 9, 2015 [Page 19]
Internet-Draft SUPA - Proposition June 2015
4.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.
4.2.5.1. Group-Based Policy
The Group-Based Policy 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 Group-Based Policies is limited to networking
within the Neutron module.
4.2.5.2. Congress
The Congress project within OpenStack provides a way to define
complex policies using extensions to the Datalog language.
Datalog is entirely declarative, and its evaluation is based on
first-order logic with restrictions. This 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.
There is a significant body of knowledge and experience relating
to declarative languages and their implementation. Congress
policies aim at manipulating objects exposed by multiple
OpenStack modules, and is therefore larger in scope than network
element policies.
The declarative policies of SUPA are similar to those in Congress;
the primary difference relies in the characteristics and behavior
(in the sense of restrictions) of the underlying logic for
Congress vs. SUPA. SUPA's propositional logic statements are
simpler but more limited than Congress, while SUPA's first-order
logic statements are more complex but more powerful than those
of Congress. If desired, a Congress model could be easily added
to SUPA.
Klyus, et al. Expires December 9, 2015 [Page 20]
Internet-Draft SUPA - Proposition June 2015
4.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. This work is
organized in the Intent-Based NEMO (IBNEMO) mail list within
the IETF.
NEMO declarative policies are different than SUPA declarative
policies. NEMO uses a flatter, simpler object model with fewer
objects, does not support ECA policies, and emphasizes the use
of a language. SUPA uses a richer class model that offers both
ECA and declarative policies. SUPA has not proposed a language.
4.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. The Indigo agent also supports
an abstraction layer to make it easy to integrate with physical
and virtual switches. It supports configuration of an abstraction
layer so that it can configure OpenFlow in hybrid mode.
4.2.8. The ONOS Project
The ONOS is an SDN controller design for Service Provider networks.
It uses a distributed architecture, and supports abstraction for
both southbound and northbound interfaces. Its modules are managed
as OSGi bundles. It is an open source project.
ONOS announced an "application-intent framework", which is similar
in nature to SUPA's declarative policies. However, no object model
or language has been defined yet.
5. Conclusions: the Value of SUPA
SUPA) defines an interface to a network management function that
takes high-level, possibly network-wide policies as input and
creates element configuration snippets as output. SUPA expresses
policies using a generic policy information model, and produces
generic policy YANG data models. SUPA focuses on management
policies that control the configuration of network elements.
Management policies can be interpreted outside of network
elements, and the interpretation typically results in
configuration changes of collections of network elements.
Klyus, et al. Expires December 9, 2015 [Page 21]
Internet-Draft SUPA - Proposition June 2015
Policies embedded in the configuration of network elements are
not in the scope of SUPA. In contrast to policies targeted by
SUPA, embedded policies are usually interpreted on network
elements in isolation, and often at timescales that require the
representation of embedded policies to be optimized for a
specific purpose.
The SUPA information model generalizes common concepts from
multiple technology-specific data models, and makes it reusable.
Conceptually, SUPA can be used to interface and manage existing
and future data models produced by other IETF working groups.
In addition, by defining an object-oriented information model
with metdata, the characteristics and behavior of data models
can be better defined.
6. Security Considerations
TBD.
7. IANA Considerations
This document has no actions for IANA.
8. Contributors
The following people all contributed to creating this document:
Jun Bi, Tsinghua University
Vikram Choudhary, Huawei Technologies
Luis M. Contreras, Telefonica I+D
Georgios Karagiannis, Huawei Technologies
Hosnieh Rafiee, Huawei Technologies Duesseldorf GmbH
Dan Romascanu, Avaya
J. Schoenwaelder, Jacobs University, Germany
Qiong Sun, China Telecom
Parviz Yegani, Juniper Networks
Cathy Zhou, Huawei Technologies
9. Acknowledgments
This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in
alphabetical order: J. Bi, Luis M. Contreras, G. Karagiannis, D.
Romascanu, J. Schoenwaelder, Q. Sun, P. Yegani, and C. Zhou.
Klyus, et al. Expires December 9, 2015 [Page 22]
Internet-Draft SUPA - Proposition June 2015
10. References
10.1. 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.
[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.
[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
Authors' Addresses
Maxim Klyus, Ed.
NetCracker
Kozhevnicheskaya str.,7 Bldg. #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
Klyus, et al. Expires December 9, 2015 [Page 23]