Changes between Version 52 and Version 53 of Internal/OpenFlow/Controllers/MultiCtl


Ignore:
Timestamp:
Mar 1, 2013, 3:00:12 AM (11 years ago)
Author:
akoshibe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/Controllers/MultiCtl

    v52 v53  
    99[#iii Subpages] - extra notes related to this page [[BR]]
    1010[#iv Logs] - records of work
    11  [#w1 week1][[BR]]
    12  [#w2 week2][[BR]]
    13  [#w3 week3][[BR]]
    14  [#w4 week4][[BR]]
    15  [#w5 week5][[BR]]
    16  [#w6 week6][[BR]]
    17  [#w7 week7][[BR]]
    18  [#w8 week8][[BR]]
    19  [#w9 week9][[BR]]
    20  [#w10 week10][[BR]]
    21  [#w11 week11][[BR]]
    22  [#w12 week12][[BR]]
    23  [#w13 week13][[BR]]
    24  [#w15 week 15][[BR]]
    25  [#w17 week 17][[BR]]
    26  [#w19 week 19][[BR]]
    27  [#w20 week 20][[BR]]
     11 || [#w1 week1] || [#w7 week7]   || [#w13 week13]  || ||
     12 || [#w2 week2] || [#w8 week8]   || [#w15 week 15] || ||
     13 || [#w3 week3] || [#w9 week9]   || [#w17 week 17] || ||
     14 || [#w4 week4] || [#w10 week10] || [#w19 week 19] || ||
     15 || [#w5 week5] || [#w11 week11] || [#w20 week 20] || ||
     16 || [#w6 week6] || [#w12 week12] || [#w23 week 23] || ||
     17[[BR]]
     18 
    2819== Overview. == #i
    2920The basic architecture for an !OpenFlow network is a client - server (switch - controller) model involving a single controller and one or more switches. Networks can host multiple controllers. !FlowVisor virtualizes a single network into slices so that it can be shared amongst various controllers, and the newest !OpenFlow standard (v1.3.0) defines ''equal'', ''master'' and ''slave'' controllers to coexist as part of a redundancy scheme in what would be a single slice. A multi-controller scheme that isn't really explored yet is one where each controller has a different function, and cooperate.
     
    488479 3. Filters and actions: How the controller responds to control messages, and decides where packets it received goes. This is part of the dispatcher, which I kind of see as a event-driven scheduler.
    489480 4. Application modules: The applications that leverage the first three to function. They live in the local process chain of 2. 
     481
     482==== w/o 2/24-3/2 ==== #w23
     483Many revisions to things:
     484 * update to Mininet 2.0.0
     485 * update to topologizer
     486 * first working example of peer proxy
     487Details as follows:
     488
     489 1. Mininet update. Scripts break without it. This involves the rough following steps:
     490    1. removal of old mininet, openflow, and ovs source directories
     491    1. pull from mininet repo
     492    1. kill any ovs processes (ovs-db and vswitchd), unload kernel module
     493    1. manual restart of ovs once re-installed, if mininet complains about connection refusal (sometimes ovs runs, but not properly).
     494 Mininet's syntax is a bit different in 2.0. starting a linear topology with 3 switches, to a remote controller becomes:
     495 {{{
     496 sudo mn --topo=linear,3 --controller=remote,ip=192.168.1.20
     497 }}}
     498
     499 2. Topologizer (makeshift script for launching multiple floodlights). Added ways to launch with terminals, no logging, backgrounded etc. Killing of processes.
     500 
     501 3. peer proxy: layer 1 of the control plane node, which supports route setup and routing to services, which includes peer forwarding of services. In addition:
     502    * invisibility of peers to one another, since we don't want peers to ask each other for services they don't host. Peers do not show up in each others' route tables.
     503    * service advertisement propagation, across to peers that don't see the service.   
    490504----
    491505[#home Home.]