Changes between Version 29 and Version 30 of GEC21Agenda/ChoiceNet/gt_tool

10/16/14 23:00:10 (8 years ago)



  • GEC21Agenda/ChoiceNet/gt_tool

    v29 v30  
    2626    a. Source-Routed Forwarding:[[BR]] [[BR]] 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.[[BR]] [[BR]] 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.[[BR]] [[BR]] 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.[[BR]][[BR]]
    2727    a. OpenFlow-based Forwarding:[[BR]] [[BR]] 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.[[BR]][[BR]]
    28  1. Use the getool to enable (turn on) tje CLICK on all the Router Nodes (using the getool's -R option)
     28 1. Use the getool to enable (turn on) CLICK on all the Router Nodes (using the getool's -R option)