Virtualizing Network and Service Functions:Impact on ICT Transformation and Standardization

Bhumip Khasnabish,Jie Hu,and Ghazanfar Ali

(1.Strategy Planningand Standards Development，ZTETXInc.，Morristown，NJ 07960，USA;

2.Strategy Planning Department，ZTENanjing R&DCenter，Nanjing 210012，China)

Abstract Virtualization of network/service functions means time-sharing network/service(and affiliated)resources in a hyper-speed manner.The concept of time sharing was popularized in the 1970s with mainframe computing.The same concept has recently resurfaced under the guise of cloud computing and virtualized computing.Although cloud computing was originally used in ITfor server virtualization，the ICTindustry is taking a new look at virtualization.This paradigm shift is shaking up the computing，storage，networking，and service industries.The hope is that virtualizing and automating configuration and service management/orchestration will save both capes and opex for network transformation.A complimentary trend is the separation(over an open interface)of control and transmission.This is commonly referred to as software-defined networking(SDN).This paper reviews trends in network/service functions，efforts to standardize these functions，and required management and orchestration.

Keyw ords network function virtualization(NFV)and chaining;service function virtualization(SFV)and chaining;network virtualization overlay(NVO);software-defined networking(SDN);networkingeconomics

1 Introduction

N etwork function virtualization(NFV)[1]-[6]has its origin in virtualized computing and storage services.However，there are many significant differences between NFV and virtualized computing and between NFV and virtualized storage.The primary objective of NFV is to share physical networking resources in a hyperspeed manner and minimizecommon overheads.

However，without any common application programming interfaces(APIs)or interoperable resource format，network infrastructure resources cannot be shared or efficiently used.Service providers also do not like proprietary APIs and solutions because network migration，transformation，and upgrade can beamajor issue.Fig.1 showsahigh-level architecture for separating network and service infrastructure resources，separating the control of these resources，and separating their usage by applications and services[7]-[9].

