Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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 Location Relation Lifetime * * Network Object name: <string> id: <URI> Node Port Link Group Service Rule 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 • Group – Domain, network, path, topology • Service Path Topology Domain – Measurement Archive Network – 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