Network Schemata

Martin Swany

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

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

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

The UNIS Base Model

Basics

• Network Element– Name, ID

• Lifetime– Monitoring data still valid after an entity is

gone– Reservations

• Location– Geographic things defined, but other things

possible

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”

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

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

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