SPRING-OPEN SDN Based Control of Open Segment Routers An ONF TAG Project Saurav Das Project Lead / Consultant @ ONF 

But  when  it  comes  to  Hardware  switches,     misconcep4ons  abound   •   OpenFlow  is  not  mature   •   OpenFlow  does  not  work  with  current  hardware   •   OpenFlow  does  not  scale     Motivation: ONF Point of View SDN/OpenFlow  successful     •   in  DataCenters   •   with  So@ware  Switches     •   and  Overlay  networks   

state   behavior   Interface   msg   match  Eth,  VLAN,  IP,  L4   flows   1.0   Q4  ‘09   single  message  queue   w/op4onal  barriers   ports   forward  {0,  1,  n}     1.1   Q1  ‘11   +  Mul4ple  Tables/Pipelines:   +  Group  Tables   +  forward  1-­‐in-­‐n  (ECMP)   +  match  QinQ,  MPLS,  SCTP     +  match  virtual  ports   +  extensible  match   +  extensible  ac4ons     1.2   Q4  ‘11   +  IPv6   +  mul4ple  controllers   1.3   Q2  ‘12   +  per-­‐flow  metering   +  tunnel-­‐id   OpenFlow has evolved towards production readiness. +  mul4ple  channels   (auxiliary  connec4ons)   1.4   Q4  ‘13   +  op4cal  ports   +  synchronized  tables   +  bundle  messages   

SPRING-OPEN Project Goals 1.  Demonstrate  maturity  and  scale  of  the  ONF   work  product  in  hardware  readily  available   today  using  the  latest  stable  versions  of  ONF   protocols  –  eg.  OF  1.3.4.     2.  Provide  feedback  to  ONF  WGs  on  their  work   product  from  an  implementa4on  of  the  chosen   networking  scenario.   3.  Promote  adop4on  by  crea4ng  a  core-­‐kernel  that   is  extensible  for  value-­‐add  towards  deployment,   interoperability  and  differen4a4on.     

SDN Based Control of Open Segment Routers OpenFlow  1.3   Rou4ng,   Recovery,   Label  imposi4on   Requests   SR  Labels   imposed  by   controller   OSR  FIB  built  by   controller   Requests   Open   Segment   Routers   (OSR)   

Why Segment Routing 1.     Eliminates  label  distribu4on  protocols  –  LDP  and  RSVP-­‐TE   2.     Source  rou4ng  via  ‘segments’  –  maps  to  labels  in  MPLS   3.     Introduces  globally  significant  labels  –  simpler,  easier  to  debug   Segment  Rou4ng  (SR)  or  SPRING  (IETF  name)   –  Source  Packet  Rou4ng  In  NetworkinG   Think  of  Segment  Rou4ng  as  a  beher  MPLS  network   with  no  change  to  the  MPLS  data  plane.   

ON.Lab Involvement SPRING-OPEN IPv4 unicast routing using MPLS labels, following Segment Routing rules ONOS Existing Hardware Switches A platform for multiple switch types: Software Switches Newer Hardware Switches Optical Switches A platform for multiple services: Multi-layer packet-optical integration NFV BGP 

Dell Involvement Dell Networking S4810-ON Open Networking Switch Ingress   Port     Incoming   Packet   VLAN   Flow   Table     Termina4on   MAC  Flow   Table       Unicast   IPv4   Rou4ng   Flow   Table       z   MPLS   Forwarding   Flow  Table       ACL   Policy   Flow   Table       Apply   Ac4ons   -­‐push/pop   -­‐TTL  mpls   -­‐Set   -­‐Output   -­‐Group   Outgoing   Packet   z   Group  Table  Entries:   L3  Unicast   MPLS  Unicast   ECMP   Pkt.  +   Meta-­‐   Data  +   Ac4on   Set  {}   Egress   Port     or   Group   SPRING-­‐OPEN     Hardware  Abstrac4on   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 192.168.0.7 107 h3 h4 10.200.3.0/24 10.200.4.0/24 Prototype     &  Demo   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 192.168.0.7 107 h3 h4 10.200.3.0/24 10.200.4.0/24 106   106   106   106   no  label   no  label   Global  Labels   ECMP  &  PHP   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 192.168.0.7 107 h3 h4 10.200.3.0/24 10.200.4.0/24 106   106   no  label   Data  Plane   Recovery   with  Consistent     Loop  Free  Updates   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 h3 h4 10.200.3.0/24 10.200.4.0/24 105   106   106   no  label   Source  Routed   Loose-­‐hop  Tunnels  &   Priori4zed  Policies   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 h3 h4 10.200.3.0/24 10.200.4.0/24 Adjacency   Segment  103005   103005   106   103   103005   106   106   no  label   Strict-­‐hop  Tunnels  &   Fine-­‐grained  Traffic   Steering   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 h3 h4 10.200.3.0/24 10.200.4.0/24 Adjacency  Segment   77777   88888   88888   106   106   106   106   no  label   Load  balancing  on     Non-­‐ECMP  paths   

