RSpec

The ProtoGENI RSpec will be based on the ptop/vtop format designed for assign?. This format is fairly simple, and has the advantage of being in production use for 8 years now in Emulab?. This format does have some parts that are specific to Emulab and assign: these will simply be ignored to begin with, and we will remove them from the RSpec or implement them as extensions as we move to a full GENI rspec.

The RSpec schema is given in the "RelaxNG Compact" syntax. The advantage of doing this is that RNC is very human-readable and flexible, and can be translated to the W3C XML schema, which is more widely supported, but is incredibly hard to read/write by hand.

Key features of the ProtoGENI RSpec

  • Identifying resources
    • All nodes and links are identified by a UUID
    • There is also a "human readable" name field to aid readability
  • Nodes
    • Node have types
    • Virtualization technology is included as a field
  • Links
    • Links are point-to-point: LANs and other "full connectivity" environments (such at the Internet), a "LAN node" is created, and all members are linked to it.
    • Links have bandwidth, a type, etc.
    • Links endpoints reference Interfaces on Nodes
  • Interfaces
    • Endpoint of a link
    • Named by node, plus an opaque interface name
    • In progress: Interfaces will be first-class entities, declared as part of the component they belong to
  • Metadata
    • A "valid until" field
    • A "generated" time

Open Issues

  • Do we directly include assign's features and desires?
  • Should we introduce something into the RSpec to indicate whether or not it comes from an aggregate?

RSpec Lifecycle

RSpecs interact with nearly every piece of the GENI architecture. How does it all fit together?

Resource Discovery

ProtoGENI will use a very simple resource discovery model. The number of entities federating will be relatively small, so it will be reasonable to have global knowledge of which

There will be two phases.

  • In the first phase, the querier gets a list of all physical resources - whether or not they are currently available. The idea is that this operation does not need to be done often - possibly only once, or possibly weekly, monthly, etc. This information is cached.
  • In the second phase, the querier gets a list of which resources are currently available. This phase does *not* return details about the physical hardware, simply a "bit" indicating whether each component is available for use or not. This step in context-sensitive: ie. the query needs to be made with the identity of the person who will be requesting tickets, as the (aggregate) components might make different policy decisions depending on who is asking.

Because all components are uniquely identifiable with UUIDs, it is easy to combine the results of the second query with the results of the first, and feed this in to the slice embedding service.

The idea is to use optimistic resource reservation, as Emulab does: make the availability query right before running the slice embedder, then attempt to get tickets for the components that were chosen. If any have become unavailable in the meantime, simply hold on to the tickets you were able to grab, and run the slice embedder again to replace the unavailable ones.

Migration From vtop/ptop Format

Because the ProtoGENI RSpec schema is descended from the Emulab ptop/vtop format, it currently contains some Emulab-specific elements. This section goes through the major element specifications from top.rnc (attached below), and comments on their role in the ProtoGENI RSpec.

  • NodeSpec? Name element remains as a human-readable name, but the UUID (added by the RSpec) is now the unique identifier for a node. Other portions of this pattern discussed below.
  • LinkSpec? Like a node, the "name" tag remains as a HRN, and the new UUID is the actual unique identifier.
  • NodeTypeSpec? Semantics are defined by Emulab, but so useful we're not going to throw it out - will remain in the ProtoGENI RSpec, though possibly in some Emulab namespace
  • NodeFlagSpec? Totally assign-specific, will not be put in the ProtoGENI RSpec
  • FeatreDesireSpec? Somewhat Emulab-specific, but very useful, so we will keep it in the Emulab namespace
  • PropertySpec? Not even implemented in Emulab yet - so not in our RSpec
  • LinkTypeSpec? Same as NoedeTypeSpec?
  • LinkEndPoints? Will be in the GENI RSpec, with the modification that endpoints/interfaces now 'link' to nodes using the UUID, not HRN (we might keep the HRN for readability)
  • LinkCharacteristics? Yes, in the ProtoGENI RSpec
  • InterfaceSpec? Yes, in the ProtoGENI RSpec

Attachments