1. LHC T0/T1 networking meeting
LHC-OPN operations
Roberto Sabatino
LHC T0/T1 networking meeting
Rome, 4 April 2006

2. From 31 January Integrate LHCnet and Taiwan
Relationship with EGEE-SA2 / ENOC use cases
Progress of GN2 JRA4 and perfSONAR

3. LHCNET+TAIWAN LHCNET TAIWAN
Based on 10Gbps circuits between Force10 switches
Possible and willing to extract up/down status
Hence is possible to integrate in operational monitoring model
TAIWAN
pending

5. ENOC use cases
Document sent to list, resulting from discussions between EGEE-SA2, DANTE, DFN
2 functions (data model, weathermap) and 5 workflows described

6. WF 1-T1 notices a fault in connectivity to T0
the networking staff at T1 will inform the GGUS via a TT
T1 (belongs to NREN A) may contact the NREN A following the national procedures:
It is a known fault (or scheduled maintenance) in which case GGUS will re-issue the trouble ticket, or point to the repository of open tickets.
If it is a new fault, workflow 2 below applies

7. WF-2: The ENOC takes TT from GGUS/gives feedback to GGUS
ENOC analyses where the fault is. Two cases apply:
The ENOC via the weathermap is able to automatically locate the fault. The ENOC will signal the fault to the NREN involved via a trouble ticket and await further information from that NREN. ENOC will keep GGUS informed who in turn will keep users informed. ENOC will keep other relevant NOCs informed via TTs
It is a new fault and the weathermap does not locate the fault. In this case the ENOC will query each NOC involved in the link and ask them to check the status of their portion of the link. The ENOC will issue periodic trouble tickets to GGUS until the fault is located. Once it is located , the NOC where the fault is located will send periodic TTs to ENOC who will dispatch them to GGUS and other relevant NOCs.
ENOC gives feedback to close TT in GGUS, if fault is resolved

8. WF-3: : NREN-A notifies the ENOC of a fault
NREN-A will notify its user base following its own national procedures.
NREN-A will notify the ENOC via a trouble ticket.
The weathermap will be updated showing a fault in NREN-A
The ENOC will notify all other parties affected by the fault via a trouble ticket to the GGUS
NREN-A will send periodic updates on the resolution of the fault to the ENOC and these will be passed on by the ENOC to all other parties affected until the fault is resolved. At that time the weathermap is updated

9. WF-4:NREN-A notifies a scheduled maintenance
NREN-A notifies the ENOC of a scheduled maintenance with an agreed notice period (for example 1 week).
The ENOC re-issues the trouble ticket to all other relevant parties with an agreed notice period
The ENOC stores the information in a DB that can be consulted by all parties via a web portal
The weathermap will be able to show that a scheduled maintenance is due on a link within a period of 1 week

10. WF-5:The ENOC, via the weathermap, notices a fault
The ENOC contacts the NREN-A to clarify the situation
If the fault is confirmed, ENOC informs GGUS via a TT and other relevant NOCs
NREN-A will issue periodic TTs to ENOC who will dispatch them to GGUS and other relevant NOCs.

11. LHC End User T0/T1 staff GGUS/TTM Other .. NOC ENOC Weathermap
LHC View
TT System
MSR
LHC-OPN
is customer of
reports WLAN fault
LHC End User
reports general fault
T0/T1 staff
NREN .. NOC
GÉANT2 NOC
fault & maintenance notification
Provides
monitoring data
automated perfSONAR framework
GGUS/TTM
Other .. NOC
Trouble Tickets

12. Relevant work in GN2 e2e lightpaths
NREN
GEANT2
The GN2 JRAs (JRA4 and JRA3) are looking at aspects of monitoring the status of lightpaths

13. Draft E2E Link data model
To be renamed “ID_Link”

14. Use perfSONAR Re-uses software developed to date
Will automatically have AA capabilities
Will allow for easier interworking with Internet2 & ESnet
Maintenance/support provided

15. E2E visualisation and NREN services

16. Expectations from NRENs
It will be incumbent upon the NRENs to provide the status information of the NREN_links (and possibly ID_links) for which they are responsible. This implies:
Monitoring of the relevant alarms raised by NEs or an NMS or the periodic polling of parameters from individual NEs (directly or via an NMS) and, if needs be, concatenation of multiple measurements to provide (synthesize) the NREN_link and/or ID_link information
Establishing a service which listens for the perfSONAR requests and responds with perfSONAR answers
Does it mean that every NREN has to develop all this?
No! , see next slides

17. Option 1
The NRENs develop the data retrieval, local processing and stores the results in XML format , updated in (near) real time
NOTE:
monitoring proxy
The NREN deploys a service (that will be provided by GN2 JRA1) which, when receiving a perfSONAR request, parses the XML file and returns a perfSONAR reply to the requester
The NREN can use any programming language to retrieve the data, analyse it and write the results into the register/XML file

18. Option 1
NREN is in charge of retrieving the data from the NMS/DB, processing it and writing the data into the register file
JRA1 to produce the service code and maintain it. The service reads the register file and sends valid perfSONAR responses to requests (end April, early May).
JRA1 ensures that the JRA4 data model is integrated within the perfSONAR schema
JRA4 is in charge of the E2E NOC visualisation (and other) tools

19. Option 2
The NRENs develop the data retrieval, local processing and passes the results to a JRA1 java class which will store the data into a mySQL database (JRA1 provides the DB schema).
The NREN deploys a service (that will be provided by JRA1) which, when receiving a perfSONAR request, fetches the required data from the mySQL database and returns a perfSONAR reply to the requester
Requests for instantaneous and historical data supported
The main advantage of this solution is that it minimises the development to be done by the NREN. The NREN can use any programming language to retrieve the data, process it and pass the results to the java class (provided the latter is done using a predefined format).

20. Option 2
NREN in charge of retrieving the data from the NMS/DB, processing it and passing the results to a java class
JRA1 to produce the “mySQL MA service” code (end of April) and maintain it, plus the DB and its schema
JRA1 ensure that the data model is integrated within the perfSONAR schema
JRA4 in charge of the E2E NOC visualisation (and other) tools

21. Possible future options
This probably means into Gn2 Y3 (from September 06)
Direct SNMP access to NREN equipment
NREN data available in RRD or MySQL DB
NMS northbound interface

22. The weathermap
Visualisation tool that uses the data made available by perfSONAR
Work by DFN
A sample weathermap for POC from using NMS traps (GEANT2 view only)