1 / 7

Enhancing Network Representation in PlanetLab and VINI: Developer Meeting Insights

During the Developer's Meeting on May 13-14, 2008, Andy Bavier discussed strategies for storing and representing network information in PlanetLab and VINI. Key topics included differentiating between physical and virtual network topologies, creating tools for altering topology instances, and storing physical resources in the database. Solutions proposed involve using new API calls to enhance functionality and leverage existing frameworks for better network management. The meeting aimed to outline steps for integrating and improving network abstractions across both platforms.

otis
Télécharger la présentation

Enhancing Network Representation in PlanetLab and VINI: Developer Meeting Insights

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. Network Rspecs in PlanetLab and VINI Andy BavierPL Developer's MeetingMay 13-14, 2008

  2. Adding Networks to PL / VINI • How to store and represent network information in PlanetLab and VINI? • Currently: only information for physical hosts • VINI needs to represent information about: • Physical network topologies • Virtual links connecting virtual hosts • Distinguish between • Topologies: Physical vs. virtual • Information: Storing (in DB) vs. representing (rspec) • Other work in this space? (e.g., Wireless in OneLab)

  3. Control Flow • Topology creation/modification tool • Extracts physical topology info from PLC DB • Extracts existing virtual topology for slice • User manipulates slice's virtual topo • Saves changes to PLC DB • Optional: pushes virtual topology to nodes • Requirement: support many such tools • Topology creation vs. binding resources • Best-effort topologies? • Add/subtract resources to an existing topology

  4. Storing Physical Topologies • At each VINI site: two nodes -> switch -> core router • Abstractions: • sites connected by bit-pipes • allocated vs. free capacity • Other network abstractions? • Proposal: • <LinkID, [SiteID, SiteID], Bandwidth, [VirtLinkIDs]>

  5. Physical Topology Rspec • Communicate physical topology (e.g., to Emulab) • New API call: GetLinks()? • Suggestions: • Leverage others' work • GENI compliance if possible

  6. Storing Virtual Topologies • Virtual links are tunnels between virtual interfaces • Physical interfaces • Demux protocol, key • Other implementation details • Proposal: • <VirtLinkID, SliceID, [NodeID, NodeID], LinkID, Bandwidth, DemuxProtocol, DemuxKey, Type> • Type can hint at implementation • EGRE_BRIDGE_ETUN • Add to slice: list of VirtLinkIDs

  7. Virtual Topology Rspec • Need to communicate to NodeManager how to set up a virtual link • Incorporate into the Ticket? • Create a parallel mechanism?

More Related