wiki:GEC21Agenda/ChoiceNet/gt_tool

Version 35 (modified by griff@netlab.uky.edu, 4 years ago) (diff)

--

Navigation: Up

Installing the ChoiceNet Software

At this point we will install the ChoiceNet software onto the nodes in your slice, configure the software, and start it running. In the following commands, note that you must replace the <MANIFEST_FILENAME> and <GENI USERNAME> with the values shown to you during the pre-setup phase. If you forgot to write down the MANIFEST_FILENAME, it will be ~/SLICENAME_manifest.xml (where SLICENAME is the name of your slice).

Ok. Let's get started. Execute the list of commands below on your global node GN0:

  1. Change into the choicenet bin directory where the ChoiceNet software is located:
    cd choicenet/source/bin/
    
  2. Use the getool configure command to configure the slice with the addresses, interface, bridges, etc needed by the ChoiceNet services:
    ./getool -f <MANIFEST FILENAME> -l <GENI USERNAME> -i ~/.ssh/id_rsa configure
    
  3. Now use the getool install command to install the ChoiceNet software:
    ./getool -f <MANIFEST FILENAME> -l <GENI USERNAME> -i ~/.ssh/id_rsa install
    
    This command will take several minutes to run (10-15 minutes). Since you have some time, you might as well read about the ChoiceNet software that is currently being installed. In particular, the getool is currently installing two different (network layer) ChoiceNet routing and forwarding services. The following describes the two services being installed:

    1. Source-Routed Forwarding:

      Unlike existing IP source routing protocols, this ChoiceNet forwarding service will only forward a packet if the packet contains proof that the sender paid for the forwarding service at each hop along the source-route. Each entry in the source-route not only identifies the next hop, but also provides a proof of purchase indicating that the sender paid for use of the next hop. This proof-of-purchase is checked at the next hop before the packet is allowed to proceed forward. Packets without proof are automatically dropped.

      Senders in this model contact a Path Service (PS) that discovers multiple paths between any two nodes. The send application tells the PS what type of path is desired -- for example a High Bandwidth (and presumably expensive) path, or a Low Bandwidth path (that may be substantially cheaper).The sender also includes some form of payment in the request to the PS, who in turn formulates the best path for the sender, and then returns the best path along with the proof of purchase needed to get packets through each hop along the path. Senders then include the path and proof of purchases for each router along the path in the packet header which is examined by every router along the path.

      To implement this service, we install a Click Router in the linux kernel along with a click module that implements our forwarding service. As packets enter the router they are passed to our Click module to examine them and decide whether to forward them or not. We also need to install a Path Service (PS) that sending applications contact to purchase paths. The Click routers advertise their forwarding service to the PS which in turn computes the best path (e.g., high bandwidth or low latency) and sells it to the sending application. To avoid the need to write an entirely new set of applications that are ChoiceNet-aware, we instead wrote a wrapper library that we can load with existing IPv6 applications. The wrapper library intercepts socket library calls from the application, consults a local config file to determine what type of path is needed, purchases the appropriate path from the PS, and then begins sending packets using the newly purchased path.

    2. OpenFlow-based Forwarding:

      The second ChoiceNet forwarding service uses OpenFlow packet matching to forward packets through routers. Each router in our slice runs the OVS kernel module that supports OpenFlow. To enable path selection, we implemented a ChoiceNet OpenFlow controller (based on POX) to discover the topology of OVS nodes and then advertise the OVS forwarding services to a SDN Path Service (SDN PS) (distinct from the Source-routed PS mentioned above). The SDN PS service collects these advertisements and uses them to discover paths across the topology. To avoid writing applications that must talk to the SDN PS, we install a kernel netfilter module that intercepts out-going packets and contacts the SDN PS on behalf of the application to request establishment of a path. The SDN PS determines a set of possible paths along with their prices. The SDN PS then creates a URL in Paypal and directs the application's users to that URL to pay for the path. After the path has been paided for at Paypal, the SDN PS issues commands to the ChoiceNet OpenFlow controller to set up the OVS rules needed to forward packets. The SDN PS then informs the netfilter module at the sender that packets can be allowed through.

      (The software installation process should complete soon. At that point you can continue on with the instructions below to start up some of the services described above).

  4. Use the getool to enable (turn on) CLICK on all the Router Nodes (using the getool's -R option)
    ./getool -f <MANIFEST FILENAME> -l <GENI USERNAME> -i ~/.ssh/id_rsa -R clickon
    
  5. Use the getool to start up ChoiceNet path service (PS) -- see above
    ./getool -f <MANIFEST FILENAME> -l <GENI USERNAME> -i ~/.ssh/id_rsa pathServiceOn
    
  6. Start up the ChoiceNet daemon to periodically send path advertisements to the PS
    ./sendAdvertisements.sh
    

At this point all the ChoiceNet software has been installed, and the routing/forwarding services for our ChoiceNet source-routed service are running. In the next section we will send packets across different paths using our source-routed forwarding service. Then, in the section after that, we will enable and send packets using our OpenFlow-based forwarding service.