## 2 State of the Art
### Design of a SDN Management Layer to Control Service Reconfiguration Policies on the SDN-GPON Model
\right)\) can be dynamically modified according to specific bandwidth allocation policies implemented by ISPs/Network Operators, allowing a real-time bandwidth reconfiguration according to the real-time requested bandwidth of residential users. Consequently, we propose an online service reconfiguration policy, in which users contract a guaranteed bandwidth \(\left( \begin{array}{c}B_{guaranteed}^{ONT_{i},service_{j}}\\ \end{array} \right)\) and it can be offered an extra maximum according to the priority and conditions of the contracted Service Level Agreement (SLA) up to a maximum limit \(\left( \begin{array}{c}B_{max}^{ONT_{i},service_{j}}\\ \end{array} \right)\). Therefore, users do not need to request more bandwidth whenever they need it, but it is the external SDN management layer that monitors changes and decides to increase or decrease the bandwidth of residential users at a given time. Under this network scenario, the external SDN management layer by means of the ODL controller transparently gives a user some bandwidth in excess if it demands it and there is enough capacity in the GPON. Then, a bandwidth management program (located in the SDN management layer) is constantly listening for the arrival of OpenFlow messages (OFM_METER) and collecting the value of the demanded bandwidth of the sliding window that corresponds to one service of one specific ONT, calculating the average of the said window in real-time, as it can be observed in the flowchart of Figure 4.  
Every time the sliding window updates the mean requested bandwidth \(\left( \begin{array}{c}B_{request}^{ONT_{i},service_{j}}\\ \end{array} \right)\) an instance is launched to the service reconfiguration policy to detect if the average bandwidth of the window is higher than the current maximum bandwidth, called \(B_{max,\,updated}^{ONT_{i},service_{j}}\) in our algorithm. To do this, the algorithm first connects to the internal database that stores the maximum bandwidth \(\left( \begin{array}{c}B_{max}^{ONT_{i},service_{j}}\\ \end{array} \right)\) and the guaranteed bandwidth of the contracted service. In the next step, the management program must assure the user an assigned rate always greater or equal than the basic contracted bandwidth \(\left( \begin{array}{c}B_{guaranteed}^{ONT_{i},service_{j}}\\ \end{array} \right)\) in case the residential user demands it. Then, the program must verify that the requested bandwidth \(\left( \begin{array}{c}B_{request}^{ONT_{i},service_{j}}\\ \end{array} \right)\) does not exceed the maximum contracted bandwidth \(\left( \begin{array}{c}B_{max}^{ONT_{i},service_{j}}\\ \end{array} \right)\). If all the conditions are met, the bandwidth management algorithm makes sure that the available resources are enough for the requested new bandwidth. In that case, the algorithm modifies this value \(\left(B_{max,updated}^{ONT_{i},service_{i}}\right)\), updates the database, and sends a request to the ODL controller to add new flows to the corresponding ONT (COVS, ROVS) with the new QoS requirements and discard the existing flows with the old QoS requirements. Otherwise, the maximum bandwidth \(\left(B_{max,updated}^{ONT_{i},service_{i}}\right)\) is not updated and no commands are sent to the ODL controller. Figure 4: Flow chart of the implemented service reconfiguration policy. Therefore, it could be very appealing that some online service management strategies can be moved out of the OLT to be centralized and controlled by the external SDN management layer. In addition, it avoids the synchronized time required in PON devices each time a service reconfiguration is made over the OLT and the ONTs. Then, we propose that the external SDN management layer could have implemented different service reconfiguration strategies. Finally, this approach avoids modifying the legacy GPON layer and it provides the full functionality of the integrated OpenFlow solution.