Towards a Network Abstraction Model for SDN

Evangelos Haleplidis • Jamal Hadi Salim •

Spyros Denazis • Odysseas Koufopavlou

Received: 15 September 2013 / Revised: 2 June 2014 / Accepted: 19 June 2014

� Springer Science+Business Media New York 2014

Abstract Recent advances in networking, namely the reemergence of network pro-

grammability with a new name, that of Software-Defined Networking (SDN) have

paved the way for a new approach to network datapath configuration. SDN provides an

abstraction model of the forwarding plane and separates it from the control plane using

open APIs. On the other hand, regarding network infrastructure, motivated by the

advances of virtualization, major operators created the Network Function Virtualization

(NFV) group, as an Industry Specification Group at the European Telecommunications

Standards Institute. NFV’s goal is to define how network functions such as firewalls and

load-balancers or any other data or control plane functionality in the mobile and fixed

network, can be virtualized and run as software on high-volume servers instead of using

specialized hardware. We argue that both SDN and NFV are part of a bigger networking

picture, that of the complete lifecycle of the network devices and therefore could take

advantage of the definition of a common abstraction model, both for the forwarding

model and for the network functions. Such a model will allow interoperability and

homogeneity, as well as one protocol, for control, management and orchestration of the

network datapath and the network functions respectively. This paper proposes, defines

and designs a reference Network Abstraction Model based on a building block approach

and demonstrates an initial proof-of-concept implementation.

E. Haleplidis (&) � S. Denazis � O. Koufopavlou

Electrical and Computer Engineering Department, University of Patras, Rio, Greece

e-mail: ehalep@ece.upatras.gr

S. Denazis

e-mail: sdena@upatras.gr

O. Koufopavlou

e-mail: odysseas@ece.upatras.gr

J. Hadi Salim

Mojatatu Networks, Suite 400, 303 Moodie Dr., Ottawa, ON, Canada

e-mail: hadi@mojatatu.com

123

J Netw Syst Manage

DOI 10.1007/s10922-014-9319-3

Keywords Software Defined Networking � Network Function Virtualization �Abstraction model � IETF � ETSI � ForCES

1 Introduction

Network programmability was the main objective of the two converged schools of

thought that dominated the networking research agenda in the mid-90s up until

early-00s: Active [1] and Programmable Networks [2] (A&PN). Current network

programmability has received a recent boost of attention and innovation with its

resurgence in the form of Software Defined Networking (SDN).

SDN [3] is an emerging network architecture where network behavior is defined

by software through open interfaces as a northbound interface and the network

control plane is decoupled from the forwarding plane and is programmable

southbound of the control plane via an open protocol. One of the key elements of

SDN required for the separation between the control and forwarding planes is an

abstraction of the forwarding plane.

In parallel to SDN and motivated by the advances of virtualization, at October

2012 some of the major operators got together at Darmstadt in Germany and drafted

the white paper for Network Functions Virtualization (NFV) [4]. In essence, as the

white paper clearly explains, these operators want to reduce their Operational

Expenses (OPEX) and Capital Expenses (CAPEX) by virtualizing network

functions and deploying them at will on high-end devices.

With the advent of cloud computing and virtualized infrastructure in the data

centers, elasticity amongst others in terms of network functions is important for both

OPEX and CAPEX for operators and service providers. However keeping track of

the lifecycle of virtualized network functions such as load balancers and firewalls or

any other data or control plane functionality requires orchestration, configuration

and management mechanisms while also need a way to integrate and deploy them

into the network.

Already in NFV there are discussions and work items, regarding necessary

abstractions for NFV, especially in the management and orchestration (MANO)

group. We agree and argue that there is indeed a need for a reference abstraction

model for network functions. Such a model would provide a point of interoper-

ability between Network Function developers and application developers, mimick-

ing the SDN separation, as well as with future network functions.

SDN and NFV may not immediately appear to be closely related, but we argue

that SDN and NFV are part of a bigger networking picture which should be dealt as

a whole, that of the lifecycle of network devices and therefore the network. The

lifecycle of a network device comprises of allocating resources to boot up a device,

the initial management of the device followed by continuous control and

configuration of the device’s datapath, ending with shutting down of the device

and releasing the allocated resources. SDN deals with the runtime control and

configuration of the device, while NFV deals with the rest part of the lifecycle.

J Netw Syst Manage

123

As an example of the interaction between SDN and NFV, the instantiation of new

network functions is under the auspices of NFV. On the other hand the network

function integration within the network, the automation of forwarding traffic to

newly instantiated network functions fall into the realm of SDN. While NFV can

work with traditional methods of network management, SDN will provide the

necessary tools for rapid deployment of NFV followed by its configuration. In this

respect, SDN and NFV become complementary to each other thus advancing

innovation further by providing a common model for manipulation of all network

resources, both the network functions and the network function infrastructure with

the required granularity respectively for management and control.

Cumulatively, seeing the need for an abstract reference model for both SDN and

