GENI Aggregate Manager API Draft Revisions

This page documents DRAFT revisions to the GENI Aggregate Manager API, proposed for the next version of the API. As indicated below, some of the revisions documented here have been discussed on the GENI developer mailing list, and during at least one GEC. Other revisions are in early discussions and subject to change or abandonment.

The GENI Aggregate Manager API allows aggregates to advertise resources and to allocate resources to Slices in the form of Slivers. A Sliver is a set of resources allocated by one Aggregate to one Slice. See below for a proposed complete definition.

The current officially adopted version of the API is 3 and is documented on the main API page.

API Version 3 was adopted based on changes previously listed on this page. Those changes have been removed from this page, and are now documented on a separate page. They are detailed below.

API Version 2 was adopted based on changes previously listed on this page. Those changes have been removed from this page, and are now documented on a separate page. They include:

1. RSpec related changes, specifying that RSpecs are XML following GENI standard schemas.
   • Since June 2011, the latest software from ProtoGENI and SFA (as of code tag 1.0-24) has complied with these changes.
   • Omni version 1.3 (released June 2011) added client software support for these changes.
2. Supporting flexible arguments and returns. Specifically, adding a property list to all calls, and making all returns be a property list.

This page documents proposed changes for AM API version 4. These changes are grouped into sets. API Version 4 will be the collection of changes from the change sets below which we next agree on. Change sets still under discussion will then be targeted at a future release.

Proposing Additional Changes

GENI community members are encouraged to propose changes to the GENI Aggregate Manager API.

Technical discussions are generally held on the ​Developers mailing list

Specific questions may be directed to the software team at the GPO (Tom Mitchell, Aaron Helsinger, and Sarah Edwards) at {tmitchel, ahelsing, sedwards} at geni.net

Change Sets Adopted in GENI Aggregate Manager API version 3

Version 3 has been adopted.

Details of the change sets included in AM API version 3 are at the v3 Deltas page.

Proposals adopted after GEC13:

• Change Set D: Slivers: Change methods to clarify that there may be multiple slivers per slice at an AM, and to allow operating on individual slivers
• Change Set F3: Sliver Allocation States and methods
• Change Set F4: Method to perform Sliver Operational actions
• Change Set F5: Sliver Operational States
• Change Set M: New method signatures, incorporating all previous adopted change sets

Proposals adopted at GEC13:

• ADOPTED: Change Set G: Generalize the credentials argument, allowing ABAC support
• ADOPTED: Change Set I1: SliversStatus return structure includes sliver expiration
• ADOPTED with changes: Change Set I2: SliversStatus return includes SSH logins/key for nodes that support SSH access
• ADOPTED: Change Set I3: CreateSlivers return becomes a struct, adds sliver expiration
• ADOPTED: Change Set K: Standardize certificate contents, etc.
  • Include a real serial number, holder email, holder uuid, and optionally authority URL in certificates
  • Define slice ID as the UUID plus URN in slice certificates
  • Define slice name, sliver name, and user name restrictions, and similar for URNs
  • Publish schemas for credentials and certificates

Proposed Changes for GENI Aggregate Manager API version 4

From the below, Change Sets C, N, O, P, Q and R have been adopted. These will be required in AM API version 4, and may optionally be implemented in earlier AM API implementations. For details, see the Adopted changes page.

Change Set C: Update()

This change was adopted at the GEC15 coding sprint for inclusion in API v4. Aggregates are permitted to include this method in the API v3 implementations. See the Adopted Changes page.

Change Set N: Add information to GetVersion

This change set adds some additional information to the return from GetVersion.

This change set was discussed at the GEC15 coding sprint and adopted at GEC19. Aggregates may implement this as part of their AM API v3 implementation, but will be required to do so as part of AM API v4. For details, see the Adopted changes page.

Change Set O: Refine character restrictions

This change set was discussed at the GEC15 coding sprint and adopted at GEC19. Aggregates may implement this as part of their AM API v3 implementation, but will be required to do so as part of AM API v4. For details, see the Adopted changes page.

Change Set P: Support proxy clients that 'Speak For' an experimenter

This change set was adopted at GEC19. This functionality may be implemented in AM API v2, and is required in AM API v4. For details, see the Adopted changes page.