h1 h2 10.200.2.0/24 10.200.1.0/24 101 192.168.0.1 192.168.0.2 102 103 192.168.0.3 192.168.0.5 105 104 192.168.0.4 106 192.168.0.6 192.168.0.8 108 192.168.0.7 107 h3 h4 10.200.3.0/24 10.200.4.0/24 102   103   104   103   104   104   106   no  label   no  label   S4tch   Point   Segment   S4tching   

All features implemented using ONOS on hardware switches from Dell Learn more: https://wiki.onosproject.org/display/ONOS/Segment+Routing SPRING-OPEN 

INVITATION Learn more: https://wiki.onosproject.org/display/ONOS/Segment+Routing SPRING-OPEN Segment Routing Prototype In Your Lab 

Backup 

Summary of Features 1.  Default  Segment  Rou4ng  with  MPLS  (node-­‐segments)  ,   ECMP,  PHP  and  OpenFlow  1.3  (mul4-­‐tables  &  groups)   2.  ARP/ICMP  handling,  subnet-­‐configura4on,  pinging   router-­‐IPs  (normal  router  behavior)     3.  Link  and  Switch  failure  recovery  (taking  ECMP  into   account)   4.  Crea4ng  an  SR  tunnel  with  loose  and  strict  hops   5.  Crea4ng  policies  (priori4zed)  and  assigning  them  to  SR   tunnels.   

Summary of Features 6.  Segment  s4tching  (where  tunnel  requires  pushing   more  than  3  labels,  and  so  we  s4tch-­‐segments  of  the   tunnel  to  get  around  hardware  limita4ons)   7.  Use  of  Adjacency  Segments   •  For  selec4ng  one  of  many  ports  (fine-­‐grained   traffic  steering)   •  For  hashing  across  mul4ple  ports  (enabling  load-­‐ balancing  across  mul4ple  non-­‐ECMP  paths)   8.  Consistent  loop-­‐free  updates  using  des4na4on   rooted  in-­‐trees   

Non  -­‐  Goals   1.  Not  crea4ng  GA  product;  no  QA;  will  not  be  ready   for  produc4on  nor  interoperate  with  other   networks  and  network  control  planes.  Will  support   some  elements  helpful  for  produc4za4on  (eg.   config,  troubleshoo4ng/OAM,  visibility  etc.)   2.  Not  delivering  a  specific  service  like  Bandwidth-­‐ TE  /VPN/NFV.  Instead  suppor4ng  core-­‐capabili4es   to  build  such  services  on  top  (extensibility  op4ons)   3.  Not  a  plugfest  –  data  and  control  plane  choices  will   be  made;  however  choices  should  be  replaceable   by  other  parts,  both  commercial  and  open-­‐source   as  long  as  they  conform  to  the  requirements   

master mid-May onos13 1st June 1st July 8th August 1st Sept 1st Nov 5th Dec onos13integration -- Unit tests -- Manual Integration -- OF 1.3 support -- Driver Manager -- I/O State Machine -- Role management -- Debug framework 25 26 27 -- Prototyping -- CPqD13 -- OVS13 -- Dell13 -- Network Config Manager onos-spring Segment Routing Application -- Driver, TTP , Features -- CPqD software switches cli dell Project Timeline Integration -- Dell hardware switches Working Hardware Prototype All code open-sourced 17th Nov