Shared Unified Policy Automation (SUPA): Configuration and Policy Mapping
draft-pentikousis-supa-mapping-02
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 "Expired".
|
|
|---|---|---|---|
| Authors | Kostas Pentikousis , Dacheng Zhang | ||
| Last updated | 2015-01-30 | ||
| 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-pentikousis-supa-mapping-02
Internet Working Group K. Pentikousis, Ed.
Internet Draft EICT
Intended status: Informational D. Zhang
Expires: August 3, 2015 Alibaba
January 30, 2015
Shared Unified Policy Automation (SUPA):
Configuration and Policy Mapping
draft-pentikousis-supa-mapping-02
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 to IETF 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 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."
Pentikousis, et al. Expires August 3, 2015 [Page 1]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 30, 2014.
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. Terminology .............................................. 3
3. Configuration and Policy Mapping.......................... 4
3.1. Overview .............................................. 4
3.2. Mapping Procedure...................................... 5
3.3. SUPA Mapping Example................................... 6
4. Security Considerations.................................. 11
5. IANA Considerations...................................... 11
6. References .............................................. 11
6.1. Normative References.................................. 11
6.2. Informative References................................ 11
7. Acknowledgments ......................................... 12
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
Pentikousis, et al. Expires August 3, 2015 [Page 2]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
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
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 Management Agent (MA) blocks. MAs represent one or more
entities that are able to control the operation and management of a
network infrastructure and mediate between the Operation and
Management Application (OAMA) and the network elements to provide,
maintain and deploy network services and policies. Each MA 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 MA 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. Terminology
This document uses the following terms:
Management Agent (MA): represents one or more entities that are able
to control the operation and management of a network infrastructure.
Network element (NE): a physical or virtual entity that can be
locally managed and operated.
Operation and Management Application (OAMA): represents one or more
network entities that are running and controlling network services.
SUPA: Shared Unified Policy Automation.
Pentikousis, et al. Expires August 3, 2015 [Page 3]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. 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 operation and management applications (OAMAs).
3.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) OAMA, ii) MA and iii) NEs.
+---------------+ -------------------------
| | |
| OAMA | |
| | |
+-------+-------+ |
| NetConf/RestConf |
| Network
+-----------------v--------------+ Level
| +------------+ +-------------+| |
| | Topology | | Service/ || |
| +------------+ | Policy || |
| +-------------+| |
| | |
| MA -------------------------
| +-----------------+ | |
| |protocol-specific| | |
| | configuration | | |
| +-----------------+ | |
+-----------------^--------------+ Device
| Level
+-----------------+--------------------+ |
CLI/I2RS | | CLI/I2RS |
| | |
| | |
+---------------+ +---------------+ |
| | | | |
| NE | ... | NE | |
| | | | |
+---------------+ +---------------+----------
Pentikousis, et al. Expires August 3, 2015 [Page 4]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
Figure 1: SUPA configuration and policy mapping overview
OAMA manages and programs the underlying network elements indirectly
based on the abstract view of the network infrastructure. In
practice, this means that OAMA 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 OAMA 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 OAMA and that
required by the NEs, the MA 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 MA to
support such a mapping mechanism, as follows.
First, a topology module maintains the topology of the network
infrastructure and provides topology information in the specific
network layer as the network service expects. It also provides the
necessary information of each network element when mapping
configuration from the network-level to device-level. Second, the
service/policy configuration module receives the network-level
configuration and acts as the primary input of the mapping mechanism.
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 OAMA
policies/configurations. Note, however, that said algorithms and
strategies are out of the scope of this document.
3.2. Mapping Procedure
From the view point of OAMA:
Firstly, OAMA 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
OAMA attempts to steer traffic from one path to another, it should
have the information of the existing paths first. OAMA requests this
context information from MA, and the information is provided with the
Pentikousis, et al. Expires August 3, 2015 [Page 5]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
topology model. This procedure does not have to be processed every
time OAMA deploys a policy/service.
Secondly, OAMA can obtain the current status of a policy/service for
reference before it deploys a new one. In such cases, OAMA sends a
"GET" request to the MA, and the MA encapsulates this information
with the models specified by SUPA network service models or policy
models.
Thirdly, OAMA deploys a policy/service by sending a "POST" request to
the MA with the policy/service information formatted with SUPA
models.
From the view point of MA:
Firstly, the MA is responsible for maintaining the infrastructure
information, and it provides information to OAMAs with the topology
information model.
Secondly, once the MA receives policy/service models from OAMAs, 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 MA using, for example, [RFC6020], [RESTCONF],
[I-D.ietf-i2rs-architecture] and CLI, to the corresponding NEs.
3.3. SUPA Mapping Example
Figure 2 illustrates a simple example in which interoperability
between OAMA and MA 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(1.1.1.1)-C(3.3.3.3) >
B(2.2.2.2). However, under certain conditions, such as, for instance,
when the bandwidth between A and B is not suitable, the OAMA can
Pentikousis, et al. Expires August 3, 2015 [Page 6]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
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.
+-----------------------+
| +------+ |
| |Policy| |
| +------+ |
| OAMA |
+----------^------------+
|
| NETCONF/RESTCONF
|
+--------------v---------------+
| |
| M A |
| |
+--------------^---- ----------+
| CLI/I2RS/NETCONF
|
+----------------v--------------------+
| |
1.1.1.1 2.2.2.2
+------+ +------+ +------+
| A +----------+ C +------------+ B +-----+
+-+--+-+ +------+ +---+--+ |
| | 3.3.3.3 | |
++ | | |
| | | +---+--+
| | | | G |
+---+--+| | +---+--+
| F || | |
+------+| +--+---+ +---+--+ |
+-------+ D +-----------------+ E +-----+
+------+ +------+
4.4.4.4 5.5.5.5
Figure 2: Bandwidth use optimization for DC Interconnection
Pentikousis, et al. Expires August 3, 2015 [Page 7]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
First, OAMA needs some information about A, B, C, D and the links
between them. This information can be obtained from MA, and it is
listed in the fragment below. This information is derived from the
Topology YANG model described in [draft-contreras-supa-yang-network-
topo-02].
<topologies>
<topology>
<topoId>1111111100000000</topoId>
<topoName>mapping_topo</topoName>
<layer>ip</layer>
</topology>
<nodes>
<node>
<nodeID>1.1.1.1</nodeID>
<nodeName>A</nodeName>
<nodeType>physical</nodeType>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<parentTopoID>1111111100000000</parentTopoID>
</node>
<node>
<nodeID>2.2.2.2</nodeID>
<nodeName>B</nodeName>
<nodeType>physical</nodeType>
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<parentTopoID>1111111100000000</parentTopoID>
</node>
... skip ...
<node>
<nodeID>3.3.3.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>
Pentikousis, et al. Expires August 3, 2015 [Page 8]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
<adminStatus>adminUp</adminStatus>
<operStatus>up</operStatus>
<sourceNodeId>1.1.1.1</sourceNodeId>
<destinationNodeId>3.3.3.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>3.3.3.3</sourceNodeId>
<destinationNodeId>2.2.2.2</destinationNodeId>
<parentTopoID>1111111100000000<parentTopoID>
<linkTeAttrCfg>
<maxReservableBandwidth>50000</maxReservableBandwidth>
</linkTeAttrCfg>
</link>
</links>
</topologies>
Secondly, OAMA sends the steering information to MA using a protocol
such as NETCONF or RESTCONF. Figure 3 presents the requirements for
traffic steering: the traffic (supaflow) with destination IP address
11.11.11.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-configuration-model].
Pentikousis, et al. Expires August 3, 2015 [Page 9]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
<specifyFlowPaths>
<vpnName>supa_vpn</vpnName>
<vpnType>L3VPN</vpnType>
<flowName>supa_flow</flowName>
<node>4.4.4.4</node>
</specifyFlowPaths>
Figure 3: Example traffic steering requirements
Based on this configuration, the MA generates a path which meets the
requirements: in this example, the computed path is (A, D, E, B). MA
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 MA decides
which device ought to be configured.
With the assistance of other information in MA, 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.ietf-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>
11.11.11.11/24
</v4ur:destination-prefix>
<v4ur:next-hop>
<v4ur:next-hop-address>
5.5.5.5
</v4ur:next-hop-address>
</v4ur:next-hop>
</v4ur:route>
</v4ur:ipv4>
Pentikousis, et al. Expires August 3, 2015 [Page 10]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
</rt:static-routes>
</rt:routing-protocol>
</rt:routing-protocols>
</rt:routing-instance>
</rt:routing>
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 OAMA specified.
4. Security Considerations
Security considerations will be discussed in an upcoming revision of
this document.
5. IANA Considerations
TBD
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.zaalouk-supa-configuration-model] Zaalouk, A., Pentikousis, K.,
and W. Liu, "A YANG Data Model for Configuration of Shared Unified
Policy Automation (SUPA)", draft-zaalouk-supa-configuration-model
(work in progress), October 2014.
[I-D. contreras-supa-yang-network-topo] Contreras, L. and Andrew Qu,
"A YANG Data Model for Network Topologies", draft-contreras-supa-
yang-network-topo-02 (work in progress), January 2015.
Pentikousis, et al. Expires August 3, 2015 [Page 11]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
[I-D.zhou-supa-framework] C. Zhou, L. M. Contreras, Q. Sun, and Q.
Sun "The Framework of Shared Unified Policy Automation (SUPA)",
draft-zhou-supa-architecture-00, (work in progress), January 2015.
[I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward,
D., and T. Nadeau, "An Architecture for the Interface to the
RoutingSystem", draft-ietf-i2rs-architecture-08 (work in progress),
January 2015.
[I-D.ietf-netmod-routing-cfg] Lhotka, L., "A YANG Data Model for
Routing Management", draft-ietf-netmod-routing-cfg-16 (work in
progress), October 2014.
[RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-ietf-netconf-restconf-03 (work in
progress), October 2014.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
7. Acknowledgments
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.
Pentikousis, et al. Expires August 3, 2015 [Page 12]
Internet-Draft SUPA Configuration and Policy Mapping January 2015
Authors' Addresses
Kostas Pentikousis (editor)
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, et al. Expires August 3, 2015 [Page 13]