Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cardinal Release- ONOS Use Cases Planning Session

Cardinal Release- ONOS Use Cases Planning Session

ONOS Use Case planning session for Cardinal Release

ONOS Project

January 26, 2015
Tweet

More Decks by ONOS Project

Other Decks in Technology

Transcript

  1. ONOS  USE  CASES  PLANNING  SESSION   (Cardinal  Release)   JAN

     26TH,  2015     Details at : https://wiki.onosproject.org/display/ONOS/May+2015-+Use+Case+Release+Planning+Session
  2. Blackbird  release   Cardinal  Release   August  Release   November

     release   Nov   Sep   Aug   Jul   Jun   May   Mar   Feb   Jan’15   Dec’14   Apr   Oct   •  Target  for  use  cases  –Cardinal  release  (May  2015)   •  But  work  for  use  cases  is  already  in  progress.  Some  parts  get  into  master  in  Blackbird  and   majority  in  Cardinal.     ONOS  Use  Cases  Planning  Session:  Timelines  
  3. 1 2 3 Goals  of  Use  Case  Planning  Session  

    •  Sync  up  on  the  current  status  and  the   priori[zed  list  of  to-­‐do  items  for  each  use   case  (targeted  for  Cardinal  Release)   •  Introduce  the  Use  Cases  Steering  team   •  Tom  Anschutz,  AT&T   •  Yoichi  Sato,  NTT   •  Introduce  team  leads  for  each  use  case.   •  Iden[fy  concrete  ways  in  which  the  ONOS   community  can  par[cipate  and  collaborate   on  ONOS  use  cases.   COMMUNITY   PLANNING   STEERING  TEAM  
  4. Use  Cases  Steering  Team  Intro   – Tom  Anschutz,  AT&T  

    – Yoichi  Sato,  NTT   (  Please  view  video)  
  5. ONOS  USE  CASES  –  PART  1   BLACKBIRD/CARDINAL  RELEASE  

    USE  CASE  PLANNING  SESSION-­‐  JAN  26TH,  2015    
  6. Use  Case  1-­‐  Mul[layer  SDN   Control  for  IP+Op[cal  

    Marc  De  Leenheer,  ON.Lab   Tom  Tofigh,  AT&T    
  7. Status  and  Goals   ¡  ONOS  to  handle  converged  control

     of  forwarding,  configura[on  and   monitoring  in  mul[-­‐layer  networks   ¡  Scale  out,  HA,  and  high  performance   ¡  Current  status   ¡  Demonstrated  converged  L0  and  L3  bandwidth  provisioning  and  restora[on   ¡  Running  on  emulated  network  (LINC-­‐OE,  OVS,  and  Mininet)   ¡  Southbound  fully  based  on  OpenFlow   ¡  Missing  features   ¡  No  real  hardware   ¡  No  real  scale  
  8. Epics   ¡  Epic  1:  Proof  of  Concept   ¡ 

    Mul[-­‐vendor,  mul[-­‐layer  (L0  &  L3)  hardware  testbed   ¡  ROADMs  by  Ciena  &  Fujitsu,  TL1  southbound   ¡  Packet  switches  by  Corsa,  OF1.3  southbound   ¡  Demonstrate  bandwidth  provisioning  and  restora[on     ¡  Epic  2:  Scalable,  open  source  reference  pladorm  for  mul[-­‐layer  networks   ¡  Soeware  environment  to  prototype,  evaluate,  and  validate   ¡  Scale  &  HA  for  packet/op[cal  app   ¡  Enhanced  integra[on  of  LINC-­‐OE  in  Mininet   ¡  Dynamic  network  elements  (ROADM,  ports,  links)  
  9. Areas  of  Community  Par[cipa[on   ¡  Epic  1   ¡ 

    External  PCE   ¡  External  service  for  ONOS’  intent  compiler  and  resource  manager   ¡  PCE  protocol   ¡  Enhanced  network  resiliency   ¡  1+1,  1:1,  1:N  considering  Shared  Risk  Groups   ¡  Automa[c  Protec[on  Switching   ¡  Epic  2   ¡  Neighbor  discovery   ¡  Based  on  ONF  Op[cal  Transport  WG:  OpenFlow  1.3  extensions   ¡  OTN  Layer   ¡  Physical  Impairments   ¡  Model  in  LINC,  observability  in  ONOS  
  10. Related  Informa[on   Person Organization Email Marc De Leenheer ON.Lab

    [email protected] Tom Tofigh AT&T [email protected] Location Notes Link Wiki Docs, tutorial, videos https://wiki.onosproject.org/display/ ONOS/Packet+Optical Google Drive Slides for planning, design https://drive.google.com/drive/u/0/ #folders/ 0B1ROTy2_BxgKV3V2TDRCSzBmQU0 Jira Issue tracking, spring planning https://jira.onosproject.org/secure/ RapidBoard.jspa? rapidView=1&view=planning&select
  11. Use  Case  2:  SDN-­‐IP  /  Deployment-­‐  1:  Internet2    

    Connec[ng  Internet2  islands  through  SDN   Pingping  Lin,  Luca  Prete,  Pavlin  Radoslavov     For  more  info,  please  write  to  [email protected]  
  12. Use-­‐case  overview     Goal •  Connect external (legacy) networks

    through SDN •  Provide L3 functionalities using OF switches Features •  6 universities distributed around the country will communicate together through SDN •  The SDN will act as a transit network •  SDN-IP: the SDN and the external networks will exchange routes through BGP •  SDN benefits + ONOS added values •  43 switches of different vendors
  13. SDN-­‐IP      What  is  it?     •   SDN-­‐IP

     is  an  applica[on  running  on  top  of  ONOS            Features   •   It  allows  your  SDN  to  scale  and  connect  to  the  rest  of  the  Internet     •   You  can  migrate  your  exis[ng  network  to  SDN  incrementally     •   You  can  scale  your  SDN  control  plane        Technology   •   It  exchanges  routes  peering  with  external  edge  routers  (BGP  –  vendor  independent)     •   HA  func[onali[es  (both  in  data  plane  and  control  plane)          
  14. I2  actual  progress   Today •  The code seems “quite”

    stable, even if it’s always the first ONOS release •  Integration automatic tests missed, but in progress •  Collaboration with I2: SDN-IP (almost) deployed in the Internet2 testlab •  Issues with a vendor not supporting dst_mac re-write (blocking) To be done •  Understand the feasibility of the deployment •  Internet2 would validate the platform before moving to the “official” deployment •  Involving interested universities. Deployment on AL2S with I2 support •  Performances improvements not needed for the specific deployment
  15. TBD:  Epics  and  stories  (Internet2)   Internet2 - ONOS-493 • 

    Finish the deployment in the Internet2 testlab - ONOS-494 o  More discussions on the feasibility of the deployment o  Validation of the solution and discussion with I2 •  Deploy on Internet2 AL2S - ONOS-495 o  Re-build with the Internet2 staff the production testbed o  Involve interested universities and support them along the deployment
  16. SDN-­‐IP  new  func[ons  (scheduled  by  May)   Here is where

    we would appreciate the help of the community! •  Performances tests and improvements (up to 600,000 routes) - ONOS-62 •  Understand the network modeling and configuration refactoring - ONOS-642/65 •  Security: explicit BGP configuration for SDN-IP - ONOS-2 •  Finish the integration with IPv6 (only tests needed) - ONOS-646 •  Disable LinkDiscovery on the access ports - ONOS-429 •  Cancel host monitoring in SDN-IP when it not longer has routes to the next hop – ONOS-424 •  Use intent replace operation instead of withdraw and submit - ONOS-430
  17. OpenFlow   Rou[ng,   Recovery,   Label  imposi[on   Requests

      SR  Labels   imposed  by   controller   OSR  FIB  built  by   controller   Rou[ng   Service   Requests   ONOS   Discovery   Service   Open   Segment   Routers   (OSR)   Forwarding   Service   Open   Segment   Routers   (OSR)   USE  CASE  OVERVIEW  
  18. GOALS   •  Current  Status   •  Segment  Rou[ng  was

     demonstrated  on  a  development  version  of  ONOS  as  part  of   Dec  2014  Open  source  release   •  Dell  4810  Open  Networking  switches   •  hlps://wiki.onosproject.org/display/ONOS/Segment+Rou[ng     •  ONOS-­‐Cardinal  Release  Goals   •  Change  parts  of  official  ONOS  to  accommodate  SR  and  other  apps  that  need  OF1.3   features  -­‐-­‐  eg.  pipeline  support  in  drivers,  flow-­‐rule  subsystem   •  Introduce  new  features  in  official  ONOS  to  accommodate  SR  and  other  apps  that  need   such  capabili[es  -­‐-­‐  eg.  group-­‐subsystem  &  network-­‐config-­‐manager   •  Port  SR  applica[on  onto  official  version  of  ONOS   •  Con[nue  suppor[ng  Dell  4810  switches   •  ONS  demo  in  June  2015      
  19. STORIES   •  High  level  work  items  for  Segment  Rou[ng

     use  case  in  Cardinal  Release   •  Mul[ple  table  support  for  Flow  Rule  subsystem  (ONOS-­‐682)   •  New  Group  subsystem  (ONOS-­‐679)   •  Network  configura[on  management  framework  (ONOS-­‐685)   •  Segment  Rou[ng  Applica[on     •  Default  Rou[ng  Handling  and  Recovery  (ONOS-­‐686,  687)   •  Default  Group  Handling  and  Recovery   •  Policy  Rou[ng  support  (ONOS-­‐688,  689,  690)   •  Policy  Group  Handling  and  Recovery   •  CLI  (ONOS-­‐691)   •  GUI  (ONOS-­‐692)  
  20. COMMUNITY  CONTRIBUTION   •  Community  Contribu[on/Help   •  Policy  

    -­‐  Segment   Rou[ng   allows   the   crea[on   of   policies   that   fall   into   several   categories:   tunnel-­‐flow,   load-­‐balance,   avoid,   deny   etc.   Help   us   make   these   policies   beler/stronger   and   more   feature-­‐full   (eg.   add   protec[on),   or   implement  a  new  policy!!   •  CLI   -­‐  SR  applica[on  currently  uses  a  CLI  from  a  different  project.  We  can  use  help  to   inves[gate   the   integra[on   of   that   CLI   with   ONOS-­‐Cardinal.   We   can   also   use   help  to  explore  possible  changes  to  the  Karaf  CLI   •  GUI   -­‐  We  need  help  to  figure  out  how  to  expose  SR  features  on  the  GUI                                    
  21. CONTACTS  &  RESOURCES   •  Contacts   •  Sangho  Shin

     ([email protected])   •  Srikanth  Vavilapalli  ([email protected])   •  Saurav  Das  ([email protected])       •  Resources   •  Segment  Rou[ng  in  December  Release:   hlps://wiki.onosproject.org/display/ONOS/Segment+Rou[ng   •  ONOS  1.2  Segment  Rou[ng  Design:   hlps://wiki.onosproject.org/display/ONOS/Segment+Rou[ng+for+ONOS+1.2     •  ONOS  1.2  Segment  Rou[ng  JIRA  stories:  hlps://jira.onosproject.org        
  22. Use  Case  4   Central  Office  Re-­‐architected     as

     a  Datacenter  (CORD)* Larry  Peterson     *(Reframing of NFaaS)
  23. OLT   Packet  SW  +  ROADM   Centralized  Control  &

     Management  Plane   29   Central  Office  as  a  Datacenter   Enterprise Customers VPN            WanEx            DSA            IDS     Residential Customers BNG            CDN            CG-­‐NAT          Firewall   Mobile Customers PGW          XCODE            NLA            CDN             Commodity  Servers,  Switches  and  Storage  
  24. •  Three  Independently  Developed  Technologies   –  Cloud  –  Scale

     applica[ons   –  SDN  –  Programmable  control  plane   –  NFV  –  Programmable  data  plane   •  Bring  all  Three  Together  in  the  Central  Office   –  Leverage  cloud  technology  to  reduce  CAPEX/OPEX   •  e.g.,  virtual  machines,  virtual  networks,  elas[c  scaling   –  Offer  local  value-­‐add  to  global  cloud  services   •  e.g.,  CDN,  Object  Store,  NoSQL  DB,  Data  Analy[cs   –  Offer  control  plane  based  services   •  e.g.,  VPN,  Traffic  Engineering,  Firewall,  Load  Balancing   –  Offer  data  plane  based  services   •  e.g.,  BNG,  Web  Access  Control,  CG-­‐NAT,  WAN  Accelera[on   Opportunity  /  Challenge  
  25. Centralized  Control  and  Management  Plane   XOS  (Services)  +  OVX

     (Virtual  Networks)  +  ONOS  (Network  ApplicaOons)     BNG   BNG   vSW   BNG   BNG   vSW   BNG   BNG   vSW   BNG   vSW   L2  ConnecOvity   IDS   WAN-­‐ Accel   Cache   Cache   Cache   vSW   vSW   L2VPN/L3VPN/   L3  ConnecOvity   EtherSW+  ROADM   NFV  chaining   Central  Office  as  a  Datacenter   Commodity  Servers  &  Storage   Service  Chaining   ONOS   ONOS   ONOS  
  26. OS   Virtual  Net   (e.g.,  Big  Switch)   Service

     “S”  deployed   on  a  scalable  set  of  VMs   S   BNG   Access   Subscriber   …   Subscriber   AUTH   RR   HPC   Internet   Wide-­‐Area  Acquisi[on   Net  running  on  ONOS   Demonstra[on  Services   URL   Filter   SDN-­‐IP  running  as   an  ONOS  applica[on   (enterprise  VPN  in   a  similar  manner)   Caching  Hierarchy   running  on  ONOS   Scales  on  private   OVX-­‐based  VN   Explicit  OVX-­‐based   VN  interconnec[on  
  27. Demonstra[on  Hardware   Management   Network   OpenFlow  capable  

    External  Network   Cisco  3560   IBM  G8264   14  x  Cisco  220  M3   (16  cores  /  128GB  RAM)  
  28. Technical  Summary   •  Services  managed  as  a  first-­‐class  abstrac[on

      –  XOS  provisions  each  service  as  a  scalable  set  of  VMs   –  OVX  provides  per-­‐service  VNs  for  scaling   –  ONOS  applica[ons  are  a  source  of  services   •  XOS  supports  arbitrary  service  composi[on   –  Expressed  in  terms  of  high-­‐level  specifica[on   –  Implies  isola[on  (security  policy)   •  OVX  manages  VNs  according  to  2  orthogonal  policies   –  Topology  of  the  VNs  associated  with  each  service   –  VN  interconnec[on  in  support  of  service  composi[on   •  XOS  manages  VM  placement  according  to  2  policies   –  Service-­‐specific:  to  meet  global  demands   –  Site-­‐specific:  to  op[mally  u[lize  Central  Office  resources  
  29. ONOS  USE  CASES  –  PART  2   CARDINAL  RELEASE  

      USE  CASE  PLANNING  SESSION-­‐  JAN  26TH,  2015    
  30. SLIDE  1  -­‐  Status   ¡  DREAMER  in  one  sentence:

      ¡  Design  and  implement  an  east-­‐west  applica[on  for  ONOS  clusters  (each  one  made  by   mul[ple  ONOS  instances),  allowing  a  single  ISP  to  manage  a  geographically  distribute   control  plane.   ¡  Current  status:   ¡  ICONA  (Inter  Cluster  Onos  Network  App)  design  done.     ¡  Topology  discovery  done  (modifica[on  to  the  LLDP  discovery  to  include  cluster  id).   ¡  Messaging  system  between  clusters,  based  on  mul[cast  Hazelcast  done.   ¡  Currently  implemen[ng  MPLS-­‐based  tunnels  between  clusters.   ¡  Missing  features  (May  release  goals):   ¡  Finalize  the  tunneling  mechanism   ¡  Implement  the  recovery  mechanism  to  manage  data-­‐plane  failures  
  31. SLIDE  2  -­‐  Epics   ¡  Epic  1:  Tunneling  mechanism

      ¡  Descrip[on:  Michele  extended  the  ONOS  Intent  framework,  adding  the  MPLS  intent  (currently  under   review  -­‐  hlps://jira.onosproject.org/browse/ONOS-­‐631  ).  Leveraging  on  this  new  Intent,  we  are  currently   sexng  up  the  mul[  cluster  tunneling  mechanism.   ¡  Stories:   ¡  Implement  the  distributed  mechanism  to  install/update/remove  pseudo-­‐wires  (e.g.  tunnels)  crossing   mul[ple  clusters.   ¡  Test  the  features  in  real  environments,  such  as  OFELIA  and  GEANT  testbeds.   ¡  Epic  2:  Recovery  mechanism  to  manage  data-­‐plane  failures   ¡  Descrip[on:  we  already  leverage  on  ONOS  to  automa[cally  redirect  traffic  inside  a  single  cluster.  With   ICONA,  we  need  to  take  care  of  the  inter-­‐clusters  links  and  switches.  To  minimize  the  down[me,  we  have   designed  a  solu[on  that  preinstall  some  backup  paths.  (more  details  if  required…)   ¡  Stories:   ¡  Implement  a  two-­‐stack  MPLS  Intent  (ICONA  only,  not  ONOS).   ¡  Implement  the  failure  detec[on  and  recovery  in  ICONA.   ¡  Test  the  solu[on  both  with  Mininet  and  real  testbeds.    
  32. Areas  for  Community  par[cipa[on   ¡  Epic  2:   ¡ 

    Helping  in  the  design  and  implementa[on  of  the  data  plane  recovery  mechanism.   ¡  Epic  1:   ¡  Improving  the  MPLS  Intent  designing  and  implemen[ng  a  general  purpose  intent   with  mul[ple  tags  (e.g.  VLAN,  MPLS,  GRE,  …)   ¡  Tes[ng  of  ICONA.    
  33. SLIDE  4  -­‐  Contacts   ¡  Maleo  Gerola   ¡ 

    [email protected]   ¡  maleo.gerola@create-­‐net.org   ¡  Michele  Santuari  (developer)   ¡  michele.santuari@create-­‐net.org   ¡  Documenta[on  is  available  offline  (European  project),  just  ask  and  I’ll  send   to  you   ¡  Some  slides  are  available  in  the  ONOS  Google  drive  
  34. Goals   ¡  Deploy  ONOS  in  a  small  network  running

     produc[on  traffic   ¡  We  have  a  deployment  opportunity  set  up  for  March,  to  be  presented  at  a   conference  on  March  24/25   ¡  This  deployment  is  to  take  one  Corsa  switch  and  turn  it  into  a  BGP-­‐speaking   IP  router   ¡  Corsa  switch  has  a  OF1.3  mul[-­‐table  pipeline  that  ONOS  needs  to  work  with  
  35. Stories   ¡  Write  a  Corsa  switch  driver  that  implements

     the  specific  pipeline   ¡  Needs  to  set  up  sta[c  flows  in  correct  tables  on  switch  join   ¡  Needs  to  place  dynamic  flows  in  the  correct  table   ¡  Introduce  no[on  of  group  in  the  flow  API  alongside  selectors  and  treatments   ¡  Modify  SDN-­‐IP  to  set  up  a  new  group  when  a  new  next  hop  is  resolved   ¡  Introduce  abstract  table  no[on  in  flow  API   ¡  Extend  flow{mod,entry}  builders  for  groups  and  mul[ple  tables   ¡  Allow  BGP  packet  tunnelling  through  OpenFlow  pk[n/pktout   ¡  Extend  IP  edge  configura[on  to  support  VLANs   ¡  proxyarp  needs  to  take  VLANs  into  account   ¡  Set  up  an  automated  integra[on  testbed  for  this  specific  deployment   ¡  Test  &  Debug  on  the  Corsa  switch  
  36. Yuta  HIGUCHI  (NEC)     Toru  FURUSAWA  (NTT  Communica[ons)  

    Naoki  SHIOTA  (NEC)   Use  Case  6  :  NTT  Communica[ons/NEC   Mul[-­‐domain,  Mul[-­‐layer  and  Mul[-­‐vender   WAN  use  case  (N2M3  use  case)  
  37. Background We’ve  been  developing  SDN  Framework:  ODENOS,      which

     provides  hierarchical  network  abstrac[on  model,      to  enable  easily  extensible  &  customizable  SDN  deployment   Applica[on  A 48   Packet  Transport  Network PTN   This  research  is  executed  under  a  part  of  a   “Research  and  Development  of  Network   Virtualiza[on  Technology”  program   commissioned  by  the  Ministry  of  Internal   Affairs  and  Communica[ons.
  38. Example:  L3  rou[ng  on  mul[-­‐domain  network   Hierarchical network abstraction

    model PTN  Driver� L3  rou[ng� LinkLayerizer� WDM  Driver� Aggregator� 49  
  39. Short term goal toward ONS 2015 mul[-­‐domain,  mul[-­‐layer  and  mul[-­‐vender

     WAN  use  case   using  ODENOS  and  ONOS   ONOS ODENOS L0  Topo LinkLayerizer L2  Topo (Layerized)   L2  Topo WDM  Network Packet  Transport  Network OpenFlow  Network ü  Makes  best  use  of  ODENOS  network  abstracOon  feature  into  ONOS     ü  Models  pracOcal  telecom  carriers’  and  service  providers’  network  systems   50  
  40. Long term goal ONOS ODENOS Toward  ONS2015  [meframe   Post

     ONS2015   L2  Topo LinkLayerizer L0  Topo (Layerized )   L2  Topo ONOS abstrac[on  model Enable  applica[on  developers  to  u[lize   hierarchical  network  abstrac[on  model  on  ONOS   L2   To po LinkLa yerize r L0   To po (La yer ize d)   L2   To po 51  
  41. Planned Schedule ONS  2015   June   Ø  N2  team

     (NTT  Communica[ons  and  NEC)     integrates  ONOS  and  ODENOS  to  provide   network  abstrac[on  features  into  ONOS.   Ø  Tes[ng  its  feasibili[es  and  effec[veness     Open  the  project  to  discuss  how  to  bring  in     the  key  essence  of  ODENOS  network  abstrac[on   into  ONOS   We’re  looking  forward  to   collaborate  with  ON.lab  and    ONOS  community   52   Today   26th  Jan  
  42. Use-Case Overview Use  Case   IP  Mul[cast  in  a  hybrid

     network  (SDN  &  Legacy)       ConfiguraOon  Support   Following  configura[ons  should  be  possible  for  Mul[cast  with  legacy  devices  at   the  core   •  Mul[cast  source  behind  SDN  network,  Receivers  behind  legacy  network   •  Source  behind  legacy  network,  Receivers  behind  SDN  network   •  Both  sources  and  receivers  behind  SDN  networks    
  43. Multicast Flow Configuration Legacy  Core  Network  (MulOcast  Flow)   Sender

     2   Receiver  1   Sender  1   SDN  Controller   Receiver  2   OF  Switch   Legacy  Router   IP  MulOcast  
  44. Goals May  Release   •  Support  for  Mul[cast  including  PIM-­‐SSM

     &  IGMP     •  Controller  capabili[es  to  receive  and  interpret  IGMP  join  requests  from  the   receivers  (receivers  behind  SDN  network)   •  Controller   capabili[es   to   install   mul[cast   flows   depending   on   ac[ve   join   requests  by  the  receivers  (source  behind  SDN  switch)  
  45. Community Contribution •  Design  for  IP  mul[cast  support  in  ONOS

      •  Implementa[on     •  Tes[ng,  troubleshoo[ng  and  deployment  
  46. Current Status 1.  Focus on PoC of L3VPN service, demoed

    on ONOS summit 2014 2.  Current Status q  Huawei SNC(in-house controller) integration solution (NB/SB Agent) q  PCE is implemented in App q  Service Data Model (e.g. L3VPN, LB) q  NB Flow Rule API Extension (Ready for Code Review) q  SB Provider for Huawei Devices
  47. Goal & Stories May Release •  Team up with community

    and ON.LAB ONOS team on the following Stories q  Service Data Installation (FlowRule Service Extension) q  MPLS Label Service/Management (New) q  Broadcast Network Topology Support (Topology Manager Enhancement) q  Packet In/Out Service q  MPLS Tunnel Priority  
  48. Community Contribution q  MPLS Label Service/Management (New) q  Broadcast Network

    Topology Support (Topology Manager Enhancement) q  Packet In/Out Service q  MPLS Tunnel
  49. •  PCEP-­‐based  SDN  control  for  IP+Op[cal  (evolu[onal  approach  for  service

     providers)   •  NB:  external  ML-­‐PCE  leverages  global  topology  provided  by  ONOS  for  E2E  op[mized  TE-­‐LSP   computa[on  by  considering  rich  policies   •  Core:  integra[ng  ONOS  distributed  core  for  HA,  global  database  (e.g,  to  accommodate  TEDB/LSPDB)   •  SB:    using  the  PCEP/IGP  protocols  for  mul[-­‐layer  topology  auto-­‐discovery  to  support  commercial  IP/ Op[cal  NEs   •  Current  Status   ü  External  ML-­‐PCE    implementa[on   ü  Internal  NB/SB  soeware  agent   ü  NB  API  Extension   ü  Intent  Extension   ü  SB  Provider  PCEP/IGP  protocols     v  System  Integra[on/Test  for  a  Testbed  (not  finished  yet)       Current Status
  50. Community Contribution May  Release q  NB/SB API extensions for PCEP

    support in ONOS q  New Intent for PCEP q  LSP event notifications mechanism q  Packet In/Packet out
  51. Closing  notes   ¡  Tom  Anschutz,  AT&T   ¡  Yoichi

     Sato,  NTT   ¡  Bill  Snow,  VP  Engineering,  ON.Lab   (  Please  view  video)