Change Set Q: Support changing users and keys on existing compute slivers

This change set was adopted at GEC19. For details, see the Adopted changes page.

Change Set R: Allow Renew to extend slivers as much as possible

Adopted at the GEC 18 Coding Sprint. For details, see the Adopted changes page.

Change Set S: More info from GetVersion

GetVersion should return an additional field indicate the URN of the Aggregate Manager at this endpoint. This corresponds to the URN in the SubjectAltName of the certificate of the aggregate, or the URN that the aggregate uses if reporting slivers to the Federation SA API (and this URN also determines the authority portion of the URN for any slivers issued by this aggregate). For aggregates that have a single component manager, then this is likely the component_manager or component_manager_id from the advertisement RSpec produced by this aggregate (which in turn determines the authority portion of related component_id URNs). Aggregates which have multiple component managers must select a single AM URN, which may be the same as one of the component manager URNs.

Proposal: GetVersion adds the field geni_am_urn whose value is an XMLRPC string containing the URN of the aggregate manager running at this XMLRPC endpoint. This field is required as of AM API version 4, optional earlier.

Change Set T: Long Lived Slices

This proposal provides a way to support long running experiments that require slices and resource reservations with long lives. This proposal requires changes to Slice Authorities and aggregates.

This topic was raised at the GEC18 Coding Sprint.

The original proposal would add a new privilege to existing slice credentials meaning that the SA says reservations in this slice should be 'long', with the meaning (length of reservation) up to individual aggregates.

Other proposals have been surfaced, including having aggregates sign credentials to users rather than the SA.

The topic was later discussed at GEC19. The proposal described below was agreed to in principle, with details to be specified.

Proposal:

Use the extensions field of the existing slice credential schema, to add an extension specifying the number of days that reservations in this slice should be good for. The presence of this extension in the credential indicates that the issuer believes that when receiving this credential in a createsliver or renew or provision request, the aggregate should reserve the requested resources for the given number of days (up to the slice expiration as usual), independent of typical local AM policy or resource specific policy. Aggregate local policy will determine what the aggregate actually allows, but policy for a specific GENI federation may require aggregates to follow this extension when found in a slice credential issued by the federation slice authority. The proposal does not specify how the issuer decides to include this privilege extension. Requesting a credential for such a slice results in a slice credential that adds this privilege.

Credentials containing this extension will typically be issued by the slice authority as the single slice credential, retrieved by clients requesting a slice credential. Aggregates are free to issue their own similar credentials, that only they are likely to honor.

At an aggregate honoring this extension, on initial provision/createsliver the resource should expire after the minimum of the slice expiration and now+the number of days specified in the credential. On renew the resource should be renewed until the minimum of the requested date, the slice expiration, and the current date plus the # of days in the slice credential.

The extension for specifying this: ​http://www.protogeni.net/resources/credential/ext/policy/1/policy.xsd

This change requires aggregates to accept and handle these new credentials when issued by a trusted authority.

Change Set U: Scheduling

The ability to schedule resource reservations in the future has been discussed multiple times as desirable. This proposal would add support in the AM API to allow aggregates to provide this ability.

This proposal is incomplete and requires further discussion.

An Analogy

First, an analogy to reserving a table at a restaurant:

The current AM API does not support reservations - we only support walk-ins. In AM API v2, we support "Can I have a table?" (Createsliver), with the possible answers "No" or "I'll bring you your menus."

In AM API v3, we support "Can I have a table?" (Allocate) with the answers "No" or "I have a table free, would you like it?". Then the experimenter can say "No" (Delete) or "Yes, I'll take it" (Provision), or "Can you give me a minute to consult with my friends?" (Renew)

With this proposal, we want to support reservations:

Experimenter: Can I have a table on Tuesday? (Allocate)

Aggregate: I have a table by the door, would you like it?

• And the restaurant will not give away that table until the experimenter answers, but only waiting a short time.

E: Give me a minute to consult? (Renew)

or

E: No thanks (Delete)

or

E: Yes, please reserve that table for me on Tuesday. (Provision?)

Then when Tuesday rolls around, the restaurant will only hold the table for a limited time.

E: I'm here, ready to sit down. (Provision? PerformOperationalAction of geni_start?)

or

E: Never mind, I don't want the table. (Delete)

