Version 26 (modified by yxin, 8 years ago)

--

We describe the models in the life cycle of resource reservations and the resource allocation policy and stitching workflow implementation.

A. Models

We need a set of unified semantic schemas for representing the data models needed in the life circle of resource reservation. We develop NDL-OWL - an extension of the Network Description Language using OWL. We use a number of tools to create and manipulate NDL-OWL ontologies. We are trying to stay away from the procedural programming model to a semantic query based programming approach to implement the policies for resource allocation, path computation, and topology embedding applications.

There are at least 5 types of models to be defined, that are circulated among the site authorities, broker and service manager.

1. Substrate description model

This is the substrate specific detailed resource and topology model that is used by the substrate manager to describe its physical resource including edge (compute and storage) resource and network topology. It also describes the domain service exposed to the broker.

a. Domain Service Description(domain.owl)

The class hierarchy is defined in the diagram ndl-domain.png. A substrate (domain) is defined as a collection of PoPs?. Each PoP, with a geographical location, is a collection of network devices and/or data center.

The Class domain also has a property NetworkService? which could have a number of ServiceElement?. This information would be passed to the advertisement RDF.

  • AccessMethod?: e.g. ORCAActor, or GENI AM API.
  • Topology: Topology abstraction level exposed to outside. Right now, only node abstraction is defined.
  • ResourceType?: This is inferred via a list of defined available resource label set, e.g. 32 VMs, 100 VLANS, that will be delegated to the broker.
  • AggregateManager?: e.g. the URL of its aggregate manager.

b. Compute Resource Description (compute.owl)

The class hierarchy is shown in ndl-compute.png. Three subclass hierarchies are defined here:

E.g. The ProtoGeniVNode class is defined as a VirtualMachine? that hasVMM VServer. It can be further constrained to hasVMIImage x and is a MediumServer?.

c. Network topology and resource description: extension of the original NDL

  • topology.owl
  • layer.owl
  • ethernet.owl,ip4.owl,dtn.own

2. Substrate delegation model

This is the abstract model that is used by the substrate manager to delegate its available services and resources to outsiders, the clearing house in the GENI context. This mode should allow multiple abstraction levels as different substrate manager may want to expose different levels of resource and topology description of its substrate. The model is obtained online when a substrate is stand up and contains two types of information:

  • Domain network service.
    • AccessMethod?: e.g. ORCAActor, or GENI AM API.
    • Topology: Topology abstraction level exposed to outside. Right now, only node abstraction is defined.
    • Resource Type: This is inferred via a list of defined available resource label set, e.g. 32 VMs, 100 VLANS, that will be delegated to the broker.
    • AggregateManager?: e.g. the URL of its aggregate manager.
  • Domain topology abstraction: Currently, the whole doman is abstracted to a node, a network device with following information:
    • Switching matrix: capability (ethernet, IP, etc.), label swapping capability (means vlan translation for ethernet switching)
    • Border interfaces: connectivity to neighboring domains, bandwidth and available label set (e.g. vlan)

3. Slice request model

This is used by the user, or the slice controller after interpreting the user's requests in ad hoc format, to describe the specifics of the user's request, often this is represented in the form of a virtual topology.

  • The topology request is defined a collection of bounded or unbounded connections. The end node of the connection can specify the amount of requested edge resource type (e.g. amount of VMs).
  • In redeeming the ticket to a specific site, the controller would dynamically create a sub-request to ask for a sliver.

4. Slice reservation model (Not implemented yet)

This is used by the clearing house (brokers) to return resource reservation description to the slice controller so that the controller can use to talk to related substrate manager to redeem tickets. This model should be able to describe the interdependency relationship among the slivers so that the controller can stitch to a slice.

5. Slice manifest model (Not implemented yet)

This is used to describe the access method, state, and other post-configuration information of the reserved slivers.

B. Resource allocation and stitching policies

Current implementation is based on a two-level resource allocation and stitching model: the controller and the broker policies do the cross-site path/topology computation/embedding and resource allocation based on the abstract delegation models. Upon reservation redemption, each site implements its own control policy to do intra-site sub-path/topology computation/embedding and resource allocation based on the its substrate RDF model. The whole process is based on a reservation dependency workflow.

  • Stitching Resource Components Information (=Common Topology Schema Information)

The information should bel obtained online when a substrate is stand up and contains two types of information:

  • Domain network service.
    • AccessMethod?: e.g. ORCAActor, or GENI AM API.
    • Topology: Topology abstraction level exposed to outside. Right now, only node abstraction is defined.
    • ResourceType?: This is inferred via a list of defined available resource label set, e.g. 32 VMs, 100 VLANS, that will be delegated to the broker.
    • AggregateManager?: e.g. the URL of its aggregate manager.
  • Domain topology abstraction: Currently, the whole doman is abstracted to a node, a network device with following information:
    • Switching matrix: capability (ethernet, IP, etc.), label swapping capability (means vlan translation for ethernet switching)
    • Border interfaces: connectivity to neighboring domains, bandwidth and available label set (e.g. vlan)
  • Common Topology Schema definition
  • AM API Extensions for Stitching

  • Stitching Path Computation API Definition
  • Stitching Topology Service API Definition

Attachments