1 / 10

SDN/OPENFLOW in LHCONE

SDN/OPENFLOW in LHCONE. A discussion. SDN discussion in LHCONE. We had a session on SDN in LHCONE, appended to the point-to-point workshop in Geneva in May https ://indico.cern.ch/conferenceDisplay.py?confId=241490 The idea was to open a discussion on SDN use cases in the scope of LHCONE.

anoki
Download Presentation

SDN/OPENFLOW in LHCONE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SDN/OPENFLOW in LHCONE A discussion Artur.Barczyk@cern.ch

  2. SDN discussion in LHCONE • We had a session on SDN in LHCONE, appended to the point-to-point workshop in Geneva in May • https://indico.cern.ch/conferenceDisplay.py?confId=241490 • The idea was to open a discussion on SDN use cases in the scope of LHCONE Artur.Barczyk@cern.ch

  3. One slide of introduction • Software Defined Networking (SDN): Simply put, physical separation of control and data planes • Openflow: a protocol between controller entity and the network devices • The potential is clear: a network operator (or even user) can write applications which determine how the network behaves App App Controller (PC) OpenFlow Protocol OpenFlow Switch Flow Tables ACTION MAC src MAC dst …

  4. A problem statement • SDN/Openflow could enable solutions to problems where no commercial solution exists • Can we identify such unsolved issues/problems? • Which • have no solution so far, or • the solution is complex or introduces other issues • SDN/Openflow could naturally provide a platform for a solution • network intelligence is completely controlled by the developer • Caveat: coding is required, not for the faint-hearted • (no, we cannot just buy a controller) Artur.Barczyk@cern.ch

  5. SDN - Brief summary At the meeting in Geneva, we had identified such cases: • Multitude of transatlantic circuits makes flow management difficult • Impacts the LHCONE VRF, but also the GPN • No satisfactory commercial solution has been found at layers 1-3 • Problem can be easily addressed at Layer2 using Openflow • Caltech has a DOE funded project running, developing multipath switching capability (OLiMPS) • We’ll examine this for use in LHCONE • ATLAS use case: flexible cloud interconnect • OpenStack at several sites. • Openflow is the natural virtualisation technology in the network. Could be used to bridge the data centers Artur.Barczyk@cern.ch

  6. And NOW FOR SOMETHING DIFFERENT Artur.Barczyk@cern.ch

  7. Activities in LHCONE… Lars Fischer Artur.Barczyk@cern.ch

  8. On the other hand… • the openflow activity as such is dormant • the CE/TRILL activity has evolved towards using Openflow for demos • Ronald suggested we might merge the two activities • Proposal: new, single activity: Applied SDN • include multipath concept development • include WAN virtualisation • include …. Artur.Barczyk@cern.ch

  9. Role of the group? • There exist several Openflowtestbeds • ESnet ANI, OFELIA, GN3+ openflow facility, etc. • Some (not all) could be a playground for testing the ideas for later use in LHCONE • A role for this group could be twofold: • work with the respective entities on development of a particular solution • follow/inform the various efforts in NRENs Artur.Barczyk@cern.ch

  10. open for debate… Artur.Barczyk@cern.ch

More Related