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 – 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) https://forge.gridforum.org/sf/projects/nml- wg

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 http://www.itu.int/rec/T-REC/e

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. BEN, ITU G.805, and NDL ITU G.805: Network elements Functional elements Ontology – Topology Connectivity and switching capability – Cross-layer adaptation, aggregation, and capacity – Logic constraints and path computation – It’s complex and abstract, but powerful and modular NDL is a set of ontology based on G.805 – Resource description with focuses on connectivity and cross-layer adaptation description – RDFS/XML – Modular design BEN: Cross-layer transport network – VLAN->GE Ethernet->10G Ethernet->Lambda->OCG->Fiber – VLAN->Ethernet->DTN bandwidth pool (bandwidth virtualization) – Switching: Fiber, OCG, Lambda, Sub-Lambda, Ethernet – Possible multiple end-to-end paths cross different layers – So complex that an abstract model is desired

14. RDF vs plain XML RDF advantage: – 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

15. RDFS: Simple semantics Class and Property hierarchy statements ->Graph XML: data types No semantic meanings OWL: description logic Relations (disjointness,symmetric), cardinality, enum,etc SPARQL: Query path query Reasoner: Inference engine rules Java API and tools: Builder: Protégé API: Jena Semantic Web: from RDF to OWL to Inference

16. Where we are: NDL-OWL 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

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

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

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

20. BACKUP

21. Basic NDL model

22. 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 {" + "( '[ndl:hasInterface]+/([ndl:hasInputInterface]|[ndl:hasOutputInterface])*/([ndl:linkTo]|[ndl:connectedTo])+/[ndl:interfaceOf]+' ) gleen:Subgraph (?a ?b ?c)”+ " }"; A complicated one: String selectStr = "SELECT ?intf ?intf_peer ?c ”; String fromStr="”; String whereStr= "WHERE {" + "?p a layer:AdaptationProperty. ”+ " " + " 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"+ " }";

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

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

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

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

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