NFV and anticipating as stated a tight correlation between SDN and NFV we argue

that there is a need for a unified Network Abstraction Model (NAM) that will

encompass both SDN and NFV, especially when we consider more granular packet

processing functions deployed on demand as virtualized network functions

composing a virtualized network infrastructure.

Having such a model will enable us to use a single protocol to control the

network devices’ lifecycle instead of having a menu of protocols and architectures

each for a specific work, e.g. one for infrastructure provisioning and another for

network provisioning. Additionally it will allow easier integration of new

forwarding capabilities and network functions and allow tools to span both SDN

and NFV allowing the creation of applications such as a global Network Manager.

Such a model would be required to be open, extensible and flexible enough in order

to describe elements from both SDN and NFV realms.

The paper proposes a unified reference NAM for both SDN and NFV and

presents an initial limited prototype as a proof-of-concept of the model. The paper is

structured as follows. In the next two sections we briefly introduce SDN and NFV.

We then describe our motivation and vision of the NAM. In the next section we

describe our instantiation of the NAM and next we show alternative frameworks

that we explored for our instantiation. Later we provide an initial proof-of-concept

implementation and conclude our paper with discussions and the future of our work

in this field. Part of this work has been presented at the 3rd Future Networks

Workshop at European Telecommunications Standards Institute (ETSI) [5].

2 Software Defined Networking

As discussed in the introduction, SDN is a fresh approach with a new term for an

older paradigm that of programmable networks. SDN in essence refers to the ability

of software applications to program the network and the network devices.

It is not coincidence that SDN and the concept of network programmability have

strongly reemerged with the advent of cloud computing. The lack of network

programmability in a clear and uniform approach is still a challenge that is being

addressed. SDN’s overall motivation, in addition to solving network cloud

provisioning is driven by desire for deployment, control and management of

networks, devices and services. SDN attempts to resolve this issue by providing

J Netw Syst Manage

123

interfaces for applications that demand specific requirements or services from the

network.

One of the key elements of SDN (Fig. 1) is the separation of control and forwarding

planes which is achieved by defining a common abstraction model of the forwarding

plane accompanied with one or more protocols to perform the control and

configuration. Such an abstraction would decouple the aforementioned planes and

allow faster innovation on both planes as well as interoperability between vendors.

On the control plane a network control system has a broader view of the network

and can perform control plane functionalities, such as routing. The network control

system can provide access via APIs to user defined applications.

There is an increased activity on research and development around SDN in the

networking community, with the most representative organizations, besides large

networking companies and new startups, being the Open Networking Foundation

(ONF) [6], IETF [7, 8], IRTF [9] and open source projects such as OpenContrail

[10], Floodlight [11] and the Linux Foundation’s OpenDaylight project [12].

3 Network Functions Virtualization

As stated in the introduction some of the major operators got together and drafted

the white paper for NFV [4]. The problem that NFV tried to address is threefold.

Firstly to reduce the costs of purchasing physical dedicated and expensive network

equipment such as firewalls. Such equipment may be sparsely used as the purchase

is based on perceived use and in effect underused, increasing the overall energy

consumption. Secondly to allow quick innovation and deployment cycles of new

devices to provide new services for users. Finally to reduce the overall cost of

management required for a large and dynamic number of such devices.

NFV’s solution is to virtualize network functions and deploy them as software on

virtual platforms, e.g. virtual machines (VM) or Linux containers (namespaces),

residing in high volume devices on a per-need basis. As stated in [4] NFV is

applicable to any data plane packet processing and control plane function in mobile

and fixed networks Such an approach will allow operators to design, implement,

Fig. 1 SDN framework

J Netw Syst Manage

123

deploy and destroy network functions at will and reduce energy consumption by

utilizing only the necessary amount of infrastructure resources. As such NFV must

provide flexibility, adaptability to new user requirements for services and elasticity.

NFV defines NFs [13] as ‘‘a functional building block (BB) within a network

infrastructure, which has well-defined external interfaces and a well-defined

functional behavior. In practical terms, a Network Function is today often a node or

physical appliance’’. This NF definition applies to a variety of packet processing

appliances, such as switches, routers, to more complex functions like firewalls or

intrusion detection systems to both wired and wireless networks.

With the plethora of NFs the definition of these functions will require a large

number of specifications and different APIs, unless a common abstraction model for

NFs is applied. Such a model will facilitate the creation of a unified framework for

developing NFs. The model must also be expressive enough to accommodate future

NFs.

As we discussed in the introduction, NFV also deals with the NFs management

lifecycle. Namely how these NFs are instantiated, integrated into the datapath once

deployed, configured and finally destroyed. In essence, with NFV once a NF is

deployed it must be integrated into the datapath in an automated and hassle-free

fashion in order for traffic to pass through and be processed by the NF.

To realize such automation in a heterogeneous network where devices are made

from different vendors and have different APIs, there is a need for an abstraction

