Experimenting with ontologies for multi-layer network slicing Ilia Baldine Yufeng Xin Cluster-D ORCA-BEN Max Ott Ivan Seskar Cluster E Orbit

What do we need? A way to describe So we can What he have (substrate) What we want (slice request) What we are given (slice specification) So we can Map that to available or alternative resources Configure resources in a consistent (?) manner So that we use the same lambda on both ends Know what to measure Measurement points are effectively resources too, but are currently treated separately

What is the problem? We currently have many “organically grown” solution which kind-of work for their respective contexts We need a functional model utilizing formalized techniques that fully describe the context of an experiment.

Slicing a network

Multi-layered networks Multi-layered network is not a single graph It is an embedding of graphs of higher level networks into graphs of lower level networks Done by selecting proper layer adaptations The lower level graphs may evolve over time Cross-layer path threading model is not appropriate

Link slivering

We aren’t the First! Network Markup Language Working Group (NML-WG) Participants: Internet2, ESnet (PerfSONAR model) Dante / GN2 JRA3 (cNIS) University of Amsterdam (NDL) https://forge.gridforum.org/sf/projects/nml-wg

NDL Origin: Universiteit van Amsterdam SNE group Under development for several years In use within GLIF Based on OWL/RDF Can be used with RDF frameworks Inference engines/reasoners Query tools (SPARQL) Other semantic web advances Based on G.805 (for transport networks) and the concept of layer adaptations

Relevant ITU Standards General architecture/models G.805: Generic functional architecture of transport networks G.809: Functional architecture of connectionless layer networks Technology specific descriptions of architectures G.803: SDH G.872: Optical transport G.8010: Ethernet G.8110: MPLS Documents are available at http://www.itu.int/rec/T-REC/e

G.805 example

What do we need? Computer readable network description, which can describe state and capabilities of multi-layer networks, using a technology independent model. Virtualization is just another form of layering A vibrant testbed will continuously add NEW technologies

What else do we need? Ability to describe slice requests Fuzzy, if necessary Ability to describe slice specifications Precise Ability to perform resource accounting

RDF vs plain XML RDF advantage: RDF Disadvantage: Ontology: When defining a schema for RDF, you have to define a complete ontology, which means that every element must be given a well-defined meaning. This is both an advantage to the schema author, who is forced to clearly define context and meaning for every single element, as well as for users, who may use the meaning to leverage the information on the semantic web. Use of URIs: Every element described in RDF is automatically given a unique URI. These identifiers are usually based on the location of the published document. Internal references: RDF provides a very easy way to reference other objects defined in the same document. Pointers to other documents: When you want to reference a resource described elsewhere, you can explicitly point to another RDF file. This allows for a structured way of maintaining distributed information Extensibility: A user can mix two ontologies in his application, even when neither ontology author was aware of the other schema. Toolset: Because RDF is meant as a generic way of describing information, there are several tools which can automatically “make sense” of your data. RDF Disadvantage: Verbosity: In our experience, RDF/XML is about 1 to 2 times as verbose as XML. It should be noted that RDF models can also be described using other syntaxes, such as N3, which can easily be optimized for fast parsing. It’s for the computer to read, not a human, and there are tools 1. Freek Dijkstra, Jeroen van der Ham. Paola Grosso, Cees de Laat “Lightpath provisioning: XML schema or RDF schema?”, OGF NML Document, 2007 February 27

Where we are: NDL-OWL Existing toolkits: Gleen: subGraph query API NDL-OWL extends NDL in OWL Richer semantics and inference capability Unified semantic for substrate description, request description, and substrate configuration Accountability of network resource: physical, virtual, allocateable OWL Modules: Topology, layer Data structure utilities Technologies: PC, Ethernet, DTN, fiber switch…. BEN RDF describes BEN substrate Existing toolkits: Protégé: build and maintain Ontology and RDF Jena API library: Jena: Ontology model (resource, property) creation, modification, and validation ARQ: SPARQL query langauage Gleen: subGraph query API

NDL-OWL Java API: work in progress Slice representation in multiple abstract levels Device level within the end-to-end layer Device level cross layer Interface level Substrate configuration state represented in online RDF model Virtual topology embedding Available resource and used resource Slice spec validation and mapping End-to-end cross-layer path availability Virtual topology mapping = Ontology subgraph embedding Mapping to the switching and configuration actions in each device along the path Path computation based on rules and constraint logic programming and optimization We know this isn’t the way to do it – quick hack

Future goals Unified spectrum-based resource representation, allocation, control and management Problems: Introducing time for resource scheduling Precise resource accounting Further ontology extensions (xDL) CDL: Cloud computing: Ontology for software and virtual machine MDL: Substrate measurement capabilities WDL: Wireless All extending common vocabularies to introduce new relationships Service procedures and Protocol: OWL-S

Lessons so far An abstract domain model is the key to develop the ontology OWL/RDF files are big, but the lines of code could be much shorter if efficient query/inference implementation Modular structure is good: grow as you need RDF/OWL is verbose and hard to maintain and validate, fortunately there are Jena, Protégé, etc… Processing in the ontology model or Java class: an implementation tradeoff between lines of code and probably performance. Computation performance needs to be further studied when we get more into the computation (path, virtual topology, scheduling, etc).

BACKUP

Basic NDL model

Query Examples Connection List query String selectStr = "SELECT ?resource ?object "; String fromStr="”; String whereStr = "WHERE {" + "?resource "+"ndl:connectedTo "+"?object”+ " }"; SubGrapgh query: String s ="SELECT ?a ?b ?c "; String ffromStr = ""; String whereStr = "WHERE {" + "(<"+url1+"> '[ndl:hasInterface]+/([ndl:hasInputInterface]|[ndl:hasOutputInterface])*/([ndl:linkTo]|[ndl:connectedTo])+/[ndl:interfaceOf]+' <"+url2+">) gleen:Subgraph (?a ?b ?c)”+ " }"; A complicated one: String selectStr = "SELECT ?intf ?intf_peer ?c ”; String whereStr= "WHERE {" + "?p a layer:AdaptationProperty. ”+ "<"+rsURI+">" + " ndl:hasInterface ?intf. ”+ "?intf ndl:connectedTo ?intf_peer." + "?intf ?p ?a.”+ "?intf_peer ndl:inConnection true."+ "?intf_peer ?l ?r."+ "?r rdf:type layer:Layer."+ "?intf_peer ndl:interfaceOf ?b.”+ "?b ndl:hasSwitchMatrix ?sw. "+ "?sw layer:switchingCapability ?c"+ " }";

G.809 -- Functional architecture of connectionless layer networks Rewrite of G.805, but for connection-less instead of for connection-oriented (transport) networks. The mapping is virtually one-to-one, though in G.809, all definitions are for unidirectional datastreams, while in G.805, most definitions are bidirectional

G.8010 ITU-T developed G.8010 to describe Ethernet networks in terms of G.805 like functional models Allows greater understanding of the distribution of network functions and how these are managed.

The ITU-T Ethernet network model (G The ITU-T Ethernet network model (G.8010) describes Ethernet as two layers: ETH and ETY (Packet, physical)

Functional modeling utilizes formalized techniques to allow provides the details necessary to understand the distribution of functions throughout a network. Function interactions fully understood from the network level Allows complete specification of equipment The network is fully manageable

References Michael Mayer, Functional Modeling for Synchronization Networks http://www2.theiet.org/OnComms/PN/communications/009%20-%20M%20Mayer.pdf