LHC Open Network Environment LHC ONE

1. LHC Open Network EnvironmentLHCONE David Foster CERN IT LCG OB 30th September 2011

2. Agenda Introduction LHCONE Status The way forward – A personal view to be discussed

3. History of LHCONE • I am assuming much of the background is familiar • This is not an LHCONE tutorial • Pre-cursor requirements paper (Bos-Fisk condensate) • LHCONE.net website for all reference documentation • This is an exercise that grew out of 2 main considerations • Result of the 2010 transatlantic workshop at CERN • To ensure that the services to the science community maintain their quality and reliability. • To protect existing R&E infrastructures against the potential “threats” of very large data flows that look like ‘denial of service’ attacks. • This is coordinated through the LHCOPN community • All the large R&E providers are represented. • The LHC user communities are invited. • But this (unlike the LHCOPN) is not a CERN led activity.

4. LHC Networking Production • The production services for LHC Networking are • The LHCOPN for T0-T1 and T1-T1 traffic • The general purpose IP networks for T1/T2/T3 interactions. • LHCONE is investigating different approaches for providing capability and manage large data flows. • It is not yet a production service • It has crystallised much activity that has been on-going on the different continents into testing multi-domain, inter-continental solutions • There is no clear agreement (yet) on the long-term technical approaches • Although this is emerging • There are a number of early adopter sites that are benefitting but it must be clear that this is an evolving solution. • This is being ‘financed’ by the network providers with the motivation of providing new types of services to the user communities. • Utilising some additional research network capacity (transatlantic projects such as ACE) or national infrastructures (NREN’s, I2, ESNet).

5. The promise of LHCONE • Providing some ‘guarantees’ of performance • Large data flows across managed bandwidth that would provide better determinism than shared IP networks. • Segregation from competing traffic flows. • Manage capacity as Number of sites x Max flow/site x Number of Flows increases. • Better utilisation of resources • Use all available resources especially transatlantic. • Provide better traffic management and engineering capability • Leverage investments being made in advanced networking • Access to more resources.

6. LHCONE Status • Intention was to execute a prototype proof of concept • Based on the concept of Open Lightpath Exchanges. • Switched core, routed edge. • Recognise individual contraints • Allow everyone to use existing equipment. • Use existing standards. • This has resulted in an interesting and working proto-infrastructure • But scalability and manageability are doubtful with current technology. • This has resulted in a fork in the road • Transform this into a safe, but constrained solution today • Are the requirements from the R&E networks still valid? • Slow down the move to a production infrastructure to investigate emerging solutions • New standards for L2 networking.

7. Overview (from Dante)

8. Detailed View (Bill Johnson)

9. The Way Forward A Personal View – To Be Discusssed • There is no imminent problem of saturating existing R&E IP networks and therefore constructing simply an independent IP network for large science communities, such as HEP has limited value. • General purpose IP networks remain the main production facility for the LHC traffic until at least the LHC restart, 2015. • All R&E network providers are investing in many initiatives (Dynes, DICE etc) to investigate the future of large science flows beyond traditional IP networks and should therefore work together on this global initiative. • LHCONE should be the exemplar of that approach applicable to all future large-scale science experiments on a world wide scale. • It should be ambitious in its approaches on the timeframe of the next 3 years. It should aim to bring an alternative to “traditional” large-scale IP infrastructures or demonstrate that it not feasible, economic or advantageous to do so. • The existing multi-VLAN infrastructure should continue to be used and developed but also evolved along the common lines to be decided by the architecture group with a view to manageability and integrating new approaches. Perhaps the scope needs to be limited in the short term. • LHCONE should engage with early adopter user communities in a managed way to demonstrate that the new infrastructures can provide production services. This should bring new capability to the early adopters and not impact the current production capabilities. This should be coordinated, for the LHC, with the experiments.

10. Next Steps • Coordination will continue through the joint LHCOPN/LHCONE meetings and the associated working groups • Architecture working group will meet this week and an architecture workshop is being planned. • For all information, technical or otherwise: http://LHCONE.net