Download Document

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