Вы находитесь на странице: 1из 102

MASTER THESIS

Thesis submitted in partial fulfilment of the requirements


for the degree of Master of Science in Engineering at the University of
Applied Sciences Technikum Wien
Degree Program MTI

Remote Management of a Software


Defined Network with Mobile
Application using REST API of Cisco
APIC-EM Controller.

By: Mark Uzsoki, BSc

Student Number: ti16m007

Supervisor 1: Ing. Thomas Gerbafczits, MSc, BSc

Supervisor 2: Dipl.-Ing. Thomas Zeitlhofer

Vienna, 30 May 2018


Declaration of Authenticity
“As author and creator of this work to hand, I confirm with my signature knowledge of
the relevant copyright regulations governed by higher education acts (see
Urheberrechtsgesetz/ Austrian copyright law as amended as well as the Statute on Studies
Act Provisions / Examination Regulations of the UAS Technikum Wien as amended).

I hereby declare that I completed the present work independently and that any ideas,
whether written by others or by myself, have been fully sourced and referenced. I am aware
of any consequences I may face on the part of the degree program director if there should
be evidence of missing autonomy and independence or evidence of any intent to
fraudulently achieve a pass mark for this work (see Statute on Studies Act Provisions /
Examination Regulations of the UAS Technikum Wien as amended).

I further declare that up to this date, I have not published the work to hand nor have I
presented it to another examination board in the same or similar form. I affirm that the
version submitted matches the version in the upload tool.”

Place, Date Signature


Abstract

Software Defined Networking (SDN) is a new approach that offers evolutional changes to
address current challenges of information networks. Separating the control logic of the network
from the underlying forwarding function of network devices introduces the possibility to
program networks. This separation simplifies network management and facilitates network
evolution. Not only does the unseparated architecture cause traditional IP networks hard to be
managed, but also lacks of a Graphical User Interface (GUI) to provide perceivable and instant
intervention capabilities. Representational State Transfer Application Programming Interfaces
(REST APIs) connected to either SDN controller or individual devices might revolutionize
Network Management, since this mechanism enables to overcome present limitations of
traditional networks. This thesis focuses on the simplification of network management of SDN
architectures through the development of an Android software application that is built upon a
REST API. As mobile applications have become an essential part in business life, it is
important to take mobile network management applications into consideration in order to
manage networks efficiently or gain information about them this work implements an empirical
approach by the development of a mobile application and by the analysis of its usefulness and
advantages over traditional methods. The implementation of the application relies on a
reproducible environment based on emerging network virtualization software in order to ensure
future work in this field. The system tests show that the application fulfils its required functions
and helps network operators obtain substantial information about forwarding devices and
topology from the network. Moreover, the application is able to change network path
preferences on a per-application basis. The analysis also indicates the possibility of time-
efficient network operation.
Acknowledgements

I would like to express my special thanks of gratitude to my Supervisor (Ing. Thomas


Gerbafczits) being meticulous, tolerant and not letting me produce faint work and encouraging
me at dark hours. Also to my first contact at the Hungarian Cisco (Fulajtár József) who is the
man behind the idea and my “Software Defined Network Spiritual Leader”. They both gave me
the opportunity to do this wonderful little application on the topic (Remote Management of a
Software Defined network with Android Application cloud network management using REST
API of Cisco APIC-EM controller), and also helped me in doing a lot of Research and reading
tons of paper. Secondly I would also like to thank my lovely wife (Varga Petra) and children
(Bendegúz and Zoé) bearing my change of moods during this project, and abide the lack of
helping hand around the family. I am sending my deepest gratitude to my friend (Székely Zsolt)
to show me the way of Android Programming. Not to mention my precious English teacher
(Lengyelfi Orsolya) who corrected all my mistakes and gave me hope by offering her
companionship, laughter and knowledge.

2
Table of Contents
1 Introduction............................................................................................................. 5

1.1 Problem Definition .................................................................................................. 5

1.2 Goals...................................................................................................................... 6

1.3 State of the Art ....................................................................................................... 7

1.4 Applied Methodology .............................................................................................. 8

1.5 Research Questions ............................................................................................... 9

1.6 Structure................................................................................................................. 9

2 Theoretical background ........................................................................................ 10

2.1 Software Defined Networking ............................................................................... 10

2.2 REST API (Representational State Transfer)........................................................ 24

2.3 Android Studio ...................................................................................................... 32

3 Test Environment ................................................................................................. 33

3.1 VMWARE Environment ........................................................................................ 35

3.2 EVE-NG ............................................................................................................... 36

3.3 APIC-EM .............................................................................................................. 40

3.3.1 Installation of the APIC-EM ........................................................................... 40

3.3.2 Explanation of IWAN Application for APIC-EM .............................................. 41

3.3.3 Setting of APIC-EM and IWAN with the Test Environment ............................ 43

4 Application Functions ........................................................................................... 46

4.1 Extraction of inventory information ........................................................................ 47

4.2 Drawing of network topology ................................................................................ 48

4.3 Change of Application Path Preference ................................................................ 48

3
4.4 Development of application functions ................................................................... 49

4.4.1 REST APIs ................................................................................................... 49

4.4.2 Android Studio .............................................................................................. 59

5 Presentation and verification of application functions ............................................ 67

5.1 Inventory Function ................................................................................................ 67

5.2 Topology Function ................................................................................................ 77

5.3 Application Path Preference Function ................................................................... 83

6 Conclusion ........................................................................................................... 89

6.1 Future Development ............................................................................................. 89

6.2 Economic considerations ...................................................................................... 90

7 Bibliography.......................................................................................................... 92

8 List of Figures ....................................................................................................... 97

9 List of tables ....................................................................................................... 100

4
1 Introduction
Network Management is an important part of Information Technology Networks. Having the
adequate software solution with the right purpose is a powerful tool in hand. New opportunities
regarding network management provided by Software Defined Networking (SDN) such as
abstraction of network function, full manageability of networks instead of partial management
and the standardization of management interfaces with Representational State Transfer
Application Programming Interfaces (REST API) play an important role in Network
Management nowadays. This thesis intends to show the Remote Management of a Software
Defined Network with an Android Application using the REST API of a Cisco APIC-EM
Controller.

1.1 Problem Definition

Networks do not operate as static environments. For keeping networks in a proper


condition, network-operators usually adjust link weights, change traffic schemes, migrate
virtual computers and update routing configuration. These updates and subsequent
maintenance steps need precaution. Otherwise, issues such as forwarding loops, congestions
and network policy violations will appear during maintenance or update procedures. It seems
that traditional networks nowadays become too complex to be maintained, influenced or
queried. Therefore, this process needs a great deal of a well-trained engineer time and causes
has a relevant financial impact. A research has shown [1] that about 20% of network faults
derive from planned maintenance.

Furthermore, the network outage during updates frequently lasts long [2], since 30% of the
packet losses were suffered after dynamic routing updates. It is impossible to ignore the issues
while network update is on, because customers’ needs take priority. Suffering delay at financial
trade, online shopping, or any network error that affects the quality of service (QoS) of the
network might cause issues. For example, a paper [3] calculated that Amazon would loss 1%
of sales in every 100ms latency. Research [4], [5] also shows that highly trained engineers
dealing with traditional information networks are hard to finance hereafter and increase the
overall business expenditure significantly. These papers demonstrated that the traditional
approach of receiving data from a network or changing its parameters takes too much time
and is expensive as well.

Software-defined networking (SDN) is a developing networking approach that gives the


opportunity to overcome the previously mentioned limitations of network infrastructures [6].
SDN approach has many advantages. For instance, the control logic is transferred to an

5
external device named SDN Controller. Its purpose is to run server services that provide
abstraction to assist and program the data forwarding devices (switches, routers etc.). This
kind of network is programmable via software applications using standardized interfaces on
the top of the SDN controller, which in turn modifies the underlying devices also through
standard interfaces and protocols.

These interfaces are called Northbound Application Programming Interface (Northbound


API) and Southbound API. This architecture is less error is prone when changing network
policies compared to traditional device configuration methods. Network Management
Applications connected to SDN controllers running on tablets or laptops might face the
mentioned problems above. Therefore, this paper intends to demonstrate the method of
building such an application for the management of SDNs from the scratch and deals with
related technologies necessary for the implementation of an overall solution. It also intends to
point out the economic impact of the usage of such applications.

1.2 Goals

The main goal is the development of a Network Management Android application, which is
able to query and influence a network through a Northbound API called Representational State
Transfer API (REST API) using JavaScript Object Notation (JSON) format. The application
accomplishes the following functions: List Inventory, Display Topology and Change Application
Path Preference. The objective of the first function 'List Inventory” -is to collect inventory data
with a single click on a mobile device.

The second function “Display Topology” intends to display the topology of the network
managed by the SDN controller. Will it not only display the topology but also will show
connection information between devices like IP addresses and the names of the connected
interfaces.

The last function “Change Application Path Preference” allows the user to change three
application classes’ path preference. The three classes are “net-admin”, “browsing” and “file-
sharing”. In order to reach the main goals it is also necessary to demonstrate how REST API
requests and responses work and in what way they can be bonded together with the
developing language.

6
1.3 State of the Art

