Network Measurement and Control WG BOF

1. Network Measurement and Control WG BOF Jeff Boote, Martin Swany, Verena Venus

2. OGF IPR Policies Apply • “I acknowledge that participation in this meeting is subject to the OGF Intellectual Property Policy.” • Intellectual Property Notices Note Well: All statements related to the activities of the OGF and addressed to the OGF are subject to all provisions of Appendix B of GFD-C.1, which grants to the OGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in OGF meetings, as well as written and electronic communications made at any time or place, which are addressed to: • the OGF plenary session, • any OGF working group or portion thereof, • the OGF Board of Directors, the GFSG, or any member thereof on behalf of the OGF, • the ADCOM, or any member thereof on behalf of the ADCOM, • any OGF mailing list, including any group list, or any other list functioning under OGF auspices, • the OGF Editor or the document authoring and review process • Statements made outside of a OGF meeting, mailing list or other function, that are clearly not intended to be input to an OGF activity, group or function, are not subject to these provisions. • Excerpt from Appendix B of GFD-C.1: ”Where the OGF knows of rights, or claimed rights, the OGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant OGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the OGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the OGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification.” • OGF Intellectual Property Policies are adapted from the IETF Intellectual Property Policies that support the Internet Standards Process.

3. Working Group Summary • Generation and exchange of network measurements is critical for all networked environments, and in particular advanced environments like the Grid. The schemata for network metrics that have been defined in the OGF’s Network Measurement Working Group (NM-WG) have spawned a vibrant community among R&E network operators who have been developing and deploying an infrastructure called perfSONAR. The perfSONAR effort began in September 2004 in a series of meetings in and around GGF-12 in Brussels, Belgium. The perfSONAR consortium has begun to produce a series of protocol documents describing the messaging functionality in that system and the NMC group will house the formalization of those standards within the OGF.

4. Purpose and Scope • The purpose of the Network Measurement and Control Working Group is to standardize the XML-based protocols that are currently in use in the perfSONAR project to control network measurement infrastructure and to share the results of the measurements and metrics that are generated. These protocols are already in widespread use and are described across a number of documents with various degrees of formality. • The scope of the Network Measurement and Control Working Group is to define base protocols and extension frameworks for those protocols, as well as to define extensions that are already in common use.

5. Relationships with other WGs

6. Deliverables and Milestones • D1. Base perfSONAR Protocol. This document describes the basic message formats and exchange models. This document also describes the extension mechanism and simple extensions that are common to all perfSONAR services as well as the “result codes” and their extension mechanism. This document will also discuss the AA framework and describe more complicated message patterns and the extension points to allow definition of new ones.

7. Deliverables and Milestones • D2. Measurement Archive Protocol. This document describes the extension and application of the base protocol to support communication with a Measurement Archive (MA). The particular message types that MAs support are defined here.

8. Deliverables and Milestones • D3. Information Service Protocol. This document describes the extension and application of the base protocol to support communication with an Information Service. The particular message types that ISs support are defined here.

9. Deliverables and Milestones • D4. Measurement Point Protocol. This document describes the extension and application of the base protocol to support communication with a Measurement Point (MP). The particular message types that MPs support are defined here.

10. Deliverables and Milestones • D5. Transformation Service Protocol. This document describes the specific messages and interactions required to provide a generic transformation service. The concept is to allow a mechanism for data transformation using a pipeline of web services.

11. Deliverables and Milestones • OGF 23 (June 2008): • official start of working group • first drafts of deliverables D1, D2, D3 ready for discussion • August 2008: • second draft of deliverables D1, D2, D3 ready for WG review on mailing list • First draft of deliverable D4 • OGF 24 (September 2008): • WGLC for D1, D2, D3 • Second draft of deliverable D4 • November 2008 • WGLC for deliverable D4 • September 2009: • official closure of working group

12. What is perfSONAR • 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 capabilites to themselves and their user comunities. • An architecture & a set of protocols • Web Services Architecture • Protocols based on the Open Grid Forum Network Measurement Working Group (NM-WG) Schemas • Emerging standards in the Network Markup Language WG (NML-WG) • Several interoperable software implementations • Java & Perl • A Deployed Measurement infrastructure

13. perfSONAR Goals • Increase network awareness • Set user expectations accurately • Reduce diagnostic costs • Performance problems noticed early • Performance problems addressed efficiently • Network engineers can see & act outside their “turf” • Transform application design • Incorporate network intuition into application behavior

14. Vision: Network 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)

