The Abstraction and Control of Traffic-Engineered Networks (ACTN) initiative represents a set of well-defined use cases developed from the input of network operators and service providers, international academic researchers, and vendors. The ACTN framework and its ongoing solution development addresses gaps between technology layers that could limit resource abstraction for multitechnology and multivendor transport networks. Key industry partners for the work include China Mobile, China Unicom, Ericsson, ETRI, Huawei, Juniper, KDDI, KT, Microsoft, Nokia, SKT, Telefonica, and University of Lancaster.
ACTN’s main characteristics include:
- A practical approach to repurpose both existing and well-defined technologies and underpinning them with software-defined networking (SDN) principles, ACTN facilitates heterogeneous domain transport networking and control/management technologies (e.g., GMPLS/ASON, PCE, and NMS/EMS), while enabling logically centralized multidomain control/management.
- Use of a hierarchical architecture to scale and support the clear domains (vertically and horizontally) that exist in current transport networks
- Facilitating role-based access to allow consumers of high-bandwidth services seamless access to the underlying packet and optical transport networks.
- Virtual network automation using abstraction, slicing, and in-operation optimization of underlying network resources for higher-layer services, independent of how the underlay domain resources are managed or controlled.
- Design objectives and requirements that are derived from network operators’ and service providers’ needs for end-to-end service agility.
- Provision of network virtualization services to customers and the ability to control and operate their virtual network slices according to their application requirements and underlying provider policies and technology rules.
This article provides an overview of ACTN: its architecture, Internet standards progress, and academic collaboration via the Towards Ultimate Convergence (TOUCAN) project, and other related work, including the IETF Hackathon, Bits-N-Bites, and inclusion into the Open Network Operating System (ONOS).
ACTN Architecture
Figure 1 shows the architecture of ACTN. ACTN supports controller hierarchies defined for various functions and roles via three controller types: customer network controller (CNC), multidomain service coordinator (MDSC), and physical network controller (PNC). In addition to the controllers, there are devices in the network that are referred to as network elements. There are also three types of interfaces: CNC-MDSC interface (CMI), MDSC-PNC interface (MPI), and southbound interface (SBI).
Figure 1. ACTN Architecture
The CNC enables the network’s customers to instantiate their virtual networks. Usually, the CNC directly interfaces the applications and forwards their requirements to the MDSC via the CMI. It is assumed that both the CNC and the MDSC have common knowledge about the end-point interfaces based on their business negotiation prior to service instantiation. Given their virtual network, customers can better manage and operate their services/applications with a higher degree of flexibility—a benefit for businesses based on the Internet.
The MDSC is usually run by the carriers to provide services to the customer (CNC). The MDSC receives abstracted network information from one or multiple PNCs, and can therefore coordinate resources from various PNCs in multidomain, multivendor, or multitechnology scenarios. The MDSC is the only building block of the architecture that needs to implement all the main ACTN functionalities, including the multidomain coordination function, virtualization/abstraction function, customer mapping function, and virtual service coordination. Carriers will take advantage of ACTN, as interoperation is enabled on the MDSC level, and the corresponding operations and management are also greatly simplified due to abstraction.
The PNC is the domain controller in charge of configuring the network elements, monitoring the physical topology of the network, and passing it, either raw or abstracted, to the MDSC. The PNC and its SBI, together with devices, can support a variety of heterogeneous protocols that are suited to a vendor’s choice to pursue high-performance with automation techniques.
IETF Standard Progress
The ACTN requirements and framework documents are progressing in the Traffic Engineering Architecture and Signaling (TEAS) WG in the Routing Area. To date, the ACTN requirement draft (draft-ietf-teas-actn-requirement) and the ACTN framework draft (draft-ietf-teas-actn-framework) are WG documents in the TEAS WG. From the solutions perspective, the TEAS WG and other WGs, including PCE, CCAMP, and RTGWG, are relevant WGs. YANG-based solutions to fulfill ACTN requirements are addressed in the TEAS and CCAMP WGs, while PCEP-based solutions are addressed in the PCE WG.
IETF YANG models associated with RESTconf or Netconf protocols are considered solutions for the ACTN interfaces. A topology model (defined in draft-ietf-teas-yang-te-topo) and a tunnel model (defined in draft-ietf-teas-yang-te) have been adopted in the TEAS WG. Other models, such as service and virtual network models (defined in draft-zhang-teas-transport-service-mode and draft-lee-teas-actn-vn-yang) are also applicable to ACTN interfaces. Draft-zhang-teas-actn-yang provides an overview of how various YANG models are applicable to ACTN. Similarly, draft-dhody-pce-applicability-actn offers an overview of how PCEP is applicable to ACTN.
ACTN IETF Events: Hackathon and Bits-N-Bites
ACTN participated in the IETF 96 Hackathon with two independent projects. One was applied on an optical network and involved making a tool for online network survivability analysis. YANG model work was evaluated in the optical project, as a solution for MPI. Two IETF Internet-Drafts—draft-ietf-teas-yang-te-topo-04 and draft-zhang-ccamp-transport-ctrlnorth-yang-00—were implemented. This project successfully concluded that IETF YANG models are applicable to the ACTN architecture. The second project was applied on a packet network to enable customers to dynamically select among multiple destinations. Both of these projects were based on the Open Network Operating System (ONOS) controller platform, and used PCEP as a protocol between controller and network elements.
Based on the single domain scenario of IETF 96, the ACTN Hackathon project will bring multiple vendors to further develop multidomain and multilayer scenarios at IETF 97. The packet network will be interworking with the optical network to provide E2E service, and a uniform IETF YANG model will be supported by multiple vendors on MPI. During the Bits-N-Bites session at IETF 97 we will demonstrate an IP and optical multidomain, multivendor scenario using RESTConf/YANG models, as well as Stateful H-PCEP.
ONOS ACTN Project
An open source project has been launched in ONOS. The project aims to implement IETF YANG models and the RESTconf protocol in order to better fit the MPI for multidomain, multivendor service provisioning. Full details about the project can be found at https://wiki.onosproject.org/pages/viewpage.action?pageId=8424694.
Toward Ultimate Convergence Project
The TOUCAN project outlined the grand research challenges of facilitating the optimal interconnection of infrastructure and resource abstraction (virtualization and programmability) of transport network technology. This is the foundation upon which technology-agnostic and seamless end-to-end convergence is achieved. TOUCAN Project partners include University of Bristol, University of Edinburgh, Heriot-Watt University, and University of Lancaster.
For more information about ACTN, visit https://sites.google.com/site/openactn/.