Internet DRAFT - draft-zhou-supa-framework
draft-zhou-supa-framework
Network Working Group C. Zhou
Internet-Draft Huawei Technologies
L. M. Contreras
Intended status: Informational Telefonica
Expires: November 08, 2015 Q. Sun
China Telecom
P. Yegani
Juniper Networks
May 08, 2015
The Framework of Simplified Use of Policy Abstractions (SUPA)
draft-zhou-supa-framework-02
Abstract
Currently, there are network services that impose specific demands
on a communication network. This document describes the SUPA basic
architecture, its elements and interfaces. The main SUPA
architecture entities are the Service Management (SM) and the
Network Manager/Controller (NM/NC). The SM is a functional entity
that creates and runs network services by using a set of NM/NCs. The
NM/NC is a functional entity that provides one or more of the
following functions: (1) the generation, maintenance and release of
network topologies, (2) the generation, maintenance, and release of
network service-specific abstractions, (3) the mapping between
network service-specific abstractions and the network topology, and
(4) the mapping between network service-specific abstractions and
network device configuration. Both the SM and the NM/NC may be made
up of multiple distinct entities that collectively perform their
functions.
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 August 08, 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 .................................................. 4
4. FRAMEWORK FUNCTIONAL ENTITIES ................................... 6
4.1. SERVICE MANAGEMENT ........................................... 6
4.2. NETWORK MANAGER/CONTROLLER ................................... 6
4.3. NETWORK ELEMENTS ............................................. 7
5. SECURITY CONSIDERATIONS ......................................... 8
6. IANA CONSIDERATIONS ............................................. 8
7. ACKNOWLEDGEMENTS ................................................ 8
8. NORMATIVE REFERENCES ............................................ 8
9. INFORMATIVE REFERENCES .......................................... 8
AUTHORS' ADDRESSES ................................................. 9
1. Introduction
As the Internet grows, new services are created, new devices are
connected, and new users use the Internet. These and other factors
contribute to the significant increase in the amount and type of
network traffic. This in turn makes network management and
configuration more and more complicated.
However, the need for dynamic and real-time configuration changes is
required. One example is Inter-Data Center (DC) traffic steering and
tunneling, based on real-time network status. Dedicated network
management applications are required to automate the complicated and
Zhou, et al Expires November 08, 2015 Page 2
Internet-Draft SUPA Architecture January 2015
dynamic network configuration present in today's systems. Such
applications need interoperable data models of network topology,
network services, and policy rules to support the design, deployment,
and maintenance of network services. Providing these data models to
network management applications may provide significant improvements
in configuration agility, error detection, and uptime for operators.
However, in order to scale and to ensure configuration change
consistency, existing network configuration schemes must be
simplified through the use of abstraction. This increases the
programmatic control over such systems. 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
one or more network topology data models. Each such topology model,
whether physical or logical, may be used as its own reusable managed
object. This enables existing topologies to be reused to create new
topologies. This applies to models of different layers, including
the application layer (L7), IP/network layer (L3), and lower layers
(L0-L2, such as MPLS, SDH, OTN, WDM). The network resources may
include physical and/or virtual network nodes and links.
A network service data model is service specific, and usually relies
on a network topology data model. The network service data model
defines the behavior of the network service, which is characterized
by one or more metrics that include performance, dependability, and
security specifications.
One method to automate service configuration is to use a policy data
model. Policy, in conjunction with network service and device data
models, can be used to tell the Network Manager/Controller (NM/NC)
how to generate Network Element (NE) configurations using network
service data models in combination with topology data models. For
example, this process can be used 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
architecture, its elements, and its interfaces.
YANG data models (e.g., see [RFC6020], [RFC6991]) can be used for
representing service and topology models.
2. Terminology
The terminology used in the SUPA problem statement draft
[ID.karagiannis-supa-problem-statement] also applies to this draft.
NE Network Element
NC Network Controller
NM Network Manager
Zhou, et al Expires November 08, 2015 Page 3
Internet-Draft SUPA Architecture January 2015
NM/NC Network Manager/Controller
SM Service Management
3. SUPA Framework
+------------------------+
| Service Management |
| +--------------------+ |
| | Policy Data Model | |
| +--------------------+ |
| +--------------------+ |
| | Service Management | |
| | Data Model | |
| +--------------------+ |
+------------------------+
|
|
| NETCONF/RESTCONF
-----------------------------------------------
| |
| |
+----------------------------+ +----------------------------+
| Network Manager/Controller | | Network Manager/Controller |
| +------------------------+ | | +------------------------+ |
| | Network Resource | | | | Network Resource | |
| | Data Model | | | | Data Model | |
| +------------------------+ | | +------------------------+ |
+----------------------------+ +----------------------------+
| | | | | |
| | | | | |
| | | | | |
NE1 NE2 NEn NE1 NE2 NEn
Figure 1 SUPA Framework
An overview of the SUPA framework is shown in Figure 1. The network
entities used in this framework are:
SM: Service Management, which represents one or more network
entities that are running and controlling network services.
Policy Data Model
Model of policy rules for managing the network service and
mapping services dynamically to the network topology and
network resources. Policy data models are used to describe
high level service requirements, such as routing requirements.
Example of policy data model can be found in [ID.draft-
strassner-supa-generic-policy-info-model] and [ID.draft-bi-
supa-policy-model].
There can be various types of policies, including service
specific policies and network-wide policies. There can be a
Zhou, et al Expires November 08, 2015 Page 4
Internet-Draft SUPA Architecture January 2015
centralized entity managing the network-wide policies, which
may be called as policy manager. The policy manager can be
located in the SM or in a separate location.
Policy data models now considered by SUPA are generic policy
data model, ECA (event, condition, action) as described in
SUPA charter. The work may be extended in the future.
Service Management Data Model
Model of the network service (e.g., VPNs) and the network
resources required by the network service to be correctly
deployed and executed on the physical and/or virtual topology.
Example of service management data model can be found in
[ID.draft-zaalouk-supa-vpn-service-management-model].
NM/NC: Network Manager / Controller, which 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 Resource Data Model
Model of the physical and virtual network topology including
the resource attributes (e.g., data rate or latency of links)
and operational parameters needed to support service
deployment over the network topology.
Example of network resource data model can be found in
[ID.draft-contreras-supa-yang-network-topo]
SUPA will not define network resource data model, which is
out of the scope of SUPA. SUPA will make use of network
resource data models defined by other WGs or SDOs.
Network Element (NE), which handles packets based on the network
management and controlling procedures. NEs can interact with
local or remote NM/NC in order to exchange information, such as
configuration information, policy enforcement capabilities, and
network status.
Service Management (SM) communicates with Network Manager/Controller
(NM/NC) using an appropriate protocol, such as NETCONF [RFC6241] or
RESTCONF [ID.draft-ietf-netconf-restconf].
NM/NC exchanges configuration information with NEs and derives the
current network topology that contains the NEs, and also the
capabilities and status of NEs, which will be stored in network
resource data model. NM/NC may also communication with traditional
network management system to retrieve the above information. It can
use existing network management and signaling protocols, such as
I2RS [I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf-
restconf], etc.
Zhou, et al Expires November 08, 2015 Page 5
Internet-Draft SUPA Architecture January 2015
Service Management (SM) will send policy data model and service
management data model, which will in conjunction with network
resource data model be mapped to detail NEs' configurations by
network manager / controller.
4. Framework Functional Entities
4.1. Service Management
There are a wide variety of communication services offered by
service providers.
The Service Management (SM) is a functional entity, residing at the
Application layer, which enables network services, such as:
o) Network services (e.g., L2VPN, L3VPN, etc.)
o) application-specific policies
SM will push service management data model and policy data model to
NM/NC for service deployment.
4.2. Network Manager/Controller
|
| to/from Service Management
|
+--------------------------+----------------------------------------+
| Network Manager/Controller Functional Block |
| +-------------------------------+ +---------------------------+ |
| | NM/NC to SM Interface | | mapping: Policy Data | |
| +-------------------------------+ | Model + Network Resource | |
| | Data Model to Service | |
| +-------------------------------+ | Specific Topology | |
| | | +---------------------------+ |
| | Network Resource Data Model | |
| | | +---------------------------+ |
| +-------------------------------+ | mapping: Service Data | |
| | Model + Service Specific | |
| +-------------------------------+ | Topology to Detail NEs' | |
| | NM/NC to NE Interface | | Configurations | |
| +-------------------------------+ +---------------------------+ |
+-------------------------------------------------------------------+
Figure 2 NM/NC Functional Blocks
Network Manager/Controller (NM/NC) is a functional entity that is
able to generate and maintain desired and current topologies of the
network infrastructure. As part of this process, it is also
responsible for reserving and releasing network resources that are
required to support network services in a given network
infrastructure.
The NM/NC contains a set of data models, functions and APIs,
including:
Zhou, et al Expires November 08, 2015 Page 6
Internet-Draft SUPA Architecture January 2015
o) Network Resource Data Model
Maintain an up to date topology of the network infrastructure,
including capabilities and current status of NEs.
o) Mapping: service specific topology
This mapping procedure will combine the policy data model and
service management data model and generate a specific topology.
o) Mapping: target NE(s) detail configurations
This mapping procedure will use the service specific topology
generated in the previous procedure and the service management
data model to generate detail NE(s) configurations.
o) NM/NC to traditional network management system interface:
provides the interface with existing network management system
protocols (e.g., I2RS [I2RS], NETCONF, etc.) to request
configuration and status information, and push configuration changes
to NEs.
o) NM/NC to SM interface: used to support the communication between
the SM and NM/NC. The candidate protocols used for this purpose
could be either NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-
netconf-restconf].
An example of the mapping procedures can be that, a service requires
that a link from A to B is created; and the policy requires that the
hops of this link should not exceed N. Then when NM/NC receives the
policy data model and service management data model from SM, it will
first apply the policy data model to the network resource data model
and get a sub-set topology which can fulfill the hops limit
requirements. Then NM/NC will further generate detail configurations
for target NE(s). The mapping procedures can be enforced by
functional entity called policy agent.
After the service is deployed, if there is a network topology change,
network configurations for this service may need to be updated
accordingly. A possible solution is to repeat the mapping procedures,
and generate configurations for NEs (maybe another set of NEs). This
requires that NM/NC maintains a copy of the service management data
models and policy data models.
For more detail about mapping mechanisms, please refer to [ID.draft-
pentikousis-supa-mapping].
4.3. Network Elements
The Network Element (NE) responds to requests and commands from the
NM/NC and makes corresponding configuration changes. An NE may be a
physical or a virtual entity, and is locally managed (e.g., via CLI,
SNMP, or NETCONF).
SUPA will specify mechanisms, in order to enable the NEs to interact
with either local or remote network management systems. The
Zhou, et al Expires November 08, 2015 Page 7
Internet-Draft SUPA Architecture January 2015
interaction may include the exchange of information, such as
configuration and status information. The NEs will be able to push
this information in an event that the NM/NC can subscribe to, and/or
provide this information after receiving a request from the NM/NC.
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,
Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou,
Georgios Karagiannis, John Strassner, Raghav Rao, Jing Huang.
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 issues 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 a 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/
Zhou, et al Expires November 08, 2015 Page 8
Internet-Draft SUPA Architecture January 2015
[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-04, January 2015
[ID.karagiannis-supa-problem-statement] G. Karagiannis, Q. Sun, L. M.
Contreras, P. Yegani, JF Tremblay, " Problem Statement for
Simplified Use of Policy Abstractions (SUPA)" IETF Internet Draft
(work in progress)", draft-karagiannis-supa-problem-statement-06,
March 2015.
[ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi
, L. M. Contreras, "Use Case for Distributed Data Center in SUPA",
IETF Internet draft (Work in progress), draft-cheng-supa-ddc-use-
cases-06, April 2015
[ID. draft-zaalouk-supa-vpn-service-management-model] D. Zhang, A.
Zaalouk, K. Pentikousis, Y. Cheng, "VPN Service Management YANG Data
Model", IETF Internet draft (Work in progress), draft-zaalouk-supa-
vpn-service-management-model-03, April 2015
[ID.draft-strassner-supa-generic-policy-info-model] J. Strassner,
"Generic Policy Model for Simplified Use of Policy Abstractions
(SUPA)", IETF Internet draft (Work in progress), April, 2015
[ID.draft-bi-supa-policy-model] J. Bi, R. Tadepalli, M. Hayashi,
"DDC Service Policy YANG Data Model", IETF Internet draft (Work in
progress), March, 2015
[ID.draft-pentikousis-supa-mapping] K. Pentikousis, D. Zhang,
"Simplified Use of Policy Abstractions (SUPA): Configuration and
Policy Mapping", IETF Internet draft (Work in progress), draft-
pentikousis-supa-mapping-04, March 2015
[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
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Zhou, et al Expires November 08, 2015 Page 9
Internet-Draft SUPA Architecture January 2015
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 November 08, 2015 Page 10
