# Software Defined Wireless Mesh Network Flat Distribution Control Plane
## 3 Architecture Implementation
### Coordinator Implementation  
The coordinator is implemented as any other POX application. It receives Packet-In messages from the Core module after subscription, sends its Packet-Out messages, reads and writesinformation from/to the aggregated-DB and at startup it views the POX controller configuration file. For coordinator operation, there are configurations parameters which should determine: agents_list, messaging_server_type and messaging_server_listening_port. Also, other optional parameters can be specified. An agent is a small class that manages inter-domain exchanges to/from a module to handle intra-domain communication. Coordinator activates a specific agent from the agents_list by specifying the port that it reaches by the messaging_server_listening_port. Moreover, from the messaging_server_type parameter, the coordinator determines the messaging driver that it uses, for current implementation the RabbitMQ driver [21] is used to implement the federation mode of AMQP, but the FD-SDWMN architecture allows the use of other AMQP implementations such as Active MQ.  
The coordinator implements an extended LLDP (Link Layer Discovery Protocol) version, which is called Coordinator-LLDP (C-LLDP) that is used in discovery functionality. The C-LLDP message contains an OpenFlow option added to the regular LLDP message. Moreover, IEEE has allocated the Organizationally Unique Identifier (OUI) to OpenFlow. The coordinator sends these messages announcing controller existence in order to discover other domains' controllers. When it receives a reply toa discovery message, it establishes a connection via AMQP to its peer in that controller and stops sending discovery messages. Otherwise, the coordinator continues sending discovery messages periodically. A C-LLDP message--as shown in Figure 3--contains the required information to reach a controller.  
The coordinator offers a communication channel (publish/subscribe) for inter-domain exchanges. It is essential the operation is done via two particular topics: C_ID.*.* topic, where C_ID is a controller identifier. Via this topic, other controllers can directly send messages to this controller. For instance, this is used for a local domain topology discovery update. The other topic is general.*.*, which enables a controller to communicate to all other controllers in the network, such as when a controller decides to leave its domain.  
The coordinator communicates with AMQP implementation via drivers. An AMPQ driver should support a set of functions:  
1. Subscribe (topic)/unsubscribe (topic): to add and remove a topic to/from the topic list.
2. Send (topic, message): send to a particular topic a specific message.  
Figure 3: The discovery message. LLDP: Link Layer Discovery Protocol; OUI: Organizationally Unique Identifier.  
Pair (C_ID) and unPair (C_ID): controller function to create a control channel to another controller and the opposite function is to remove this channel when a controller fails and is not able to receive information from neighbors.  
The coordinator also maintains a controller existence by sending periodic Keep-Alive messages. In the case that three contiguous Keep-Alive messages have no response, a controller infers that its neighbor controller has failed and it triggers a mitigate procedure for this failure. The coordinator application is flexible enough for an extension without altering the main classes of POX. Developers can provide a new driver for the implementation of AMQP to extend the coordinator class, or by adding a new agent function.