Or the experimenter doesn't show up, and the reservation "expires" and the restaurant is free to give the table away.

Goals

• Experimenters can specify both start and end time for when they want resources
• Experimenters must commit to using the resources, so that aggregates are not holding resources that the experimenter will never use
• Experimenters know when they have the resources
• Experimenters know how long they may be able to hold the resources, and when the resources are likely taken by someone else
• Support for scheduling is optional

Proposal

• Allocate takes both a geni_start_time (new) and geni_end_time (already allowed).
  • The geni_start_time option to Allocate indicates when the experimenter wants the reservation to start. The semantics are such that the aggregate may give the client the resources early, or up to 10 minutes later than requested, but no more. If the aggregate cannot reserve the requested resources for the client within that time window, then the request must fail with the error code indicating the resources are UNAVAILABLE. Aggregates may include in the error some message indicating if a slightly different start time would succeed, if known.
  • Aggregates that do not support scheduled reservations will ignore this option, always treat the request as a request for resources now. Clients may examine the return from Allocate to and see that geni_start_time and geni_end_time is not specified in the return, indicating that this is not a scheduled reservation, but an immediate reservation.
  • Note that geni_start_time is not an option to Provision

• Add a geni_max_expiration field wherever we currently return a sliver expiration. This is advisory, indicating the latest datetime that you should expect to be able to renew your reservation until. This may be based on local aggregate policy only, or based on known other scheduled future reservations for the same resource(s). Note though that this is not a guarantee: a request to extend a reservation up until this time may still be denied (other resource reservations that come in in the interim for example), and it is even possible that a request to renew past this time might succeed, though clients should not expect this.

• Add a geni_start_time field to the return wherever we currently return a sliver expiration. This field is required only for reservations that begin in the future.

• geni_expires is slightly redefined. This now indicates the end of the time window in which you must act on the sliver(s) / reservation, or else the slivers will expire and be given to others. This is consistent with how the field is used by aggregates that do not support scheduling today. Aggregates that do support scheduling however will use this and a new option.

