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

2. 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

3. 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.

4. Slicing a network

5. 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

6. Link slivering

7. 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)

8. 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

9. 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

10. G.805 example

11. 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

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

13. 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

14. 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

15. 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

16. 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

17. 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).

18. BACKUP

19. Basic NDL model

20. 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"+
" }";

21. 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

22. 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.

23. 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)

24. 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

25. References
Michael Mayer, Functional Modeling for Synchronization Networks