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
25
Embed
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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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 LiUniversity of Virginia
John Vollbrecht and Brian CashmanInternet2
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?
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 purchase2. 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
Virtual HOPI node for user 1
Virtual HOPI node for user 2
Note: Hopi topology obtained courtesy of Rick Summerhill
18
How to virtualize Force10 switch
Networking-researcher 1's
software
“Virtualizer” software module
Networking-researcher 2's
software
Control plane
Data plane
Force10 E-series
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