Network Working Group K. Pentikousis
Internet-Draft EICT GmbH
Intended status: Informational D. Zhang
Expires: September 10, 2015 Alibaba
March 9, 2015
Simplified Use of Policy Abstractions (SUPA): Configuration and Policy
Mapping
draft-pentikousis-supa-mapping-04
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 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 September 10, 2015.
Pentikousis & Zhang Expires September 10, 2015 [Page 1]
Internet-Draft SUPA Configuration and Policy Mapping March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Mapping Procedure . . . . . . . . . . . . . . . . . . . . 5
4.3. SUPA Mapping Example . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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, the definition of a
standardized model for a network topology graph, which could be used
to describe topologies at any functional layer, and information
models of various network services and network service development
policies 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
Pentikousis & Zhang Expires September 10, 2015 [Page 2]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
various applications needs, from the lower-level physical network to
high-level network services. 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/ControllerY",
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.
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.
Pentikousis & Zhang Expires September 10, 2015 [Page 3]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
+------------------------+ -------------------------
| 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
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
Pentikousis & Zhang Expires September 10, 2015 [Page 4]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
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 Manager/
Controller has to provide a mapping mechanism which translates the
configuration settings from the network level to the device level.
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
infrastracture, such as topology of the network, and provides the
information of the resouce to Service Management. It also provides
the necessary information of each network element when mapping
configuration from the network-level to device-level. Second, the
service management and policy module, which is responsible for
transmitging (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, Service Management needs some context of the underlying
network, 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
Network Manager/Controller, and the information is provided with the
topology model. This procedure does not have to be processed every
time Service Management deploys a policy/service.
Secondly, Service Management can obtain the current status of a
service for reference before it deploys a new policy. In such cases,
Service Management sends a "GET" request to the Network Manager/
Controller, and the Network Manager/Controller encapsulates this
Pentikousis & Zhang Expires September 10, 2015 [Page 5]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
information with the models specified by SUPA network service models
models.
Thirdly, Based on the service and policy configuration, and also
service/network status if neccessary, 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,
[RFC6020], [I-D.bierman-netconf-restconf],
[I-D.atlas-i2rs-architecture] and CLI, to the corresponding NEs.
4.3. SUPA Mapping Example
Pentikousis & Zhang Expires September 10, 2015 [Page 6]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
+-----------------------+
| +---------+ |
| |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,
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) >
Pentikousis & Zhang Expires September 10, 2015 [Page 7]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
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.
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>
... skip ...
<node>
<nodeID>192.0.2.3</nodeID>
<nodeName>C</nodeName>
<nodeType>physical</nodeType>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<parentTopoID>1111111100000000</parentTopoID>
Pentikousis & Zhang Expires September 10, 2015 [Page 8]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
</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
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
Pentikousis & Zhang Expires September 10, 2015 [Page 9]
Internet-Draft SUPA Configuration and Policy Mapping March 2015
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.
<ddc-policy>
<specify-flow-paths>
<specify-flow-path>
<vpn-name>supa_vpn</vpn-name>
<vpn-type>L3VPN</vpn-type>
<flow-name>supa_flow</flow-name>
<traffic-steering-policy>
<bandwidth>
<type>utilization</type>
<value>80</value>
</bandwidth>
<threshold>
<match>above</match>
</threshold>
<adjust-path>
<constraint-nodes>
<constraint-node>
<nodeId>192.0.2.4</nodeId>
<constraint-type>
pass
</constraint-type>
</constraint-node>
</constraint-nodes>
</adjust-path>
</traffic-steering-policy>
</specify-flow-path>
</specify-flow-paths>
</ddc-policy>
Figure 4: Example traffic steering policy
Pentikousis & Zhang Expires September 10, 2015 [Page 10]
Internet-Draft SUPA Configuration and Policy Mapping March 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 September 10, 2015 [Page 11]
Internet-Draft SUPA Configuration and Policy Mapping March 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 September 10, 2015 [Page 12]
Internet-Draft SUPA Configuration and Policy Mapping March 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-00 (work in
progress), February 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 September 10, 2015 [Page 13]
Internet-Draft SUPA Configuration and Policy Mapping March 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.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
Alibaba
Chaoyang Dist
Beijing 100000
P.R. China
Email: Dacheng.zdc@alibaba-inc.com
Pentikousis & Zhang Expires September 10, 2015 [Page 14]