• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
RTI/Cisco response to the Software Defined Networks (SDN) OMG RFI
 

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

on

  • 3,877 views

Presentation given to the OMG Software Defined Networking (SDN) SIG at the December 2013 meeting. This presentation describes the response to the SDN RFI jointly written by RTI and Cisco. The full ...

Presentation given to the OMG Software Defined Networking (SDN) SIG at the December 2013 meeting. This presentation describes the response to the SDN RFI jointly written by RTI and Cisco. The full RFI response is available at:
http://www.omg.org/cgi-bin/doc?mars/13-11-27.pdf
The original RFI document is available at:
http://www.omg.org/cgi-bin/doc?mars/13-09-16.zip

Statistics

Views

Total Views
3,877
Views on SlideShare
3,872
Embed Views
5

Actions

Likes
1
Downloads
17
Comments
0

1 Embed 5

http://community.rti.com 5

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 Software Defined Networks (SDN) OMG RFI RTI/Cisco response to the Software Defined Networks (SDN) OMG RFI Presentation Transcript

    • OMG    So'ware  Defined  Networks  (SDN)       RFI    Response    from    RTI    and    Cisco   December  2013   mars/2013-­‐12-­‐14   Gerardo  Pardo-­‐Castellote,  Ph.D.      (RTI,  gerardo  AT  rO  DOT  com)   hPp://www.rO.com,  hPp://community.rO.com     Gary  Berger  (Cisco,  gaberger  AT  cisco  DOT  com   hPp://www.cisco.com    
    • SDN  programming  requirements   FuncOonal:   •  Query  network  (network  components)  state   •  Define  forwarding  policies   •  Update  forwarding  policies   Non-­‐FuncOonal:   •  Simple,  High-­‐Level  interface   •  Scalability   •  Distributed  consistency   •  Management  of  heterogeneous  devices   •  Management  of  mulOple  protocols  (OpenFlow,  OF-­‐CONFIG,   PCEP,  I2RS,  OVSDB,  OnePK,  …)   12/29/13   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   2  
    • Response  main  points   See: http://www.omg.org/cgi-bin/doc?mars/13-11-27.pdf •  Focus  on  standardizing  the  InformaOon  Model   that  represents  the  Observable  and   Controllable  state  of  SDN  Network  Elements   •  Use  MDA  to  define  an  SDN  model  of  the   informaOon,  interacOons,  services,  and  APIs   •  Map  MDA  model  to  exisOng  middleware   technologies  (DDS,  XMPP,  AMQP,  REST/HTTP)     to  create  specific  ways  to  observe/control/ configure  SDN  elements   12/29/13   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   3  
    • ObservaOons/MoOvaOon   •  A  single/common  middleware  plaform  is  unlikely  to   succeed  due  to  exisOng  investments,  vendor  preferences   and  need  to  interoperate  with  deployed  systems   –  IntegraOon  of  all  these  approaches  around  a  common  MDA   informaOon  model  is  the  next-­‐best  approach   •  Leveraging  exisOng  middleware  plaforms  automaOcally   bring  standard  APIs,  data-­‐representaOons,  protocols,   discovery  and  proven  scalability,  robustness.   –  Effort  can  be  directed  towards  high-­‐level  abstracOons,   composiOon,  segmentaOon  of  controller  logic,  etc.   •  A  common  SDN  InformaOon  model  can  be  the  foundaOon   for  bridging  exiOng  protocols  and  remain  open  to  support   new  ones  in  the  future   12/29/13   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   4  
    • Steps  to  MDA  SDN  InformaOon  Model   1.  Use  UML  to  define  data-­‐centric  informaOon  model   for  SDN   –  Data-­‐Centric  Model  makes  not  assumpOon  about  protocols,   interacOons  or  APIs.  Models  simply  the  observable  and  controllable   state   2.  Map  the  InformaOon  Model  to  exisOng   technologies:   –  –  Standards:    SNMP,  OpenFlow     Vendor  technologies:  Cisco  OnePK,  Juniper  Contrail,  VmWare  NSX   3.  Maps  InformaOon  Model  to  exisOng  middleware   plaforms:     –  DDS,  XMPP,  AMQP,  REST   ©  2013  RTI  •  CISCO  •  ALL  RIGHTS  RESERVED   5  
    • Some  benefits  of  leveraging  standard   middleware  technologies   •  Many  things  come  for  free.  E.g.  in  DDS:   –  Discovery     –  Asynchronous  noOficaOon  (events/traps/signals)   –  Content  based  Filtering  at  the  source   –  Scalability   –  Reliability  in  the  presence  of  failures/disconnects   –   Qos,  PrioriOzaOon   –  History  and  Durability/Persistence     –  Etc.   ©  2013  RTI  •  CISCO  •  ALL  RIGHTS  RESERVED   6  
    • RFI  QuesOons:   1.  SDN  Maintain  open,  vendor  neutral…     •  Standard  InformaOon  Model  defined  using   MDS  is  available  to  all  and  maintained  by  an   standards  body  open  to  all   •  Mapping  of  the  InformaOon  Model  to  standard   middleware  plaforms  also  done  and   maintained  by  standard  body  such  as  the   OMG.   –  New  mappings  can  be  developed  for  new   standards  and  also  contributed  by  vendors  to   match  their  own  plaforms   ©  2013  RTI  •  CISCO  •  ALL  RIGHTS  RESERVED   7  
    • Many  things  come  “for  free”   2.  support  for  network  related  enOty  discovery,  connecOon,  …   3.  Support  interoperability  of  network  control  and   operaOonal  data…     4.  Support  for  mulOple  programming  languages…     5.  What    architectural  paPerns  could  miOgate  the  Controller  choke  point  problem?     8.  How  are  SDN  ecosystem  events  from  …      handled?     10.  How  does  the  SDN  ecosystem  support  federated  data  centers?     11.  How  to  handle  (DIL)    environments?     These  are  all  already  provided  by  each  middleware  plaform  so  it   comes  “for  free”   ©  2013  RTI  •  CISCO  •  ALL  RIGHTS  RESERVED   8  
    • 6.  Support  of  exisOng  network  standards   9.  Interoperate  with  legacy  network  architectures   •  Each  standard/architecture  should  be  mapped   to  the  common  SDN  InformaOon  Model   •  Standard  Bridges/Gateways  can  be  developed   between  different  standards  as  they  are  all   mapped  to  the  same  InformaOon  Model   ©  2013  RTI  •  CISCO  •  ALL  RIGHTS  RESERVED   9  
    • 7.  RelaOonship  to  exisOng  SDN  efforts   •  OMG  should  focus  on  its  areas  of  core   experOse:   –  Use  of  UML  to  define  a  MDA  Common  InformaOon   Model  for  SDN   –  Mapping  to  Middleware  technologies:  DDS,  REST,   XMPP   ©  2013  RTI  •  CISCO  •  ALL  RIGHTS  RESERVED   10  
    • Discussion