LEFT | RIGHT |
(no file at all) | |
| 1 /** Author: Blake Hurd <naimorai@gmail.com> |
| 2 * \ingroup devices |
| 3 * \defgroup SwitchModel Switch Model |
| 4 * |
| 5 * \section SwitchModelOverview Switch Model Overview |
| 6 * |
| 7 * The ns-3 Switch device models an OpenFlow-enabled switch. It is designed to |
| 8 * express basic use of the OpenFlow protocol, with the maintaining of a virtual |
| 9 * Flow Table and TCAM to provide OpenFlow-like results. |
| 10 * |
| 11 * The functionality comes down to the Controllers, which send messages to the |
| 12 * switch that configure its flows, producing different effects. Controllers can |
| 13 * be added by the user, under the ofi namespace extends ofi::Controller. To· |
| 14 * demonstrate this, a DropController, which creates flows for ignoring every si
ngle |
| 15 * packet, and LearningController, which effectively makes the switch a more com
plicated |
| 16 * BridgeNetDevice. A user versed in a standard OFSID, and/or OF protocol, can w
rite |
| 17 * virtual controllers to create switches of all kinds of types. |
| 18 * |
| 19 * \section SwitchOpenFlowModel Switch OpenFlow Model |
| 20 * |
| 21 * The Switch device behaves somewhat according to the diagram setup as a classi
cal OFSID |
| 22 * switch, with a few modifications made for a proper simulation environment. |
| 23 * |
| 24 * Normal OF-enabled Switch |
| 25 * ----------------------------------- |
| 26 * | Secure Channel | <--OF Protocol--> | Controller is externa
l | |
| 27 * | Hardware or Software Flow Table | |
| 28 * ----------------------------------- |
| 29 * |
| 30 * ns-3 OF-enabled Switch (module) |
| 31 * ------------------------------------- |
| 32 * | m_controller->ReceiveFromSwitch() | <--OF Protocol--> | Controller is inter
nal | |
| 33 * | Software Flow Table, virtual TCAM | |
| 34 * ------------------------------------- |
| 35 * |
| 36 * In essence, there are two differences: |
| 37 * # No SSL, Embedded Controller: Instead of a secure channel and connecting to
an |
| 38 * outside location for the Controller program/machine, we currently only allow
a |
| 39 * Controller extended from ofi::Controller, an extension of an ns3::Object. Thi
s |
| 40 * means ns-3 programmers cannot model the SSL part of the interface or possibil
ity |
| 41 * of network failure. The connection to the Switch is local and there aren't an
y |
| 42 * reasons for the channel/connection to break down. <<This difference may be an |
| 43 * option in the future. Using EmuNetDevices, it should be possible to engage an |
| 44 * external Controller program/machine, and thus work with controllers designed |
| 45 * outside of the ns-3 environment, that simply use the proper OF protocol when |
| 46 * communicating messages to the switch through a tap device.>> |
| 47 * |
| 48 * # Virtual Flow Table, TCAM: Typical OF-enabled switches are implemented on a
hardware |
| 49 * TCAM. The OFSID we turn into a library includes a modelled software TCAM, tha
t produces |
| 50 * the same results as a hardware TCAM. We include an attribute FlowTableLookupD
elay, which |
| 51 * allows a simple delay of using the TCAM to be modelled. We don't endeavor to
make this |
| 52 * delay more complicated, based on the tasks we are running on the TCAM, that i
s a possible |
| 53 * future improvement. |
| 54 * |
| 55 * \section SwitchNetDeviceModel Switch Net Device Model |
| 56 * |
| 57 * The Switch network device is aimed to model an OpenFlow switch, with a TCAM a
nd a connection |
| 58 * to a controller program. With some tweaking, it can model every switch type,
as per OpenFlow's |
| 59 * extensibility. It outsources the complexity of the switch ports to NetDevices
of the user's choosing. |
| 60 * It should be noted that these NetDevices must behave like practical switch po
rts, i.e. a Mac Address |
| 61 * is assigned, and nothing more. It also must support a SendFrom function so th
at the Switch can forward |
| 62 * across that port. |
| 63 * |
| 64 * The SwitchNetDevice provides following Attributes: |
| 65 * |
| 66 * - FlowTableLookUpDelay: This time gets run off the clock when making a l
ookup in our Flow Table. |
| 67 * - Flags: OpenFlow specific configuration flags. They are
defined in the ofp_config_flags enum. Choices include: |
| 68 * OFPC_SEND_FLOW_EXP (Switch notifies controller w
hen a flow has expired), |
| 69 * OFPC_FRAG_NORMAL (Match fragment against Flow ta
ble), |
| 70 * OFPC_FRAG_DROP (Drop fragments), |
| 71 * OFPC_FRAG_REASM (Reassemble only if OFPC_IP_REAS
M set, which is currently impossible, |
| 72 * because switch implementation does not support I
P reassembly) |
| 73 * OFPC_FRAG_MASK (Mask Fragments) |
| 74 * - FlowTableMissSendLength: When the packet doesn't match in our Flow Table,
and we forward to the controller, |
| 75 * this sets # of bytes forwarded (packet is not fo
rwarded in its entirety, unless specified). |
| 76 * |
| 77 * \section SwitchModelSummary Switch Model Summary |
| 78 * |
| 79 * The ns-3 Switch device models an OpenFlow-enabled switch. It is designed to |
| 80 * express basic use of the OpenFlow protocol, with the maintaining of a virtual |
| 81 * Flow Table and TCAM to provide OpenFlow-like results. |
| 82 * |
| 83 * The functionality comes down to the Controllers, which send messages to the |
| 84 * switch that configure its flows, producing different effects. Controllers can |
| 85 * be added by the user, under the ofi namespace extends ofi::Controller. To· |
| 86 * demonstrate this, a DropController, which creates flows for ignoring every si
ngle |
| 87 * packet, and LearningController, which effectively makes the switch a more com
plicated |
| 88 * BridgeNetDevice. A user versed in a standard OFSID, and/or OF protocol, can w
rite |
| 89 * virtual controllers to create switches of all kinds of types. |
| 90 * |
| 91 * In order to use the Switch module, you must create and link the |
| 92 * OFSID (OpenFlow Software Implementation Distribution) to ns-3. |
| 93 * To do this: |
| 94 * |
| 95 * #1 Obtain the OFSID code. The suggested distribution currently is |
| 96 * Ericsson's MPLS modified OFSID, located at |
| 97 * <http://arl.wustl.edu/~mah5/openflow-mpls.tgz>. Extract it to |
| 98 * a directory named "openflow" (the path in the filesystem does |
| 99 * not matter). |
| 100 * |
| 101 * #2 Copy the waf and wscript files in the "openflow" subdirectory |
| 102 * to the directory you have extracted/copied OFSID code to. |
| 103 *· |
| 104 * #3 From the "openflow" directory, run: |
| 105 *······ |
| 106 * $ ./waf configure |
| 107 * $ ./waf build |
| 108 * |
| 109 * #4 Your OFSID is now built into a libopenflow.a library! To |
| 110 * link to an ns-3 build with this switch module, run from the ns-3-dev |
| 111 * (or whatever you have named your distribution): |
| 112 * |
| 113 * $ ./waf configure --with-openflow=path/to/openflow |
| 114 * |
| 115 * #5 Under "---- Summary of optional NS-3 features:", you should see |
| 116 * "NS-3 OpenFlow Integration : enabled", indicating the library |
| 117 * has been linked to ns-3. Run: |
| 118 * |
| 119 * $ ./waf build |
| 120 * |
| 121 * to build ns-3 and activate the Switch module. |
| 122 * |
| 123 * Once set up, you have access to some tests: |
| 124 *······ |
| 125 * For a test suite for the switch module, run: |
| 126 * |
| 127 * $ ./test.py --suite=switch |
| 128 * |
| 129 * For an example demonstrating its use in a simple learning controller/switch,
run: |
| 130 * |
| 131 * $ ./waf --run examples/switch/csma-switch |
| 132 * |
| 133 * To see it in detailed logging, run: |
| 134 * |
| 135 * $ ./waf --run "examples/switch/csma-switch -v" |
| 136 * |
| 137 * If you have any questions, read the wiki <http://www.nsnam.org/wiki/index.php
/GSOC2010OpenFlow> |
| 138 * first, and consider posting to the ns-3 developers mailing list <http://www.i
si.edu/nsnam/ns/ns-dev-list.html>, |
| 139 * but feel free to reach me at <naimorai@gmail.com> |
| 140 */ |
LEFT | RIGHT |