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,
-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.
PCE
^^^^^^^^^^^^^^
allows keeping PCE aligned with the latest changes in the topology. Information
about current and planned services is available in the MD-SAL data store.
-Current implementation of PCE allows finding the shortest path, minimizing
-either the hop count (default) or the propagation delay. Wavelength is assigned
-considering a fixed grid of 96 wavelengths. Current PCE handles the following
-constraints as hard constraints:
+Current implementation of PCE allows finding the shortest path, minimizing either the hop
+count (default) or the propagation delay. Wavelength is assigned considering a fixed grid of
+96 wavelengths. In Neon SR0, the PCE calculates the OSNR, on the base of incremental
+noise specifications provided in Open RAODM MSA. The support of unidirectional ports is
+also added. PCE handles the following constraints as hard constraints:
- **Node exclusion**
- **SRLG exclusion**
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.
-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).
OLM
^^^^^^^^
- service-reroute (given service-name, service-aend, service-zend)
+ - service-restoration (given service-name, service-aend, service-zend)
+
+ - temp-service-create (given common-id, service-aend, service-zend)
+
+ - temp-service-delete (given common-id)
+
- Data structure
- - service list : composed of services
+ - service list : made of services
+ - temp-service list : made of temporary services
- service : composed of service-name, topology wich describes the detailed path (list of used resources)
- Notification
- calculate-spanloss-current
+odl-transportpce-stubmodels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ - This feature provides function to be able to stub some of TransportPCE modules, pce and
+ renderer (Stubpce and Stubrenderer).
+ Stubs are used for development purposes and can be used for some of the functionnal tests.
+
Running transportPCE project
----------------------------
"node": [
{
"node-id": "<node-id>",
- "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"
}
]
}
**REST API** : *GET /restconf/config/portmapping:network*
+.. note::
+
+ in Neon SR0, the support of openroadm 2.2 device model is added. Thus 2.2 nodes can be
+ discovered and added to the portmapping node list. However, full topology management
+ support (and notably link discovery) is not provided for 2.2 nodes. The support for link
+ discovery and full topology management with 1.2.1 and 2.2 nodes will be added in a next release.
+
.. note::
In ``org-openroadm-device.yang``, two types of optical nodes can be managed:
.. code:: json
{
- "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"
+ }
}
Most important parameters for this REST RPC are the identification of the two physical client ports
.. code:: json
{
- "input": {
- "sdnc-request-header": {
- "request-id": "request-1",
- "rpc-action": "service-delete",
- "request-system-id": "appname",
- "notification-url": "http://localhost:8585/NotificationServer/notify"
- },
- "service-delete-req-info": {
- "service-name": "test1",
- "tail-retention": "no"
- }
- }
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-delete",
+ "request-system-id": "appname",
+ "notification-url": "http://localhost:8585/NotificationServer/notify"
+ },
+ "service-delete-req-info": {
+ "service-name": "test1",
+ "tail-retention": "no"
+ }
+ }
}
Most important parameters for this REST RPC is the *service-name*.
Code Review / transportpce.git / blobdiff