GridPP 12th Collaboration Meeting Networking: Current Status Robin Tasker 31 January 2005

1. To bring the technology of very high rate/long distance data transport to practical use in experimental production environments (both current and LHC experiments); and to demonstration of one or more UK HEP experiments being able to regularly transport data at rates in excess of 500 Mbit/s and preferably 1 Gbit/s. 2. To exploit the UKLIGHT infrastructure to utilise switched dedicated circuits between major centres including UK Tier1 and 2, CERN and FNAL. [Barney Garrett] 3. To participate in EGEE oriented network monitoring service developments and deployment within the UK, and development of diagnostic engines for Grid operations [Mark Leese] 4. To maintain the strategic relation which HEP holds with all relevant major Network authorities globally. 5. To provide PPNCG support and other work as specified Network Objectives

Network Performance Monitoring Current partners: Current collaborators:

Current Activities #1 GGF NM-WG 1. The group are looking at new, more powerful schemas 2. Also pushing the stabilisation of the current schemas. This is very important for early adopters, such as EGEE JRA4, DANTE, Internet2 and NCSA, as well as GridMon EGEE-JRA4 1. Collaboration with JRA4 resulting in their network performance monitoring prototype. 2. JRA4 “mediator” software was developed together with a sample human client. The mediator provided a single interface to two underlying monitoring infrastructures via the NM-WG interfaces The prototype was important because it demonstrated, albeit in a simplistic manner, obtaining network performance data from multiple domains using the same method. The deliverable detailing this approach – DJRA4.2, Specification of Interfaces for Network Performance Monitoring – was submitted on time and was successful in its EGEE review

Current Activities #2 GridMon The Web Service A first pass of a NM-WG compliant web services interface into the relational database by March It will allow more complex queries than the original JRA4 prototype, and thus demonstrate the power of this idea even further. Monitoring Nodes Moving to a model where the tools store their results in a central database at DL. Web services and human (web) access to the data will also be via services running at DL. Storing and providing access to the data from a central location allows us to reduce the complexity of the individual monitoring nodes. Critically, is the move to a relational database model, speeding up access to the data, and allowing far more advanced queries to be made.

Networking for LHC T0/T1 Meetings 8 October 2004 and 20 January 2005 Meeting between CERN, T1 representatives, NRENs and DANTE LHC T1 Requirements: provides a ballpark understanding of the raw data requirements. The prosaic approach says the provision of a 10Gbits/s access from a T1 will in the first instance (2007) be sufficient. On-going / refining work – Jamie Shiers (CERN) T1/T1: As yet limited estimations have been developed but if the capacity is not sufficient then quality will suffer but usage is still possible. T1/T2: The model for delivery from T1 to T2's and restoring datasets back from T2's to the T1 is not well developed. Also to be understood is the relationship between a T1 and the set of T2s accessing it (particularly across national boundaries) GN2 architecture: at one extreme a 10Gbits/s full mesh (T0/T1 and T1/T1) would solve the problem but other architectures were at least as effective particularly when the different Quality requirements were considered. i.e. a 10Gbits/s access into a "star" centred on CERN GN2 procurement and deployment through 2005 and early 2006

Service Challenge Issues Service Challenge Workshop 27/28 January 2005 Nominal LHC Data Rates: (from Les Robertson) ALICE ATLAS CMS LHCb Total CERN GBytes/s av T MBytes/s SC3: 2Q2005 (disk - network - disk) with aim of 60MB/s at each T1 and 500MB/s agg at CERN with modest T2 traffic. Aim that by end 2005 this is available as service for experiments to use SC4: 1Q2006 running at nominal data rate for LHC by summer 2006, and service by September 2006 and then run out the operational service at the full rate, i.e. twice the nominal rate. Purpose: 1. The point is to stress test the system and ensure that it is operationally capable 2. Needs to ensure that the planned connectivity T0 - T1 is actually in place! 3. Need to be sorted out

RAL Connectivity - Now

NNW Manchester St Pancras EastNet Cambridge EastNet Cambridge Warrington C-PoP 10G ULCC Amsterdam 10G Chicago 10G Leeds C-PoP Leeds C-PoP C&NLMAN Lancaster CLRC-RAL Reading C-PoP YHMAN Leeds UKLight Phases 1 & 2, as of January 2005 David Salmon, UKERNA

RAL Connectivity - UKLight

RAL Connectivity

Questions?