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 perfSONAR and 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:port vs 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