Inter
national
J
our
nal
of
Electrical
and
Computer
Engineering
(IJECE)
V
ol.
7,
No.
4,
August
2017,
pp.
2261
–
2277
ISSN:
2088-8708
2261
I
ns
t
it
u
t
e
o
f
A
d
v
a
nce
d
Eng
ine
e
r
i
ng
a
nd
S
cie
nce
w
w
w
.
i
a
e
s
j
o
u
r
n
a
l
.
c
o
m
A
Pr
oposal
f
or
End-to-End
QoS
Pr
o
visioning
in
Softwar
e-Defined
Netw
orks
Francesco
Lucr
ezia
1
,
Guido
Mar
chetto
2
,
Fulvio
Risso
3
,
Michele
Santuari
4
,
and
Matteo
Ger
ola
5
1,2,3
Polytechnic
of
T
urin,
T
orino,
Italy
4,5
CREA
TE-NET
,
T
rento,
Italy
Article
Inf
o
Article
history:
Recei
v
ed:
Feb
17,
2017
Re
vised:
Jun
2,
2017
Accepted:
Jun
17,
2017
K
eyw
ord:
QoS
Pro
visioning
Netw
orking
SDN
ONOS
ABSTRA
CT
This
paper
describes
a
frame
w
ork
application
for
the
control
plane
of
a
netw
ork
infras-
tructure;
the
objecti
v
e
is
to
feature
end-user
applications
with
the
capability
of
requesting
at
an
y
time
a
customised
end-to-end
Quality-of-Service
profile
in
the
conte
xt
of
dynamic
Service-Le
v
el-Agreements.
Our
solution
tar
gets
current
and
future
real-time
applications
that
require
tight
QoS
parameters,
such
as
a
guaranteed
end-to-end
delay
bound.
These
ap-
plications
include,
b
ut
are
not
limited
to,
health-care,
mobility
,
education,
manuf
acturing,
smart
grids,
g
aming
and
much
more.
W
e
discuss
the
is
sues
related
to
the
pre
vious
Inte
grated
Service
and
the
reason
wh
y
the
RSVP
protocol
for
guaranteed
QoS
did
not
tak
e
of
f.
Then
we
present
a
ne
w
signaling
and
resource
reserv
ation
frame
w
ork
based
on
t
he
cutting-edge
netw
ork
controller
ONOS.
Moreo
v
er
,
the
presented
system
foresees
the
need
of
considering
the
edges
of
the
netw
ork,
where
terminal
applications
are
connected
to,
to
be
piloted
by
dis-
tinct
logically
centralised
controllers.
W
e
discuss
a
possible
inter
-domain
communication
mechanism
to
achie
v
e
the
end-to-end
QoS
guarantee.
Copyright
c
201x
Institute
of
Advanced
Engineering
and
Science
.
All
rights
r
eserved.
Corresponding
A
uthor:
Name:
Francesco
Lucrezia
Af
filiation:
Polytechnic
of
T
urin,
Italy
Address.
Corso
Duca
de
gli
Abruzzi,
24,
10129
T
orino,
Italy
Email:
francesco.lucrezia@polito.it
1.
INTR
ODUCTION
Internet
service
pro
viders
(ISPs)
are
stri
ving
to
inno
v
ate
their
netw
ork
infrastructures
at
the
pace
content
pro
viders
do
with
their
services.
Digital
contents
are
consumed
by
smart
phones
and
sophisticated
terminal
stations
that
continuously
e
v
olv
e
together
with
the
applications
the
y
host.
Interestingly
enough,
the
e
v
olution
of
the
Ov
er
-
The-T
op
(O
TT)
services
is
mainly
happening
without
the
aid
of
netw
ork
service
pro
viders,
within
the
best-ef
fort
data
traf
fic
channel
in
the
access
netw
orks.
Recently
,
a
ne
w
plethora
of
applications
requiring
a
R
TT
delay
of
around
1ms
ha
v
e
been
grouped
under
the
hat
of
tactile-internet
applications:
a
tactile
s
ensor
reads
information
and
a
connected
system
reacts
with
actuators
seen
by
a
human
within
1
ms
[1].
Although
we
are
still
f
ar
from
achie
ving
end-to-end
R
TT
of
around
1ms
with
wireless
communications,
ISPs
need
to
be
ready
to
re-a
rchitect
their
softw
are
control-plane
in
order
to
fully
e
xploit
the
enormous
potentials
of
fered
by
their
infrastructures.
The
goal
of
this
paper
is
to
present
the
design
and
a
prototype
implementation
of
a
control-plane
netw
ork
application
for
pro
visioning
dynamic
end-to-end
QoS
profiles
to
end-user
applications.
The
current
adoption
of
distrib
uted
control
algorithms
forces
the
use
of
the
same
signaling
protocol
(e.g.
RSVP
,
BGP-LS)
in
all
the
data-path
nodes,
not
taking
into
account
the
resistances
ine
vitably
present
between
de
vice
v
endors
and
between
administrati
v
e
domains.
F
or
this
reason
the
Service-Le
v
el-Agreements
(SLAs)
between
a
service
pro
vider
and
its
customers
or
between
pro
viders
are
still
mainly
sta
tic.
Moreo
v
er
,
the
e
xperience
has
sho
wn
that
the
scalability
issue
of
the
core
netw
ork
in
maintain-
ing
per
-flo
w
s
tate
for
resource
reserv
ation
in
each
node
along
a
path
pre
v
ented
the
dif
fusion
of
RSVP
and
inte
grated
services
in
general.
As
discussed
in
[2],
per
-flo
w
service
treatment
does
not
scale
in
the
Internet
core;
backbone
routers
must
be
f
ast
and
only
an
a
g
gr
e
gate
behaviour
is
feasible.
Instead,
it
is
important
to
enable
such
treatment
J
ournal
Homepage:
http://iaesjournal.com/online/inde
x.php/IJECE
I
ns
t
it
u
t
e
o
f
A
d
v
a
nce
d
Eng
ine
e
r
i
ng
a
nd
S
cie
nce
w
w
w
.
i
a
e
s
j
o
u
r
n
a
l
.
c
o
m
,
DOI:
10.11591/ijece.v7i4.pp2261-2277
Evaluation Warning : The document was created with Spire.PDF for Python.
2262
ISSN:
2088-8708
at
the
edge
of
the
netw
ork
where
mass
of
users
enj
o
ying
a
mixture
of
heterogeneous
applications
share
indistinctly
the
same
portion
of
the
netw
ork
as
in
the
case
of
cellular
access
netw
orks;
performance
de
gradation
is
lik
ely
to
hap-
pen
in
the
access
links
where
an
increasing
number
of
traf
fic
sources
and
sinks
can
introduce
a
significant
amount
of
queueing
delay
.
Gi
v
en
these
considerations,
we
belie
v
e
that
an
h
ybrid
combination
of
flo
w-based
and
class-based
traf
fic
treatment,
respecti
v
ely
at
the
edge
and
in
the
core
of
the
netw
ork,
could
enable
guaranteed
services
for
current
and
future
real-time
applications.
Since
these
applications
could
ha
v
e
terminals
deplo
yed
all
around
the
globe,
the
end-to-end
pro
visioning
will
ha
v
e
to
span
a
chain
of
administrati
v
e
domains,
requiring
an
east-west
communication
interf
ace
to
con
v
e
y
data
that
v
ary
from
classic
inter
-domain
routing
information
e
xchanged
via
BGP
.
If
we
mak
e
the
assumption
that
QoS
requirements
requested
by
the
customer
applications
are
satisfied
in
the
core
netw
ork,
at
least
for
what
concerns
a
delay
bound,
and
up
to
a
maximum
bandwidth
allocation,
then
we
can
think
to
o
v
erlay
an
inte
grated
service
scheme
on
top
of
the
current
deplo
yments
where
class-based
treatment
is
applied,
as
long
as
the
resource
admission
control
system
is
able
to
map
the
dynamic
service
requests
to
the
statical
ly
allocated
resources
in
the
core.
Our
proposal
is
a
signaling
scheme
for
pa
th
reserv
ation
and
configuration
whose
implementation
does
not
require
the
in
v
olv
ed
data-path
de
vices
to
be
bound
to
a
single
control
protocol.
The
aim
is
to
solv
e
the
interoperability
problem
in
pro
visioning
end-to-end
guaranteed
services,
in
a
multi-v
endor
,
multi-technology
and
mult
i-domain
en
vironment
by
e
xploiting
current
softw
are
technologies
adv
ances;
in
particular
,
the
decoupling
between
functional
intents
and
the
w
ay
the
y
are
accomplished
is
crucial.
The
paper
is
or
g
anised
as
follo
ws:
Section
2.
gi
v
es
a
high
le
v
el
description
of
the
complete
system
w
orkflo
w
,
the
first
part
of
Section
3.
is
dedicated
to
a
general
introduction
to
the
QoS
and
to
the
Internet
technologies
adopted
to
achie
v
e
it.
Here
is
where
the
most
of
t
he
related
w
orks
are
considered.
Then
it
focuses
on
our
specific
use-case
scenario
and
on
the
RSVP
critical
issues.
In
Section
4.
we
discuss
the
communication
interf
ace
between
clusters
or
domains
of
netw
orks
required
to
achie
v
e
the
end-to-end
pro
visioning,
while
in
Section
5.
a
brief
conte
xtualisation
of
our
w
ork
into
a
polic
y
management
system
is
presented.
Section
6.
and
a
ll
its
subsections
contain
the
specific
details
of
our
prototype
system
implementation
and
Section
7.
presents
some
benchmark
results
on
the
service
request
computation
time.
Finally
,
Section
8.
concludes
the
paper
.
2.
SYSTEM
W
ORKFLO
W
The
o
v
erall
process
is
acti
v
ated
upon
the
occurrence
of
some
e
xternal
e
v
ent,
either
sensorial
or
caused
by
the
human
will,
that
triggers
the
dispatch
of
a
request
sent
by
the
user
application.
The
request
contains
a
user
au-
thentication
tok
en,
an
application
identifier
,
information
about
an
endpoint
to
contact
together
with
additional
flo
w
specifications,
and
a
QoS
profile
containing
delay
and
bandwidth
requirements,
plus
an
amount
of
time
(or
an
estimate
of
it)
for
which
the
profile
is
required.
A
pre
vious
agreement
between
the
user
and
the
netw
ork
operator
is
made
in
order
to
con
v
e
y
to
a
traf
fic
plan
based
on
its
dynamism,
amount
of
data,
QoS
parameters,
number
of
request
s
and
possibly
other
par
ameters.
The
request
is
sent
to
a
manager
application
running
on
top
of
the
local
domai
n
controller
that
is
listening
for
incoming
connections
from
re
gistered
users.
The
authentication
tok
en,
pre
viously
generated
in
a
hand-shak
e
phase
is
v
erified
and
the
content
of
the
payload
is
parsed
and
elaborated
as
follo
ws.
The
endpoint
information,
either
a
destination
address
(L2
or
L3,
depending
on
the
use-case)
or
the
hostname
of
the
machine
to
be
contacted,
is
used
as
look-up
k
e
y
to
get
the
collection
of
candidate
paths
e
xisting
between
the
end
terminals
of
the
user
application.
Then
an
admission
contr
ol
routine
runs
to
check
the
a
v
ailability
of
a
suitable
path
where
resources
are
to
be
reserv
ed
for
the
subject
QoS
profile.
Once
a
path
is
selected,
the
netw
ork
application
has
to
instruct
t
h
e
core
controller
to
setup
a
priority
flo
w
between
the
endpoints
of
the
user
application;
for
the
sak
e
of
simplicity
,
we
will
refer
to
point-to-point
paths,
although
the
solution
is
equally
applicable
to
paths
with
multiple
destinations
(
>
2).
It
may
be
necessary
to
establish
connecti
vity
between
the
endpoints,
other
than
traf
fic
control’
s
rules.
F
or
e
xample,
in
a
pure
Openflo
w
netw
ork
where
none
of
the
routing
protocol
suite
runs
in
the
data-path
de
vices,
the
controller
w
ould
prescribe
a
set
of
flo
w
rules
containing
forw
arding
instructions,
together
with
QoS
constrai
nts.
If
forw
arding
rules
ha
v
e
been
pre
viously
installed
on
the
data-path
de
vices,
then
only
traf
fic
classification
and
shaping
is
to
be
done
through
de
vice-specific
configurations.
T
o
setup
a
priority
flo
w
,
the
manager
application
issues
the
setup
of
custom
queues
in
the
de
vices
along
the
selected
path
and
sends
an
intent
request
to
the
controller’
s
core
with
the
specification
of
the
tar
get
flo
w
.
An
intent
is
an
abstraction
used
by
the
applications
to
specify
their
high-le
v
el
desires
in
form
of
policies.
The
ONOS
netw
ork
controller
[3],
used
in
our
prototype
implementation,
is
the
first
open-source
controller
that
pro
vide
such
feature
to
IJECE
V
ol.
7,
No.
4,
August
2017:
2261
–
2277
Evaluation Warning : The document was created with Spire.PDF for Python.
IJECE
ISSN:
2088-8708
2263
(
2)
R
e
que
s
t
(
1)
T
opol
ogy di
s
c
ove
r
y
(
4)
P
a
t
h s
e
t
up
(
3)
R
e
s
our
c
e
r
e
s
e
r
va
t
i
on
DOM
AI
N
CO
N
TRO
LLER
A
P
e
e
r
i
ng P
r
ovi
de
r
A
dm
i
s
s
i
on
C
ont
r
ol
(
4)
P
a
t
h s
e
t
up
DOM
AI
N
CO
N
TRO
LLER
B
P
e
e
r
i
ng P
r
ovi
de
r
A
dm
i
s
s
i
on
C
ont
r
ol
Figure
1.
Reference
scenario
10
En
d
-
Po
i
n
t
in
t
e
r
lin
k
CL
U
S
T
E
R
A
CL
U
S
T
E
R
B
N
e
t
w
or
k vi
e
w
of
c
l
us
t
e
r
A
Figure
2.
Domain
topology
abstraction
its
appli
cations.
The
intent
is
then
split
by
the
core
into
de
vice-specific
flo
w
rule
requests
dispatched
to
the
proper
softw
are
dri
v
ers
of
the
underlying
de
vices.
Queues
are
also
configured
by
means
of
de
vice-specific
dri
v
ers.
As
mentioned
before,
the
endpoints
can
normally
span
multiple
domains
and,
clearly
,
each
domain
has
to
tak
e
care
of
its
portion
of
the
netw
ork.
A
k
e
y
point
of
the
system
is
the
topology
abstraction
(Figure
2):
all
forw
ard-
ing
de
vices
of
the
local
domain
are
e
xposed
to
the
controller
with
the
same
abstraction
model,
as
is
an
entire
remote
domain
topology
,
vie
w
as
a
single
de
vice
(a
big
switch)
whose
ports
are
connected
to
terminal
endpoints
or
to
other
domain
topologies.
When
the
endpoint
of
the
application
requesting
a
priority
path
resides
on
a
dif
ferent
domain,
the
admission
control
routine
recognises
the
presence
of
a
virtual
de
vice
associated
to
the
remote
domain
and
as
a
con-
sequence
queries
the
netw
ork
manager
application
of
the
remote
domain
in
order
to
establish
an
end-to-end
resource
reserv
ation
along
the
path
between
the
endpoints
(Figure
1).
Once
the
process
con
v
er
ges,
the
domain
controllers
can
simultaneously
setup
the
path
in
their
o
wn
portion
of
the
netw
ork,
the
manager
application
that
recei
v
ed
the
original
request
sends
a
response
back
to
the
user
application
that
can
start
sending
priority
data
o
v
er
the
netw
ork.
3.
QOS
PR
O
VISIONING
3.1.
General
Discussion
QoS
is
introduced
in
pack
et-switched
netw
orks
in
order
to
apply
a
special
treatment
to
specific
data
pack
et
flo
ws.
At
the
de
vice
le
v
el,
QoS
is
achie
v
ed
through
traf
fic
classification,
shaping,
and
scheduling
at
the
e
gress
ports;
at
the
ingress
ports
pack
ets
are
filtered
for
policing.
Classification
determines
which
treatment
each
data
pack
et
has
to
under
go,
shaping
is
used
to
control
customer
input
data
rate
to
conform
to
the
SLAs,
while
scheduling
af
fects
delay
and
throughput
of
the
data
pack
et
flo
ws.
Gi
v
en
conformance
to
a
SLA,
scheduling
at
the
netw
ork
interf
aces
is
the
lo
west
le
v
el
operation
gearing
QoS
pro
visioning,
also
kno
wn
as
service
discipline
.
At
the
path
le
v
el,
QoS
is
achie
v
ed
through
resource
reserv
at
ion
o
v
er
the
whole
set
of
nodes
along
the
path.
The
reserv
ati
on
must
be
secured
end-to-end
and
the
resource
allocation
in
one
node
must
be
consistent
with
the
others
along
the
path.
A
path
selection
with
the
end-to-end
delay
constraint
is
subject
to
inaccurate
information
due
to
the
dynamic
nature
of
the
delay
and
hence
subject
to
theoretical
intractability
([4]
[5]).
Ho
we
v
er
,
end-to-end
delay
and
delay
jitter
bounds
ha
v
e
been
computed
by
means
of
netw
ork
calculus
applied
to
queueing
systems
modelling
the
A
Pr
oposal
for
End-to-End
QoS
Pr
o
visioning
...(F
r
ancesco
Lucr
ezia)
Evaluation Warning : The document was created with Spire.PDF for Python.
2264
ISSN:
2088-8708
netw
orks
([6,
7,
8]).
Academic
and
industrial
communities
ha
v
e
been
v
ery
acti
v
e
in
the
last
decades
in
in
v
estig
ating
netw
ork
models
and
algorithms
to
solv
e
the
QoS
r
outing
problem,
also
kno
wn
as
the
multi-constr
ained
path
compu-
tation
problem
([9,
10,
11,
12,
13,
14,
15]).
In
[2]
the
y
co
v
er
all
the
important
component
s
of
the
QoS
pro
visioning
in
Internet
as
it
has
been
concei
v
ed
in
the
last
decades:
inte
grated
services,
RSVP
([16,
17]),
Dif
fServ
[18],
Multi
Protocol
Label
Switching
(MPLS
[19])
and
constraint-based
routing.
T
oday
netw
ork
operators
emplo
y
MPLS
mainly
for
layer
2
and
Layer
3
V
irtual-Pri
v
ate-Netw
ork
(VPN)
ser
-
vices
([20]),
while
constrain-based
routing
for
T
raf
fic
Engineering
(TE)
operations
is
comple
x
to
achie
v
e
in
a
complete
distrib
uted
control-plane.
Moreo
v
er
,
TE
is
not
useful
in
presence
of
congestion.
This
happens
at
the
bottleneck
links
that
typically
reside
in
the
last
mile
to
w
ards
the
cust
o
m
ers.
Dif
fServ
model
within
a
single
AS
is
emplo
yed
by
ISPs
for
class-based
tr
eatment
of
the
data
pack
ets;
b
ut
the
v
alidity
of
the
T
ype
of
Service
(T
oS)
field
in
the
pack
et
IP
header
may
lose
completely
meaning
when
tra
v
ersing
multiple
administrati
v
e
domains.
In
other
w
ords,
within
a
single
ad-
ministrati
v
e
domain
the
class-based
QoS
pro
visioning
is
theoretically
easy
t
o
achie
v
e
and
technology
is
not
the
hurdle,
while
polic
y
and
economic
f
actors
ha
v
e
the
major
impact
on
the
f
ate
of
the
QoS
pro
visioning
in
the
multi-domain
scenario.
IntService
and
the
RSVP
signaling
protocol
instead
did
not
tak
e
of
f
e
v
en
within
the
single
administrati
v
e
domain.
RSVP
is
used
for
labels
distrib
ution
in
G/MPLS
b
ut
it
f
ailed
in
its
primordial
intent.
In
order
to
accomplish
the
process
described
in
Section
2.
an
end-to-end
guaranteed
service
must
be
pro
vided.
In
the
ne
xt
section
we
discuss
the
critical
issues
of
RSVP
and
in
what
our
proposal
dif
fers
from
it.
3.2.
Comparison
with
RSVP
P
ath
Computation
and
Routing
.
RSVP
uses
a
combination
of
Constrained
Shrotest
P
ath
First
(CSPF)
algo-
rithm
and
Explicit
Route
Objects
(ER
Os)
to
determine
ho
w
reserv
ed
traf
fic
and
signal
ing
messages
are
routed
o
v
er
the
netw
ork;
RSVP
is
a
distrib
uted
signaling
protocol
and
it
needs
routing
to
w
ork.
ER
Os
are
a
mean
to
e
xplicit
indicate
some
nodes
that
must
belong
to
the
reserv
ed
path;
in
order
to
force
a
specific
path
through
a
set
of
nodes
you
should
enter
and
configure
each
node
with
specific
ER
Os
instructions.
If
the
total
bandwidth
reserv
ation
e
xceeds
the
a
v
ailable
bandwidth
specified
across
the
link
for
a
particular
path
se
gment,
the
path
must
be
recomputed
through
another
route.
If
no
se
gments
can
support
the
bandwidth
reserv
ation,
path
setup
f
ails
and
the
RSVP
session
is
not
established.
In
our
solution
the
path
computation
is
independent
from
the
routing
protocol.
Dif
ferent
routing
and
for
-
w
arding
scheme
can
be
used
to
b
uild
the
path
in
the
underlying
netw
ork:
flo
w-rules,
labels,
tunnels.
But
no
routing
of
the
signaling
scheme
is
needed;
centralised
path
computation
is
clearly
much
f
aster
and
protocol-independent.
The
controller
only
needs
the
vie
w
of
the
topology
as
a
connected
graph.
T
o
force
the
reserv
ation
in
a
specific
path,
you
can
directly
reserv
e
resources
and
install
forw
arding
rules
into
the
proper
de
vices
at
once.
The
candidate
paths
are
collected
from
the
store
and
a
suitable
one
is
found
before
injecting
resource
reserv
ation
rules
into
the
netw
ork.
This
occurs
in
the
centralised
controller
within
a
single
softw
are
process.
RSVP
is
simplex
.
In
RSVP
the
reserv
ation
process
is
applied
in
a
single
direction
of
the
path.
T
o
ha
v
e
full
duple
x
reserv
ation,
the
number
of
operations
and
the
messages
e
xchanged
are
doubled.
In
a
centralised
netw
ork
controller
,
you
can
e
q
ua
lly
pro
vide
simple
x
or
duple
x
reserv
ation
via
a
single
soft-
w
are
entity
.
Admission
and
P
olicy
Control
.
RSVP
Admission
and
polic
y
control
is
applied
to
ea
ch
node.
So
RSVP
implementation
must
be
inte
grated
with
each
node’
s
traf
fic
and
polic
y
control
module,
thus
increasing
the
chance
of
interoperability
.
RSVP
must
pro
vide
QoS
service
characterisation
within
opaque
objects
parsed
by
each
netw
ork
node.
In
our
proposal
the
QoS
service
characterisation
is
completel
y
decoupled
by
the
signaling
protocol/scheme
and
must
be
embedded
only
into
the
front-end
APIs
consumed
by
the
customer
applications.
The
admission
and
polic
y
control
is
applied
only
once,
in
each
domain,
in
the
central
controller
.
An
RPC-based
mechanism
is
used
for
configur
-
ing
the
traf
fic
control
module
gi
v
en
the
possibility
to
fulfil
the
request.
Our
prototype
relies
on
ONOS.
ONOS
pro
vides
common
abstracted
beha
viours
for
traf
fic
selection
and
treatments
that
are
translated
into
de
vice-specific
rules.
F
irst
speak
er
.
RSVP
session
initiator
is
the
inbound
router
running
RSVP
in
conjuction
with
other
protocols
(e.g.
MPLS
or
GMPLS
in
case
of
label
distrib
ution).
If
RSVP
is
embedded
in
a
host
application,
then
the
first
net-
w
ork
node
should
speak
RSVP
,
otherwise
a
tunnel
between
the
applicati
on
and
the
first
RSVP-capabl
e
de
vice
shall
be
IJECE
V
ol.
7,
No.
4,
August
2017:
2261
–
2277
Evaluation Warning : The document was created with Spire.PDF for Python.
IJECE
ISSN:
2088-8708
2265
created
thus
increasing
the
number
of
operation
required
for
RSVP
signaling
to
w
ork.
In
the
presented
solution
the
session
initiator
is
a
user
application
featured
with
proper
APIs
for
contacting
the
controller
.
The
idea
is
to
k
eep
the
API
consumer
implementation
as
simple
as
a
REST
client
that
has
the
capability
to
create,
remo
v
e,
update
and
de
lete
a
priority
path.
Such
client
w
ould
be
pro
vided
for
dif
ferent
softw
are
en
vironments.
Scalability
.
As
per
[21],
the
scaling
problems
of
RSVP
are
link
ed
to
the
resource
requirements
(in
terms
of
processing
and
memory)
of
running
RSVP
.
The
resource
requirements
increase
proportionally
with
the
number
of
sessions.
Each
session
requires
the
generation,
transmission,
reception
and
processing
of
RSVP
P
ath
and
Resv
mes-
sages
per
refresh
period.
Supporting
a
lar
ge
number
of
sessions,
and
the
corresponding
v
olume
of
refresh
messages,
presents
a
scaling
problem.
A
centralised
control
plane
presents
the
same
scalability
issues
concerning
the
state
maintenance
of
an
in-
creasing
number
of
sessions
in
the
data-path
nodes.
But
it
only
matters
the
traf
fic
control
and
flo
w
rule
s,
while
processing
and
singnaling
o
v
erhead
are
significantly
lo
wered.
Complexity
.
Finally
,
and
maybe
the
most
rele
v
ant
obstacle
to
success,
RSVP
is
comple
x
because
it
w
as
designed
with
IP
multicast
in
mind,
intermediate
nodes
ha
v
e
to
mer
ge
resource
reserv
ation
requests
coming
from
the
recei
v
er
nodes.
Moreo
v
er
,
the
basic
RSVP
reserv
ation
model
is
"one
pass":
a
recei
v
er
sends
a
reserv
ation
request
up-
stream,
and
each
node
in
the
path
either
accepts
or
rejects
the
request.
This
scheme
pro
vides
no
easy
w
ay
for
a
recei
v
er
to
find
out
the
resulting
end-to-end
service.
T
o
solv
e
this
issue
an
enhancement
w
as
proposed
[22],
introducing
further
comple
xity
in
the
concretization
of
RSVP
and
the
inte
grated
services
in
general.
Orchestrating
the
data-path
nodes
from
within
a
central
controller
a
v
oids
the
issues
related
to
the
e
xchange
of
asynchronous
signaling
messages.
The
decision
process
not
being
distrib
uted
decreases
the
comple
xity
in
maintaining
a
single
state
of
the
system.
3.3.
End-to-End
Beha
viour
The
end-to-end
QoS
profile
model
shall
follo
w
the
one
described
in
the
Specification
of
Guaranteed
Quality
of
Service
[23].
As
per
[23],
"
the
end-to-end
behaviour
pr
o
vided
by
a
series
of
network
elements
is
an
assur
ed
le
vel
of
bandwidth
that,
when
used
by
a
policed
flow
,
pr
oduces
a
delay-bounded
service
with
no
queueing
loss
for
all
conform-
ing
data
gr
ams
".
W
e
in
vite
to
refer
to
the
specifications
for
further
clarification
about
the
QoS
model
tak
en
into
account.
Each
netw
ork
node
must
pro
vide
a
service
that
matches,
with
some
error
bounds,
the
fluid
model
([24,
25])
through
the
tok
en
b
uck
et
scheme
with
paramters
(
b;
r
;
p
)
,
respecti
v
ely
the
b
uck
et
size,
the
tok
en
rate
and
the
peak
rate.
The
QoS
request
includes
a
maximum
end-to-end
delay
bound,
d
r
eq
,
that
shall
be
guaranteed
between
the
application
terminals.
In
the
centralised
controller
,
the
link
pro
viders
are
responsible
for
notifying
the
presence
of
the
information
on
the
links
the
y
are
pro
vider
for
(propag
ation
delay
,
transmission
capacity
and
the
maximum
trans
mission
unit);
these
information
are
stored
in
the
controll
er
database
upon
disco
v
ery
of
the
link
itself.
Lik
e
wise,
the
de
vice
pro
viders
in
the
southbound
must
e
xport
other
rele
v
ant
information,
such
as
the
delay
error
terms
representing
ho
w
the
de
vice’
s
implementation
of
the
guaranteed
service
de
viates
from
the
fluid
model
in
each
netw
ork
interf
ace
(the
C
tot
and
D
tot
in
the
formula
2
belo
w).
On
a
link
l
with
capacit
y
c
l
,
we
define
a
minimum
bandwidth
reserv
ed
to
the
best
ef
fort
traf
fic,
R
be
l
.
Let
R
i
be
the
allocated
bandwidth
for
a
flo
w
i
.
On
each
link,
the
total
number
of
accepted
profiles
N
is
subject
to:
N
:
c
l
R
be
l
+
N
X
i
R
i
(1)
The
end-to-end
delay
bound
as
defined
in
[23]
is:
[(
b
M
)
=R
(
p
R
)
=
(
p
r
)]
+
(
M
+
C
tot
)
=R
+
D
tot
+
X
l
d
p
l
(2)
W
ith
r
<
=
p
<
=
R
,
M
being
the
path
Maximum-T
ransmission-Unit
and
P
l
d
p
l
the
propag
ation
delay
sum.
A
Pr
oposal
for
End-to-End
QoS
Pr
o
visioning
...(F
r
ancesco
Lucr
ezia)
Evaluation Warning : The document was created with Spire.PDF for Python.
2266
ISSN:
2088-8708
Statement
1
imposes
that
the
sum
of
the
allocated
bandwidths
for
N
flo
ws
must
not
e
xceed
the
capacity
of
the
link.
Flo
ws
requesting
a
maximum
delay
bound
are
assigned
to
higher
priority
queues
w
.r
.t.
to
the
best
ef
fort
traf
fic.
It
is
possible
to
assign
the
same
high
priority
queue
to
more
distinct
flo
ws,
as
long
as
statement
1
holds.
R
shall
be
chosen
such
that
d
r
eq
is
greater
or
equal
to
the
v
alue
computed
in
equation
2,
pro
vided
that
d
r
eq
is
greater
than
the
fix
ed
delay
terms
D
tot
and
P
l
d
p
l
.
These
constraints
must
apply
on
all
links
of
a
candidate
path
between
the
end
terminals
of
the
customer
application;
a
ne
w
queue
is
created
for
a
ne
w
flo
w
if
the
y
are
satisfied.
As
mentioned
in
the
pre
vious
section,
the
admission
contr
ol
routine
occurs
only
once
per
domain
(more
details
in
Sec.
4.),
in
the
central
controller
.
Netw
ork
element
s
must
e
xport
the
proper
information,
while
the
dri
v
ers
ha
v
e
to
translate
a
service
request
into
de
vice-specific
traf
fic
control
rules.
The
pro
visioning
of
a
guaranteed
service
along
a
path
of
se
v
eral
de
vices
and
links
is
possible
only
through
a
cross-v
endor
and
cross-technology
solution.
This
leads
to
the
adoption
of
softw
are
dri
v
er
modules
installed
into
the
centralised
controller
.
These
dri
v
ers
con
v
erts
the
protocol-agnostic
rules
into
de
vice-specific
instructions
and
are
essential
to
s
olv
e
the
interoperability
problem
deri
v
ed
by
the
presence
of
de
vices
from
multiple
v
endors
and
technolo-
gies.
F
or
e
xample,
in
a
L
TE
cellular
netw
ork,
the
high-le
v
el
profile
is
mapped
to
a
standardised
QoS
Class
Identifier
(QCI)
by
the
proper
softw
are
dri
v
er;
the
mapping
w
ould
be
follo
wed
by
the
setup
of
the
pack
et
data
netw
ork
g
ate
w
ay
and
the
mobile
station
with
some
scheduling
rules
applied
to
the
tar
get
data
flo
w
[26].
The
same
high-le
v
el
profile
has
to
be
translated
into
a
specific
setup
on
the
backhaul
that
pro
vides
the
connecti
vity
to
w
ards
the
core
netw
ork
consisting
of
all
the
required
switches
to
aggre
g
ate
the
traf
fic
from
the
access
cellular
netw
ork
[27].
The
se
switches
could
be,
for
instance,
pure
Linux
de
vices
in
which
case
the
dri
v
er
w
ould
e
x
ecute
a
remote
procedure
call
configuring
the
in
v
olv
ed
interf
aces
with
the
well-kno
wn
commands
s
uite
tc
qdisc
,
tc
filter
and
tc
class
for
setting
up
the
queues.
If
instead
a
switch
is
an
Openflo
w-enabled
de
vice,
classification
and
priority
come
within
the
forw
arding
rules,
while
the
queue
configuration
for
the
service
discipline
must
be
supplied
on
a
separate
communication
channel,
for
e
xample,
through
O
VSDB
protocol
in
Open-vSwitch
[28]
(Fig
3).
T
ogether
with
the
local
domain
(or
local
cluster
in
the
single
administrati
v
e
domain)
our
frame
w
ork
adds
the
reflection
of
such
operations
into
the
remote
domain
(cluster)
where
the
endpoint
of
the
customer
appl
ication
requesting
the
service
resides.
Note
that
we
control
the
edge
de
vices
on
each
side
of
the
communication
while
lea
ving
aside
the
backbone
routers
where
per
-flo
w
service
treatment
does
not
scale.
While
rfc-2212
states
that
all
the
nodes
of
a
path
should
tak
e
part
of
the
resource
reserv
ation
process
for
equation
2
to
hold,
we
ar
gue
that
the
dynamic
resource
reserv
ation
at
the
edge
of
the
netw
ork
can
occur
transparently
w
.r
.t.
the
statically
allocated
resources
of
the
core
where
the
QoS
e
xists
only
for
classes
of
traf
fic,
rather
than
flo
ws,
in
form
of
virtual
circuits
created
with
protocols
such
as
MPLS
or
GMPLS
(Fig.
4).
If
the
backbone
is
treated
as
a
composition
of
these
cir
cuits
rather
than
a
composition
of
nodes
and
links,
then
a
resource
mapping
between
the
dynamic
and
the
static
portions
of
the
netw
ork
resolv
es
in
representing
these
circuits
as
aggre
g
ate
elements
into
the
topology
vie
w
of
the
controller
.
P
ath-Computation-El
ement
(PCE)
describes
a
model
to
address
the
problem
of
constrain-based
path
computation
in
conjunction
with
a
label
switched
protocol
([29,
30]).
An
all
in
one
orchestration
frame
w
ork
for
the
complete
set
of
the
netw
ork
elements
is
left
as
a
future
w
ork.
I
ngr
e
s
s
P
ol
i
c
i
ng
F
or
w
a
r
di
ng
P
R
I
O
0
P
R
I
O
1
Q
ue
ui
ng
I
ngr
e
s
s
P
ol
i
c
i
ng
F
or
w
a
r
di
ng
Q
ue
ui
ng
C
ont
r
ol
l
e
r
L
i
nux
tc
dr
i
ve
r
O
pe
nf
l
ow
dr
i
ve
r
OVS
DB
dr
i
ve
r
L
i
nux de
vi
c
e
O
V
S
br
i
dge
RP
C
•
tc
qdi
s
c
•
tc
fi
l
t
e
r
•
tc
cl
as
s
Q
ue
ue
c
onf
i
g
•
que
ue
i
d
•
que
ue
m
i
n
bw
•
que
ue
m
a
x
bw
F
l
ow
c
onf
i
g
•
s
e
t
que
ue
•
s
e
t
pr
i
or
i
t
y
Figure
3.
Dri
v
er
modules
in
the
controller
are
the
means
for
de
vice-le
v
el
configuration
of
the
queues
IJECE
V
ol.
7,
No.
4,
August
2017:
2261
–
2277
Evaluation Warning : The document was created with Spire.PDF for Python.
IJECE
ISSN:
2088-8708
2267
Dy
n
a
m
i
c
r
es
o
u
r
c
e
a
l
l
o
c
a
t
i
o
n
St
a
t
i
c
r
es
o
u
r
c
e
a
l
l
o
c
a
t
i
o
n
(e.
g
.
M
P
LS
c
h
a
n
n
el
s
)
Figure
4.
T
w
o
allocation
schemes
for
tw
o
layers
of
the
netw
ork
4.
EAST
-WEST
COMMUNICA
TION
INTERF
A
CE
When
the
terminals
of
the
application
requiring
a
priority
path
are
located
in
tw
o
portion
of
the
netw
ork
pi-
loted
by
distinct
controllers,
a
communication
mechanism
between
these
controllers
is
necessary
in
order
to
e
xchange
the
proper
information
during
the
reserv
ation
process.
From
hereafter
,
we
will
use
the
term
domain
and
cluster
inter
-
changeably
to
indicate
distinct
portions
of
the
netw
ork.
At
the
origin
of
the
communication,
there
is
the
route
disco
v
ery
phase
to
share
the
endpoints
of
each
domain.
A
design
choice
is
to
be
made
on
ho
w
and
when
to
e
xpose
the
netw
ork
element
parameters
related
to
the
topology
itself.
There
are
tw
o
options:
a)
sharing
these
i
nformation
during
the
route
disco
v
ery
phase,
or
b)
a
v
oid
to
pre-share
the
parameters
and
collect
them
during
the
resource
reserv
ation
process
on-demand,
that
is,
e
v
ery
time
a
ne
w
request
arri
v
es.
Suppose
we
ha
v
e
a
portion
of
the
netw
ork
under
domain
A
,
and
another
portion
under
domain
B
,
then
suppose
that
at
some
point
in
time
an
application
connected
to
A
asks
for
a
priority
path
that
includes
an
endpoint
in
domain
B
.
The
tw
o
dif
ferent
approaches
are
described
in
the
follo
wing
sections.
4.1.
Pr
e-Shar
ed
Netw
ork
P
arameters
and
Band
width
Resour
ce
W
ith
option
(a)
,
the
controller
A
has
already
all
the
information
required
for
the
end-to-end
admission
control
routine
when
the
request
arri
v
es.
This
means
that
the
topology
e
xposed
by
B
to
A
shall
include
all
the
necessary
netw
ork
infrastructure
parameters,
(
c
l
;
M
T
U
;
C
tot
;
D
tot
;
d
pr
op
tot
)
p
for
all
p
in
the
set
of
paths
that
B
is
willing
to
e
xpose
to
A
,
which
in
turns
implies
that
the
e
xposed
topology
shall
be
detailed
enough
for
A
to
select
a
suitable
path.
This
requires
a
more
comple
x
topology
abstraction
than
the
single
big
switch
as
depicted
in
Fig.
2,
because
clearly
with
the
si
ng
l
e
node
abstract
ion
you
cannot
ha
v
e
as
man
y
path
properties
as
you
w
ould
ha
v
e
with
a
netw
ork
of
nodes.
Y
ou
can
al
w
ays
achie
v
e
a
certain
le
v
el
of
aggre
g
ation
by
hiding
element
s
of
the
B
topology
,
by
computing
the
aggre
g
ate
parameters
for
some
paths
to
w
ards
the
destinations
and
then
e
xposing
a
virtual
topology
composed
by
only
these
paths.
In
this
case
each
domain
controller
should
maintain
a
mapping
between
the
local
ph
ysical
de
vices
and
links
and
the
virtual
ones
e
xposed
to
the
remote
domains.
Other
than
the
topology
abstraction,
there
is
one
major
issue
with
this
approach:
the
computation
of
the
aggre
g
ate,
rate-related
delay
error
term,
C
tot
,
which
is
theoretically
not
feasible
when
the
computation
occurs,
for
instance,
in
the
domain
controller
A
for
some
de
vices
of
domain
B
,
because
C
depends
on
the
parameter
r
,
the
rate
requested
by
a
user
application.
So
either
C
,
e
xpressed
as
a
function
of
r
for
each
de
vice,
is
shared
during
the
topology
disco
v
ery
phase,
which
means
e
xposing
the
entire
topology
,
or
it
must
be
computed
on-demand,
by
the
domain
controller
B
as
described
in
the
ne
xt
section.
4.2.
On-demand
Netw
ork
P
arameters
and
Band
width
Resour
ce
In
this
case,
the
path
parameters
are
collected
and
e
xchanged
during
the
admission
control
routine.
The
do-
main
B
is
requested
to
run
the
resource
reserv
ation
process
in
its
o
wn
domain.
Controller
A
forw
ards
the
application
request
parameters
(i.e.
d
r
eq
,
the
tuple
(
b;
r
;
p
)
,
the
domain
ingress
point
and
the
tar
get
destination)
to
B
,
which
replies
with
a
tuple
(
M
;
C
tot
;
D
tot
;
d
p
)
B
and
an
upper
bound
on
R
,
chosen
based
on
a
proper
selected
path,
if
a
v
ailable,
so
that
A
can
compute
the
end-to-end
delay
bound
before
proceeding
with
the
actual
reserv
ation
and
path
setup.
This
w
ay
the
topology
abstraction
can
be
k
ept
as
simple
as
a
single
big
switch
whose
function
is
to
merely
of
fer
a
point
of
connection
t
o
the
remote
destinations
t
o
an
y
domain
controllers
with
which
there
is
a
peering.
The
netw
ork
parameters
and
the
resource
select
ion
comes
directly
from
an
up-to-date
decisi
on
process
made
within
the
concerned
domain.
The
computation
of
C
tot
can
be
actually
computed
while
masking
the
details
of
the
local
topology
.
This
approach
is
the
choice
of
our
implementation
prototype
described
in
the
rest
of
the
article.
A
Pr
oposal
for
End-to-End
QoS
Pr
o
visioning
...(F
r
ancesco
Lucr
ezia)
Evaluation Warning : The document was created with Spire.PDF for Python.
2268
ISSN:
2088-8708
4.3.
Resour
ce
Management
The
netw
ork
parameters
used
for
the
delay
bound
computation
in
equation
2
are
mainly
static,
e
xcept
for
the
bandwidth
R
,
the
dynamic
netw
ork
resourc
e
under
consideration.
W
e
assume
unlimited
b
uf
fer
space
for
the
queues,
or
at
least
enough
to
fill
the
entire
bandwidth
resource
in
an
y
link
of
the
netw
ork.
W
ithin
each
domain
a
resource
management
system
should
track
the
allocated
and
the
a
v
ailable
bandwi
dth
in
each
link
of
the
underlying
netw
ork.
From
the
inter
-domain
communication
perspecti
v
e,
the
bandwidth
resource
management
unfolds
three
cases
depending
on
the
use-case
scenario:
Full
shar
e
.
The
bandwidth
is
completely
shared
between
applications,
re
g
ardless
of
the
domain
the
y
reside.
This
can
be
the
case
where
the
control
plane
of
a
single
administrat
i
v
e
domain
is
split
into
multiple
re
gions
for
performance
reason
or
because
of
dif
ferent
underlying
ph
ysical
netw
orks.
In
this
scenario,
it
is
necessary
to
update
the
e
xposed
resource
each
time
an
application
obtains
or
releases
a
portion
of
the
bandwidth.
Upon
a
ne
w
allocation
or
release
in
one
domain,
a
mes
sage
is
sent
in
broadcast
to
all
the
other
domains
with
which
there
is
a
peering.
The
message
is
read
by
the
remote
controllers
and
their
local
resource
stores
are
updated
accordingly
.
In
the
on-demand
mode
of
communication,
Section
4.2.,
each
domain
manages
its
bandwidth
resource
independently
and
only
during
a
reserv
ation
process
the
resource
a
v
ailability
in
a
remot
e
domain
is
determined.
P
artial
shar
e
.
This
case
is
equal
to
the
pre
vious
one
b
ut
only
a
portion
of
the
bandwidth
is
shared
with
the
remote
domains.
P
artial
static
shar
e
.
A
domain
controller
adv
ertises
to
each
remot
e
controllers
a
virtual
v
alue
of
the
bandwidth
resource
during
the
route
disco
v
ery
phase
and
no
further
update
messages
are
e
xchanged
between
controllers.
This
v
alue
is
the
static
portion
of
the
bandwidth
allocated
to
each
remote
domain.
In
this
case,
also
with
the
on-
demand
mode
of
communication
a
controller
can
determine
the
a
v
ailability
of
bandwidth
e
v
en
before
contacting
a
remote
domain.
This
is
the
case
of
the
multi
administrati
v
e
domains
scenario.
5.
POLICY
ENFORCEMENT
Polic
y-based
QoS
management
is
of
primary
importance
for
netw
ork
operators.
If
the
service
discipline
at
the
netw
ork
interf
ace
is
the
lo
west
le
v
el
operation
gearing
QoS,
at
the
top
le
v
el
we
ha
v
e
the
SLAs
e
xpressed
in
terms
of
pol
icies.
The
SLAs
consist
of
a
set
of
specifications
that
are
translated
by
the
netw
ork
manager
into
de
vice
le
v
el
primiti
v
es
(e.g.,
forw
ardi
ng
rules,
queue
configurations,
traf
fic
shaping
policies,
etc.).
In
[31]
[32]
the
authors
pro-
pose
automatic
polic
y
based
management
system
in
the
Internet
Dif
fServ
architectures.
The
y
present
a
frame
w
ork
for
polic
y
management
that
reacts
to
netw
ork
state
changes
or
customer
users
requests
to
dynamically
re-adapt
the
polic
y
enforcement.
In
[33]
a
management
frame
w
ork
for
automati
c
polic
y
enforcement
is
introduced
in
a
netw
ork
controller
based
on
Openflo
w;
the
y
describe
all
the
necessary
functional
components
of
the
system
without
entering
in
the
implementation
details
of
an
y
of
them
thus
a
v
oiding
to
discuss
ho
w
do
the
y
actually
interact
between
each
other
.
The
focus
of
the
present
article
is
on
the
QoS
pro
visioning
in
the
economic
conte
xt
of
dyn
a
mic
SLAs;
this
frame
w
ork
foresees
the
possibility
to
be
inte
grated
with
an
e
xisting
polic
y-based
management
system.
The
concerned
SLAs
are
between
a
service
pro
vider
and
its
customers
and
between
service
pro
viders
who
cooperate
to
pro
vide
an
o
v
erall
service
that
can
span
multiple
administrati
v
e
domains.
Between
the
customer
and
the
pro
vider
,
a
set
of
APIs
can
be
embedded
directly
into
the
customer
applications
and
layered
on
top
of
an
e
xisting
polic
y
management
system.
The
netw
ork
operator
could
also
pro
vide
ready-to-use
applicati
ons
for
specific
services
(e.g.
a
remote
health
control
system).
Here
we
limit
the
discussion
by
listing
the
additional
information
needed
by
the
polic
y
manager
in
order
to
conform
the
ingress
traf
fic
to
the
dynamic
SLAs.
P
olicy
to
regulate
the
interaction
with
customer
applications:
List
of
user
and
application
IDs
that
are
allo
wed
to
request
a
service
Upper
bound
on
the
amount
of
bandwidth
each
user
could
request
Maximum
amount
of
time
each
user
is
allo
wed
to
retain
a
priority
path
Amount
of
bandwidth
reserv
ed
to
the
best
ef
fort
traf
fic
Set
of
destinations
for
which
a
user
could
request
a
priority
path
Set
of
netw
ork
elements
that
cannot
be
part
of
the
reserv
ation
process
Pre-configured
queues
for
selected
customers
or
applications
IJECE
V
ol.
7,
No.
4,
August
2017:
2261
–
2277
Evaluation Warning : The document was created with Spire.PDF for Python.
IJECE
ISSN:
2088-8708
2269
P
olicy
to
regulate
the
interaction
betw
een
pro
viders:
List
of
peer
domains
that
are
allo
wed
to
interact
with
the
local
domain
List
of
destinations
to
e
xpose
to
the
remote
domains
T
opology
abstraction
to
e
xpose
to
the
remote
domains
V
irtual
bandwidth
resource
associated
to
the
e
xposed
destinations
Aggre
g
ate
parameters
selection,
M
T
U
;
C
tot
;
D
tot
;
d
p
Number
of
total
service
requests
that
a
remote
cluster
is
able
to
perform
Pre-configured
queues
for
selected
peers
6.
ARCHITECTURE
6.1.
High-le
v
el
System
Components
The
main
functi
onal
modules
in
the
control
plane
are
pr
otocol
a
gnostic
thanks
to
the
separation
of
concerns
gi
v
en
by
the
netw
ork
controller
architecture
of
ONOS
(see
Section
6.2.)
that
is
partitioned
into:
Protocol-a
w
are
netw
ork-f
acing
modules
that
interact
with
the
netw
ork
Protocol-agnostic
system
core
that
tracks
and
serv
es
information
about
netw
ork
state
Applications
that
consume
and
act
upon
the
information
pro
vided
by
the
core
At
the
application
layer
resides
the
admission
contr
ol
and
r
esour
ce
allocation
routine.
It
guarantees
the
correctness
of
the
QoS
pro
visioning
to
the
end-user
applications;
it
has
to
dynamically
setup
a
n
d
teardo
wn
multiple
and
concurrent
QoS
profile
sessions
and
v
erify
that
e
v
erything
in
the
underlying
netw
ork
is
up-to-date
and
in
a
consistent
state
.
In
the
core
controller
there
are
se
v
eral
components
required
to
accomplish
the
compl
ete
reserv
ation
process,
see
Figure
5,
while
in
the
netw
ork-f
acing
layer
we
ha
v
e
as
man
y
dri
v
ers
as
the
number
of
dif
ferent
d
e
vices
in
the
underlying
net-
w
ork
and
a
comm
unication
interf
ace
used
to
e
xchange
data
between
the
domain
netw
ork
controllers.
Such
interf
ace
has
to
tak
e
into
account
se
v
eral
aspects
of
the
system:
routes
to
destinations
disco
v
ery
,
netw
ork
topology
elements
e
xposition,
resource
reserv
ation
parameters
and
a
polic
y-dri
v
en
mechanism
to
abide
t
o
the
SLA
made
between
the
in
v
olv
ed
administrati
v
e
domains.
W
e
le
v
erage
on
a
project
called
ICON
A
to
fulfil
the
remote
topology
and
destina-
tions
disco
v
ery
function,
see
Section
6.4..
The
resource
reserv
ation
parameters
are
currently
e
xchanged
during
the
admission
contr
ol
routine
at
the
application
layer
,
using
a
prototype
REST
channel
interf
ace.
The
inte
gration
with
a
polic
y
manager
is
left
as
a
future
w
ork.
P
a
t
h M
a
na
ge
r
A
dm
i
s
s
i
on C
ont
r
ol
F
r
ont
-
E
nd
A
P
I
s
P
r
of
i
l
e
S
t
or
e
Q
ue
ue
C
onf
i
gur
a
t
i
on
I
nt
e
nt
I
ns
t
a
l
l
e
r
T
opol
ogy M
a
na
ge
r
N
e
t
. E
l
e
m
. S
t
or
e
R
e
s
our
c
e
M
a
na
ge
r
D
e
vi
c
e
M
a
na
ge
r
D
om
a
i
n M
a
na
ge
r
I
nt
e
nt
M
a
na
ge
r
F
l
ow
R
ul
e
M
a
na
ge
r
D
r
i
ve
r
M
a
na
ge
r
D
e
vi
c
e
D
r
i
ve
r
s
R
e
m
ot
e
D
om
a
i
n
T
opol
ogy
P
r
ovi
de
r
A
ppl
i
c
a
t
i
on
C
or
e
P
r
ot
oc
ol
s
P
r
ot
oc
ol
s
Figure
5.
Controller’
s
Main
Components
A
Pr
oposal
for
End-to-End
QoS
Pr
o
visioning
...(F
r
ancesco
Lucr
ezia)
Evaluation Warning : The document was created with Spire.PDF for Python.
2270
ISSN:
2088-8708
A
ppl
i
c
a
t
i
on
N
or
t
hbound
–
I
nt
e
nt
F
r
a
m
e
w
or
k
(
pol
i
c
y e
nf
or
c
e
m
e
nt
, c
onf
l
i
c
t
r
e
s
ol
ut
i
on)
D
i
s
t
r
i
but
e
d C
or
e
(
s
c
a
l
a
bi
l
i
t
y
, pe
r
s
i
s
t
e
nc
e
, a
va
i
l
a
bi
l
i
t
y)
S
out
hbound
(
di
s
c
ove
r
, obs
e
r
ve
, pr
ogr
a
m
,
c
onf
i
gue
)
O
pe
nf
l
ow
N
e
t
C
onf
OVS
DB
Figure
6.
ONOS
distrib
uted
architecture
6.2.
An
o
v
er
view
of
ONOS
The
Open
Netw
ork
Operating
System
(ONOS)
is
a
softw
are
defined
netw
orking
(SDN)
OS
for
Service
Pro
viders,
that
is
tar
geting
scalability
,
high
a
v
ailability
,
high
performance
and
abstractions
to
mak
e
it
easy
to
cre-
ate
apps
and
services
[34].
ONOS
implements
a
distrib
uted
architecture
in
which
multiple
controller
instances
share
multiple
distrib
uted
data
stores
with
dif
ferent
le
v
el
of
consistenc
y
.
The
entire
data
plane
is
managed
simultaneously
by
the
whole
cluster
.
Ho
we
v
er
,
for
each
de
vice
a
single
controller
acts
as
a
master
,
while
the
others
are
ready
to
step
in
if
a
f
ailure
occurs.
W
ith
these
mechanisms
in
place,
ONOS
achie
v
es
scalability
and
res
ilienc
y
.
Figure
6
sho
ws
the
ONOS
internal
archi-
tecture
within
a
cluster
of
four
instances.
ONOS
is
based
on
softw
are
modules
managed
by
the
Apache
Karaf
suite
[35],
a
set
of
ja
v
a
OSGi
based
runtime
and
applications.
It
pro
vides
a
container
into
which
v
arious
component
can
be
deplo
yed,
installed,
upgraded,
started
and
stopped
at
runtime,
without
interfering
other
components.
The
southbound
modules
manage
the
ph
ysical
topology
,
react
to
netw
ork
e
v
ents
and
program/configure
the
de
vices
le
v
eraging
on
dif-
ferent
protocols.
The
distrib
uted
core
is
responsible
to
maintain
coherent
infor
mation,
to
elect
the
master
controller
for
each
netw
ork
portion
and
to
share
information
with
the
adjacent
layers.
In
case
of
a
f
ailure
in
the
data
path
(switch,
link
or
port
do
wn),
an
ONOS
instance
becomes
a
w
are
of
the
e
v
ent
through
the
s
outhbound
modules,
computes
alter
-
nati
v
e
paths
for
all
the
traf
fic
crossing
the
f
ailed
element,
and
notifies
them
to
the
distrib
uted
core;
then,
each
master
controller
configures
accordingly
its
portion
of
the
netw
ork.
The
northbound
subsystem
of
fers
an
abstraction
of
the
netw
ork
and
the
interf
ace
for
applications
to
interact
and
program
the
NOS.
Finally
,
the
Application
layer
of
fers
a
container
in
which
third-party
applications
can
be
deplo
yed.
Applications
on
top
of
ONOS
can
benefit
of
the
Intent
Frame
w
ork.
The
ONOS
core
accepts
the
intent
specifications
and
translates
them
into
actionable
operations
on
the
netw
ork
en
vironment.
These
actions
are
carried
out
by
the
intent
installation
process,
such
flo
w
rules
being
installed
on
a
switch,
or
optical
lambdas
(w
a
v
elengths)
being
reserv
ed.
6.3.
The
Manager
A
pplication
The
manager
application
is
a
standard,
on-platform
ONOS
application.
Its
main
function
is
the
admission
contr
ol
routine.
W
e
separate
the
routing
and
resource
assignment
process
into
tw
o
steps:
the
collection
of
candidate
paths
between
the
application
terminals
through
the
ONOS
P
athMana
g
er
and
the
selection
of
the
one
that
satisfies
the
constraints
imposed
by
the
basic
admission
contr
ol
scheme
des
cribed
in
Section
3..
The
state
of
the
underlying
netw
ork
resources
is
track
ed
by
the
Resour
ceMana
g
er
,
back
ed
by
a
distrib
uted
store,
whic
h
is
queried
during
this
process
to
reserv
e
the
bandwidth
resource.
The
local
path
parameters
are
collected
by
the
internal
store
populated
with
the
information
of
t
h
e
underlying
netw
ork
elements,
while
i
n
presence
of
virtual
domain
de
vices,
the
parameters
are
queried
to
the
remote
controllers
and
then
mer
ged
with
the
local
ones.
If
a
suitable
path
is
found
using
algorithm
1,
the
bandwidth
in
each
link
is
temporary
reserv
ed
(lock
ed),
priorities
queues
are
setup
in
each
de
vice
through
the
QueueMana
g
er
module
and
an
intent
is
submitted
by
the
IntentInstaller
(Fig.
7).
If
the
installation
is
successful,
the
Resour
ceMana
g
er
is
requested
to
allocate
the
pre
viously
lock
ed
resource,
otherwise
a
rollback
is
performed
on
all
the
IJECE
V
ol.
7,
No.
4,
August
2017:
2261
–
2277
Evaluation Warning : The document was created with Spire.PDF for Python.