1 Proposals for HOPI Outline A proposal for testing on the HOPI testbed specific applications, and a control-plane solution A proposal to virtualize the HOPI testbed Malathi Veeraraghavan & Tao Li University of Virginia John Vollbrecht and Brian Cashman Internet2

2 Application testing Applications Selected to show-case advantages of high-speed dedicated virtual circuits (VCs) between PCs located at HOPI PoPs Mostly file transfer applications Examples: Web proxy (caching) servers: allows users not directly connected to HOPI to nevertheless use it (use HOPI VCs for inter-proxy file transfers) CDN and web mirroring: locate these servers at HOPI PoPs, and use VCs for file movement between CDN servers/mirrors IPTV: move video files between IPTV servers located at PoPs that serve local audiences servers: SMTP-to-SMTP server file transfers Storage and disaster recovery CDN: Content Delivery network; SMTP: Simple Mail Transfer Protocol

3 Process for application testing End hosts on which to run applications: Use existing "support" PCs at HOPI PoPs, or Collocate UVa-provided PCs at HOPI PoPs Obtain virtual circuits from HOPI TSC as required for the experiments, and run tests Focus: on the data-plane benefits

4 Control-plane testing Cheetah Control-Plane Module (CCPM) Implements distributed bandwidth management One CCPM per HOPI Force10 switch to manage the bandwidth for all the interfaces on that particular switch Dynamic virtual-circuit service for calls with  high call arrival rates  short durations  immediate-request type

5 Process for control-plane testing Obtain logins on control PCs Upload and run the CCPM module at two or more HOPI PoPs Obtain logins on Force10 switches To enable CCPMs to issue VLAN configuration commands to the Force10 switches Obtain a set of resource partitions from HOPI TSC VLAN IDs, ports and bandwidth

6 A question raised by this experiment: Will conflicts arise in the use of bandwidth and/or VLAN IDs between the proposed CCPM and the current NARB/VLSR control-plane solution? We generalized this question to how can the HOPI testbed support proposals for "networking-research" experiments? experiments that require access to the Force10 switch resources

7 So we generalized the proposal A proposal for testing on the HOPI testbed specific applications, and control-plane software  A proposal to virtualize the HOPI testbed  Are there other application ideas?  Are there other "networking-research" ideas?

8 Other application ideas? Who are the specific "application" researchers to whom we could market this high-speed dynamic- VC network? Games developers: Multiplayer games require servers; presumably a server is located at a PoP to serve players within the PoP's region. True? Can HOPI VCs help in server-to-server communication? Middleware developers for eScience, e.g., GridFTP, PVFS, Phoebus (Swany), data-mining (Grossman) Storage researchers, e.g., Micah Beck Virtual computing: Mladen Vouk

9 Applications that won't work! Because HOPI is only a backbone network: Any application that requires a human user at an enterprise to view the monitor Remote desktop from the enterprise PC to a HOPI PoP PC will be a limiting factor for high-speed applications Example: Watching an uncompressed HDTV video signal, or remote visualization

10 Other "networking-research" experiments? Network management software Accounting management Performance monitoring Fault management - restoration studies Security software Changing bandwidth partitions based on long-term measurements - "configuration mgmt." Control-plane solutions Immediate-request, fast signaling Book-ahead schedulers Routing algorithms L2 vs. L3, with/without QoS (e.g., Diffserv)

11 Question So how do we set up the HOPI testbed in such a way that it can support multiple, simultaneous application researchers, and networking researchers?

12 Copy parts of the PlanetLab model What is the PlanetLab model? A researcher contributes PCs to PlanetLab: this requires giving up administrative access to the PlanetLab team; the researcher can physically locate the PCs anywhere as long as they can be accessed remotely via the Internet PlanetLab team loads the PlanetLab OS on these PCs The entire PlanetLab community immediately gets logins on these newly contributed PCs The researcher is given a login with which he can access all the PlanetLab PCs (> 200 or so, right?) The researcher can schedule and receive a "slice" of a set of PCs (virtual hosts) Researcher gets immediate access to a wide-area network of PCs interconnected by the IP-routed Internet!

13 Proposed HOPI testbed model Copy features from PlanetLab Ask researchers to contribute PCs, but physically locate these at HOPI PoPs Slice PCs and offer usage of the PCs to the entire HOPI testbed community Offer slices of the Force10 backbone switches: virtualize these switches Invite contributions of switches and routers from researchers, and locate at HOPI PoPs Slice these switches & routers and offer usage to the whole community

