Blog

The Internet Engineering Task Force (IETF) has just published a “Framework for Abstraction and Control of TE Networks (ACTN)” as RFC 8453 [1]. This is an important milestone for the Metro-Haul project because ACTN is a key concept in the management architecture that we are considering. The document received text contributions from two Metro-Haul participants, Adrian Farrel and Daniel King.

So, now is a good time for a quick overview of ACTN, its components, the external interfaces it presents, and the processes that would be followed. The ACTN project started as a management architecture directed at transport networks, but was quickly expanded to cover all Traffic Engineering (TE) networks. The objective is to provide a way for customers of a network operator to request and then manage a virtual network built on top of TE connections across the operator’s network.

Figure 1 (below) is the reference architecture for ACTN. The Customer Network Controller (CNC) is a software component under control of the customer. It makes a request to the network operator for a virtual network by sending a message over the CNC-MDSC Interface (CNI). The message is caught by a central control component called the Multi-Domain Service Coordinator (MDSC).

The MDSC is responsible for orchestration of the network resources in order to plan and instigate TE connections across the operator’s networks to build a virtual network to meet the customer’s requirements. The MDSC talks to a Provisioning Network Controller (PNC) component, that is responsible for controlling one of the operator’s networks. The MDSC sends the PNC requests over the MDSC-PNC Interface.

Each PNC controls a network over a South Bound Interface (SBI) and uses that to instruct the networks to set up the desired connections. The networks may be different administrative domains, entirely different technologies, or may themselves be virtual networks. The MDSC has applied any required policy and orchestrated the necessary connections across all underlying networks that combine to create the customer’s virtual network.

Figure 1 : The ACTN Architectural Components

Figure 2 (below) shows another view of the ACTN architecture and shows how different level networks are coordinated to produce an end-to-end connection.

Figure 2 : The ACTN Architecture Producing and End-to-End Connection

The ACTN forms an important part of the Software Defined Networking (SDN) element of the Metro-Haul project. As you can see from Figure 3 (below), the project is working hard to design a software control system to operate the optical metro network to support 5G services.

Figure 3 : A Whiteboard from Metro-Haul’s Software Design

The IETF is, of course, in the process of developing and standardising a large number of YANG data models, and it is important to understand how these can be applied in the context of the ACTN architecture. Due to the importance of this work to Metro-Haul, a number of project participants are contributing to the work on the YANG model.

At the CMI there are several existing models that may also be applied, these include: the Layer 3 VPN Service Model (L3SM) [2], the Layer 2 VPN Service Model (L2SM) [3], and the Layer 1 Connectivity Model [4]. Each model describes how a customer can request a service from a network operator in abstract terms. Additionally, the ACTN Virtual Network Operations Model [5] allows a customer to request and interact with a virtual network created by the network operator.

The MPI is achieved by a range of YANG modules dependent on the technology of each underlying network. Some models are more generic such as the YANG Data Model for Traffic Engineering Tunnels and Interfaces [6] and the TE Topology and Tunnel Modeling for Transport Networks [7]. Other models are much more detailed and represent specific network technologies such as the Optical Transport Network (OTN) Tunnel YANG Model [8], and the YANG data model for Flexi-Grid media-channels [9].

The SBI data models are not in scope for the ACTN specification, but there are plenty of southbound YANG models being specified both in the IETF and within other standards bodies and OpenSource initiatives.
A further discussion of the applicability of YANG models to ACTN can be found in [10].

References:
[1] https://www.rfc-editor.org/rfc/rfc8453.txt
[2] https://www.rfc-editor.org/rfc/rfc8299.txt
[3] https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model.txt
[4] https://www.ietf.org/id/draft-ietf-ccamp-l1csm-yang.txt
[5] https://www.ietf.org/id/draft-ietf-teas-actn-vn-yang.txt
[6] https://www.ietf.org/id/draft-ietf-teas-yang-te.txt
[7] https://www.ietf.org/id/ draft-ietf-teas-te-topo-and-tunnel-modeling.txt
[8] https://tools.ietf.org/html/draft-ietf-ccamp-otn-tunnel-model.txt
[9] https://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-media-channel-yang.txt
[10] https://www.ietf.org/id/draft-ietf-teas-actn-yang.txt