• Add a geni_end_time return element wherever geni_expires is returned, to be required only for aggregates that support scheduling, and only when both a geni_start_time and geni_end_time was supplied in the original reservation request. This element specifies the time at which the reservation has been requested to end. For example, geni_start_time might be tomorrow at 1pm, geni_end_time might be tomorrow at 3pm, and `geni_expires might be 10 minutes from now. This indicates that the client has 10 minutes in which to confirm the reservation for resources tomorrow from 1 to 3pm.

• After Allocate, scheduled requests are geni_allocated as before. As before, such slivers have a short expiration time (given in geni_expires), during which time Delete and Renew are both valid.
  • Renew does not change the requested start and end times of the reservation, it only extends the time window in which the client must confirm the reservation. To change the requested start or end times of an allocated reservation, use Update, or call Delete and then Allocate.
  • Experimenters must call Provision as before (arguments are unchanged) to confirm the reservation during this time window (before geni_expires).
    • If the client does not call Provision during that time window, the slivers expire and the reservation is cancelled.
    • If the client does call Provision for a reservation in the future (has a geni_start_time), then the sliver(s) transition to the new geni_scheduled state. The aggregate does not begin instantiating the resources at this point. The aggregate only changes the state of the slivers and the geni_expires time at which the slivers will expire (see below).

• Add a new geni_scheduled allocation state after geni_allocated and before geni_provisioned. Slivers in this state are being held for the client for some future time. The client has already confirmed that they want the resources as promised, but the requested start time has not arrived or the experimenter has not confirmed that they are ready to start using their reservation. This state is only used by aggregates that support scheduling and only for requests for resources in the future.
  • While in this state, the client may call Describe, Status, Delete, or Update. Renew is not legal on slivers in the geni_scheduled state: aggregates may raise an error, or simply return the existing expiration times and states.
    • Update moves the slivers to the geni_updating state; clients must confirm the new request with a new call to Provision before the time in geni_expires, or else the update request expires, the slivers return to the geni_scheduled state, and the reservation remains unchanged. Regardless of the specified geni_start_time, resources will not be instantiated until the slivers move out of the geni_updating state. Update may be used to request a change to both what resources are reserved, and the requested geni_start_time and geni_end_time.
  • When Provision is used on geni_allocated slivers with a geni_start_time in the future, it moves the slivers to the geni_scheduled state. The return must include geni_start_time, geni_end_time, and geni_expires. geni_end_time is the end of the requested reservation window. geni_expires is a time some small delta after the geni_start_time. This indicates the time at which the slivers will expire, if the client has not claimed the slivers with a second call to Provision.

• When the geni_start_time arrives, the client must call Provision (arguments are unchanged), indicating the client is ready to use the resources. Only at this point does the aggregate begin to instantiate the resources. The slivers become geni_provisioned as before.
  • If the client does not call Provision before the sliver expiration time given in geni_expires, then the slivers expire and become geni_unallocated (as before).
  • Renew has no effect on slivers that are geni_scheduled.

• Update on slivers that are already geni_provisioned will not change the geni_start_time. It may request a change to the geni_end_time, along with changes to what resources are reserved.

Questions

• Is there any way to query the reservation schedule of a particular resource?

Change Set V: Create and Manage Disk Images

This proposal would allow creating, listing and deleting disk images based on the state of existing disks in your slice at an aggregate.

This proposal is based on the functionality exported by ProtoGENI based aggregates. FIXME: This proposal must be made more generic.

Some general notes:

• Disk images are typically created with snapshots of the disk of an existing compute resource. At some aggregates this might disrupt the state of the compute resource.
• Images exist local to an aggregate: They are created, listed and deleted at a particular aggregate
• Images are identified by a URN. At some aggregates, they are also identifiable by a URL (for purposes of exporting an image to another aggregate)
• Exporting an image to another aggregate involves copying the image from one aggregate to another.
  • Not all aggregates will support exporting images
  • An image imported from another aggregate may not function at the new aggregate (due to hardware differences, etc)
  • Once imported, the disk image now exists local to the new aggregate as well

FIXME

• Add a separate SERVICE indicating if images are exportable to other aggregates (EXPORT_IMAGES?)
• Define rules for legal disk image names
• Define URL rules for exporting images
• Define authorization rules for deleting and listing images
• Are exportable images always public? Or does public only control what is listable?

CreateImage

Create a disk snapshot or image based on the state of the disk for an existing sliver.

Arguments:

• slice URN
• name for the image: An alphanumeric non empty string
• sliver URN of the machine whose disk should be snapshotted
• credentials giving the caller rights on this slice
• options
  • The option global defines whether this image will be publicly visible or not. The value is an XML-RPC boolean indicating whether the image should be public, defaulting to False meaning private to your project or sub-SA. "Private" images are visible and usable by any experimenter in the same project (or sub slice authority) at this aggregate. "Public" images are usable by anyone with the URL or URN of the image.

Returns:

• URN naming the new image. The image URN looks like urn:publicid:IDN+<aggregate authority>+image+<aggregate authority with punctuation replace by hyphens>:<image name supplied in the argument>, for example urn:publicid:IDN+foo.net+image+foo-net:booboo.
• URL for referencing the image, for use at other aggregates, for example: https://www.foo.net/image_metadata.php?uuid=c0b47d37-f6cd-11e1-9f72-001143e453fe

Image names must be unique at this aggregate. If an image of the same name already exists and is "owned" (was created or imported by this user), then this image replaces the previous image of the same name. For other experimenters, this method shall return an error code BADARGS indicating that the image name is taken.

If local policy determines that this experimenter or project or slice has exceeded some quota on number of images or disk space, then this command may fail with an error message explaining the issue (code 2 or 7).

This function should return quickly, asynchronously snapshotting the disk. While the disk is being snapshotted, do not modify the state of your VM - results will be unpredictable.

Only slivers in the geni_ready state may be imaged. While the image is being created, the sliver will be in a new operational state, geni_imaging. While the sliver is in this state, no operational actions are permitted, and at some aggregates, the sliver may be inaccessible. Note that at some aggregates, creating an image may disrupt the running and state of the resource. When imaging is complete (successfully or due to error), the operational state transitions back to geni_ready.

The aggregate will contact the user who created the snapshot, typically at the email address found in the user's certificate, providing status and results.

DeleteImage

Delete the named disk image owned by / created by the named user.

Arguments:

• image URN
• credentials, including a valid slice credential for any slice in the same project / sub-slice authority as the slice from which the image was created (or imported)
• options
  • creator_urn: image creator URN (a valid "user" URN). If not supplied, the current user is assumed

Return: XML-RPC boolean for success. On error, return codes include SEARCHFAILED, FORBIDDEN and ERROR.

Only users in the same project / sub-Slice Authority may delete an image (as authorized by the supplied slice credential).

Note that the experimenter who created the image locally or imported it from another aggregate is the image 'creator' for purposes of this method.

ListImages

List the disk images created by the given user at the aggregate you are calling.

Arguments:

• creator URN
• credentials, including optionally a valid slice credential for the project / sub-slice authority whose images you want to list
• options

The creator URN must be from the same authority as the caller (i.e. the portion of the user URN before user must be identical).

Note that the experimenter who created the image locally or imported it from another aggregate is the image 'creator' for purposes of this method.

Return: a list of structs, each containing the url and urn of the images at this aggregate. Note that only public images will be provided in general, plus images in the same project / sub-slice authority as the slice whose valid slice credential was supplied will be listed.

 [ 
   {"urn" => <image_urn>,
    "url" => <image_url>
   },
     ....
 ]

Only users in the same project / sub-Slice Authority may list private images (as authorized by the supplied slice credential).

FIXME: Are those the right authorization rules?

Image URN type

This proposal introduces a new "type" of URN, image, to be used to name disk images.

FIXME: Restrictions on the characters legal in the name of an image or image name length?

• Image names should begin with a letter and be alphanumeric or underscore, hyphen, at sign or period: ('[a-zA-Z][a-ZA-Z0-9\-_@\.]{0,63}$').
  • FIXME: PG uses ^[a-zA-Z0-9][-\w\.+]+$
• Image names are limited to 64 characters.
• The authority in an image URN is the aggregate hosting the image

Import Disk Images

A disk image that was created / is stored at one aggregate may be used at another aggregate, if the source aggregate supports it, and if the new aggregate accepts a URL for disk images in the request RSpec. If both are true, then an experimenter may specify this remote disk image by URL in the name slot of the disk_image element in a request RSpec. The aggregate exporting the image serves up the image at the URL. The aggregate importing the image:

• May fail the import if imports are not supported, or local policy prohibits, or local disk space or quotes are exceeded
• Stores the image locally
• Gives it a local name / URN, locally unique
• Lists the experimenter who imported the image as the image 'creator'
• Associates the image with the project/sub slice authority of the slice for which the image was imported
• FIXME: Makes the image public? Private? Does the experimenter get to say or change it?
• Contacts the 'creator' with the new URN and URL for the local copy of the image (typically via email)

When an image is imported to another aggregate, the experimenter that imports the image is treated as the local image "creator", and the slice in which they import the image determines the local project / sub-slice authority for controlling local access to the image.

This proposal does not specify how aggregates manage local disk space or might limit the number of disk images a particular experimenter or project can have. Importing a disk image therefore might fail due to local AM policy. Additionally, disk images might 'expire' at certain aggregates. This proposal does not specify this one way or another.

Change Set W: Rename fields to drop geni prefix

In the interest of making this API better apply to international federations, change all options and return elements that are currently named geni_foo to just plain foo. Non standard options and return elements should use a local aggregate type specific prefix.

That is, where the spec currently says:

The prefix geni_ is reserved for members that are part of this API specification. Implementations should choose an appropriate prefix to avoid conflicts.

Instead, it should say:

Implementations may add additional options or return elements that are not standard to this API.
To avoid conflicts with options in this specification or other implementations, implementations
should name these non-standard members with their aggregate type specific prefix.

See Change Set N3.

Change Set X: Split API into services advertised in GetVersion

The Uniform Federation API defines multiple "services". Each service is a coherent piece of functionality that a given server / authority may implement. For example, some slice authorities support projects and some do not. This proposal would split up the AM API into services, and add a SERVICES element in the return from GetVersion that is a list of the string names of services supported by this aggregate.

FIXME

Possible services:

• SCHEDULING: Indicates that the aggregate supports scheduled reservations per the previous proposal. Aggregates that support this will accept a geni_start_time option to Allocate, others will ignore such an option.
• IMAGES: This aggregate allows creating and deleting and listing disk images, per the previous proposal.
• COMPUTE: This aggregate supports reserving nodes and will list nodes in its Ad RSpec.
• OPENFLOW: This aggregate supports reserving or configuration OpenFlow links
• STITCHING: This aggregate supports the stitching extension and creating stitched links between aggregates.
• STORAGE: This aggregate supports reserving storage resources.
• UPDATE: This aggregate supports the Update method

Change Set Z: Support Shutdown on a single sliver

This proposal would allow calling Shutdown with a specific sliver or slivers specified, and would only shut down the named slivers, not the entire slice at this aggregate.

Questions:

• What if there are interdependencies among slivers such that other slivers must also be shut down?
• Can an aggregate specify that only the whole slice may be shut down?
• Is this like the options for how Allocate works?

FIXME

Change Set AA: Batch Allocate

Scheduling (see above) is complicated. Often, what an experimenter really wants is to get a particular set of resources whenever they are available. This change set proposes a way for a client to submit an asynchronous request for resources.

In this proposal, an experimenter submits a resource request (via Allocate), but does not immediately receive a manifest. Instead, the aggregate contacts the experimenter (typically via email) when and if the requested resources are available. At that time, the resources are geni_allocated and the experimenter can Provision and use the resources as usual.

In detail:

• Add a new option to Allocate: geni_when_ready. If supplied, the experimenter is requesting the resources described in the request RSpec whenever they become available. The value of geni_when_ready may be None (empty), meaning that the experimenter wants these resources however long it takes to get them. If the value is a datetime, then the experimenter wants these resources only if they become available by the specified date.
• If an aggregate does not support this option, it will ignore it, and either allocate the resources immediately, or fail the request (with an UNAVAILABLE error).
• The return from Allocate when this option is accepted is different than usual:
  • The geni_rspec will be the request rspec as submitted, not a manifest RSpec
  • The geni_slivers list will contain a single sliver. This sliver identifies this new request (distinguishing it from other resource reservations in the same slice at the same aggregate, if any).
    • geni_expires is in general not defined, but will be the time specified by geni_when_ready if any
    • geni_allocation_status will not be geni_allocated, but a new allocation state: geni_batch_requested
• Add a new allocation state, geni_batch_requested: The single sliver that results from a call to Allocate with the geni_when_ready option will be in the geni_batch_requested state until:
  • The aggregate can allocate the resource (and the sliver(s) become geni_allocated), or
  • The experimenter calls Delete on the sliver, and the sliver becomes geni_unallocated
• Update on a batch requested sliver is legal, modifying the request that has been batched. geni_when_ready is not accepted in Update.
• Delete on a batch requested sliver cancels the request, making the sliver geni_unallocated
• If a time was specified in geni_when_ready and the resources have not become available, then:
  • The aggregate shall contact the requester (typically using the email address in the client certificate), specifying that the request could not be satisfied (including the slice urn and sliver urn)
  • The sliver becomes geni_unallocated
• Otherwise, when the resources become available:
  • The resources are reserved and change to geni_allocated as usual. The expiration time should be larger than for usual allocated resources, to allow time for the experimenter to receive the notification and respond. Typically at least 1 business day.
  • The aggregate shall contact the requester (typically using the email address in the client certificate), specifying that the request has been satisfied, including the usual return structure from Allocate plus the slice URN and aggregate URN
• Once a batched request has been made geni_allocated, it behaves like any other set of allocated slivers. You can call Update, Renew, Delete, or Provision on it as usual.

Change Set AB: Case Sensitivity

This API specification calls out that certain fields are case insensitive (RSpec and credential and AM type fields, for example, plus usernames). But for most fields, this specification is silent. This has led to some confusion. FOAM and ORCA/EG are generally case sensitive. ProtoGENI/IG and SFA/Planetlab are generally case insensitive. The GENI Clearinghouse is generally case sensitive. This causes problems. In particular, if a Slice Authority can generate 2 slices whose names differ only by case, and some aggregates will treat those as duplicates, that is a problem.

Some notes on relevant specifications:

• DNS names are case insensitive (RFC4343)
  • This suggests that the authority field of a URN which is generally a hostname should be case insensitive.
  • It also means that aggregates that generate hostnames based on slice URNs may be inclined to treat those fields as case insensitive
• URNs are generally case sensitive, except for the NSS and NID portions (in GENI, the 'publicid:IDN' portion), per RFC 2141
• In URLs, the domain name is case insensitive per RFC 4343, but URLs in general are case sensitive, ​http://www.w3.org/TR/WD-html40-970708/htmlweb.html

Options

• Define slice names and authority names as case insensitive, but requiring (suggesting?) that services are case preserving
  • Note however that in the context of a URN that is case sensitive, this is a little funny
• Define these strings, or all URNs, as strictly lowercase (so case sensitivity is not a problem)
• Note that while URNs are case sensitive, some services that operate on URNs are case insensitive, so URN generating services and clients must avoid conflicts based on case - either by being case insensitive, or by generating URNs that follow a fixed case pattern of their choosing.
• Get a new GENI namespace (not publicid) and define our own subset of the URN spec that codifies one of these alternatives (strictly lowercase, case insensitive)

Proposal

• Slice names and project names (sub-authorities) are case INsensitive, but should be case preserving (If you ask for Myslice you always have Myslice and no one else can have myslice).
• URNs are case sensitive
• In other words, slice authorities must not issue slice names or project names that differ only by case.
• Note however, slice authorities may treat slice and project names as case sensitive for lookup operations.
  • In this case, if slice 'MySlice' exists you cannot create 'myslice', but if you try to get a credential for 'myslice' you will get an error that the slice does not exist - you have to ask for a credential for 'MySlice'.
  • Alternatively, the slice authority could return a credential for 'MySlice' when asked about 'myslice', but in this case the tool must change what slice URN it uses, to match that found in the slice credential.

At GEC19, the GENI GPO and ProtoGENI clearinghouses agreed to follow the above proposal.

Change Set AC: Aggregate Description in GetVersion

At Fed4Fire, aggregates provide some additional information in GetVersion, useful for tools. This includes a pretty name, description, logo, URL, and tools that are known to work well or be specially supported by the aggregate. Provide this in GetVersion so it is available without the privileged ListResources call. This information would be used by tools to provide more and prettier information to experimenters about aggregates.

Fed4Fire uses:

"f4f_testbed_homepage" -> "http://www.wilab2.ilabt.iminds.be",
"f4f_testbed_picture" -> "https://fed4fire-testbeds.ilabt.iminds.be/wilab2_overview.jpg",
"f4f_describe_testbed" -> "The Wilab2 testbed is a heterogeneous wireless testbed that consists of 60 wireless nodes, equipped with IEEE 802.11a/b/g/n, IEEE802.15.4 and IEEE802.15.1 (Bluetooth) interfaces. Every node is also equipped with a custom environment emulator board, enabling unique features of the testbed including the triggering of repeatable digital or analog I/O events at the sensor nodes, real-time monitoring of the power consumption, and battery capacity emulation. The nodes are installed in an unmanned utility room (size: 66m x 22.5m) which is characterised by a minimum of external radio interference. Next to these 60 fixed nodes, the Wilab2 testbed also offers an additional 20 similar setups which are deployed on mobile robots. And finally, the testbed also hosts software defined radio platforms (USRP, WARP) and spectrum scanning engines developed by imec.",
"f4f_endorsed_tools" -> [
       {
          "tool_homepage" -> "http://mytestbed.net",
          "tool_logo" -> "http://mytestbed.net/omf-images/omf-logo.png",
          "tool_version" -> "5.4 - 6.0",
          "tool_name" -> "OMF"
          },
       {
          "tool_homepage" -> "http://oml.mytestbed.net",
          "tool_logo" -> "http://oml.mytestbed.net/attachments/download/797/oml.png",
          "tool_version" -> 2.1,
          "tool_name" -> "OML"
          }
       ],

Proposal: GetVersion adds the following optional but recommended fields:

• geni_am_homepage: A URL providing human readable content describing the aggregate and its resources.
• geni_am_logo: An image usable by tools to represent the aggregate.
• geni_am_pretty_name: A pretty name for the aggregate (better than something extracted from a URN or URL hopefully)
• geni_am_description: A plain text description of the aggregate, its resources, and any usage restrictions.

Change Set AD: Do not require a user credential in ListResources

Currently, a user credential is requires to call ListResources to get the advertisement RSpec from an aggregate. Tools have a tool certificate, but cannot get a user credential. The result is that tools cannot retrieve current resource availability without a user who allows the tool to speak for them. Since Ads change infrequently, this is inefficient. Tools would like to be able to cache Ads.

This proposed change would make the user credential OPTIONAL that is currently required to call ListResources (not in a slice context).

Note:

• A valid / trusted client certificate is still required. This could be the certificate of the tool. So the caller is authenticated, but not separately authorized.
• Aggregates are free to return a different Advertisement to callers who do not supply a valid user credential.

This proposal was discussed at the GEC22 Developer Roundtable.

Proposal: Modify ListResources (for both API version 2 when not in a slice context and version 3+ implementations):

• Make explicit in APIv2 that ListResources requires no credentials when no slice URN is supplied, but a user credential may optionally be supplied.
• For APIv3, change the ListResources details that now says this list must include a valid user credential to instead use may, as in: this list may include a valid user credential.

Older Proposals

Older proposals, withdrawn, superseded, or postponed:

• Original Change Set C: On hold (waiting for a revised proposal). Add the ability to UpdateSlivers to immediately modify your reservation
• Change Set E: Tickets: On hold (waiting for a revised proposal). Add methods using tickets to do negotiated reservations
• Change Set F1: Superseded by F3 and F4: Define sliver states, and the state changes that various methods cause
• Change Set F2: Superseded by F3 and F4: Add a new general ActOnSlivers method allowing AMs to support AM and resource-type specific operations
• Change Set H: Superseded by F3: Clarify: A second call to CreateSlivers without an intervening DeleteSlivers is an error.
• Change Set I4: Superseded by F3 and F4: CreateSlivers optionally does not start resources.
• Withdrawn: Change Set J: Support proxy aggregates with 1 new option and 1 new GetVersion entry
• Postponed: Change Set L: Standardize slice credential privileges
• Change Set O3: Allow unicode values
• No Reservation Allocate

Unspecified items

• UpdateSlivers: Update a reservation or sliver in place, without risking losing resources
• Publish credential schema
• Define error codes returned by new methods, conditions

---

Changes Not Included

RSpec changes resulting in GENI v4 RSpecs

• Support unbound manifests
• Make manifest an extension of Request, so you can readily edit & resubmit a manifest
• Make configuration information in request and manifest optional, so it can be supplied/returned separately
• Fully implement the compute ontology from Ilia
• Ilia's other requests (Openflow related information)
• Document process for updates per my dev list email
• Be consistent: ref vs idref vs href
• Include AM name/URL in RSpecs? Experimenter who allocated it URN?
• Incorporate stitching extension as part of the 'base' RSpec

Misc

• Allow Shutdown on a single sliver or a list of slivers
• Add geni_am_info block to GetVersion return (name, id, url, location, description, is_proxy, proxy: {(a geni_am_info block)}, proxy_for[] (list of geni_am_info blocks))
• Allow the update methods to take a generic rspec argument, allowing AMs to accept full or diff RSpecs
• Tickets
  • Remove requestor certificate?
  • Support brokers: Make ticket methods return multiple tickets. Define tickets as optionally diffs (additive). Make RedeemTicket and UpdateTicket take a list of tickets. Tickets are delegatable via signing, but the delegated ticket must be for a strict subset of the resources in the original.
  • Drop ticket struct, not a signed document. Just reference by ID
• Support message passing
  • Add sendMsg (and getMsgs?) methods that take a signed document, allowing freely passing messages instead of XMLRPC?

Stitching

AMs must support the stitching extension where Layer 2 connections are available:

• including in ads, requests, and manifests.
• Advertise available VLANs, attempt to honor requested VLANs, reserve VLANs with tickets, and report reserved or instantiated VLANs in manifests
• Use schema ​http://hpn.east.isi.edu/rspec/ext/stitch/0.1/stitch-schema.xsd, or even better, version 2 of the schema as specified here: http://www.geni.net/resources/rspec/ext/stitch/2/stitch-schema.xsd
  • Follow guidelines here: ​http://wiki.maxgigapop.net/twiki/bin/view/GENI/NetworkStitchingExt
• Follow general stitching approach as outlined here: ​https://wiki.maxgigapop.net/twiki/bin/view/GENI/NetworkStitchingOverview