perfSONAR Schema and Topology Martin Swany

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

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

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

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

A Message Message MetadataData

An Object Store Store MetadataData

A Data is Linked to a Metadata Metadata someId Data someId

A Metadata may be linked to another Metadata someId Metadata someOtherId someId

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

Schema Namespaces - 2 Why encode the measurement/event type in the namespace? The encoding is essentially redundant 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

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

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

Versioning Example <nmwg:message id="snmpmsg5" type="MetadataKeyRequest" xmlns:nmwg=" xmlns:snmp=" xmlns:nmwgt=" scotch.pc.cis.udel.edu SNMP.Get.Request

Versioning Separate revisions of base schema and eventType schema Open Issues: Query for supported versions must be defined This will enable a migration strategy

Topology Schema

Topology schema Reusable Subject elements for common cases Also reduces redundancy Relationships between Subjects Same basic structure at all layers Networks are graphs Define: Nodes Interfaces Links Networks

Topology

Topology - Recursive Links

Topology Schema Structured by layers and the same elements recurring there Varied again by namespaces Reuse visualization logic, etc. 4 Layers: Base (both abstract and L1), L2, L3, L4

Relationships between Subjects To completely capture the relationships, we need to do a few more things Recursive definition of links Logical links consist of physical links Ordered lists of links Like above, but we need to introduce an Index attribute Networks Physically consist of links but that is not always the most convenient logical view Special element to which Interfaces or Links belong

Relationships between Subjects Elements at the same layer have relationships A link “contains” two interfaces At Layer2 or Layer3 Elements of the same sort have relationships between themselves at different layers A Layer 1 Interface (physical NIC) can have one or more Layer 2 Interfaces, which can each have one or more Layer 3 Interfaces Node is special Since a Node doesn’t really have any higher-layer characteristic independent of its Interfaces

Current Status

Schema Status Three documents in preparation for OGF Base Schema Topology Schema Extension guide With examples of utilization, traceroute, ping Complete drafts by December To NMWG by January OGF meeting in February

Schema Status Three schema components Base Defines Message, Store, Data, Metadata, Parameters Topology Defines Subjects that can appear in the Metadata and Version 3 represents their relationships as well EventTypes Each data type extends the Base and can define what Parameters are acceptable and what subjects are required

Outstanding Issues Namespaces for Message types Currently a simple text field, but namespaces might make Message syntax/semantics easier to track (and version) Uniform EventTypes that match the EventType namespace XML Factoring to further reduce redundant information Some work at UD on “views”