-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,
-service–delete, service-reroute.
-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 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.
-
+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.
-The Renderer module, on request coming from the Service Handler through a
-service-implementation-request /service delete rpc, sets/deletes the path
-corresponding to a specific service between A and Z ends.
-It first checks what are the existing interfaces on the ports of the different
-nodes that the path crosses. It then creates missing interfaces. After all
-needed interfaces have been created it sets the connections required in the
-nodes and notifies the Service Handler on the status of the path creation.
-Path is created in 2 steps (from A to Z and Z to A). In case the path between
-A and Z could not be fully created, a rollback function is called to set the
-equipment on the path back to their initial configuration (as they were before
-invoking the Renderer).
+The Renderer module, on request coming from the Service Handler through a service-
+implementation-request /service delete rpc, sets/deletes the path corresponding to a specific
+service between A and Z ends. The path description provided by the service-handler to the
+renderer is based on abstracted resources (nodes, links and termination-points), as provided
+by the PCE module. The renderer converts this path-description in a path topology based on
+device resources (circuit-packs, ports,…). The conversion from abstracted resources to
+device resources is performed relying on the portmapping module which maintains the
+connections between these different resource types. In Neon (SR0), portmapping modules
+has been enriched to support both openroadm 1.2.1 and 2.2 device models. The full support
+of openroadm 2.2 device models (both in the topology management and the rendering
+function) is planned at a later step (ORD2.2 full support is targeted for Neon SR1).
+
+After the path is provided, the renderer first checks what are the existing interfaces on the
+ports of the different nodes that the path crosses. It then creates missing interfaces. After all
+needed interfaces have been created it sets the connections required in the nodes and
+notifies the Service Handler on the status of the path creation. Path is created in 2 steps
+(from A to Z and Z to A). In case the path between A and Z could not be fully created, a
+rollback function is called to set the equipment on the path back to their initial configuration
+(as they were before invoking the Renderer).
- "netconf-node-topology:tcp-only": "false",
- "netconf-node-topology:reconnect-on-changed-schema": "false",
- "netconf-node-topology:host": "<node-ip-address>",
- "netconf-node-topology:default-request-timeout-millis": "120000",
- "netconf-node-topology:max-connection-attempts": "0",
- "netconf-node-topology:sleep-factor": "1.5",
- "netconf-node-topology:actor-response-wait-time": "5",
- "netconf-node-topology:concurrent-rpc-limit": "0",
- "netconf-node-topology:between-attempts-timeout-millis": "2000",
- "netconf-node-topology:port": "<netconf-port>",
- "netconf-node-topology:connection-timeout-millis": "20000",
- "netconf-node-topology:username": "<node-username>",
- "netconf-node-topology:password": "<node-password>",
- "netconf-node-topology:keepalive-delay": "300"
+ "netconf-node-topology:tcp-only": "false",
+ "netconf-node-topology:reconnect-on-changed-schema": "false",
+ "netconf-node-topology:host": "<node-ip-address>",
+ "netconf-node-topology:default-request-timeout-millis": "120000",
+ "netconf-node-topology:max-connection-attempts": "0",
+ "netconf-node-topology:sleep-factor": "1.5",
+ "netconf-node-topology:actor-response-wait-time": "5",
+ "netconf-node-topology:concurrent-rpc-limit": "0",
+ "netconf-node-topology:between-attempts-timeout-millis": "2000",
+ "netconf-node-topology:port": "<netconf-port>",
+ "netconf-node-topology:connection-timeout-millis": "20000",
+ "netconf-node-topology:username": "<node-username>",
+ "netconf-node-topology:password": "<node-password>",
+ "netconf-node-topology:keepalive-delay": "300"
- "input": {
- "sdnc-request-header": {
- "request-id": "request-1",
- "rpc-action": "service-create",
- "request-system-id": "appname"
- },
- "service-name": "test1",
- "common-id": "commonId",
- "connection-type": "service",
- "service-a-end": {
- "service-rate": "100",
- "node-id": "<xpdr-node-id>",
- "service-format": "Ethernet",
- "clli": "<ccli-name>",
- "tx-direction": {
- "port": {
- "port-device-name": "<xpdr-client-port>",
- "port-type": "fixed",
- "port-name": "<xpdr-client-port-number>",
- "port-rack": "000000.00",
- "port-shelf": "Chassis#1"
- },
- "lgx": {
- "lgx-device-name": "Some lgx-device-name",
- "lgx-port-name": "Some lgx-port-name",
- "lgx-port-rack": "000000.00",
- "lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
- "port": {
- "port-device-name": "<xpdr-client-port>",
- "port-type": "fixed",
- "port-name": "<xpdr-client-port-number>",
- "port-rack": "000000.00",
- "port-shelf": "Chassis#1"
- },
- "lgx": {
- "lgx-device-name": "Some lgx-device-name",
- "lgx-port-name": "Some lgx-port-name",
- "lgx-port-rack": "000000.00",
- "lgx-port-shelf": "00"
- }
- },
- "optic-type": "gray"
- },
- "service-z-end": {
- "service-rate": "100",
- "node-id": "<xpdr-node-id>",
- "service-format": "Ethernet",
- "clli": "<ccli-name>",
- "tx-direction": {
- "port": {
- "port-device-name": "<xpdr-client-port>",
- "port-type": "fixed",
- "port-name": "<xpdr-client-port-number>",
- "port-rack": "000000.00",
- "port-shelf": "Chassis#1"
- },
- "lgx": {
- "lgx-device-name": "Some lgx-device-name",
- "lgx-port-name": "Some lgx-port-name",
- "lgx-port-rack": "000000.00",
- "lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
- "port": {
- "port-device-name": "<xpdr-client-port>",
- "port-type": "fixed",
- "port-name": "<xpdr-client-port-number>",
- "port-rack": "000000.00",
- "port-shelf": "Chassis#1"
- },
- "lgx": {
- "lgx-device-name": "Some lgx-device-name",
- "lgx-port-name": "Some lgx-port-name",
- "lgx-port-rack": "000000.00",
- "lgx-port-shelf": "00"
- }
- },
- "optic-type": "gray"
- },
- "due-date": "yyyy-mm-ddT00:00:01Z",
- "operator-contact": "some-contact-info"
- }
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "test1",
+ "common-id": "commonId",
+ "connection-type": "service",
+ "service-a-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "Ethernet",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "Ethernet",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "due-date": "yyyy-mm-ddT00:00:01Z",
+ "operator-contact": "some-contact-info"
+ }