xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun  

To solve this problem, in your terminal, run the following command to install xcode command line.

xcode-select --install  

References:
Xcode IDE

ICN indexes contents not in form of location, but naming.
Contents are not stored in the provider's server, but everywhere.
User does not have to care about the location of content, but only the contents themselves. By sending a request of content name, the network will provide the content without DNS to resolve the name. (may need but not resolve the locations).

The search engine currently cannot handle this kindle of searching, i.e., searching contents name and return a location of contents.
And the network does not need DNS. ICN needs a new naming-based search engine to discovery contents.
If contents are everywhere (at least, not centralized in provider's server), how the search engine should perform and what kind of results should return.
What the user wants, when the user search a phase.

Linear Programming is:

"A method to allocate scarce resources to competing activities in an optimal manner when the problem can be expressed using a linear objective function and linear inequality constraints."

A linear program consists of:

• a set of variables
• a linear objective function
• a set of linear constraints

Decision Variables
The variables in a linear program are a set of quantities that need to be determined in order to solve the problem.

The variables are sometimes called decision variables because the problem is to decide what value each variable should take.

Typically, the variables represent the amount of a resource to use or the level of some activity.

Objective Function
The objective of a linear programming problem will be to maximize or to minimize some numerical value.

Constraints
Constraints define the possible values the variables of a linear programming problem may take. They typically represent resource constraints, or the minimum or maximum level of some activity.

Non-negativity Constraints
For technical reasons, the variables of linear programs must always take non-negative values.

References
Linear Programming

sudo iwlist wlan0 scan  

Configure wpa_supplicant.conf file:

sudo vi /etc/wpa_supplicant/wpa_supplicant.conf  
network={  
    ssid="The_ESSID_from_earlier"
    psk="Your_wifi_password"
}

Restart wlan0 or reboot:

sudo ifdown wlan0 and sudo ifup wlan0, or reboot your Raspberry Pi with sudo reboot.

Reference:

Raspberry Pi Website

Hose服务模型的实现：
在hose模型中，VPN用户需要指定一些列的终端，以及终端到终端的性能保证。每一个终端到网络之间的连接可以认为是一个软管(hose), 并且包含：

1. 从终端到网络的(到其他VPN终端的)聚合外出(outgoing)流量的容量(capacity)需求
2. 从网络到终端的(从其他VPN终端来的)聚合进入流量的容量需求。
3. 从软管接口(hose interface)角度来看的的聚合流量的性能保证

举一个论文里的例子： 用户的四个网络A, B, C, D与服务提供网络连接，其中B, C, D与A之间的收发速度分别不超过3Mbps, B, C, D之间的收发速率不超过2Mbps, 则软管模型(hose model)可以有下面的图表示。 红色的代表软管。

从用户的角度看，Hose的优点是：

1. 规格简单，只需要指定每个软管终端的流进和流出速率
2. 灵活，从一个软管终端收发的数据可以随意地分配到提供与软管大小相符合的其他终端上
3. 复用增益，根据统计的复用增益，软管速率可以小于用户管道(custom-pipe)的聚合速率
4. 易于描述，软和的需求可以被很容易的描述出来因为每一个单独的源-目的地的流量的统计上的变量可以很容易的聚合到软管里。

References
1 N.G. Duffield, et al., "A flexible model for resource management in virtual private networks," ACM SIGCOMM Computer Communication Review. Vol. 29. No. 4. ACM, 1999.

1. Download CCNx Sources from website

2. untar:
   $tar -zxvf distillery-ccnx-absinthe-source-current.tgz

3. Enter the ccnx directory
   $cd distillery-cnnx

4. Create two directory for ccnx as follow:
   /usr/local/ccnx/
/usr/local/parc/

5. Install dependency:

   $ sudo apt-get update
   $sudo apt-get install build-essential libssl-dev openssl libevent-dev autoconf automake libtool python
   $sudo apt-get install uncrustify doxygen

6. $make
There should be no error

References:
CCNx Downloads

netem provides Network Emulation functionality for testing protocols by emulating the properties of wide area networks. The current version emulates variable delay, loss, duplication and re-ordering.

TC(Traffic Control) is a Linux command to configure the Linux kernel's Network scheduler to show and manipulate Network traffic control settings.

Traffic Control consists of the following:
SHAPING
SCHEDULING
POLICING

Processing of traffic is controlled by three kinds of objects: qdiscs, classes and filters

By issuing the following command, packets with source IP address 192.168.10.109/32 and source port 59734 and 52049 is delayed 2000ms on eth0

sudo tc qdisc add dev eth0 root handle 1: prio  
sudo tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 2000ms  
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 3  \  
      u32 match ip src 192.168.10.109/32 match ip sport 59734 0xffff flowid 1:3
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 3 \  
      u32 match ip sport 52049 0xffff flowid 1:3

References:
NETEM-LinuxFoundation
TC WIKI
Linux man page

Iperf is a commonly used network testing tool that can create Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) data streams and measure the throughput of a network that is carrying them.

