GridPP 12th Collaboration MeetingNetworking: Current Status

Robin Tasker31 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:

http://gridmon.dl.ac.uk/gridmon/

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 networkperformance data from multiple domains usingthe same method.

The deliverable detailing this approach – DJRA4.2, Specificationof Interfaces for Network Performance Monitoring – wassubmitted 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 byMarch 2005. It will allow more complex queries than the original JRA4 prototype, and thusdemonstrate the power of this idea even further.

Monitoring Nodes

Moving to a model where the tools store theirresults in a central database at DL. Webservices and human (web) access to the datawill also be via services running at DL.

Storing and providing access to the data from acentral location allows us to reduce thecomplexity 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. Theprosaic approach says the provision of a 10Gbits/s access from a T1 will in the firstinstance (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 sufficientthen 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 andthe 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 solvethe problem but other architectures were at least as effective particularly when the differentQuality 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 120-600 750 700 100 1.7 - 2.2 GBytes/s av T1 20-100 75 100 60 260 - 340 MBytes/s

SC3: 2Q2005 (disk - network - disk) with aim of 60MB/s at each T1 and 500MB/s agg at CERNwith modest T2 traffic. Aim that by end 2005 this is available as service for experimentsto use

SC4: 1Q2006 running at nominal data rate for LHC by summer 2006, and service bySeptember 2006 and then run out the operational service at the full rate, i.e. twice thenominal 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 <T1 - Campus - RPAN - JANET - GN2 - CERN - Campus - T0> to be sorted out

RAL Connectivity - Now

NNWManchester

NNWManchester

St PancrasSt Pancras

EastNetCambridge

EastNetCambridge

WarringtonC-PoP

WarringtonC-PoP

10G10G

ULCCULCCAmsterdamAmsterdam

10G10G

10G10G

10G10G

ChicagoChicago

10G10G

LeedsC-PoP

LeedsC-PoP

C&NLMANLancaster

C&NLMANLancaster

CLRC-RALCLRC-RAL

ReadingC-PoP

ReadingC-PoP

YHMANLeeds

YHMANLeeds

UKLight Phases 1 & 2, as of January 2005

David Salmon, UKERNA

RAL Connectivity - UKLight

RAL Connectivity - 2006

Questions?