This document discusses the need for a standardized information model and high-level northbound API for SDN to abstract away the low-level details of existing protocols like OpenFlow. It proposes defining a common data-centric information model using UML that existing SDN protocols and middleware platforms can map to in order to provide interoperability and simplify development. RTI and Cisco believe this model-driven approach will help unify and evolve SDN systems to accommodate multiple protocols and legacy networks.
How to Troubleshoot Apps for the Modern Connected Worker
RTI/Cisco response to the OMG Software Defined Networks (SDN) RFI
1. OMG
SDN
RFI
Response
from
RTI
and
Cisco
Contacts:
Gerardo
Pardo-‐Castellote
(RTI)
gerardo
AT
rti
DOT
com
Gary
Berger
(Cisco)
gaberger
AT
cisco
DOT
com
1 Summary
It
is
well
understood
that
OpenFlow
is
a
low-‐level
interface
for
network
programming
surfacing
the
need
for
a
high-‐level
programming
model
to
help
developers
reap
the
benefits
of
simplified
network
management.
SDN
programming
relies
on
the
ability
to
query
network
state,
define
forwarding
policies
and
update
policies
in
a
consistent
way.
Another
important
aspect
is
the
management
and
configuration
interfaces
across
heterogeneous
devices.
Current
northbound
API’s
still
force
developers
to
think
in
terms
of
match-‐action
rules
and
not
in
higher
level
abstractions
with
proper
compositional
semantics
[12-‐
14].
Part
of
the
problem
lies
in
the
various
protocols
being
adopted
for
SDN
including
OpenFlow,
OF-‐CONFIG,
PCEP,
I2RS,
OVSDB,
IF-‐MAP,
OnePK,
etc.
Vendors
must
either
build
adapters
for
each
or
rely
on
a
mediation
server
such
as
OpenDaylight
Controller
Service
Abstraction
Layer
[20]
to
provide
the
mediation
between
protocols.
Each
of
these
protocols
expands
the
feature
space
with
sometimes
conflicting
behaviors
and
representations
making
it
difficult
to
design
a
high-‐level
interface
which
addresses
the
developers
need
to
build
applications
out
of
multiple
independent
and
reusable
network
policies
that
must
act
on
the
same
traffic
[12].
With
this
in
mind,
the
first
step
towards
developing
and/or
standardizing
a
Northbound
protocol
and/or
API
should
be
the
standardization
of
the
information
model
that
represents
the
observable
and
controllable
state
of
the
SDN
network
elements.
Model
Driven
Architectures
are
fundamental
to
building
platform
and
computation
independent
services
[18].
SDN
adopts
some
of
these
principals
leveraging
schema
driven
approaches
[16]
and
data
driven
models
[17]
but
there
are
no
efforts
to
converge
onto
a
well-‐understood
model
that
can
be
used
to
define
the
protocol
and
API
interaction.
In
this
respect
our
motivation
is
to
leverage
existing
middleware
technologies
and
architectures
such
as
DDS,
XMPP,
AMQP
and
REST
to
provide
an
extensible
and
www.rti.com
www.cisco.com
2. adaptable
protocol,
which
will
promote
unification
and
simplify
access
to
the
goals
of
querying
state,
notification
of
changes,
forwarding
policy,
security
and
performance
policies.
For
instance
leveraging
middleware
platforms
which
can
automatically
define
the
network
data
representations,
network
protocols,
discovery
mechanism,
and
the
means
to
scale
in
a
fault
tolerant
way
would
allow
more
concentration
on
the
higher
level
abstractions,
composition
and
segmentation
of
controller
logic.
In
addition
these
middleware
platforms
provide
standard
APIs
in
different
programming
languages,
so
the
API
also
comes
“for
free”
once
the
mapping
is
done.
While
technically
it
may
be
possible
we
do
not
believe
that
it
would
be
practical
to
define
a
single
middleware
platform
because
different
providers
have
strong
preferences
and
deployed
technologies
and
are
unlikely
to
simply
agree
to
a
common
middleware
platform.
Beyond
practical
agreement,
having
multiple
middleware
platforms
leaves
the
door
open
for
innovation
and
evolution,
and
moreover
it
may
provide
technical
advantages
as
different
middleware
technologies
differ
in
scalability,
performance
and
support
for
communications
patterns
and
QoS.
The
support
and
co-‐existence
of
multiple
middleware
platforms
is
also
necessary
to
accommodate
legacy
systems
and
should
not
introduce
too
much
complexity
as
long
as
they
all
map
a
common
SDN
information
model.
2 RFI
Response
SDN
systems
provide
opportunity
to
separate
control
plane
services
from
the
data
plane.
Traditional
networks
distribute
state
through
embedded
control
algorithms
leveraging
many
different
protocols
(RIP,
LLDP,
OSPF,
etc).
This
model
has
been
proven
inflexible
and
complex
due
to
the
diversity
of
devices
and
the
use
of
closed
proprietary
vendor-‐specific
interfaces
and
the
need
to
individually
configure
each
device.
Recently
OpenFlow
has
emerged
as
a
standard
protocol
that
can
be
used
to
configure
these
devices
and
query
their
state.
It
is
already
supported
by
many
network
device
vendors
and
deployed
in
datacenters
and
backbone
networks.
However,
it
is
a
low-‐level
protocol,
has
been
difficult
to
program
against,
and
it
is
but
one
of
many
approaches
currently
being
explored
[21].
It
is
also
desirable
to
offer
incremental
ways
to
migrate
legacy
systems
to
SDN
and
provide
leave
the
door
open
for
innovation
and
evolution.
Our
perspective
is
that
multiple
protocols
and
APIs
will
necessarily
co-‐exist
and
therefore
the
first
step
to
add
a
layer
of
abstraction
creating
a
unified
architecture.
It
is
our
goal
to
define
a
solid
and
evolvable
information
model
that
can
be
used
as
the
foundation
to
map
and
bridge
existing
protocols.
The
model
should
be
www.rti.com
www.cisco.com
3. independent
of
specific
middleware
platforms
or
technologies
and
be
comprehensive
enough
to
allow
those
existing
platforms
to
be
mapped.
We
believe
that
the
most
promising
approach
would
be
use
UML
to
define
a
data-‐
centric
information
model.
A
data-‐centric
model
has
the
advantage
of
making
no
assumptions
about
protocols,
interactions,
or
APIs.
It
simply
models
the
information:
flows,
access
rules,
statistics,
these
are
things
that
are
reasonable
well
understood
and
agreed
in
the
SDN
community.
Being
grounded
in
the
physics
of
network
flows
the
model
is
also
more
stable
than
APIs,
protocols,
and
policies.
Once
a
the
UML
data-‐centric
information
model
is
developed
it
can
be
mapped
to
legacy
technologies,
such
as
SNMP,
standards
like
Open
Flow,
and
vendor-‐
proprietary
mechanisms
such
as
Cisco
OnePK,
Juniper
Contrail,
VmWare
NSX.
This
provides
an
open
and
evolvable
way
to
interact
with
the
network
devices.
In
addition
to
mapping
to
low
level
device
oriented
protocols
such
as
OpenFlow,
the
data-‐centric
information
model
can
also
be
mapped
to
existing
middleware
platforms
such
as
DDS,
XMPP,
and
AMQP.
These
mappings
provide
the
scalable
distribution
protocols,
network
representations,
and
language
APIs
needed
to
interact
remotely.
Controllers
could
use
one
or
more
of
these
technologies
to
access
the
state
of
the
network
devices
and
modify
their
configuration.
Using
standard
middleware
technologies
avoids
“reinventing
the
wheel”
and
leverages
the
middleware
technology
platform
for
the
things
it
is
very
good
at:
scalable
and
robust
distribution
of
information.
For
example
DDS
already
provides
mechanisms
for
discovery,
asynchronous
notification,
scalable
content-‐based
subscription,
reliability
in
the
presence
of
connection
failures,
data-‐distribution
Qos,
robust
management
of
DIL
environments,
etc.
Other
middleware
technologies,
XMPP,
AMQP,
REST,
also
provide
valuable
capabilities
that
would
be
automatically
leveraged.
3 Response
to
the
specific
questions
in
the
RFI
3.1 How
does
the
SDN
ecosystem
maintain
an
open,
vendor-‐neutral,
abstract
set
of
APIs
for
network
related
entities
including
but
not
limited
to
elements,
flows,
policies
and
applications?
Rationale:
To
simplify
network
related
application
development
for
new
and
existing
SDN
controllers
This
could
be
accomplished
in
two
steps:
a) A
vendor-‐neutral
data-‐centric
information
model
could
be
defined
that
covers
the
observable
state
of
the
software-‐controlled
network
elements
(controllers,
switches,
etc.),
the
controllable
services
it
offers,
and
the
mechanisms
to
control
that
state.
b)
The
information
model
could
be
mapped
to
a
variety
of
standard
protocols
offering
API
portability
and
network
interoperability.
For
example
DDS,
REST,
or
XMPP
www.rti.com
www.cisco.com
4. The
vendor
neutral
information
model
could
be
defined
using
UML.
This
higher-‐
level
model
expresses
the
kind
of
information
that
can
be
observed
from
the
network
elements,
such
as
flow
information,
the
associated
schemas,
neighboring
information,
link-‐status,
etc.
It
also
describes
the
kinds
of
control-‐commands
that
are
accepted
by
the
switch.
While
a
normalization
of
this
is
desirable
it
is
not
strictly
necessary
as
the
model
could
encompass
different
versions
(as
would
be
derived
from
different
versions
of
open
flow
versus
Cisco
OnePK,
and
even
multiple
versions
of
those).
The
information
model
would
be
data-‐centric
because
it
focuses
on
exposing
the
state
of
the
network
elements
and
their
controllable
elements
and
not
specifically
on
sequences
of
commands,
message-‐exchange
or
handshakes.
This
approach
maps
well
to
middleware
technologies
such
as
REST
and
DDS
and
has
been
proven
to
be
simpler
and
more
scalable
than
an
RPC
or
RMI
oriented
model.
The
mapping
of
the
data-‐centric
information
model
two
different
middleware
platforms
would
provide
the
portable
and
interoperable
APIs
to
interact
with
the
network
elements.
The
set
of
mapped
middleware
technologies
can
remain
open
and
evolve.
Supporting
more
than
one
approach
provides
significant
benefits:
(a)
(b)
Different
middleware
technologies
offer
different
tradeoffs
with
regards
to
performance,
scalability,
and
ease
of
use,
and
Practically
it
would
be
next
to
impossible
to
have
everyone
“agree”
on
a
single
middleware
given
that
existing
players
have
strong
preferences
for
technologies
they
are
familiar
with
or
have
vested
interest
in
(XMPP,
AMQP,
HTTP/REST,
DDS).
Beyond
the
practical
advantages,
the
effort
of
mapping
a
middleware
is
reasonably
small.
Protocols,
data-‐formats,
language
APIs,
etc.
are
all
defined
and
provided
by
each
middleware
platform.
All
it
takes
is
a
mapping
of
the
information
model
to
the
artifacts
the
middleware
provides)
and
having
multiple
does
not
create
significant
complexity.
Since
all
the
middleware
mappings
originate
from
a
common
information
model
the
bridging
can
be
done
by
automatic
tools
or
well
defined
gateway
services.
3.2 How
does
the
SDN
ecosystem
support
network
related
entity
discovery,
connection,
configuration,
performance
and
fault
management?
Rationale:
To
maintain
the
functional
network
management
capabilities
available
to
legacy
non-SDN
networks
These
features
would
come
from
the
facilities
provided
by
the
middleware
platform
and
the
mapping
of
the
SDN
information
model
to
the
corresponding.
Middleware
platform.
When
using
DDS
entity
discovery
would
be
provided
by
the
built-‐in
DDS-‐
Entity
discovery
mechanism
similarly
for
XMPP
and
other
middleware
platforms.
www.rti.com
www.cisco.com
5. 3.3 How
does
the
SDN
ecosystem
support
interoperability
of
network
control
and
operational
data
at-‐rest
and
in-‐motion?
Rationale:
Exposure
and
marshaling
in
consistent
data
formats,
structures
simplifies
network
related
application
development.
Similar
to
the
previous.
This
would
simply
leverage
the
mechanisms
provide
by
the
middleware
platforms.
3.4 How
does
the
SDN
ecosystem
support
multiple
programming
languages?
Rationale:
To
enable
an
evolving
and
diverse
SDN
ecosystem
for
application
development.
Similar
to
the
previous.
This
is
already
provided
by
the
different
middleware
platforms.
3.5 What
architectural
patterns
could
mitigate
the
Controller
choke
point
problem?
(e.g.,
Could
separation
of
operational
data
collection
from
network
data
achieve
this?)
Rationale:
Existing
network
architectures
create
a
constricted
conduit
through
which
operational
data
flows
to
network
controllers.
Scaling
up
the
number
of
controllers,
switches,
and
appliances
compounds
the
problem.
Scaling
the
information
distribution
is
something
that
middleware
platforms
are
already
doing.
This
one
of
their
fundamental
value-‐adds
to
a
system.
The
key
point
is
that
the
proposed
approach
leverages
the
technology
and
investment
that
the
middleware
providers
are
doing.
It
would
seem
that
the
publish-‐subscribe
pattern
offered
y
technologies
such
as
DDS,
XMPP,
and
AMQP
could
be
one
of
the
main
architectural
patterns.
Beyond
that,
using
peer-‐to-‐peer
middleware
platforms
such
as
DDS
and
XMPP,
which
unlike
AMQP
do
not
force
messages
to
flow
via
intermediate
points
or
brokers,
would
be
important
to
avoid
introducing
additional
choke
points.
3.6 How
does
the
SDN
ecosystem
support
existing
networking
standards?
Rationale:
To
enable
co-existence
for
legacy
network
components
such
as
Simple
Network
Management
Protocol
(SNMP).
Existing
network
standards
would
be
mapped
to
the
SDN
information
model,
similar
to
how
the
new
middleware
platforms
are
mapped.
Once
this
is
done
it
is
possible
to
develop
gateways
that
would
translate
between
those
standards
and
the
ones
the
operator
chooses
to
deploy.
www.rti.com
www.cisco.com
6. 3.7 Does
the
response
relate
to
other
SDN
efforts
underway?
Rationale:
To
enable
collaboration
and
avoid
conflicts
and
redundancies
between
SDN
community
efforts.
The
OMG
would
focus
on
the
areas
in
its
areas
of
core
expertise,
namely
leveraging
the
existing
UML
and
middleware
standards
to
providing
suitable
ways
to
model
the
SDN
information
and
map
it
to
middleware
technologies
such
as
DDS,
REST,
and
XMPP.
The
SDN
information
model
is
proposed
here
would
provide
a
framework
in
which
multiple
standards
would
co-‐exists
and
also
provide
the
tools
necessary
to
bridge
and
harmonize
between
those
standards.
3.8 How
are
SDN
ecosystem
events
from
data
and
controller
planes
etc.
handled?
Rationale:
Existing
SDN
architectures
are
perceived
to
have
scaling
issues
attributed
to
network
status
and
configuration
polling.
These
mechanisms
are
provided
by
the
middleware
platform.
The
use
of
middleware
platforms
that
support
scalable
event-‐distribution
mechanisms
would
address
this.
For
example
when
using
DDS
the
publish-‐subscribe
pattern
combined
with
the
writer-‐side
content-‐based
filtering
that
DDS
offers
would
provide
the
scalable
event
distribution.
3.9 How
does
the
ecosystem
interoperate
with
legacy
network
architectures?
Rationale:
To
enable
co-existence
for
legacy
network
components
and
support
evolving
network
topologies.
Yes.
To
the
extent
that
legacy
approaches
can
be
mapped
to
the
Information
Model
and
a
proper
gateway
is
developed.
3.10 How
does
the
SDN
ecosystem
support
federated
data
centers?
Rationale:
The
purpose
of
aggregating
Control
Planes
is
to
optimize
data
requests
from
SDN
applications.
In
a
distributed
data
center
environment,
aggregation
into
a
single
Control
Plane
can
cause
unacceptable
latency.
This
is
also
typically
provided
by
the
different
middleware
platforms.
DDS
for
example
supports
smart
federations.
3.11 How
does
the
SDN
ecosystem
handle
Disconnected,
Intermittent,
and
Limited
(DIL)
environments?
Rationale:
Many
controllers,
switches,
and
appliances
are
deployed
within
mobile
environments
such
as
airplanes,
ships,
trains,
and
cars.
These
environments
will
experience
intermittent
connectivity
with
times
of
no
connectivity
or
restricted
bandwidth.
www.rti.com
www.cisco.com
7. Similar
to
the
previous
this
type
of
facility
is
already
provided
by
middleware
platforms
such
as
DDS
so
it
would
become
automatically
available
when
using
that
platform.
Since
multiple
middleware
platforms
can
co-‐exist
and
be
bridged
it
is
always
possible
to
choose
one
of
the
most
appropriate
middleware
platform
to
handle
the
DIL
portions
of
the
system.
4 References
1)
OpenFlow
https://www.opennetworking.org/images/stories/downloads/sdn-‐
resources/onf-‐specifications/openflow/openflow-‐spec-‐v1.4.0.pdf
2)
Cisco
OnePK.
http://www.cisco.com/en/US/prod/iosswrel/onepk.html
3)
Opendaylight
project.
http://www.opendaylight.org/
4)
Juniper
Contrail
Architecture
http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-‐en.pdf
5)
Conry
Murray,
Andrew
“Cisco
and
OpenDaylight:
The
SDN
Application
Land
Grab”
6)
VMWare
NSX
http://cto.vmware.com/introducing-‐vmware-‐nsx-‐the-‐platform-‐
for-‐network-‐virtualization/
7)
OMG
Data-‐Distribution
Service
specification
(DDS).
www.omg.org/spec/DDS/1.2/
8)
The
Real-‐Time
Publish-‐Subscribe
Wire
Protocol
DDS
Interoperability
Wire
Protocol
(DDS-‐RTPS)
http://www.omg.org/spec/DDS-‐RTPS/
9)
Extensible
And
Dynamic
Topic
Types
For
DDS
(DDS-‐XTypes).
http://www.omg.org/spec/DDS-‐XTypes/
10)
Extensible
Messaging
and
Presence
Protocol
(XMPP)
.
http://tools.ietf.org/html/rfc6120
11)
Advanced
Message
Queuing
Protocol
(AMQP)
http://docs.oasis-‐
open.org/amqp/core/v1.0/amqp-‐core-‐complete-‐v1.0.pdf
12)
Christopher
Monsanto,
Joshua
Reich,
Nate
Foster,
Jennifer
Rexford,
and
David
Walker.
Composing
Software
Defined
Networks.
In
USENIX
Symposium
on
Networked
Systems
Design
and
Implementation
(NSDI),
Lombard,
IL,
April
2013
13)
Nate
Foster,
Michael
J.
Freedman,
Arjun
Guha,
Rob
Harrison,
Naga
Praveen
Katta,
Christopher
Monsanto,
Joshua
Reich,
Mark
Reitblatt,
Jennifer
Rexford,
Cole
Schlesinger,
Alec
Story,
and
David
Walker.
Languages
for
software-‐
defined
networks.
IEEE
Communications
Magazine,
51(2):128-‐134,
2013.
www.rti.com
www.cisco.com
8. 14)
Joshua
Reich,
Christopher
Monsanto,
Nate
Foster,
Jennifer
Rexford,
and
David
Walker.
Modular
SDN
Programming
with
Pyretic.
;login
Magazine,
38(5):128-‐
134,
2013.
15)
A.
Voellmy,
H.
Kim,
and
N.
Feamster.
Procera:
a
language
for
high-‐level
reactive
network
control.
In
Proceedings
of
the
first
workshop
on
hot
topics
in
software
defined
networks,
HotSDN
'12,
pages
43{48,Helsinki,
Finland,
2012.
16)
http://git.openvswitch.org/cgi-‐
bin/gitweb.cgi?p=openvswitch;a=blob;f=vswitchd/vswitch.ovsschema
17)
https://wiki.opendaylight.org/view/YANG_Tools:YANG_to_Java_Mapping
18)
http://www.omg.org/cgi-‐bin/doc?omg/03-‐06-‐01
19)
http://tools.ietf.org/html/rfc6020
20)
OpenDaylight
Controller
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-‐
SAL:Architecture
21)
Guide:
Vendors
take
alternatives
to
OpenFlow
SDN.
http://searchsdn.techtarget.com/guides/Guide-‐OpenFlow-‐SDN-‐not-‐the-‐only-‐
show-‐in-‐town-‐for-‐vendors
www.rti.com
www.cisco.com