Changes between Initial Version and Version 1 of MAX-DesignUpdate

05/13/10 10:08:45 (9 years ago)
Vic Thomas



  • MAX-DesignUpdate

    v1 v1  
     1'''MAX.S2.i: Common Control Framework Design Update'''
     3We have continued our common control framework design approach that includes use of the PlanetLab GENI Control Framework and a specifically tailored MAX RSPEC to incorporate the unique features of the MAX Substrate. These unique features revolve around the integration of dynamic network provisioning with host-based resources like PlanetLab slivers.  Details of this RSPEC were presented earlier in this status report. 
     5The general approach for our common control framework interoperability is a MAX Aggregate Manager based on an open service interface using standardized web service mechanisms.  We feel that this will allow us to conform to any common control framework that may evolve from the multiple GENI Aggregate Managers under development.  As described above in the milestone MAX.S2.h (DRAGON Aggregate Manager Enhancement Initial Implementation) status, we now have the base implementation of a fully featured service interface for the MAX GENI Aggregate Manager that includes the following services:
     6 * !ListCapabilities
     7 * !ListNodes
     8 * !ListSlices
     9 * !CreateSlice
     10 * !DeleteSlice
     11 * !UpdateSlice
     12 * !StartSlice
     13 * !StopSlice
     14 * !QuerySlice
     15 * !CreateSliceVlan
     16 * !DeleteSliceVlan
     17 * !QuerySliceVlan
     18 * !CreateSliceNetwork
     19 * !DeleteSliceNetwork
     20 * !QuerySliceNetwork
     21 * !GetResourceTopology
     23It appears that currently a single GENI Common Control Framework is still under discussion and development within the community.  The start of an official API being defined here:
     24 *
     26The key services defined here are:
     27 * !ListResources
     28 * !CreateSliver
     29 * !DeleteSliver
     30 * !SliverStatus
     31 * !RenewSliver
     32 * !Shutdown
     34While we have slightly different names, we feel we do include all the functionality defined above in our aggregate manager service interface.  And as with the other aggregate manager development efforts, we have an extended set of capabilities in the form of more advanced and substrate specific services.  In general each aggregate is developing its own API that generally includes a more extensive list of services then those defined above. 
     36Our design approach for a common control framework is to develop our open service interface, publish the API, and demonstrate interoperability with other Aggregates.  In some cases these interoperability demonstrations will require translation between aggregate services interfaces.  We believe this will maximize the chance of an interoperable control framework evolving from the multiple aggregate service development efforts.  These interoperability demonstrations will be a focus of our efforts during the next reporting period.