|
C. QoSFlow Architecture
In its current version, OpenFlow is not able to configure QoS
parameters in a dynamic and on-demand manner (i.e., it does
this manually). In order to deal with QoS problems in dynamic
approach, a framework called QoSFlow (Fig. 18) that enables
QoS management in OpenFlow environment is proposed in
[134]. QoSFlow allows the management of traffic class and
queues through rules or policy. It manages QoS resources (e.g.,
bandwidth, queue size) without changing the SDN architecture.
All actions are invoked by an OpenFlow controller and in a
dynamic and on-demand manner (not manually).
QoSFlow is an extension of the standard OpenFlow con-
troller which provides multimedia delivery with QoS. The
QoSFlow controller is based on NOX, which is responsible for
managing/monitoring actions and controlling signaling mes-
sages. The new controller, besides NOX API, contains the
following new components: QoSFlow agent, QoSFlow man-
ager, QoSFlow monitor, and DB-QoSFlow client. These four
modules have been designed to extend the NOX API with QoS
features called QoSFlow API. QoS Agent is responsible for
creating a communication module between an administrator
management tool and the other two QoSFlow components: the
manager and monitor QoSFlow. By using JSON interface, the
agent is able to receive policies, manage or monitor commands
from a third-part administrator application. The QoSFlow
monitor and manager components, respectively, monitor and
Fig. 19.
QoSFlow controller architecture [134].
manage the QoS of OpenFlow domains. Fig. 19 shows its
controller architecture.
The QoSFlow data-path component is responsible for creat-
ing all low-level actions on the switch ports. This component
allows OpenFlow to get all the required information to run
management commands created by either the administrator’s
tool or through header packet information. In QoS management
tool, the actions are processed in the QoSFlow Agent. When
receiving those actions, it checks the type of the received
requests in order to select the next procedure. This new message
is automatically sent to controllers through NOX. The QoS
actions can be applied automatically through the packet header
information. In order to support fine-granularity QoS, the in-
coming traffic is grouped as data flows and multimedia flows,
where the multimedia flows are dynamically placed on QoS
guaranteed routes and the data flows remain on their traditional
shortest-path routing approach.
D. Operating System for QoS Optimization
NOX, the standard network operating system, can be used
for packet-level or flow-level control. However, it does not
have the necessary APIs for QoS support. For instance, it does
not support QoS-oriented virtual network management, or end-
to-end QoS performance monitoring. In [98] an QoS-aware
Network Operating System (QNOX) is proposed to support
general OpenFlow QoS functions.
The QNOX system includes the following modules: WDM/
ASON, IP, MPLS-TP. Here, WDM/ASON can monitor large
network traffic status. QoS-aware Open Virtual Network Pro-
gramming interface (QOVNPI) allows a client to request any
type of QoS performance. The service element (SE) can be used
for QoS demand definitions, such as the required network band-
width, memory overhead, preferred server locations, packet loss
rates, delay bounds, and security levels. The SLA (service level
agreement) and SLS (service level specification) modules can
be used to assess the OpenFlow resource availability, that is, to
check whether the network can meet the client’s QoS demands.
Obviously QNOX can define fine-granularity of QoS, such
as packet-level delay or loss rate. Based on the experimental
results in [98], QNOX can quickly calculate the routing path in
less than 100 ms even with over 100 nodes in the SDN. The
SLA/SLS can find all network resources in less than 1 s.
2196
IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 16, NO. 4, FOURTH QUARTER 2014
TABLE III
A C
OMPARISON OF
D
IFFERENT
SDN S
ECURITY
S
CHEMES
Do'stlaringiz bilan baham: | 
