Context Navigation

Changes between Version 6 and Version 7 of OpenFlow/CampusTopology

Timestamp:: 04/05/11 17:16:44 (13 years ago)
Author:: Josh Smift
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

OpenFlow/CampusTopology

-                      v6
+                      v7
 [[PageOutline]]
 This is an example topology of a campus OpenFlow network, designed to allow experimenters to access the GENI network core in a variety of ways depending on their needs. In particular, it offers three main options for connecting resources at campuses to inter-campus VLANs:
+This is an example topology of a campus !OpenFlow network, designed to allow experimenters to access the GENI network core in a variety of ways depending on their needs. In particular, it offers three main options for connecting resources at campuses to inter-campus VLANs:
 . Connect directly to one or more pre-provisioned [wiki:ConnectivityHome core VLANs], without using any campus OpenFlow resources. This is a very simple option for experiments that don't need to use OpenFlow campus resources at all, and merely want to access the GENI network core.
+. Connect directly to one or more pre-provisioned [wiki:ConnectivityHome core VLANs], without using any campus !OpenFlow resources. This is a very simple option for experiments that don't need to use !OpenFlow campus resources at all, and merely want to access the GENI network core.
 . Use OpenFlow to connect to one or more pre-provisioned [wiki:ConnectivityHome core VLANs], via a cross-connect cable that translates from a campus OpenFlow VLAN onto the core VLANs. This is a fairly simple option for experiments that want to use OpenFlow campus resources, and can use existing core VLANs.
+. Use !OpenFlow to connect to one or more pre-provisioned [wiki:ConnectivityHome core VLANs], via a cross-connect cable that translates from a campus !OpenFlow VLAN onto the core VLANs. This is a fairly simple option for experiments that want to use !OpenFlow campus resources, and can use existing core VLANs.
 . Use OpenFlow to connect to any [wiki:ConnectivityHome core VLANs], by having OpenFlow configure the switch to do VLAN translation. This is a more complicated option for experiments that want to use OpenFlow campus resources, and need to use VLANs that aren't provisioned with a physical cross-connect for whatever reason (e.g. large numbers of VLANs, dynamically provisioned VLANs, etc).
+. Use !OpenFlow to connect to any [wiki:ConnectivityHome core VLANs], by having !OpenFlow configure the switch to do VLAN translation. This is a more complicated option for experiments that want to use !OpenFlow campus resources, and need to use VLANs that aren't provisioned with a physical cross-connect for whatever reason (e.g. large numbers of VLANs, dynamically provisioned VLANs, etc).
 Most OpenFlow experiments will probably be able to use the second option, which offers a good combination of performance, features, and ease of use.
+Most !OpenFlow experiments will probably be able to use the second option, which offers a good combination of performance, features, and ease of use.
 Note that this page assumes that your campus is already connected to the GENI network core. The [wiki:ConnectivityHome GENI Connectivity] page has more information about how to get connected to the GENI core, how to get connected to other campuses through the core, etc.
 …
 = Diagram =
 The following is a minimalist diagram of an OpenFlow switch configuration that implements all three of these options:
+The following is a minimalist diagram of an !OpenFlow switch configuration that implements all three of these options:
 {{{
 …
 = Uplink =
 Port 1 is the uplink port from the campus OpenFlow switch to the regional network. It might connect directly to the regional, or it might go through other non-OpenFlow campus switches. It's a trunk port, configured to carry all of the VLANs that will be used between the campus and the GENI network core through the regional. All traffic between the campus and the core uses this port.
+Port 1 is the uplink port from the campus !OpenFlow switch to the regional network. It might connect directly to the regional, or it might go through other non-!OpenFlow campus switches. It's a trunk port, configured to carry all of the VLANs that will be used between the campus and the GENI network core through the regional. All traffic between the campus and the core uses this port.
 Port 2 is intentionally left blank, only so that if you wanted to implement this using exactly these port numbers, the next few pairs of ports would be neatly vertically stacked pairs (in a typical switch).
 …
 Ports 3 and 4 are a pair of ports that are directly connected to each other by a short cross-connect cable, to effectively implement VLAN translation at Layer 1 (aka "physical VLAN translation"). Traffic from VLAN 1750 that exits the switch on port 3 will re-enter the switch on port 4, but the switch will now consider that traffic to be on VLAN 3715. Ports 5 and 6 do the same thing, but for VLAN 1750 and VLAN 3716.
 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.
+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 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.)''
+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.
 = OpenFlow-based software VLAN translation =
+= !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). 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:
+This approach effectively implements VLAN translation in !OpenFlow. It has a few limitations:
  * The transvl controller can insert a flow rule to handle the translation, so every packet doesn't have to flow to the controller; but this sort of rewriting operation is typically done in the slow path on the switch, rather than at line speed. This can have a significant performance impact, so this approach is more suitable for experiments that don't have high performance requirements.
  * Some switch firmware will reject the tagged packets coming in on port 8, before the transvl controller sees them. In particular, the HP OpenFlow firmware and NEC Product firmware don't seem to permit this configuration; the NEC Prototype firmware does.
+ * Some switch firmware will reject the tagged packets coming in on port 8, before the transvl controller sees them. In particular, the HP !OpenFlow firmware and NEC Product firmware don't seem to permit this configuration; the NEC Prototype firmware does.
 Its main advantage is that experimenters can translate between any VLAN carried on port 7, without requiring any physical provisioning from campus network admins (e.g. when GENI tools become able to provision new inter-campus VLANs, all the way to port 7).