15. perfSONAR Collaborators • RNP • ARNES • BELNET • CARNET • CESNET • CYNET • DANTE • DFN • ESnet • FCCN • FERMI • GARR • GEANT • Georiga Tech • GRNET • HEAnet • Indiana University • Internet2 • ISTF • POZNAN • UNINETT • University of Delaware • Renater • RedIRIS • SLAC • SWITCH • SURFnet And anybody else we missed

16. 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.

17. perfSONAR: System Description • Domains represented by a set of services • Each domain can deploy services important to the domain • Analysis clients interact with service across multiple domains

18. perfSONAR: Services (1) • Lookup Service • Allows the client to discover the existing services and other LS services. • Dynamic: services registration themselves to the LS and mention their capabilities, they can also leave or be removed if a service gets down. • AuthN/Z Service • Internet2 Middleware Group, GN2-JRA5 (eduGAIN) • Authorization functionality for the framework • Users can have several roles, the authorisation is done based on the user role. • Trust relationships defined between users affiliated with different administrative domains.

19. perfSONAR Services (2) • Transformation Service • Transform the data (aggregation, concatenation, correlation, translation, etc). • Topology Service • Make the network topology information available to the framework. • Find the closest MP, provide topology information for visualisation tools • Resource protector • Arbitrate the consumption of limited resources between multiple services.

20. Inter-domain perfSONAR example interaction Useful graph Client Token MA Here is who I am, I’d like to access MA B Here is who I am, I’d like to access MA A Token MB a,b,c : Network A, MA A, AA A Where Link utilisation along - Path a,b,c? AA A Here you go Get Link utilisation a,b,c Get link utilisation c,d,e,f AA B Here you go a,b,c: Network A – LS A, c,d,e,f : Network B, MA B, AA B Where Link utilisation along - Path a,b,c,d,e,f? LS A LS B MA B MA A a b f e c d Network A Network B

21. Schema • Key Goals: Extensibility, Normalization, Readability • Break representation of performance measurements down into basic elements • Data and Metadata • Measurement Data • A set of of measurement events that have some value or values at a particular time • Measurement Metadata • The details about the set of measurement data

22. Schema Normalization • Can simply the database representation for many types of measurement data • While optimizations are certainly possible, many measurement types can be viewed as one value over time • Assists Combination/Concatenation of metrics • Creating derived metrics • Normalization helps with inferring relationships between types of metrics

23. Schema Basic Elements - Metadata • Subject • The measured/tested entity • EventType (Verb) • What type of measurement, value, or event occurred • Characteristic, tool output, or generic event • Parameters (Adjectives and Adverbs) • How, or under what conditions, did this event occur?

24. Schema Basic Elements - Data • Some sort of value - Datum • Existence of an event might point to the case where there no additional value • As in “Link up/down” or threshold events • Time • Must be extensible since even agreement about the right structure is not easy • E.g. UNIX timestamp vs NTP time

25. Metadata Data A Message Message Message

26. Metadata Data An Object Store Store

27. A Data is Linked to a Metadata Metadata <id>someId</id> Data <metadataIdRef> someId </metadataIdRef>

28. A Metadata may be linked to another Metadata <id>someId</id> Metadata <id>someOtherId</id> <metadataIdRef> someId </metadataIdRef>

29. Schema Namespaces • All measurements have some sort of Data and Time • All measurements can be described by the Metadata identifying who, what and how • The specific structures of the Data and Metadata elements depend on the measurement • Approach: Consistently use Data and Metadata elements and vary the namespaces of the specific elements

30. Schema Namespaces - 2 • We encode the measurement/event type in the namespace • And as a standalone element • Some components of the system can pass Data and Metadata elements through without understanding their specific structure • Allows and implementation to decide whether it supports a particular type of data or not • Allows validation based on extended (namespace-specific) schemata

31. Schema Namespaces and Extensibility • One key to extensibility is the use of hierarchy with delegation • Similar to OIDs in the IETF management world • The NM-WG has a hierarchy of network characteristics • Good starting point • However, not all tools are cleanly mapped onto the Characteristic space • Often a matter of some debate

32. Schema Namespaces and Extensibility - 2 • Organization-rooted tools namespace addresses this • Some top-level tools • ping, traceroute • Easy to add new tools in organization-specific namespaces • Performance Event Repository • Add a schema and get a URI • Add Java classes