GENERAL OPTIONS

-p --port n
The server port for the server to listen on and the client to connect to. This should be the same in both client and server. Default is 5201.

-i --interval n
Sets the interval time in seconds between periodic bandwidth, jitter, and loss reports. If non-zero, a report is made every interval seconds of the bandwidth since the last report. If zero, no periodic reports are printed. Default is zero.

-F, --file name
client-side: read from the file and write to the network, instead of using random data;
server-side: read from the network and write to the file, instead of throwing the data away.

-A, --affinity n/n,m-F
Set the CPU affinity, if possible (Linux and FreeBSD only). On both the client and server you can set the local affinity by using the n form of this argument (where n is a CPU number). In addition, on the client side you can override the server’s affinity for just that one test, using the n,m form of argument. Note that when using this feature, a process will only be bound to a single CPU (as opposed to a set containing potentialy multiple CPUs).

-B, --bind host
Bind to host, one of this machine's addresses. For the client this sets the outbound interface. For a server this sets the incoming interface. This is only useful on multihomed hosts, which have multiple network interfaces.

-V, --verbose
give more detailed output

-J, --json
output in JSON format

--logfile file
send output to a log file. (new in iPerf 3.1)

--d, --debug
emit debugging output. Primarily (perhaps exclusively) of use to developers.

-v, --version
Show version information and quit.

-h, --help
Show a help synopsis and quit.

SERVER SPECIFIC OPTIONS

-s, --server
Run iPerf in server mode. (This will only allow one iperf connection at a time)

-D, --daemon
Run the server in background as a daemon.

-I, --pidfilefile
write a file with the process ID, most useful when running as a daemon. (new in iPerf 3.1)

CLIENT SPECIFIC OPTIONS

-c, --client host
Run iPerf in client mode, connecting to an iPerf server running on host.

--sctp
Use SCTP rather than TCP (Linux, FreeBSD and Solaris). (new in iPerf 3.1)

-u, --udp
Use UDP rather than TCP. See also the -b option.

-b, --bandwidth n[KM]
Set target bandwidth to n bits/sec (default 1 Mbit/sec for UDP, unlimited for TCP). If there are multiple streams (-P flag), the bandwidth limit is applied separately to each stream. You can also add a ’/’ and a number to the bandwidth specifier. This is called "burst mode". It will send the given number of packets without pausing, even if that temporarily exceeds the specified bandwidth limit.

-t, --time n
The time in seconds to transmit for. iPerf normally works by repeatedly sending an array of len bytes for time seconds. Default is 10 seconds. See also the -l, -k and -n options.

-n, --num n[KM]
The number of buffers to transmit. Normally, iPerf sends for 10 seconds. The -n option overrides this and sends an array of len bytes num times, no matter how long that takes. See also the -l, -k and -t options.

-k, --blockcount n[KM]
The number of blocks (packets) to transmit. (instead of -t or -n) See also the -t, -l and -n options.

-l, --length n[KM]
The length of buffers to read or write. iPerf works by writing an array of len bytes a number of times. Default is 128 KB for TCP, 8 KB for UDP. See also the -n, -k and -t options.

-P, --parallel n
The number of simultaneous connections to make to the server. Default is 1.

-R, --reverse
Run in reverse mode (server sends, client receives).

-w, --window n[KM]
Sets the socket buffer sizes to the specified value. For TCP, this sets the TCP window size. (this gets sent to the server and used on that side too)

-M, --set-mss n
Attempt to set the TCP maximum segment size (MSS). The MSS is usually the MTU - 40 bytes for the TCP/IP header. For ethernet, the MSS is 1460 bytes (1500 byte MTU).

-N, --no-delay
Set the TCP no delay option, disabling Nagle's algorithm. Normally this is only disabled for interactive applications like telnet.

