Changes between Version 1 and Version 2 of OpenFlow/CampusTopology

Timestamp:

04/05/11 16:24:00 (13 years ago)

Author:

Josh Smift

Comment:

--

OpenFlow/CampusTopology

@@ -49 +49 @@
 Note that the two ports don't have to be on the same switch. In particular, if there were already another campus switch in the path between this OpenFlow switch and the regional, you could connect port 3 on this switch (still on VLAN 1750) to a port on that other campus switch (still on VLAN 3715), and accomplish the same effect. This would free up a port on this OpenFlow switch, but use up a port on the other switch, so campuses should decide where to put the cross-connects based on where ports are scarce.
 
-VLAN 1750 is OpenFlow-controlled. In addition to whatever other OpenFlow programming the experimenter wishes to do, they also use OpenFlow to direct outbound traffic to a physical port; the port they choose controls which inter-campus VLAN will be used for the outbound traffic. For example, an experiment that wanted to send inter-campus traffic via VLAN 3715 would use OpenFlow to send that traffic out port 3. Example code to do this is available from Stanford and the GPO, contact us for more information. ''(FIXME: Replace the previous sentence with a link to a page with more information, download links, etc.)''
+VLAN 1750 is an OpenFlow-controlled VLAN, shared by multiple experimenters via the FlowVisor. In addition to whatever other OpenFlow programming each experimenter wishes to do with their sliver, the experimenter also uses OpenFlow to direct outbound traffic to a physical port; the port they choose controls which inter-campus VLAN will be used for the outbound traffic. For example, an experiment that wanted to send inter-campus traffic via VLAN 3715 would use OpenFlow to send that traffic out port 3. Example code to do this is available from Stanford and the GPO, contact us for more information. ''(FIXME: Replace the previous sentence with a link to a page with more information, download links, etc.)''
 
 Additional VLANs can be set up for physical translation, but they use two ports per VLAN, and they need to be physically connected by a campus network admin... So this can be done if needed, but should generally be minimized.
@@ -55 +55 @@
 = OpenFlow-based software VLAN translation =
 
-Ports 7 and 8 are a pair of ports that are directly connected to each other by a short cross-connect cable, but unlike the previous pairs, one is a trunk port, carrying any VLANs that the campus network admin wants to allow experimenters to translate between. VLAN 1799 is OpenFlow controlled, using a controller that can rewrite VLAN tags (such as transvl), such that when a packet from VLAN 1700 goes out port 7, the switch tags it (because port 7 is a trunk port), and the transvl controller then receives the tagged packet. It can then remove the tag and add a new one (for VLAN 3704, say), and put the packet back out port 8 with the new tag, at which point port 8 receives the tagged packet, strips off the tag, and the switch then handles it in whatever way VLAN 3704 is normally handled.
+Ports 7 and 8 are a pair of ports that are directly connected to each other by a short cross-connect cable, but unlike the previous pairs, one is a trunk port, carrying any VLANs that the campus network admin wants to allow experimenters to translate between. VLAN 1799 is OpenFlow controlled, using a controller that can rewrite VLAN tags (such as transvl). When a packet from VLAN 1700 goes out port 7, the switch tags it (because port 7 is a trunk port), and the transvl controller then receives the tagged packet. It can then remove the tag and add a new one (for VLAN 3704, say), and put the packet back out port 8 with the new tag, at which point port 8 receives the tagged packet, strips off the tag, and the switch then handles it in whatever way VLAN 3704 is normally handled.
 
 This approach effectively implements VLAN translation in OpenFlow. It has a few limitations: