Network Working Group C. Zhou
Internet-Draft Huawei Technologies
L. M. Contreras
Intended status: Informational Telefonica
Expires: July 15, 2015 Q. Sun
China Telecom
P. Yegani
Juniper Networks
January 15, 2015
The Framework of Shared Unified Policy Automation (SUPA)
draft-zhou-supa-framework-00
Abstract
Currently, there are a lot of network services that impose specific
demands on a communication network, which makes it significantly
more challenging to network management and service deployment. SUPA
aims to provide a set of data models and a framework to simply the
deployment and management of network services. This document
describes the SUPA basic framework and its elements. The main SUPA
framework entities are the Operation and Management Application
(OAMA) and the Management Agent (MA). OAMA is a functional entity
that creates and runs network services; MA is a functional entity
which enables the generation, maintenance and release of network
topologies and network service specific abstractions, and maps
network service specific abstractions in combination with network
topology and policy to detail network element configurations.
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 April 27, 2015.
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.
Zhou, et al Expires July 5, 2015 Page 1
Internet-Draft SUPA Architecture January 2015
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.
Requirements Language
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 RFC 2119 [RFC2119].
Table of Content
1. INTRODUCTION ................................................... 2
2. TERMINOLOGY .................................................... 3
3. SUPA FRAMEWORK ................................................. 3
4. FRAMEWORK FUNCTIONAL ENTITIES .................................. 5
4.1. OPERATION AND MANAGEMENT APPLICATION ........................ 5
4.2. MANAGEMENT AGENT ............................................ 5
4.3. NETWORK ELEMENTS ............................................ 7
5. SECURITY CONSIDERATIONS ........................................ 7
6. IANA CONSIDERATIONS ............................................ 7
7. ACKNOWLEDGEMENTS ............................................... 7
8. NORMATIVE REFERENCES ........................................... 8
9. INFORMATIVE REFERENCES ......................................... 8
AUTHORS' ADDRESSES ................................................ 8
1. Introduction
As the Internet grows, more and more new services keep on arising,
and network traffic is rapidly increased, which makes network
management and configuration more and more complicated, while on the
other hand, dynamic and real-time configuration change is required,
e.g. Inter-Data Center (DC) traffic steering and tunneling, based on
real-time network status. Network applications can be used to
automate the complicated and dynamic network configuration. For this
goal, data models of network topology, data models of network
services, data model of network service development policies are
very necessary. Providing these data models to applications may
Zhou, et al Expires July 5, 2015 Page 2
Internet-Draft SUPA Architecture January 2015
provide significant improvements in configuration agility, error
detection and uptime for operators.
However the real value behind these configuration schemes lies
within the possible simplification through abstract models provided
by such systems to applications and network services running above
them (on the so-called northbound side). Well-designed simplified
models are able to provide a wide range of granularity for various
applications and network services needs, from the lower-level
physical network to high-level application services.
An abstract view of a network infrastructure can be realized using
network topology data model. The more accurate and detailed network
topology contains the details Protocol Layer 0 to Protocol Layer 7
(L0-L7) of network topology of a network infrastructure. This is the
case where resources across different layers including application
layer (L7), IP/network layer (L3), and lower layers (L0-L2), e.g.,
MPLS, SDH, OTN, WDM). The network resources may include physical
and/or virtual network node and links, e.g. routers, switches, and
VPN, etc.
Network service data model is service specific, and usually it
relies on network topology data model. The network service
contributes to the behavior of the higher layer service, which is
characterized by at least performance, dependability, and security
specifications.
In order to automate service configuration, sometimes it is
necessary to use a policy data model to tell the network Management
Agent (MA) how to map network service data model in combination with
topology data model into detail Network Element (NE) configuration,
e.g. how to choose a path for VPN which will involve a set of NE's.
The main goal of this document is to specify the SUPA reference
framework, its elements and interfaces.
The technology that can be used for this purpose is based on YANG
information and data models, see [RFC6020], [RFC6991].
2. Terminology
The terminology used in the SUPA problem statement draft
[ID.karagiannis-supa-problem-statement] applies also to this draft.
NE Network Element
MA Management Agent
OAMA Operation and Management Application
3. SUPA Framework
Zhou, et al Expires July 5, 2015 Page 3
Internet-Draft SUPA Architecture January 2015
+-------+ +-------+
| OAMA | | OAMA |
+-------+ +-------+
| | <-----SUPA data models
| |
--------------------------------- BUS
| |
| |
+-------------+ +-------------+
| Management | | Management |
| Agent | | Agent |
+-------------+ +-------------+
| | | | | |
| | | | | |
| | | | | |
NE1 NE2 NEn NE1 NE2 NEn
Figure 1: SUPA Framework
This section provides an overview of the SUPA framework. An overview
of the SUPA framework is given in Figure 1. The network entities
used in this framework are:
OAMA: Operation and Management Application, represents one or
more network entities that are running and controlling network
services.
MA: Management Agent, represents one or more entities that are
able to control the operation and management of a network
infrastructure, e.g., a network topology that consists of
Network Elements (NEs.)
Network Element (NE): handles incoming packets based on the
network management and controlling procedures. NEs can interact
with local or remote MA in order to exchange information, such
as configuration information, policy enforcement capabilities,
and network status.
BUS: there can be multiple OAMAs and MAs in a large scale
network, either in a single administrative domain or in multiple
administrative domains. The communication between OAMAs and MAs
can make use of a BUS. A BUS can be a message queue service, or
a dedicated (small) network or VPNs.
MA exchanges configuration information with NEs and derive the
actual and detailed network topology model. When an OAMA needs to
use this network topology it applies NETCONF [RFC6241] or RESTCONF
[ID.draft-ietf-netconf-restconf] and it sends a request to receive a
service specific abstraction from the MA(s). Subsequently, the MA(s)
provides a service specific abstraction of the network topology to
the application, which should be able to meet the requirements
imposed by this application. Various types of applications may get
different service specific abstractions of the same network topology
from MA. For example, for the same actual network topology, a VPN
network service will receive a different service specific
Zhou, et al Expires July 5, 2015 Page 4
Internet-Draft SUPA Architecture January 2015
abstraction of the network topology, than an inter-Data Center (DC)
network service.
For each network service instance a service specific abstraction
network topology needs to be generated and maintained. A network
service can use application based demands and policies, such as
tunneling or traffic steering, and possibly update its associated
service specific abstraction network topology. Moreover, by using
such policies, the application can instruct MA to map the service
specific abstractions to the actual (detailed) network topology and
NE specific configuration.
4. Framework Functional Entities
4.1. Operation and Management Application
There are a wide variety of communication services offered by
service providers. For each network service instance a service
specific abstraction network topology needs to be generated and
maintained.
The Operation and Management Application (OAMA) is a functional
entity, residing at the Application layer, which enables network
services, such as:
o) Network service, e.g. L2VPN, L3VPN, etc.
o) Application based policies
o) Update network topologies associated with each application.
As part of the SUPA operational procedures, OAMA performs the
following functions:
o) OAMA sends a request to MA to get service-specific
information to create an abstract network topology for a given
application.
o) OAMA exchanges necessary information with MA regarding any
update on the network topology for a given application along
with service-related policy information (e.g., tunneling or
traffic-steering policy rules).
4.2. Management Agent
Zhou, et al Expires July 5, 2015 Page 5
Internet-Draft SUPA Architecture January 2015
|
| to/from OAMA
|
+--------------------------+------------------------------+
|Management Agent Functional Block |
| |
| +----------+ +----------+ +---------+ +---------+ |
| | Generic | | Network | | Policy | | Service | |
| | Network | | Services | | Rules | | to | |
| | Topology | | Specific | | For | | Network | |
| | | | Topology | | Service | | Mapping | |
| +----------+ +----------+ +---------+ +---------+ |
| |
| +---------------------+ +-------------------------+ |
| | MA - OAMA Interface | | MA Management Interface | |
| +---------------------+ +-------------------------+ |
+---------------------------------------------------------+
Figure 2: MA Functional Blocks
Management Agent (MA) is a functional entity that is able to
generate, maintain and release:
1) Detailed network topology of a network infrastructure
2) Network service-specific network topology.
Moreover, MA supports the SUPA northbound interface/protocol. It
also supports a software repository, which stores the information
associated with each NE. By using application-based demands &
policies received from the OAMA it can map the service-specific
network topology and feature specific YANG models to the target
NE(s). This framework was enhanced to satisfy the demands of the
SUPA use cases.
The MA function provides a set of functions, including:
o) Detailed network topology: maintains an up to date
description of a detailed network topology that models the
topology and configuration of the network infrastructure.
Moreover, it can use existing network management and signaling
protocols, such as I2RS [I2RS], NETCONF [NETCONF], RESTCONF
[ID.draft-ietf-netconf-restconf], etc., to request the
implementation of the changes into the network
status/configurations.
o) Network service specific topology: maintains an up to date
service specific abstraction of the topology of the network
infrastructure, e.g. VPN service.
o) Policy Rules for Network Service: the policies can help to
automate service deployment and management, e.g. a policy when
the traffic load on a link exceeds a threshold, MA will
configure an extra link and perform load-balance. MA will
maintain a repository of policy rules.
o) Application to Network Mapping: using the application-based
demands and policy data model received from the OAMA it maps
service specific network topology to the actual/detailed network
Zhou, et al Expires July 5, 2015 Page 6
Internet-Draft SUPA Architecture January 2015
topology. Moreover, this functional block provides the mapping
of the actual/detailed network topology to NE/feature-specific
YANG models.
o) MA to network management system interface: provides the
interface with existing network management system, I2RS [I2RS]
NETCONF, etc. protocols to request and negotiate the
implementation of the changes into the network
status/configuration.
o) MA to OAMA interface: used to support the communication
between the OAMA and MA. The candidate protocols used for this
purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft-
ietf-netconf-restconf].
4.3. Network Elements
The Network Element (NE) handles incoming packets based on the
policy information communicated with MA and makes corresponding
policy enforcement, which is based on existing network management
policies. An NE may be a physical entity or a virtual entity and is
locally managed, via CLI, SNMP, or NETCONF.
SUPA will specify mechanisms, in order to enable the NEs to interact
with either local or remote network management system in order to
exchange information, such as configuration and status information.
The NEs will be able to push this information in an event or
periodic basis towards the network controller or provide it after
receiving a request from the network controller.
5. Security Considerations
Security is a key aspect of any protocol that allows state
installation and extracting of detailed configuration states. More
investigation remains to fully define the security requirements,
such as authorization and authentication levels.
6. IANA Considerations
No IANA considerations.
7. Acknowledgements
The authors of this draft would like to thank the following persons
for the provided valuable feedback: Diego Lopez, Jose Saldana,
Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue,
Zhou, et al Expires July 5, 2015 Page 7
Internet-Draft SUPA Architecture January 2015
Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou,
Georgios Karagiannis.
Early version of this draft can be found here:
https://tools.ietf.org/html/draft-zhou-supa-architecture-00
At the early stage of SUPA, we think quite some issue are left open,
it is not so suitable to call this draft as "architecture". we would
like to rename it to "framework". Later there may be dedicated
architecture document.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Informative References
[I2RS] Interface to the Routing System (i2rs) charter,
http://datatracker.ietf.org/wg/i2rs/charter/
[ID.draft-ietf-netconf-restconf] A. Bierman, M. Bjorklund, K. Watsen,
R. Fernando, "RESTCONF Protocol", IETF Internet draft (work in
progress), draft-ietf-netconf-restconf-03, October 2014
[ID.karagiannis-supa-problem-statement] G. Karagiannis, Q. Sun, L. M.
Contreras, P. Yegani, JF Tremblay, "Problem Statement for Shared
Unified Policy Automation (SUPA) " IETF Internet Draft (work in
progress)", draft-karagiannis-supa-problem-statement-02,October 2014.
[ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, C. Zhou, G.
Karagiannis, JF. Tremblay, "Use Cases for Distributed Data Center
Applicatinos in APONF", IETF Internet draft (Work in progress),
draft-cheng-supa-ddc-use-cases-01, October 2014
[NETCONF] Network Configuration (netconf) charter,
http://datatracker.ietf.org/wg/netconf/charter/
[RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6991] J. Schoenwaelder, "Common YANG Data Types", RFC 6991,
July 2013.
[RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman,
"Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
Authors' Addresses
Zhou, et al Expires July 5, 2015 Page 8
Internet-Draft SUPA Architecture January 2015
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: cathy.zhou@huawei.com
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
Parviz Yegani
JUNIPER NETWORKS
1133 Innovation Way
Sunnyvale, CA 94089
Email: pyegani@juniper.net
Zhou, et al Expires July 5, 2015 Page 9