Both computing(e.g.DMTF[10])and networking(e.g.ETSI[1]，[2]，[5]，[6]，IETF/IRTF[11]-[15])standardization organizations have initiated activities based on use cases and aimed at developing NFV and integrating it into legacy networks.A number of proof-of-concept(POC)and testbed/integration activities have also begun in the laboratories of various service providers.These activities are being augmented by cost/benefit analyses and return on investment(ROI)calculations1For example，Amazon provides a tool for calculating the TCOor total cost of ownership(http://aws.amazon.com/tco-calculator/)for the Amazon Web Service(AWS)，and Microsoft Windows Azure also supports a similar tool(http://cloud-assessment.com/home/calc).The objective is to demonstrate reduction in growth and administrative costs for the same services when virtualized infrastructures are utilized instead of clusters of in-house physical(server，storage，CPEand networkinggears)resources.for the field deployment of NFV.Initial results，reported by the migration working groups of various service providers，customers and SDOs，are promising.

▲Figure1.High-level architecturefor network/servicefunction virtualization and software-defined networking.

2 Use Cases

2.1 Distributed Management Task Force

DMTF's Network Services Management(NSM)working group is focused on network-service profiles for routed and routing protocols，which ensure IPv4，IPv6 and layer-2(L2)connectivity that relates to the services provided by the network infrastructure to applications running in the cloud.Recently，DMTF NSM WG has developed a set of use cases，which we describe here.

2.1.1 Predefined Template-Based Network Configuration

In this use case，the end user is not concerned with the network topology(Fig.2).The network service required by virtual machines(VMs)can be predefined in network templates.For example，the cloud service provider can define a standard network topology and servicefor athree-tiered website.

To build a website in the cloud，a user can select a predefined three-tiered website and assign roles，such as frontend web server，application server or database server，to VMs.Once the VM roles are assigned，high-level network services can be automatically provisioned to these VMs.For example，firewalls may be set up between web servers and application servers or between application servers and database servers to control access of these servers.Furthermore，a load balancer acting as front-end web servers can be automatically configured to distribute external requests to VMs.

From a network provider's perspective，the network template and role assignment information provided by users should be mapped to configurations on physical network devices and VMs(when network services are provided by software).A cloud service provider should be capable of managing network topology，flows，and services so that the most frequently used network architectures can be deployed inside the virtual network environment.

2.2.2 Network Configuration Based on the Existing

Physical Network Topology of a User's Data Center A cloud consumer may have already deployed their own private network and server clusters.When users move their existing IT infrastructures to the cloud，services in the existing physical networks should also be moved to the virtual network so that VMs migrated from existing physical servers can work properly.In this case，users should first extract network service configurations，such as ACLs in firewall and policy settings in load balancer，from the deployed physical network(Fig.3).

To facilitate network migration，users may map their network configurations to a standardized format or template，e.g.network service model in CIMI interface or OVF-2 package.After the virtual network has been set up by the cloud service provider，a user can seamlessly plug in the VMs to the virtual network interfacesmapped totheir existingphysical network.

For each DMTFuse case，both administrative and operational costs can be significantly reduced.Initial setup and learning costs can be paid off in a few years，and thisjustifies the investment in a predefined template and virtualizing the existing physical networks.

As well as developing service profiles for DNS，DHCP and NetConf，the DMTFNSM working group is developing network policy management profiles for firewall，load balancer，QoS，routing，access control list，and network resource security group.The DMTF NSM working group is also developing network services management profiles for BGP，layer 3 interface，and routingservice.

2.2 ETSI/ISGNFV Use Cases

It is widely believed that NFV was created to virtualize functions of OSI Layer 4(transport layer)through to OSI Layer-7(application layer)asan alternativetousinghigh-cost，purposebuilt network appliancesand devices.

Consequently，the NFV use cases mostly arise as a result of the need for large service providers to save capex and opex.For example，capex can be saved by using commercial off-theshelf(COTS)equipment，and opex can be saved by seamless，automated network and service management.Automated network configuration means automatically configuring virtualized network entities for a desired service.Automated service configuration means automatically steering the flows(packet streams)to the most desirable service nodes through the most desirablenetwork path/route.

▲Figure2.Precondition for template-based network configuration[10].

▲Figure3.Precondition for network configuration based on existing physical network topology of a user'sdata center[10].

As described in[5]，NFV is current exploring the following use cases:

·network function virtualization infrastructure as a service(IaaS)

·virtual network function asaservice(VNFaaS)

·virtual network platformasaservice(VNPaaS)

·VNFforwardinggraphs(VFGs)

·virtualization of mobilecore network and IMS

·virtualization of mobilebase stations

·virtualization of thehomeenvironment

·virtualization of CDNs(vCDN)

·virtualization of fixed-accessnetwork functions.

The main objective is to implement the above use cases by chaining a set of abstracted network entities，called virtual network functions(VNFs)，that derive from the physical network resourcesviaavirtualization layer(Fig.4).

Using VNFs for just-in-time implementation of services provides the desired level of flexibility and deployment efficiency;however，automation/management resiliency and complexity requires further investigation.

Fig.5 shows how physical and virtual network functions can beconcatenated todynamically createand updatenew service.

The logical view of the set of VNFs touched by a service can beillustrated by theflow paths(packet streams)(Fig.6).

NFV recognizesthat maintainingaconsistent view of thestatuses of virtualized devices and VNFs across multiple administrative domains in order to trace and diagnose faults and meet end-to-end SLAs.

Other challenges include distributed implementation of a logical and centralized control system using COTS hardware;developing common APIs，authentication，and virtualization;and uniform，transparent benchmarking of performance，capacity，scaling，handover，system-integration(including software upgrade)，and resiliency acrossphysical network boundaries.

However，once these challenges have been dealt with，deployment and operation of virtualized CPE，Broadband Network Gateway，firewall/load-balancer，and address translator(IPv4 to IPv4/IPv6/name-or-content-based address)will be flexible and cost-effective.Service providers are expected to reduce both infrastructure costs and operation costs once provisioningand capacity adjustment areautomated.

▲Figure4.The NFV concept:end-to-end network servicethrough chained VNFs[6].

2.3 IETF and IRTFUse Cases

▲Figure5.NFVphysical view:Virtual network function forwarding graph[5].

▲Figure6.NFVlogical view of virtual network function forwarding graph[5].

The first bar BoF on Cloud Computing，Networking and Services was held during IETF-87 in March 2010[11].Since then，a number of groups have been created within IETF and IRTF to discuss network virtualization.The most important of these are the Network Virtualization Overlays(NVO3)working group[12]，System for Cross-Domain Identity Management(SCIM)working group[13]，and the Software-Defined Networking Research Group(SDN-RG).

The main focus of IETF NVO3 working group is to support multi-tenancy，which has become a core requirement of data centers(DCs)，especially data centers that support virtualized hosts and VMs.The NVO3 working group will investigate the interconnection of DC virtual private networks(VPNs)and their tenants with non-NVO3 Internet-protocol-based networks to determine whether any specific work isneeded[12]-[15].

IETFNVO3 use cases are focused on DCnetwork virtualization and its applications.DC virtualization use cases include DC virtual network(VN)access via Internet and DC VN and Enterprise site interconnection via service provider's wide area network(WAN).Use cases related to DC network applications include support for multiple technologies and applications in a DC，tenant network with multiple subnets or across multiple DCs，and virtual data centers(VDCs)[12].These use cases focus on virtualizing access，networking，and tenant systems within a DCin order to create virtualized DCs.The objective is to save both fixed costs and operational costs for DCbased services as well as providing the desired level of flexibility.

The main focus of the IETF SCIM working group is to standardize methods for creating，reading，searching，modifying，and deleting user identities and identity-related objects across administrative domains.The goal is to simplify common tasks related to user-identity management in services and applications[13]，[14].

The use cases of IETF SCIM working group[13]include cloud service provider to cloud service provider flows as well as enterprise cloud subscriber to cloud service provider flows with an emphasison the followingscenarios:

·changeof the ownership of an entity(e.g.afile)·migration of identities

·singlesign-on(SSO)service

·provisioning of user accounts for a community of interest(CoI)

·transfer of attributesto arelying party web site

·notification of changes.

Here again，the objective is not only to provide flexibility but also to offer a desired level of security across different physical/virtual administrative domains without incurring excessiveinfrastructureand operationscosts.

The SDN-RGof IRTFprovides a forum for researchers to investigate key problems in software-defined networking(SDN).SDN-RG investigates SDN from various perspectives with the goal of identifying approaches that can be defined and used in the near term and to identify future research challenges.Key areas of interest include solution scalability，abstractions，and programming languages and paradigms that are particularly useful in thecontext of SDN[15].

The main focusof SDN-RG[15]isadaptingthenetwork configuration at the speed that service development requires within a mixture of legacy and advanced networking where operation and debugging are becoming increasingly complex in enterprise，data center，and service provider networks.The use cases include the following areas:network description languages，abstractions，interfaces and compilers including the methodsand mechanismsfor(on-line)verification of both configuration and operation of network/nodefunctions.

3 Reference Framework Architecture

3.1 DMTF

In modern data centers，multiple network and service elements，such as firewalls，routers，AAA servers，DNS，QoSmanagers，and load balancers exist in LANs and SANs，both of which can be used to provide advanced network services.These elements may be implemented as virtual appliances or traditional dedicated devices and applications.For unified management access to such network and service elements，we introduce virtualized networking.We look at the externally manageable functionality of such entities abstracted from their actual realization.

DMTF NSM working group focuses on developing specifications that help present a unified management view of the virtualized networking，services and their components to both cloud consumers and providers.

In a virtualized network，there are several challenging network-related problems，including configuringfor network topology and service deployment，and configuring for physical network hostingin avirtualized environment.

3.1.1 Virtualized Networking Components

Fig.7 shows a high-level schematic for abstracting network elements in order to expose themasthe virtualized network entities(VNEs)for management.

The main components of virtualized networking are:physical and virtual network elements/entities，VNEs，and API for VNEmanagement(Fig.7).

3.1.2 Network Entities

Network entities include routers，firewalls，AAA servers，DNS，and load balancers，all of which can be interconnected to support network services.Such entities can be realized both as physical devicesor virtual appliances.

A common mechanism is needed to virtualize these generic network entities and achieve seamless interoperability.Once these generic network entities are virtualized，the VNEs can be exposed through an open API so that various applications and servicescan manageand usethem.

▲Figure7.Network entities(resourcesand services)abstraction,virtualization and management[10].

3.1.3 Virtualized Network Entities

VNEs are the abstraction of physical network entities and the network entities realized as virtual appliances.VNEs can be flexibly combined to support virtualized networking services.

These VNEs can be exposed via a management API to the upper management layers.The management API can be used to create，assign，monitor，update，and releasethe VNEs.

3.2 ETSI/ISGNFV Architecture

The ETSI/ISG NFV[1]，[2]，[5]，[6]architecture identifies functional blocks and the main reference points between these blocks.The main functional blocksare:

·VNF

·element management system(EMS)

·NFV Infrastructure，including hardware and virtualised resources，and virtualization layer

·virtualized infrastructure manager(s)·orchestrator

·VNFmanager(s)·service，VNF and infrastructure description

·operation support systems(OSS)and business support systems(BSS)

Fig.8 shows the NFV architecture with functional blocks and reference points.The reference points that are shown by solid lines are potential targets for standardisation.Reference points Vn-Nf and Ve-Vnfm are of interest in terms of SDN controller NBI becausetheseare involved in lifecycle and portability management of VNFs.

For reference point Vn-Nf(VNF to NFVI)，Puppet，Chef OpenSource driver，and configuration file management(IETF NetConf)may be useful[7]along with VM Manager MIB(currently beingdiscussed in IETFOPSA WG).

Reference point Ve-Vnfm(VNF.Environment to VNF.Manager-Orchestrator)needs to support a mechanism for a distributed and centralized VNF environment to request scale out/in，up/down may use extensions to OpenSource cloud computing APIs(e.g.CloudStack，extensionsto OpenStack).

For NFVI to VIM(reference points Nf-Vi and/or Or-Vi and/or Vi-Vnfm)，we may need extensions to 1)OpenStack for VMM Configuration Management，2)IETF(OPSAWG)VM Manager MIB，and 3)DMTF Open Virtualization Format(OVF).In addition，special purpose plugins and/or adaptors to OpenStack Neutron can be used in to expose the northbound APIsof ONF.

