An Intent-based Network Virtualization Platform

for SDN

Yoonseon Han∗ , Jian Li† , Doan Hoang‡ , Jae-Hyoung Yoo§ , and James Won-Ki Hong∗†
∗ Division
of IT Convergence Engineering, POSTECH, Korea.
[email protected]
† Department of Computer Science and Engineering, POSTECH, Korea.

{gunine, jwkhong}@postech.ac.kr
‡ School of Computing and Communications, University of Technology Sydney (UTS), Australia.

[email protected]
§ Ministry of Science, ICT and Future Planning, Korea.

[email protected]

Abstract—Currently, the Software Defined Networking (SDN) management/operation. Currently, most of the SDN controllers
paradigm has attracted significant interests from industry and support OpenFlow as an essential South Bound Interface
academia as a future network architecture. SDN brings many (SBI) according to the Open Networking Foundation (ONF)’s
benefits to network operations and management including pro- specification [1].
grammability, agility, elasticity, and flexibility. With SDN and
OpenFlow, one of the promising SDN protocols, software defined Network Virtualization (NV) is a networking technology
Network Virtualization (NV) techniques can be designed and that creates dedicated Virtual Networks (VNs) over a physical
implemented via flow table segmentation to provision independent infrastructure. With the help of NV, multiple tenants are able
virtual networks (VNs). In this paper, we propose an intent based to share the underlying physical network resources, and they
virtual network management platform based on software defined can operate their isolated virtual networks independently. By
NV. The objective of the proposed NV platform is to automate the
provisioning VNs over the physical network, network function-
management and configuration of virtual networks based on high
level tenant requirement specifications, called intents. The design ality is abstracted from its physical elements. NV technology
and implementation of the platform is based on ONOS, an open- has the potential to reduce significantly CAPEX and OPEX
source SDN controller, and OpenVirteX, a network hypervisor. for network and network service providers with its flexible,
The platform is designed to provide multiple VNs over the same on-demand, and scalable provisioning capability. A possible
physical infrastructure to multiple tenants. approach to NV is the slice-based NV whereby a slice of
Keywords—Software Defined Networking (SDN), Network Vir-
the network physical resources can be allocated to a VN by
tualization, Intent Framework, Virtual Network Management and segmenting OpenFlows flow tables into partitions.
Configuration, Virtual Network Embedding A major deficiency of the slice-based NV approaches is
that they require underlying network infrastructure to be con-
I. I NTRODUCTION structed using OpenFlow protocol. Futhermore, the configura-
tion and management process of each VN are still complicated
Software-Defined Networking (SDN) is a new networking
and time consuming because of the lack of generally available
paradigm which enables flexible and efficient network manage-
VN embedding methods and automated VN provisioning pro-
ment. The essential principle of SDN is to decouple network
cesses. Currently, to configure and manage VNs, administrators
control and forwarding functions, and leave each function in
have to deal with all technical aspects of networking such as
its individual network plane. In the context of SDN, all control
underlying protocols, addresses, topologies, control rules, and
related functions are moved to a centralized control plane,
etc. To overcome this complexity and problems, in this work,
hence optimal network control decisions can be made using a
we introduce the principles of intent-based management. The
global networking view. SDN also provides the ability to sim-
definition of intent is not standardized yet, but it is generally
plify network design and operations, with this ability, we can
perceived as business or system level policies (or higher level
deploy complex network policies. To summarize, SDN brings
specifications). Intents is independent from specific network
four major features such as programmability, agility, flexibility,
technologies and vendor specific features. Moreover, it allows
and vendor neutrality to network management domain. By
the administrator to use higher level abstraction by using
properly utilizing those features, SDN has been promised to
business or system level terminologies and concepts. With
reduce CAPEX by using cheap, open, commodity switches
intents, users only need to concentrate on specifying what they
and cloud computing for replacing expensive middle boxes
need, rather than how to realize or implement the need.
and to reduce OPEX by providing simplified and centralized
In this paper, we propose an intent based VN management
This work was supported by the ICT R&D program of MSIP/IITP, platform for SDN to overcome these problems. The funda-
Republic of Korea. [B0190-15-2011, Korea-US Collaborative Research on
SDN/NFV Security/Network Management and Testbed Build], and [B0190- mental idea is to automatically manage VNs from high-level
15-2012, Global SDN/NFV OpenSource Software Core Module/Function tenant requirements using intents. To be more specific, the
Development]. proposed intent-based NV platform addresses the following

