Changes between Version 50 and Version 51 of NDL-OWL

Show
Ignore:
Timestamp:
02/22/11 17:26:15 (8 years ago)
Author:
yxin (IP: 152.54.9.71)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NDL-OWL

    v50 v51  
    22 
    33We describe the models in the life cycle of resource reservations and the resource allocation policy and stitching workflow implementation. The implementation details refer to the Camano generation of ORCA code. 
    4  
    5 = A. Models =  
    64 
    75We 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 [http://www.science.uva.nl/research/sne/ndl Network Description Language] using OWL.  We use a number of [wiki:OrcaNDL tools] to create and manipulate NDL-OWL ontologies. We deliberately stay away from the procedural programming model in favor of a more flexible semantic query-based programming approach to implement the policies for resource allocation, path computation, and topology embedding applications. 
     
    9492        This is used to describe the access method, state, and other post-configuration information of the reserved slivers. 
    9593 
    96 = B. Resource allocation and stitching policies = 
    97 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 core of the process is a reservation dependency workflow model. 
    98  
    99  == 1. Stitching Resource Components Information (Common Topology Schema Information) ==  
    100 The information should be obtained online when a substrate is stand up and contains two types of information: 
    101        * Domain network service. 
    102              * !AccessMethod: e.g. ORCAActor, or GENI AM API. 
    103              * Topology: Topology abstraction level exposed to outside. Right now, only node abstraction is defined. 
    104              * !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.    
    105              * !AggregateManager: e.g. the URL of its aggregate manager. 
    106        * Domain topology abstraction: Currently, the whole doman is abstracted to a node, a network device with following information: 
    107                * Switching matrix: capability (ethernet, IP, etc.), label swapping capability (means vlan translation for ethernet switching)  
    108                * Border interfaces: connectivity to neighboring domains, bandwidth and available label set (e.g. vlan)  
    109  
    110 == 2. Common Topology Schema definition == 
    111  
    112 == 3. AM API Extensions for Stitching == 
    113     * AM abstraction delegation: abstract rSpec. 
    114     * AM query: available resource 
    115     * AM sub-request redeeming: local provisioning  
    116  
    117 == 4. Stitching Workflow API Definition == 
    118     * Input: outputs of 5 and 6. 
    119     * Output: parent-children relationship in a dependency workflow DIG. 
    120  
    121 == 5. Stitching Path Computation API Definition == 
    122     *  Input: (source <resource type,units,IP address>, destination<resource type,units,IP address>, performance <layer,bandwidth,delay>, <source site>,<destination site>) 
    123     * Output: List of sites.  
    124  
    125 == 6. Stitching Topology Service API Definition == 
    126      * Input: (A collection of requested paths, A collection of available sites) 
    127      * Output: a collection of list of sites per path.