| CCAMP Working Group | X. Zhang, Ed. |
| Internet-Draft | Huawei Technologies |
| Intended status: Informational | A. Sharma, Ed. |
| Expires: May 4, 2017 | Infinera |
| S. Belotti | |
| Nokia | |
| T. Cummings | |
| Ericsson | |
| October 31, 2016 |
YANG Models for the Northbound Interface of a Transport Network Controller: Requirements and Gap Analysis
draft-zhang-ccamp-transport-yang-gap-analysis-01
A transport network is a lower-layer network designed to provide connectivity services for a higher-layer network to carry the traffic opaquely across the lower-layer network resources. A transport network may be constructed from equipment utilizing any of a number of different transport technologies such as the optical transport infrastructure (Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport Network (OTN)) or packet transport as epitomized by the MPLS Transport Profile (MPLS-TP).
All transport networks have high benchmarks for reliability and operational simplicity. This suggests a common, technology-independent management/control paradigm that can be extended to represent and configure specific technology attributes.
This document describes the high-level requirements facing transport networks in order to provide open interfaces for resource programmability and control/management automation. Furtheremore, gap analysis against existing models are also provided so that it can used as the guidance to separate efforts/drafts proposing new models or augmentation models based on existing models.
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 May 4, 2017.
Copyright (c) 2016 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.
A transport network is a server-layer network designed to provide connectivity services, or more advanced services like Virtual Private Networks (VPN) for a client-layer network to carry the client traffic opaquely across the server-layer network resources. It acts as a pipe provider for upper-layer networks, such as IP network and mobile networks.
Transport networks, such as Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), Wavelength Division Multiplexing (WDM), and flexi-grid networks, are often built using equipments from a single vendor and are managed using proprietary interfaces to dedicated Element Management Systems (EMS) / Network Management Systems (NMS). All transport networks have high benchmarks for reliability and operational simplicity. This suggests a common, technology-independent management/control paradigm that is extended to represent and configure specific technology attributes.
Network providers need a common way to manage multi-vendor and multi-domain transport networks (where each domain is an island of equipments from a single supplier) and this requirement has been further stressed by the expansion in network size. At the same time, applications such as data center interconnection require larger and more dynamic connectivities. Therefore, transport networks face new challenges going beyond automatic provisioning of tunnel setup enabled by GMPLS (Generalized Multi-Protocol Label Switching) protocols to achieve automatic service provisioning, as well as address opportunities enabled by partitioning the transport network through the process of resource slicing. With a reduction in operational expenditure (OPEX) and capital expenditure (CAPEX) as the usual objectives, a common interface to transport network controllers are considered by network providers as a way to meet the requirements. The concept of Software Defined Networking (SDN) leverages these ideas.
The YANG language [RFC6020] is currently the data modeling language of choice within the IETF and has been adopted by a number of industry-wide open management and control initiatives. YANG may be used to model both configuration and operational states; it is vendor-neutral and supports extensible APIs for control and management of elements.
This document first specifies the scope and provides high-level requirements for transport network open interface modelling. Furthermore, detailed gap analysis of the typical scenarios with the existing model are provided. Thus, this document can used as a reference of existing models, and provides information of the missing ones which suggest further work.
For this draft, we use the domain controller as the reference point, with South Bound Interface (SBI) to the transport devices and North Bound Interface (NBI) to the orchestrator.
Transport networks have been evolving and deploying for decades, making them very heterogeneous. New and legacy transport devices support many protocols such as Path Computation Element Protocol (PCEP), TL1, SNMP, CLI, XML, NETCONF, Openflow etc. Domain controllers interfacing with transport devices need to support these protocols on its SBI, making the southbound fragmented. Domain controllers abstract the fragmented southbound view for its northbound clients by normalizing the NBI across various technologies, protocols, and vendors. The focus of this document is not to go into various southbound protocols to interface with the transport devices. Instead, this document focuses on the models that can be used by the domain controller and the orchestrator for various use cases identified in later sections of this document.
There is an ongoing unofficial weekly meeting among a group of individuals (see the github files [Transport-modeling-github] for more meeting minutes and materials produced), focusing on the efforts of analyzing the IETF models against a list of well known use cases to identify gaps. This document captures this efforts and summarized the main work and key findings of this group work.
YANG models are currently developed not only in IETF, but also in other Standard Development Organizations (SDO) such as ONF and MEF, which can be used on the interfaces of a domain controller and an orchestrator. Each domain controller and orchestrator can use models developed by different SDOs. Therefore it is important to ensure that deployment use cases and related funcionalities are supported by all models to allow a seamless translation/mediation between systems using different models.
If the Abstraction and Control of Traffic-Engineered Networks (ACTN) defined in [I-D.ceccarelli-teas-actn-framework] is used as a reference architcture, then the focus is equivalent to MPI (MDSC-PNC Interface) and CMI (CNC-MDSC Interface). More details about the relationship of the type of models and the type of ACTN interfaces can be found in [I-D.zhang-teas-actn-yang].
This section covers various high-level modeling requirements for transport networks.
The following are generic requirements for transport models:
The model should support the following Topological Links:
The Link should support various link related attributes like cost, latency, capacity, risk characteristics (including shared risk). The model should provide clear association between Link and its topology (including virtual topology), nodes and termination points.
The model should provide association between the link and any underlay circuit / service supporting the Link.
The model should support the following Topology Node:
[Editors' note: more details will be added later, which can be found in [Transport-requirements-github].]
[Editors' note: this will be added later, which can be found in [Transport-requirements-github].]
[Editors' note: this will be added later, which can be found in [Transport-requirements-github].]
[Editors' note: this will be added later which can be found in [Transport-requirements-github].]
There are several scenarios (a.k.a., use cases) where an open interface via domain controller to access server-layer (transport) network resources would be useful. Three scenarios are provided and can be used for model instantiation exercise to identify missing pieces of existing models. Note the models provided in this draft is for explanation purpose, the group effort actually uses slight different network examples for gap analysis exercise (see [Transport-usecases-github] for more details).
The first scenario is depicted as below (Figure 1 ):
/--\ +------+ +------+ /--\
| 1 ~~~| A +------------------| B |~~~~~ 3 |
\--/ +-----++ +--+---+ \--/
| |
| |
| |
++-----+ +---+--+
| F +------------+ C |
++-----+ +--+---+
| |
| |
| |
| |
| |
+---+-+ +---+-+ /---\
| E +---------------+ D |~~~~ 4 |
/--\~~~~~+-----+ +-----+ \---/
| 2 |
\--/
+----+ /--\
| | Transport NE | | DC
+----+ \--/
----- Transport Link ~~~ Transport-DC link
(a) Data Centers interconnected via a transport network
+---------------------+
| Data Center Network |
| Controller |
+---------+-----------+
|
|
|
| Open Interface
|
|
+---------+-----------+
| Transport Network |
| Controller |
+---------------------+
(b) The controller architecture for data center interconnection
Figure 1: Scenario 1: Data centers interconnected via a transport network and the controller architecture
For the data center operator, as a client of the transport network, assuming the objective is to trigger the transport network to provide connectivity on demand, the following capabilities, at a minimum, would be required on the common interface between the two controllers illustrated in Figure 1:
The second scenario, more complicated than the first, is depicted as below (Figure 2). In this example, we focus on the management and control via common interfaces for multi-domain networks with homogeneous technologies (such as OTN), but it can be extended further to multi-domain networks with heterogeneous technologies with higher complexity.
+-------------------------------------------------+ | Orchestrator/Coordinator | +---------+--------------+-------------------+----+ | | | | | | +------------+--+ | +----------+----------+ | Controller 1 | | | Controller 2 | +---------+-----+ | +-------+-------------+ # +----------------+ # #Qx | Controller 3 | # # +----------------+ #TL1 # # # ----+----- # ----+----- ____/ \____ # ____/ \____ | | # | | | | # | | | Network Domain +***********+ Network Domain | | 1 | # | 2 | |____ ___| # |____ ___| \ / #PCEP \ / ----------- # *---------- * * # * * * * # * * * * # * * * * # * * * * # * * * * # * * * *----+-----* * * ____/ \____ * *| |* | | | Network Domain | | 3 | |____ ___| \ / ---------- ***** inter-domain links ----- Open Interfaces ##### Controller-device interfaces
Figure 2: Scenario 2: Multi-domain network control and management
For the second scenario, the orchestrator controls and manages three distinct network domains, each controlled/managed by their domain controller. This scenario is of interest not only to transport-only networks, but also to heretegenous network orchestration such as coordinating the transport, the radio (5G) and packet core domains. But to keep the functions explanation later accurate, only transport-only multi-domain networks are considered.
In order to orchestrate across domains/layers, besides the capabilities mentioned for the first scenario, the orchestrator needs its interface between domain controllers to be equipped with the following additional functions:
In the first use case, if there are multiple technologies invovled, then it can be considered as a multi-layer case. [Editors' note: more details to be added later, some can be found in [Transport-usecases-github].]
For the common interface of a transport controller towards a northbound client, six main functions are derived from the scenarios explained in the last section. They are summarized in the table below and we also match these functions with YANG models that are being developed in existing drafts.
+-------------+-----------------------+---------------------------+ | Functions | Description | Related Existing | | | | YANG Models | |-------------+-----------------------+---------------------------+ | Obtaining |Getting the necessary | ietf-network.yang | | Access |access points info | ietf-network-topology.yang| | Point Info | | ietf-te-topology.yang | +-------------+-----------------------+---------------------------+ | Obtaining |Getting the topology | ietf-te-topology.yang | | Topology |info | ietf-otn-topology.yang | | | | ietf-wson-topology.yang | +-------------+-----------------------+---------------------------+ | Tunnel |Tunnel Setup, Deletion | | | Operations |Modification and Info | ietf-te.yang | | |Retrieval | ietf-otn-tunnel.yang | +-------------+-----------------------+---------------------------+ | Service |Requesting connectivity| | | Request |service and retrieval |ietf-transport-service.yang| | |the list of service | ietf-actn-vn.yang | | |request | | +-------------+-----------------------+---------------------------+ |Path Comp. | Path Computation pre | | | | service provisioning | ietf-te.yang | +-------------+-----------------------+---------------------------+ | Virtual |Requesting a virtual | | | Network |network and related | ietf-te-topology.yang | | Operations |control operations, | ietf-actn-vn.yang | | |(e.g.,update, deletion)| | +-------------+-----------------------+---------------------------+
Analysis and descriptions of whether and how these functions are supported by the YANG models are provided in more detail in Section 5.
As shown in the previous section, the functions of obtaining access point information, obtaining topology, and imposing virtual network operations can take advantages of the same set of topology YANG models. These functions are briefly explained further in the following sub-sections.
For cases such as scenario 1, a client may have no interest in directly controlling network resources, but might want an automated common control interface for initiating service requests. In this case, a transport domain controller may provide the access point information. This information can then be used in service request sent over the common interface.
The TE Topology YANG model provided in [TE-topo] [I-D.ietf-teas-yang-te-topo] can be used to provide a list of links. If the remote node and termination point information is unknown, it is omitted from the reported information. If the client-side node and termination point information is obtained via configuration or a distributed discovery mechanism, then it can also be added into the reported information. Technology-specific details might also be needed to further express the constraints/attributes associated with the access points. Note that all of this information is usually read only.
Refer to [I-D.ietf-teas-yang-te-topo] for explanations and examples on how to obtain the topology. For technology specific topology information, other models such as those provided in [WDM-Topo] [I-D.ietf-ccamp-wson-yang] and [ODU-Topo] [I-D.zhang-ccamp-l1-topo-yang] may be used.
There are two ways provided in [I-D.ietf-teas-yang-te-topo] in terms of how to present a multi-layer topology, discussions have been carried out among the unofficial group in terms of how the transitional link approach can work and the discussion material will be available soon in the github [Transport-modeling-github].
There are two ways to request the creation of a virtual network. One is to define the topology explicitly using the model provided in the topology YANG drafts listed in previous section. The other way is to provide an estimated traffic information (a traffic matrix) and ask for a domain controller of the provider network to provide a virtual network that can fulfill the demand. This second approach is supported by the YANG model in [I-D.lee-teas-actn-vn-yang].
The current [TE-Tunnel] [I-D.ietf-teas-yang-te] provides a technology agnostic Traffic-Engineered (TE) to manage and configure tunnel. The model included in that draft is currently being developed to make it generic for both controller and device usage. In the latest version, it already provides such a generic TE tunnel model that can cater to the base requirementss for tunnel operations but it may need to be augmented to support controller-specific operations.
Furthermore, technology-specific augmentations of the base generic TE tunnel models are needed. For example, for Optical Channel (OCh) (note: ITU is updating this term as OTSi.) tunnels in WDM networks, information such as the lambda resource usage is needed. Similarly, for ODU tunnels, information such as ODU-specific client signal, tributary slot information etc. is needed.
For path computation, [I-D.busibel-teas-yang-path-computation] presents now only use cases but YANG model work is also under consideration to provide statelss path computation RPC. There is currently ongoing discussions on how to provide such a function using the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base.
Service model is an important type of models, such as the one provided in [I-D.zhang-teas-transport-service-model], that enables automated operations between a client controller or an orchestrator and a domain controller. This transport connectivity service model is different from the model of a tunnel since the transport connectivity service model are enforced over the client-server interfaces, and it hides unnecessary provider network details from a client.
This document requests no IANA actions.
Clearly modifying server-layer resources will have a significant impact on network infrastructure. More specifically they will provide the services and applications running across client-layers, which the server-layer is supporting. Therefore, security must be an important consideration when implementing the architecture, models and protocol mechanisms discussed in this document.
Communicating service and network information (including access point identifiers, capabilities, topologies, etc.) across external interfaces represents a security risk. Thus, mechanisms to encrypt or preserve the domain topology confidentiality should be used.
A key consideration are the external protocols (those shown as entering or leaving the orchestrator and controllers shown in Figure 2 (Scenario 2: Multi-domain network control and management)) which must be appropriately secured. This security should include authentication and authorization to control access to different functions that the orchestrator may perform to modify or create state in the server-layer, and the establishment and management of the orchestrator to controller relationship.
The orchestrator will contain significant data about the network domains, the services carried by each domain, and customer type information. Therefore, access to information held in the orchestrator must be secured. Since such access will be largely through external mechanisms, it may be pertinent to apply policy-based controls to restrict access and functions.
The core objectives of this document are to assist in the deployment and operation of transport services across server-layer network infrastructure. The model-driven management/control principles, which are vendor-neutral and supported by extensible APIs, should be utilized.
The open models described in this document are based on YANG [RFC6020] and the RESTCONF [RESTCONF] messaging protocol, a REST-like protocol running over HTTP for accessing data defined in YANG, may also be used.
We would like to thank Young Lee, Igor Bryskin and Aihua Guo for their comments and discussions.
The following people all contributed to this document and are listed below:
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Yan Shi
China Unicom
Email: shiyan49@chinaunicom.cn
Jeong-dong Ryoo
ETRI
Email: ryoo@etri.re.kr
Yunbin Xu
CAICT
Email: xuyunbin@ritt.cn
Daniel King
Lancaster University
Email: d.king@lancaster.ac.uk
| [I-D.ietf-netconf-restconf] | Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ietf-netconf-restconf-13, April 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |