Skip to content

Latest commit

 

History

History
209 lines (178 loc) · 10.2 KB

Ontology.md

File metadata and controls

209 lines (178 loc) · 10.2 KB
Raw

Ontology Notes

The handling of MRML ontologies can be complex when trying to map semantics through to a protocol such as NSI-CS. In addition, time can addle the minds of software developers, so keeping notes should help to refresh the memory before making modifications to the existing code base.

Building MRML topology documents

The SENSE-N-RM communicates with the NSI-DDS to discover the NML topology document associated with the networking domain being managed by the RM. Once discovered, this NML document is used to populate the fixed components of the MRML ontology. The dynamic NSI-CS reservations are also added to the MRML topology to provide a service topology.

  • nml:Topology

    • The nml:Topology resource is completely populated from data in the NML document.

  • nml:BidirectionalPort

    • The nml:BidirectionalPort resource is populated using three different pieces of information.
      • (1) The base nml:BidirectionalPort resource is populated exclusively from the NML document, with the nml:isAlias property populated by resolving unidirectional nml:PortGroup resource nml:isAlias properties within peer NML documents.
      • (2) Any nml:BidirectionalPort resource that is a child of an nml:BidirectionalPort resource is currently populated from NSI-CS reservation information, and represents the logical endpoint of a connection. This information is retrieved from the NSA using the NSI-CS query operation. If this nml:BidirectionalPort was created by the RM as the result of a reservation discovered on the NSA, then the URI for the resource, nml:name property, and mrs:tag property are generated by the RM.
      • (3) If this nml:BidirectionalPort was created by the RM as the result of an addition delta request from the SENSE-O, then the URI for the resource, nml:name property, and mrs:tag property are supplied in the SENSE-O request. These values are then stored in the SENSE-N-RM with a mapping to the created NSI-CS reservation so translation between the two protocol can be performed.

  • nml:LabelGroup

    • The nml:LabelGroup resource is populated for the nml:BidirectionalPort based on the nml:LabelGroup from the NML topology document using information contained in the unidirectional nml:PortGroup (or nml:Port) resource.

  • nml:Label

    • The nml:Label is populated with a single VLAN value associated with the child nml:BidirectionalPort it has a relationship with. This value can be populated one of two ways: (1) populated from NSI-CS reservation information when new reservations are discovered on an NSA, which therefore results in all properties of the resource being populated by the RM; (2) It is specified by the SENSE-O in a delta addition request creating a new mrs:SwitchingSubnet. These values are then stored in the SENSE-N-RM with a mapping to the created NSI-CS reservation so translation between the two protocol can be performed.

  • mrs:BandwidthService

  • mrs:SwitchingSubnet

  • nml:Lifetime

  • sd:ServiceDefinition

  • nml:SwitchingService

The SENSE-O to SENSE-RM protocol

The SENSE-O to SENSE-RM protocol is a polling based mechanism that utilizes the exchange of MRML topology documents, and delta requests with specify changes to the MRML topology. The initial topology is loaded by the SENSE-O from the SENSE-RM using a HTTP GET operation on the MRML topology endpoint. Changes to the topology are requested using POST operations on the deltas endpoint. The following endpoints are supported by the SENSE-RM:

/api/sense/v1/models
/api/sense/v1/models/{id}
/api/sense/v1/models/{id}/deltas
/api/sense/v1/models/{id}/deltas/{deltaId}
/api/sense/v1/models/{id}/deltas/{deltaId}/actions/commit
/api/sense/v1/deltas
/api/sense/v1/deltas/{deltaId}
/api/sense/v1/deltas/{deltaId}/actions/commit

/**

  • Returns a list of available SENSE topology models.
  • Operation: GET /api/sense/v1/models
  • @param accept Provides media types that are acceptable for the response.
  • At the moment 'application/json' is the supported response encoding.
  • @param ifModifiedSince The HTTP request may contain the If-Modified-Since
  • header requesting all models with creationTime after the specified
  • date. The date must be specified in RFC 1123 format.
  • @param current If current=true then a collection of models containing only
  • the most recent model will be returned. Default value is current=false.
  • @param encode Transfer size of the model element contents can be optimized
  • by gzip/base64 encoding the contained model. If encode=true the
  • returned model will be gzipped (contentType="application/x-gzip") and
  • base64 encoded (contentTransferEncoding= "base64") to reduce transfer
  • size. Default value is encode=false.
  • @param summary If summary=true then a summary collection of models will be
  • returned including the model meta-data while excluding the model
  • element. Default value is summary=true.
  • @param model Specify the model schema format (TURTLE, JSON-LD, etc.).
  • @return A RESTful response. */

MRML control over SENSE-N-RM resources