model as well. The integrating and configuration of the NFV with the network is

related to the SDN paradigm.

There is significant ongoing work being done in NFV in the MANO group that

will provide a high-level framework as well as an information model for NFs [14].

According to [15] the MANO will address ‘‘End to end NFV network mapping,

instantiating VNFs at appropriate locations, keeping track of VNF instances

allocating resources, etc.’’ However such work is still in draft mode and prone to

changes.

Our approach is aligned with the current work at the MANO group and enhances

it twofold. Firstly by combining inherently SDN functionality under a common

model, allowing the Orchestrator to seamlessly integrate NFs into the network.

Secondly by providing a data model for defining network functions, accompanied

with a model-agnostic protocol to open up the network functions themselves.

Work towards orchestrating virtual infrastructure, as VMs in the network, is

currently being done in the OpenStack [16], Cloudstack [17], Eucalyptus [18] and

similar cloud management community, as well as by many vendors for their

proprietary data center orchestration solutions.

4 Network Abstraction Model

As discussed in the introduction, conceptually and technically, SDN and NFV can

be knitted together to provide a bigger picture of the network, that of the complete

network devices’ lifecycle. NFV will provide a flexible infrastructure substrate by

deploying new NFs and SDN will be responsible for configuring the infrastructure’s

J Netw Syst Manage

123

datapath. Additionally, as discussed before, packet processing appliances can be

realized as NFs, empowering NFV to be able to create virtual network

infrastructures and SDN to configure them, thus having one complete virtual

Network Manager.

Figure 2 depicts our view of how SDN and NFV currently map on network

devices. Above the devices, there are entities that are responsible for controlling and

managing the devices and the datapath on each respective plane via APIs. Each

entity may provide different APIs for user developed applications. User applications

can vary, ranging, but not limited, from control to management applications. The

dotted lines refer to management APIs.

A network device primarily has two distinct planes, the forwarding plane and the

operational plane, with the forwarding plane being responsible for executing the

datapath functionality on the packets and the operational plane being responsible for

keeping and manipulating the state of the device, e.g. device, port status.

A network device may be capable of either or both SDN and NFV. If the device

supports virtualization, there will be a hypervisor that will manage the resources of

the device and partition them as requested at various instantiations of network

devices.

SDN is responsible for the forwarding plane of a network device. Additionally

SDN may handle certain aspects of the operational state of the device that refer to

the forwarding plane, e.g. initiating and stopping the device or opening and closing

ports.

NFV on the other hand deals with infrastructure resource allocation, in essence

starting and stopping VNFs, i.e. what, where and how NFs are instantiated, managed

and destroyed. A hypervisor, for example, will be required to start/stop NFs, which

may reside on VMs and request and release resources.

Currently, NFV and SDN are being discussed by different organizations

independently [4, 6, 9]. Different APIs are being standardized between each plane

with little or no synergy. If the efforts were synchronous and since SDN and NFV

are complementary it will drive further innovation in networking.

Fig. 2 SDN and NFV

J Netw Syst Manage

123

Driven by motivation to unify SDN and NFV, we argue that a MAL would

facilitate the creation of one single framework. Being able to describe both SDN and

NFV under a single architecture, we avoid using multiple models and interfaces and

avoid having a menu of protocols and architectures which in turn will allow us to

have a cleaner design platform.

One single framework, model and protocol, in essence having the same semantics

for all the necessary operations, will in turn enable easier development of user

applications that span both SDN and NFV. Having such a model, we can apply a

unified abstraction layer, and even accompany it with a single protocol. With these

guidelines in mind and taking into consideration existing approaches for designing a

model for networking [19–22] we designed our NAM with three requirements.

Firstly as we would need to be able to describe new or existing NFs and connect

them on the fly, we designed the NAM to be based on a BB approach. New BBs can

be created and also existing blocks can be reused in order to build define, design and

deploy NFs. That led us to specify that the NAM had to be able to describe how

these BBs are knitted together.

Parts of the network device resources, such as the operational functions and the

hypervisor may appear not to be BBs in the sense that they are aggregated together

to perform a function. However we argue that there are simple, single blocks that

can be used to express manageable parameters of the respective parts using the same

model. We distinguish them only by name but treat them the same as the BBs. We

name operational blocks (OB) for the operational plane and hypervisor blocks (HB)

for the hypervisor.

For the second requirement, as we expect many variations of BBs that capture

SDN and NFV designs and capabilities, we require the NAM to be expressive

enough to be able to describe all envisioned modeled elements. Additionally the

NAM should be extensible enough to accommodate new blocks with little or no

changes to the model.

For the final requirement, since we want the NAM to be expressive and

extensible, we require that our NAM should provide sufficient information for the

interface between the controller and the network device to be model agnostic.

Therefore extensions to the model must not affect the design of the interface.

While possible to use more than one interface definition, namely protocols, based

on the same NAM, we argue that having one will simplify even more the design of

the Network Manager. However having a single protocol imposes an additional

