perfSONAR 8 th Annual Global LambdaGrid Workshop, Seattle Oct 1, 2008

1. perfSONAR 8th Annual Global LambdaGrid Workshop, SeattleOct 1, 2008 Thomas Tam CANARIE Inc.

2. Outline • Lightpaths monitoring challenges • Why perfSONAR? • perfSONAR overview – Jeff Boote • Test lightpath overview • Results and Observations • Next steps

3. End-to-end Lightpaths monitoring challenges • End-to-end Lightpaths often cross multiple domains. • NOCs have direct control only over a section of a lightpath. • NOCs can monitor their own network. • manual, semi-automated, and fully automated processes • Netherlight SpotLight provides a lot monitoring information for external users. • None of us has a complete view of the lightpath • When an outage hits, alarms could raise for the entire path. • NOCs or organizations would broadcast email globally to notify all lightpath participants. • Due to time zone and operating hours differences, sometime responses might take hours – perhaps days. • A monitoring tool that shows the end-to-end lightpath status and is available 7x24 would be idea.

4. Why perfSONAR? • The idea monitoring tool would: • show a near real-time status • help NOCs to isolate problems quicker • provide readable operation and alarms information • provide an interface to historical events • allow easy integration to the existing monitoring tools • be a collaborative tool instead of central managed tool • perfSONAR network monitoring middleware seems to fit in well. • From the last GLIF meeting, community agreed that perfSONAR could be a potential tool that helps NOCs manage cross-domain lightpaths effectively.

5. perfSONAR trial working group • In January meeting, a working group was formed. • The objectives are: • to explore the ability of perfSONAR and • organize a demo in the October meeting. • The working group member consists of: • CANARIE – Thomas Tam (Leader) • KRLight – Dongkyun Kim • Internet2 – Jeff Boote • Netherlight/SARA – Ronald van der pol • NorduNet – Lars Fischer • Later, UNINETT and StarLight have got involved on the lightpath provisioning and testing.

6. perfSONAR Technology Overview Jeff W. Boote Senior Network Software Engineer Internet2

7. What is perfSONAR An architecture & a set of protocols Services Oriented Architecture (SOA) Web Services Interfaces Protocols being standardized in the OGF NMC-WG Also A collaboration Production network operators focused on designing and building tools that they will deploy and use on their networks to provide monitoring and diagnostic capabilities to themselves and their user communities. Several interoperable software implementations Java & Perl A Federated set of Deployed Measurement Infrastructures

8. Vision: Performance Information is … Available People can find it (Discovery) “Community of trust” allows access across administrative domain boundaries Ubiquitous Widely deployed (Paths of interest covered) Reliable (Consistently configured correctly) Valuable Actionable (Analysis suggests course of action) Automatable (Applications act on data)

9. perfSONAR Motivation Most organizations can do monitoring and diagnostics of their own network Networking is becoming an increasingly cross-domain effort Monitoring and diagnostics must also become a cross-domain effort

10. Decouple 3 phases of a Measurement Infrastructure

11. perfSONAR Components Analysis/Visualization Infrastructure Data Services Information Services Measurement Points User GUIs Service Lookup Web Pages Measurement Archives Topology NOC Alarms Service Configuration Transformations Auth(n/z) Services

12. perfSONAR Architecture Interoperable network measurement middleware: Modular Web services-based Decentralized Locally controlled Integrates: Network measurement tools Network measurement archives Discovery Authentication and authorization Data manipulation Resource protection Topology Based on: Open Grid Forum Network Measurement Working Group schema.

13. How might this apply to GLIF? Monitoring Deployed infrastructure for sharing network performance data Specific tools (circuit status) Infrastructure pieces Topology Discovery Authentication

14. Distributed Status Architecture Web Client Status Service Status Service Status Service Status Archive Status Archive Status Archive Status Collector Status Collector Status Collector Device Device Device Device Device Device

15. E2Emon - Monitoring Circuits

16. E2Emon: Status of E2E link CERN-LHCOPN-FNAL-001 E2Emon generated view of the data for one OPN link [E2EMON]

17. Future Considerations • Current configuration is too manual • perfSONAR related Information Services (IS) can help to automate • Implies *some* standardization for things like circuit identifiers • Current demo only monitors circuit up/down status • Other ‘health’ metrics useful (light levels…) • Performance metrics would be useful (where available)

18. The perfSONAR trial ligtpath

19. E2EMon Screenshots In normal operation, everything is showing green.

20. E2EMon Screenshots SARA took down the fibre to Nordunet to trigger the outage.

21. E2EMon Screenshots UNINETT took down an interfaces to trigger the outage

22. E2EMon Screenshots CANARIE portion is showing down due to maintenance.

23. Observations from participants • Setup • Installation of perfSONAR-PS is reasonable straight forward. • needs more documentation, configuration requires some helps • E2EMon GUI • is the only web client for monitoring link status • shows simple oper/admin states (up/down, Normal Operation/maintenance) • polls domains’ MAs to retrieve links information • update everything 60s • can be brought up anywhere and more than one. • Others • The distributed framework of perfSONAR fits well in cross-domain lightpath monitoring • It is a start, but more need to be done to be an effective tool • Additional statuses would be helpful - alarms, event, historical data • It could help NOCs isolating problem much quicker

24. Next Steps • Next steps - as a community, we should • continue our efforts to deploy perfSONAR on trial basis • provide recommendations to enhance the functionality and usability of the tool. • help to define meaningful operation and administration states that can enhance NOCs collaborative operation. • document our experiences so other users can use them as reference, perhaps organize a discussion forum. • help drafting how-to documents.

25. Thanks • KRLight – KwangJong Cho, Dongkyun kim • Internet2 – Jeff Boote, Aaron Brown, John Graham(MANLAN) • NetherLight/SARA – Ronald van der pol, SARA NOC • StarLight – Linda Winkler • NorduNet – Lars Fischer, Lars Lange Bjørn • UNINETT – Olav Kvittern, Jon K Hellan, Trond Skjersol Thanks !!!! to all the participants