3.3 IETF and IRTF

IETF NVO3 WG is developing network virtualization overlays framework，and SCIM WGis focusing of schema and protocol development for a set of cross-domain identity management usecases.

Fig.9 shows the network virtualization edge(NVE)referencemodel from IETFNVO3 WG[12].

▲Figure8.ETSI/ISGNFVreferencearchitecture[1],[2],[5],[6].

▲Figure9.Generic network virtualization edgereferencemodel（IETFNVO3 Ref.Draft[12]）

One or more virtual network instances(VNIs)can be instantiated on an NVE.A tenant system interfaces with a corresponding VNI via a virtual access point(VAP).An overlay module provides tunneling overlay functions that include encapsulation and de-capsulation of tenant traffic，tenant identification，and mapping.Some NVE functions，such as data plane and control plane functions may reside in one device or may be implemented separately in different devices.NVE functions can also be hierarchically implemented，e.g.an end device can act as an NVE spoke，and an access switch can act as an NVE hub.

The SCIM WG is currently developing use cases，management protocol，and management core schema.The objective is to develop the core schema and interfaces based on HTTPand REST.

At IETF87 in July 2013 and IETF88 in November 2013，the IETF hosted the Network Service Chaining(NSC)and Service Function Chaining(SFC[14])BoFs with the objective of supporting the implementation of use cases that ETSI/ISG NFV is(or will be)putting forward to industry.The proposed milestones for SFCinclude developing a framework so that the requirements for information model，encapsulation protocol，control plane，management information base，and IETF protocol adaptation/updatecan bedetermined.