As described earlier, the SENSE-N-RM converts NML topology documents discovered through NSI to populate the fixed components of the MRML ontology. The dynamic NSI-CS reservations are also added to the MRML topology to provide a service topology. It is this dynamic service topology and associated meta-data that the SENSE-O can control through the model delta process. This results in two types of information within the SENSE-N-RM, resources related to the NSI-CS reservation and mapped directly to services in the network, and meta-data stored locally in the SENSE-N-RM that is annotated to NSI-CS reservation information to restore the original ontology model as requested from the SENSE-O. This meta-data information included subject names and annotating tags that are not storable in the NSI-CS reservation.

Handling MRML delta reductions

A delta reduction document sent from the SENSE-O to the SENSE-N-RM contains tuples that are to be removed from the current model. The reduction document is not an ontology, but a set of statements that may lead to an object being deleted from the current ontology, or represents properties that may be modified. In the example below, we see there is a subject, but there is no type for the resource, just three properties. This is an example of a model modification, in this case a bandwidth change on a mrs:BandwidthService resource. We know this is a mrs:BandwidthService resource because we look up the subject in the existing ontology (it should be there) and we can determine the type from returned resource.

<urn:ogf:network:es.net:2013::sunn-cr6:1_1_c3_1:+:conn+6af3a5f3-a3ec-4fee-ad6b-dc5fb9e7cb7b:vt+l2-policy-Connection_1:vlanport+1717:service+bw>
  <http://schemas.ogf.org/mrs/2013/12/topology#availableCapacity> "25000000000"^^xsd:long ;
  <http://schemas.ogf.org/mrs/2013/12/topology#maximumCapacity> "25000000000"^^xsd:long ;
  <http://schemas.ogf.org/mrs/2013/12/topology#reservableCapacity> "25000000000"^^xsd:long .

For completeness, we should see a similar entry in the delta addition specifying the new mrs:BandwidthService values.

<urn:ogf:network:es.net:2013::sunn-cr6:1_1_c3_1:+:conn+6af3a5f3-a3ec-4fee-ad6b-dc5fb9e7cb7b:vt+l2-policy-Connection_1:vlanport+1717:service+bw>
  <http://schemas.ogf.org/mrs/2013/12/topology#availableCapacity> "10000000000"^^xsd:long ;
  <http://schemas.ogf.org/mrs/2013/12/topology#maximumCapacity> "10000000000"^^xsd:long ;
  <http://schemas.ogf.org/mrs/2013/12/topology#priority> "0" ;
  <http://schemas.ogf.org/mrs/2013/12/topology#reservableCapacity> "10000000000"^^xsd:long .

If the target object does not exists within the ontology model then a delta:

  1. A subject in a reduction referencing a non-existing object in the ontology is an error;
  2. A subject in an addition referencing a non-existing object in the ontology results in a new object being created.

If the target object exists within the ontology model then a delta:

  1. Reduction removes an existing property (for example an mrs:tag);
  2. Addition adds a new property (for example an mrs:tag, or mrs:priority);
  3. Reduction/addition modifies an existing property (for example an mrs:tag, or mrs:priority, or mrs:availableCapacity).

We can specify a simple modification algorithm to be:

variable m is the ontology model specified by the delta;
variable r is the current reduction;
variable a is the current addition;

foreach Subject s in r {
  if s is not contained in m {
    return error "s is not a valid subject in model m";
  }

  if s is contained in a {
    // The object identified by the subject exists after the delta so we can
    // consider this a modification operation. How property statements listed
    // in the reduction will be removed from the model is dependent on the
    // type of object being reference and the mapping to the NSI-CS protocol.
    // For example, if a mrs:tag statement is being removed from ab object then 
    // this is a model local value that is stored in the RM database so this
    // is a simple update.  If the delta is a service bandwidth change on an
    // mrs:BandwidthService resource then the mrs:MaximumCapacity property
    // with the original value will be listed in the reduction, and will be 
    // listed with the new value in the addition. 
    modify(m, r, a);
  } else {
    // The object identified by the subject does not exist after the delta
    // so we can assume this is a delete operation.  How property statements 
    // listed in the reduction will be removed from the model is dependent on 
    // the type of object being reference and the mapping to the NSI-CS protocol.
    // For example, a deletion of a mrs:SwitchingSubnet will result in the
    // termination of the corresponding NSI-CS reservation, and removal of
    // all associated VLAN ports, lifetime objects, etc from the model.
    delete(m, r);
  }
}

foreach Subject s in a {
  if s is not contained in m {
    // We have an addition of a new object to the ontology.
  } else {
    // We have a modification scenario.
    if s is contained in r {
      // The object is being modified.
      modify(m, r, a);