SUPA Proposition
draft-klyus-supa-proposition-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Maxim Klyus , John Strassner | ||
| Last updated | 2015-06-07 | ||
| Replaced by | draft-klyus-supa-value-proposition | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-klyus-supa-proposition-00
Network Working Group M. Klyus
Internet Draft NetCracker
Intended status: Standard Track J. Strassner
Expires: December 2015 Huawei Technologies
June 6, 2015
SUPA Proposition
draft-klyus-supa-proposition-00
Abstract
The rapid increase in enterprise and service provider network
architecture complexity makes operating and managing services
much more difficult. Simplified Use of Policy Abstractions
(SUPA) defines a generic policy information model, and
associated generic YANG data models, for different types of
policy rules that control managed entities throughout the
service development and deployment lifecycle. It also defines a
mapping by which the management and monitoring of network
services can be done using standardized policy rules.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
Klyus, et al. Expires September 6, 2015 [Page 1]
Internet-Draft SUPA - Proposition June 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction .................................................. 3
1.1. Problem Statement ........................................ 4
1.2. Requirements ............................................. 6
2. Terminology ................................................... 7
3. Framework for Generic Policy-based Management ................. 9
3.1. Overview ................................................. 9
3.2. Functional Entities ..................................... 12
3.2.1. Service Management ................................. 12
3.2.2. Network Manager/Controller ......................... 12
3.2.3. Network Elements ................................... 14
3.3. Generic Management Policy Information Model ............. 14
3.4. Refinement of the SGPIM ................................. 15
3.4.1. Event-Condition-Action Policy Information Model .... 15
3.4.2. Declarative Policy Information Model ............... 15
3.4.3. Data Model Mappings ................................ 15
4. Application of Generic Policy-based Management ............... 15
4.1. Declarative Example ..................................... 16
4.2. ECA Example ............................................. 16
4.3. ECA plus Declarative Example ............................ 17
5. Related Work ................................................. 18
5.1. Related Work within the IETF ............................ 18
5.1.1. I2RS Working Group ................................. 18
5.1.2. L3SM Working Group ................................. 18
5.1.3. ALTO Working Group ................................. 18
5.1.4. TEAS Working Group ................................. 19
5.1.5. BESS Working Group ................................. 19
5.1.6. SFC Working Group .................................. 20
5.1.7. NVO3 Working Group ................................. 20
5.1.8. ACTN Working Group ................................. 20
Klyus, et al. Expires December 6, 2015 [Page 2]
Internet-Draft SUPA - Proposition June 2015
5.2. Related Work outside the IETF ........................... 21
5.2.1. TM Forum ........................................... 21
5.2.2. MEF ................................................ 22
5.2.3. Open Daylight ...................................... 23
5.2.4. Open Networking Foundation ......................... 23
5.2.5. OpenStack .......................................... 23
5.2.6. The NEMO Project ................................... 24
5.2.7. The Floodlight Project ............................. 25
5.2.8. The ONOS Project ................................... 25
5.3. Technical Implementation Scenarios ...................... 25
6. Framework Summary ? Features and Benefits .................... 25
7. Security Considerations ...................................... 26
8. IANA Considerations........................................... 26
9. Acknowledgments .............................................. 26
10. References .................................................. 26
10.1. Normative References ................................... 26
10.2. Informative References ................................. 26
1. Introduction
Network operators, including Internet Service Providers,
Datacenters operators and others, are under constant pressure
to optimize the usage of their installed network resources
while maintaining high availability, complexity and deploying
new services at an ever-increasing pace. The introduction of
new paradigms aims at reducing these efforts, optimized network
resource usage and minimize operational overhead. Such a new
paradigm is the deployment of automated network configuration
and optimization through the use of two complementary
mechanisms that are software abstractions to simplify
monitoring and control operations and the increase in
programmatic control over the configuration and operation of
such networks. Policy-based management can be used to combine
these two mechanisms into an extensible framework.
Management applications would benefit from a view of the
network that is adapted to their needs and from a policy
framework that is efficient and simple to use. Several
organizations have started working on protocols and models to
be used between controllers and network devices, either
physical ones or virtualized. This work started some years ago
in a number of different organizations and has spawned a large
amount of interest in the networking community.
However the definition of interfaces between controllers and
applications, the so-called "northbound" side, has seen a lot
less progress during the same time. There's a need for
management applications to interface with controllers in a
Klyus, et al. Expires December 6, 2015 [Page 3]
Internet-Draft SUPA - Proposition June 2015
simple and elegant way. For this purpose, applications require
a way to express their requirements in the form of simple
policy statements applied to network elements. These network
elements should be as simplified (abstracted) as possible for
their manipulation by the application.
The responsibility of providing an abstract and simple view
adapted to each application need is the burden of the
controller. The goal of the Simplified Use of Policy
Abstractions (SUPA) group is to develop a methodology by which
network services can be managed and automated by using a set of
information policy model and how these model can map to YANG-
based service and policy data models. It also focus on how to
communicate these policy models. SUPA will focus in the first
phase on inter-datacenter traffic management as part of the
distributed data center use case, including the set of
information models required to construct an extensible, policy-
based framework.
These information models will lead to a set of core YANG data
models for a policy-based management framework to monitor and
control network services.
1.1. Problem Statement
Network operators are faced with networks of increasing size
and complexity while trying to improve their quality and
availability, as more and more business services depend on them.
Software abstractions simplify the design and configuration of
monitoring and control operations, and enable more powerful
programmatic control (often called software-defined) to be
exerted. These are considered by many network operators as an
essential tool toward the management of that complexity.
Providing means to network operators to (1) express policies on
top of arbitrary configuration data models and (2) represent
and use multiple types of policy rules, enable significant
improvements in configuration agility, error detection and
uptime for operators.
This section describes the problems that need to be addressed
in order to equip service providers with a generic policy-based
management model that can represent multiple types of policy
rules to quickly and dynamically manage their offering of
network services.
The rapid growth in the variety and importance of traffic
flowing over increasingly complex enterprise and service
Klyus, et al. Expires December 6, 2015 [Page 4]
Internet-Draft SUPA - Proposition June 2015
provider network makes the task of network operations and
management applications and of deploying new services much more
difficult.
This is a significant challenge that network operators (service
providers, SME, etc) face today.
Several mechanisms can be used to deal with this challenge. The
main ones are: (1) the use of software abstractions to simplify
the design and configuration of monitoring and control
operations and (2) the use of programmatic control over the
configuration and operation of such networks. The combination
of these mechanisms can (1) provide additional and significant
benefits in design and deployment agility and (2) be used to
define a generic policy-based management model.
In particular, the power of policy management is its
applicability to many different types of systems. Many
different types of actors can be identified that can use a
policy management system, including applications, end-users,
developers, network administrators and operators. Each of these
actors, typically, has different skills and uses different
concepts and terminologies. For example, an operator may want
to express that only Platinum and Gold users can use streaming
and interactive multimedia applications. As a second example,
an operator may want to define a more concrete policy rule that
looks at the number of dropped packets. If, for example, this
number exceeds a certain threshold value, then the applied
queuing, dropping and scheduling algorithms could be changed in
order to reduce the number of dropped packets.
Both examples can be referred to as "policy rules", but they
take very different forms, since they are at very different
levels of abstraction and likely authored by different actors.
The first example described a very abstract policy rule, and
did not contain any technology-specific terms, while the second
example included a more concrete policy rule and likely used
technical terms of a general (e.g., IP address range, port
numbers) as well as vendor-specific nature (e.g., specific
algorithms implemented in a particular device). Furthermore,
these two policy rules could affect each other. For example,
Gold and Platinum users might need different device
configurations to give the proper QoS markings to their
streaming multimedia traffic. This is very difficult to do if a
common policy framework does not exist.
It needs to be mentioned that there are ongoing policy modeling
efforts in IETF. However, all these policy modeling efforts can
Klyus, et al. Expires December 6, 2015 [Page 5]
Internet-Draft SUPA - Proposition June 2015
be characterized as being technology-specific. This means that
the IETF needs to reinvent the wheel in different colors (i.e.,
policy models that apply for a specific technology) several
times.
SUPA will address these challenges by:
(1) developing an information model fragment for defining
standardized policy rules at different levels of abstraction,
(2) specifying how to map this information fragment into
corresponding YANG [RFC6020] and [RFC6991], data models to
define interoperable implementations that can exchange and
modify generic policies using protocols such as
NETCONF/RESTCONF on the interface north of the controller
(or other similar management entity) and south of the
service manager.
Specifically, three information model fragments are envisioned:
(a) a generic policy information model (GPIM) that defines
concepts needed by policy management independent of the form
and content of the policy
(b) a more specific information model that refines the
generic information model to specify how to build policy
rules of the event-condition-action (ECA) paradigm
(c) a more specific information model that refines the
generic information model to specify how to build policy
rules that declaratively specify what goals to achieve (but
not how to achieve those goals); this is often called
"intent-based" policy
1.2. Requirements
In order to satisfy the challenges mentioned in Section 1.1 and
the goal of the DDC use case briefly described in section 5.3,
the following requirements need to be addressed:
o) Specify a generic and non-technology specific policy
information model.
o) Specify a more specific information model that defines
how to build policy rules of the event-condition-action
(ECA) paradigm.
o) Specify a more specific information model that defines
how to build policy rules that declaratively specify what
Klyus, et al. Expires December 6, 2015 [Page 6]
Internet-Draft SUPA - Proposition June 2015
goals (what intents) to achieve using the Goal (Intent)
policy paradigm.
o) Specify how to map the above mentioned information models
into corresponding YANG standardized data models to define
interoperable implementations that can exchange and modify
generic policies using protocols such as NETCONF/RESTCONF on
the interface north of the controller (or other similar
management entity) and south of the service manager.
2. Terminology
This section defines acronyms and terms used in the rest of
this document.
NE Network Element
NC Network Controller
NM Network Manager
NS Network Service
Some of definitions are based on [RaBe11] and/or [Stras02].
Network Service: the composition of network functions as
defined by its functional and behavioral specification. A
network service is characterized by performance, dependability,
and security specifications. Furthermore, a network service is
delivered by network service endpoints, which may be
aggregations of multiple lower-layer technology specific
endpoints.
Network Element: a physical or virtual entity that implements
one or more network function(s). NEs can interact with local or
remote network controllers in order to exchange information,
such as configuration information and status.
Service specific abstraction: an abstract view of the service
topology, associated with a specific network service type, e.g.,
inter-datacenter communication services
Policy: a definite goal, course, or method of action to guide
and determine present and future decisions. Policies are
implemented or executed within a particular context.
SUPA policy: a means to monitor and control the changing and/or
maintaining of the state of one or more managed entities.
Klyus, et al. Expires December 6, 2015 [Page 7]
Internet-Draft SUPA - Proposition June 2015
Policy-based management: the usage of policy rules to manage
one or more entities.
Information Model: a representation of managed objects and
their relationships that is independent of data repository,
language, and protocol.
Data Model: a representation of managed objects and their
relationships that is dependent on data repository, language,
and/or protocol (typically all three).
Policy Rule: A container that uses metadata to define how the
content is interpreted, and hence, how the behavior that it
governs is defined separates the content of the policy from its
representation provides a convenient control point for OAMP
operations.
Policy condition: a representation of the necessary state
and/or prerequisites that define whether a policy rule?s
actions should be performed.
Policy action: defines what is to be done to enforce a policy
rule when its conditions are met.
Event Condition Action policy: reactive behavior of a system
that correlates a set of events, a set of conditions, and a set
of actions. Conditions are evaluated on the occurrence of an
event and which determine whether the policy is applicable or
not for that particular situation. Furthermore, the actions are
only executed only if the conditions are met.
Goal (Intent) policy rule (also called a declarative policy
rule, or an intent-based policy rule): a declarative statement
that defines what the policy should do, but not how to
implement the policy.
Model Mapping: a translation from one type of model to another
type of model. Model mapping changes the representation and/or
level of abstraction used to another representation and/or
level of abstraction. The most common form of model mapping is
from an information model to a data model; another important
form is from a vendor-neutral data model to a vendor-specific
data model.
Klyus, et al. Expires December 6, 2015 [Page 8]
Internet-Draft SUPA - Proposition June 2015
3. Framework for Generic Policy-based Management
The SUPA policy framework defines a set of consistent,
flexible, and scalable mechanisms for monitoring and
controlling resources and services. It may be used to create a
management and operations interface that can enable existing
IETF frameworks, including but not limited to I2RS and L3SM. It
allows resources and services to be controlled and monitored in
a unified way that is independent of technology and vendor.
Resource and service management become more effective, because
policy defines the context that different operations, such as
configuration, are applied to.
3.1. Overview
<insert explanation of Figure 1>
+-----------------------------------------------------------------
| Service Management |
| +----------------------------------+ |
| | Generic Policy Information Model | |
| +----+------------------------+----+ |
| D R |
| D R |
| \ / \ / |
| +---------------------------+ +-------------------------------+ |
| | Generic Policy Data Model | | Service Management Data Model | |
| +---------------------------+ +---------------+---------------+ |
| / \ / \ |
| | | |
| | NETCONF/RESTCONF | |
| +----+----------------------+----+ |
| C C |
| C C |
| \ / \ / |
| +----------------+-----------+ +-------+--------------------+ |
| | Network Manager/Controller | | Network Manager/Controller | |
| | +--------------------+ | | +---------------------+ | |
| | | Network Resource | | | | Network Resource | | |
| | | Data Model | | | | Data Model | | |
| | +--------------------+ | | +---------------------+ | |
| +----------------------------+ +----------------------------+ |
+------+---+---+-------------------------+---+---+----------------+
/ \ / \ / \ / \ / \ / \
Klyus, et al. Expires December 6, 2015 [Page 9]
Internet-Draft SUPA - Proposition June 2015
C C C C C C
C C C C C C
C C C C C C
\ / \ / \ / \ / \ / \ /
NE1 NE2 NEn NE1 NE2 NEn
Figure 1 SUPA Framework
In Figure 1:
A double-headed arrow with Cs means communication;
A double-headed arrow with Ds means derived from;
A double-headed arrow with Rs means references;
An overview of the SUPA framework is shown in Figure 1. The
network entities used in this framework are:
SM: Service Management, which represents one or more network
entities that are running and controlling network services. This
model contains the following entities:
Generic Policy Information Model: a model for defining policy
rules that are independent of data repository, data definition,
query, and implementation languages, and protocol.
Generic Policy Data Model: a model of policy rules for that
are dependent of data repository, data definition, query, and
implementation languages, and protocol.
Examples of policy information models can be found in
[ID.draft-strassner-supa-generic-policy-info-model] and
[ID.draft-bi-supa-policy-model].
There can be various types of policies, including service
specific policies and network-wide policies. There can be a
centralized and/or distributed entity or set of entities that
are responsible for the creation, management, and retirement
policy rules, which is known as a policy manager. The policy
manager can be located in the SM or in a separate location.
Policy data models now considered by SUPA take two forms:
(1) ECA (event, condition, action) and (2) declarative (also
known as intent-based), as described in
[ID.draft-strassner-supa-generic-policy-info-model]. This may
Klyus, et al. Expires December 6, 2015 [Page 10]
Internet-Draft SUPA - Proposition June 2015
be extended in the future.
Service Management Data Model: a model of the network service
(e.g., VPNs) and resources (e.g., a device interface) required
by the network service to be correctly deployed and executed
on the physical and/or virtual topology.
An example of a service management data model can be found in
[ID.draft-zaalouk-supa-vpn-service-management-model].
NM/NC: Network Manager / Controller, which represents one or
more entities that are able to control the operation and
management of a network infrastructure (e.g., a network
topology that consists of Network Elements (NEs)).
Network Resource Data Model: a model of the physical and
virtual network topology including the resource attributes
(e.g., data rate or latency of links) and operational
parameters needed to support service deployment over the
network topology.
An example of a network resource data model can be found in
[ID.draft-contreras-supa-yang-network-topo].
SUPA will not define network resource data models, which is
out of the scope of SUPA. SUPA will make use of network
resource data models defined by other WGs or SDOs.
Network Element (NE), which handles packets based on the network
management and controlling procedures. NEs can interact with
local or remote NM/NC in order to exchange information, such as
configuration information, policy enforcement capabilities, and
network status.
Service Management (SM) communicates with the NM/NC using an
appropriate protocol, such as NETCONF [RFC6241] or RESTCONF
[ID.draft-ietf-netconf-restconf].
NM/NC exchanges configuration information with NEs and derives the
current network topology that contains the NEs, and also the
capabilities and status of NEs, which will be stored in network
Klyus, et al. Expires December 6, 2015 [Page 11]
Internet-Draft SUPA - Proposition June 2015
resource data model. NM/NC may also communication with a network
management system to retrieve the above information. It can use
existing network management and signaling protocols, such as I2RS
[I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf-
restconf], etc.
Service Management (SM) will send policy rules and associated data
(e.g., service management data), both in the form of a data model,
To the NM/NC. The NM/NC will (in conjunction with network resource
data models) then produce NE configurations.
3.2. Functional Entities
3.2.1. Service Management
There are a wide variety of communication services offered by
service providers.
The Service Management (SM) is a functional entity, residing at
the Application layer, which enables network services, such as:
o) Network services (e.g., L2VPN, L3VPN, etc.)
o) application-specific policies
SM will push service management data model and policy data model
to NM/NC for service deployment.
3.2.2. Network Manager/Controller
|
| to/from Service Management
|
+--------------------------+----------------------------------------+
| Network Manager/Controller Functional Block |
| +-------------------------------+ +---------------------------+ |
| | NM/NC to SM Interface | | mapping: Policy Data | |
| +-------------------------------+ | Model + Network Resource | |
| | Data Model to Service | |
| +-------------------------------+ | Specific Topology | |
| | | +---------------------------+ |
| | Network Resource Data Model | |
| | | +---------------------------+ |
| +-------------------------------+ | mapping: Service Data | |
Klyus, et al. Expires December 6, 2015 [Page 12]
Internet-Draft SUPA - Proposition June 2015
| | Model + Service Specific | |
| +-------------------------------+ | Topology to Detail NEs' | |
| | NM/NC to NE Interface | | Configurations | |
| +-------------------------------+ +---------------------------+ |
+-------------------------------------------------------------------+
Figure 2 NM/NC Functional Blocks
Network Manager/Controller (NM/NC) is a functional entity that is
able to generate and maintain desired and current topologies of
the network infrastructure. As part of this process, it is also
responsible for reserving and releasing network resources that are
required to support network services in a given network
infrastructure.
The NM/NC contains a set of data models, functions and APIs,
including:
o) Network Resource Data Model
Maintain an up to date topology of the network infrastructure,
including capabilities and current status of NEs.
o) Mapping: service specific topology
This mapping procedure will combine the policy data model and
service management data model and generate a specific topology.
o) Mapping: target NE(s) detail configurations
This mapping procedure will use the service specific topology
generated in the previous procedure and the service management
data model to generate detail NE(s) configurations.
o) NM/NC to traditional network management system interface:
provides the interface with existing network management system
protocols (e.g., I2RS [I2RS], NETCONF, etc.) to request
configuration and status information, and push configuration
changes to NEs.
o) NM/NC to SM interface: used to support the communication
between the SM and NM/NC. The candidate protocols used for this
purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft-
ietf-netconf-restconf].
Klyus, et al. Expires December 6, 2015 [Page 13]
Internet-Draft SUPA - Proposition June 2015
An example of the mapping procedures can be that, a service
requires that a link from A to B is created; and the policy
requires that the hops of this link should not exceed N. Then when
NM/NC receives the policy data model and service management data
model from SM, it will first apply the policy data model to the
network resource data model and get a sub-set topology which can
fulfill the hops limit requirements. Then NM/NC will further
generate detail configurations for target NE(s). The mapping
procedures can be enforced by functional entity called policy
agent.
After the service is deployed, if there is a network topology
change, network configurations for this service may need to be
updated accordingly. A possible solution is to repeat the mapping
procedures, and generate configurations for NEs (maybe another set
of NEs). This requires that NM/NC maintains a copy of the service
management data models and policy data models.
For more detail about mapping mechanisms, please refer to
[ID.draft-pentikousis-supa-mapping].
3.2.3. Network Elements
The Network Element (NE) responds to requests and commands from
the NM/NC and makes corresponding configuration changes. An NE may
be a physical or a virtual entity, and is locally managed (e.g.,
via CLI, SNMP, or NETCONF).
SUPA will specify mechanisms, in order to enable the NEs to
interact with either local or remote network management systems.
The interaction may include the exchange of information, such as
configuration and status information. The NEs will be able to push
this information in an event that the NM/NC can subscribe to,
and/or provide this information after receiving a request from the
NM/NC.
3.3. Generic Management Policy Information Model
The purpose of the SUPA Generic Policy Information Model (SGPIM)
is to define a common framework for expressing policies at
different levels of abstraction. SUPA uses the SGPIM as a
common vocabulary for representing concepts that are common to
expressing policy, but which are independent of language,
Klyus, et al. Expires December 6, 2015 [Page 14]
Internet-Draft SUPA - Proposition June 2015
protocol, repository, and level of abstraction. This enables
different policies at different levels of abstraction to form a
continuum, where more abstract policies can be translated into
more concrete policies, and vice-versa.
3.4. Refinement of the SGPIM
An information model is abstract. As such, it cannot be
instantiated (i.e., objects cannot be created directly from
it).
Therefore, SUPA defines a mapping from its information model to
two different data models (which can be instantiated). These
two data models represent two different forms of policy rules,
with two different sets of semantics. One is an event-
condition-action (ECA) form, while the other is a declarative,
or logic-based, form. This provides two different types of
abstractions that serve different use cases. It also helps
prove the genericity of the SGPIM.
3.4.1. Event-Condition-Action Policy Information Model
The SUPA ECA Policy Rule Information Model (EPRIM) represents a
policy rule as a statement that consists of an event clause, a
condition clause, and an action clause. This type of Policy
Rule explicitly defines the current and desired states of the
system being managed.
3.4.2. Declarative Policy Information Model
The SUPA Logic Statement Information Model (SLSIM) is a set of
(logic-based) propositions that form a (single) conclusion. A
proposition is either TRUE or FALSE. A proposition be created
from simpler propositions. This version of the SGPIM defines
two forms of SUPA Logic Statements: one using propositional
logic, and one using first order logic.
3.4.3. Data Model Mappings
The SGPIM defines concepts common to any type of policy rule or
statement. It is used in combination with the EPRIM or the
SLSIM to create a reusable model of a policy. This combined
information model is then mapped to a YANG data model.
4. Application of Generic Policy-based Management
This section provides examples of how SUPA can be used to
define different types of policies. Examples applied to various
Klyus, et al. Expires December 6, 2015 [Page 15]
Internet-Draft SUPA - Proposition June 2015
domains, including access control, routing, and service
function chaining, are also included.
4.1. Declarative Example
Declarative policies are policies that describe what to do, but
not how to do it. Declarative policies can apply to services
and/or resources. Here are some simple examples:
Access to source code servers is limited to Intranet users.
The above policy does not specify ports, protocols, IP addresses,
or other specific technology. Furthermore, it is not limited to
any one specific user or application.
Periodically perform workload consolidation if average CPU
utilization falls below X%.
Again, note the lack of technology-specific references in the
policy.
Proactively monitor Gold Service users to ensure their SLAs
are not violated.
In the above policy, Gold Service is an aggregation of different
traffic types, each with different constraints. The policy will
dynamically create a service function chain based on the current
context to ensure that the customer's SLA is not violated.
4.2. ECA Example
ECA equivalents to the above three examples follow.
Access to source code servers is limited to Intranet users.
Event: access request to code server received
Condition: is connection type intranet based
Action: no: deny; yes: accept
Periodically perform workload consolidation if average CPU
utilization falls below X%.
Event: alarm or periodic time period check
Condition: CPU utilization level comparison
Action: no violation: no action
violation:
1) determine workload profile in time interval
2) determine complementary workloads (e.g.,
Klyus, et al. Expires December 6, 2015 [Page 16]
Internet-Draft SUPA - Proposition June 2015
whose peaks are at different times in day)
3) combine workloads (e.g., using integer
programming)
Proactively monitor Gold Service users to ensure their SLAs
are not violated.
Event: alarm or periodic time check
Condition: is SLA metric set in danger of being violated
Action: no: no action
yes: based on metric(s) being violated, take
one or more actions such as remark, change
queuing, dropping, and/or scheduling parameters
(or even the algorithm), create new service to
offload traffic, etc.
In the above examples, the event, condition, and/or action
clauses are typically expressed using technology-specific
concepts. This is in direct contrast to their declarative
equivalents.
4.3. ECA plus Declarative Example
The fundamental reason that SUPA defines two different types of
policy rules is to enable different actors to express policy in
a manner conducive to their role. The SGPIM defines concepts
that are common to both the EPRIM and the SLSIM. This enables
these two types of policies to be used together to provide a
more powerful description.
For example, consider the second example above. The declarative
policy is conceptually more abstract than its ECA counterpart,
since the declarative version expresses intent without defining
which specific managed entities are affected. The execution of
the declarative example could result in one or more ECA policy
rules being triggered. Similarly, an ECA policy rule could
trigger additional ECA policy rules to be evaluated.
The advantage of this approach is that policy, along with
metadata, can be used to dynamically decide which service
functions to insert into a path (instead of being restricted to
a fixed, linear set of service functions).
Klyus, et al. Expires December 6, 2015 [Page 17]
Internet-Draft SUPA - Proposition June 2015
5. Related Work
5.1. Related Work within the IETF
5.1.1. I2RS Working Group
I2RS defines an interface that interacts with the routing
system using a collection of protocol-based control or
management interfaces. Users of I2RS interfaces are typically
management applications and controllers. SUPA is an I2RS
client, and does not directly interface to the routing system.
Rather, SUPA uses data produced by I2RS (e.g., topological
information) to construct its policies.
The SUPA use case involved distributed data center
interconnection; this use case defines a multi-tenant
environment, where each tenant may control and monitor its
network, even if that network may be physically located in a
different data center. In contrast, I2RS defines interfaces to
routing system (i.e., the collection of entities, protocols,
and processes that collectively build the forwarding tables
that are exported to the network's forwarding plane).
It is envisioned that SUPA will use work produced by I2RS. SUPA
may also provide policies that can be used by I2RS to monitor
and control the routing system. Since both SUPA and I2RS uses
YANG data models, communication between the two groups is
facilitated.
5.1.2. L3SM Working Group
L3SM defines an L3 VPN service model that can be used for
communication between customers and network operators. This
model enables customers to configure the network elements via
L3 VPN technologies. In contrast, SUPA defines policies that
are independent of a specific type of service, and hence
conceptually, provides policies that define the configuration
requirements for L3 VPN models that L3SM then implements. Both
SUPA and L3SM use YANG data models.
5.1.3. ALTO Working Group
The ALTO working group defined an architecture for exposing
topology information, more specifically the cost of paths
through an infrastructure, as defined in [RFC7285]. ALTO
services are able to provide network maps defined as groups of
endpoints. Endpoints are provider-defined entities, and can
therefore represent any granularity of network, from the
Klyus, et al. Expires December 6, 2015 [Page 18]
Internet-Draft SUPA - Proposition June 2015
physical to groups of networks following similar paths or
restraints. Although this model can represent different levels
of abstraction at multiple granularities, it is not clear if it
could be adapted easily for other purposes than providing cost
maps in the context of ALTO. The ALTO model is meant to be used
outside of the trust domain of an ISP by external clients.
SUPA does not generate data that is similar to ALTO. Rather,
SUPA could use ALTO data as part of its policies to configure
services and/or resources. SUPA could also interact with ALTO
by defining policies that tell the host which ALTO server to
use.
5.1.4. TEAS Working Group
The Traffic Engineering Architecture and Signaling working
group is responsible for defining MPLS- and GMPLS-based Traffic
Engineering architectures that enable operators to control how
specific traffic flows are treated within their networks. It
covers YANG models for a traffic engineering database, in
coordination with other working groups (I2RS) providing YANG
models for network topologies.
Both TEAS and SUPA use YANG data models. SUPA does not generate
traffic engineering (TE) data. However, SUPA could use TE data
as part of its policies for configuring resources and/or
services.
SUPA could also define policies that define which service,
path, and link properties to use for a given customer, and
consequently, which protocol extensions to use. TEAS data could
also be used to enable operators to define how particular
traffic flows are treated in a more abstract (but still
consistent) manner.
5.1.5. BESS Working Group
The BGP Enabled Services defines and extends network services
that are based on BGP. This includes BGP/MPLS IP provider-
provisioned L3VPNs, L2VPNs, BGP-enabled VPN solutions for use
in data center networking, and extensions to BGP-enabled
solution to construct virtual topologies in support of services
such as Service Function Chaining. The working group is also
chartered to work on BGP extensions to YANG models and data
models for BGP-enabled services.
Both BESS and SUPA use YANG data models. SUPA does not generate
BGP configurations. However, SUPA could use data defined by
Klyus, et al. Expires December 6, 2015 [Page 19]
Internet-Draft SUPA - Proposition June 2015
BESS as part of its policies for configuring resources and/or
services.
SUPA could also define policies that define that govern
different aspects of services defined by BESS.
5.1.6. SFC Working Group
The Service Function Chaining (SFC) working group defines a
mechanism where traffic is classified; that classification is
then use to select an ordered set of services to pass the
traffic through.
Both SFC and SUPA use YANG data models. SUPA could define
policies that augment the functionality of SFC in several
different ways, including: (1) path selection based on context,
(2) which set of mechanisms to use to steer traffic through
which set of service functions, (3) simplify the definition of
dynamic service function chains (e.g., service paths that
change based upon a set of data that is discovered at runtime),
and (4) scalable mechanisms to monitor and control the
configuration of SFC components.
5.1.7. NVO3 Working Group
The NVO3 group proposes a way to virtualize the network edge
for data centers in order to be able to move virtual instances
without impacting their network configuration. This is realized
through a centrally controlled overlay layer-3 network. The
NVO3 work is not about defining policy information.
Both NVO3 and SUPA use YANG data models. SUPA could define
policies that define how the logically centralized network
virtualization management entity (or entities) of NVO3 behave
(e.g., the functions in the network virtualization control
plane).
5.1.8. ACTN Working Group
The ACTN proposed work, as described in [actn] framework, has
two main goals, the abstraction of multiple optical transport
domains into a single controller offering a common abstract
topology and the splitting of that topology into abstract
client views, which are usually a fraction of the complete
network. The ACTN work is therefore about unification of
several physical controllers in a virtual one and also about
the segmentation, isolation and sharing of network resources.
The ACTN work is not explicitly about policies, but some level
Klyus, et al. Expires December 6, 2015 [Page 20]
Internet-Draft SUPA - Proposition June 2015
of policing is applied in the creation of a client view and the
way it interacts with the virtual controller beneath. One point
where overlap may exist with some of the work proposed in SUPA
is in the definition of multiple levels of abstract topologies.
The ACTN proposed work, as described in [actn] framework, has
two main goals, the abstraction of multiple optical transport
domains into a single controller offering a common abstract
topology, and the splitting of that topology into abstract
client views, which are usually a fraction of the complete
network. The ACTN work is therefore about unification of
several physical controllers into a virtual one, and also about
the segmentation, isolation and sharing of network resources.
The ACTN work is not about defining policy information.
Both SFC and SUPA use YANG data models. SUPA could define
policies that define the behavior of the controller.
5.2. Related Work outside the IETF
5.2.1. TM Forum
The TM Forum (a.k.a., the TeleManagement Forum) develops
standards and best practices, research, and collaborative
programs focused on digital business transformation. It
consists of three major programs:
1) Agile Business and IT
2) Customer Centricity (experience)
3) Open Digital Ecosystem
Of these, the ZOOM (Zero-touch Orchestration, Operations, and
Management) project, located in the Agile Business and IT
project, is the main sub-project in this area that is of
interest to SUPA.
Within ZOOM, the Foundational Studies project contains work on
an information model and management architecture that are
directly relevant to SUPA. The Information Model, Policy, and
Security working groups are involved in this work.
The ZOOM information model updates the existing Shared
Information and Data (SID) information model to add support for
the management of physical and virtual infrastructure, event-
and data-driven systems, policy management (architecture and
Klyus, et al. Expires December 6, 2015 [Page 21]
Internet-Draft SUPA - Proposition June 2015
model), metadata for describing and prescribing behavior that
can support changes at runtime, and access control.
The policy information model defines event-condition-action
(ECA), declarative (intent-based), utility function, and
promise policies. The work in draft-strassner-supa-generic-
policy-info-model-01 is based on this work. It currently
extends the ECA model and provides additional detail not
currently present in ZOOM; the next version of this draft will
do the same for declarative policies.
There is currently no plan to use the utility function and
promise policies. Finally, it should be noted that the data
model work planned for SUPA is not currently planned for the
ZOOM project.
5.2.2. MEF
MEF
The MEF (originally named the Metro Ethernet Forum) develops
architecture, service and management specifications related to
Carrier Ethernet (CE). The CE architecture includes the
definition of several interfaces specific to CE like the User
Network Interface (UNI) and External Network Network Interface
(ENNI). Specifications developed in this space include the
definitions of CE services, CE service attributes, Ethernet
Access Services, Class of Service, OAM and Management
interfaces, Service Activation and Test.
The more recent vision of the MEF related to the future of
networking is described as The Third Network and includes plans
to develop Lifecycle Service Orchestration with APIs for
existing network, NFV and SDN implementations enabling Agile,
Assured and Orchestrated Services. This stage of the MEF
activity is now in early phases with focus on architectural
work.
The MEF has developed a number of Information and Data Models,
and has recently started a project that used YANG to model and
manage the services covered by the MEF. Although the MEF has
created quite rigorous definitions of these services, these are
transport technology specific, and they do not include and rely
on policies.
Klyus, et al. Expires December 6, 2015 [Page 22]
Internet-Draft SUPA - Proposition June 2015
5.2.3. Open Daylight
Open Daylight network controller implements a number of models
through its service abstraction Layer (MD-SAL) based on draft
IETF Yang models. Few of the below mentioned Open Daylight
projects provides policy abstraction and better flexibility to
the user.
5.2.3.1. Network Intent Composition (NIC)
Network Intent Composition project aims at providing better
flexibility and high-level interface for the specification of
policies. The intents-based interface would provide a high
level of abstraction easy to formulate by an application
developer and completely detached from the underlying
implementation details. By making intents portable and
composable, the project aims at making intents a more scalable
approach than existing interfaces.
5.2.3.2. Group Policy
The group-based policy project defines an application-centric
policy model for Open Daylight that separates information about
application connectivity requirements from information about
the underlying details of the network infrastructure.
5.2.4. Open Networking Foundation
The ONF created a group responsible of defining northbound
interfaces, but this hasn't lead to the publication of
standards in this area so far. A blog entry on the ONF web site
showed an interest in using the principle of intents at ONF,
but no details were provided on the status of this project. The
membership of this group being closed in nature, the status of
current draft proposals is not known.
5.2.5. OpenStack
OpenStack software controls large pools of compute, storage,
and networking resources throughout a datacenter, managed
through a dashboard or via the OpenStack API. OpenStack works
with popular enterprise and open source technologies making it
ideal for heterogeneous infrastructure. Few of the below
mentioned OpenStack projects provides policy abstraction and
better flexibility to the user.
Klyus, et al. Expires December 6, 2015 [Page 23]
Internet-Draft SUPA - Proposition June 2015
5.2.5.1. Group-Based Policies
The Group-Based Policies project for OpenStack Neutron is built
around entities assembled in Endpoints Groups (EPG) that
provide or consume Contracts. Such Contracts are hierarchical
entities containing policy rules. A first version was released
in January 2015, based on the Juno release. This type of
approach is more relational than declarative, but could be used
to describe a large amount of possible scenarios. It has the
advantage of providing a relatively simple policy model that
covers a large applicability. From an OpenStack point of view,
the scope of GBP is limited to networking within the Neutron
module.
5.2.5.2. Congress
The Congress project within OpenStack provides a way to
formulate complex policies using the Datalog language, a
derivate of Prolog. Datalog is entirely declarative and first-
order logic, which gives it interesting properties, such as
providing the same result no matter the order in which the
statements are made. The language allows for the definition of
types and for active enforcement or verification of the
policies. Using Datalog also allows Congress to take advantage
of the significant body of knowledge and experience relating to
declarative languages and their implementation. The Congress
policies aim at manipulating objects exposed by multiple
OpenStack modules and is therefore larger in scope than network
policying only. The only drawback of this approach lies in its
potentially large computational complexity, which could limit
its ability to react in real time fast events such as those
relating to the network.
5.2.6. The NEMO Project
The NEMO project is a research activity aiming at defining a
simple declarative framework for networking. The NEMO syntax is
not based on
an existing language and covers the basic elements for network
manipulation such as nodes, links and flows. The NEMO project
has been successfully demonstrated at IETF-91, along with a
companion graphical user interface, and this work now being
proposed as the base for a new group called Intent-Based NEMO
(IBNEMO) within the IETF.
Klyus, et al. Expires December 6, 2015 [Page 24]
Internet-Draft SUPA - Proposition June 2015
5.2.7. The Floodlight Project
The Floodlight is an openflow enabled SDN controller. it uses
another open source project called Indigo to support openflow
and manage southbound devices. Indigo agent also supports
abstraction layer to make it easy to integrate with physical
and virtual switches. It supports configuration of abstraction
layer so that it can configure openflow in hybrid mode.
5.2.8. The ONOS Project
The ONOS is a SDN controller. It supports abstraction for both
southbound and northbound interfaces. This is because NFV used
in ONOS can reduce CaPex because each service can be
virtualized, but it increases OpEx as service providers now
have to contend with increased management complexity due to the
management and orchestration of a large numbers of VMs on
commodity servers, the management of network function software
on the VMs and how VMs must be interconnected based on
subscriber's service contract. This is why, ONOS uses Network
Function as a Service (NFaaS) that not only virtualized the
components and Virtual Network Functions (VNFs) but also
introduces an abstractive unit for a collection of VMs and
their interconnecting network(s). Being able to create and
manipulate these units, rather than handling individual
components, significantly simplifies operation. NFaaS
manipulates these units in the enhanced form of a service.
5.3. Technical Implementation Scenarios
Large scale Distributed Data Centers (DDCs) can provide various
services and usually consist of many internal and external
links where various VPNs are built upon. The Service
provisioning and network connectivity configurations could be
complex and dynamic, for which manual configuration is not
onerous and error-prone.
The SUPA generic policy management models can be used to
support the dynamic and automated resource usage and simplify
and automate the service/network deployment/configuration of
various VPN scenarios in the DDC environment. A more detailed
description of this use case is provided in [ID.draft-cheng-
supa-ddc-use-cases].
6. Framework Summary ? Features and Benefits
Klyus, et al. Expires December 6, 2015 [Page 25]
Internet-Draft SUPA - Proposition June 2015
7. Security Considerations
TBD
8. IANA Considerations
This document has no actions for IANA.
9. Acknowledgments
This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in
alphabetical order: G. Karagiannis, J. Strassner, C. Zhou, Q. Sun,
Luis M. Contreras, Telefonica, P. Yegani, D. Romascanu, J. Bi
10. References
10.1. Normative References
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6991] J. Schoenwaelder, "Common YANG Data Types", July 2013
[RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman,
"Network Configuration Protocol (NETCONF)", June 2011
[RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi,
W. Roome, S. Shalunov, R. Woundy
"Application-Layer Traffic Optimization (ALTO) Protocol",
September 2014
10.2. Informative References
[SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P.
Yegani, " The Framework of Simplified Use of Policy
Abstractions (SUPA) ", IETF Internet draft, draft-zhou-supa-
framework, February 2015.
[SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M.
Contreras, P. Yegani, JF Tremblay and J. Bi, "Problem Statement
for Simplified Use of Policy Abstractions (SUPA)", IETF
Internet draft, draft-karagiannis-supa-problem-statement,
January 2015.
[SUPA-gap-analysis] J. Bi, H.Rafiee, V,Choudhary, J.Strassner,
D.Romascanu "Simplified Use of Policy Abstractions (SUPA) Gap
Analysis", IETF Internet draft, draft-bi-supa-gap-analysis, May
2015.
Klyus, et al. Expires December 6, 2015 [Page 26]
Internet-Draft SUPA - Proposition June 2015
[SUPA-DDC] Y. Cheng, and JF. Tremblay, "Use Cases for Distributed
Data Center Applications in SUPA", IETF Internet draft, draft-
cheng-supa-ddc-use-cases, January 2015
[RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal Specification of
DomainSpecific ECA Policy Models", in Proc. 2011 Fifth IEEE
International Conference on Theoretical Aspects of Software
Engineering, 2011
[Stras02] John Strassner, "DEN-ng: Achieving Business-Driven Network
Management" in Proc. IEEE Network Operations and Management Symposium
(NOMS), 2002.
Authors' Addresses
Maxim Klyus, Ed.
NetCracker
Kozhevnicheskaya str.,7 Bldg. Nr. 1
Moscow, Russia
Phone: +7-916-8575717
E-mail: klyus@netcracker.com
John Strassner, Ed.
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95138 USA
Email: john.sc.strassner@huawei.com
Georgios Karagiannis
Huawei Technologies
Hansaallee 205,
40549 Dusseldorf,
Germany
Email: Georgios.Karagiannis@huawei.com
Klyus, et al. Expires December 6, 2015 [Page 27]
Internet-Draft SUPA - Proposition June 2015
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI:http://people.tid.es/LuisM.Contreras/
Parviz Yegani
JUNIPER NETWORKS
1133 Innovation Way
Sunnyvale, CA 94089
Email: pyegani@juniper.net
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
EMail: junbi@tsinghua.edu.cn
Hosnieh Rafiee
Huawei Technologies Duesseldorf GmbH
Munich, Germany
Phone: +49 (0)162 204 74 58
E-mail: ietf@rozanak.com
Vikram Choudhary
Huawei Technologies
E-mail: vikram.choudhary@huawei.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv 61581, Israel
Phone: +972-3-6458414
E-mail: dromasca@avaya.com