The SFCarchitecture includes flow/packet classifier and appropriate NBI based control of packet/flow path by encapsulating the path information in the header of the flows/packets.These will reduce the number of hardware devices in the path of serviceflowsand result in cheaper services.

4 Service-Level Agreement in Virtual Environments

When virtualized network and service functions are used，it may be very difficult to maintain a consistent end-to-end SLA.The TM Forum has recently published a document[16]called Enabling End-to-End Cloud SLAManagement that emphasizes a set of business considerations and architecture design principles for supporting end-to-end cloud SLA management.The main barriersidentified in that document are:

·lack of asinglepoint of authority/accountability

·lack of integration of the service models and dependencies of various infrastructure and platform providers，and lack of interoperability，includingbrokering

·lack of consistent monitoring APIsand reportingtools

·lack of uniformity between business and service-level objectivesand their correlation with the SLA

5 Regulatory and Security Requirements in Virtual Environments

There are many new security and regulatory requirements for both enterprise and carrier servicesthat use virtualized network and service functions.These requirements are mainly related to data，and information and knowledge-base security，as discussed in a recent IETF draft[17].These arise from lack of mandatory application security in protocols.Other gaps include

·systemssecurity and new requirements

·network security and new requirements

·mobile security and new requirements

·physical security and new requirements

