Proposals for HOPI

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 • Email 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: • High-speed testing - gear expensive to purchase • Wide-area testing - WAN emulators in labs are alternatives, but the HOPI testbed makes it real. • 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 • 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: • ports EASY? • VLAN IDs EASY? • bandwidth DIFFICULT? • 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 0-2047 • Control-plane solution 2 is allocated VLANs with IDs, 2048-4095

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-6.5.1.0.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? 