SlideShare a Scribd company logo
1 of 8
Download to read offline
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	
  
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	
  
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	
  
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	
  
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	
  
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	
  
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	
  
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	
  

More Related Content

What's hot

Part I -Summary of service oriented architecture (soa) concepts, technology, ...
Part I -Summary of service oriented architecture (soa) concepts, technology, ...Part I -Summary of service oriented architecture (soa) concepts, technology, ...
Part I -Summary of service oriented architecture (soa) concepts, technology, ...Mohammed Omar
 
Applications Drive Secure Lightpath Creation Across Heterogeneous Domains
Applications Drive Secure Lightpath Creation Across Heterogeneous DomainsApplications Drive Secure Lightpath Creation Across Heterogeneous Domains
Applications Drive Secure Lightpath Creation Across Heterogeneous DomainsTal Lavian Ph.D.
 
213650704 literature-survey
213650704 literature-survey213650704 literature-survey
213650704 literature-surveySrikanth Reddy
 

What's hot (7)

Part I -Summary of service oriented architecture (soa) concepts, technology, ...
Part I -Summary of service oriented architecture (soa) concepts, technology, ...Part I -Summary of service oriented architecture (soa) concepts, technology, ...
Part I -Summary of service oriented architecture (soa) concepts, technology, ...
 
Abhilash_CV
Abhilash_CVAbhilash_CV
Abhilash_CV
 
Applications Drive Secure Lightpath Creation Across Heterogeneous Domains
Applications Drive Secure Lightpath Creation Across Heterogeneous DomainsApplications Drive Secure Lightpath Creation Across Heterogeneous Domains
Applications Drive Secure Lightpath Creation Across Heterogeneous Domains
 
A210105
A210105A210105
A210105
 
542 546
542 546542 546
542 546
 
213650704 literature-survey
213650704 literature-survey213650704 literature-survey
213650704 literature-survey
 
Royal Saudi Air Force - RSAF
Royal Saudi Air Force - RSAFRoyal Saudi Air Force - RSAF
Royal Saudi Air Force - RSAF
 

Similar to RTI/Cisco response to the OMG Software Defined Networks (SDN) RFI

Architecture evolution for automation and network programmability
Architecture evolution for automation and network programmabilityArchitecture evolution for automation and network programmability
Architecture evolution for automation and network programmabilityEricsson
 
Software Defined Networks
Software Defined NetworksSoftware Defined Networks
Software Defined NetworksShreeya Shah
 
netconf, restconf, grpc_basic
netconf, restconf, grpc_basicnetconf, restconf, grpc_basic
netconf, restconf, grpc_basicGyewan An
 
Ericsson Review: Software-Defined-Networking
Ericsson Review: Software-Defined-NetworkingEricsson Review: Software-Defined-Networking
Ericsson Review: Software-Defined-NetworkingEricsson
 
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...University of Technology - Iraq
 
Software defined optical communication
Software defined optical communicationSoftware defined optical communication
Software defined optical communicationRonak Vyas
 
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...IBM India Smarter Computing
 
An Investigation into Convergence of Networking and Storage Solutions
An Investigation into Convergence of Networking and Storage Solutions An Investigation into Convergence of Networking and Storage Solutions
An Investigation into Convergence of Networking and Storage Solutions Blesson Babu
 
Module1 Mobile Computing Architecture
Module1 Mobile Computing ArchitectureModule1 Mobile Computing Architecture
Module1 Mobile Computing Architectureraksharao
 
ENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKING
ENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKINGENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKING
ENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKINGIJCNCJournal
 
Cc unit 2 ppt
Cc unit 2 pptCc unit 2 ppt
Cc unit 2 pptDr VISU P
 
Sreerag what is a web service
Sreerag   what is a web serviceSreerag   what is a web service
Sreerag what is a web serviceSreerag Gopinath
 
.Net projects 2011 by core ieeeprojects.com
.Net projects 2011 by core ieeeprojects.com .Net projects 2011 by core ieeeprojects.com
.Net projects 2011 by core ieeeprojects.com msudan92
 
Software-Defined Networking(SDN):A New Approach to Networking
Software-Defined Networking(SDN):A New Approach to NetworkingSoftware-Defined Networking(SDN):A New Approach to Networking
Software-Defined Networking(SDN):A New Approach to NetworkingAnju Ann
 
Cloud computing and Software defined networking
Cloud computing and Software defined networkingCloud computing and Software defined networking
Cloud computing and Software defined networkingsaigandham1
 