·OAMsecurity and new requirements

DMTF is also working[18]with the Cloud Security Alliance(CSA)to address many of these issues and develop an audit process and trust models that are suitable for virtual network/service functions.

6 Interoperability in Virtual Environments

One of the main impediments to using virtualized network and service functions across different administrative domains is that the network and service functions(resources)must be exposed and orchestrated through the same interface.Thus，it isnecessary tohaveeither acommon APIor abstract thedifferences between the APIs in order to support seamlessorchestration and interoperability.

Deltacloud[19]offers an API based on Representational State Transfer(REST)，which supports an alternative to SOAPbased web services protocols.This API abstracts the differencesbetween clouds.It offersthefollowingthreefront-ends:Classic Deltacloud，DMTF Cloud Infrastructure Management Interface(CIMI)[20]，and Amazon EC2[21]，and supports all of the other major Cloud serviceproviders.

DMTF's CIMI allows interoperability between a cloud consumer and any cloud providers which supports standard CIMI interface for managing a cloud infrastructure.The interface uses REST-full HTTPto send and receive messages.These messages are formatted by using either Java Script Object Notation(JSON)or XML.

7 Conclusions,Recommended Action and Future Research

It is widely believed that the following technical trends will be dominant in the ICT industry in the foreseeable future:1)virtualized network and service functions，2)automated configuration and service management/orchestration，and 3)separation(over an open interface)of control and media forwarding/transmission，which isalsoknown as SDN.

Service providers，including enterprises，campuses，Internet，and common wireline and wireless/mobile carrier，are jumping on the bandwagon.The objective is to save capex and opex and make the network infrastructure more agile so that any new service can be introduced without needing to spend significant money on network resources.However，the following need to be addressed before there is any measurable benefit fromdeploying these new technologies:

·interoperable virtualization of network and service functions(i.e.interoperability acrossmultiplehypervisors)

·visualization of virtualized network and serviceresources

·multidomain management(discover，add，move，change/update，release)and orchestration of network and service functions to dynamically create network and service chains and graphs

·lifecycle management of virtualized network and service functions

·end-to-end management of service-level objective(SLO)and service-level agreement(SLA)by automatically monitoring overloads and failures and recovering from these.Standard distributed resiliency and efficiency management methods may bevery useful for thispurpose.

·authentication and security management for virtualized network and service functions.Standard management/orchestration capabilities may be necessary for reliable，secure management of connectivity over multiple administrative domains.

·Maintenance of geographical boundaries for using virtualized resources in support of privacy，secrecy，and Regulations

Over the next decade，service providers，ICTequipment and solution providers，academics，and SDOs will work together to support seamless virtualization，automation，and separation of control and mediatransmission acrossnetwork infrastructures.