978-3-901882-85-2 
c 2016 IFIP 353 ManSDN/NFV Full Paper
challenges: 1) using intent to express high-level VN require- directly programmed for the virtual elements to provide QoS.
ment specifications, 2) combining SDN and NV technologies Tenants can use their own specific controllers to control their
into a single framework, 3) automating the task of VN structure own VNs. Currently, available solutions include FlowVisor
composition and embedding. The platform will host multiple, [10], OpenVirteX [2], and FlowN [11]. However, the critical
independent, and isolated VNs, and support multi-tenancy. disadvantage of the software defined NV is that the physical
VNs belonging to different tenants may have different network network has to support SDN and OpenFlow.
configurations in terms of network address space, topology,
and may be governed by different policies. The proposed Another important related technology is Intent-based
platform is implemented on OpenVirtex network hypervisor mangement. Oxford dictionary defines “intent” as “an aim
[2] and ONOS SDN controller [3]. or plan or purpose.” The definition of intent for network
management is commonly perceived as business or system
level policies specified with common concepts and terminolo-
II. R ELATED WORK gies agreed by all related stake-holders. However, a clear
In this section, we focus on describing the overlay NV and concise definition of intent for network management has
and the software defined NV approaches that can be real- not been standardized yet. Several projects are proposed to
ized with SDN technologies. Most commercial NV solutions introduce intent for SDN application development and network
are based on overlay NV approach by leveraging tunneling management based on high-level requirements or management
or encapsulation techniques such as VMware NSX [4] and policies. Recently, intent-based interface has been pursued rig-
Microsoft Hyper-V [5]. Overlay NV approach can be further orously by IETF and major open-source project communities
categorized depending on whether the approach supports layer (ONF, ONOS and OpenDaylight) to provide a standardized
2 and layer 3 virtualization. Usually, to deliver packets, an intent-based northbound interface for SDN [3], [12]–[14]. The
ingress network device (switch or router) encapsulates packets specification methods was also developed by using language
by inserting an outer packet header indicating a specific virtual (e.g., NEMO [12], [15]) or policy graph (e.g., PGA [16]).
network instance ID (VVID). The encapsulated packets are
delivered to the destination according to forwarding rules, III. OVERALL P LATFORM A RCHITECTURE
and then, decapsulated to restore the original packets at the
egress network device. VXLAN [6] and NVGRE [7] are The proposed intent-based VN management platform is
two most representative overlay NV approaches that support designed to have a hierarchical architecture.The platform plays
layer 2 virtualization, while Generic Routing Encapsulation two roles which are 1) network hypervisor and 2) SDN
(GRE) [8] and Locator/Identifier Separation Protocol (LISP) controller. As a network hypervisor, the platform possesses VN
[9] are two most representative approaches that support layer management capabilities such as VN provisioning, modifica-
3 virtualization. tion, and removal, at the same time, it also provides interfaces
to relaying VN events and messages to external entities running
The advantages of the overlay NV approach include tenant specific applications. As an SDN controller, the platform
1) only network edges are involved in tunnel encapsula- provides network abstractions and control capabilities for both
tion/decapsulation, the remainder of the network remains physical and virtual networks. The overall architecture is
unchanged, 2) theoretically, unlimited number of VNs are depicted on Fig. 1. The design objectives are 1) to support
supported, 3) VNs are independent from the physical network multi-tenancy, 2) to provide network abstractions for applica-
topology and configuration, 4) VNs mobility can easily be sup- tion development, 3) to allow high-level tenant requirements
ported. As the overlay NV approach is based on encapsulation specification using intents, and 4) to support tenant specific
mechanism and tunneling, it also brings disadvantages. The controllers and applications by providing various interfaces.
main disadvantages include 1) Two separated networks, VN The platform has five layers: protocol adaptation, abstraction,
and PN, are maintained in terms of network services such as virtualization, virtual abstraction, and intent layer.
management, provisioning, and control, 2) it does not provide
mechanisms to provide to guarantee QoS, 3) it introduce high The protocol adaptation layer is responsible for processing
encapsulation and tunneling overheads, and 4) it incurs high protocol specific messages which are used to communicate
management complexity for both VN and PN at the same with physical hardware such as OpenFlow switches. The
time. To overcome these disadvantages, cloud platform such main roles of this layer are: 1) decoding protocol specific
as OpenStack provides several methods (such as Neutron) to messages and delivering them to proper providers located in
manage network resources. the abstraction layer, 2) managing communication channel be-
tween the controller and network devices, and 3) receiving the
With the introduction of SDN and OpenFlow technologies, requests from upper layers, encoding the request into protocol
it is possible to implement NV as an application or a service specific messages and transmitting to hardware devices. The
provided by an SDN controller via flow table segmentation. abstraction layer is responsible for abstracting protocol specific
This slice-based NV approach can support layer 1 - 4 net- concepts and hiding the details of underlying infrastructure.
work virtualization by matching appropriate packet headers. The abstractions can represent various elements and properties
Performance degradation caused by tunneling overheads is in a protocol-agnostic manner. Some representative abstrac-
eliminated. By inserting appropriate forwarding (flow) rules, tions are Device, Link, Topology, Event, Path, Flow, etc.
software defined NV approach can provide specific NV fea-
tures. Moreover, this approach introduces network abstractions The main responsibility of the virtualization layer is to
that can be utilized by management application such as virtual translate VN objects into physical objects by maintaining map-
links, virtual switches, and virtual routers. Within software ping information. The mapping information includes address
defined NV approach, corresponding physical hardware can be mapping and topology mapping. To support various strategies

