Experimenting with ontologies for multi-layer network slicing

1. Experimenting with ontologies for multi-layer network slicing Ilia Baldine YufengXin 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. 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

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

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 fromStr="”; String whereStr= "WHERE {" + "?p a layer:AdaptationProperty. ”+ "<"+rsURI+">" + " ndl:hasInterface ?intf. ”+ "?intfndl:connectedTo ?intf_peer." + "?intf ?p ?a.”+ "?intf_peerndl:inConnection true."+ "?intf_peer ?l ?r."+ "?rrdf:typelayer:Layer."+ "?intf_peerndl:interfaceOf ?b.”+ "?bndl:hasSwitchMatrix ?sw. "+ "?swlayer: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.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 • http://www2.theiet.org/OnComms/PN/communications/009%20-%20M%20Mayer.pdf