33. perfSONAR-PS Motivation • Create separate implementation of perfSONAR standard • Use same protocol/standards • Proof of interoperability (strengthens the standard) • Targeted for NOC deployments • Lightweight • Easy to deploy/manage • (We were unable to convince our primary users to deploy Java services due to the complexity of dependencies)

34. perfSONAR-PS Beta Release (0.09) (May/08) • Focus on development of major perfSONAR components • LS - perfSONAR_PS::Services::LS::LS • SNMP MA - perfSONAR_PS::Services::MA::SNMP • Status MA - perfSONAR_PS::Services::MA::Status • CircuitStatus MA - perfSONAR_PS::Services::MA::CircuitStatus • Topology MA - perfSONAR_PS::Services::MA::Topology • PingER (SLAC) * • Recently released • OWAMP/BWCTL archive (perfSONARBUOY) • Not released via CPAN

35. SNMP Measurement Archive • Provide access to network performance data • Utilization • Errors • Discards • Numerous tools exist to collect passive measurements (via SNMP): • MRTG • Cacti • Cricket • Expose archives from RRD files

36. SNMP Measurement Archive • Current Deployment: • Internet2 Network • ESnet • Georgia Tech/SOX • Fermilab

37. Pinger Based MP/MA • Joint effort between Fermi Lab and SLAC • Present views of historic Pinger data • Expose interface to schedule live tests • Built with perfSONAR-PS infrastructure • pingER is used in the LHCOPN

38. Link Status Measurement Archive • Provide access to up/down status information about layer2 links • Data stored in a SQL database • Database schema allows for storing time ranges during which a link had a certain status • Minimizes storage costs for rarely changing links • Communication/Configuration via XML • Target audience is network operators and users interested in obtaining the status of the links over which their data flows

39. Link Status Measurement Archive • Collector • Allows for the periodic collection of the status of one or more links • Can use SNMP, Scripts or simply Constants • Can store results directly into a database or into a remote Measurement Archive • Future Plans: TL1 Collection

40. Link Status Measurement Archive • Visualization • A perfSONAR-UI Plugin is available that can display a network and the status of its links • Current Deployment • Internet2 Network • Internet2 Dynamic Circuit Network (limited)

41. Circuit Status Measurement Archive • An e2emon-compatible service • Integrates with the Link Status MA to provide the information stored in MAs • Can work with local MAs directly or with remote MAs • Can use the Topology MA to obtain necessary information about nodes • Can use a Lookup Service to lookup the MA containing information on each link • Target audience is administrators who want to publish circuit status information to e2emon clients

42. Circuit Status Measurement Archive • Visualization • Any tool that is compatible with e2emon will work with this service • Current Deployment • Internet2 Network

43. Topology Service • Provides a queryable repository for obtaining topology information about a domain • Can obtain the entire network • Xquery interface allows the construction of complex queries about the network • Topology is specified according to the schema in development in the OGF

44. Topology Service • Current Deployments • Internet2 • SLAC (PingER Topology Information) • Planned Deployments • DICE Dynamic Circuit Service Sites • ESnet

45. perfSONAR Lookup Service • Directory service of perfSONAR deployments • Accept service registrations • Handles queries for service location and capabilities and location of available data • Manage the lifetimes of data and services to keep information up to date • Web Service interface to XML Database • Sleepycat XML Database • Service Info/Data kept in native formats • Draw away the complex query tasks from otherwise 'busy' services

46. Lookup Service • Also XML based configuration/protocol • Native storage/query mechanisms [Xpath/XQuery] • Message format to exchange the data • Targeted at single domain deployment • Single instance to manage multiple services • Client components and applications use the LS to find services • perfSONAR-UI • perfAdmin

47. Lookup Service • Current Deployment: • Internet2 (Ann Arbor)‏ • University of Delaware • Planned Deployment: • IU for Internet2 network and regionals • DICE Dynamic Circuit Network sites • International Partners

48. Distributed Lookup Service • Federation of individual LS instances into a global system • “Meta”-lookup phase allows a query to find the specific LS that has relevant information • Or perhaps the relevant LSes that have said info • The specific query is sent directly to the LS in question • Recent active design and development

49. Distributed Lookup Service • Service and measurement metadata is “summarized” for propagation to distant domains • IP addresses in service and measurement metadata are compressed into network/netmask pairs in the same way that routes are advertised (CIDR-style) • These summarized metadata elements are advertised to external “scopes” • A “scope” is a set of LSes that are related by e.g. being in the same administrative domain (although multiple scopes within a single domain are possible)

50. Weather Maps - Internet2