354 ManSDN/NFV Full Paper

  '#%! ""'$

$$& #"'%# %& can be shared by multiple tenants with different VN views.
To support off-platform applications, a special application,
called relaying interface, is provided. The responsibility of
  
  
this application is to deliver messages or events from the
  virtual abstraction layer to external entities. This application
""'*%
+'"
#%'#("
"'%

enables the communication to tenant specific controllers and
 ,"

$$&
"'% (    applications similar to that in a traditional network hypervisor
such as FlowVisor [10].
"'"' "'"' #" ' "'"' #( %,
,% "% " #!$ % '#%
IV. I NTENT BASED VN M ANAGEMENT AND
%'( C ONFIGURATION
)) ) " ))"' )'
&'%'#" %#)% %#)% .
%#)%
%#)%
,% A. Definition of Intent
%'( -'#" #$# #,
%&&
.

 In this paper, an intent is defined as a high-level policy
!$$" !$$" !%
,%
specified in common concepts and terminologies, and inter-
&'%'#" ) " )"' '
pretable by both tenants (network service consumers) and
.
,% %#)% %#)% %#)% %#)% network service providers. However, this does not mean that
all policies are specified in a business-level or system level
%#'##
$''#" $" #*  
#*
( 
"&' %
terminologies. Our objective introducing the concept of intent
,% is to mitigate the network management obstacles. With intent,
#('#("
"'%
we expect that the knowledges that are required for managing
network is significantly reduced in application developers’

   perspective.
By using intent based interface to specify high-level re-
Fig. 1. The overall platform architecture design quirements, consumers (e.g. applications developers) can pro-
gram network services without concerns for technical specifics
and implementation details. Intent tends to be more concen-
to satisfy different user requirements, the platform design
trating on describing the outcome rather than the process
should consider to address multiple embedding algorithms as
that dictates the decisions toward the outcome. By summary,
plug-ins. In the platform design, a VN embedder plays the
intent is used to describe “what” the user want, but not
role of a matchmaker between resources and VN embedding
“how” to realize it (with respect to resources, constraints,
algorithms. Moreover, the actual embedding algorithms can be
and actions). From the user perspective, technology-agnostic
deployed as an off-platform component.
interfaces are more desirable. The intent based interface shields
The virtual abstraction layer provides network abstractions the complexity of underlying networks and allows users to
for tenant VNs. The fundamental difference between virtual focus on expressing their network service demands.
networks model objects and physical network model objects
is that virtual objects can be freely created and removed on B. Intent Specification for VN Management
the top of physical objects. However, physical objects have
strong dependency on physical network infrastructure in terms The first step of performing intent based management is
of protocol, topology, network addresses, and links. The usage to provide an interface to express high-level specification as
to consume virtual objects is same as the physical objects a form of intent. The way that is provided by the proposed
provided by lower abstraction layer after the creation of the platform is based on an intent framework, with which tenant
objects. applications can consume intent model objects. The underlying
design of the proposed intent framework is inspired by the
The intent layer allows tenants to specify their high level ONOS’s intent framework [17]. The pre-defined types of intent
requirements independent from low level details. The services, objects, which could be extended to address tenant specific
which are located in the intent layer, provide 1) intent objects intent types, are depicted in Fig. 2. The proposed platform
consumed by applications; 2) an intent confliction checking also provides a way to use intents with high level network
service between different intents to avoid conflicted and illegal abstraction objects (e.g., host, switches, link, and middle-
intents; and 3) an interface to the administrator to feed the boxes).
information that is used to interpret and translate the intents
into installable flow rules. The stored information can specify - VN Topology Intent: This type of intent only expresses
various entities such as human domain exerts and network the connectivity relationships among network nodes (i.e., hosts
management protocols provided by the protocol adaptation and virtual switches) without specifying VN behaviors. The
layer. The intent layer provides extended North Bound Inter- network behaviors such as packet forwarding or management
face (NBI) that is consumed by various applications. policies are managed by SDN controllers.
According to the location where the applications are exe- - VN Endpoint Intent: This intent allows to express high-
cuted, they can be categorized into two types which are on- level requirements for tenant’s endpoints without concerns
platform and off-platform applications. On-platform applica- of supporting network infrastructure. Because only endpoints
tions are developed with tenant-awareness using the abstrac- are involved in the intent specification, a tenant application
tions provided by the virtual abstraction layer. Therefore, they developer can entirely focus on describing the relationship
  





 



 



 














   





 
   



 



 




 





 
 

 
 

 


  




 


 





