Merge "Update diagram and developer guide for Si and P"

diff --cc docs/developer-guide.rst
index 410ade6d1517d1b2f89a2231eb67b16d98f4aa45,75372e6fa3b0fab478e071f7c6392df2e75231d3..1e6e5d3080246dde822c36336065e99c14b7d24e
--- 1/docs/developer-guide.rst
--- 2/docs/developer-guide.rst
+++ b/docs/developer-guide.rst
@@@ -67,31 -81,26 +81,32 @@@ Module descriptio
  ServiceHandler
  ^^^^^^^^^^^^^^
  
- Service Handler handles request coming from a higher level controller or an orchestrator
- through the northbound API, as defined in the Open ROADM service model. Current
- implementation addresses the following rpcs: service-create, temp-service-create,
- service–delete, temp-service-delete, service-reroute, and service-restoration. It checks the
- request consistency and trigs path calculation sending rpcs to the PCE. If a valid path is
- returned by the PCE, path configuration is initiated relying on Renderer and OLM. At the
- confirmation of a successful service creation, the Service Handler updates the service-
- list/temp-service-list in the MD-SAL. For service deletion, the Service Handler relies on the
- Renderer and the OLM to delete connections and reset power levels associated with the
- service. The service-list is updated following a successful service deletion. In Neon SR0 is
- added the support for service from ROADM to ROADM, which brings additional flexibility and
- notably allows reserving resources when transponders are not in place at day one.
- Magnesium SR2 fully supports end-to-end OTN services which are part of the OTN infrastructure.
- It concerns the management of OCH-OTU4 (also part of the optical infrastructure) and structured
- HO-ODU4 services. Moreover, once these two kinds of OTN infrastructure service created, it is
- possible to manage some LO-ODU services (for the time being, only 10GE-ODU2e services).
- The full support of OTN services, including 1GE-ODU0 or 100GE, will be introduced along next
- releases (Mg/Al).
+ Service Handler handles request coming from a higher level controller or an
+ orchestrator through the northbound API, as defined in the Open ROADM service model.
+ Current implementation addresses the following rpcs: service-create, temp-service-
+ create, service–delete, temp-service-delete, service-reroute, and service-restoration.
+ It checks the request consistency and trigs path calculation sending rpcs to the PCE.
+ If a valid path is returned by the PCE, path configuration is initiated relying on
+ Renderer and OLM. At the confirmation of a successful service creation, the Service
+ Handler updates the service-list/temp-service-list in the MD-SAL. For service deletion,
+ the Service Handler relies on the Renderer and the OLM to delete connections and reset
+ power levels associated with the service. The service-list is updated following a
+ successful service deletion. In Neon SR0 is added the support for service from ROADM
+ to ROADM, which brings additional flexibility and notably allows reserving resources
+ when transponders are not in place at day one. Magnesium SR2 fully supports end-to-end
+ OTN services which are part of the OTN infrastructure. It concerns the management of
+ OCH-OTU4 (also part of the optical infrastructure) and structured HO-ODU4 services.
+ Moreover, once these two kinds of OTN infrastructure service created, it is possible
+ to manage some LO-ODU services (1GE-ODU0, 10GE-ODU2e). 100GE services are also
+ supported over ODU4 in transponders or switchponders using higher rate network
+ interfaces.
  
 +In Silicon release, the management of TopologyUpdateNotification coming from the *Topology Management*
 +module was implemented. This functionality enables the controller to update the information of existing
 +services according to the online status of the network infrastructure. If any service is affected by
 +the topology update and the *odl-transportpce-nbi* feature is installed, the Service Handler will send a
 +notification to a Kafka server with the service update information.
 +
  PCE
  ^^^