-4, --version4
only use IPv4.

-6, --version4
only use IPv6.

-S, --tos n
The type-of-service for outgoing packets. (Many routers ignore the TOS field.) You may specify the value in hex with a '0x' prefix, in octal with a '0' prefix, or in decimal. For example, '0x10' hex = '020' octal = '16' decimal. The TOS numbers specified in RFC 1349 are:

IPTOS_LOWDELAY     minimize delay        0x10
IPTOS_THROUGHPUT   maximize throughput   0x08
IPTOS_RELIABILITY  maximize reliability  0x04
IPTOS_LOWCOST      minimize cost         0x02

-L, --flowlabel n
Set the IPv6 flow label (currently only supported on Linux).

-Z, --zerocopy
Use a "zero copy" method of sending data, such as sendfile(2), instead of the usual write(2). This uses much less CPU.

-O, --omit n
Omit the first n seconds of the test, to skip past the TCP TCP slowstart period.

-T, --title str
Prefix every output line with this string.

-C, --linux-congestion algo
Set the congestion control algorithm (Linux only for iPerf 3.0, Linux and FreeBSD for iPerf 3.1).

Reference:
Iperf

This module first gets network's graph by using openflow.discovery module mentioned in Discovery Topology in POX. The discovery module raises linkEvent if any link between two switches is added or removed. Then, this link is added to (or removed from) the network's graph. After controller got the network's graph, it calls nx.shortest_path to find the shortest path between host1 and host2.

from pox.core import core  
import pox.openflow.libopenflow_01 as of  
from pox.lib.revent import *  
from pox.lib.recoco import Timer  
from collections import defaultdict  
from pox.openflow.discovery import Discovery  
from pox.lib.util import dpid_to_str  
import time  
import networkx as nx


class topoDiscovery(EventMixin):  
    G = nx.Graph()
    def __init__(self):
        def startup():
            core.openflow.addListeners(self, priority = 0)
            core.openflow_discovery.addListeners(self)
        core.call_when_ready(startup, ('openflow','openflow_discovery'))
        print "init completed"
    def _handle_LinkEvent(self, event):
        l = event.link
        sw1 = l.dpid1
        sw2 = l.dpid2
        pt1 = l.port1
        pt2 = l.port2
        self.G.add_node( sw1 )
        self.G.add_node( sw2 )
        if event.added:
            self.G.add_edge(sw1,sw2)
        if event.removed:
            try:
                self.G.remove_edge(sw1,sw2)
            except:
                print "remove edge error"
        print 'link added is %s'%event.added
        print 'link removed is %s' %event.removed
        print 'switch1 %d' %l.dpid1
        print 'port1 %d' %l.port1
        print 'switch2 %d' %l.dpid2
        print 'port2 %d' %l.port2
        print self.G.edges()

        try:
            print nx.shortest_path(self.G,1,6)
        except:
            print "no such Graph"
def launch():  
    core.registerNew(topoDiscovery)

run topoDiscovery and openflow.discovery

sudo ./pox/pox.py topoDiscovery openflow.discovery

Shortest path is shown as following:

[1, 2, 3, 6]

References:
Install NetworkX
Discovery Topology in POX

Controller can query about datapath's current state using the OFPT_STATS_REQEST message. The structure of OFPT_STATS_REQUEST message is shown as following:

struct ofp_stats_request {  
    struct ofp_header header;
    uint16_t type; /* One of the OFPST_* constants. */
    uint16_t flags; /* OFPSF_REQ_* flags (none yet defined). */
    uint8_t body[0]; /* Body of the request. */
};
OFP_ASSERT(sizeof(struct ofp_stats_request) == 12);

The switch responds with one or more OFPT_STATS_REPLY messages:

struct ofp_stats_reply {  
    struct ofp_header header;
    uint16_t type; /* One of the OFPST_* constants. */
    uint16_t flags; /* OFPSF_REPLY_* flags. */
    uint8_t body[0]; /* Body of the reply. */
};
OFP_ASSERT(sizeof(struct ofp_stats_reply) == 12);

In both the request and response, the type field specifies the kind of information being passed and determines how the body field is interpreted:

enum ofp_stats_types {  
/* Description of this OpenFlow switch.
* The request body is empty.
* The reply body is struct ofp_desc_stats. */
OFPST_DESC,  
/* Individual flow statistics.
* The request body is struct ofp_flow_stats_request.
* The reply body is an array of struct ofp_flow_stats. */
OFPST_FLOW,  
/* Aggregate flow statistics.
* The request body is struct ofp_aggregate_stats_request.
* The reply body is struct ofp_aggregate_stats_reply. */
OFPST_AGGREGATE,  
/* Flow table statistics.
* The request body is empty.
* The reply body is an array of struct ofp_table_stats. */
OFPST_TABLE,  
/* Physical port statistics.
* The request body is struct ofp_port_stats_request.
* The reply body is an array of struct ofp_port_stats. */
OFPST_PORT,  
/* Queue statistics for a port
* The request body defines the port
* The reply body is an array of struct ofp_queue_stats */
OFPST_QUEUE,  
/* Vendor extension.
* The request and reply bodies begin with a 32-bit vendor ID, which takes
* the same form as in "struct ofp_vendor_header". The request and reply
* bodies are otherwise vendor-defined. */
OFPST_VENDOR = 0xffff  
};

Since we want to get the table statistics information from switch, we need to send OFPT_STATS_REQUEST packet with type field OFPST_TABLE.

The body of the reply consists of an array of the following:

/* Body of reply to OFPST_TABLE request. */
    struct ofp_table_stats {
    uint8_t table_id; /* Identifier of table. Lower numbered tables are consulted first. */
    uint8_t pad[3]; /* Align to 32-bits. */
    char name[OFP_MAX_TABLE_NAME_LEN];
    uint32_t wildcards; /* Bitmap of OFPFW_* wildcards that are supported by the table. */
    uint32_t max_entries; /* Max number of entries supported. */
    uint32_t active_count; /* Number of active entries. */
    uint64_t lookup_count; /* Number of packets looked up in table. */
    uint64_t matched_count; /* Number of packets that hit table. */
};
OFP_ASSERT(sizeof(struct ofp_table_stats) == 64);  

According to the body of reply message, following information about flow table in switch can be obtained.

Max number of entries supported  
Number of active entries  
Number of packets looked up in table  
Number of packets that hit table  

The following code is an example for monitoring active entries in switches based on the topology mentioned in Create a custom topology in Mininet (2).

from pox.core import core  
import pox.openflow.libopenflow_01 as of  
from pox.lib.revent import *  
from pox.lib.recoco import Timer  
from collections import defaultdict  
from pox.openflow.discovery import Discovery  
from pox.lib.util import dpid_to_str  
import time

class tableStats(EventMixin):  
  def __init__(self,interval = 10):
    self.tableActiveCount = {}
    self.interval = interval
    core.openflow.addListeners(self)
  def _handle_ConnectionUp(self,event):
    print "Switch %s has connected" %event.dpid
    self.sendTableStatsRequest(event)
  def _handle_TableStatsReceived(self,event):
    sw = 's%s'%event.dpid
    self.tableActiveCount[sw] = event.stats[0].active_count
    print "TableStatsReceived"
    print self.tableActiveCount
    Timer(self.interval, self.sendTableStatsRequest,args=[event])
  def sendTableStatsRequest(self, event):
    sr = of.ofp_stats_request()
    sr.type = of.OFPST_TABLE
    event.connection.send(sr)
    print "Send table stat message to Switch %s " %event.dpid

def launch(interval = '10'):  
  interval = int(interval)
  core.registerNew(tableStats,interval)

The above codes send table statistic request once controller and switches get connected. And when controller receives TableStatsReceived event, controller handles this event and sends table statistic request again in a interval (default is 10 seconds).

This program can be run by input

sudo ./pox/pox.py tableStat --interval=1

and the output is a dictionary like

{'s3': 0, 's2': 0, 's1': 0, 's6': 0, 's5': 0, 's4': 0}

References:
OpenFlow Switch Specification Version1.0.0
POX WIKI - Requesting statistics from switches

In order to write a publish/subscribe program, we need to create 3 classes -- an event class, a publisher class, and a subscriber class. The relation between these 3 classes is shown as following figure.

Event Class

Event Class can convey message from publisher to subscriber. In POX, events are subclasses of revent.Event. So to create an event, simply create a subclass of Event. You can add any extra attributes or methods you want.

First, create a python file named publisher.py

vi ./pox/ext/publisher.py  