Fig. 3. Intent composition and conflict checking process


  
  
  
 

Fig. 2. Three basic types of intents provided by the proposed platform as conflicted intents (possibly through duplication). The intents
that encounter any conflict are required to be modified and
negotiated into composable intents.
between endpoints. Various relations between endpoints such
as 1 to 1, 1 to many, and many to many, are possible.
D. Intent Mapping and Installation
- VN Chain Intent: This intent type is an extended
Our VN model representation consists of a set of net-
intent type from the VN Endpoint Intent to chain intermediate
work model objects and network behavior abstractions. To
network behaviors. This type of intent expresses network
embed a VN into existing physical network resources, virtual
service chains by composing virtual network functions or
model objects should be bound to actual physical objects.
physical middle-boxes.
The network behaviors also require to be translated from
To specify intents accurately, we need to define the context virtual network behaviors into installable physical network
that describes what, when, and how the specified intents should behaviors. The objective of VN embedding algorithm is to find
be applied. To express a context, an intent object requires an optimal mapping between the VN and physical resources
four attributes; resources, conditions, priority, and instructions. with considering to satisfy a set of requirements defined by
Resources refers to a set of virtual network objects involved network administrator. To efficiently embed VNs according
in intent specification. Conditions are a set of criteria that to management objectives, the platform may adopt various
describes when the intent will be activated. Priority is used to algorithms introduced in [18].
determine the execution order of intents. Instructions refers to
To translate VN model objects into physical objects, the
a set of actions that to be applied to the packets which satisfy
platform should bind all virtual entities into concrete network
resources and conditions what have been defined.
nodes. This process can be supported by managing tenant’s
end-points. Discovering and managing end-points of VNs are
C. Intent Composition and Conflict Checking challenging because the terminologies are not standardized
After specifying intents for each tenant requirement, the among stake-holders yet. To provide a solution, in this paper,
next step is to aggregate all intents to construct the requested we introduce the concept of “vocabulary store” which refers
VN model which consists of a set of network objects and to a knowledge store that contains information from various
behavior abstractions. The intent composition process is re- sources include 1) human domain experts and/or network
quired to translate high level specifications into a network administrators, 2) host and network discovery and 3) man-
driven concepts and terminologies. First of all, we need to agement protocols. To efficiently querying the equivalence
identify and manage VN endpoints. This is needed to unify and between entities, a ontology based knowledge representation is
translate concepts, resources, and terminologies into a single adopted for the platform to support a semantic based inference
unified form agreed by all involved entities. To address this mechanism. This does not mean that “vocabulary store” simply
issue, [17] proposed an end-point discovery protocol, while generates new knowledge by using inference rules, but it
[16] used “label” to apply policies. Note that “label” contains supports checking and finding simple equivalent relationships
a group of pre-defined endpoints with the same set of policies. between entities.
As outputs of intent composition, VN topology, address space


