Deconstructing PLC PlanetLab Developer’s Meeting May 13-14, 2008 Larry Peterson

Overview PlanetLab NG = GENI Prototype PlanetLab 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, PubKey, TTL) signed by chain of authorities Human Readable Name (HRN) –e.g., planetlab.eu.inria.p2p Credentials –slice: explicitly identifies permitted operations –component (aka ticket ): explicitly identifies resources (aka rspec )

Parts List Slice Interface - create & control slices/slivers Registry Interface - bind & resolve naming info Management Interface - query & reboot components Peering Interface - exchange resource rights Uber Researcher Interface - slice interface & so much more Slice Registry (SR) - SA responsible for users & slices - exports registry interface Slice Manager (SM) - creates & controls slices - exports researcher interface Aggregate Manager (AM) - responsible for a set of components - exports slice & mgmt interfaces Component Manager (CM) - controls a component - exports slice & mgmt interfaces Component Registry (CR) - MA responsible for components - exports registry interface

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

Case 2 PLC CMSMSRAMCM … User SM Emulab x

Case 3 PLC CMSMSR AM CM … User SM AMCM … Emulab

Case 3a PLC CMSRCM … User SMAMCM … AM VINI x x

Case 4 PLC CMSRCM … User SM AMCM … AM SR PLE x

Case 4a PLC CMSRCM … User SMAMCM … AM PLE x SMSR User

Peering Issues N x 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 ä 3rd 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 –OneLab 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 (getSliver 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 PlanetLab reality –PLC hands out tickets –Tickets redeemed/split at nodes ä Necessary to implement Sirius –PLC and nodes are in cahoots Alternative Interface –2D 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