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
• Wireless Nodes
  • We need to make special provision for nodes which can communicate wirelessly: WirelessRSpec?
• Extensions (see RSpecExtensions)
  • The RSpec must provide an extensions mechanism to accommodate the wide range of stakeholders which will make use of the RSpec.

Design Principles

• RSpecs should be about what a Component Manager can do, not about what the user can do. For instance, a user may be able to set up a virtual router themselves on a raw PC. But the node should only have a 'virtual router' virtualization type if the CM sets one up.
• RSpecs should contains specific information about components, not universal relationships. If a field can change from node to node even if all the other fields are identical, then that is specific information about that node. Information about the relationships between disk images and virtualization types or the virtualization type on the node and the interface are universal to those virtualization types, not the nodes.

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?

• RSpecLifeCycle

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

Integration with CMU

There are a number of changes we needed to make to the RSpec so that it contains the information necessary for integration with CMU.

Location

• GPS Coordinates -- We included the location of each node based on WGS84 standard definition of longitude and lattitude.
• Country -- Different countries may have different laws about permissible activities on nodes. In addition, we can use the standard two-letter ISO 3166 code to distinguish them consistently.
• City, State, Address -- We'll continue to store these in our database, but only country will go into the RSpec for now. The main rationale iss that we want the stuff in the RSpec to be 'machine readable' and this stuff is generally not - useful for humans, but hard to standardize for proper matching (eg. Salt Lake City/SLC, New York City/Manhattan, Calcutta/Kolkata, Mumbai/Bombay, etc.)

Administrative

• Contact information (name, email, telephone, shipping address) -- Each node in an RSPec contains the UUID for its component manager. Therefore administrative information can be made as a separate RPC call to the component manager rather than embedding it into the RSpec.

Internetwork

• Type of connection -- There will be a 'dummy' node that represents "the Internet", and there will be a link from the homenet, etc. node to it. This will have type, bandwidth, etc.
• Bandwidth limits imposed, if any -- Not yet included
• NAT and firewalls -- These will be represented as explicit middleboxes, exact details TBD. The node itself will have a link (type 'Ethernet', usually) to the nat/firewall, and that box will have a link to "the Internet" - this lets us also give the private and public IP addresses, and lets us represent multiple nodes behind the same NAT. The middleboxes will have some 'gateway' type, which will specify, in addition to the regular node stuff, which side is "inside", what functions that box can perform (NAT, firewalling, emergency cutoff, etc.) We're still a little fuzzy on how this will turn into XML, but have a general sense of it.
• Reachability: Internet, I2, {other} -- Will handle this with multiple 'dummy nodes' as mentioned above for "commodity Internet"

HomeNet?

• Wireless Monitoring Devices (USRPs acting as spectrum analyzers) -- We added a <monitoring> tag to interfaces that could be used to tag stuff like this - probably just a simple string indicating that you can monitor it with a USRP.
• 3 wireless devices that the users can configure in various ways -- Interfaces are explicit. So each interface can have independent configuration options.
• Ability to get user traffic -- We added a 'user_traffic' attribute in the <monitoring> section indicating you are allowed to monitor end-user traffic on a particular interface.
• A TV tuner / digitizer card -- Might handle this using an extension that just plops in assign's features/desires system.
• RON nodes have BGP feeds from their local hosts in some cases -- Not sure how to handle this one, will have to talk to Dave Anderson and possibly Nick more about it.