Changes between Version 64 and Version 65 of NDL-OWL

Show
Ignore:
Timestamp:
02/24/11 18:34:50 (8 years ago)
Author:
chase (IP: 152.54.6.232)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NDL-OWL

    v64 v65  
    11= NDL-OWL Models in ORCA = 
    22 
    3 We describe the models in the life cycle of resource reservations (leases) and the resource allocation policy and stitching workflow implementation. The implementation details refer to the Camano release of ORCA code. 
     3This page describes the semantic web models used in the life cycle of resource reservations (leases), and in ORCA implementations for resource allocation policy and stitching workflow. The implementation details refer to the Camano release of ORCA code. 
    44 
    5 We need a set of unified semantic schemas for representing the data models to describe resources in a reservation across the stages of its life cycle. 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. NDL-OWL gives us a flexible semantic query-based programming approach to implement the policies for resource allocation, path computation, and topology embedding applications.  It enables these functions to be coded generically to operate on declarative specifications, rather than baking in assumptions about the resources. 
     5We use a set of unified semantic schemas (ontologies) for representing the data models to describe resources in a reservation across the stages of its life cycle. 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. NDL-OWL gives us a flexible semantic query-based programming approach to implement the policies for resource allocation, path computation, and topology embedding.  It enables these functions to be coded generically to operate on declarative specifications, rather than baking in assumptions about the resources. 
    66 
    77There are at least 5 types of models to be defined.  ORCA actors (authority/AM, broker and slice manager/SM) pass these representations as they interact to stand up reservations at multiple substrate aggregates and stitch them into an end-to-end slice. 
    88 
    99== 1. Substrate description model == 
    10 This is the detailed resource and topology model that is used by the owner of the substrate to describe its physical resources including edge (compute and storage) resource and network topology.  ORCA AMs use this model to drive their internal resource allocation policies and resource configuration (setup/teardown handler invocations).  The model also specifies which elements of the structure are exposed externally (e.g., in resource advertisements or delegations), and which are kept hidden.  
     10This is the detailed resource and topology model that is used to describe a physical substrate including network topology and edge resources (compute and storage).  ORCA AMs use this model to drive their internal resource allocation policies and resource configuration (setup/teardown handler invocations).  The model also specifies which elements of the structure are exposed externally (e.g., in resource advertisements or delegations), and which are kept hidden.  
    1111 '''a. Domain Service Description ([source:orca/trunk/network/src/main/resources/orca/network/schema/domain.owl domain.owl])'''  
    1212      The class hierarchy is defined in the diagram below. A substrate (domain) is defined as a collection of !PoPs. Each PoP has a geographical location and a collection of network devices and/or edge resources (e.g., a cloud provider site). The Class ''Domain'' also has a property ''!NetworkService'' which could have a number of ''!ServiceElement''.  The ServiceElements will be made visible in external advertisements (see below). 
     
    3232                 * Vendor 
    3333        * !ComputeElement 
    34                 * !ClassifiedServer : defined by the serverSize and using popular cloud provisioning technologies. Each can be distinguished by number and type of CPU cores, amount of RAM or storage and support for different virtualization technologies 
     34                * !ClassifiedServer : defined by the serverSize and using popular cloud provisioning technologies. Each can be distinguished by number and type of CPU cores, amount of RAM or storage and support for different virtualization technologies. 
    3535                     * !LargeServer  
    3636                     * !MediumServer 
     
    7272 
    7373== 2. Substrate delegation model == 
    74         This is the abstract model to advertise an aggregate's resources and services externally.  ORCA AMs use this representation to delegate advertised resources to ORCA broker(s).  AMs may also use this representation to describe resources in response to queries (e.g., ListResources) or to advertise resources to a GENI clearinghouse.  This mode should allow multiple abstraction levels, as different AM may want to expose different levels of resource and topology description of its substrate.  The model is generated automatically from the substrate description model (above) when a substrate stands up.  The model contains two types of information: 
     74        This is the abstract model to advertise an aggregate's resources and services externally.  ORCA AMs use this representation to delegate advertised resources to ORCA broker(s).  AMs may also use this representation to describe resources in response to queries (e.g., ListResources) or to advertise resources to a GENI clearinghouse.  This mode should allow multiple abstraction levels, as different AMs may want to expose different levels of resource and topology description of its substrate.  The model is generated automatically from the substrate description model (above) when a substrate stands up.  The model contains two types of information: 
    7575       * Domain network service. 
    7676             * !AccessMethod: e.g. ORCAActor, or GENI AM API. 
     
    7878             * !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.    
    7979             * !AggregateManager: e.g. the URL of the AM. 
    80        * Domain topology abstraction: Currently, the whole domain is abstracted to a node, a network device with following information: 
     80       * Domain topology abstraction: Currently, the domain's topology is abstracted to a node, a network device with following information: 
    8181               * Switching matrix: capability (ethernet, IP, etc.), label swapping capability (i.e., VLAN translation for ethernet switching)  
    8282               * Border interfaces: connectivity to neighboring domains, bandwidth and available label set (e.g. VLAN)  
     
    8585 * [source:orca/trunk/network/src/main/resources/orca/network/schema/request.owl request.owl] 
    8686         
    87         This defines a top-level ''Reservation'' object to describe a particular lease reservation (term, etc.).  
    88         It describes the specifics of the user's request.  Often this is represented in the form of a virtual topology with specific resources at the edges.  It might be generated by unspecified experiment control tools.  In our implementation, it is generated by a controller module in the slice manager (SM) after interpreting the user's request in an ad hoc format. 
    89          In our current implementation for the multi-domain setting, this SM controller performs inter-domain path or topology computation and automatically breaks the user request into domain-specific sub-requests.         
     87        This is the abstract model to represent user resource requests.  
     88        A typical request might be a virtual topology with specific resources at the edges, generated by unspecified experiment control tools.  In our implementation, the representation is produced by a controller module in the slice manager (SM) after interpreting the user's request in an ad hoc format. 
     89         In the current implementation for the multi-domain setting, this SM controller performs inter-domain path or topology computation based on a description of the global topology, and automatically breaks the user request into sub-requests for each domain.         
    9090 
    9191        * The topology request is defined as a collection of bounded or unbounded connections. The end node of the connection can specify the amount of requested edge resource type (e.g. number of VMs or other slivers).  
     
    9393 
    9494== 4. Slice reservation model (Not implemented yet) ==  
    95         This is used by the clearing house (brokers) to return resource reservation description to the SM controller so that the controller can use it 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. 
     95        This is the abstract model used by ORCA brokers to return resource tickets to the SM controller.  Each ticket contains a specifier for one or more slivers from a single AM named in the ticket.  The SM controller obtains the slivers by redeeming these tickets to the AMs ('''redeem tickets''').  This model must describe the interdependency relationships among the slivers so that the SM controller can drive stitching for each sliver into the slice. 
    9696   
    9797== 5. Slice manifest model (Not implemented yet) == 
    98         This is used to describe the access method, state, and other post-configuration information of the reserved slivers. 
     98        This is the abstract model to describe the access method, state, and other post-configuration information of the reserved slivers. 
    9999