14 How does this compare with PlanetLab? Differences PlanetLab is a large-scale, low-speed network HOPI is a small-scale, high-speed network QoS studies possible on HOPI; not so on PlanetLab Examples: A user gets only 2-3Mbps on a PlanetLab PC's NIC PlanetLab PCs can have only one NIC One significant difference: Researchers do not have to pay to join PlanetLab In HOPI, researchers may have to, e.g., colo costs

15 Why would a researcher want to use the HOPI testbed? We conjecture... for these four reasons: 1. High-speed testing - gear expensive to purchase 2. Wide-area testing - WAN emulators in labs are alternatives, but the HOPI testbed makes it real. 3. Scalability testing Metcalfe's observation on value of the network being related to the number of users Deployment at HOPI PoPs at least offers the opportunity to invite growth 4. Access to switches/routers - expensive to fund via small NSF grants

16 Virtualizing HOPI nodes Virtual HOPI node Each user is allocated a fraction of resources on every HOPI PoP; User has full control of allocated resources Resources to be partitioned: Bandwidth on 10G Ethernet interfaces, 1G Ethernet ports, VLAN ID space, hosts, etc.

17 Topology after virtualization Note: Hopi topology obtained courtesy of Rick Summerhill

18 How to virtualize Force10 switch Virtualizer: a “wrapper” for authorization  Each networking-researcher's software can issue commands that manipulate only its allocated resources  Three sets of resources:  portsEASY?  VLAN IDsEASY?  bandwidthDIFFICULT?  Virtualizer keeps database associating user logins with resources, and checks every command before forwarding to the switch  Example in figure: Both networking researchers have implemented control-plane solutions, which require the creation and deletion of VLANs:  Control-plane solution 1 can configure VLANs with IDs in the range of  Control-plane solution 2 is allocated VLANs with IDs,

19 Does the virtualizer need to keep state information? Creating or deleting a VLAN takes a sequence of commands Example: a user wants to set up VLAN 100, and add 1G ports “gi 2/0”, “gi 2/1”, and 10G port “te 0/0” into this VLAN: Force10#config Force10(conf)#int vlan 100 Force10(conf-if-vlan)#tagged gi 2/0 Force10(conf-if-vlan)#untagged gi 2/1 Force10(conf-if-vlan)#tagged te 0/0 Force10(conf-if-vlan)#end

20 Does the virtualizer need to keep state information? Maybe not. When the virtualizer receives: an "int vlan" command, it checks if the VLAN ID provided is allowed for the user that issued the command a "tagged" or "untagged" port command, it checks if the port can be used by the user that issued the command, and if the user has permission to use it in the requested tagged/untagged mode What if a user module erroneously issued the "tagged gi 2/0" command before the "int vlan 100" command? the virtualizer would simply pass the erroneous command to the Force10 (if that user had rights to issue the tagged command for that port), receive an error message from the switch, which it passes back to the software module Will this work? Comments?

21 The bandwidth resource complexity Problem: How to ensure that the bandwidth partitions allocated to the multiple networking-research experiments are being honored? Possible solution 1: virtualizer tracks BW Procedure: Virtualizer keeps track of aggregate bandwidth for each user login For every command issued by an experiment that adds or deletes bandwidth, the total value is checked against allocation Commands that set policing limits or output rate limits are "accepted" and passed through to switch only if there is no violation

22 Bandwidth partitioning, cont’d Possible solution 2: without BW-tracking in virtualizer Create virtual ports on each shared interface Use VLAN-stack VLANs? Use priority field? For example, if the switch had MPLS, Can partition bandwidth into "fat" MPLS LSPs on each port, allocating one LSP to each simultaneous networking-research experimenter Each "fat" MPLS LSP is an interface with an ID. The virtualizer then just checks interface IDs against user logins without concern for bandwidth Bandwidth partitions are then enforced by the switch itself Without MPLS, is this feasible on the Force 10s?

23 Data-plane enforcement of bandwidth partitions "Set rate police for incoming traffic: You can configure rate policing for an interface. If you use VLANs for each physical interface, you can configure six rate police commands specifying different VLANs." Page 295 of Config pdf A similar statement is made for output rate limiting. We need VLAN stacking to allow our control- plane for example to allocate sub-rate VLANs within this outer VLAN

24 Options for virtualizing the hosts VMware Planetlab OS Other options?

25 Thanks for listening! Questions? Suggestions?