Modifying and querying techniques of networks can be varying based on the devices and
the network management system as well. The simplest way is to connect via Command Line
Interface (CLI) using either Telnet or Secure Shell (SSH) and set commands that can provide
data or change parameters. Several terminal emulator applications exist and can be used on
Android platform as well [7]. Contemporary network device manufacturers are committed to
add the ability to enable controlling network devices via Graphical User Interface (GUI) and let
the user to change settings. One of its form of presence is enabling to connect the device via
browser using Secure Socket Layer (SSL) connection or through custom interfaces such as
Mikrotik Winbox (insert reference to solution in brackets [x]. However, all of these forms of
connection see the network as interconnected devices and make network changes through
configuring individual devices.

As a network contains more and more devices, the network management becomes highly
complex. A research conducted by the members of the University of Wisconsin [8] pointed out
that there are key management tasks, which are crucial to handle complex networks, such as
understanding the network structure, identifying the inconsistencies and conducting a what-if
analysis. The paper also concludes that configuration errors are answerable for most of the
network shutdowns and as networks turn into more complex the risk of configuration error
increases. Hence, configuring the network on a per device basis embodies high risk of
configuration issues. Within this type of network, the distributed transport and control protocols
operate inside the network devices (switches, routers or firewalls) and are the key technologies
that enable information packets to circulate.

Despite their dispersed acceptance this so-called traditional IP networks are complex and
hard to administer [8]. As a comprehensive survey [9] explains in order to represent the
expected high-level network policies, administrators need to configure each of the network
devices separately using low-level commands. Moreover, networks shall stomach the
dynamics of errors and fit to load changes. Response mechanisms and automatic
reconfiguration are apparently nonexistent in actual IP networks. A research has shown that
[10] network operators not only have devices and labour costs, but the lack of optimization and
investment on new technologies [11] as well. Software Defined Networking brings a new
approach into this equation by simplifying the network management and giving opportunity to
handle the network as a common view. [9]. Having the potential of querying the network using
applications can help engineers and decision-makers.

7
Not only is SDN able to use network management applications and make the configurations
and modifications easier, but traditional network management, as well. Most of traditional
network management solutions are capable of automatic network discovery and scanning for
wired and wireless connected devices, analysing critical data points and paths across your
network, monitoring firewall rules automatically displaying network maps and topology views,
monitoring and analysing Wi-Fi networks and supervising hardware health of servers, firewalls,
routers, switches, desktops, laptops and more. Here is a list on the most successful of them
[12]. As a trend, these management applications seem to be web based [13] these days. It is
also clear that more and more Android applications appeared in the last decade in order to
help network administrators [14] [15].

The only application existing that is related to the Cisco APIC-EM Controller and Android is
Cisco PnP Android application. It uses the controller northbound interface, which is close to
SDN technology. It does connect to a Cisco APIC-EM controller via https and uses REST API
calls to get pre-defined Bootstrap configuration from the controller. Moreover, it displays
already configured and provisioned devices. Furthermore, it is possible to register new devices
in order to have the possibility to upload device info onto the controller without a highly trained
engineer. This small application uses Bluetooth to connect to a special device called
AirConsole, which connects you to a Device via its serial console using Bluetooth. The
application uses REST API calls to connect to the controller and to receive or set data [16].

1.4 Applied Methodology

The chosen method is empirical, since it is a development of an application. The application


will modify and query network settings and these functions will be demonstrated within the
document. The built test environment, which is a virtual network system running on virtualizing
software, is capable of emulating real network environment, hence the measurements will be
appropriate to prove the application functions. The gauging and presentation can be found in
chapter 5 in this paper.

8
1.5 Research Questions

The State Of The Arts chapter pointed out that programming SDN controller has been
unexploited. One of the widely used Northbound protocol is REST API, and unfortunately there
are just a few existing programs (being either front-end or back-end) to manipulate or display
network configuration. At this point, there is only one Android application to work with Cisco
APIC-EM SDN controller, which is the Cisco Network Plug and Play Mobile Application. It sets
bootstrap information on network devices in order to connect those devices with the APIC-EM
controller itself. Hence, the research questions are the followings:

How can Mobile or any other application become an important participant in Network
Management through the usage of northbound APIs of a Cisco SDN Controller? How can we
produce an application, which queries or influences the network upon request without any
knowledge about networking itself?

1.6 Structure

First, this paper will introduce the theoretical background of the related technologies, such
as SDN, REST API and Android development. Then it will introduce the test environment and
will answer how the specific systems will connect to each other and what the functions of them
are. Thirdly, the Thesis will give the reader an overview about the required installation and
setup steps of all systems (please do not invest too much effort on this section, keep short).
Chapter 5 will make appearance of the functions of the Android application followed by the
most important part where all REST API calls and relating Android Studio developing process
will be explained. This chapter will exactly subject the essence of interconnecting REST API
and developing language. Finally, the next head will visualize and prove these functions.
Finally yet importantly, the possible economic impact of a probable spread of SDN Architecture
and Applications will be discussed in the main body. In the conclusion section, firstly all the
reached objectives (Chapter 6) will be summarized. Furthermore, existent ideas and future
development possibilities will be argued

9
2 Theoretical background
The practical part of this Thesis is based on three particular technologies such as SDN,
REST API and Android Studio. While Android Studio is nouveau developing environment to
provide fast tool for building applications on mobile devices, SDN and REST API have long
history and require unfolding in detail.

2.1 Software Defined Networking

TRADITIONAL NETWORK ARCHITECTURE

Despite the fact that traditional networks are widely used, they cause issues due to their
complexity and hard manageability. In order to integrate high-level policies, engineers must
implement configurations on each network devices individually using Command Line Interface
(CLI) and mostly vendor specific commands. It is also nearly impossible to implement
automatic reconfigurations or built-in response mechanisms. Therefore, it is an exceptional
challenge to enforce policies in dynamic environments. Moreover, today’s networks are
vertically unified.

End- user devices, or hosts are the elements of data communication networks and they are
interconnected by the network infrastructure. This infrastructure is shared by hosts and
contains routers, switches (active devices) as well as communication links to carry information
between hosts. Active devices are usually “closed” systems and they usually have vendor-
specific control interfaces. Once they are deployed, it is difficult to evolve. Traditional Networks
are divided into three major planes: data, control and management planes as depicted on
Figure 1. Only the last one can be centralized in this architecture. [17].

Figure 1: Traditional Network Planes

The first plane (data) is responsible for simple packet forwarding and corresponds to the
networking device (router, switch). The control plane shapes the protocols, which deploy the
forwarding tables of the data plane elements. Management services like Simple Network
Management Protocol (SNMP) or Secure Shell (SSH) configure and monitor the control

10
functionality. A network policy is defined in the management plane, enforced by the control
plane and executed by the data plane by forwarding the data according to that policy.

Traditional IP networks couple the data and the control plane within the same device and
their structures look highly decentralized. On one hand, this decentralization was an essential
base of early Internet, since it guaranteed the network resilience. The outcome of this design
caused very complex and mostly static architecture that is rigid and hard to manage.
Misconfigurations of a network and the related issues are common these days. Misconfiguring
a single device might cause undesired network behaviours and many unwanted results such
as data losses or even service contract violations.

The so-called control plane is the decision maker that implements the rules that define how
to handle the network traffic. The other important plane is the data plane that forwards the
traffic regulated by control plane decisions. Both planes are bundled together inside active
devices causing reduced flexibility and inhibit the innovation in the networking infrastructure.
The reconsideration of the whole Internet architecture (e.g. replacing IP) seems to be
complicated and almost impossible to execute [18] causing the capital and operational
expenses being off the charts.

SOFTWARE DEFINED NETWORKING ARCHITECTURE

SDN is a new approach and emerging as well that might overcome the limitations of current
network infrastructures by offering central control decision and programmable network.
Software Defined Networking (SDN) is a new networking paradigm in which the forwarding
hardware is separated from control decisions and networks became to be “programmable” in
a way to support network development. SDN also offers to simplify network management and
enable innovation and evolution. It is also worth to note that the idea of decoupled control logic
and programmable networks has been around for many years. Early programmable
networking efforts (OPENSIG [19], NETCONF and Ethane [20]) had great impact to the form
of the current SDN by laying the foundation for many of the ideas we are seeing today.

The basic idea of programmability is to allow software developers to trust to network


resources in the same way as in storage and computing resources by using standardized
interfaces. These interfaces named as Northbound interfaces. The control separation means
that the network intelligence is in logically centralized systems named as controllers (the
control plane). It also means that network devices become simple packet forwarding devices

11
(the data plane) that can be programmed by using well-defined open interfaces such as
(ForCES [21], OpenFlow [22] , etc.). These interfaces collecting name appeared as
Southbound. A group of service providers, network operators and vendors have founded the
Open Network Foundation [23] to promote SDN and standardize the OpenFlow protocol [22]
as the open Southbound interface to program network devices. Standardization efforts also
have been conducted on SDN by IETF and IRTF. It seems that OpenFlow is a new idea in
networking [24] has received considerable attention from industry.

Software-Defined Networking was developed to enable programmatic control of the network


data-path to support innovation. The separation of the hardware - that forwards data - from the
control logic offers easier deployment of new applications, network visualization techniques
and management functions. This decoupling is depicted on Figure 2.

Figure 2: SDN Architecture 1

12
The SDN concept separates the data and the control plane from each other and moves the
intelligence of the network to a central unit called controller as depicted on Figure 3. It also
simplifies network configuration needs to be validated and enforced. It is important to know
that the centralized control logic does not just a few centralized physical devices. Implementing
physically distributed control planes is more preferable [25], since it enhances system
reliability.

Figure 3: Central Control Plane

Using a well-defined programming interface between the SDN controller and the active
network devices (SouthBound Interface) is the key of the separation of the two planes (control
and data plane). The SDN controller dictates the functioning of the data plane elements via a
precisely defined API interface. One of these approach is to use OpenFlow [26] southbound
interface and OpenFlow capable switches. These switches have packet handling rules called
flow tables. Each rule is compared to a subset of traffic and executes certain actions such as
dropping, modifying or forwarding. The controller application installs the rules, which influence
the behaviour pattern of the affected device. Hence, the device might act as router, switch or
even firewall depending on the certain rule. SDN and OpenFlow were initiated by universities
as an experiment and later they have become significant on the networking market and most
vendors offer the possibility of OpenFlow usage. This operation is depicted on Figure 4.

13
Figure 4: Southbound Interfaces

Using a well-defined interface between applications and the SDN controllers offers the
programmability. Early programmable networks appear in SDN architecture as Northbound
Interfaces and allow software to connect the controller. They also offers options to query or
influence the network behaviour. Such interfaces like REST API [27], Java API [28] and GUI
Shell [29]. This behaviour is depicted on Figure 5.

14
Figure 5: Northbound Interfaces

Again, SDN architecture can be characterized by the following aspects.

Firstly, data and control planes are decoupled and the control functionality is extracted from
the network device, meanwhile the data plane is downgraded.

Secondly, the decision of the forwarding mechanism is based on flow entries instead of
destination. These entries are part of a flow table where flow information is used for creating
matching rules that trigger actions. This flow abstraction makes different functionalities merge
such as router, switch, firewall or even Intrusion Prevention System (IPS).

Thirdly, the logic of the control is placed outside of the network devices. This external
element is the SDN controller or Network Operating System (NOS), which runs on servers and
a software platform. The NOS provides resources, abstractions and a logically centralized
network view to assist the coding of forwarding network devices.

15
Lastly, the network is modifiable and able to provide information for queries through
standard interface for software applications. These applications run on the top of the SDN or
NOS.

In order to identify the basic elements of SDN here are a few terminologies.

 Forwarding Devices
These are the devices that perform basic operations based on either hardware or
software data plane.
 Data Plane
The interconnected forwarding devices – through wired or wireless channel -
represent the data plane.
 Southbound Interface (SI)
Firstly, the SI contains all the commands and instructions for the forwarding devices
defined by southbound API. Secondly, it defines the communication protocol between
the control plane elements and the forwarding devices.
 Control Plane
The control plane elements program the forwarding devices through well-defined
southbound interfaces.
 Northbound Interface
The SDN controller or NOS offers APIs to applications.
 Management Plane
This plane is usually a set of applications that offers the help in manageability and
operation logic. Usually the management application defines the policy, which is
translated to southbound instructions that modify the forwarding devices.

16
With the knowledge of all participants Figure 6 depict the SDN architecture.

Figure 6: SDN Architecture with Controller

Beyond the exact definition of SDN, its architectural approaches might differ. These
differences depend on networking approaches and all are used in networking industry.

The original – the “pure” SDN – is mentioned before, where the control plane is decoupled
from the data plane.

The second one is the so-called “Control Plane SDN” where control plane is still distributed,
but offers APIs that allow an interaction between the network and an application. The SDN
controller plays a broker role between network devices and applications. This type of

17
architecture appeared as Opendaylight [30] controller with Openflow [31] capable forwarding
devices.

The third manifest is the overlay SDN, where the control plane distribution still exists and
connects the network devices control planes with the SDN controller through a static underlay
transport network. Then the controller provides logical overlays, which utilize the underlay
network. The second architecture may include Cisco DNA center [32] as controller and SSH
as southbound protocol with various tunnelling protocols in order to accomplish the overlay
network function such as Virtual Extensible LAN (VXLAN) [33], locator/ID separation protocol
[34] (LISP) and Network Virtualization Using Generic Routing Encapsulation (NVGRE) [35].

This Thesis uses the third kind of architecture with Cisco APIC-EM controller.

In order to understand better the SDN architecture the following sections - from the letter A
to H - disassemble the architecture into layers and explains each layer in detail. The selection
of these layers below from A to H is arbitrary, but illustrates well by dissecting the SDN
architecture.

A. Layer 1 – Network Infrastructure

Both traditional and SDN infrastructures are composed of a set of networking devices such
as routers, switches, firewalls, and various middleboxes. In case of SDN infrastructure the
networking, equipment consists of simple forwarding elements without any embedded control
to take self-dependent decisions. The network intelligence is moved to a centralized system,
to the so-called NOS. There is a trend in SDN to build these new networks on top of an open
standard interface such as OpenFlow, which is a determining approach for guaranteeing
configuration and communication compatibility among various devices. Technically speaking,
having open interfaces enable various controllers to communicate and program
heterogeneous forwarding devices, which was difficult in traditional networks due to the high
diversity of proprietary interfaces. OpenFlow style architecture uses the forwarding devices
and the controllers as main elements, where the controller represents the network brain as a
software stack and the data plane device usually a hardware device to forward packet. These
forwarding devices use a pipeline of flow tables where each entry of a flow table contains three
pieces such as rule, action and counter. The rule where the matching packet definition takes
place is based on any header information from layer 2 to layer 4. For instance, switch port,
source MAC address, destination IP address or source TCP port as well. At the action part,
the execution of a specific action occurs on that matching packet. For instance if a certain
source tcp port is detected then certain actions might happen independently from each other

18
such as forward packet to a port, drop packet, encapsulate and forward to controller or even
send to another pipeline. The last part is the counter where information is kept about statistics
of matching packets. Although there are other approach paths to implement such SDN design,
yet Openflow seems to be the most widespread of this kind. Inside OpenFlow, devices there
might be one or more flow tables connected to each other as a pipeline. When a new packet
arrives the packet processing starts in the first table, goes along all the tables within the
pipeline and gets either match or miss. If there is no matching rule then the packet usually
discards. However, the common practice is to define a default rule that tells the router or switch
to send the packet to the controller to avoid “no matching rule” situations. As OpenFlow has
evolved, the versions contain matching field capabilities. For instance, IPv6 was introduced
only from version 1.2. There are a large number of variety OpenFlow capable devices on the
market being either commercial or open source products and the market is changing rapidly.

B. Layer 2 – Southbound Interfaces

The communication between control and forwarding elements applies southbound


interfaces or southbound APIs that act as bridges between those elements and create the
separations between control and data plane functionality. Unfortunately, these APIs are still
tightly connected with forwarding devices. Typically, a new device takes around three years to
be ready including the software development as well and the risk is too high. Having standards
like OpenFlow are welcomed in the market, since the standards always help implementation
easily.

C. Layer 3 – Network Hypervisors

Virtualization has become the mainstream of computing platforms and technically inevitable
in networking as well. Cloud routers, wireless controllers and even Intrusion Prevention
Systems are running on virtual platforms and the virtualization is still rising. Hypervisors enable
various virtual machines to utilize the same hardware resource. Moreover, in cloud
environment users can have its own virtual resources such as processors, memories and
storages. On the top of that, virtual machines can be easily migrated between physical servers
as well. Unfortunately, the network is still mostly statically configured on physical devices.

The two main problem with traditional networks are caused by topology and address space
issues. As different companies, need different services, which require different network
topology. The topology implementation is usually based on the Open Systems Interconnection
(OSI) Layer services and currently it is difficult to support the various demands and services
on the same physical topology. Similarly, the address space of a network is static and hard to
change within the same environment. Having fixed address scheme and topology make

19
keeping the original network configuration difficult. In order to reach complete virtualization the
network should offer similar functions to the computing layer. It would be desirable to retrieve
services like arbitrary network topologies and addressing schemes from the network
infrastructure. SDN with network hypervisors seems to be a good solution to this issue
providing the flexibility of network hypervisors.

D. Layer 4 – Network Operating Systems / Controllers (NOS)

Ordinary Operating Systems have played an important role for increased productivity by
providing abstractions for low-level devices, managing the access to the underlying resources
and offering security features. These capabilities have contributed to the spread and the
development of various kind of applications. In contrast, up to this point engineers have
configured and managed networks by using low-level and mostly device specific commands
with proprietary software. Moreover, the use of abstractions of operating systems is still absent
in today’s network. SDN is a promising technology and approach to solve networking problems
by providing a centralized control offered by a NOS. The essential part of the NOS is to provide
abstractions, common APIs and services such as network state, network topology information,
network configuration distribution and device discovery. Thus, NOS behaves like a traditional
Operating System. Most importantly, policies are easier to distribute and no need to care about
low-level commands and instructions, which helps avoid misconfigurations and issues. The
NOS itself is a crucial part of SDN architecture by supporting control logic and generating
network configurations. These configurations and logic are based on policies defined by
network engineers and operators. Existing controllers can be classified variously based on
many aspects such as being architectural or functional. One of the most relevant classification
is whether the controller is centralized or distributed. The centralized is a single entity, which
manages all forwarding devices within the network. Unfortunately, its failure might be an issue
and as being single it is hard to scale and not enough to handle large networks. The distributed
version on the other hand is easy to scale up to meet special requirements and might be used
in any kind of environment from small to large. Moreover, a distributed controller might be
implemented as a centralized cluster of nodes or physically distributed appliances. The first
implementation is useful to offer high throughput for date centers, the latter is for fault tolerance
systems. Of course, the distributed version has a lack of consistency, since data updates on
distinct nodes are updated on all the rest of the controllers and those updates are time
consuming causing different configuration values on distinct nodes. On the other hand,
centralized version offers clearer interface to application developers despite its strong
consistency affecting the performance of the system. In order to have a better architectural
overview and be able to understand the Network Operating Systems Table 1 summarizes three

20
SDN controllers and their properties, which represent components, considered important such
as base network services, management interfaces, southbound and northbound interfaces.

Component OpenDaylight Cisco APIC-EM Cisco DNA Center

Base Network Topology Manager Topology Topology


Services
Switch Manager Discovery Discovery
Stats Manager PnP PnP
Host Tracker Path Tracker Path Tracker
Shortest Path WAN NFV Campus and WAN
Forwarding NFV

Management GUI, CLI, REST API GUI, CLI, REST API GUI, CLI, REST API
Interfaces

NorthBound APIs REST, RESTCONF, REST API REST API


JAVA

SouthBound APIS OpenFlow, OVSDB, SSH, SNMP, SSH, SNMP,


SNMP, NETCONF TELNET NETCONF
BGP

Table 1: Architecture and Design Elements of Three Control Platforms

First and the most important part of SDN controllers is the Core Controller Function as
depicted on the middle of (). It contains the base network services and functions, which are the
essential part of functionalities that controllers should provide. They are like the base services
of traditional Operating Systems, but with different services like topology, statistics,
notifications and device management. Secondly, as an analogy southbound interfaces are like
device drivers in traditional operating systems and offers transparent communications toward
low-level devices. Finally, current controllers provide a great variety of northbound APIs such
as REST API and multilevel programming interfaces.

As a summary, today’s NOS systems can be categorized by various aspects and they
accomplish a great deal of services that have common and different components as well.

E. Layer 5 – Northbound Interfaces

The two key abstractions of an SDN system are the southbound and northbound interfaces.
Whilst the former has standard proposals, the latter has still issues about choosing a common
solution. It would be beatific to have a standard northbound interface since abstraction allows
network applications not to be dependent on specific or even proprietary implementations in

21
order to exploit all aspects of SDN. The southbound APIs act like a hardware ecosystem by
contrast northbound is more like a software ecosystem. Discussions have already been started
among network engineers [36] and it ended with an agreement to delay the issue, since it is
too early to define the standard now. Having experience with various kinds of controllers is an
excellent way to come up with a common idea about a standard northbound interface.
Ultimately, promoting only one northbound interface as winner might seem useless, since
different network applications have unalike requirements. For instance, security applications
have different criteria from financial or routing. This approach might definitely ease the daily
life of networking developers, as they do not need to care about individual device
configurations. The use of this kind of abstraction simplifies the development of complex
network applications such as deploying security or IPS rules.

F. Layer 6 – Language-based Virtualization

Gaining as much as possible by having virtualization is based on two factors: modularity


and allowing a different kind of abstraction. For instance, it is desired to have different views
of a single physical network, such as regarding several forwarding devices as one switch with
a great deal of ports. One appearance of the virtualization is a programming language that
offers high-level of abstraction of network topologies and policies to particular topologies.
Another form of language based on virtualization is the so-called “slicing” that means the
network is sliced based on application layer definitions.

G. Layer 7 – Programming Languages

Programming languages have been evolving since the first computer appeared in computer
industry being either a low-level machine code like Assembly or a high-level one such as Java
or Python. Similarly, in networking codes have been moving form low-level as if OpenFlow to
high-level such as REST API, where OpenFlow is a machine code and RES API creates the
higher abstraction. At low-level the code imitates the behaviour of forwarding devices, but
these have limitations according to their original purpose. High-level programming languages
address better these limitations and issues by creating higher-level abstractions, enabling
more problem-focused environment, promoting software modularization in control plane and
fostering the network virtualization.

H. Layer 8 – Network Applications

The “network brains” implement the control logic that will be converted into commands to
be executed in the data plane. These “brains” are the network applications that form the habit
of particular forwarding devices. For instance, the routing application decides on the path to

22
forward packets and becoming as a routing definition logic. To do that this precedent
application calculates the path and instructs the controller to add or modify forwarding rules on
all devices within that path. Since SDN capabilities are not limited to special kind of network,
the occurrences of these network applications are well spread and have a large number of
varieties such as routing, load balancing, security policy installations and even new
approaches like altering power consumptions in devices. Other examples consist of fail over
functionalities, QoS for all devices within a path, Network Virtualization Function (NFV) or even
mobility management in the case of wireless networks. These applications fall into five distinct
categories: mobility and wireless, traffic engineering, monitoring, security and data center.

As a conclusion traditional network seems to be complex and inconvenient to manage,


since control, data planes are integrated, and mostly vendor specific, and forwarding devices
are closely tied to versions. These issues cause problems for network infrastructure owners,
whereas the necessity of using only one vendor creates severe restrictions in innovations.
SDN offered a window to move forward and leave behind these long-standing problems by
developing key ideas such as dynamic programmability in forwarding devices using open
southbound interfaces, separating the data, the control plane, and the common view of
networks by centralizing logically of the “network brain”. SDN creates higher performance and
better manageability by degrading forwarding devices to dumb but efficient and representing
control plane elements as single entities i.e. controller or NOS. On the top of the controllers
the network logic appears in the form of network applications causing easier development and
implementation compared with traditional networks. Having a common, global view of the
network the consistency of policies is easy to enforce. Despite the fact that SDN technology
seems to be chaotic its appearance represents paradigm shift in networking. SDN has
successfully managed to survive over the years and moved toward to be a next-generation
networking.

23
2.2 REST API (Representational State Transfer)

This chapter introduces the Representational State Transfer (REST). REST is acronym
for Representational State Transfer. It is an architectural style for distributed systems and was
first presented by Roy Fielding in 2000 [37] and it has an advantage to design to connect
applications over Hypertext Transfer Protocol (HTTP) [38]. It is also used between web
services to communicate each other as depicted on Figure 7.

Figure 7: REST API Communications

REST does not have any rules to be implemented at low level; it just offers a high-level
design guideline as architectural constraints [39], which must be fulfilled if an interface needs
to be referred as RESTful [27]. These constraints are Uniform interface client–server,
stateless, cacheable, layered system and code on demand, which is optional.

A. REST API Constraints Figure 8

Figure 8: REST API Constraints

24
Uniform Interface means that a resource in system has only one logical URI and this is a
central feature to make a difference from other network-based style. This feature also provides
way to fetch related or additional data. A good synonym for resource is a web page. A single
resource contains every data in its form and can contain links to point to relative URI to get
related information.

Client-server means that the user interface (client) and data storage (server) are separated
and can be developed independently from each other. The client only knows about the
resource UIRs and this is a common practice in web development.

Stateless constraint originates from HTTP and it means that all interaction between client
and server are stateless. The server regards every request from the client as new and does
not keep anything about previous HTTP requests. Technically, the session state is kept on the
client.

Cacheable has a meaning that the data within a response to a request can be labelled as
cacheable or non-cacheable. For instance, if a response is cacheable the client has the right
to reuse that information. Caching offers performance improvement on the client side, and
scalability for servers by reducing their load.

REST offers Layered system to be used to deploy distributed services. For instance, APIs
on one particular server, the data on another one and authentication with a last one. A client
is unable to identify whether it is connected directly to a server or not.

Although the last constraint is optional, Code on demand extends client functionality by
providing to download and execute codes. These codes can be in applets or scripts. It is worth
to mention that all above constraints are similar to WWW and Using RESTful APIs the same
thing can be done with web services what can be done with web pages.

25
B. REST Architectural elements

The basic and key abstraction of information in REST is a resource. A resource is an


information and can be the followings: image, document, service, other resources or a person
as well (non-virtual object) as depicted on Figure 9.

Figure 9: REST Resource Examples

REST uses a resource identifier to refer to resource and can be a singleton or a collection
[40]. The resource is the nucleus of REST API. The state of the resource is the resource
representation at a particular time and consists the followings: data, metadata and
hypermedia links to help the clients to move to the next state. The data format of a particular
representation is the so-called media-type that tells how the representation is to be processed.
In addition, the resource representation is self-descriptive; hence, the client does not require
knowing about the form of resource. Another important thing in REST is the resource
methods, which is for performing the desired action and are USUALLY HTTP methods like
GET, PUT, POST or DELETE, but not necessarily. REST and HTTP are not the same. In
26
REST, data and functionality are referred as resources and are got by the use of Uniform
Resource Identifiers (URIs). The clients and servers usually exchange representations of
resources by using HTTP.

C. REST API Request and Response

In REST API, every single URI is named request while the information sent back for that
request is called response as depicted on Figure 10.

Figure 10: REST API Request and Response

The request is made up of four distinct parts that are listed in Table 2

Sequential number Name

01 Endpoint

02 Method

03 Headers

04 Body (data)

Table 2: REST API parts

27
1. Endpoint

The first part is the endpoint and it has it has three parts. The first part is root-
endpoint, in this case api.guthub.com and is the starting point of the API that is
requested. The path determines the requested resources and similar to an
answering machine that asks for pressing either one or two for different services.
Also works in a similar way when linking to parts of a website. In order to get all
available paths the related API documentations are required to be reviewed for
that particular root-endpoint. Any colons (:) within a path denotes a variable and
need to be replaced by the actual value when sending a request.

The final part of an endpoint is “query parameters”, which technically do not


belong to REST architecture, but most of the APIs use them. Query parameters
are to modify your request with key-value pair and each parameter pair is
separated with ampersand (&) and always begin with a question mark (?).In order
to test these requests great tools are Postman [41] or Firefox Browser
RESTClient [42]. Sending and requesting data through a REST API the body of
a request has a format. Interestingly, this format is the same as what the server
uses to send back the response. This common format for sending the body or are
response is JavaScript Object Notation (JSON) and looks like a JavaScript
Object. In JSON, each property and value is wrapped with double quotation
marks and looks something like this:

“property1”: “value1”,

“property2”: “value2”,

“property3”: “value3”,

2. Method

The second in the sequence is the method, which is chosen from five types
such as GET, POST, PUT, PATCH and DELETE. These methods provide
meaning for that particular request and are to perform four possible actions such
as CREATE, READ, UPDATE or DELETE. The following Table 3 lists the
methods and their meanings.

28
Table 3: REST API Methods

Method Name Request Meaning

This request is used to get a resource from a server. If you


perform a “GET” request, the server looks for the data you
“GET” requested and sends it back to you. In other words, a “GET”
request performs a “READ” operation. This is the default request
method.

This request is used to create a new resource on a server. If you


perform a “POST” request, the server creates a new entry in the
“POST”
database and tells you whether the creation is successful. In
other words, a “POST” request performs a “CREATE” operation.

These two requests are used to update a resource on a server. If


you perform a “PUT” or “PATCH” request, the server updates an
“PUT” and “PATCH” entry in the database and tells you whether the update is
successful. In other words, a “PUT” or “PATCH” request performs
an “UPDATE” operation.

This request is used to delete a resource from a server. If you


perform a “DELETE” request, the server deletes an entry in the
“DELETE”
database and tells you whether the deletion is successful. In other
words, a “DELETE” request performs a “DELETE” operation.

3. Headers

The headers are useful to provide additional information to the server or the
client and are used for various purposes such as authentication or supply
auxiliary data about the body content. Here is a list of valid headers [43]. These
headers are property-value pairs, which are separated by a colon.

4. Body
The data (body) contains information being sent to the server and only used
in the case of POST, PUT, PATCH or DELETE requests and has the form of
JSON.

29
D. JSON

It is worth expanding JSON [44] in details, since the data, structure allows data serialization
to become effortless and offers the developers to retrieve information efficiently. JOSN is a
lightweight data-interchange format and relatively easy to read and write. Moreover,
accommodating JSON format is passed and generated by machines. It is grounded on a
subset of the JavaScript Programming Language. JSON is completely language independent,
it has a textual format. Moreover, it uses conventions that is well known for programmers of
the C-family such as C, C++, C#, Java, JavaScript, Perl, and Python. It is an ideal data-
interchange format due to its properties. JSON is based on two structures such as a collection
of name and value pairs, and an ordered list of values. The former is usually called object
or record in prevalent programming languages. The latter is array, vector or list. An object
is between { (left brace) and } (right brace) and is an unordered set of name and value pair
where each name and value pair is separated by comma and between them there is a colon.
On the other hand array is an ordered list of values and begins with [ (left bracket) and ends
with ] (right bracket) and every single value is separated by comma. It is important to know that
array values might contain objects as well. A value can be the following: string (in double
quotes), number, Boolean, object, array, and nesting is common within these structures. A
string contains Unicode characters and is wrapped in double quotes. It uses backslash
escapes character and similar to C or Java string. The number looks like C or Java number
with the exception of not using octal and hexadecimal formats. Finally, whitespaces are
allowed to be inserted between any pair of names and value pairs. It structure is depicted on
Figure 11.

30
Figure 11: JSON Structure

JSON format and REST API together use less bandwidth comparing to other structures and
this makes them suitable for internet usage. Moreover, the stateless properties make them
useful in cloud applications like this Thesis about.

31
2.3 Android Studio

Android Studio as a developer tool is based upon IntelliJ IDEA [45], Moreover; this is the
official Integrated Development Environment (IDE) for Android app development. IntelliJ IDEA
is a powerful code editor and developer tool and helps developers stay in the flow while working
with code completion and with other features. IntelliJ also informs developers what is wrong if
a code does not compile and offers options to fix the issue. It is convenient to refractor code
while writing, implement interfaces, create methods, rename anything while coding or extract
variables, fields, methods and so on. Code completion can be chosen in smart or dumb ways
as well. On the top of IntelliJ Android Studio offers even more features that offer developers to
enhance the coding process such as Gradle-based build system [46], fast and rich emulator,
unified environment for all Android devices. Furthermore, an instant run option to update the
changes to the running app without building, code templates to support building common
application features and importing sample codes, testing tools, C++ support and an easy
integration capability with cloud platforms such as Google Cloud [47].

Android Studio uses Project Structures that contain one or more modules including source
code and resource files. Module types are Android application, Library or Google App Engines.
By default, it displays the project files in project view organized by modules offering quick
access. All the build files are under the name Gradle Scripts and every single app module
has manifest, java and res folders. The manifest contains the AdroidManifest-xml file, the
java the Java source code files and the res all non-code resources. These resources contain
SML layouts, User Interface strings and bitmap images.

One of its most important part is the Gradle Build System that runs as an integrated tool
from the Android Studio menu and it is independent from the command line. It is useful to
customize, configure the build process, create different versions of the application and reuse
the code and resources. This build system offers the creation of different versions of the same
application within a single project in order to distribute different device configurations on
Google Play. It allows creating multiple versions efficiently for different appearance. For
instance, based on different screen density. Android Studio automatically shrinks resources by
removing unused ones from the packaged app and library dependencies. It assist in debugging
and helps improve the performance of the code by offering inline debugging and performance
analysis tools. Inline debugging is beneficial by walking through systematically the code and
verifying the references, expressions and variables.

Android Studio was announced on May 16, 2013 and the first stable build was released in
December 2014 providing a plausible tool for building apps on every type of Android device.

32
3 Test Environment
The test environment is built in a lab that comprises a firewall, switches and virtualization
software running on a Server. The general structure of the test environment is shown on Figure
12.

Figure 12: The general view of the test environment

The Cisco ASA operates as a firewall and provides Internet connection, maintains security
and generates Network Address Translations (NAT) in order to ensure reachability of the Cisco
APIC-EM controller and other elements from outside the lab environment. The L3 switch is
placed there in order to separate other lab systems from the Test Environment and maintains
routing information on the Virtual Network for the APIC-EM and others. The L2 switch is

33
assigned to give Layer2 trunk connectivity between the physical network and the VMWARE
ESXi virtual environment, which runs the Cisco APIC-EM SDN Controller and the Emulated
Virtual Environment for the Network (EVE-NG). The developed application connects to the
APIC-EM.

It is important to visualize the systems running inside the VMWARE and the connection
between the application, the Cisco APIC-EM controller and the managed network. All these
can be observed in Figure 13.

Figure 13: Test Environment Elements and Connections

Finally, the logical network topology of this case will be displayed in detail with networks,
routing protocols and IP addresses in chapter 3.2. The following requirements are mandatories
for the network in order to successfully build up an environment. Firstly, the devices that
operate the application and are designed to connect via REST API to the APIC-EM controller
must reach it via HTTPS protocols (TCP port 443). Secondly, the APIC-EM must be able to
connect the network devices that it wants to manage through SSH or TELNET and SNMP
(TCP port 22, TCP port 23 and UDP 161). The APIC-EM installation steps and deployment
options will be explained in detail later in chapter 3.3.
34
The latter demand embodies the necessity of being able to reach the network devices by
the controller via TCP/IP, so network route or multiple routes shall be established toward them.
The following chapters include installation and settings information about all systems
participating in the test environment except the physical devices. The physical devices’ settings
are meant to give the opportunity to connect to or from the Internet and as such may differ in
various circumstances.

3.1 VMWARE Environment

The VMWARE management network is separated from the Test Environment Network due
to security issues and manageability and connected with the physical server through a different
physical Ethernet port.

Figure 14: VMWARE Management Network Connection

35
3.2 EVE-NG

EVE-NG is the successor of the famous graphical network simulator called GNS3, but far
more safe, practicable and does not consume as many resources as its predecessor.
Moreover, it runs on Linux operating system and incomplex to manage. The management
interface of EVE-NG is a Web page running under Apache Web Server, which allows
engineers to utilise this network simulator without any concern and enables the use of the
management interface from anywhere. EVE-NG is the first real clientless network emulation
software and offers conveniences for network engineers. Using this software allows IT
professionals to build and test network environments and behaviours without compromising
corporate security policies as it runs in a completely quarantined environment. EVE-NG is
currently released as an OVA file and ISO. OVA means Open Virtual Appliance. It is an archive
(TAR) which holds disks and configuration file OVF (Open Virtualization Format) [48] for the
virtual machine. EVE-NG can be also directly installed on the physical hardware, without any
virtualization by using ISO image. Because EVE-NG runs many hypervisors, a dedicated
physical server without any virtualization software is highly recommended for it, for simplicity
reasons in this case the EVE-NG runs on VMware.

After the successful provisioning of the EVE-NG OVA image file the Virtual Machine has to
be started and a few questions have to be answered, like the EVE-NG admin user password,
the system name, the domain name, the use of DHCP or static IP address scheme of the
system. If static has been chosen then the IP address, network mask and default gateway
have to be set. The last two questions are about Network Time Protocol server (NTP Server)
host name and the usage of direct or proxy connection in order to reach the Internet. All these
answers depend on the environment and in this Thesis case on the following settings:

 The management network is set by DHCP


 The hostname is eve-ng
 The domain name is sdn.test
 Password is eve
 NTP server is 0.hu.pool.ntp.org
 Direct Access without proxy

Once all settings are complete, the EVE-NG reboots and the management web page is
available via http://EVE-NG-IP-ADRESS. This IP address belongs to a network that is other
than VMware management network as it is shown on Figure 6, which in this case 10.0.135.0/24
and the internal IP address of the EVE-NG is 10.0.135.200.

36
After the successful installation of the base EVE-NG the image of the routers, switches and
servers have to be uploaded, since the basic EVE-NG is just a frame for network virtualization
and it sets the stage for running various network device operating systems. The supported
images and HowTo’s are available under the official webpage of the software [33]. The Virtual
Network Environment uses four images within the EVE-NG to create the proper stage to work
with.

In order to realize the Application Path Preference function (Chapter 1.2) of the Android
Software some of the network devices require compatible physical routers and images or
suitable virtual router software image. As the network is virtual, in this case the used image is
CSR1000V (Cloud Services Router Virtual image). In addition, the Application Path Preference
Function needs Intelligent Wide Area Network application (IWAN) installed on APIC-EM. The
minimal IWAN requirements contain one HUB site and one Branch site in the network. The
HUB site must have at least three and the Branch site at least one router with CSR1000V
image.

The possible network scenarios of the IWAN solutions will be detailed at Chapter 3.3. In
order to get sightful topology view function of the Android SDN-NM the Branch Site part of the
virtual network contains one gateway and a network with a switch, routers and a Linux host
acting as a client for testing and demonstration purposes. EVE-NG can use all kinds of network
device images among various manufacturers. Most of them need powerful memory and
processor resources, but a few of them not. Unfortunately, CSR1000V needs many resources,
hence the rest of the chosen devices are limited in numerosity and functionality, but this choice
does not affect the outcome of the software. This is the reason for choosing Cisco IOL as the
other virtual operating system image. Cisco IOL is a lightweight implementation of the Cisco
IOS operating system requiring no more than 100Mb RAM to run. It exists in two formats:
Layer2 or Layer3. Layer2 acts as a Switch and Layer3 as a router. These routers and switches
can be placed into the topology in exactly the same manner as other network elements. The
configuration engine is able to configure the IOL instance, creating an appropriate bootstrap
configuration in order that the device boots and then participates in the network simulation.

It must be noted that there is no 'serial console' present on the IOL instance. A maximum
of 16 Fast Ethernet interfaces are provided. CSRV1000 has maximum three Gigabit Ethernet
interfaces. The last pieces of the Virtual Network are two virtual Linux Operating Systems with
Tiny Core Linux [34] distributions. Using Linux gives the opportunity to demonstrate and check
the Application Path Preference functionality. The provision of EVE-NG to use these virtual
images is relatively easy and well documented on the EVE-NG website [33]. A brief summary
of the used images are shown on Table 7.

37
Function Image Access Place

Router for IWAN Cisco CSR1000V IOS XE [49]


functionality UNIVERSAL 16.3.5

Router for general Cisco IOL L3 Advanced [50]


purposes Enterprise 15.4-2T

Switch for general Cisco IOL L2 Advanced [50]


purposes Enterprise 15.2-IRON

Linux for test purposes Tiny Core 6.4 release [51]

Table 4: Used Images of the Virtual Network

Once all images are uploaded and tested the EVE-NG Virtual Network without APIC-EM
looks as it is shown on Figure 15.

Figure 15: EVE-NG Virtual Network without APIC-EM from Visio

The NET cloud icon accomplishes the connection option of the EVE-NG virtual network with
the network.

The next phase of the implementation is to set up and configure all network elements in
order to connect with APIC-EM later. To achieve these goals all necessary configurations must
be installed. Router MC, BR1, BR2 and server Linux1 reside on the HUB site and Gateway,
Core1, Core2, Dist1, Dist2 and Linux2 on the Branch site. The requirements of the EVE-NG
virtual network ensue from IWAN application specifications are the followings

38
 APIC-EM must reach HUB site routers and the Gateway router on
Branch Site. Using IP protocol
 Gateway must reach Brach site routers and switches using IP protocol

To reach these two goals within both sites a well-chosen dynamic routing protocol is
desirable. The Thesis uses Enhanced Interior Gateway Routing Protocol (EIGRP) on the HUB
site and Open Shortest Path First (OSPF) on the branch site as dynamic routing protocol. Later
the IWAN will be responsible for creating and applying the configuration on Gateway, BR1,
BR2 and MC routers to interconnect the two sites. The whole network including the APIC-EM,
EVE-NG virtual and the physical ones are depicted on Figure 16. There are two possibilities
to configure devices using EVE-NG management interface. Both options allow configuring the
devices through Command Line Interface (CLI). The first option uses Putty software to connect
the devices through a random port via telnet protocol (rfc845), the second uses a built-in html5
code to emulate the CLI through the web browser. Both have the same effect, but Putty has
more options to copy, paste text or even log the configuration activity. On the other hand
managing this system behind a firewall using the Putty option requires additional tasks to
perform such as providing Network Address Translation (NAT) and firewall rules. The case of
the Thesis uses Putty and the firewall is set to be in accordance with the requirements. At this
point all network elements are ready except the APIC-EM controller, which is shown in chapter
(3.3).

39
Figure 16: The Whole Network Topology

3.3 APIC-EM

Although the general installation guide of the APIC-EM is available [52], a few steps must
be explained to build the network environment for the Thesis. In addition, there are a few parts
of the APIC-EM structure to understand in order to realize the planned function of the Android
SDN-NM.

3.3.1 Installation of the APIC-EM

Installing the APIC-EM on VMWare according to the installation guide [52] requires
minimum 32GB memory, but experience has shown that the installation randomly fails if it does
not have at least 64GB. The basic APIC-EM does not contain IWAN application; hence, IWAN
application must be installed after setting up the basic system. It is also required to install Plug
And Play Application for APIC-EM prior to IWAN, but this requirement is never documented on
any official site. These applications are not bundled with the Cisco APIC-EM controller and
should be downloaded, installed and enabled to use it [53] .

40
The installation works almost the same way as EVE-NG except APIC-EM uses ISO file for
installation. However, unlike EVE-NG APIC-EM installation is well-documented [52]. After the
successful installation and reboot of APIC-EM, the system is available and reachable for
further settings via ssl connection though recommended browsers [54] using the administrator
name and password provided at installation. Adding the IWAN functionality to the APIC-EM
require to install PnP and the IWAN application itself through the GUI interface of the APIC-
EM and it is quite easy. Both information is available on the official release notes of the selected
application, in this case those are [55], [56] Figure 17.

Figure 17: Installing Applications on APIC-EM

These workarounds are explained in chapter 3.3.3.

3.3.2 Explanation of IWAN Application for APIC-EM

The Intelligent WAN application for APIC-EM simplifies WAN design. IWAN offers a policy-
based interface that represents network abstraction as business intent. The business ideas
are transformed into policies and configurations that propagated toward network devices by
the controller. Technically IWAN on APIC-EM extends the SDN functionality to remote offices
(Branch Site) by using an application centric approach, which derived from business
necessitation and application rules. The IWAN works on WAN design and allows connecting
multiple Brach sites with various kinds of private or public WAN connections with one or more
HUB sites. Usually HUB sites are the ones where services like Data Centers (DC) or
Multiprotocol Label Switching (MPLS) core networks. Brach sites act like subsidiaries or
remote offices within a company, since need central services. The IWAN offers intuitive GUI
management without any knowledge of Command Line Interface permitting the configuration

41
of the network for non-technical staff also by conceiving business priorities into network
policies. The Test Environment for the Thesis does not require more than one HUB site.
However, for the possibility of displaying difficult topology the Brach site contains several
routers. A usual Brach site may connect to a public (Internet) or private (MPLS) WAN and have
one or more connections. Depending on the number and the type of the connections and the
number of the active devices (routers, switches) on the Branch Site the configuration may also
differ. However, both configurations possibility exist within IWAN by taking the correct steps to
take. The Thesis uses two internet connections with one gateway device connected to the
cloud with difficult Layer3 connection among network devices on the Brach Site. Both Brach
and HUB are depicted on Figure 18.

Figure 18: HUB and Brach Sites of the Test Environment

In this case, the gateway devices forward routing information between Brach Site and HUB
Site. All kinds of configuration option descriptions and examples are available here [57]. The
HUB site contains the border routers (BR1, BR2) and the master controller (MC) router as well.
The development of the required Application Path Preference (1.2) function needs Cisco
Performance Routing (PfR) features, which consists of border routers (BRs) that connect to
the DMVPN overlay networks for each carrier network (emulating Internet Service Providers)
and a master controller (MC) application process that enforces policy. The BR collects traffic
and path information and sends it to the MC at each site. The MC and BR can be configured
on separate routers or the same router as well.

42
3.3.3 Setting of APIC-EM and IWAN with the Test Environment

The final move is to interconnect the APIC-EM controller and its IWAN application with the
active devices of the Test Environment. However, the Branch site network devices are
available for the APIC-EM after configuring the IWAN, since IWAN application sets the
redistribution of Branch site networks toward HUB site, where APIC-EM resides. Hence, the
final step can be divided into three tasks: connecting the HUB site routers and the Gateway
router of the Brach site with the APIC-EM, setting up the IWAN and connecting the other
Branch Site routers with the APIC-EM. In order to accomplish these tasks on all routers and
switches Secure Shell (SSH) and Simple Network Management (SNMP) must be enabled a
configured properly, since APIC-EM uses these protocols to get information from or upload
configuration to them. Both SNMPv2 and SNMPv3 are available, but the latter is advisable due
to security considerations. SNMPv3 allows using security features like authentication,
encryption and privacy. SNMPv3 is used in this case.

The development of the connections between the routers and the APIC-EM controller works
in two ways and both are usable. The first and convenient way is to use the APIC-EM discovery
process. This function needs an IP range or more ranges to scan and proper credentials for
SSH and SNMPv2 or SNMPv3. The other method is a manual adding process, which means
that all routers must be added one by one with credential information, and IP addresses. Once
all routers are discovered then all should be in “Managed” state in the device inventory Figure
19.

Figure 19: Partial Device Inventory

After all necessary routers are managed (MC, BR1, BR2 and Gateway) the next two phases
are to set up HUB and then Branch site using the GUI interface of the IWAN application within
the APIC-EM. In order to have the HUB site a few parameters must be taken into account such

43
as the number of the Service Providers, decision of the type of the Brach site, DMVPN and
various IP address pools or the propagation of data center network prefixes. All of the
mentioned settings and parameters are properly explained here [58] and here [57] as well. The
Thesis Test Environment uses two Service Providers to form the possibility to choose
Application Path Preference over two connections that appear as links between
Gateway and the Border routers.

After having the HUB site up and running the Brach site preparation follows that also
requires certain settings to do and decisions to be made based on various factors that are
documented in [57], [58]. In the Test Environment, the Branch site connects through Layer 3
method with the HUB site, which adds the possibility to push routing information toward the
HUB site about Brach routers and their networks. All existing dynamic routing protocols and
redistributions are depicted on Figure 20 used in the case of Thesis.

Figure 20: Dynamic routing protocols and redistributions

EIGRP with AS number 1 is for distributing routing information between test environment
and outside network and offers the possibility to reach the test environment from anywhere.

44
For instance, to connect to a specific router in the EVE-NG network. EIGRP AS 2 is for
redistributing networks connected with the HUB site toward Branch site. For instance, a HUB
site might contain one or more Datacentres network and they are required to be reachable
from the Branch site. In this case, it establishes the connection between the physical and the
virtual environment. EGRP AS 400 is for the redistribution networks between the HUB and
Branch site and it is created and maintained by the IWAN application. Lastly, OSPF collects
all routing information within the Brach site. It can be any other routing protocols such as other
BGP, EIGRP or even static. The reason of using different areas like zero, one and two is
because core and distributions routers are connected via point-to-point interfaces and in that
case having only area 0 is not an option.

The last phase after the successful deployment of the Brach site is to add all remaining
active devices reside on Brach site to the APIC-EM, which make the inventory encompass
more devices (Figure 21).

Figure 21: Full Device Inventory

45
4 Application Functions
It is important to lay down the Android SDN-NM application functions in detail in the next
chapters besides the short version mentioned in chapter 1.2. Table 5 summarizes the
functions.

Function Name Detail

List the names, IP addresses and Software Version numbers of all


Inventory
devices in pre-defined locations known by the SDN controller

Display the devices and connections of all devices in pre-defined


locations known by the SDN controller.
Topology
Display the names and IP addresses of the connected interfaces within
a connection if selected.

Change application path preference between two Internet Service


Policy Routing
Providers for three application classes

Settings Change controller IP address, port, username and password

Table 5: Application Functions

The „Inventory” function is for displays all active devices within a selected location. The
location information is assigned to a particular devices in the APIC-EM in order to distinguish
geographical information. Selecting a device lists its full particulars.

The “Topology” visualize the network topology in a particular location and differentiate
routed and layer2 links by painting them with different colours. Tapping on either active devices
or links displays the device or link information in detail.

The “Policy Routing” let the user to use different Internet Service Provider group of
applications at the Branch site.

“Settings” menu allows the user to change the APIC-EM connection parameters such as its
IP address and port to connect to. Also, let to modify the authentication data like the username
and password.

The distinction of certain application is taken place by their transport protocol characteristic.
Every application class might contain one or more class members and each class member has
its own feature. In this case, their properties are based on the destination port and protocol.

46
Not only can these properties be the base of the differentiation but other characteristics as well
such as URL, Differentiated Services Code Point (DSCP) and Layer 3 information. Table 6
unfolds the protocols under Application Classes.

Class
Class Members Class member detail
Name

ping ip protocol 1

net-admin telnet destination tcp port is 23

ssh destination tcp port is 22

browsing http destination tcp port is 80

ftp destination tcp port is 21, 21000


file-
sharing destination tcp port is 20,21, 21000
ftp-data
destination udp port is 20

Table 6: Protocols of the Application Classes

The selection of these protocols is because these applications are easy to evaluate. For
instance, it is convenient to install and test ftp, apache or samba services within the network
by using tiny Linux operating system distributions. The port selections of the applications are
based on their descriptions.

4.1 Extraction of inventory information

Routers and switches are constantly being replaced, removed or added from or to the
device inventory of the enterprise; hence the changes are hard to follow. Ordinary Network
Management Software helps the issues, but usually requires trained users. In these days,
mobile phones are integral parts of the human daily life. Accounting or logistic personnel use
these devices as work instruments keeping the diary in mind or answering messages and
emails as well. Getting instant information about a device whereabouts or existence is
sometimes crucial.

Android SDN-NM gives the opportunity to reach that data with a simple tab on the mobile
phone. At this moment the Android SDN gives the name, type and the IOS version back and
displays in a simple way, but the possibilities of the available data are numerous such as
location information, serial number, device family, role in the network, MAC address, uptime
information, hostname, ip address, memory size, platform and various status data as well. The
Android SDN-NM retrieves information by querying the controller inventory data using REST

47
API northbound protocol. This is similar to a simple http query and easy to nest inside higher
developer language. The APIC-EM SDN controller is responsible to query proactively and keep
network information up to date by using southbound protocols like SSH and SNMPv3.

4.2 Drawing of network topology

Visualizing the network devices and their connections together with necessary device
information and link details between them is a powerful knowledge in network engineers’
hands. Knowing how and what connects with what usually reduces required maintenance,
troubleshooting, debugging and planning resources as well. Drawing the topology with bare
hand with external software is time consuming, requires company policy that informs engineers
about all changes instantly and asserts regular updates on the topology documents. The
Android SDN-NM displays the topology and provides device information and link details by
tapping either the device or the link. Device information includes type ,serial number , device
family, device role, MAC address, software version, uptime, device series, location, hostname,
last updated, boot time, collection status, interface count, linecard count, management IP
address, memory size, platform id and reachability status. Link details consist of IP addresses,
subnet masks, interface names, and the link speeds. The data query method is the same as
what the previous function “name of function” uses (see chapter 4.1). For displaying the
topology, the Android SDN-NM applies a procedure which distributes the devices on an inner
curve of a circle evenly. The radius of the circle is determined by the used mobile phone display
and is usually the half of the shorter side’s dimension. Every information and draw is inside of
this circle toward the centre of the circle visualized horizontally. The number of the devices
stipulates the spin degree between two devices. Unfortunately, the size and the resolution of
the display limits the number of the devices to be visualized. The number of selected protocols
within an application is arbitrary, but useful in case the application function is being proved.

4.3 Change of Application Path Preference

Contracts with Service providers may cause unexpected issues and the agreements show
wide variances. For instance, company may pay by the number of bytes they used on a
physical link to connect to the Internet, or the average links speed they got. Even an ongoing
contract has variable conditions that influence the network reliability or the monthly fee as well.
Changing the routes within a network or distinguish data paths among various applications
definitely necessitates highly qualified network engineers and poses potential issues caused
by human errors. Offering an application that executes such changes based on business
decisions and eliminating the outlined error factors might be the approach of the future.

48
Defining the protocols used by an application and setting the Service Provider path for that
application are available options in APIC-EM controller. The mobile application influences the
IWAN module of APIC-EM. It sends REST calls to APIC-EM and influences which path is taken
for the application. Also lets the user select three well-defined applications class paths between
two imaginary Service Providers with a single tap.

4.4 Development of application functions

The following chapters demonstrates the use of RESP APIs in all function of the mobile
application and shows basic information of the programming procedure.

4.4.1 REST APIs

In order to accomplish the application functions every function requires to use one or more
REST API calls to get data from or to pass to APIC-EM. Discovering possible response values
and the data model is realizable by using the interactive interface of the APIC-EM called
swagger, where all possible REST APIs are available. The interface is accessible by opening
the URL https://ip-address-of-apic-em/swagger web page through a browser or by reading the
APIC-EM API reference [59]. In addition, an authentication must be used in order to get
responses from the APIC-EM controller using REST API calls. APIC-EM offers the so-called
Service Ticket or as known as token method. This method is used to create a new user ticket
and the response data is used as a basic of all other REST API calls. Here Table 7 is a list of
all REST API calls used by particular application function.

Function REST API Method REST API Call

Inventory POST /ticket

GET /network-device

Topology POST /ticket

GET /physical-topology

Policy Update POST /ticket

GET /policy

POST /policy/diff

Table 7: Functions and their REST APIs

49
A. TOKEN REST API

This given token is used as the value of a header key of the other REST API calls. To get
this ticket a REST API post request is required. Besides the value, the token has session and
idle timeout parameters for security reasons. This request has a header key and value pair to
determine the content type of the request, In this case it define that the body of this post request
is in JSON format. This process is depicted on Figure 22

Figure 22: Token REST API

50
The „serviceTicket“value is the token and used as header parameters for further RESP API
calls. In this case, this token is „ ST-290-uFAKg7DKiYifzwBCv0aa-cas “.

B. Inventory REST API

The first function of the application is listing the inventory. To do this the following request
should be sent and alternatively contains the following parameters which depicted on Figure
23.

Figure 23: Inventory REST API

51
As Figure 23 shows that the previous ticket REST API response is used as a header value
for X-Auth-Token parameter and realize the authentication process. The response for
Inventory REST API contains a list of all network devices together with their information in
JSON format. For instance, location, serial number, hostname and many more. These
response data will be de-serialized and stored by the application for further process and display
as well.

C. Topology REST API

This chapter explains the REST API calls in order to have the topology data. The function
Visualization of the topology in the Android SDN-NM has three sub-functions. Firstly, it
visualizes the whole topology including the links and displays minimal information about the
connected devices. Secondly, after selecting a particular device it lists information about it.
Finally, after selecting a link it shows the link information.

Getting the topology and drawing the nodes and links the REST API “get physical topology”
call is sufficient. The response falls into two parts. The first part describes node information
participating in the topology and the second gives data about the links between them. An
example with a few details of a response body of the get topology REST API call is shown in
Figure 24

52
Figure 24: Topology REST API

53
The responses about nodes are depicted with orange colours and link data with blue. Both
nodes and links details have IDs. In this case one of the node has "314a378c-2ad9-4d10-
9aad-94f3856fac34” id and link has “502502”. These IDs will be used in the subsequent
queries to get information about that particular node or link.

Displaying information about a chosen device requires an additional REST API query. This
query use the previously mentioned is as parameter to get node information and depicted on
Figure 25 and the device ID inserted at the end of the endpoint information to get data only
about that particular node which is represented by that ID.

Figure 25: One Node Inventory REST API

54
It sends back almost the same reply as the inventory query, but only for that specified
device. Lastly, displaying the link information the first topology query is enough, since its
response contains all data about a selected link such as port names, IP addresses and subnet
masks and depicted on Figure 24 with blue colour.

D. Application Path Preference REST API

Setting path preferences for chosen application classes and displaying them in the
application requires two types of REST API requests. The first one is to get the actual state of
these application classes and the second is to apply the selected policy based on the user’s
command.

A response of a general policy request contains all kind of policies within APIC-EM. For
instance for QoS services and as in this case for the IWAN application. As the mobile
application uses only the IWAN policy the general policy request is restricted to get only the
policy belongs to IWAN and depicted on Figure 26.

55
Figure 26: Get Policy REST API

56
This response contains path preferences about all application classes. However, the mobile
application uses only to determine the paths for application classes such as net-admin, file-
sharing or browsing. Hence, after the successful de-serialization, the data is filtered to store
only about net-admin, file-sharing and browsing application class information. These data
are in this case the values of “PrimaryPathPref” and “SecondaryPathPref” parameters and
can be either ISP1 or ISP2. Only these application classes are displayed for the user in order
to change them and they are depicted on Figure 27. This example shows ISP2 for net-admin
and file-sharing application classes and ISP1 for browsing.

Figure 27: Policy Change Screen

The APIC-EM let the use of changing the policy in two ways. The first way is to define the
whole policy and include all data. The second way is only to define the difference, which is
used in this case. After the user selects the desired path for an application class, the
enforcement of the policy by a REST API call is depicted on Figure 28 as an example. This
example shows data to be passed to change the primary path for this application class using
policy update REST API call.

57
Figure 28: Push Policy Diff REST API

58
The response body in this case is the ID of the task to apply this policy change and can be
queried its state by the URL provided in the response as well.

4.4.2 Android Studio

This chapter describes the processes, data store and displaying techniques within Android
Studio, which is the development environment of the Android SDN-NM application. Firstly, this
chapter shows how the various functions appear and the Android Studio forms these functions.
Secondly, how to take care of getting, storing or renewing data from or to APIC-EM and how
the application retrieves that information. Finally, how the processes (threads) work to
implement the particular function.

A. Activities

Activities in Android Studio are a representation of a function to be materialized. An activity


is also a single, focused thing that the user can do and almost all activities interact with the
user. Technically, they contain processes (threads) and visualization information by using XML
descriptors. The program comprises one main and other activities. The main activity is to
display the start-up screen, where all the distinct functions and the setting menu reside. The
Inventory activity prepare to list inventory data. The topology activity visualises the physical
topology of the network and contains two sub activities such as the node and link information,
that - as the names suggest – provides detailed network device and link parameters. The policy
routing realises the Application Path Preference function. The settings activity allows setting
IP address, port, username and password to authenticate the user with a specific APIC-EM
controller. All activities and their connected functions are depicted in Figure 29.

59
Figure 29: Android Studio Activities and Functions

B. Data

It is important to understand the retrieval and storage procedures applied in the


programming phase and it is worth to be split into two distinct pieces. The first procedure
describes the external, the second the internal data flows. The first is to download or upload
and store locally on the mobile device the data from or to the APIC-EM. The first part also
demonstrates the transformation of the data between REST API JSON and the application
object data. The second – internal – represent the data flow within the application itself. For
instance, is to retrieve data from objects to display or store to application object provided by
user input.

The response to a REST API GET query has a well-defined structure. However, to read the
data provided by the output of a particular REST API response it must be de-serialized, since
the response itself is just a flow of information. Figure 30

60
Figure 30: Android Application External Data Flow

In turn, uploading the data requires serialization. These procedures are depicted on Figure
30. Storing or retrieving the data locally between the program and its local inventory object
requires classes to be implemented. This data movement between object and the display or
user input are depicted on Figure 31.

Figure 31: Android Application Internal Data Flow

A particular child object is assigned to every REST API responses or body to represent the
de-serialized data. In addition, every child object is attached to a particular activity. The child
objects are depicted on Figure 32.

61
Figure 32: Android Studio Object Classes for data

C. Relations between functions, requests and objects

When the list inventory function is executed – inventory activity and sub-activity like nodes
activity - the program checks at first the validity of the Service Ticket. If not valid, then request
for a new one and passes it to the network device and location retrieval REST API request to
use as header. Both queries responses are stored into their respective child objects, which are
used for displaying the list of devices. If the user select a particular device the nodes activity
is opened, where the already locally stored data is retrieved for – retrieved by the previous
inventory activity - that particular device. Both process are depicted on Figure 33.

62
Figure 33: Inventory Activities Interrelations

Correspondingly, to the previous process the topology visualization happens in the same
way that depicted on Figure 34.

Figure 34: Topology Activities Correlations

Lastly, the policy routing activities correlations are depicted on Figure 35.

Figure 35: Policy Routing Activities Correlations

63
During the settings activity data transformation or REST API query does not happen. Those
inputs are stored in local variables instead of child objects.

D. Threads

There are two kinds of processes – called threads in Android Studio –, which play important
roles in the application. The first is the so-called UserInterfaceThread (UI Thread), which has
the only right to write on the mobile phone display and it has access to call other threads. The
second thread is the WorkingThread, which is called by UIThread that is responsible for
network communication. It executes REST API calls, serializes or de-serializes data, stores
and retrieves data locally and passes control back to UIThread, which gets and displays the
particular function (activity).

It is very important to note that running REST API calls require a service ticket in order to
successfully authenticate with the APIC-EM controller. This ticket must be part of the header
of any further REST API calls. The WorkingThread always checks the existence or the validity
of the ServiceTicket. If the ServiceTicket is missing or expired, WorkingThread requests a new
one.

E. Threads within activities

When a certain window is opened (start-up, settings, topology, policy, node, link), a related
activity starts. The activity calls the OnCreate command [60] that called when the activity is
starting. This is where most initialization usually goes and which generates the UIthread. Then
UITherad calls the WorkingThread, which executes REST API queries. Next, serialization or
de-serialization and storing commands are executed and the WorkingThread gives back the
control to UIThread. The UIThread get the relevant data for the activity and displays them. In
order to understand the procedures better, the process of the policy update is depicted
exemplarily in Figure 36.

64
Figure 36: Android Application Policy Update Procedure

65
All other procedure work in the same way, but they use other child objects that correspond
to that particular process. Usually in all procedure the UITread – where user inputs and
visualizations happen – calls the WorkingThread – where network communications happen -,
that runs the Service Ticket validity process, query the APIC-EM, de-serialize the given data
and store them locally into the corresponding child object of particular activity. Then the
WorkingThread gives the control back to UIThread that load the data from the local child object
and displays them.

66
5 Presentation and verification of application
functions
Presentation and verification of the Android SDN-NM application is separated into two
distinctive fractions. The first one is to demonstrate the operation of the selected function of
the Android SDN-NM application. The second one is to prove that the displayed result does
correspond to reality. In order to have those the Thesis uses various sources such as
Wireshark captures, router logs, APIC-EM logs and screen captures.

5.1 Inventory Function

The presentation of the first function – List the inventory – takes place at first by opening
the application and tapping the Inventory sign as depicted in Figure 37.

Figure 37: Start-up Screen of the Android SDN-NM Application

This functions list the inventory as shown on Figure 38 with the possibility of changing the
location.

67
Figure 38: Inventory Screen of the Android SDN-NM Application

At this function, the network device REST API call retrieves data from the APIC-EM and
depicted on Figure 39.

68
Figure 39: Inventory Request

The request URL – endpoint – is https://82.150.42.74/api/v1/network-device, where


82.150.42.74 is the IP address of the APIC-EM. The response contains all network devices
managed by APIC-EM. The response is in JSON format and has the following formats listed
in Table 8.

69
NetworkDeviceResult {

version (string),

response (NetworkDeviceDTO)
}

NetworkDeviceDTO1 {

location (string): Location ID that is associated with the device,

type (string): Type of device as switch, router, wireless lan controller, accesspoints,

serialNumber (string): Serial number of device,

family (string): Family of device as switch, router, wireless lan controller, accesspoints,
errorCode (string): Inventory status error code,

role (string): Role of device as access, distribution, border router, core,


macAddress (string): MAC address of device,

softwareVersion (string): Software version on the device,

inventoryStatusDetail (string): Status detail of inventory sync,

collectionInterval (string),

upTime (string): Time that shows for how long the device has been up,

series (string): Device series,


lastUpdateTime (date-time),

locationName (string): Name of the associated location,

tagCount (string): Number of tags associated with the device,

hostname (string): Device name,

errorDescription (string): Inventory status description,


lastUpdated (string): Time when the network device info last got updated,

roleSource (string): Role source as manual / auto,

apManagerInterfaceIp (string): IP address of WLC on AP manager interface,

bootDateTime (string): Device boot time,

collectionStatus (string): Collection status as Synchronizing, Could not synchronize, Not manageable, Managed, Partial Collection
Failure, Incomplete, Unreachable, Wrong credential, Reachable, In Progress,
interfaceCount (string): Number of interfaces on the device,

lineCardId (string): IDs of linecards of the device,

managementIpAddress (string): IP address of the device,

memorySize (string): Processor memory size,


platformId (string): Platform ID of device,

reachabilityFailureReason (string): Failure reason for unreachable devices,

reachabilityStatus (string): Device reachability status as Reachable / Unreachable,


snmpContact (string): SNMP contact on device,

snmpLocation (string): SNMP location on device,

tunnelUdpPort (string): Mobility protocol port is stored as tunneludpport for WLC,

instanceUuid (string),

id (string)

},
NetworkDeviceDTO2

Table 8: Device Inventory Response Model

70
Every NetworkDeviceDTO describes a network device and for instance has the following
response depicted on Table 9.

"location": "2a914485-fd17-4ea7-921a-e41503ac1915",
"type": "Cisco Cloud Services Router 1000V",
"serialNumber": "925V6RE7X5M",
"family": "Routers",
"errorCode": null,
"role": "BORDER ROUTER",
"lastUpdateTime": 1527498795379,
"macAddress": "00:1e:bd:b4:98:00",
"softwareVersion": "16.3.5",
"collectionInterval": "Global Default",
"upTime": "34 days, 1:18:00.80",
"series": "Cisco Cloud Services Router 1000V Series",
"locationName": "Wien",
"hostname": "BR1.sdn.local",
"errorDescription": null,
"lastUpdated": "2018-05-28 09:13:15",
"roleSource": "AUTO",
"apManagerInterfaceIp": "",
"bootDateTime": "2018-02-06 09:43:52",
"collectionStatus": "Managed",
"interfaceCount": "10",
"lineCardCount": "2",
"lineCardId": "4a0b648b-a2ee-4c0e-bcf5-a25aafb68356,
"managementIpAddress": "10.0.135.2",
"memorySize": "1103530520",
"platformId": "CSR1000V",
"reachabilityFailureReason": "",
"reachabilityStatus": "Reachable",
"snmpContact": "",
"snmpLocation": "",
"tunnelUdpPort": null,
"instanceUuid": "31e12dad-4ae8-47fd-93bd-1b9e8b077988",
"id": "31e12dad-4ae8-47fd-93bd-1b9e8b077988"

Table 9: Inventory Response Example

71
This function also let the user lists network devices residing on specific locations. Location
parameter of a device can be set in the APIC-EM as depicted on Figure 40.

Figure 40: APIC-EM Location Settings

In order to give an example the operation of location specific inventory list the following
procedure is executed:

72
1. Creation of a new location named as New York Figure 41

Figure 41: New York Location Creation

2. Set MC.sdl.local routers location to New York Figure 42

Figure 42: Set Location for Device

73
3. List inventory in APIC-EM Figure 43

Figure 43: List Inventory in APIC-EM with New York location

4. List the Inventory with the mobile application within New York location Figure 44

Figure 44: New York Inventory

74
It is also possible to get detailed information by tapping a particular device and it gives back
the following information that depicted on.

Figure 45: Particular Detailed Device Information

This information require comparing with output of the „show version” command on the
device Figure 46.

75
Figure 46: Output of "Show version" command

76
5.2 Topology Function

This function displays the topology either within a selected location or within all location,
Similarly, the previous function this also retrieves information from APIC-EM via REST API
call, but this time it queries the topology data. It is depicted on Figure 47.

Figure 47: Topology request

The request URL – endpoint – is https://82.150.42.74/api/v1/physical-toplogy, where


82.150.42.74 is the IP address of the APIC-EM. The response contains all network devices
managed by APIC-EM. The response is in JSON format and has the following formats listed
in Table 10.

77
}
Topology {

links (array[LinkWrapper]): List of link between devices,


nodes (array[NodeWrapper]): List of devices and hosts,

id (string, optional)

}
LinkWrapper {

endPortID (string): Device port ID corresponding to end devices,

startPortID (string): Device port ID corresponding to start devices,

greyOut (boolean): Device greyout,


source (string): Device ID correspondng to the source device ,

target (string): Device ID corresponding to the target device,


id (string): Unified identifier for device,

tag (string): Tag for the devices,

linkStatus (string): Indicates whether link is working,

endPortName (string): Interface port name corresponding to end devices,


endPortSpeed (string): Interface port speed corresponding to end devices,

startPortName (string): Interface port name corresponding to start devices,


startPortSpeed (string): Interface port speed corresponding to start devices,

endPortIpv4Address (string): Interface port IPv4 address corresponding to end devices,

endPortIpv4Mask (string): Interface port IPv4 mask corresponding to end devices,

startPortIpv4Address (string): Interface port IPv4 address corresponding to start devices,

startPortIpv4Mask (string): Interface port IPv4 mask corresponding to start devices


}
NodeWrapper {

dataPathId (string, optional): ID of the path between devices,

aclApplied (boolean): Indicates if the ACL that is applied on the device,

fixed (boolean): Indication of whether the position is fixed or will use auto layout ,

tags (array[string]): List of tags applied on this device,


id (string): Unique identifier for device,

order (integer, optional): Device order by link number,

role (string): Role of the device,

deviceType (string): Type of the device,

softwareVersion (string, optional): Device OS version,

networkType (string, optional): Type of network,

osType (string, optional): OS type of the device,


userId (string, optional): ID of the host ,

family (string): Product family which is part of the product identifier,

vlanId (string): VLan id,

platformId (string): Device platform description,

rip (string): IP address of the device,

nodeType (string): Host or device,


label (string): Hostname of the device,

y (integer): Y position of the device on the displayed topology view,


x (integer): X position of the device on the displayed topology view,

upperNode (string, optional): Start node ID


}

