## 6 Proposal of a Layered Communication Architecture and an Application Protocol for MG's
### P2P Layer  
The proposed P2P layer defines two levels or software layers for implementing overlay-P2P services (see Figure 6): On one hand, the DHT-Chord layer provides P2P networking services to  
Figure 6: Proposed stack protocol of an operational peer for a generic DHT peer communication architecture.  
achieve the following tasks: (i) resource and network discovery; (ii) session establishment; (iii) routing; (iv) data transfer among nodes and (v) entry/exit management of nodes. To evaluate the network performance, the different algorithms previously developed will be implemented in this level. On the other hand, the second P2P layer is responsible for handling the peer resources information.  
In the P2P overlay networking layer, an Application Programing Interface (API) has been developed to run the node functions (i) to (iv) that have been listed in the previous paragraph. In this layer, each peer maintains the connection with their neighbor peers. Moreover, this layer includes neighbor discovery and it has a bootstrap engine for session establishment. For joining and leaving the network there is a join/leave protocol. The overlay networking layer also provides the mechanisms for routing data packets across a large network. In addition, Chord runs a special stabilization algorithm, called _stabilize_, which is periodically executed by each node every 60 ms to keep the list of predecessors and successors and to confirm that the ring integrity has not been corrupted. Therefore, if a certain node \(n\) fails, the nodes whose finger table includes \(n\) are responsible for finding the n's successor. It must be avoided that the failure of n provokes a disruption of the queries that are in process while the system is re-stabilizing. To achieve that, each peer maintains a successor list of its \(r\) nearest successor's node. In this way, when a certain node \(m\) notices that its successor has failed, it replaces the failed node by the first alive entry from its successor list. The queries will continue while the algorithm is correcting the finger table entries and the successor list. This allows not significantly increasing the end to end latencies if a node fails.  
Besides, the DHT-Data layer establishes how the peers self-organize its resources and also the data management. It is worth noting that the DHT-data layer includes databases and uses the DHT-Chord one for storage of data. The Data layer for each node is defined as described below. On the one hand, peers should be able to react by sending messages in certain situations, for instance, in faulty conditions, when the operative power limits are reached, etc. On the other hand, peers should be continuously providing information about its actual status and also the one of its neighbors. Thus, the data base of each node is composed by two parts, named static and dynamic sides. The static side provides the description of the node itself (kind of DER: CL, SCL, NCL, DG... ), the IP address, the Global Unique Identifier (GUID) and the definition of its power limits. The dynamic side periodically collects, from itself and from its neighboring peers, the main power parameters for knowing the global status of the microgrid.