Changes between Initial Version and Version 1 of GeniOmisUseAssumptions


Ignore:
Timestamp:
04/24/08 21:10:30 (16 years ago)
Author:
Mike Patton
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeniOmisUseAssumptions

    v1 v1  
     1= OMIS Use Case Assumptions =
     2
     3These are (some of) the assumptions that were made about GENI operations for the [GeniOmisUseIntro OMIS Use cases].  As these assumptions evolve with the design they form a list of requirements for the facility.
     4
     5 * Aggregate Operations monitor their own components in whatever way they choose, so that they notice if the components they are providing go down or behave in some way that Agg Ops themselves have defined as not acceptable.  Note that this behavior can be defined without any reference to slices or slivers whatsoever.  In this example, the criteria might be that Agg Ops decides no CPU in a cluster should run at higher than 90% utilization, or they notice that some process is spewing packets at a rate that's overloading the isolation filtering.
     6 * Aggregate Operations can map the slivers on any of its components to the GENI slice that is using the components at any point in time.  (The architecture says that the CM binds the resource request (in an RSpec) to the slice ID when a "ticket" is redeemed, making a slice "active." so we require this state to be preserved somehow.)
     7 * GENI Ops staff have a "secure enough" way to identify who they are, for example an electronic key, and that appropriate key registry service exists.  There also needs to be some way for Component Managers, Slice Authorities (and other things?) to verify that a particular key belongs to someone with NOC privileges.  In fact, there probably needs to be a general "group" or "role" feature that can securely chain credentials and associated privileges.
     8 * Properly authenticated GENI Ops staff can:
     9  * map any slice to the component managers that granted resources to that slice.
     10   * Remember that a CM can actually "front" for several components if Agg Ops decides to handle their network that way, so GENI Ops can't necessarily know which physical components are in a slice.  However, in certain discussions it's been suggested that when a ticket is redeemed the ''actual'' resources assigned need to be returned, and should presumably also be entered in the Slice Registry.  The exact details are still '''to be resolved'''.
     11  * query a CM to ask for the mapping of resources to a slice at that point in time, and/or issued, but not yet redeemed tickets for some future time.
     12  * look up contact information for the responsible parties for any slice in the slice registry.  This information was collected and correllated when the researcher created their slice.
     13 * GENI Ops has defined parameters that indicate "acceptable" operation criteria for each slice.  These could be simply verifying that the slivers are all active, or it could be more complicated, such as verifying that end-to-end delays do not exceed some maximum in a sliver.  Defining these parameters is a use case in itself.  Note that you could envision GENI Ops without this function, in which case GENI Ops would just respond to reported problems instead of continuously monitoring, but that use case is easier, so we're leaving it out for now.
     14 * Similarly, GENI Ops has defined conditions under which a slice should be shut down (for example, if it is consuming more than its share of a scarce resource.)  These conditions could be set uniformly for all slices, or could be variable for different slices, depending on GENI policy.  However, the conditions should be considered in advance, and documented in policy, rather than decided on the fly.
     15 * GENI Ops has a trouble ticket system that allows operations staff to record events and make that information available to the GENI community.  (For example, the TRAC ticket system on the GENI wiki).  Some required features from the Use Cases:
     16  * The ticket system needs some automated way to provide all the data to open the ticket.
     17  * There needs to be a way to correlate outages to the slices and components affected, and to retrieve a list of parties interested in receiving tickets about those.  Conversely, there needs to be a way for any party to express interest in tickets on any slice and/or component.