Table 10: Topology response model

78
The response contains node and link information as well and here is an example in Table
11.

"response": {
"nodes": [
{
"deviceType": "Cisco GatewayServer",
"label": "Branch-Core1.sdn.local",
"ip": "10.0.8.9",
"softwareVersion": "15.4(2)T4",
"nodeType": "device",
"family": "Routers",
"platformId": "UNKNOWN",
"tags": [],
"role": "DISTRIBUTION",
"roleSource": "AUTO",
"customParam": {},
"id"
.
.
.
"links": [
{
"source": "314a378c-2ad9-4d10-9aad-94f3856fac34",
"startPortID": "b1aadd60-2076-49e4-95bd-fdd1076fcba8",
"startPortName": "Ethernet0/3",
"startPortIpv4Address": "10.0.8.9",
"startPortIpv4Mask": "255.255.255.0",
"startPortSpeed": "10000",
"target": "51ff227e-9f71-454f-94ac-6344fc9f2de0",
"endPortID": "7fae867e-bb77-4c89-8b80-18981b16caa2",
"endPortName": "Ethernet0/1",
"endPortSpeed": "10000",
"linkStatus": "up",
"id": "502502"
},

Table 11: Topology response example

79
This function also let the user to select location and displays only the topology within that
selected location. Also offers to display detailed node information by tapping a particular device
or list link data by selecting a specific link.

The demonstration of this function firstly requires to modify two nodes locations as New
York and display the New York topology. Then add two and later one more node to this location
and displays again the topology.

Here is the topology with two nodes (Branch-Switch.sdn.local, Branch-Core1.sdn.local) in


New York location Figure 48.

Figure 48: Topology with two nodes

80
After changing Branch-Core2.sdn.local and Branch-Dist1.sdn.local routers locations to New
York the topology shows the following. Figure 49

Figure 49: Topology with four nodes

Lastly, here is with five nodes Figure 50.

Figure 50: Topology with five nodes

81
The topology draw uses circle approach for visualization. This means that all nodes to be
displayed are placed evenly along a circle. The radius of this circle is the half of the shorter
dimension of the screen. This let the user rotate the screen while displaying the topology.

The node selection and data appearance take place in the same way as described in the
inventory function. However, tapping a link display link information as well and depicted on
Figure 51. This link information is between Branch-Core1 and Branch-Core2 routers.

Figure 51: Link Information

To add proof both routers are queried with show interface commands and they are depicted
on Figure 52.

Figure 52: Show Interface Command Outputs

82
5.3 Application Path Preference Function

The policy update function has two parts, the first part displays the current state of the
application path preferences, while the second applies and pushes the policy that is modified
by user interaction.

A. Policy Retrieval

The policy retrieval communication is depicted on Figure 53.

Figure 53: Policy Request

The request URL – endpoint – is


https://82.150.42.74/api/v1/policy?policyScope=IWAN, where 82.150.42.74 is the IP
address of the APIC-EM. The response contains all policy settings within IWAN policy
by APIC-EM. The response is in JSON format and has the following formats and an
example is depicted here Table 12.

83
"instanceUuid": "e6901ecf-d0c0-42f1-8292-e2ea1d592490",
"policyName": "voice-and-video",
"policyPriority": 64,
"state": "Active",
"taskId": "adbb2f9e-63aa-46e5-8a7c-4bf04d4db2c2",
"id": "e6901ecf-d0c0-42f1-8292-e2ea1d592490",
"resource": {
"categories": [
{
"id": "e156ff72-30a0-43dd-a27e-d8ef1958993f",
"name": "voice-and-video"
}
]
},
"actions": [
"SET_PROPERTY"
],
"actionProperty": {
"relevanceLevel": "Business-Relevant",
"hostTrackingControlFlag": false,
"fastlaneControlFlag": false,
"easyQosMonitoringFlag": false,
"pathControlFlag": true,
"pathPreferenceFlag": true,
"PrimaryPathPref": [
"ISP1"
],
"SecondaryPathPref": [
"ISP2"
]
},
"policyScope": "IWAN"
},

Table 12: Policy Example

84
The screen shows the following on the mobile application Figure 54.

Figure 54: Policy Screen

A. Policy Update

When the user change one or more application path preferences and hit the apply button
then the following communication takes place between the mobile application and the APIC-
EM. It is depicted on Figure 55.

85
Figure 55: Policy Update Communication

The request URL this time is https://82.150.42.74/api/v1/policy/diff ,but the method is POST,
that requires data in the body. The data requires containing only those objects on which the
modification is requested. Within an object, „optional” data can be omitted. The following body
example changes net-admin application class path preference to ISP2 (Table 13).

86
"policies": [
{
"operation": "UPDATE",
"policy": {
"instanceUuid": "9c7cc852-a921-4fef-86ee-1d5e5d0c7cd6",
"policyName": "net-admin",
"policyPriority": 64,
"networkUser": {},
"state": "Active",
"id": "9c7cc852-a921-4fef-86ee-1d5e5d0c7cd6",
"resource": {
"categories": [
{
"id": "7ddb658f-2f2f-44cb-9ef7-a11d781fc880",
"name": "net-admin"
}
]
},
"actions": [
"SET_PROPERTY"
],
"policyScope": "IWAN",
"actionProperty": {
"relevanceLevel": "Default",
"hostTrackingControlFlag": false,
"fastlaneControlFlag": false,
"easyQosMonitoringFlag": false,
"pathControlFlag": true,
"pathPreferenceFlag": true,
"PrimaryPathPref": [
"ISP2"
],
"SecondaryPathPref": [
"ISP1"
]
}
},
"changeList": []
},

Table 13: Policy Update Body example

87
The modification of policy also means that APIC-EM connect to routers and change their
configurations as well. This communication is documented on the following picture (Figure 56).

Figure 56: Policy Update Changes on Routers

This communication show SSH communication between routers and the APIC-EM within
the network, and show that a policy is downloaded. The APIC-EM log also shows the execution
of the policy update with the same time entries as the routers (Figure 57). The two hours
differences is due to the different time zone usage of the routers and APIC-EM. Between
tapping the “apply” and the appearance of the policy download on the routers take around
twenty seconds.

Figure 57: APIC-EM log

88
6 Conclusion
Traditional networks have limitations about gaining information from them or modifying their
behaviour to be in accordance with various business needs. Both information gathering and
changing processes are time consuming.

Software-defined networking (SDN) is a novel approach to solve these issues by offering


standard interfaces for programs to change or query networks. SDN also provides controllers
to enforce policies or retrieve information from network devices that are formulated by
applications. Using properly developed and tested programs reduces network information
collection, modification time and issues.

The Thesis demonstrates the development of such application on Android platform. It offers
insight how RESP API queries are formulated and embedded in software development
environment. It also proves that using the developed SDN-NM application reduces the time
spent on gaining information or changing the behaviour. The SDN-NM application has simple
appearance, works together with Cisco APIC-EM SDN controller in harmony, which allows
anyone without technical knowledge to use it. It is also capable to display data or change
network configuration within a short time. On the other hand, it has a disadvantage about
drawing topologies that contain large number of active devices, since mobile displays are
limited in size and resolutions.

Obtainment of information about network devices, visualization of the network topology,


listing IP addresses of network links and alteration of data path are integral parts of network
operators. This Thesis introduces a program and its development to support such activities
and to extend the existing functions.

6.1 Future Development

The solution of this Thesis can be developed further in many ways such as with the
improvement of existent functions, development of new functions and selection of different
controller or application platforms.

Firstly, the Inventory List function requires to show more information about network devices
for instance serial number or device family. Most importantly this function asks for search
capability to find information about devices based on advanced queries. For instance, finding
the device with the highest uptime. Secondly, the topology visualization screen should be able
to be resized or be movable by finger movements. Enabling to export the topology is also worth
considering. Lastly, it would be preferable to have all application classes included and variable.

89
The next phase of future development is to invent new functions based on the RESP API
capabilities of the APIC-EM or other - even not proprietary - controller like Opendaylight. These
functions might be device configuration export, QoS settings capability, advanced topology
view and many more. As controllers have more REST APIs, more functions can be
implemented.

It is also important to emphasize the development of such applications on different platforms


such as Windows or IOS. Furthermore, a proper approach might be to develop these
applications as back-end solutions and in this way to offer client platform independent
solutions.

Not only do SDN controllers have a REST API northbound interface, but individual devices
as well. For instance, Cisco Adaptive Security Appliance (ASA) firewall and Cisco Prime
Infrastructure and devices from Open Source communities like OpenDaylight [30] have plenty
of capabilities over REST API to implement configurations, handle network situations, issues
or retrieve information about devices. It seems that almost every manufacturer’s product has
a built-in REST API interface nowadays, which aids the possibility of appearance of Mobile or
Computer application in order to interfere the operation of networks. Beyond the obvious
modification and query reasons these applications carry the possibilities of the “in case of”
intervening. This means that, running these applications on back-end platforms and constantly
observing the network parameters, it allows to modify certain operating settings when certain
parameters reach certain values. For instance, changing the Service Provider path in the case
of a QoS threshold. Also, the author of this Thesis is committed to develop a topology
visualization software for browsers running on a back-end software such as Apache.

6.2 Economic considerations

The current economic situation of the western world seems to be in ascending stage. From
day to day more businesses appear on the market and shareholders are confident. United
Nation’s report [61] describes that economic growth in developed countries strengthened
within the last decade. The research also states that the global economy faces labour market
challenges. There are concerns about the sufficient generation of highly trained workers in the
IT industry, which generates the necessity of automation. Companies with Developer
Operation portfolio have numerous purchase orders and they have become inevitable. The
shortage of highly qualified labour infers the necessity for programs that execute special tasks.

The market of the Information Technology seems to be in a growing phase [62]. The
information needs and the progressiveness of logistics generate the importance of data and

90
information technology. Networks have become larger and more complex and hard to keep
them transparent. Maintenance challenges, network issues and data losses make the whole
IT operation and development difficult to finance. As the complexity and scale of networks turn
into larger, the knowledge of the engineers gets more important and more expensive as well.
Salaries have risen within networking industry [63], and even unexperienced engineers have
high claims, which generates higher costs and lower margins for system integrators.

To cope with these tendencies the spread of SDN systems, automation techniques together
with small assistant programs that run on mobile devices, tablets or laptop’s browsers might
be the right course. Having the opportunity to modify the network of getting data instantly
without the occupation of an expensive employee might create better circumstances for
companies. Not only do large companies suffer from the lack of intelligent operative, but so do
middle-sized and even small firms. The desirable concept is to bring forth the possibility of
growth without losing profit by using small Network Management programs.

Taking everything into account it is definitely worth spending on and developing small
Network Management application with the new SND approach.

91
7 Bibliography

[1] 1. Characterization of Failures in an Operational. Athina Markopoulou, Gianluca Iannaccone, upratik


Bhattacharyya, Chen-Nee Chuah, Yashar Ganjali and Christophe Diot. Aug, 2008, EEE/ACM Transactions on
Networking, Vol. 16, pp. 749-762.

[2] 2. Delayed internet routing convergence. C. Labovitz, A. Ahuja, A. Bose, and F. Jahanian. 2001 Jun,
IEEE/ACM Trans. Netw., Vol. 9, pp. 293-306.

[3] 3. Hoff, T. Latency is everywhere and it costs you sales - how to crush it. [Online] 2009 Jul. [Cited: 13 April
2018.] http://highscalability.com/blog/2009/7/25/latency-is- everywhere-and-it-costs-you-sales-how-to-crush-it.html.

[4] 4. Gray, George. What’s Your Netwrok Cost? Connecticut, USA : GENERAL DATACOMM, 2009.

[5] 5. Computer Weekly. UK IT Priorities 2018. UK : Computer Weekly, 2018.

[6] 6. McKeown, Nick. How SDN will Shape Networking. [Online] Youtube. [Cited: 09 April 2018.]
https://www.youtube.com/watch?v=c9-K5O_qYgA.

[7] 7. Rathore, Deven. 10 Best Android Terminal Emulator. [Online] DuneBook. [Cited: 13 05 2018.]
https://www.dunebook.com/10-best-android-terminal-emulator/.

[8] 8. Theophilus Benson, Aditya Akella. Unraveling the Complexity of Network Management. University of
Wisconsin, Madison : Microsoft Research, 2009.

[9] 9. Software-Defined Networking: A Comprehensive Survey. Diego Kreutz, Fernando M. V. Ramos, Paulo
Esteves Verıssimo, Christian Esteve Rothenberg, Siamak Azodolmolky and Steve Uhlig. 1, 2015 January, Proceedings
of the IEEE, Vol. 13, pp. 14-76.

[10] 10. Ronald G. Addie, Yu Peng, Mostfa Albdair, Chang Xing, David Fatseas, Moshe Zukerman. Cost
modelling and validation in network optimization. Australia : International Telecommunication Networks and Applications
Conference (, 2015.

[11] 11. Cisco. The economics of networking. USA : Cisco, 2011.

[12] 12. PS & Network Downloads. 10 Best Network Monitoring Tools & Software of 2018. [Online] PS & Network
Downloads, 2017. https://www.pcwdld.com/best-network-monitoring-tools-and-software.

[13] 13. Jim Turner, Swami Jayaraman and Tizil Zecheria. Management Intranet: Integrating Web-based Network
Management Applications. USA : IEEE, 2002.

[14] 14. Geier, Eric. 16 essential Android apps for IT pros. [Online] Network World, September 2011.
https://www.networkworld.com/article/2181178/mobile-apps/16-essential-android-apps-for-it-pros.html.

[15] 15. Khrisna, Vamsi. Top 10 Network Monitoring Apps for Android. [Online] Techwiser, october 2016. [Cited: 01
May 2018.] https://techwiser.com/network-monitoring-apps-for-android/.

[16] 16. Get Console. What is Airconsole? - The Only Serial Adaptor You'll Ever Need. [Online] Get Console, 2018.
[Cited: 24 May 2018.] https://www.get-console.com/shop/en/27-airconsole.

[17] 17. Veeraraghavan, Prof. Malathi. Three planes in networks. Virgina, USA : Polytechnic University, 2011.

[18] 18. Ali Ghodsi, Teemu Koponen, Barath Raghavan. Intelligent Design Enables Architectural Evolution.
[Online] Berkeley Education, November14-15 2011. [Cited: 30 04 2018.]
https://people.eecs.berkeley.edu/~alig/papers/intelligent-design-evolution.pdf.

[19] 19. Open signaling for atm, internet and mobile networks (opensig’98). A.T. Campbell, I. Katzela, K. Miki, and
J. Vicente. 1999, ACM SIGCOMM Computer Commun., Vol. 29, pp. 97–108.

[20] 20. Ethane: Taking control of the enterprise. M. Casado, M.J. Freedman, J. Pettit, J. Luo, N. McKeown, and
S. Shenker. 2007, ACM SIGCOMM Computer Commun. Review, Vol. 37, pp. 1–12.

92
[21] 21. A. Doria, J. Hadi Salim, R. Haas, H. Khosravi, W. Wang, L. Dong, R. Gopal, and J. Halpern. Forwarding
and Control Element Separation (ForCES) Protocol Specification. [Online] IETF, March 2010. [Cited: 28 May 2018.]
https://tools.ietf.org/html/rfc5810.

[22] 22. N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J.
Turner. OpenFlow: Enabling Innovation in Campus Networks. New York : ACM SIGCOMM, 2008. ACM SIGCOMM
Computer Communication Review, Vol. 38.

[23] 23. Open Networking Foundation. Software-Defined Networking (SDN) Definition. Open Networking
Foundation. [Online] 2018. [Hivatkozva: 2018. January 10.] https://www.opennetworking.org/sdn-definition/.

[24] 24. Limoncelli, Thomas A. OpenFlow: A Radical New Idea in Networking. [Online] acmqueue, 2012. [Cited: 28
May 2018.] https://queue.acm.org/detail.cfm?id=2305856.

[25] 25. Teemu Koponen, Martin Casado, Natasha Gude, Jeremy Stribling, Leon Poutievski, Min Zhu, Rajiv
Ramanathan. A Distributed Control Platform for Large-scale Production Networks. [Online] 2010. [Cited: 30 04 2018.]
https://www2.cs.duke.edu/courses/fall14/compsci590.4/Papers/onix-osdi.pdf.

[26] 26. Open Networking Foundation. Software-Defined Networking (SDN) Definition. Open Networking
Foundation. [Online] 2018. [Cited: 10 January 2018.] https://www.opennetworking.org/sdn-definition/.

[27] 27. Deering, Sam. Do you know what a REST API is? [Online] Sitepoint, 2012. [Cited: 26 May 2018.]
https://www.sitepoint.com/developers-rest-api/.

[28] 28. Oracle. Java API. [Online] Oracle, 2018. [Cited: 30 May 2018.] https://docs.oracle.com/javase/7/docs/api/.

[29] 29. Hewlett Packard. HP-UX Distributed Systems Administration Utilities (DSAU). [Online] Hewlett Packard,
2014. [Cited: 28 May 2018.]
https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=DSAUtilities.

[30] 30. Opendaylight. Opendaylight Project. Opendaylight Project. [Online] Opendaylight.


https://wiki.opendaylight.org/view/Main_Page.

[31] 31. Open Networking Foundation. OpenFlow Switch Specification. hely nélk. : Open Networking Foundation,
2016.

[32] 32. Cisco. Cisco DNA Center. [Online] Cisco, 2018. [Cited: 30 May 2018.]
https://www.cisco.com/c/en/us/products/cloud-systems-management/dna-center/index.html.

[33] 33. Arista. Virtual Extensible LAN (VXLAN) Overview. Santa Clara, CA 95054 : Arista, 2016.

[34] 34. Cisco. Locator ID Separation Protocol (LISP) Overview. San Jose, CA : Cisco, 2012.

[35] 35. IETF. Network Virtualization Using Generic Routing Encapsulation. [Online] IETF, September 2015. [Cited:
04 May 2018.] https://tools.ietf.org/html/rfc7637.

[36] 36. Dix, John. Clarifying the role of software-defined networking northbound APIs. [Online] Network World, 2
May 2013. [Cited: 14 05 2018.] https://www.networkworld.com/article/2165901/lan-wan/clarifying-the-role-of-software-
defined-networking-northbound-apis.html.

[37] 37. Fielding, Roy. Architectural Styles and the Design of Network-based Software Architectures. [Online] Roy
Fielding, 2000. [Cited: 28 May 2018.] https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

[38] 38. W3C. HTTP - Hypertext Transfer Protocol. [Online] W3C, 2014. [Cited: 28 May 2018.]
https://www.w3.org/Protocols/.

[39] 39. Mayko, Lexy. Structure Constraints to Define or Design It Right. [Online] API2CART, 2017. [Cited: 27 May
2018.] https://api2cart.com/api-technology/rest-api-cheat-sheet-structure-constraints-define-design-wright/.

[40] 40. Subramaniam, Prakash. REST API Design - Resource Modeling. [Online] Thoughtworks, 2014. [Cited: 23
May 2018.] https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling.

[41] 41. Postman. Postman. [Online] Postman, 2018. [Cited: 11 May 2018.] https://www.getpostman.com/.

93
[42] 42. Zhou, Chao. RESTClient, a debugger for RESTful web services. [Online] Firefox, 2018. [Cited: 11 May
2018.] https://addons.mozilla.org/en-US/firefox/addon/restclient/.

[43] 43. MDN. HTTP headers. [Online] MDN, 2018. [Cited: 11 May 2018.] https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers.

[44] 44. ECMA. The JSON Data Interchange Syntax. Ecma International : ECMA, Ecma International, 2017.

[45] 45. Jet Brains. IntelliJ IDEA. [Online] Jet Brains, 2018. [Cited: 06 May 2018.]
https://www.jetbrains.com/idea/?fromMenu.

[46] 46. Lars Vogel, Simon Scholz. The Gradle build system- Tutorial. [Online] Vogella, 09 March 2016. [Cited: 12
05 2018.] http://www.vogella.com/tutorials/Gradle/article.html.

[47] 47. Google. Cloud Tools for Android Studio Documentation. [Online] Google, 2018. [Cited: 14 05 2018.]
https://cloud.google.com/tools/android-studio/docs/.

[48] 48. Distributed Management Task Force, Inc. Open Virtualization Format. [Online] Distributed Management
Task Force, Inc., 2018. [Cited: 30 May 2018.] https://www.dmtf.org/standards/ovf.

[49] 49. Cloud Services Router 1000V - Release Denali-16.3.5. [Online] Cisco, 2018. [Cited: 10 Mach 2018.]
https://software.cisco.com/download/home/284364978/type/282046477/release/Denali-16.3.5.

[50] 50. Cisco. Cisco DEVNET. [Online] Cisco, 2018. [Cited: 10 February 2018.] https://developer.cisco.com/.

[51] 51. Shingledecker, Robert. Tiny Core Linux. [Online] Tiny Core Linux, 2008. [Cited: 20 April 2018.]
http://distro.ibiblio.org/tinycorelinux/.

[52] 52. Cisco Systems, Inc. Cisco Application Policy Infrastructure Controller Enterprise Module Installation Guide,
Release 1.6.x. San Jose, : Cisco Systems, Inc., 2017.

[53] 53. —. Cisco Application Policy Infrastructure Controller Enterprise Module Upgrade Guide, Release 1.6.x. San
Jose, : Cisco Systems, Inc., 2016.

[54] 54. Cisco Systems,. Release Notes for Cisco Application Policy Infrastructure Controller Enterprise Module,
Release 1.6.0.x. San Jose : Cisco Systems,, 2017.

[55] 55. Cisco System Inc. Cisco IWAN Application on APIC-EM Release Notes, Release 1.6.0. [Online] Cisco
System Inc., 24 October 2017. [Cited: 12 04 2018.]
https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Intelligent_WAN/release/notes/1-6-0/iwan-release-notes-1-6-
0.html.

[56] 56. —. Release Notes for Cisco Network Plug and Play, Release 1.6.x. [Online] Cisco System Inc., 16 April
2018. [Cited: 23 April 2018.] https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Plug-and-
Play/release/notes/pnp-release-notes16.html.

[57] 57. Cisco Systems, Inc. Software Configuration Guide for Cisco IWAN on APIC-EM. San Jose : Cisco Systems,
Inc., 2016.

[58] 58. —. Cisco IWAN Application on APIC-EM User. San Jose, CA 95134-1706 : Cisco Systems, Inc., 2017.

[59] 59. Cisco. APIC-EM API Reference. [Online] Cisco Systems Inc. [Cited: 29 04 2018.]
https://developer.cisco.com/site/apic-em-rest-api/.

[60] 60. Android Studio. Activity Android Developer. [Online] Google, 2018. [Cited: 26 May 2018.]
https://developer.android.com/reference/android/app/Activity.html#onCreate(android.os.Bundle).

[61] 61. United Nations. World Economic Situations and Prospects. New York : United Nations, 2018.

[62] 62. CompTIA. IT Industry Outlook 2018. [Online] CompTIA, 2018. [Hivatkozva: 2018. May 28.]
https://www.comptia.org/resources/it-industry-trends-analysis.

94
[63] 63. Statista. IT networking - Statistics & Facts. [Online] Statista, 2018. [Hivatkozva: 2018. 04 29.]
https://www.statista.com/topics/3936/it-networking/.

[64] 64. Cisco Systems, Inc. Cisco Application Policy Infrastructure Controller Enterprise Module. San Jose, CA
95134-1706 : Cisco Systems, Inc., 2017.

[65] 65. —. Cisco Network Visibility Application on APIC-EM User Guide, Release 1.6.0.x. San Jose, CA 95134-
1706 : Cisco Systems, Inc., 2015.

[66] 66. EVE-NG Ltd. Emulated Virtual Environment. [Online] EVE-NG Ltd., 2017. http://eve-
ng.net/index.php/documentation.

[67] 67. Linder, Josh. Cisco Meraki Systems Manager Review. [Online] tom's IT PRO, 2016. October.
http://www.tomsitpro.com/articles/cisco-meraki-systems-manager-review,2-1105.html.

[68] 68. S., Anthony. Meraki Systems Manager Reviews. [Online] G2 Crowd, 2017. August.
https://www.g2crowd.com/products/meraki-systems-manager/reviews.

[69] 69. VMWARE. VMware Compatibility Guide. [Online] VMWARE, 2018.


https://www.vmware.com/resources/compatibility/search.php.

[70] 70. VMware Inc. vSphere Installation and Setup. Palo Alto, CA 94304 : VMware Inc., 2017.

[71] 71. Rufus. Create bootable USB drives the easy way. [Online] Rufus. https://rufus.akeo.ie/.

[72] 72. Cisco. Software Download for Application Policy Infrastructure Controller Enterprise Module (APIC-EM).
[Online] Cisco, 2018. https://software.cisco.com/download/home/286208072/type/286291196/release/1.6.

[73] 73. Network Alliance. Understanding Technology Costs. [Online] Network Alliance, 2018. [Hivatkozva: 2018. 4
29.] http://www.networkalliance.com/your-advantage/understanding-technology-costs.

[74] 74. VMware. Network Virtualization and Security Platform. [Online] VMware. [Hivatkozva: 2018. 04 30.]
https://www.vmware.com/hu/products/nsx.html.

[75] 75. WMware. vSphere Web Client Software Requirements. [Online] WMware, Oct 2016.
https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.install.doc/GUID-F6D456D7-C559-439D-8F34-
4FCF533B7B42.html.

[76] 76. Lundgren, Henrik. Implementation and Real-world Evaluation of Routing Protocols for Wireless Ad hoc
Networks. UPPSALA UNIVERSITY, Sweden : Department of Information Technology, Uppsala University, Sweden,
2002.

[77] 77. ONF. Open Networking Foundation Formed to Speed Network Innovation. [Online] ONF, 2011. March 21.
[Hivatkozva: 2018. May 25.] https://www.opennetworking.org/news-and-events/press-releases/onf-formed-to-speed-
network-innovation/.

[78] 78. IETF. NETCONF Configuration Protocol. [Online] IETF, 2006. [Hivatkozva: 2018. May 28.]
https://tools.ietf.org/html/rfc4741.

[79] 79. VMware, Inc. Wmware information center. [Online] VMware, Inc, 2018.
https://docs.vmware.com/en/VMware-vSphere/index.html.

[80] 80. Cisco. APIC Enterprise Module - Swagger. APIC Enterprise Module. [Online] Cisco, 2018. [Cited: 28 02
2018.] https://82.150.42.74/swagger#!/network-device/addNetworkDevice.

[81] 81. Cisco Systems, Inc. Cisco Application Policy Infrastructure Controller Enterprise Module. San Jose, CA
95134-1706 : Cisco Systems, Inc., 2015.

[82] 82. United Nations. World Economic Situations and Prospects. New York : United Nations, 2018.

[83] 83. Veeraraghavan, Prof. Malathi. Three planes in networks. Virgina, USA : Polytechnic University, 2011.

95
[84] 84. Statista. IT networking - Statistics & Facts. [Online] Statista, 2018. [Cited: 29 04 2018.]
https://www.statista.com/topics/3936/it-networking/.

[85] 85. CompTIA. IT Industry Outlook 2018. [Online] CompTIA, 2018. [Cited: 28 May 2018.]
https://www.comptia.org/resources/it-industry-trends-analysis.

96
8 List of Figures
Figure 1: Traditional Network Planes ........................................................................................ 10

Figure 2: SDN Architecture 1 .................................................................................................... 12

Figure 3: Central Control Plane ................................................................................................ 13

Figure 4: Southbound Interfaces............................................................................................... 14

Figure 5: Northbound Interfaces ............................................................................................... 15

Figure 6: SDN Architecture with Controller................................................................................ 17

Figure 7: REST API Communications ....................................................................................... 24

Figure 8: REST API Constraints ............................................................................................... 24

Figure 9: REST Resource Examples ........................................................................................ 26

Figure 10: REST API Request and Response........................................................................... 27

Figure 11: JSON Structure ....................................................................................................... 31

Figure 12: The general view of the test environment ................................................................. 33

Figure 13: Test Environment Elements and Connections .......................................................... 34

Figure 14: VMWARE Management Network Connection........................................................... 35

Figure 15: EVE-NG Virtual Network without APIC-EM from Visio .............................................. 38

Figure 16: The Whole Network Topology .................................................................................. 40

Figure 17: Installing Applications on APIC-EM .......................................................................... 41

Figure 18: HUB and Brach Sites of the Test Environment ......................................................... 42

Figure 19: Partial Device Inventory ........................................................................................... 43

Figure 20: Dynamic routing protocols and redistributions .......................................................... 44

Figure 21: Full Device Inventory ............................................................................................... 45

Figure 22: Token REST API ..................................................................................................... 50

Figure 23: Inventory REST API................................................................................................. 51

Figure 24: Topology REST API................................................................................................. 53

97
Figure 25: One Node Inventory REST API ................................................................................ 54

Figure 26: Get Policy REST API ............................................................................................... 56

Figure 27: Policy Change Screen ............................................................................................. 57

Figure 28: Push Policy Diff REST API....................................................................................... 58

Figure 29: Android Studio Activities and Functions ................................................................... 60

Figure 30: Android Application External Data Flow ................................................................... 61

Figure 31: Android Application Internal Data Flow..................................................................... 61

Figure 32: Android Studio Object Classes for data .................................................................... 62

Figure 33: Inventory Activities Interrelations.............................................................................. 63

Figure 34: Topology Activities Correlations ............................................................................... 63

Figure 35: Policy Routing Activities Correlations ....................................................................... 63

Figure 36: Android Application Policy Update Procedure .......................................................... 65

Figure 37: Start-up Screen of the Android SDN-NM Application ................................................ 67

Figure 38: Inventory Screen of the Android SDN-NM Application .............................................. 68

Figure 39: Inventory Request ................................................................................................... 69

Figure 40: APIC-EM Location Settings...................................................................................... 72

Figure 41: New York Location Creation .................................................................................... 73

Figure 42: Set Location for Device............................................................................................ 73

Figure 43: List Inventory in APIC-EM with New York location .................................................... 74

Figure 44: New York Inventory ................................................................................................. 74

Figure 45: Particular Detailed Device Information ..................................................................... 75

Figure 46: Output of "Show version" command ......................................................................... 76

Figure 47: Topology request ..................................................................................................... 77

Figure 48: Topology with two nodes ......................................................................................... 80

Figure 49: Topology with four nodes ......................................................................................... 81

Figure 50: Topology with five nodes ......................................................................................... 81

98
Figure 51: Link Information ....................................................................................................... 82

Figure 52: Show Interface Command Outputs .......................................................................... 82

Figure 53: Policy Request ........................................................................................................ 83

Figure 54: Policy Screen .......................................................................................................... 85

Figure 55: Policy Update Communication ................................................................................. 86

Figure 56: Policy Update Changes on Routers ......................................................................... 88

Figure 57: APIC-EM log............................................................................................................ 88

99
9 List of tables
Table 1: Architecture and Design Elements of Three Control Platforms..................................... 21

Table 2: REST API parts .......................................................................................................... 27

Table 3: REST API Methods..................................................................................................... 29

Table 4: Used Images of the Virtual Network ............................................................................ 38

Table 5: Application Functions .................................................................................................. 46

Table 6: Protocols of the Application Classes ........................................................................... 47

Table 7: Functions and their REST APIs................................................................................... 49

Table 8: Device Inventory Response Model .............................................................................. 70

Table 9: Inventory Response Example ..................................................................................... 71

Table 10: Topology response model ......................................................................................... 78

Table 11: Topology response example ..................................................................................... 79

Table 12: Policy Example ......................................................................................................... 84

Table 13: Policy Update Body example .................................................................................... 87

100