-
Notifications
You must be signed in to change notification settings - Fork 2
License
gareging/SDN_Framework
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
= SDN Framework (Green Computing) SDN Framework module is an extension of RYU controller that provides the generic functionality for collecting data from servers on the network, making routing decisions and installing SDN flows into OVS switch. In this application of SDN Framework, the SDN controller schedules client TCP requests to data servers based on their Green Energy capacities. The servers send the green energy values by UDP "info-packets". = Architecture The SDN Framework consists of a module for RYU controller and a server module. The topology on which SDN Framework works consists of SDN controller, OVS switches connected to SDN controller, client and server hosts connected to OVS switches. The OVS switches might be connected with each other. = Installation on GENI Reserve resources using Rspec FRAMEWORK.xml. FRAMEWORK.xml generates the topology with one SDN controller, three OVS switches, three server and two client hosts per each switch. OVS switches are connected to each other. Each host is assigned with a private IP address from subnet 10.0.0.0/8. Using Rspec GENI runs different scripts on each of the reserved machines: a) On servers, scripts: * modify the routing table in order to guarantee that any packet to IP address from subnet 10.0.0.0/24 will be sent through interface eth1 (connected to OVS switch) * add an alias "controller-host" for IP address 10.10.10.10 * download from git repository the xlsx file with green energy data (/tmp/server) * download python script server.py for server-controller communication (/tmp/server) * installs Apache2 Web Server (/var/www/) b) On OVS switches, scripts: * configure OVS bridge * add interfaces to the OVS bridge except the one connected to the controller c) On SDN controller, scripts: * install RYU controller (/tmp/ryu/) * install SDN Framework module including the configuration file (/tmp/ryu/Controller) = Prepare for the experiment 1. To run the server scripts simultaneously the script start_server.sh can be used. Before running the script, it must be edited for successful remote ssh. Use the template to update it. Then run the script. 2. ssh to the controller host. In the configuration file (/tmp/config) we specify a) the parameters that SDN controller will request from servers b) the weights for these parameters (used in the scheduling algorithm) b) the frequency of the UDP "info messages" coming from servers. c) the start date of the emulation (in the current implementation it is merely for the output, does not effect the scheduling algorithm or data received from servers at all). To run SDN Framework (Green Energy), run these commands: cd /tmp/ryu; ./bin/ryu-manager Controller/GEController.py If successful, you will see that servers register at the SDN controller. Example of the output: loading app Controller/GEController.py loading app ryu.controller.dpset loading app ryu.controller.ofp_handler instantiating app Controller/GEController.py of SDNFramework instantiating app ryu.controller.dpset of DPSet instantiating app ryu.controller.ofp_handler of OFPHandler Server: dpid:200965445886537, serverID:0, serverIP: 10.10.1.1 Server: dpid:200965445886537, serverID:1, serverIP: 10.10.3.1 Server: dpid:200965445886537, serverID:2, serverIP: 10.10.2.1 Server: dpid:55309789427013, serverID:3, serverIP: 10.10.10.1 Server: dpid:55309789427013, serverID:4, serverIP: 10.10.9.2 Server: dpid:55309789427013, serverID:5, serverIP: 10.10.8.1 Server: dpid:82177703257927, serverID:6, serverIP: 10.10.13.1 Server: dpid:82177703257927, serverID:7, serverIP: 10.10.20.1 Server: dpid:82177703257927, serverID:8, serverIP: 10.10.14.1 3. ssh to client hosts and make a TCP request to one of the servers (for example, server-1). You can run the command wget http://server-1/. On the controller host, you should see that TCP request was scheduled to one of the servers. You should see its green energy values, the simulation date and a current number of users on each server. Example: L: 2001-01-01 05:00:00 325 325 325 299 294 294 260 255 242 E: 2001-01-01 06:00:00 0.0 0.0 0.0 0.0 0.0 0.0 6333.75124781 7077.17304762 4507.96520407 = Code structure 1. server.py. Sends the info packets to the controller with data taken from Excel file (Solar Energy values). Arguments: (a) The location ID 1 - ELMIRA 2 - WATERTOWN 3 - WESTHAMPTON 4 - HOMESTEAD 5 - ORLANDO 6 - TYNDALL 7 - LOMPOC 8 - MARCH 9 - TRAVIS (b) The start date in format: YYYY-mm-dd. Currently, only 2001 year's data is available. server.py sends the initial "Hello" message (UDP packet) to SDN controller in order to register the server at the controller and get its serverID, the list of required parameters, plus how often they must be sent. If timeout reached, server resends the packet. If the message from controller received, a server sends the info packet starting from the day passed in the argument (b). In order to synchronize "info packets”, each server does not send the next info packet until it receives "OK" packet from the controller. If by some reason controller was restarted, the registration of the server will be lost, so a server will have to re-register by sending another "Hello" message. If a server was restarted and re-sends "hello" message, the controller will match its IP address to registered IP addresses and will return back the existing serverID for that server. serverID + ____________________ required parameters _____________________ | | and sending rate | | ------->| Send hello message |------------------->| Send info packets | .---->|____________________| .--> |_____________________| | | | | | | Timeout | | | | |<-----------------------v <----------------------v | | Received "OK" from controller | | => send next day info | | Received error message | <-------------------------------------------------------------------v 2. GEController.py: handles arp requests, collects data from servers, makes scheduling decisions and install flows in OVS switches. At the initialization stage, reads the configuration file. def _event_switch_enter_handler(self, ev) - on switch connection event: a) Initializes data structures for the switch b) Installs miss-flows c) Sends a switch-discover broadcast message in order to establish switch neighbourship and the ports used for switch-to-switch connection def add_flow(self, datapath, match, act, priority=0, idle_timeout=0, flags=0, cookie=0) - flow installing routine. def _packet_in_handler(self, ev) - on packet in connection event: parses the packet, recognizes the protocol and calls the corresponding functions def ip_packet_handler (self, dpid, datapath, eth, msg, pkt, in_port, ipv4_pkt) - IP packet handling: analyzes upper-level protocol. UDP is allowed only for controller management and the corresponding function is called. For TCP requests controller call function PropFair(dpid, configuration) which makes scheduling decisions on what server will serve the TCP request. Before the packet is sent out to the corresponding port on the OVS switch, SDN controller install flows for both direction (client-server and server-client). These flows are used to rewrite headers of the matched packets and ouput them to the ports chosen by SDN controller. They are removed from the flow table in case of reaching idle timeout. For the simulation purpose, SDN controller installs flows for the pair (Client IP address, Client TCP port). By that, we can simulate multiple parallel TCP requests from the same machine. 3. def server_controller_communication(self, dpid, datapath, eth, msg, in_port, ipv4_pkt, udp_segment) - handles server-controller and controller-OVS switch communication. All server UDP packets match the miss-flow so they directed to the controller. Similarly, switch discover packets reach the controller so it can get the topology of the network. 4. def send_udp_reply(...), def send_arp_reply(...) - routines for sending and generatingUDP and ARP messages from the controller. 5. def flow_removal_handler(self, ev) - handles flow removal flag. 6. def remove_table_flows(self, datapath, table_id, match) - route to remove all flows from the flow table. 7. def PropFair(self, dpid, conf_src) - the scheduler routine. Takes as input the configuration for the request and the switch from which comes that request. PropFair(..) is making decisions based on the following factors: (a) Green energy values. (b) Delays in case of rerouting the packet to a server connected to the neighboring switch. (c) Weight for each of these parameters.
About
No description, website, or topics provided.
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published