and policies that are used for governing the VN are computed.    

The overall intent composition process is described in Fig. 3. 
 
   
  


During the composition process, the proposed platform can 


 
 

verify incorrect intents and detect conflicts between intents.
 

By inspecting intent resources, conditions, priorities, and in- 
 

 
 

structions, an intent composer can detect conflicts. First of
all, we need to identify the relationship between intents to
check whether they have any dependency on each other. If Fig. 4. The role of vocabulary store
any of two intents are interdependent, the platform will lookup
the priorities of intent to check whether the instructions are
E. Intent Lifecycle Management
mutually inclusive. For instance, if two intents share the same
pair of source and destination addresses, and the identical To manage intents specified from multiple tenants, we have
instructions are defined in each intent, then they are detected designed a Finite State Machine (FSM) that represents the state

356 ManSDN/NFV Full Paper

of each submitted intent. The FSM traces the entire lifecycle etc. However, ONOS and those models are originally designed
of each intent from intent submission to intent withdrawal. for managing a single physical network, rather than multiple
The main advantage of the state lifecycle management is VNs sharing a same infrastructure. To support multiple VNs,
that it allows the platform to determine whether the tenant we have implemented VN model objects by extending existing
requirements are satisfied based on their corresponding VN’s object model. The fundamental differences between the VN
status. Moreover, a recovery plan can be made if an abnormal model objects and existing model objects are 1) the addition of
state of intent is detected due to hardware failure or attack. attributes needed to identify tenants, 2) the target of operations.
The operations on virtual objects must be translated into the
V. I MPLEMENTATION operations on physical objects to be installed on the physical
devices by referring to mapping information.
In this section, we describe implementation details for
realizing the proposed platform design mentioned in previous To help translation process from virtual objects to physical
section. To accelerate our software development and make our network model objects, we also need to abstract network
contributions be available in public, we decided to adopt open operations as consumable objects such as forwarding, filtering,
source. To the best of our knowledge, OpenVirtex [2] and and drop. These behavioral abstractions make the translation
ONOS [3] are most suitable open-source projects. We adopted process to be simple and transparent. Fortunately, ONOS
those two open-source projects as base software stack. has already provided flow abstraction model named “Flow
Objective”. Originally, “Flow Objective” was proposed to hide
A. Virtualization Subsystem the forwarding behavior of OpenFlow devices, as different
OpenFlow devices have different pipeline implementation. To
To integrate ONOS and OpenVirtex, we extended SBIs and take advantages of flow objectives, our platform manages all
developed a dedicated service provider for OpenVirtex inside network behaviors as flow objectives from virtual network
ONOS. The roles of OpenVirtex provider are: 1) to manage model to physical network model.
communication channel between ONOS and OpenVirtex; and
2) to translate requests generated from OpenVirtex into ONOS
consumable format. Note that all information is exchanged C. Intent Layer
using JSON-RPC format, and to support conversion between To implement intent components inside the intent layer,
JSON-RPC messages and network objects, we developed a we developed VN intent interfaces and service components
component that serialize/deserialize virtual network objects like as an original ONOS intent framework. The goal of the
into a documents for device, link, switch, topology, and etc. ONOS intent framework is similar to our intent based VN
Moreover, we defined a VN manager component that supports management because it allows applications to specify their
OpenVirteX management operations within ONOS. Fig. 5 network control desires in a form of policy rather than mech-
shows the chain of OpenVirteX and ONOS to realize the anisms. However, there is a fundamental difference between
proposed VN platform. the intents for physical network management and the intents
for VN management. In the physical management case, intents
 
 are used to make high-level requests to consume the existing










