1 / 18

Deconstructing PLC

Deconstructing PLC. Larry Peterson. PlanetLab Developer’s Meeting May 13-14, 2008. Overview. PlanetLab NG = GENI Prototype PlanetLab 4.2 + geniwrapper (Soner Sevinc) PLC wrapper: prototype done, integration underway NM wrapper: prototype in progress Wrapper includes… interfaces

cleantha
Download Presentation

Deconstructing PLC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deconstructing PLC Larry Peterson PlanetLab Developer’s MeetingMay 13-14, 2008

  2. Overview • PlanetLabNG = GENI Prototype • PlanetLab 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

  3. 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)

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

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

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

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

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

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

  10. Peering Issues • NxN 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

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

  12. 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?

  13. 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

  14. 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

  15. 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)

  16. 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)

  17. 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)

  18. 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

More Related