Comptel Offer Example Templates to the Open Marketplace

State-of-Play

There remains no doubt that virtualization is shaking the foundations of the telecommunications industry and is here to stay. As the technology continues to mature and evolve, use cases become more realistic and so do the requirements to represent the service specifications that allow their programmatic utilization and consumption.

Several standards organizations have laid proposals to this purpose and there appears to be consensus that, in the Network Functions Virtualisation (NFV) case at least, TOSCA NFV appears to be positioning itself as the preferred option for operators and vendors alike.

The Topology and Orchestration Specification for Cloud Applications (TOSCA) is a data model standard managed by industry group OASIS that can be used to orchestrate Network Functions Virtualization (NFV) services and applications. TOSCA does this through a collection of information models and templates to orchestrate applications seamlessly across multiple cloud domains which is ideal for network functions that are virtualized and deployed in datacentres.

At the time of this writing, the latest release of the TOSCA NFV Simple Profile dates from mid-March 2016. The document provides a good insight but it lacks practical, consistent examples (e.g. there are a few errors) and examples from additional sources are hard to come by. This applies to the Cloud Service Archive or CSAR (pronounced Cesar) packaging mechanism, in which the specification is conveniently wrapped with all the necessary components.

[Comptel] has taken the information that’s publicly available and created some examples that we would like to share with the broader community.

Use Case: vEPC Core Network CSAR

A basic representation of the Evolved Packet Core (EPC) Network Service Descriptor (NSD) composed of four Virtual Network Functions (VNFs) as shown in Figure 1 below. In addition, every node has a connection to a common management network.

Figure 1: vEPC Architecture & Interfaces

The CSAR file contains metadata, the service templates or specifications, images and the corresponding scripts for the VNFs themselves. Figure 2 shows the structure of the file.

Figure 2: CSAR file structure

As displayed in Figure 3, the metadata file contains in line 4, a pointer to the main driving template, in this case the overall vEPC NSD which will link to the individual nodes (e.g. VNFs) and their relationship and corresponding connectivity.

Figure 3: Contents of metadata file (TOSCA.meta)

The Network Service Design

The NSD provides the global overview (refer to snapshot below) on how the different components (e.g. VNFs, VLs, FGs, etc.) come together. Lines 9 thru 13 point to the VNF templates, in this case for every VNF.

The individual VNFs are described in lines 26, 37, 49 and 58 respectively. They contain a reference to the type, the list of (virtual) networks they are connected to and in those cases where applicable, a declaration of the forwarding graph capabilities (e.g. lines 45, 46 and 47). Additional details on the VNF themselves are contained on their own descriptors (VNFDs) which are shown later.

Next are the details of the external connection points (CPs). These are demarcation points for the NSD as depicted in Figure 4 and they are described in lines 65, 73, 81 and 89.

Figure 4: External Connection Points

Finally, the networks interconnecting the VNFs themselves. In this case, all networks are point-to-point connections (e.g. ELINE) except for the management one, which is shared across all VNFs (ELAN). Every declaration, as seen in lines 97, 108, 113, 119, 125, 131 and 137 indicates the number of network entities attached to them.

The Virtualised Network Function Descriptor

The VNFDs provide details on the specifications of the individual nodes. The vPDN GW descriptor is shown below as a reference. Starting on line 42 the connectivity is described. This VNF requires two computational resources as expressed on line 48 (VDU1 & VDU2). Two of its interfaces (CP21 & CP22) are enabled to support Forwarding Graphs (line 51). In this specific case, four standard transactions types are supported through self-contained scripts: create, configure, stop and delete (line 54). The interfaces and their respective networks can be appreciated in general the topology depicted in Figure 5.

Figure 5: PDNGW_VNF Topology

At the end of the VNFD template are two Forwarding Paths (Line 144 and 151). They represent the incoming and outgoing traffic for the PDN gateway. Figure 6 and Figure 7 provide a visual perspective of the traffic flows they control.

Figure 6: Forwarding Path1 on VNFD

Figure 7: Forwarding Path2 on VNFD

NSD_vEPC.yaml – File contents:

vPDNGW_VNF.yaml – File contents:

Comments

The standards provide enough tools to cover the most general of use cases, but we expect to see future updates that can target elements of the service description that represent more complex and realistic scenarios, for instance:

1. Quality of Experience (QoE) or in general Quality of Service (QoS) features. There are some brief references in the existing standards but this area requires further development.
2. The transactions/interfaces need to support more complex features that can allow them to be referenced and consumed more easily by higher order service orchestration processes.
3. Forwarding Graphs should include indications of the traffic types.

Although Comptel has worked out these areas for its own products and specifications, the real value materialises when these specifications become open and seamlessly interchangeable by the different components in the architecture.