In publisher.py, we first create an event for publisher raise.
This event class is called TestEvent, it inherits from Event class. In its constructor(init), there are two arguments arg1 and arg2. When publisher raises this event, publisher can pass two arguments into this event.

from pox.core import core  
from pox.lib.revent import *  
import pox  
import pox.openflow.libopenflow_01 as of

class TestEvent(Event):  
  def __init__(self,arg1,arg2):
    Event.__init__(self)
    print "TestEvent is initialed"
    self.par = arg1
    self.par2 = arg2

Publisher Class

Then we create a publisher in the same python file publisher.py

A publisher inherits from revent.EventMixin and declares which events it raises in a class-level variable called _eventMixin_events = set([TestEvent,]). Here publisher adds TestEvent into the eventMixin sets. Then this publisher can raise TestEvent which we created above.

Then we define a function called _handle_GoingUpEvent. This function listens to core(as the code self.listenTo(core) in __init__), and handle the GoingUpEvent event raised by core. When publisher receive GoingUpEvent, publisher will listen to openflow (self.listenTo(core.openflow)).

Next we define a function publishEvent which can raise the TestEvent.

In publishEvent function, self.raiseEvent(Eventclass, **args) can raise an Event. The first argument of raiseEvent is the event's class name, and follow the event's class name are arguments for events class.

Next we define a function _handle_PacketIn . This function can handle PacketIn event raised by openflow. When publisher receive PacketIn event, publisher call foo and foo raises the TestEvent event.

Last we define a function called launch which can register publisher into POX's core.

class Publisher(EventMixin):  
  """
  This is a Class for Publisher which can raise an event
  """
  _eventMixin_events = set([TestEvent,])
  def __init__(self):
    self.listenTo(core)
    print "Publisher is intialed\n"

  def _handle_GoingUpEvent(self, event):
    self.listenTo(core.openflow)
    print "this is in publisher, what is this for?\n"

  def publishEvent(self):
    print "publishEvent is called, will raise the test Event\n"
    self.raiseEvent(TestEvent,"firstPar","secondPar")
    print "foo raised event\n"

  def _handle_PacketIn(self,event):
    print "PacketIn event is raised,packetIn\n"
    self.publishEvent()
    return

def launch():  
  core.registerNew(Publisher)

Subsrciber Class

Next, we are going to create a Subscriber Class which can listen to Publisher and handle the TestEvent passed by Publisher.

We created a new python file called subscriber.py

In POX, a subscriber inherits from revent.EventMixin.

The Subscriber first listens to POX's core, and once GoingUpEvent is raised by core, the Subscriber listen to Publisher which has been registered into POX's core.

Then we define a function _handle_TestEvent which can handle TestEvent raised by Publisher and process event's arguments passed from Publisher.

Last function launch registers Subscriber into POX's core

vi ./pox/ext/subscriber.py  

import pox  
import pox.openflow.libopenflow_01 as of  
from pox.core import core  
from pox.lib.revent import *

class Subscriber(EventMixin):  
  def __init__(self):
    self.listenTo(core)

  def _handle_GoingUpEvent (self, event):
    self.listenTo(core.Publisher)
    print "This is in subsriber, what is this for?\n"

  def _handle_TestEvent(self,event):
    print "Test Event is raised,I heard TestEvent\n"
    print "EventPar:", event.par
    print "EventPar:", event.par2
#    event.eventMethod()
    return

def launch():  
  core.registerNew(Subscriber)

So far, We have created a event class called TestEvent, a publisher class called Publisher and a subscribe class called Subscriber. And we added TestEvent into the _eventMxin_events set and created a function called publishEvent which can raise TestEvent and pass arguments into event.

In POX the function whose form is starting _handle_eventName(self), is a function that handle the eventName. Such as def _handle_GoingUpEvent(self, event) can handle the event GoingUpEvent event raised by POX core, def _handle_PacketIn(self, event) can handle the event PacketIn raised by openflow, and def _handle_TestEvent(self, event) can handle the event TestEvent raised by Publisher.

The whole process of publish/subscribe system of above codes in POX is shown as following step:

1. Publisher and Subscriber are registered into POX's core
2. Publisher and Subscriber listen to POX's core
3. Publisher and Subscriber receive an event called GoingUpEvent raised by POX's core
4. Publisher listens to core.openflow when it received GoingUpEvent, whereas Subscriber listens to Publisher when it received GoingUpEvent
5. Publisher receives a PacketIn event and then raise the TestEvent and pass two arguments
6. Subscriber receives the TestEvent event and parses the two arguments passed with the event.

