| | 1 | '''MAX.S2.i: Common Control Framework Design Update''' |
| | 2 | |
| | 3 | We 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. |
| | 4 | |
| | 5 | The 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 |
| | 22 | |
| | 23 | It 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 | * http://groups.geni.net/geni/wiki/GAPI_AM_API |
| | 25 | |
| | 26 | The key services defined here are: |
| | 27 | * !ListResources |
| | 28 | * !CreateSliver |
| | 29 | * !DeleteSliver |
| | 30 | * !SliverStatus |
| | 31 | * !RenewSliver |
| | 32 | * !Shutdown |
| | 33 | |
| | 34 | While 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. |
| | 35 | |
| | 36 | Our 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. |
