RTI/Cisco response to the OMG Software Defined Networks (SDN) RFI
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 4,850 views

Joint RTI/Cisco response to the SDN RFI (see http://www.omg.org/cgi-bin/doc?mars/13-09-16.zip). ...

Joint RTI/Cisco response to the SDN RFI (see http://www.omg.org/cgi-bin/doc?mars/13-09-16.zip).

Summary:

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.
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 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.
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. SDN adopts some of these principals leveraging schema driven approaches and data driven models 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 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.

Statistics

Views

Total Views
4,850
Slideshare-icon Views on SlideShare
4,850
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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