requirement, that the protocol will satisfy the needs of both the control and

forwarding separation for SDN as well as for operational and management for NFV.

In Fig. 2 we classify two types of interfaces. The interfaces denoted with solid

line is namely the configuration API, primarily used for SDN, which requires fast

responses, high throughput and low latency as it will need to handle a large number

of packets per second. The interfaces denoted with dotted lines are used for

management, primarily used for NFV and do not have such strict limitations as they

are not required to make time critical updates and will be used less often. Therefore

if the common protocol satisfies the configuration interface it will be sufficient for

both.

J Netw Syst Manage

123

Figure 3 shows the results of our NAM design as well as the placement of the

network abstraction layer (NAL) that is based on the NAM. A network device has a

function based forwarding plane comprised of BBs aggregated together in a graph to

perform the required functions and an operational plane. As specified before, the

operational plane is responsible for the state of the device and specific with our

model we include the device’s supported blocks and the connection graph of the

BBs. Additionally a hypervisor may exist for devices that host virtual devices.

All blocks from each respective entity in the device are visible to the Network

Manager via one interface. We still depict both the configuration and management

interfaces, but we colored them the same to denote that they use the same protocol

albeit for different purposes.

The Network Manager can now view the network devices that comprise the

network and their datapath as a whole and can deploy, configure, control and

orchestrate as needed using one protocol. The Network Manager can also provide

APIs for user applications.

Fig. 3 Network Abstraction Model

J Netw Syst Manage

123

5 Network Abstraction Model Instantiation

We explored existing frameworks in order to instantiate our NAM as we will

discuss in Sect. 6. However the only framework that satisfied and exceeded all our

requirements is IETF’s Forwarding and Control Element Separation (ForCES) [23].

ForCES includes an object oriented model [21] based on an XML schema, to

describe the datapath in very fine detail, and a protocol [24] to operate on model

entities. ForCES network elements (NEs) are composed by two entities, the

forwarding elements (FEs) and the control elements (CEs).

ForCES models FEs, e.g. switches and routers, based on an abstraction using

distinct logical functional blocks (LFBs), which are interconnected in a directed

graph and receive, process, modify, and transmit packets. Using XML a designer

creates LFB classes which can then instantiate and connect them to a graph.

An LFB is comprised of input and output ports, components which are the

operational parameters visible to a CE, capabilities advertised to the CE, and events

that a CE can subscribe to. As expected, there is a direct 1:1 mapping between LFBs

and blocks in our model and we’ll use LFBs and BBs interchangeably for the rest of

the paper, including OBs and HBs.

The initial concept of the LFB was to be a block of encapsulated fine-grained

operation of the forwarding plane and performs a well-defined action or

computation on the packets passing through it, classifiers, shapers and meters

being examples of LFBs. However in its definition the ForCES model is powerful

and flexible enough not to be limited to the forwarding plane. The XML schema can

be used to define new LFB classes, each with its own customized set of parameters.

Therefore we argue and prove on our proof-of-concept section, that ForCES can

model entirely different operations on other planes as well, such as the service plane

[25]. Figure 4 depicts a modeling example of an FE as a graph of LFB instances.

Besides the fact that ForCES satisfies our basic requirement for the NAM,

ForCES comes along with two more important features. Firstly the LFB-based

model does not distinguish between physical and virtual devices; it treats them the

same. Secondly the protocol is agnostic to the model satisfying the protocol

requirement as well. Anything that is modeled with ForCES can be accessed with

the protocol.

Fig. 4 An FE described with the ForCES Model

J Netw Syst Manage

123

5.1 ForCES and Software-Defined Networking

As discussed in Sect. 2, one of the key requirements for SDN is the separation of the

forwarding from the control plane with a standardized protocol which is the initial

domain of ForCES. Figure 5 depicts one way of how ForCES can map into SDN

with a CE assuming the role of the network control system and the FEs are the

network devices.

Using SDN, integration of NFs with the datapath can be automated using the

necessary applications with control logic and the model of the required operational

parameters. For example, some initial operational parameters would be the FEs that

belongs to the same network of the new instantiated network function, how they are

interconnected and filter that direct traffic between these FEs. Having a process that,

once a NF in instantiated, then it would automatically re-align the connection of the

FEs and install the necessary forwarding rules to redirect the required traffic to the

new NF, would provide an automated approach for fast deployment.

5.2 ForCES and NFV

Using the ForCES model to define an NF would automatically give us the capability

to manage it using the ForCES protocol, since it is model agnostic. More

importantly, for ForCES it doesn’t matter if an LFB or FE is physical or virtual

making it fit for virtualizing NFs, making no difference if the NF is virtualized or

not.

There are four possible ways to define an NF using ForCES as depicted in Fig. 6.

Firstly (a) it could be defined as an LFB. Secondly, (b) it could be defined as a

series, or a chain, of LFBs. With the current ForCES mechanics LFB chaining is

limited within one FE. However work towards creation of a chain of LFBs that span