Anuta NCX Platform Overview - Agile Network Services with Orchestration
Anuta NCX Platform Overview - Agile Network Services with OrchestrationAnuta NCX Platform Overview - Agile Network Services with Orchestration
Anuta NCX Platform Overview - Agile Network Services with OrchestrationKiran Sirupa
 

Similar to RTI/Cisco response to the OMG Software Defined Networks (SDN) RFI (20)

Architecture evolution for automation and network programmability
Architecture evolution for automation and network programmabilityArchitecture evolution for automation and network programmability
Architecture evolution for automation and network programmability
 
Report-SDN
Report-SDNReport-SDN
Report-SDN
 
Software Defined Networks
Software Defined NetworksSoftware Defined Networks
Software Defined Networks
 
netconf, restconf, grpc_basic
netconf, restconf, grpc_basicnetconf, restconf, grpc_basic
netconf, restconf, grpc_basic
 
Lecture 17
Lecture 17Lecture 17
Lecture 17
 
Ericsson Review: Software-Defined-Networking
Ericsson Review: Software-Defined-NetworkingEricsson Review: Software-Defined-Networking
Ericsson Review: Software-Defined-Networking
 
TERM PAPER
TERM PAPERTERM PAPER
TERM PAPER
 
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
 
Software defined optical communication
Software defined optical communicationSoftware defined optical communication
Software defined optical communication
 
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
 
An Investigation into Convergence of Networking and Storage Solutions
An Investigation into Convergence of Networking and Storage Solutions An Investigation into Convergence of Networking and Storage Solutions
An Investigation into Convergence of Networking and Storage Solutions
 
Adoption of SDN: Progress Update
Adoption of SDN: Progress UpdateAdoption of SDN: Progress Update
Adoption of SDN: Progress Update
 
Module1 Mobile Computing Architecture
Module1 Mobile Computing ArchitectureModule1 Mobile Computing Architecture
Module1 Mobile Computing Architecture
 
ENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKING
ENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKINGENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKING
ENHANCING AND MEASURING THE PERFORMANCE IN SOFTWARE DEFINED NETWORKING
 
Cc unit 2 ppt
Cc unit 2 pptCc unit 2 ppt
Cc unit 2 ppt
 
Sreerag what is a web service
Sreerag   what is a web serviceSreerag   what is a web service
Sreerag what is a web service
 
.Net projects 2011 by core ieeeprojects.com
.Net projects 2011 by core ieeeprojects.com .Net projects 2011 by core ieeeprojects.com
.Net projects 2011 by core ieeeprojects.com
 
Software-Defined Networking(SDN):A New Approach to Networking
Software-Defined Networking(SDN):A New Approach to NetworkingSoftware-Defined Networking(SDN):A New Approach to Networking
Software-Defined Networking(SDN):A New Approach to Networking
 
Cloud computing and Software defined networking
Cloud computing and Software defined networkingCloud computing and Software defined networking
Cloud computing and Software defined networking
 
Anuta NCX Platform Overview - Agile Network Services with Orchestration
Anuta NCX Platform Overview - Agile Network Services with OrchestrationAnuta NCX Platform Overview - Agile Network Services with Orchestration
Anuta NCX Platform Overview - Agile Network Services with Orchestration
 

More from Gerardo Pardo-Castellote

DDS, the US Navy, and the Need for Distributed Software
DDS, the US Navy,  and the Need for Distributed SoftwareDDS, the US Navy,  and the Need for Distributed Software
DDS, the US Navy, and the Need for Distributed SoftwareGerardo Pardo-Castellote
 
Introduction to DDS: Context, Information Model, Security, and Applications.
Introduction to DDS: Context, Information Model, Security, and Applications.Introduction to DDS: Context, Information Model, Security, and Applications.
Introduction to DDS: Context, Information Model, Security, and Applications.Gerardo Pardo-Castellote
 
A Converged Approach to Standards for Industrial Automation
A Converged Approach to Standards for Industrial AutomationA Converged Approach to Standards for Industrial Automation
A Converged Approach to Standards for Industrial AutomationGerardo Pardo-Castellote
 
DDS-Security Interoperability Demo - March 2018
DDS-Security Interoperability Demo - March 2018DDS-Security Interoperability Demo - March 2018
DDS-Security Interoperability Demo - March 2018Gerardo Pardo-Castellote
 
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and Simulink
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and SimulinkApplying MBSE to the Industrial IoT: Using SysML with Connext DDS and Simulink
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and SimulinkGerardo Pardo-Castellote
 
