Virtual Network Service Environment

Various services, like wired or wireless voice and data services, Internet services, content delivery, leased circuits and virtual private networks, provided by telecommunication companies have been considered in this work as carrier network services or simply carrier services. In the virtualized form they are referred to as virtual network services. Traditionally, networks providing these services have been built using specialized physical appliances and transmission links that are custom built for carrier-grade performance. The proprietary and closed nature of these appliances creates vendor lock-in leading to high cost, prolonged service deployment time, inflexibility in scaling and introducing new services. NFV and cloud computing provide a way to create network functions, in software, over inexpensive hardware resources. Such virtual functions can be linked with virtual network links to create VNSs. The VNSs result in open, flexible, scalable and less expensive networks that are not proprietary and thus prevent vendor lock-in. In the next sub-section we shall see the constituents of VNS along with the cloud set-up that can be used for hosting such services.

5.3.1 Constituents of a Virtual Network Service

In most discussions on VNSs, VNFs are the basic unit of placement. They exhibit functional behavior similar to their physical counterparts and have well-defined interfaces consistent with relevant industry standards. VNFs can be instantiated on virtual machines (VMs) obtained from datacenters, or cloud service providers. All the instances of a VNF, for example, that of the core router function, would usually be hosted on one or more dedicated VMs on one or more clouds depending on the carriers’ requirements and CSPs own policies regarding these deployments.

An SFC or a VNF forwarding graph is a set of VNFs, interconnected in a well-defined sequence, to route the packets [26]. They are connected like the way the physical appliances are connected in a traditional network [124]. IETF RFC 7498 describes each network service being implemented through one or more SFCs [125] [126]. The SFCs can also be hybrid in which the carrier retains some of the legacy physical network functions (PNFs) while virtualizing the other functions. The SFC may, therefore, consist of VNFs, PNFs, and the links among them. Figure 5.1 shows the components of an SFC and associated modules.

The broadband VNS, shown in Figure 5.1, is an SFC consisting of four VNFs, viz., an aggregation switch, a Border Network Gateway (BNG) and a core router. It also has multiple instances of a Physical Network Function (PNF), viz., Digital Subscriber Line Access Multiplexers (DSLAMs), retained from the legacy network. Each VNF has its own Element Management System (EMS), which interfaces the VNF to rest of the network [124]. The Operation Support System/Business Support System (OSS/BSS) of the carrier manages the VNFs and SFC through the EMSs.

Figure 5.1 Broadband service function chain and associated modules

SFCs can be placed on the available clouds in a number of ways. CSPs, or the niche VNF as a Service (VNFaaS) providers, may offer commonly used network functions, which may be leased by the carriers to form an SFC. Alternatively, with a view to exercise more control over the

VNF2 VNF3

DSLAM BNG Core Router

PNF1 Internet Aggr. Switch VNF1 DSLAM Users

EMS2 EMS3 EMS4

OSS/BSS

SFC EMS1

performance parameters and cost, carriers may lease, virtual machines, and associated resources, in the clouds and instantiate VNFs themselves. Unless otherwise stated, our discussion presumes the use of the latter method. Figure 5.2 shows an example of an SFC mapped to multiple clouds. It may be noted that we now have four VNFs, as the SFC has two types of BNGs. The Aggregation Switch is presumed to have a built-in load-balancing function for distributing traffic between the two forked paths. The EMSs have been omitted for simplicity. The end-to-end latency of the SFC would depend on how, when, and where the constituent functions have been placed. When an initially placed SFC does not meet the required conditions, it has to be reconfigured by scaling up functions or even moving the VNFs to different clouds.

Figure 5.2. Mapping service function chain to the multi- cloud system

5.3.2 The Multi-cloud Hierarchy

Public cloud services like Amazon EC2, Google Cloud Services, and Microsoft Azure provide the advantage of relatively inexpensive resource leasing options. Big public clouds are multi- tenant and have a regional or international presence. These clouds can handle large volume, variety, and velocity of traffic. While a large public cloud does offer greater flexibility in obtaining resources and more analytical sophistication, taking all the data to just one public cloud would create traffic congestion and increase the access latency. Using a single cloud may

BRAS3 VNF2 VNF3 VNF4 BNG1 DSLAM BNG2 Cloud1 PNF1 _Cloud3 Internet Aggr. Switch VNF1 DSLAM Core Router

also often result in a single point of failure leading to service failures because of cloud blackouts, which are not uncommon.

Additionally, the points of presence (PoPs) of even large public clouds may not be close to the carriers' subscriber clusters, and this would give rise to increased access latency. If the application calls for lower access latencies, then edge clouds closer to the subscriber clusters, offer a good solution. Carriers may also build their own private clouds, which they can customize and exercise more control over. This hierarchy of clouds – mobile-edge, private, and public – forms a multi-cloud system that can be designed to provide a combination of features like low latency, high storage, complex computations, lower cost, and better security.

5.3.3 Representation of the Tenant Profile

In this work, a cloud tenant (in our case, a carrier) profile is represented as a tuple <cN, v1, v2, …,

vm, p>, for each request. Here, v1, …, vm represent the VNFs in the order of traffic traversal in a

linear chain. The term cN is the native cloud for the tenant to which it is parented, and through

which its traffic enters an SFC. The desired packet rate is represented as p packet/second. Multiple tuples can be used to represent branched traffic flows. Other stipulations like latency threshold (Lth) are part of the SLA. All the requests of the tenant are consolidated to calculate the

required number of instances of each VNF and inter-VNF links of appropriate capacities. The cloud topology is represented by the graph Gc = (C, T), where C is the set of available clouds (c1,

c2, …, ck) and ti,j are the inter-cloud links. The CSP (or a cloud aggregator who integrates services

from multiple clouds) carries out the task of mapping service chains onto the available clouds to achieve optimal results for the carrier. In our case, optimality refers to the least-cost solution that meets the end-to-end latency threshold requirement.