Changes between Version 20 and Version 21 of GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup


Ignore:
Timestamp:
10/28/13 08:09:58 (10 years ago)
Author:
Ryan Izard
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup

    v20 v21  
    699699      ]
    700700      }}}
    701 
    702       b.  Using your favorite text editor, open the '''/root/SwitchingScripts/gec18_switch_to_wifi.py''' script. (Do not open the '''/root/SwitchingScripts/gec18_switch_to_wifi.sh''' script. This is simply a wrapper for the python script with the flows themselves.) In the python script, browse down to were you see the definition of '''flow1'''. Right before this definition are a few variables we need to check/set. They define the MAC addresses of the physical and tap interfaces. Recall that we need to rewrite these in our flows. Why is this so? Well, WiFi and WiMAX have an association process. This process provides the AP/BS with the MAC address of the associated client. The AP/BS will filter incoming packets by associate MACs. If an ingress packet contains a source MAC that is not known to the AP/BS, it will be dropped. Thus, any packets we send from our tap interface need to have their source MAC addresses rewritten so that the AP or BS will recognize the source and thus accept the packets. Using the MAC of the WiMAX interface noted in prior steps, set the MAC address of the '''wifi_mac''' and '''wimax_mac''' to the MAC address of the WiMAX MAC. This might seem odd, but in order to simplify this tuturial and experiment, we have "spoofed" the actual MAC of the WiFi interface to that of the WiMAX interface, thus making both interfaces appear to have the same MAC. You can see this for yourselves in the '''gec18_setup.sh''' script of the client. This allows the server to address the client with a single MAC.
    703       c. Next, save the WiFi switching script and open '''/root/SwithingScripts/gec_18_switch_to_wimax.py'''. Repeat step 5b.
     701      c.  Using your favorite text editor, open the '''/root/SwitchingScripts/gec18_switch_to_wifi.py''' script. (Do not open the '''/root/SwitchingScripts/gec18_switch_to_wifi.sh''' script. This is simply a wrapper for the python script with the flows themselves.) In the python script, browse down to were you see the definition of '''flow1'''. Right before this definition are a few variables we need to check/set. They define the MAC addresses of the physical and tap interfaces. Recall that we need to rewrite these in our flows. Why is this so? Well, WiFi and WiMAX have an association process. This process provides the AP/BS with the MAC address of the associated client. The AP/BS will filter incoming packets by associate MACs. If an ingress packet contains a source MAC that is not known to the AP/BS, it will be dropped. Thus, any packets we send from our tap interface need to have their source MAC addresses rewritten so that the AP or BS will recognize the source and thus accept the packets. Using the MAC of the WiMAX interface noted in prior steps, set the MAC address of the '''wifi_mac''' and '''wimax_mac''' to the MAC address of the WiMAX MAC. This might seem odd, but in order to simplify this tuturial and experiment, we have "spoofed" the actual MAC of the WiFi interface to that of the WiMAX interface, thus making both interfaces appear to have the same MAC. You can see this for yourselves in the '''gec18_setup.sh''' script of the client. This allows the server to address the client with a single MAC.
     702      d. Next, save the WiFi switching script and open '''/root/SwithingScripts/gec_18_switch_to_wimax.py'''. Repeat step 5b.
    704703
    705704   6. The configuration of the client is now complete. The next step is to configure the server node. For the tutorial at GEC18, the server has been configured for you. Not only does this save time, but it also allows multiple clients to share the same server node. The process is nearly identical to that of the client node. The difference is that you need to assign a different IP to the tap interface and provide the IP of the client instead of the the IP of the server. Another key difference is how the flows work. On the client, the flows inserted will switch packets to the interface the client wishes to use. As a simplification to this experiment and tutorial, the server's flows are configured to always listen and send packets out its WiFi and WiMAX interfaces. In other words, no switching takes place on the server node. The flows that are inserted when the server is configured and run are the flows that will remain for the lifetime of the experiment.