multiple FEs has already begun [26]. Thirdly (c) an NF could be defined as a whole

FE and finally (d) an NF could be defined as a series, or a chain, of FEs.

What remains to be answered is how a NF would be deployed on demand. There

are two possible cases, deploying a NF on a physical or on a virtual device.

Regarding the physical device, it depends whether the device actually has the

capability of deploying new functions or have the ability to dynamically alter the

LFB graph, e.g. a device has a fixed number of ports, it may not be able to

instantiate a new port LFB if there are now unallocated.

Having defined the NF as an LFB class or FE, ForCES has the ability, if the

device supports it, to instantiate and integrate a new FE/LFB to a device. Thus

instantiating a NF within a device, physical or virtual, is inherent in ForCES.

Another approach would be to group existing LFBs and transform the graph such

that it would perform the necessary function and direct traffic through the chain of

LFBs.

The same technique applies when NFs want to be deployed on a virtual device or

as a virtual device, for example a virtual router as a VM. In this case, there is a need

to abstract the hypervisor that spawns these VMs as an FE or LFB and that can in

turn be controlled by the same CE. The operational parameters of the hypervisor

could be for example, a table of network functions that are currently instantiated.

J Netw Syst Manage

123

Capabilities of the hypervisor could be for example, which FEs/LFBs and network

functions are supported and can be instantiated within a VM. Our initial proof-of-

concept at Sect. 7 is the definition and implementation of a hypervisor.

5.3 ForCES and NAM

Figure 7 depicts the overall architecture of the ForCES-based NAM that has been

discussed so far. Figure 7 relates directly with Fig. 3 with LFBs being the BBs, OBs

and HBs and the ForCES abstraction layer is our NAL. The Virtual Network

Function (VNF) is a network device.

Fig. 5 ForCES map on SDN

Fig. 6 Models of network functions

J Netw Syst Manage

123

The Network Manager has the same functionalities as we have already discussed.

The Network Manager could be centralized, distributed or even defined in any kind

of hierarchical architecture. The Network Manager could provide northbound APIs

to applications with ForCES semantics, for them to control and manage assigned

network functions.

We consider three examples of how a network function can be deployed and

integrated within the network, the first on existing hardware, the second on or as a

VM and the third a hybrid mode, where part of the NF is on hardware and part is on

a VM.

On existing hardware, the Network Manager has to locate devices that support

the NF by querying the devices of their capabilities using ForCES. Once it finds

appropriate devices, instantiate the necessary FE/LFBs by setting for example a row

in the array of an LFB that represents the graph and then configure the operational

parameters of the newly instantiated FE/LFBs. Finally configure the datapath to

direct traffic to the new NF.

On, or as a VM, the Network Manager must first instantiate the VM. It will have

to send a configuration command to the hypervisor LFB. By setting a value in the

array of instantiated VMs the hypervisor should interpret as a command to boot up a

new VM and instantiate it.

After the VM has been initialized the Network Manager would initialize the new

NF that would reside inside the VM and configure the datapath to direct traffic to the

new NF.

The third case is where part of the NF resides on a phycial device and the other

part of the NF resides on a VM. The Network Manager will have to boot up the VM

as in the second case and then start up part of the NF in the physical device similar

to the first case and interconnect these parts as shown in Fig. 8. As has been noted

Fig. 7 ForCES-based Network Abstraction Model

J Netw Syst Manage

123

before, this approach is currently being standardized by the ForCES working and is

expected to finish within this year.

Finally we elaborate with an example of why the use of one framework and

especially ForCES, will provide a common set of semantics for all necessary

operations. ForCES comes with a small set of protocol operations, or ‘‘verbs’’,

namely SET, GET and DELETE, REPORT and REDIRECT. These operations are

applied on parameters, or ‘‘nouns’’, defined by the model. Since new parameters can

be defined in a custom fashion allows for an unlimited amount of ‘‘phrases’’.

Thus, for example the NFV lifecycle, to instantiate a new LFB (or NF) instance, a

SET command on the table of instantiated LFBs would be issued accompanied by

data such as the LFB that needs to be instantiated as defined in [21]. A DELETE

command would destroy the LFB (NF) instance. Using the same semantics, a SET

command can be used to modify or create the parameters of the LFB instance. The

same semantics, SET and DELETE are used to create the graph connections

between instantiated LFBs as has been defined in [21]. A similar concept for graphs

of FEs can be extrapolated and defined as another LFB class.

While possible to use multiple protocols and models to achieve this goal, using

the same semantics provides a cleaner and easy to understand mechanics that lowers

the learning curve and avoids the need to develop and support many different

interfaces. This concept is not new, for example HTTP has similar semantics, e.g.

GET and POST. ForCES, however, is engineered specifically for the requirements

of SDN.

6 Related Work

In this section we explore other frameworks and approaches that could be used in

the design or implementation of the NAM. All the explored frameworks provided