network model objects. However, for VN management, the
 
 platform has to create virtual network model objects, not




consume. For example, from an intent that desires a connection
   
between host A and host B, the platform has to create virtual
objects representing virtual switches, links, and ports. To
  
  
  address this problem, we extended the existing ONOS intent
  

  

framework to include the capabilities to manage virtual objects
 
  
 
 
and operations.
   



D. Applications and Access Control

Fig. 5. The implementation of the proposed platform on the top of
OpenVirteX and ONOS Two types of applications are supported by the platform;
on-platform applications and off-platform applications. For
The main SBI of our platform is the OpenFlow between the the off-platform applications, the platform just needs to relay
tenant control planes and the physical network infrastructure. OpenFlow messages to external entities. However, supporting
Using this protocol, it is possible to deliver OpenFlow mes- on-platform applications is challenging because on-platform
sages generated by the physical OpenFlow devices to each applications may be shared by multiple tenants. For example,
tenant VN control plane. In this case, all VN messages are a routing application should be adopted to support multiple
delivered through the shared OpenFlow channel for all tenant VNs having different network topologies and addresses. In our
VNs. To identify destination VN of each OpenFlow message, platform, an application is a closed system that just provides
it is necessary to maintain mapping information. results in response to its input. Therefore, the state of each
VNs used as application’s input should be managed outside
B. Virtualization and Virtual Abstraction Layers the application domain. To support this design paradigm,
we have introduced a “VN context store” that stores tenant
ONOS provides a rich set of network abstractions in terms specific information about internal and/or intermediate data
of network model objects such as device, link, port, flow, and consumed by an application. By switching the context store, an

357 ManSDN/NFV Full Paper

