Network Schemata

1. Network Schemata Martin Swany

2. Perspective • UNIS – Uniform Network Information Schema • Unification of perfSONAR Lookup Service (LS) and Topology Service (TS) • Not the Network Markup Language (NML) WG in the OGF • Very related, but this talk does not represent the state of that effort • I continue to be committed to that work, but this talk is from my perspective

3. History • I began working to define network metrics in the OGF (then the Grid Forum) in 2000 • The Network Measurement WG work formed the basis of perfSONAR (2004) • Widely used in International R&E networks • While working to standardize the “Subject” of a measurement, we started to codify the representation of network elements • We realized there was value in representing the relationships between those elements, thus we needed a representation of the topology • We evaluated CIM, various alternatives • The relationship issue was pushed by the need to represent the LHC network in 2005 • Internet2, GEANT2 and ESnet began working on interoperable Dynamic Circuit networks (or bandwidth on demand) in 2006 • We observed that our existing topology schema could serve this effort for topology exchange and pathfinding. • Today, Internet2 ION and ESnet OSCARS use this schema and the Topology Service from perfSONAR • Our current work is on UNIS, which generalizes and unifies the Information Services for perfSONARand OSCARS/ION

4. Philosophy • We need to use the same schema for control and measurement • Otherwise we lose information that we need • This just makes things easier! • We need to express common attributes and elements in a common way • Not everything is common, thus it must be easy to extend the schema • We use a relatively small set of basic elements, and extend the base elements to include layer-specific, or application-specific properties • Express complexity as necessary • Varying levels of detail in the same schema framework • We use namespaces in XML, but really map these to URIs • The basic model can be encoded in a variety of ways: XML, RDF, SQL, JSON… • As long as we agree on the basic elements, translation is straightforward

5. The UNIS Base Model

6. Basics • Network Element • Name, ID • Lifetime • Monitoring data still valid after an entity is gone • Reservations • Location • Geographic things defined, but other things possible

7. Core elements • Node • Router, switch, host • Virtual instances of any of the above • Uses a Relation element • Port • Interface (name changed during the Control Plane effort) • Link • Unidirectional or bidirectional • Distinct properties in each namespace • ethernet:portvs ipv4:port • Relation element or “join”

8. Other elements • Group • Domain, network, path, topology • Service • Measurement Archive • Ability to create VMs • Switching capability of an interface or node • Rule • IP route, Openflow rule

9. Other things • We have observed that XSD and RNG lack some semantics we’d like • Recent development (Oct 2010) RFC6010 • YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) • YANG provides additional semantic power • Translations to XSD, RNG, YIN

10. Observations • There is an inherent tension between expressiveness and complexity • We may need to represent things beyond resources that can be allocated • This is certainly true in I&M • Substrate topology