part of the solution but not the whole, with the exception of ForCES. It could be

noted that the NAM can be instantiated using combinations of the following or other

frameworks as needed but that would lessen the advantages we gain by using only

one protocol.

6.1 OpenFlow

OpenFlow is a protocol designed to separate the control and the forwarding plane. It

was initially published from Stanford [27], but is currently being advanced by the

Fig. 8 Service chaining with different FEs

J Netw Syst Manage

123

ONF [6]. In [28] we presented a detailed side to side comparison between ForCES

and OpenFlow model and protocol. One of the main differences between OpenFlow

and ForCES is that with OpenFlow, an implementer can only control OpenFlow

specific datapath in presence of a large feature set a device provides whereas

ForCES can control the entirety of the device’s datapath.

While OpenFlow is suited for several aspects of SDN, specifically for flow

forwarding, the model is not extensible and therefore cannot be used to define and

configure NFs and does not satisfy our design principles. In addition, OpenFlow

cannot be used for management purposes and needs an additional management

protocol such as OVSDB [29] or OF-CONFIG [30].

6.2 NETCONF/YANG

NETCONF [31] is an IETF protocol that provides mechanisms to install,

manipulate, and delete the configuration of network devices. The NETCONF

protocol operations are realized on top of a simple remote procedure call (RPC)

layer. NETCONF can be considered a command line interface (CLI) replacement

for network devices.

Accompanying NETCONF is the YANG [32] data model. YANG is a data

modeling language used to model configuration and state data. As specified in [32]

‘‘YANG structures data models into modules and submodules. A module can import

data from other external modules, and include data from submodules. The hierarchy

can be augmented, allowing one module to add data nodes to the hierarchy defined

in another module’’. In essence YANG provides an extensible data model for

describing configuration of the device.

While NETCONF/YANG provide an extensible model/protocol with a BB

approach, however NETCONF is designed as an ASCII transfer protocol, namely

passing XML as plaintext, without any optimization for network traffic and YANG

is not an object-oriented model. Therefore NETCONF is not suited for the SDN

interface and would therefore not be suitable for our instantiation.

6.3 OpenStack

OpenStack [16], and similarly other cloud management frameworks [17, 18], is a

cloud operating system that controls large pools of compute, storage, and

networking resources throughout a datacenter. OpenStack provides a uniform and

holistic approach for managing the infrastructure of a cloud environment.

OpenStack is responsible for instantiating and interconnecting virtual infrastruc-

tures and therefore is suitable for the NFV role of the Network Manager.

OpenStack, however, is limited to cloud management and does not concern with the

managing internally the instantiated Network Functions.

On the other hand, OpenStack could take advantage of our approach by

implementing part of the NAL for NFV as plugins for its systems.

J Netw Syst Manage

123

6.4 OpenDaylight

OpenDaylight [12], and similarly other open source SDN controllers from other

companies and foundations [10, 11], is a new collaborative project under the Linux

Foundation umbrella, intending to create an open source framework, including code

and architecture of a common controller platform for SDN.

We see OpenDaylight similarly as with OpenStack, as part of our Network

Manager but for the SDN role. The abstraction layer for the SDN part, the term

OpenDaylight uses as SAL in the technical overview [33], is similar to our approach

but map it underneath into multiple protocols.

6.5 NFV

As discussed in Sect. 3, there is significant ongoing work being done in NFV and

especially in the MANO. Figure 9 depicts the current published NFV architecture

[15]. The unnamed interfaces are out of scope for the NFV ISG.

The architecture elements includes the virtualization layer that hides the

computing, storage and network hardware elements and provide a uniform approach

to the virtualized infrastructure manager to instantiate the respective virtual

resources, namely computing, storage and network. Furthermore the architecture

includes the network functions and their respective management systems (EMS).

The architecture also includes the MANO of the NFs and the NFV infrastructure.

The MANO is comprised of three components, the Infrastructure managers

responsible for managing the infrastructure resources, the VNF managers respon-

sible for managing the VNFs lifecycle and the Orchestrator which is in charge of the

orchestration and management of NFV infrastructure and network services.

Our approach closely follows the current work at the MANO group and merges

SDN and NFV. Currently the MANO group aims to develop an informational model

for NFs, with work towards a data model. This paper suggests a data model, the

ForCES model as well, that is suitable for both NFV and SDN.

Our service chaining description in Sect. 5.3 matches the architectural model of

an End-to-End network service defined in [15]. Our Network Manager matches the

NFV MANO modules, Orchestrator, Manager and Infrastructure Manager in [15]

with the addition of SDN capabilities. We describe the Service, VNF and

Infrastructure definition depicted in [15], using only the ForCES model.

Our approach matches the current discussion in the MANO group and extends

the work in the following two ways. First by utilizing SDN concepts on Network

Functions via the common abstraction model we provide the programmatic interface

between VNFs and EMSs and allow EMSs to be a split component, to be treated as

VNFs themselves that will be part of the created chain of VNFs. Secondly the

