| 167 | | |
| 168 | | === 1.4.1 !OpenvSwitch === #OVS |
| 169 | | !OpenvSwitch (OVS) is a user-space software defined switch with !OpenFlow support, complete with its own implementation of a controller. It can, and is assumed to be, built as a kernel module throughout this page. |
| | 168 | |
| | 169 | === 1.4.1 Manually adding flows, and an intro to `dpctl`. === #flows |
| | 170 | !OpenFlow flow entries can be manually pushed to a switch; This section focuses on building links by specifying pairs of flow entries for inputs and outputs. Some controllers come with APIs and CLI commands that let you manually build and push flow entries, but that requires you to install a full controller for this purpose. A bare-bones tool, called `dpctl`, can be used to do this. There are several merits to using `dpctl`: |
| | 171 | |
| | 172 | * few requirements to build |
| | 173 | * "just works" with any switch listening for a controller using ptcp |
| | 174 | * quick OF switch setup sans controller. |
| | 175 | |
| | 176 | You can grab `dpctl` as a part of the !OpenFlow reference package from the Stanford git repo: |
| | 177 | |
| | 178 | {{{ |
| | 179 | apt-get install git-core autoconf, libtool, pkg-config |
| | 180 | git clone git://gitosis.stanford.edu/openflow.git |
| | 181 | }}} |
| | 182 | |
| | 183 | and doing `./boot.sh`, `./configure`, `make`, and `make install`. `man dpctl` gives a pretty good explanation of syntax. |
| | 184 | |
| | 185 | A few things to keep in mind about statically pushed flows are: |
| | 186 | |
| | 187 | 1. A list of flow entries behaves like an ACL. |
| | 188 | Incoming packets are matched by both entry priority value and header content. Rules with higher priority values are used before lower ones. When multiple rules have the same explicit priority number, the first match applies. |
| | 189 | |
| | 190 | 2. A rule based on higher layer matches must have the lower layer rules defined. |
| | 191 | For example, to match on IP, you must also specify the Ethertype (0x800 = IP). Not doing so causes the switch to skip checking of the IP source, destination, protocol, and ToS fields. |
| | 192 | |
| | 193 | 3. Not all switches support FLOOD. |
| | 194 | FLOOD and ALL both cause the switch to output to all ports, but differently: The former instructs the switch to use its regular (non-OpenFlow) network stack, while the latter is purely !OpenFlow based and must be supported by all OF switches. As you can guess, purely !OpenFlow switches do not support FLOOD. |
| | 195 | |
| | 196 | === 1.4.2 !OpenvSwitch === #OVS |
| | 197 | !OpenvSwitch (OVS) is a user-space software defined switch with !OpenFlow support, complete with its own implementation of a controller. It can, and is assumed to be, built as a kernel module throughout this page. Details on setup are found [http://orbit-lab.org/wiki/Documentation/OpenFlow/vSwitchImage here]. |
| 236 | | For quick setup of a network toppology using nodes sharing a medium, point-to-point links should be defined at as low a layer as possible. The next best thing (that is even better because of its flexibility) to actually going in and connecting up the topology using cables is to carve up the shared switch into VLANs. This lets you restrict the broadcast domain however you want, without hard-wiring everything, even when you are restricted to just one physical interface per node. |
| 237 | | |
| 238 | | As for !OpenFlow switching, OVS nodes (or a Mininet prototype topology) controlled by a controller supporting flow pushing (e.g. BSN or Floodllight) is the most flexible, least-hassle choice for this task. |
| 239 | | ---- |
| 240 | | = II. Topology Description Methods = #tdescr |
| 241 | | The previous section described some methods to manually configure a link. The ultimate goal in topology configuration is to be able to do it automatically for multiple links in various configurations. This implies a process along the following lines: |
| 242 | | {{{ |
| 243 | | [Topology File] -> [parse] -> [configure] -> [topology in network] |
| 244 | | }}} |
| 245 | | The Topology file must be able to describe not only the topology, but also various other factors that will change between experiments. This section attempts to explore some topology description formats that may be decent candidates for an automated system. |
| 246 | | |
| 247 | | == Contents == |
| 248 | | 2.1 [#pre2 Some Considerations] [[BR]] |
| 249 | | 2.2 [#fmts Formats] [[BR]] |
| 250 | | 2.2.1 [#gexf GEXF] [[BR]] |
| 251 | | 2.2.2 [#graphml GraphML] [[BR]] |
| 252 | | 2.3 [#morals2 Summary] |
| 253 | | |
| 254 | | == 2.1 Some Considerations == #pre2 |
| 255 | | The minimum requirements for a format are: |
| 256 | | * ability to describe a graph (node-edge relations) |
| 257 | | * ability to add descriptions to nodes and edges |
| 258 | | * can be parsed systematically |
| 259 | | |
| 260 | | Additionally useful properties are: |
| 261 | | * Being human readable/writable |
| 262 | | * support in various programming languages (notably Ruby) |
| 263 | | |
| 264 | | Some things that we would like to be able to describe are |
| 265 | | * node/edge IDs |
| 266 | | * node behavior (a switch, host, router, service...) |
| 267 | | * edge weight (throughput, connectivity, delay...) |
| 268 | | * dynamic behavior (changes across time) |
| 269 | | |
| 270 | | == 2.2 Some Formats == #fmts |
| 271 | | We focus on the formats described in [https://gephi.org/users/supported-graph-formats/ this] link. |
| 272 | | |
| 273 | | === 2.2.1 GEXF === #gexf |
| 274 | | link: http://gexf.net/format/index.html [[BR]] |
| 275 | | specifications: http://gexf.net/1.2draft/gexf-12draft-primer.pdf [attached] |
| 276 | | |
| 277 | | === 2.2.2 GraphML === #graphml |
| 278 | | link: http://graphml.graphdrawing.org/ [[BR]] |
| 279 | | specifications: http://graphml.graphdrawing.org/primer/graphml-primer.html |
| 280 | | |
| 281 | | * Base: XML |
| 282 | | * node define: node ID (string) |
| 283 | | * edge define: source, target (node IDs) |
| 284 | | * attribute definition support |
| 285 | | * attribute defaults: undirected edges, user-defined allowed |
| 286 | | |
| 287 | | Features: |
| 288 | | * parse attributes (for optimization of parsers): node degrees, number of edges/nodes |
| 289 | | * hyperedges - general relations between nodes |
| 290 | | * ports - specification of how edge meets node: source node/port, target node/port pairs |
| 291 | | |
| 292 | | [[BR]] |
| 293 | | [[BR]] |
| 294 | | [[BR]] |
| | 266 | For quick setup of a network topology using nodes sharing a medium, point-to-point links should be defined at as low a layer as possible. The next best thing (that is even better because of its flexibility) to actually going in and connecting up the topology using cables is to carve up the shared switch into VLANs. This lets you restrict the broadcast domain however you want, without hard-wiring everything, even when you are restricted to just one physical interface per node. |
| | 267 | |
| | 268 | As for !OpenFlow switching, OVS nodes (or a Mininet prototype topology) controlled by a controller supporting flow pushing (e.g. BSN or Floodllight) is the most flexible, least-hassle choice for this task. |
| | 269 | |