References:
[1] POX Wiki The Event System
[2] Wiki Publish–subscribe pattern
[3] POX中创建新的Event

This component sends specially-crafted LLDP messages out of OpenFlow switches so that it can discover the network topology. It raises events (which you can listen to) when links go up or down.
More specifically, you can listen to LinkEvent events on core.openflow_discovery. When a link is detected, such an event is raised with the .added attribute set to True. When a link is detected as having been removed or failed, the .removed attribute is set to True. LinkEvent also has a .link attribute, which is a Link object, and a port_for_dpid(<dpid>) method (pass it the DPID of one end of the link and it will tell you the port used on that datapath).
Link objects have the following attributes:

A number of the other example components use discovery and can serve as demonstrations for using discovery. Obvious possibilities are misc.gephitopo and forwarding.l2multi.

This example shows how to discovery topology created in previous post.
Component Discovery mentioned above is used to find discovery topology.
This component can return the dpid and ports of switches involved in the link.

Create a python file in ~/pox/ext/topoDiscovery.py

vi ~/pox/ext/topoDiscovery.py  

from pox.core import core  
import pox.openflow.libopenflow_01 as of  
from pox.lib.revent import *  
from pox.lib.recoco import Timer  
from collections import defaultdict  
from pox.openflow.discovery import Discovery  
from pox.lib.util import dpid_to_str  
import time

class topoDiscovery(EventMixin):

    def __init__(self):
        def startup():
            core.openflow.addListeners(self, priority = 0)
            core.openflow_discovery.addListeners(self)
        core.call_when_ready(startup, ('openflow','openflow_discovery'))
        print "init over"
    def _handle_LinkEvent(self, event):
        l = event.link
        sw1 = l.dpid1
        sw2 = l.dpid2
        pt1 = l.port1
        pt2 = l.port2

        print 'link added is %s'%event.added
        print 'link removed is %s' %event.removed
        print 'switch1 %d' %l.dpid1
        print 'port1 %d' %l.port1
        print 'switch2 %d' %l.dpid2
        print 'port2 %d' %l.port2

def launch():  
    core.registerNew(topoDiscovery)

First open a terminal and run topology file in mininet as previous post.

mininet@mininet-vm:~$ sudo ./type1.py  

and open a new terminal and run pox with above code and openflow.discovery

mininet@mininet-vm:~$ sudo ./pox/pox.py topoDiscovery openflow.discovery  

mininet@mininet-vm:~$ sudo ./pox/pox.py topoDiscovery openflow.discovery  
POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.  
init over  
INFO:core:POX 0.2.0 (carp) is up.  
INFO:openflow.of_01:[00-00-00-00-00-02 4] connected  
INFO:openflow.of_01:[00-00-00-00-00-04 2] connected  
INFO:openflow.of_01:[00-00-00-00-00-06 5] connected  
INFO:openflow.of_01:[00-00-00-00-00-03 3] connected  
INFO:openflow.of_01:[00-00-00-00-00-01 6] connected  
INFO:openflow.of_01:[00-00-00-00-00-05 1] connected  
INFO:openflow.discovery:link detected: 00-00-00-00-00-02.1 -> 00-00-00-00-00-01.2  
link added is True  
link removed is False  
switch1 2  
port1 1  
switch2 1  
port2 2  
INFO:openflow.discovery:link detected: 00-00-00-00-00-02.2 -> 00-00-00-00-00-03.2  
link added is True  
link removed is False  
switch1 2  
port1 2  
switch2 3  
port2 2  
INFO:openflow.discovery:link detected: 00-00-00-00-00-04.1 -> 00-00-00-00-00-01.3  
link added is True  
link removed is False  
switch1 4  
port1 1  
switch2 1  
port2 3  
INFO:openflow.discovery:link detected: 00-00-00-00-00-04.2 -> 00-00-00-00-00-05.1  
link added is True  
link removed is False  
switch1 4  
port1 2  
switch2 5  
port2 1  
INFO:openflow.discovery:link detected: 00-00-00-00-00-06.1 -> 00-00-00-00-00-03.3  
link added is True  
link removed is False  
switch1 6  
port1 1  
switch2 3  
port2 3  
INFO:openflow.discovery:link detected: 00-00-00-00-00-03.3 -> 00-00-00-00-00-06.1  
link added is True  
link removed is False  
switch1 3  
port1 3  
switch2 6  
port2 1  
INFO:openflow.discovery:link detected: 00-00-00-00-00-03.1 -> 00-00-00-00-00-05.2  
link added is True  
link removed is False  
switch1 3  
port1 1  
switch2 5  
port2 2  
INFO:openflow.discovery:link detected: 00-00-00-00-00-03.2 -> 00-00-00-00-00-02.2  
link added is True  
link removed is False  
switch1 3  
port1 2  
switch2 2  
port2 2  
INFO:openflow.discovery:link detected: 00-00-00-00-00-01.3 -> 00-00-00-00-00-04.1  
link added is True  
link removed is False  
switch1 1  
port1 3  
switch2 4  
port2 1  
INFO:openflow.discovery:link detected: 00-00-00-00-00-01.2 -> 00-00-00-00-00-02.1  
link added is True  
link removed is False  
switch1 1  
port1 2  
switch2 2  
port2 1  
INFO:openflow.discovery:link detected: 00-00-00-00-00-05.1 -> 00-00-00-00-00-04.2  
link added is True  
link removed is False  
switch1 5  
port1 1  
switch2 4  
port2 2  
INFO:openflow.discovery:link detected: 00-00-00-00-00-05.2 -> 00-00-00-00-00-03.1  
link added is True  
link removed is False  
switch1 5  
port1 2  
switch2 3  
port2 1  