ForCES model does not distinguish whether an LFB, or NF, is virtual or physical

and is capable of handling the lifecycle of physical NFs as well, an item still under

discussion in the NFV ISG.

Therefore we argue that all interfaces between the NFV MANO and the rest of

the NFV infrastructure, along with the SDN interfaces and even the interfaces

between VNFs and EMSs are realized using the ForCES protocol.

J Netw Syst Manage

123

7 Proof-of-Concept

Our implementation focused mostly to demonstrate ForCES applicability on NFV,

as ForCES’s natural domain is SDN. We designed in Linux, using ForCES and

Mojatatu’s ForCES software development kit [34], a hypervisor LFB that would

enable the manager to specify for any number of VMs the following parameters:

• The target architecture, e.g. x86_64.

• The ID of the VM.

• The Linux Kernel version for the VM.

• Memory for the VM.

• Disk size of the VM.

We have successfully started up VMs with a predefined image of a Linux Ubuntu

12.04 setup and statically defined initial LFBs using a ForCES-based hypervisor,

proving that ForCES can indeed be used for NFV purposes.

A demonstration of the proof-of-concept was performed at the IETF ‘87 in Berlin

in the ForCES session [35]. In addition, we have begun the process of implementing

our NAM in the form of a proof-of-concept for the NFV ISG [36].

Fig. 9 NFV ISG architecture

J Netw Syst Manage

123

8 Conclusions

In this paper we presented our approach at designing a reference model of a unified

NAM that includes the concepts of SDN and NFV for managing the lifecycle of the

network and provide only one protocol. We then provided an instantiation using the

ForCES framework and provided initial implementation results as a proof-of-

concept.

We argue that such an approach will provide a more holistic approach in network

management and offer additional synergy between NFV and SDN as a common

model will enable using the same semantics to manipulate in a homogeneous way

network functions and their infrastructure both in terms of control, configuration and

management.

We have begun to work to further realize our Network Abstraction Model and in

particular providing results of the synergy between SDN and NFV as a Proof-of-

Concept for the NFV ISG and such results will be demonstrated at IETF 90th in

Toronto.

References

1. Tennenhouse, D.L., Smith, J.M., Sincoskie, W.D., Wetherall, D.J., Minden, G.J.: A survey of active

network research. IEEE Commun. Mag. 35(1), 80–86 (1997)

2. Campbell, A.T., De Meer, H.G., Kounavis, M.E., Miki, K., Vicente, J.B., Villela, D.: A survey of

programmable networks. ACM SIGCOMM Comput. Commun. Rev. 29(2), 7–23 (1999)

3. Open Networking Foundation: Software-Defined Networking: The New Norm for Networks, ONF

white paper (2012)

4. European Telecommunications Standards Institute: Network Functions Virtualisation, white paper

(2012). http://portal.etsi.org/NFV/NFV_White_Paper.pdf

5. ETSI Presentation on SDN and NFV (2013). http://docbox.etsi.org/Workshop/2013/201304_

FNTWORKSHOP/S06_SNDpart2/UNIofPATRAS_HALEPLIDIS.pdf

6. OpenNetworking homepage. https://www.opennetworking.org/

7. IETF ForCES charter: ForCES Charter (2013). https://datatracker.ietf.org/wg/forces/charter/

8. IETF NETCONF charter: NETCONF Charter (2013). http://datatracker.ietf.org/wg/netconf/charter/

9. IRTF SDNRG homepage. http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg

10. OpenContrail, open source project homepage. http://opencontrail.org/

11. Project Floodlight, open source project homepage. http://www.projectfloodlight.org/floodlight/

12. OpenDaylight project homepage. http://www.opendaylight.org/

13. European Telecommunication Standards Institute: Network Functions Virtualisation (NFV); Ter-

minology for Main Concepts in NFV, white paper, ETSI GS NFV 003 (2013). http://www.etsi.org/

deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf

14. European Telecommuncation Standards Institute: Network Function Virtualization (NFV); Man-

agement and Orchestration (2013) (work in progress)

15. European Telecommunication Standards Institute: Network Functions Virtualisation (NFV); Archi-

tectural Framework, white paper, ETSI GS NFV 002 (2013). http://www.etsi.org/deliver/etsi_gs/

NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf

16. Openstack homepage. http://www.openstack.org/

17. Apache cloudstack homepage. http://cloudstack.apache.org/

18. Eucalyptus homepage. http://www.eucalyptus.com/eucalyptus-cloud/iaas

19. Biswas, J., Lazar, A.A., Huard, J.F., Lim, K., Mahjoub, S., Pau, L., Suzuki, M., Torstensson, S.,

Wang, W., Weinstein, S.: The IEEE P1520 standards initiative for programmable network interfaces.

IEEE Commun. Mag. 36(10), 64–70 (1998)

J Netw Syst Manage

123

20. Denazis, S., Miki, K., Vicente, J., Campbell, A.: Designing interfaces for open programmable routers.