application can be shared by different tenants without having management platform that allows management applications
internal states. to express their needs in a high-level representation, not
depending on specificic techologies ,and 3) an automated VN
One of the most challenging issues in realizing a VN management method can be developed from high-level intents.
management platform is to isolate VNs from different tenants.
An unauthorized access to virtual objects or resources from an The proposed VN platform is still under development. For
application that does not belonging to the owner tenant would future work, the top priority task is to finish the development
cause wrong operations and security concerns. To manage according to the described design. Furthermore, our design will
access privileges of each tenant, we have to deliver an access be refined to address the features mentioned in the Discussion
control feature. To realize the feature, we implemented a section. Once the implementation is completed, a comprehen-
component that intercepts messages between applications and sive evaluation of the functionalities and the performance of
service interfaces to ensure that they all belong to the same ten- the platform will be presented with several use cases. We also
ant, otherwise the messages will be dropped with error reports. plan to publish the platform as open-source software.
The implementation is similar to an ONOS subsystem, called
security-mode ONOS, that provides application authentication R EFERENCES
and access control services for ONOS northbound APIs.
[1] Open Networking Foundation., OpenFlow Switch Specification Version
1.0.0, Std., Dec. 31, 2009.
VI. D ISCUSSION [2] Al-Shabibi et al., “Openvirtex: Make your virtual sdns programmable,”
in Proceedings of the Third Workshop on Hot Topics in Software Defined
In this paper, we described the initial design and implemen- Networking, ser. HotSDN ’14. New York, NY, USA: ACM, 2014, pp.
tation of the proposed NV platform. Currently, the proposed 25–30.
VN platform is still under the development. This section [3] P. Berde et al., “ONOS: Towards an open, distributed sdn os,” in
introduces further issues for consideration. Proceedings of the Third Workshop on Hot Topics in Software Defined
Networking, ser. HotSDN ’14. New York, NY, USA: ACM, 2014, pp.
1–6.
A. Native Support of Virtualization Layer [4] VMware NSX, “The platform for network virtualization.”
[Online]. Available: https://www:vmware:com/files/pdf/products/nsx/
To accelerate the development process, we decided to VMware-NSX-Datasheet:pdf
reuse two separated open-source projects, OpenVirteX and [5] A. Velte and T. Velte, Microsoft Virtualization with Hyper-V, 1st ed.
ONOS. However, this initial implementation approach does New York, NY, USA: McGraw-Hill, Inc., 2010.
not produce optimal design to elicit high performance. A [6] M. Mahalingam et al., “Virtual extensible local area network (vxlan):
performance bottle neck may be introduced with the open- A framework for overlaying virtualized layer 2 networks over layer 3
ing of OpenVirtex and ONOS to external interfaces, as this networks,” RFC 7348, August 2014.
requires heavy workload to translate ONOS abstractions into [7] M. Sridharan et al., “Nvgre: Network virtualization using generic
JSON documents used in OpenVirteX API. To overcome this routing encapsulation,” Internet Draft, September 2011.
problem, we need to migrate OpenVirteX functions to support [8] S. Hanks et al., “Generic routing encapsulation (gre),” 2000.
virtualization layer in ONOS natively. [9] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, “Rfc 6830: The
locator/id separation protocol (lisp),” 2013.
[10] R. Sherwood et al., “Flowvisor: A network virtualization layer,” Tech.
B. Virtual Network Migration Rep., 2009.
The initial optimal mapping between virtual and physical [11] D. Drutskoy et al., “Scalable network virtualization in software-defined
networks,” IEEE Internet Computing, vol. 17, no. 2, pp. 20–27, 2013.
objects, however, may no longer valid due to VN creations
[12] S. Hares, “Intent-Based Nemo Overview,” Internet Engineering Task
and removals, and physical network infrastructure failures. In Force, Internet-Draft draft-hares-ibnemo-overview-01, Apr. 2016, work
addition, due to changes in the environment, a running VN may in Progress.
need to migrate. The platform need to support VN migration [13] Open Networking Foundation., “Project boulder: Intent northbound
to reflect the new optimal mapping. In this migration process, interface (nbi).” [Online]. Available: http://opensourcesdn.org/projects/
all VN states must be managed in a way that conserves VN project-boulder-intent-northbound-interface-nbi/
structure and configurations to prevent loss of information. [14] The OpenDaylight Project, Inc., “OpenDaylight - Technical
Moreover, a method is needed to reduce service down time Overview,” 2013. [Online]. Available: http://www.opendaylight.org/
project/technical-overview
to a minimum.
[15] Y. Zhang et al., “NEMO (NEtwork MOdeling) Language,” Internet
Engineering Task Force, Internet-Draft draft-xia-sdnrg-nemo-language-
VII. C ONCLUSION 04, Apr. 2016, work in Progress.
[16] C. Prakash et al., “Pga: Using graphs to express and automatically
In this paper, we have presented an intent based VN reconcile network policies,” in Proceedings of the 2015 ACM
management platform. The design objective is to automate VN Conference on Special Interest Group on Data Communication, ser.
management process based on intent that allows expressing SIGCOMM ’15. New York, NY, USA: ACM, 2015, pp. 29–42.
high-level tenant requirements. To realize the objectives, we [Online]. Available: http://doi.acm.org/10.1145/2785956.2787506
have described the high level design and implementation [17] R. Cohen et al., “An intent-based approach for network virtualization,”
in 2013 IFIP/IEEE International Symposium on Integrated Network
approach. The proposed platform is based on a hierarchical Management (IM 2013), May 2013, pp. 42–50.
architecture consisting of five layers to isolate specific level [18] A. Fischer et al., “Virtual network embedding: A survey,” IEEE Com-
of concerns from high-level requirements to installable flow munications Surveys Tutorials, vol. 15, no. 4, pp. 1888–1906, Fourth
rules. The proposed platform can bring several advantages, 2013.
1) an integrated NV platform that integrates seamlessly the
network hypervisor and the SDN controller, 2) an intent-based

358 ManSDN/NFV Full Paper