Internet DRAFT - draft-pentikousis-supa-mapping
draft-pentikousis-supa-mapping
Network Working Group K. Pentikousis
Internet-Draft EICT GmbH
Intended status: Informational D. Zhang
Expires: November 12, 2015 May 11, 2015
Simplified Use of Policy Abstractions (SUPA): Configuration and Policy
Mapping
draft-pentikousis-supa-mapping-05
Abstract
Nowadays, the underlying network infrastructure grows in scale and
complexity, which make it challenging for network operators to manage
and configure the network. Deploying policy or configuration based
on an abstract view of the underlying network is much better than
manipulating each individual network element, however, in this case,
the policy and configuration cannot be recognized by the network
elements. This document describes guidelines for mapping said
abstract configuration and policy into device-level configuration and
the way in which such models will be processed by software to produce
configuration details for actual devices. The Simplified Use of
Policy Abstractions (SUPA) framework overview, exemplary mechanism
for exchanging service polices among the different elements
participating in their deployment and enforcement, and primary
procedures of mapping are described. Moreover, an exemplary mapping
scenario is provided to illustrate the defined mechanism.
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). 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."
This Internet-Draft will expire on November 12, 2015.
Pentikousis & Zhang Expires November 12, 2015 [Page 1]
Internet-Draft SUPA Configuration and Policy Mapping May 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Configuration and Policy Mapping . . . . . . . . . . . . . . 3
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Mapping Procedure . . . . . . . . . . . . . . . . . . . . 5
4.3. SUPA Mapping Example . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
As the underlying network infrastructure grows, new services are
introduced, and traffic volumes increase rapidly, it becomes
significantly more challenging and complicated to maintain the
network and deploy new services than in the past. Configuration
automation can provide significant benefits in deployment agility.
Simplified Use of Policy Abstractions (SUPA)
[I-D.zhou-supa-framework] aims to improve configuration automation by
introducing multi-level abstractions. In SUPA, a generic policy
information model [I-D.strassner-supa-generic-policy-info-model]is
defined, which defines a generic framework for representing policy
rules of any type, with this model, SUPA is capable to define a
common framework for representing different types of policies,
although the syntax and semantics of these policies are very
different. Based on the generic policy model, several policy data
Pentikousis & Zhang Expires November 12, 2015 [Page 2]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
models are defined to express different manners of policy
enforcement, such as ECA and intent-based polices. The information
models of various network services is also utilized in SUPA to allow
network operators to manipulate their infrastructure as a whole
rather than individual devices. Well-designed abstractions are able
to provide a wide range of granularity for various applications
needs. However, these information models cannot be directly utilized
by network elements, thus a mapping mechanism is necessary to bridge
the gap between these information models and network element-
recognized configuration.
SUPA employs Network Manager/Controller. Network Manager/Controllers
represent one or more entities that are able to control the operation
and management of a network infrastructure and mediate between the
Service Management and the network elements to provide, maintain and
deploy network services and policies. Each Network Manager/
Controller supports the SUPA interface/protocol and is a software
repository, which stores the information associated with each network
element. The mapping mechanism could be part of the Network Manager/
Controller implementation in order to map the SUPA model(s) into
specified configuration models (or so-called southbound interfaces),
which can be recognized by the network element(s).
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "Network Manager/Controller",
and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Terminology
This document uses the following terms:
Network element (NE): a physical or virtual entity that can be
locally managed and operated
SUPA: Simplified Use of Policy Abstractions
4. Configuration and Policy Mapping
This section introduces a framework for mapping configuration and
policy in the context of a network with several network elements and
one or more Service Managements.
Pentikousis & Zhang Expires November 12, 2015 [Page 3]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
4.1. Overview
The SUPA framework for mapping network-level configuration into
specific network management and controlling policies is illustrated
in Figure 1. It consists of i) Service Management, ii) Network
Manager/Controller and iii) NEs.
+------------------------+ -------------------------
| Service Management | |
| +--------------------+ | |
| | Policy | | |
| +--------------------+ | |
| +--------------------+ | |
| | Service Management | | |
| | | | |
| +--------------------+ | |
+------------------------+ |
| NetConf/RestConf |
| Network
+-----------------v--------------+ Level
| +------------------------+ | |
| | Network Resource | | |
| | | | |
| +------------------------+ | |
| Network | |
| Management/Controller -------------------------
| +-----------------+ | |
| |protocol-specific| | |
| | configuration | | |
| +-----------------+ | |
+-----------------^--------------+ Device
| Level
+-----------------+--------------------+ |
CLI/I2RS | | CLI/I2RS |
| | |
| | |
+---------------+ +---------------+ |
| | | | |
| NE | ... | NE | |
| | | | |
+---------------+ +---------------+----------
Figure 1: SUPA configuration and policy mapping overview
Pentikousis & Zhang Expires November 12, 2015 [Page 4]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
Service Management manages and programs the underlying network
elements indirectly based on the abstract view of the network
infrastructure. In practice, this means that Service Management can,
among others, configure the underlying network as a whole rather than
as a set of individual network elements. As a result, the diversity
of the actual network elements in active operation is abstracted,
which allows Service Management to manage and program the network in
a simpler, more maintainable and efficient manner. On the other end
of the spectrum, the NEs can continue their regular operation without
having to become cognizant of the fact that configuration is applied
at the network level.
In order to bridge the gap between configuration set by Service
Management and that required by the NEs, the Network Management and
Network Manager/Controller has to provide a mapping mechanism which
translates the configuration settings with high level of abstractions
to device-level configurations. This document considers three
modules in the SUPA framework to support such a mapping mechanism, as
follows.
First, a network resource module maintains the resource of the
infrastructure, such as topology of the network. It provides the
information of the resource, which maybe with high level of
abstraction to Service Management for management, and it also
provides the necessary information of each network element, which
with low level of abstraction, when mapping configuration from the
network-level to device-level. Second, the service management and
policy module, which is responsible for transmitting (send/receive)
and process the network-level configuration. Third, the protocol-
specific configuration produces the output of the mapping mechanism
and is responsible for distributing the device- level configuration
to the corresponding network elements.
In this framework, one would expect the introduction and use of
algorithms/strategies for specific network services which can
automatically generate device-level configuration based on the
Service Management policies/configurations. Note, however, that said
algorithms and strategies are out of the scope of this document.
4.2. Mapping Procedure
From the view point of Service Management:
Firstly, the operators or network administrators use a policy editor
GUI to generates a set of policies based on application requirements,
and sends these policies to the service management. It should be
noted that, the policies here maybe generated with different views,
such as business view and system view, for different users, however,
Pentikousis & Zhang Expires November 12, 2015 [Page 5]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
these polices and the interfaces between the application and the
Service Management are out of the scope of SUPA.
Secondly, in the Service Management, based on the generic policy
information model the policies generated in the previous step are
translated into the policy data models defined in SUPA. And then,
policy conflict analysis may be processed to verify the new policy
won't conflict the predefined policies.
Thirdly, if the new policy is valid, Service Management begin to
enforce this policy, in this step, it needs some context of the
underlying network if necessary, especially the infrastructure
(physical or logical) of the network, before it deploys a policy/
service to the network. For example, if Service Management attempts
to steer traffic from one path to another, it should have the
information of the existing paths first. Service Management requests
this context information from the network resource block of Network
Manager/Controller. This procedure does not have to be processed
every time Service Management deploys a policy/service.
Fourthly, service Management can obtain the current status of the
service, which will be affected by the new policy, for reference
before it deploys a new policy. In such a case, Service Management
sends a "GET" request to the Network Manager/Controller, and the
Network Manager/Controller encapsulates this information with the
models specified by SUPA network service models.
Thirdly, Based on the service and policy configuration, and also
service/network status if necessary, Service Management deploys the
action of the policy by sending a "POST" request to the Network
Manager/Controller.
From the view point of Network Manager/Controller:
Firstly, the Network Manager/Controller is responsible for
maintaining the infrastructure information, and it provides
information to Service Managements with the network resource models,
such as topology information model.
Secondly, once the Network Manager/Controller receives actions of a
policy from Service Managements, it maps these actions to protocol-
specific models. The intelligence/algorithms of how to do the
mapping is implementation-specific and out of the scope of this
specification, as are the protocol-specific models.
Thirdly, with the protocol-specific models, the device-level
configurations for heterogeneous devices can be generated and
conveyed by the Network Manager/Controller using, for example,
Pentikousis & Zhang Expires November 12, 2015 [Page 6]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
[RFC6020], [I-D.bierman-netconf-restconf],
[I-D.atlas-i2rs-architecture] and CLI, to the corresponding NEs.
4.3. SUPA Mapping Example
+-----------------------+
| +---------+ |
| |TE Policy| |
| +---------+ |
| Service Management |
+----------^------------+
|
| NETCONF/RESTCONF
|
+--------------v---------------+
| |
| Network Manager/Controller |
| |
+--------------^---- ----------+
| CLI/I2RS/NETCONF
|
+----------------v--------------------+
| |
192.0.2.1 192.0.2.2
+------+ +------+ +------+
| A +----------+ C +------------+ B +-----+
+-+--+-+ +------+ +---+--+ |
| | 192.0.2.3 | |
++ | | |
| | | +---+--+
| | | | G |
+---+--+| | +---+--+
| F || | |
+------+| +--+---+ +---+--+ |
+-------+ D +-----------------+ E +-----+
+------+ +------+
192.0.2.4 192.0.2.5
Figure 2: Bandwidth use optimization for DC Interconnection
Figure 2 illustrates a simple example in which interoperability
between Service Management and Network Manager/Controller in an
inter-data center (inter-DC) environment is considered.
For the purposes of this example, let us focus on the dynamic
configuration of the IP path between the seven illustrated DCs,
Pentikousis & Zhang Expires November 12, 2015 [Page 7]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
labeled A, B, C, D, E, F and G, based on the policies. First of all,
we would like the IP path to be created based on certain constraints.
Secondly, we would like to map it to the device-level connections.
In this scenario, there are two paths from DC A to DC B. Typical IP
shortest-path routing would choose path A(192.0.2.1)-C(192.0.2.3) >
B(192.0.2.2). However, under certain conditions, such as, for
instance, when the bandwidth utiliaztion between A and B is beyond 80
percents, the Service Management can decide that is better to steer
traffic from path (A, C, B) to a new path which goes through a
specific node. This is a policy from business view, and it can be
expressed by the ECA policy data model defined in
[I-D.bi-supa-policy-model] but in this example, how this policy
translated into the ECA policy is not provided, because it is too
dependant on the implementation.
Figure 2 depicts the layer 3 topology of the underlying network.
First, Service Management needs some information about A, B, C, D and
the links between them. This information can be obtained from
Network Manager/Controller, and it is listed in the fragment below.
This information is derived from the Topology YANG model described in
[I-D.contreras-supa-yang-network-topo].
<topologies>
<topology>
<topoId>1111111100000000</topoId>
<topoName>mapping_topo</topoName>
<layer>ip</layer>
</topology>
<nodes>
<node>
<nodeID>192.0.2.1</nodeID>
<nodeName>A</nodeName>
<nodeType>physical</nodeType>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<parentTopoID>1111111100000000</parentTopoID>
</node>
<node>
<nodeID>192.0.2.2</nodeID>
<nodeName>B</nodeName>
<nodeType>physical</nodeType>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<parentTopoID>1111111100000000</parentTopoID>
</node>
Pentikousis & Zhang Expires November 12, 2015 [Page 8]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
... skip ...
<node>
<nodeID>192.0.2.3</nodeID>
<nodeName>C</nodeName>
<nodeType>physical</nodeType>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<parentTopoID>1111111100000000</parentTopoID>
</node>
</nodes>
<links>
<link>
<linkId>1</linkId>
<linkName>A2C</linkName>
<linkType>telink</linkType>
<direction>bidrectional</direction>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<sourceNodeId>192.0.2.1</sourceNodeId>
<destinationNodeId>192.0.2.3</destinationNodeId>
<parentTopoID>1111111100000000<parentTopoID>
<linkTeAttrCfg>
<maxReservableBandwidth>2000</maxReservableBandwidth>
</linkTeAttrCfg>
</link>
... skip ...
<link>
<linkId>2</linkId>
<linkName>C2B</linkName>
<linkType>telink</linkType>
<direction>bidrectional</direction>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<sourceNodeId>192.0.2.3</sourceNodeId>
<destinationNodeId>192.0.2.2</destinationNodeId>
<parentTopoID>1111111100000000<parentTopoID>
<linkTeAttrCfg>
<maxReservableBandwidth>50000</maxReservableBandwidth>
</linkTeAttrCfg>
</link>
</links>
</topologies>
Figure 3: Information of the underlying network
Pentikousis & Zhang Expires November 12, 2015 [Page 9]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
Secondly, Service Management defines the policy using policy policy
models defined in SUPA, and then sends the steering information
derived from service and policy information to Network Manager/
Controller using a protocol such as [RFC6020], and
[I-D.bierman-netconf-restconf]. Figure 4 presents the policy for
traffic steering: the traffic (supaflow) with destination IP address
192.0.2.11/24 needs to be steered to DC B, the new path must go
through DC D. This configuration is derived from the YANG model
described in [I-D.bi-supa-policy-model]. An example of the steering
information is list in Figure 5, it specfies the traffic flow which
will be steered, and the constrains of the new path.
Pentikousis & Zhang Expires November 12, 2015 [Page 10]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
<supa-ddc-policy>
<adjust-flow-path-policy>
<adjust-flow-path>
<vpn-name>supa_vpn</vpn-name>
<vpn-type>L3VPN</vpn-type>
<flow-name>supa_flow</flow-name>
<traffic-steering-policy-rule>
<policy-rule-deploy-status>
4
</policy-rule-deploy-status>
<policy-rule-exec-status>
3
</policy-rule-exec-status>
<policy-event>
<bandwidth>
bandwidth
</bandwidth>
</policy-event>
<policy-condition>
<bandwidth-utilization>
utilization
</bandwidth-utilization>
<operator>
above
</operator>
<value>
80
</value>
</policy-condition>
<policy-action-adjust-path>
<constraint-nodes>
<constraint-node>
<nodeId>192.0.2.4</nodeId>
<constraint-type>
pass
</constraint-type>
</constraint-node>
</constraint-nodes>
</policy-action-adjust-path>
</traffic-steering-policy-rule>
</adjust-flow-path>
</adjust-flow-path-policy>
</supa-ddc-policy>
Figure 4: Example traffic steering policy
Pentikousis & Zhang Expires November 12, 2015 [Page 11]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
<ipteFlow>
<ipteFlowName>supa_flow</ipteFlowName>
<bandwidth>10000</bandwidth>
<pathPrefixs>
<pathPrefix>
<prefix>192.0.2.0</prefix>
<maskLength>24</maskLength>
</pathPrefix>
</pathPrefixs>
<paths>
<path>
<pathName>path_1</pathName >
<pathType>auto</pathType >
<pathNodes>
<pathNode>
<nodeId>192.0.2.1</nodeId>
<nodeRole>ingress</nodeRole>
<sequence>1</sequence>
</pathNode>
<pathNode>
<nodeId>192.0.2.5</nodeId>
<nodeRole> transit </nodeRole>
<sequence>2</sequence>
</pathNode>
<pathNode>
<nodeId>192.0.2.2</nodeId>
<nodeRole> egress </nodeRole>
<sequence>3</sequence>
</pathNode>
</pathNodes>
</path>
</paths>
</ipteFlow>
Figure 5: Example traffic steering information
Based on the steering information, the Network Manager/Controller
generates a path which meets the requirements: in this example, the
computed path is (A, D, E, B). Network Manager/Controller also has
to configure each device on the new path, not only the devices
specified by the configuration such as node D, but also the devices
in the underlying network which must be reconfigured, such as node E.
The topology information is also necessary when Network Manager/
Controller decides which device ought to be configured.
With the assistance of other information in Network Manager/
Controller, such as topology information, service/policy
Pentikousis & Zhang Expires November 12, 2015 [Page 12]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
configuration can be translated into protocol-specific yang models
(or southbound interface) first. Taking node D as an example, the
configuration expressed in the YANG model defined in
[I-D.lhotka-netmod-routing-cfg]could be as follows:
<rt:routing>
<rt:routing-instance>
<rt:name>rtr0</rt:name>
<rt:description>Router D</rt:description>
<rt:routing-protocols>
<rt:routing-protocol>
<rt:type>rt:static</rt:type>
<rt:name>st0</rt:name>
<rt:description>
Static routing is used for the internal network.
</rt:description>
<rt:static-routes>
<v4ur:ipv4>
<v4ur:route>
<v4ur:destination-prefix>
192.0.2.0/24
</v4ur:destination-prefix>
<v4ur:next-hop>
<v4ur:next-hop-address>
192.0.2.5
</v4ur:next-hop-address>
</v4ur:next-hop>
</v4ur:route>
</v4ur:ipv4>
</rt:static-routes>
</rt:routing-protocol>
</rt:routing-protocols>
</rt:routing-instance>
</rt:routing>
Figure 6: Example traffic steering requirements
The configuration of other nodes is similar. Based on this vendor-
neutral device-level configuration and the features of each NE, the
NE-specific configuration can be generated. Once nodes A, C, D and E
have received their respective NE-specific configurations, the
device-level configuration could be deployed and then, the traffic is
steered as Service Management specified.
Pentikousis & Zhang Expires November 12, 2015 [Page 13]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
5. Security Considerations
Security considerations will be discussed in an upcoming revision of
this document.
6. IANA Considerations
TBD
7. Acknowledgements
This document has benefited comments, suggestions, and proposed text
provided by Cathy Zhou and Will Liu (listed in alphabetical order).
Junru Lin and Zhayiyong contributed to an earlier version of this
draft.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
8.2. informative References
[I-D.atlas-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-atlas-i2rs-architecture-02 (work in
progress), August 2013.
[I-D.bi-supa-policy-model]
Bi, J., Tadepalli, R., and M. Hayashi, "DDC Service Policy
YANG Data Model", draft-bi-supa-policy-model-01 (work in
progress), March 2015.
[I-D.bierman-netconf-restconf]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-bierman-netconf-restconf-04
(work in progress), February 2014.
Pentikousis & Zhang Expires November 12, 2015 [Page 14]
Internet-Draft SUPA Configuration and Policy Mapping May 2015
[I-D.contreras-supa-yang-network-topo]
Contreras, L., Qu, A., and Y. Zha, "A YANG Data Model for
Network Topologies", draft-contreras-supa-yang-network-
topo-02 (work in progress), January 2015.
[I-D.lhotka-netmod-routing-cfg]
Lhotka, L., "A YANG Data Model for Routing Configuration",
draft-lhotka-netmod-routing-cfg-00 (work in progress),
March 2011.
[I-D.strassner-supa-generic-policy-info-model]
Strassner, J., "Generic Policy Model for Simplified Use of
Policy Abstractions (SUPA)", draft-strassner-supa-generic-
policy-info-model-00 (work in progress), April 2015.
[I-D.zhou-supa-framework]
Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The
Framework of Shared Unified Policy Automation (SUPA)",
draft-zhou-supa-framework-00 (work in progress), January
2015.
Authors' Addresses
Kostas Pentikousis
EICT GmbH
Torgauer Strasse 12-15
Berlin 10829
Germany
Email: k.pentikousis@eict.de
Dacheng Zhang
Chaoyang Dist
Beijing 100000
P.R. China
Email: Dacheng.zhang@gmail.com
Pentikousis & Zhang Expires November 12, 2015 [Page 15]