In: Stefan Covaci (ed.) First Annual International Working Conference on Active and Programmable

Networks, IWAN 1999, LNCS 1653, pp. 13–24. Springer-Verlag, Berlin, Heidelberg (1999)

21. Halpern, J., Salim, J.H.: Forwarding and Control Element Separation (ForCES) Forwarding Element

Model, RFC 5812 (2010)

22. Kohler, E., Morris, R., Chen, B., Jannotti, J., Kaashoek, M.F.: The click modular router. ACM Trans.

Comput. Syst. (TOCS) 18(3), 263–297 (2000)

23. Yang, L., Dantu, R., Anderson, T., Gopal, R.: Forwarding and Control Element Separation (ForCES)

Framework, RFC3746 (2004)

24. Doria, A., Salim, J.H., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., Halpern, J.: For-

warding and Control Element Separation (ForCES) Protocol Specification, RFC 5810 (2010)

25. Salim, J.H.: FEM Presentation in IETF 84. http://www.ietf.org/proceedings/84/slides/slides-84-

forces-2.pdf

26. Joachimpillai, D., Salim, J.H.: ForCES Inter-FE LFB, draft-joachimpillai-forces-interfelfb-03. IETF

(2013) (work in progress). http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03

27. McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S.,

Turner, J. OpenFlow: Enabling Innovation in Campus Networks (2008). http://www.openflow.org/

documents/openflow-wp-latest.pdf

28. Haleplidis, E., Salim, J.H., Halpern, J., Denazis, S., Koufopavlou, O.: Software-Defined Network-

ing—Experimenting with the Control to Forwarding Plane Interface (EWSDN ‘12) (2012)

29. Pfaff, B., Davie, B.: The Open vSwitch Database Management Protocol, RFC 7047. IETF (2013).

http://tools.ietf.org/html/rfc7047

30. Open Networking Foundation: OpenFlow Management and Configuration Protocol, OF-CONFIG

(2014). https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/

openflow-config/of-config-1.2.pdf

31. Enns, R., Bjorklund, M., Schoenwaelder, J., Bierman, A.: Network Configuration Protocol, RFC

6241. IETF (2011). http://tools.ietf.org/html/rfc6241

32. Bjorklund, M.: YANG—A Data Modeling Language for the Network Configuration Protocol

(NETCONF), RFC 6020 (2010). http://tools.ietf.org/html/rfc6241

33. OpenDaylight Technical Overview. http://www.opendaylight.org/project/technical-overview

34. Mojatatu homepage. http://www.mojatatu.info/

35. Part of IETF’s ForCES working group recorded session. IETF 87, Berlin (2013). http://recordings.

conf.meetecho.com/Recordings/watch.jsp?recording=IETF87_FORCES&chapter=part_5

36. Salim, J.H., Joachimpillai, D., Martin, J., Lopez, D., Haleplidis, E.: ForCES Applicability for NFV and

Integrated SDN, ETSI NFV PoC (2014). http://docbox.etsi.org/ISG/NFV/PER/05CONTRIBUTIONS/

2014//NFVPER(14)000046r2_ForCES_Applicability_for_NFV_and_integrated_SDN.docx

Evangelos Haleplidis received his B.Eng. from the Electrical and Computer Engineering Department,

University of Patras, Greece in 2002. He is actively involved in the standardization work in the IETF and

IRTF, specifically in the ForCES working group and the SDN research group. His current research

interests inlcude SDN and NFV. He has co-authored several papers in this area as well as a number of

RFCs and drafts in the IETF and IRTF.

Jamal Hadi Salim received his B.Sc. in Computer Engineering from the University of Toronto in 1994.

He has 20 years of experience in networking industry working on a variety of programmable networking

fields with origins in active networks. He is also a veteran open source contributor and maintainer in the

Linux environment. He is co-chair of the ForCES working group and technical advisor to the IETF

routing area. His current interests include all tenets of SDN and network virtualization. He has co-

authored a number of RFCs and drafts in the IETF.

Spyros Denazis received his B.Sc. in Mathematics from the University of Ioannina, Greece, in 1987, and

in 1993 his Ph.D. in computer science from the University of Bradford, UK. He worked in European

industry for 8 years, and is now an associate professor in the Department of Electrical and Computer

Engineering, University of Patras, Greece. His current research interests include P2P, SDN, and Future

J Netw Syst Manage

123

Internet. He is currently the technical manager of STEER EU projects. He has co-authored more than 50

papers.

Odysseas Koufopavlou received the Diploma of Electrical Engineering in 1983 and the Ph.D. degree in

Electrical Engineering in 1990, both from University of Patras, Greece. From 1990 to 1994 he was at the

IBM Thomas J. Watson Research Center, Yorktown Heights, NY, USA. He is currently Professor with

the Department of Electrical and Computer Engineering, University of Patras. He has co-authored more

than 100 papers in his field.

J Netw Syst Manage

123