Deep Dive into the OPC UA / DDS Gateway Specification
Deep Dive into the OPC UA / DDS Gateway SpecificationDeep Dive into the OPC UA / DDS Gateway Specification
Deep Dive into the OPC UA / DDS Gateway SpecificationGerardo Pardo-Castellote
 
DDS for eXtremely Resource Constrained Environments 1.0 Beta
DDS for eXtremely Resource Constrained Environments 1.0 BetaDDS for eXtremely Resource Constrained Environments 1.0 Beta
DDS for eXtremely Resource Constrained Environments 1.0 BetaGerardo Pardo-Castellote
 
DDS-Security Interoperability Demo - December 2017
DDS-Security Interoperability Demo - December 2017DDS-Security Interoperability Demo - December 2017
DDS-Security Interoperability Demo - December 2017Gerardo Pardo-Castellote
 
DDS-Security Interoperability Demo - September 2017
DDS-Security Interoperability Demo - September 2017DDS-Security Interoperability Demo - September 2017
DDS-Security Interoperability Demo - September 2017Gerardo Pardo-Castellote
 
Extensible Types for DDS (DDS-XTYPES) version 1.2
Extensible Types for DDS (DDS-XTYPES) version 1.2Extensible Types for DDS (DDS-XTYPES) version 1.2
Extensible Types for DDS (DDS-XTYPES) version 1.2Gerardo Pardo-Castellote
 
Interface Definition Language (IDL) version 4.2
Interface Definition Language (IDL) version 4.2 Interface Definition Language (IDL) version 4.2
Interface Definition Language (IDL) version 4.2 Gerardo Pardo-Castellote
 
DDS for eXtremely Resource Constrained Environments
DDS for eXtremely Resource Constrained EnvironmentsDDS for eXtremely Resource Constrained Environments
DDS for eXtremely Resource Constrained EnvironmentsGerardo Pardo-Castellote
 
DDS-XRCE - Revised Submission Presentation (September 2017)
DDS-XRCE - Revised Submission Presentation (September 2017)DDS-XRCE - Revised Submission Presentation (September 2017)
DDS-XRCE - Revised Submission Presentation (September 2017)Gerardo Pardo-Castellote
 
DDS-XRCE (Extremely Resource Constrained Environments)
DDS-XRCE (Extremely Resource Constrained Environments)DDS-XRCE (Extremely Resource Constrained Environments)
DDS-XRCE (Extremely Resource Constrained Environments)Gerardo Pardo-Castellote
 
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)Gerardo Pardo-Castellote
 

More from Gerardo Pardo-Castellote (20)

DDS, the US Navy, and the Need for Distributed Software
DDS, the US Navy,  and the Need for Distributed SoftwareDDS, the US Navy,  and the Need for Distributed Software
DDS, the US Navy, and the Need for Distributed Software
 
Introduction to DDS: Context, Information Model, Security, and Applications.
Introduction to DDS: Context, Information Model, Security, and Applications.Introduction to DDS: Context, Information Model, Security, and Applications.
Introduction to DDS: Context, Information Model, Security, and Applications.
 
DDS-TSN OMG Request for Proposals (RFP)
DDS-TSN OMG Request for Proposals (RFP)DDS-TSN OMG Request for Proposals (RFP)
DDS-TSN OMG Request for Proposals (RFP)
 
A Converged Approach to Standards for Industrial Automation
A Converged Approach to Standards for Industrial AutomationA Converged Approach to Standards for Industrial Automation
A Converged Approach to Standards for Industrial Automation
 
Overview of the DDS-XRCE specification
Overview of the DDS-XRCE specificationOverview of the DDS-XRCE specification
Overview of the DDS-XRCE specification
 
DDS-Security Interoperability Demo - March 2018
DDS-Security Interoperability Demo - March 2018DDS-Security Interoperability Demo - March 2018
DDS-Security Interoperability Demo - March 2018
 
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and Simulink
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and SimulinkApplying MBSE to the Industrial IoT: Using SysML with Connext DDS and Simulink
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and Simulink
 
Deep Dive into the OPC UA / DDS Gateway Specification
Deep Dive into the OPC UA / DDS Gateway SpecificationDeep Dive into the OPC UA / DDS Gateway Specification
Deep Dive into the OPC UA / DDS Gateway Specification
 