And in Mininet, let link between s1 and s4 down

mininet> link s1 s4 down  

wait a few seconds, pox outputs following information:

INFO:openflow.discovery:link timeout: 00-00-00-00-00-04.1 -> 00-00-00-00-00-01.3  
link added is False  
link removed is True  
switch1 4  
port1 1  
switch2 1  
port2 3  
INFO:openflow.discovery:link timeout: 00-00-00-00-00-01.3 -> 00-00-00-00-00-04.1  
link added is False  
link removed is True  
switch1 1  
port1 3  
switch2 4  
port2 1  

Next, let link between s1 and s4 up

mininet> link s1 s4 up  

wait a few seconds, pox outputs following information:

INFO:openflow.discovery:link detected: 00-00-00-00-00-04.1 -> 00-00-00-00-00-01.3  
link added is True  
link removed is False  
switch1 4  
port1 1  
switch2 1  
port2 3  
INFO:openflow.discovery:link detected: 00-00-00-00-00-01.3 -> 00-00-00-00-00-04.1  
link added is True  
link removed is False  
switch1 1  
port1 3  
switch2 4  
port2 1  

References:
POX Wiki
Create a custom topology in Mininet (2)

Create a new python file named type1.py

#!/usr/bin/env python
"""Custom topology example
This example create a topology with 6 switches and 2 hosts.

     h1 --- s1 --- s2 --- s3 --- s6 --- h2
             \            /
              \          /
               s4 --- s5

"""

from mininet.topo import Topo  
from mininet.net import Mininet  
from mininet.cli import CLI  
from mininet.log import setLogLevel, info  
class Type1( Topo ):  
    switchList = []
    def __init__( self):
        #Initialize topology
        Topo.__init__( self )
        # Add hosts and switches
        h1 = self.addHost( 'h1' )
        h2 = self.addHost( 'h2' )
        for i in range(1,7):
            self.switchList.append( self.addSwitch( 's' + str(i) ))
        # Add Links
        self.addLink( h1, self.switchList[0] )
        self.addLink( self.switchList[0], self.switchList[1] )
        self.addLink( self.switchList[0], self.switchList[3] )
        self.addLink( self.switchList[3], self.switchList[4] )
        self.addLink( self.switchList[4], self.switchList[2] )
        self.addLink( self.switchList[1], self.switchList[2] )
        self.addLink( self.switchList[2], self.switchList[5] )
        self.addLink( h2, self.switchList[5] )

def createTopo():  
    topo = Type1()
    net = Mininet( topo = topo )
    net.start()
    CLI(net)
    net.stop()

if __name__ == '__main__':  
    setLogLevel('info')
    createTopo()

This file is different from the file in "Create a custom topology in Mininet 1".
This file can be executed directly by type in cli

mininet@mininet-vm:~$ sudo python type1.py