One document matched: draft-pentikousis-supa-mapping-03.txt
Differences from draft-pentikousis-supa-mapping-02.txt
Network Working Group K. Pentikousis
Internet-Draft EICT GmbH
Intended status: Informational D. Zhang
Expires: August 10, 2015 Alibaba
February 6, 2015
Shared Unified Policy Automation (SUPA): Configuration and Policy
Mapping
draft-pentikousis-supa-mapping-03
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 Shared Unified Policy
Automation (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 August 10, 2015.
Pentikousis & Zhang Expires August 10, 2015 [Page 1]
Internet-Draft SUPA Configuration and Policy Mapping February 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 . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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.
Shared Unified Policy Automation (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 various applications needs, from the
Pentikousis & Zhang Expires August 10, 2015 [Page 2]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
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: Shared Unified Policy Automation
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 August 10, 2015 [Page 3]
Internet-Draft SUPA Configuration and Policy Mapping February 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 August 10, 2015 [Page 4]
Internet-Draft SUPA Configuration and Policy Mapping February 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, provides this
information 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.
Figure 1 only illustrates the modules in the entity which is
responsible for generating the data of them, actually, the modules,
such as policy module, service managemetn module and network resource
module, exist both in Network Management and Network Manager/
Controller.
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.
Pentikousis & Zhang Expires August 10, 2015 [Page 5]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
Secondly, Service Management can obtain the current status of a
policy/service for reference before it deploys a new one. In such
cases, 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 or policy models.
Thirdly, Service Management deploys a policy/service by sending a
"POST" request to the Network Manager/Controller with the policy/
service information formatted with SUPA models.
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 policy/service
models from Service Managements, it maps these models 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 August 10, 2015 [Page 6]
Internet-Draft SUPA Configuration and Policy Mapping February 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.5 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 August 10, 2015 [Page 7]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
B(192.0.2.2). However, under certain conditions, such as, for
instance, when the bandwidth between A and B is not suitable, 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>
</node>
Pentikousis & Zhang Expires August 10, 2015 [Page 8]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
</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 sends the steering information to
Network Manager/Controller using a protocol such as [RFC6020], and
[I-D.bierman-netconf-restconf]. Figure 4 presents the requirements
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.zaalouk-supa-vpn-service-management-model].
Pentikousis & Zhang Expires August 10, 2015 [Page 9]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
<specifyFlowPaths>
<vpnName>supa_vpn</vpnName>
<vpnType>L3VPN</vpnType>
<flowName>supa_flow</flowName>
<node>192.0.2.5</node>
</specifyFlowPaths>
Figure 4: Example traffic steering requirements
Based on this configuration, 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
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:
Pentikousis & Zhang Expires August 10, 2015 [Page 10]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
<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.11/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 5: 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.
5. Security Considerations
Security considerations will be discussed in an upcoming revision of
this document.
Pentikousis & Zhang Expires August 10, 2015 [Page 11]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
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.bierman-netconf-restconf]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-bierman-netconf-restconf-04
(work in progress), February 2014.
[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.
Pentikousis & Zhang Expires August 10, 2015 [Page 12]
Internet-Draft SUPA Configuration and Policy Mapping February 2015
[I-D.zaalouk-supa-vpn-service-management-model]
Zhang, D., Zaalouk, A., Pentikousis, K., and Y. Cheng,
"VPN Service Management YANG Data Model", draft-zaalouk-
supa-vpn-service-management-model-00 (work in progress),
February 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
Alibaba
Chaoyang Dist
Beijing 100000
P.R. China
Email: Dacheng.zdc@alibaba-inc.com
Pentikousis & Zhang Expires August 10, 2015 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:12:48 |