Internet Working Group K. Pentikousis, Ed.
Internet Draft EICT
Intended status: Informational Junru Lin
Expires: March 27, 2015 Yiyong Zha
Huawei Technologies
September 23, 2014
SUPA Configuration and Policy Mapping
draft-pentikousis-supa-mapping-00
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
devices. This document describes guidelines for mapping configuration
and policy into device-level configuration. The SUPA framework
overview and primary procedures of mapping are proposed. Moreover, an
exemplary mapping scenario is provided to illustrate the mechanism
involved.
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."
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 March 27, 2014.
Pentikousis, et al. Expires March 27, 2015 [Page 1]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
Copyright Notice
Copyright (c) 2014 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.......................... 3
3.1. Overview .............................................. 4
3.2. Mapping Procedure...................................... 5
3.3. SUPA Mapping Example................................... 6
4. Security Considerations.................................. 10
5. IANA Considerations...................................... 10
6. References .............................................. 10
6.1. Normative References.................................. 10
6.2. Informative References................................ 11
7. Acknowledgements ........................................ 11
1. Introduction
As the underlying network infrastructure grows, and new services and
traffic are rapidly increased, it becomes significantly more
challenging than in the past to maintain the network and deploy new
services. Configuration automation can provide significant benefits
in deployment agility. Shared Unified Policy Automation (SUPA)
[draft-zhou-supa-architecture-00] attempts to achieve this
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 model of various application services and
functions allow the network operators to manipulate the network
infrastructure as a whole rather than individual devices. Well-
designed abstractions are able to provide a wide range of granularity
Pentikousis, et al. Expires March 27, 2015 [Page 2]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
for various applications needs, from the lower-level physical network
to high-level application 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 the Application-Based Policy Decision (ABPD) block, an
entity used between the network services and the network elements to
provide and maintain the application-based policies. ABPD 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 ABPD to help ABPD to map the
classified application based models, which include the classified
application based policies, into specific network management
policies, i.e., device-level configuration models, which are used
by the communication network.
2. Terminology
This document uses the following terms:
Network element: a physical or virtual entity that can be locally
managed and operated.
Network service system (NSS): enhanced Operational Support System
(OSS) which runs services that enable a provider to monitor, control,
analyze and manage the services in a communication network.
SUPA: Shared Unified Policy Automation
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 network service systems.
Pentikousis, et al. Expires March 27, 2015 [Page 3]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
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) network service systems, ii) a network
management & control system and iii) network elements.
+-------------------------+ +-------------------------+ ---
| +-----------------+ | | +-----------------+ | |
| | Network Service | | | | Network Service | | |
| +-----------------+ | | +-----------------+ | |
| | Network Level | ... | | | Network Level | ... | |
| | Configuration | | | | Configuration | | |
| +-----------------+ | ... | +-----------------+ | |
| | | | |
| | | | |
| Network Service | | Network Service | |
| System | | System | |
+----------^--------------+ +----------^--------------+ |
| | Network
+-----------------+-----------------+ Level
| NETCONF/RESTCONF |
+--------------v-----------------+ |
| +--------------+| |
| +------------+ | || |
| | Topology | |Policy/ || |
| +------------+ |Configuration || |
| +--------------+| |
Network management & +-----------------+ | |
control systems | | Mapping | +-------------------
| +-----------------+ | |
| +---------------------------+ | |
| | Device-level Configuration| | |
| +---------------------------+ | |
+-------------------^------------+ Device
| Level
+-------------------+-----------------+ |
CLI/I2RS/ | CLI/I2RS/ | |
NETCONF/RESTCONF| NETCONF/RESTCONF | |
| | |
+-------------v---------------+ +------------v---------+ |
| | | | |
| | ... | | |
| Network Element | | Network Element | |
+-----------------------------+ +----------------------+----
Figure 1: SUPA configuration and policy mapping overview
Pentikousis, et al. Expires March 27, 2015 [Page 4]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
A network service system (NSS) manages and programs the underlying
network elements indirectly based on the abstract view of the network
infrastructure. In practice, this means that the network service
systems 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 the NSS to manage and program
the network in a simpler, more maintainable and efficient way. On the
other end of the spectrum, the network elements can continue 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 from the network
service systems and network elements, the network management and
control system has to provide a mapping mechanism which translates
the configuration settings from network level to the device level.
This document considers three modules in the network management and
control system 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
application/policy configuration module receives the network-level
configuration and acts as the primary input of the mapping mechanism.
Third, the device 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 NSS
policies/configurations. Note, however, that said
algorithms/strategies are out of the scope of this document.
3.2. Mapping Procedure
Firstly, the network service system acquires the topology information
from the topology module in the network management & control system
if it needs some knowledge of the underlying network to specify
policies/configurations. Then, the network service system posts the
policies/configurations to the network management & control system.
Secondly, in the network management & control system,
algorithms/strategies for specific network services generate a series
Pentikousis, et al. Expires March 27, 2015 [Page 5]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
of detailed configurations from the network level
policy/configuration, and decide which network element the
configurations need to be deployed based on the topology module. From
the topology module, the interfaces supported by a specific network
element, e.g. [RFC6020], [RESTCONF], [I-D.ietf-i2rs-architecture] or
CLI (Command Line Interface), can be confirmed. Then, the device
configuration module distributes the detailed configuration to the
corresponding network elements, according to the mechanisms that the
network elements interfaces support. Finally, the network elements
receive and use the device-level configurations.
3.3. SUPA Mapping Example
Figure 2 illustrates a simple example in which interoperability
between SUPA and IP traffic engineering (IPTE) 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, ..., 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)->B(2.2.2.2). However, under
certain conditions, such as, for instance, when the bandwidth between
A and B is not suitable, the NSS can decide that is better to steer
traffic from path (A, B) to path (A, C, B).
Figure 2 depicts the layer 3 topology of the underlying network. The
network service system attempts to steer traffic from path (A, B) to
path (A, ..., C, ..., B). At first, NSS needs some information about
A, B and C to determine the new path in the configuration. This
information can be obtained from the topology information model.
Topology for a network-level configuration loses some device-level
details for the sake of conciseness; it also can be represented as a
different network layer as the application expects. Secondly, the
network service system sends the information to the network
management and control system using a protocol such as NETCONF or
RESTCONF.
+-----------------------+
| +-----------------+ |
| | IPTE Service | |
| +-----------------+ |
| | IPTE | |
| | Configuration | |
Pentikousis, et al. Expires March 27, 2015 [Page 6]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
| +-----------------+ |
| NSS |
+----------^------------+
|
| NETCONF/RESTCONF
|
+--------------v---------------+
| |
| |
| Network management |
| control systems |
| |
| |
| |
+--------------^---- ----------+
| CLI/I2RS
|
+----------------v--------------------+
| |
1.1.1.1 2.2.2.2
+------+ +------+
| A +------------------------------+ B +-----+
+-+--+-+ +---.--+ |
| | | |
++ | | |
| +---+ | +---+--+
| | | | G |
+---+--+ | | +---+--+
| F | | | |
+------+ | +------+ +---+--+ |
| +----+ C +-------+ E +-----+
| | +------+ +------+
| | 3.3.3.3 5.5.5.5
+--+---+ |
| D +----+
+------+
4.4.4.4
Figure 2: Bandwidth usage optimization for DC Interconnection
Figure 3 presents the requirements for traffic steering: the traffic
needs to be steered to DC B whose IP address is 2.2.2.2/24, the new
path must start at DC A, terminate at DC B and go through DC C, and
the available bandwidth of the new path must more than 10 Mb/s. This
configuration is derived from the IP TE YANG model described in
[draft-xxx-supa-configuration-model-00].
Pentikousis, et al. Expires March 27, 2015 [Page 7]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
<ipteFlow>
<ipteFlowName>ddc_flow</ipteFlowName>
<bandwidth>10000</bandwidth>
<pathPrefixs>
<pathPrefix >
<prefix>2.2.2.2</prefix>
<maskLength>32</maskLength>
</pathPrefix>
</pathPrefixs>
<paths>
<path>
<pathName>path_1</pathName >
<pathType>auto</pathType >
<pathNodes>
<pathNode>
<nodeId>1.1.1.1</nodeId>
<nodeRole>ingress</nodeRole>
<sequence>1</sequence>
</pathNode>
<pathNode>
<nodeId>3.3.3.3</nodeId>
<nodeRole> transit </nodeRole>
<sequence>2</sequence>
</pathNode>
<pathNode>
<nodeId>2.2.2.2</nodeId>
<nodeRole> egress </nodeRole>
<sequence>3</sequence>
</pathNode>
</pathNodes>
</path >
</paths>
</ipteFlow>
Figure 3: Example traffic steering requirements
Based on this configuration, the network management and control
system has to configure each device on the new path-path2, not only
the devices specified by the configuration such as, B, C, but also
the devices in the underlying network which must be reconfigured,
such as in D and E. The topology information is also necessary to
decide which device ought to be configured.
In this example, the network-level configuration cannot be deployed
in the devices directly, it needs to be mapped or translated to
device-level configuration. For example, in this scenario, the
networking device (ingress/egress router) of node A, B, C, D, and E
Pentikousis, et al. Expires March 27, 2015 [Page 8]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
support configuration with ACL using CLI. In this instance the
configuration of each node is:
node A: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node D:
{
system view
acl number 2002
rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
quite
route policy ddc-example permit node 10
if-match acl 2002
apply ip-address next-hop 4.4.4.4
quit
}
Node D: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node C:
{
system view
acl number 2002
rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
quite
route policy ddc-example permit node 10
if-match acl 2002
apply ip-address next-hop 3.3.3.3
quit
}
Node C: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node E:
{
system view
acl number 2002
rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
quite
route policy ddc-example permit node 10
if-match acl 2002
apply ip-address next-hop 5.5.5.5
quit
}
Node E: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node B:
Pentikousis, et al. Expires March 27, 2015 [Page 9]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
{
system view
acl number 2002
rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
quite
route policy ddc-example permit node 10
if-match acl 2002
apply ip-address next-hop 2.2.2.2
quit
}
If the nodes support an I2RS interface, then an I2RS client [I-
D.ietf-i2rs-architecture] is introduced in the "Device Configuration"
module. This module will communicate with a number of routers using
an asynchronous protocol, sets or collects state to/from those
routers. When configuring node A, B, C, D and E, the network
management & control system only needs to send the configurations to
the I2RS client. The configuration of node A and node C set rules to
steer traffic, whose source IP is 1.1.1.1 and destination IP is
2.2.2.2/24, to node D and node E respectively. The detailed contents
and format can be found in [I-D.hares-i2rs-info-model-policy].
Once nodes A, B, C, D and E have received their respective
configurations (from the I2RS client or via CLI), the device-level
configuration is deployed and the traffic is steered as the network
service system expects.
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.
Pentikousis, et al. Expires March 27, 2015 [Page 10]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
6.2. Informative References
[draft-zaalouk-supa-configuration-model-00] Adel Zaalouk,
K.Pentikousis, W. Liu, "YANG Data Model for Configuration of Shared
Unified Policy Automation (SUPA)" (work in progress), September 2014.
[draft-zhou-supa-architecture-00] C. Zhou, T.Tsou, D.Lopez,
G.Karagiannis and Q.Sun "The Architecture for Shared Unified Policy
Automation (SUPA)", draft-zhou-supa-architecture-00, (work in
progress), September 2014.
[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-05 (work in progress),
July 2014.
[I-D.hares-i2rs-info-model-policy] Hares, S. and W. Wu, "An
Information Model for Networkpolicy", draft-hares-i2rs-info-model-
policy-03 (work in progress), July 2014.
[RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work in
progress), July 2014.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
7. Acknowledgements
This document has benefited comments, suggestions, and proposed text
provided by Cathy Zhou and Will Liu (listed in alphabetical order).
Pentikousis, et al. Expires March 27, 2015 [Page 11]
Internet-Draft SUPA Configuration and Policy Mapping September 2014
Authors' Addresses
Kostas Pentikousis (editor)
EICT GmbH
Torgauer Strasse 12-15
Berlin 10829
Germany
Email: k.pentikousis@eict.de
Junru Lin
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: linjunru@huawei.com
Yiyong Zha
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: zhayiyong@huawei.com
Pentikousis, et al. Expires March 27, 2015 [Page 12]