OPC UA/DDS Gateway version 1.0 Beta
OPC UA/DDS Gateway version 1.0 BetaOPC UA/DDS Gateway version 1.0 Beta
OPC UA/DDS Gateway version 1.0 Beta
 
DDS for eXtremely Resource Constrained Environments 1.0 Beta
DDS for eXtremely Resource Constrained Environments 1.0 BetaDDS for eXtremely Resource Constrained Environments 1.0 Beta
DDS for eXtremely Resource Constrained Environments 1.0 Beta
 
DDS-Security Interoperability Demo - December 2017
DDS-Security Interoperability Demo - December 2017DDS-Security Interoperability Demo - December 2017
DDS-Security Interoperability Demo - December 2017
 
DDS-Security Interoperability Demo - September 2017
DDS-Security Interoperability Demo - September 2017DDS-Security Interoperability Demo - September 2017
DDS-Security Interoperability Demo - September 2017
 
Extensible Types for DDS (DDS-XTYPES) version 1.2
Extensible Types for DDS (DDS-XTYPES) version 1.2Extensible Types for DDS (DDS-XTYPES) version 1.2
Extensible Types for DDS (DDS-XTYPES) version 1.2
 
DDS-Security version 1.1
DDS-Security version 1.1DDS-Security version 1.1
DDS-Security version 1.1
 
Interface Definition Language (IDL) version 4.2
Interface Definition Language (IDL) version 4.2 Interface Definition Language (IDL) version 4.2
Interface Definition Language (IDL) version 4.2
 
DDS Security Specification version 1.0
DDS Security Specification version 1.0DDS Security Specification version 1.0
DDS Security Specification version 1.0
 
DDS for eXtremely Resource Constrained Environments
DDS for eXtremely Resource Constrained EnvironmentsDDS for eXtremely Resource Constrained Environments
DDS for eXtremely Resource Constrained Environments
 
DDS-XRCE - Revised Submission Presentation (September 2017)
DDS-XRCE - Revised Submission Presentation (September 2017)DDS-XRCE - Revised Submission Presentation (September 2017)
DDS-XRCE - Revised Submission Presentation (September 2017)
 
DDS-XRCE (Extremely Resource Constrained Environments)
DDS-XRCE (Extremely Resource Constrained Environments)DDS-XRCE (Extremely Resource Constrained Environments)
DDS-XRCE (Extremely Resource Constrained Environments)
 
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)
 

Recently uploaded

AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024Brian Pichman
 
UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4DianaGray10
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameKapil Thakar
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightSafe Software
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024Brian Pichman
 
Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Muhammad Tiham Siddiqui
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Alkin Tezuysal
 
Keep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveKeep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveIES VE
 
The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)codyslingerland1
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingFrancesco Corti
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsDianaGray10
 
How to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxHow to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxKaustubhBhavsar6
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.IPLOOK Networks
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3DianaGray10
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc
 
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfKey Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
 
Explore the UiPath Community and ways you can benefit on your journey to auto...
Explore the UiPath Community and ways you can benefit on your journey to auto...Explore the UiPath Community and ways you can benefit on your journey to auto...
Explore the UiPath Community and ways you can benefit on your journey to auto...DianaGray10
 
Technical SEO for Improved Accessibility WTS FEST
Technical SEO for Improved Accessibility  WTS FESTTechnical SEO for Improved Accessibility  WTS FEST
Technical SEO for Improved Accessibility WTS FESTBillieHyde
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationKnoldus Inc.
 
Oracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxOracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxSatishbabu Gunukula
 

Recently uploaded (20)

AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024
 
UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4UiPath Studio Web workshop series - Day 4
UiPath Studio Web workshop series - Day 4
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First Frame
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024
 
Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
 
Keep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveKeep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES Live
 
The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is going
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projects
 
How to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxHow to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptx
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
 
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfKey Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdf
 
Explore the UiPath Community and ways you can benefit on your journey to auto...
Explore the UiPath Community and ways you can benefit on your journey to auto...Explore the UiPath Community and ways you can benefit on your journey to auto...
Explore the UiPath Community and ways you can benefit on your journey to auto...
 
Technical SEO for Improved Accessibility WTS FEST
Technical SEO for Improved Accessibility  WTS FESTTechnical SEO for Improved Accessibility  WTS FEST
Technical SEO for Improved Accessibility WTS FEST
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its application
 
Oracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxOracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptx
 

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