| 5 | | |
| 6 | | === Hardware Set up === |
| 7 | | |
| 8 | | [[Image()]] |
| 9 | | [[BR]]Figure 1: Ivan's arch drawing goes here |
| 10 | | |
| 11 | | |
| 12 | | The switch labeled 'sw-sb-09', a Pronto 3240, provides the central connectivity backplane between all hosts/NetFPGAs in the sandbox. Each host (node1-1..node1-9) is connected to the top switch through one 1GbE data connection on the interface 'exp0'. Also, a second GbE interface - 'control' - on the host is used exclusively for experiment control (incl. ssh/telnet sessions). The control connection is connected to an external control switch. |
| 13 | | |
| 14 | | The first 7 hosts (node1-1..node1-7) each contain a 4x1GbE NetFPGA installed on a PCI slot. The NetFPGA has 4 connections to the top switch, each corresponding to its 4-GbE ports nf2c0-nf2c3. The NetFPGAs also have two 3-Gbps SATA interfaces, presently not connected to anything. If you have a convincing argument (experiment-related, of course) for connecting those up to anything, you'd need to get in touch with an ORBIT chief. |
| 15 | | |
| 16 | | The Pronto switch, which we will call 'top switch' hereon, is a !OpenFlow enabled switch and can be run in native or !OpenFlow mode by controlling its boot configuration. When in native mode, it runs the Pica8 Xorplus switch software. However, the testbed constructs a higher-level interface to control both the mode of operation (!OpenFlow/native), and the configuration of the most relevant functions in the two modes. The interface is simple and HTTP based, and enables the experimenter to control connectivity and other parameters without opening a ssh/telnet session and using the switch CLI - more details in later section. |
| 17 | | |
| 18 | | Some external reference links about above hardware: |
| 19 | | * [http://www.netfpga.org NetFPGA] |
| 20 | | * [http://www.prontosys.net/pronto3240.htm Pronto 3240] | [http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/Pronto#Pronto_3240 OpenFlow's page on Pronto 3240] |
| 21 | | * [http://www.openflow.org/ OpenFlow] |
| 46 | | |
| 47 | | ORBIT provides HTTP request API abstraction to controlling the configuration of the top switch. The service implementing this API can be accessed by an experimenter from within the SB9 network, including the console and experiment nodes, at the following address: |
| 48 | | |
| 49 | | {{{ |
| 50 | | http://nox.orbit-lab.rutgers.edu:5052/network |
| 51 | | Or simply as: |
| 52 | | http://nox:5052/network |
| 53 | | }}} |
| 54 | | |
| 55 | | That base URL renders an XML response detailing all requests implemented by the service. Parameter values, such as to address a particular port (port #) on a particular switch (switch IP address), be passed as URL arguments in the HTTP request. For example, to retrieve the details of particular port (say 5) on the top switch ('''IP=10.19.0.253'''), the requested URL is: |
| 56 | | |
| 57 | | {{{ |
| 58 | | http://nox:5052/network/portStat?switch=10.19.0.253&port=5 |
| 59 | | }}} |
| 60 | | |
| 61 | | The service supports the following main features for the native mode (refer to XML response from the base URL for complete list and API specification): |
| 62 | | |
| 63 | | 1. Getting/setting the VLAN ID on any port(s) |
| 64 | | 1. Assigning two or more VLAN IDs on a port, making it a trunk |
| 65 | | 1. Getting per port statistics (in, out packet counts) and configuration (VLAN) information |
| 66 | | 1. Enabling/disabling a port |
| 67 | | 1. Turning on/off default switch topology protocols - Spanning Tree Protocol (STP) |
| 68 | | 1. Saving the per-port configuration of the entire switch |
| 69 | | 1. Restoring switch configuration to prior saved version |
| 70 | | |
| 71 | | In addition, it supports the following requests to support the !OpenFlow mode: |
| 72 | | |
| 73 | | 1. Change the mode of the switch from native to !OpenFlow mode (and vice versa) |
| 74 | | 1. Set the !OpenFlow mode parameters including: control port, controller IP, switch ID (dpid), and the transport mode for secure channel |
| 75 | | ''''' Q. Does the switch have to be in native mode to invoke the setvsi/getvsi requests? ''''' |
