Minutesfrom01Nov2007
!ProtoGENI Project Meeting, 01 Nov 2007
!ProtoGENI Project Meeting, 01 Nov 2007
Agenda
From: Jay Lepreau <lepreau@cs.utah.edu>
Sender: lepreau@flux.utah.edu
To: testbed-nops@flux.utah.edu, eeide@flux.utah.edu
Subject: Re: GENI reading list
Date: Wed, 31 Oct 2007 17:14:17 -0600
[...]
Folks: for tomorrow please read the first document below. If you
really don't have time, read the second (but you'll still have to read
the other later, so would take more time total).
[...]
o GENI Architectrue Redeux. June 2007.
http://www.cs.princeton.edu/~llp/arch_redeux_v0.3.pdf
An update to the GENI Architecture document (GDD-06-11) to reflect the
material incorporated into the Facility Design document. If you are going
to read only one document, this is probably it.
o A Minimal Definition of GENI's Narrow Waist.
http://www.cs.princeton.edu/~llp/arch_abridged.pdf
An abridged version of the Architecture document, focusing on the definition
of key abstractions, but sacrificing completeness. If you have time for only
the Reader's Digest version, this is the document to read.
Leigh had mentioned XML'izing some of our resource stuff.
That's the plan. See the first few pages of this doc
(the back is just long examples).
o RSpec.
http://www.cs.princeton.edu/~llp/rspec-draft-v0.4.pdf
Expands upon the Resource Specification (rspec) section of the full
Architecture document.
-- Main.EricEide - 02 Nov 2007
Notes from the Meeting
Who/When
- attendees: Jay, Rob, David, Mike (phone), Leigh (phone), Eric (@3:40 PM)
- start @ 3:00 PM
- end @ 4:35 PM
Brief GENI Q&A
- The GMC defines the GENI API, including interfaces to GMC, CM, SA, MA,
etc.
- There may be many implementations of the GMC.
- MAs are owners of resources. There will be multiple SAs (i.e., EU,
NSF-GENI, etc.).
- Parts of the MA interfaces may be private.
- What is Utah? Utah is an owner/operator of our resources (an MA), as
well as a portal.
- We are also an SES (slice embedding service), but that's part of being a portal.
- We will need to choose to make parts of Emulab available as individual components, or as one big aggregate component, or potentially both!
- Do we need to implement the whole GENI architecture (all the interfaces)
so we can interact (federate) with other prototype GENIs?
- Jay: we didn't promise interaction/federation in the proposal.
- Jay: we want to formulate our own APIs before federating.
- Jay: relates to Emulab federation; perhaps could do both at once.
- The GENI docs form a hazy picture of what's needed; we can change the docs and convince other people. We will find things that need changing.
- Desired: code, fast.
How does existing Emulab relate to GENI?
- We could have a CM for each testbed PC, and a CM for networks that connect them.
- Emulab could also be a component aggregate, which could talk to individual
CM interfaces on each PC/switch
- Rob: a complex configurable link is a component. We would have a frontend to switches and delay nodes.
- Making this distinction might be hard, if we do the aggregate CM in terms of the node/switch/etc CMs.
- Jay: figure out how links have CMs later.
Jay: what do we do first?
- Cluster pcs
- Virtual pcs
- Programmable routers? Not at first.
- NetFPGA: could do a simple thing where we just export access to the hardware to a single user, let them program it... but not at first.
- jtw's routers: wait until he develops an NM for them, then use that.
- Wireless: 802.11, SDR
- Mike: "virtual access point component"?
- Maybe phase in the more "advanced" wireless support (i.e., all the virtualization).
- Jay: just deploy a wide-area Emulab?
- Only a few things are missing
- It would be useful in the short term to people
- Must send HW around the world
- HomeNet
- This gets us into federation...
- ...unless we deploy this stuff ourselves: a Utah HomeNet
- Sensors: yes
- StarGates: no
- Cisco routers: no
Security
- Chains of certs of auth/perm
- We need to do multiple levels, but said we wouldn't (why is it hard?)
- Jay: policy aspects are hard; but mech?
- side issue: multiple leases: one for slice, one for ticket (ugly).
- Could exploit slice lease times for revocation, perhaps (why do chains
make revocation worse?)
- Eric: hard because must walk up the chain?
- Caching midchain hurts, because revocations must be pushed to root
Action items
- Mike: understand GENI's "virtual" abstractions and how they relate
to our stuff, especially in terms of wireless
- e.g., "virtual access point"
- Are some of our abstraction just "handy bundles" of resources?
- Straighten out the security
- David: figure out the "NodeManager thing", vservers, etc.
- Presumably we run the PlanetLab Node Manager, but...
- Do we run PLC, or do we have ELC?
- Leigh: figure out why we're unfaithful to the current standard way of making XMLRPC servers; SOAP/WSDL stuff too.
-- Main.EricEide - 02 Nov 2007<br/> -- Main.DavidJohnson - 06 Nov 2007