Deconstructing PLC Larry Peterson Planet Lab Developer s Meeting

Deconstructing PLC Larry Peterson Planet. Lab Developer’s Meeting May 13 -14, 2008

Overview • Planet. Lab. NG = GENI Prototype • Planet. Lab 4. 2 + geniwrapper (Soner Sevinc) – PLC wrapper: prototype done, integration underway – NM wrapper: prototype in progress • Wrapper includes… – interfaces – namespaces – security mechanisms • Migration plan – – seed registries from PLC’s DB Current and new interfaces coexist unbundle PLC over time experiment with peering

Security Architecture • Authorities – responsible for (vouch for) the objects they manage • Global Identifier (GID) – actually a certificate – (UUID, HRN, Pub. Key, TTL) signed by chain of authorities • Human Readable Name (HRN) – e. g. , planetlab. eu. inria. p 2 p • Credentials – slice: explicitly identifies permitted operations – component (aka ticket): explicitly identifies resources (aka rspec)

Case 1 User Following focuses on slice creation and not node management; does not include CR (would be associated with each Aggregate). PLC SM AM SR CM CM x … CM

Case 2 User Emulab PLC SM SM AM SR CM CM x … CM

Case 3 User Emulab PLC SM SM AM AM SR CM CM … CM

Case 3 a User VINI PLC SM AM x AM SR CM CM … CM CM CM x … CM

Case 4 User PLE PLC SM SR SM AM AM SR CM CM … CM CM CM x … CM

Case 4 a User PLE PLC SM SM AM SR CM CM … CM CM CM x … CM

Peering Issues • Nx. N vs Hierarchy? – PLC, PLE, PLJ/PLA, … – VINI, GLabs, … – Emulab, DETER, … • At what level? – Registry + Slice Interface – Peering Interface • How rich is the policy? – slice count – sliver count – arbitrary resources

Meeting Notes The following slides report “roadmap” discussions from the meeting

Deconstructing PLC • Modify current DB/API to support wrapper (Reid) • Add “slice interface” to PLC wrapper (now have an aggregate) (Scott) • Port “slice interface: to NM wrapper (now have a component) (Scott) – Revisit PLC/NM sync in light of delegation • Specialize AM for VINI (understand topology) (Andy) • Integrate wrapper GUI into PLC GUI (Reid) • Implement a minimal SM = aggregate of aggregates (Aki) – Exports the slice interface, or something more? – Caches node info / remember where slice is embedded – Must be configurable -- what aggregates does it know (set policy) ä How is this module named & accessed? – Filters the list it gives back according to caller ä Can I present a full rspec to this call?

Deconstructing (cont) • Longer-term issues – Federation outside the PL family ä ä 3 rd party SM (delegation is important) Multiple-aggregate SMs relevant here – Worry about the “management interface” (currently private) ä ä Get emergency shutdown right What about killing slices on peer aggregate? – Overhaul security mechanisms ä Make sure security modules leave audit trail

Monitoring Software • Package for distribution • NM live-ness test – both PLC instantiated and delegated slice creation (Utah has code) • Export monitor info to tech contacts – Uber monitor page (comon+monitor+…) – Place for techs to communicate with us (and track it) • Make run-levels real (support tech intervention) – Give out root when in debug mode • Maintain “known security issues” page

QA System • Support virtual and physical test nodes – Use Emulab (potentially available as a std Emulab option) • Package for distribution – One. Lab uptake is an important milestone • Make output logs readily available to developers (notification)

RSpec Discussion • Define an rspec that works today – Today’s attributes (only those that users can set) – Works with wrapper slice interface • Scope the rspec – Users can query/set themselves -- not in rspec – Admin can install themselves -- not in rspec – Requires privileged to establish (is allocate-able) -- is an rspec • Extend today’s attribute set to include some new resource(s) – Allocate whole (non-sharable) physical device to a slice for some time – GRE tunnel keys – Supercharged PL node (motivates private attribute namespace) ä • Specify parameters of hw fast-path: queues, buffers, bw, protocol… Contexts (usage scenarios) – Configuring nodes (this is something different) – Advertising resources (includes same language, but not limited to it) ä Descriptive, includes that which is allocate-able, but other info as well – Requesting / promising resources (definitely)

RSpec / Data Modeling • Identify PL current attributes (Reid) • Prepare draft data model (Mary) • Get/install Eclipse EMF tool (watch the tutorial) – Extract code generator for Python (Scott) • Put up web page for comment (Reid) • Future – Embrace model in the PLC/DB – Revisit the over-the-wire representation (get. Sliver polling)

Resource Allocation • Tickets are opaque – May be a table index – May be an rspec – May be a PLC DB entry (current implementation) • Tickets split/reassigned/redeemed by their source – Source is only one that can interpret the ticket • Planet. Lab reality – PLC hands out tickets – Tickets redeemed/split at nodes ä Necessary to implement Sirius – PLC and nodes are in cahoots • Alternative Interface – 2 D table of resources/time (owner of the allocation & slice) ä Calendar-like (trivially implement Sirius on top of this interface) – Ops: get/set_owner & get/set_slice ä ä Owner decides what slice gets to use / slice then consumes Set_slice like split (Split folds together slice & owner; split can’t revoke) – Also an escrow service that swaps rights (client of this interface) – Does this break PL’s “node state is soft” model? ä Client gets receipt & has to refresh node state