+**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "infrastructure",
+ "service-a-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OTU",
+ "otu-service-rate": "org-openroadm-otn-common-types:OTU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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": "OTU",
+ "otu-service-rate": "org-openroadm-otn-common-types:OTU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*openroadm-topology* and then invokes *renderer* and *OLM* to implement the end-to-end path into
+the devices.
+
+OTSi-OTUC4 service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *service handler* module in order to create over the optical
+infrastructure a bidirectional end-to-end OTUC4 over an optical Optical Tributary Signal
+connectivity service between two optical network ports of OTN Xponder (MUXPDR or SWITCH). Such
+service configure the optical network infrastructure composed of rdm nodes.
+
+**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "infrastructure",
+ "service-a-end": {
+ "service-rate": "400",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OTU",
+ "otu-service-rate": "org-openroadm-otn-common-types:OTUCn",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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": "400",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OTU",
+ "otu-service-rate": "org-openroadm-otn-common-types:OTUCn",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*openroadm-topology* and then invokes *renderer* and *OLM* to implement the end-to-end path into
+the devices.
+
+One shall note that in Phosphorus SR0, as the OpenROADM 400G specification are not available (neither
+in the GNPy libraries, nor in the *PCE* module), path validation will be performed using the same
+asumptions as we use for 100G. This means the path may be validated whereas optical performances do
+not reach expected levels. This allows testing OpenROADM device implementing B100G rates, but shall
+not be used in operational conditions. The support for higher rate impairment aware path computation
+will be introduced across Phosphorus release train.
+
+ODUC4 service creation
+^^^^^^^^^^^^^^^^^^^^^^
+
+For ODUC4 service creation, the REST RPC to invoke *service handler* module in order to create an
+ODUC4 over the OTSi-OTUC4 has the same format as the RPC used for the creation of this last. Only
+"service-format" needs to be changed to "ODU", and "otu-service-rate" : "org-openroadm-otn-common-
+types:OTUCn" needs to be replaced by: "odu-service-rate" : "org-openroadm-otn-common-types:ODUCn"
+in both service-a-end and service-z-end containers.
+
+OTN HO-ODU4 service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *service handler* module in order to create over the optical
+infrastructure a bidirectional end-to-end ODU4 OTN service over an OTU4 and structured to support
+low-order OTN services (ODU2e, ODU0). As for OTU4, such a service must be created between two network
+ports of OTN Xponder (MUXPDR or SWITCH).
+
+**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "infrastructure",
+ "service-a-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "ODU",
+ "otu-service-rate": "org-openroadm-otn-common-types:ODU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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": "ODU",
+ "otu-service-rate": "org-openroadm-otn-common-types:ODU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "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"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*otn-topology* that must contains OTU4 links with valid bandwidth parameters, and then
+invokes *renderer* and *OLM* to implement the end-to-end path into the devices.
+
+OTN 10GE-ODU2e service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *service handler* module in order to create over the OTN
+infrastructure a bidirectional end-to-end 10GE-ODU2e OTN service over an ODU4.
+Such a service must be created between two client ports of OTN Xponder (MUXPDR or SWITCH)
+configured to support 10GE interfaces.
+
+**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "service",
+ "service-a-end": {
+ "service-rate": "10",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "Ethernet",
+ "clli": "<ccli-name>",
+ "subrate-eth-sla": {
+ "subrate-eth-sla": {
+ "committed-info-rate": "10000",
+ "committed-burst-size": "64"
+ }
+ },
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "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": "10",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "Ethernet",
+ "clli": "<ccli-name>",
+ "subrate-eth-sla": {
+ "subrate-eth-sla": {
+ "committed-info-rate": "10000",
+ "committed-burst-size": "64"
+ }
+ },
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "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-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "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"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*otn-topology* that must contains ODU4 links with valid bandwidth parameters, and then
+invokes *renderer* and *OLM* to implement the end-to-end path into the devices.
+
+
+.. note::
+ Since Magnesium SR2, the service-list corresponding to OCH-OTU4, ODU4 or again 10GE-ODU2e services is
+ updated in the service-list datastore.
+
+.. note::
+ trib-slot is used when the equipment supports contiguous trib-slot allocation (supported from
+ Magnesium SR0). The trib-slot provided corresponds to the first of the used trib-slots.
+ complex-trib-slots will be used when the equipment does not support contiguous trib-slot
+ allocation. In this case a list of the different trib-slots to be used shall be provided.
+ The support for non contiguous trib-slot allocation is planned for later release.
+
+Deleting a service
+~~~~~~~~~~~~~~~~~~
+
+Deleting any kind of service
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *service handler* module in order to delete a given optical
+connectivity service.
+
+**REST API** : *POST /restconf/operations/org-openroadm-service:service-delete*
+
+**Sample JSON Data**
+
+.. 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": "something",
+ "tail-retention": "no"
+ }
+ }
+ }
+
+Most important parameters for this REST RPC is the *service-name*.
+
+
+.. note::
+ Deleting OTN services implies proceeding in the reverse way to their creation. Thus, OTN
+ service deletion must respect the three following steps:
+ 1. delete first all 10GE services supported over any ODU4 to be deleted
+ 2. delete ODU4
+ 3. delete OCH-OTU4 supporting the just deleted ODU4
+
+Invoking PCE module
+~~~~~~~~~~~~~~~~~~~
+
+Use the following REST RPCs to invoke *PCE* module in order to check connectivity between xponder
+nodes and the availability of a supporting optical connectivity between the network-ports of the
+nodes.
+
+Checking OTU4 service connectivity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "service-name": "something",
+ "resource-reserve": "true",
+ "service-handler-header": {
+ "request-id": "request1"
+ },
+ "service-a-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "OTU",
+ "node-id": "<otn-node-id>"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "OTU",
+ "node-id": "<otn-node-id>"
+ },
+ "pce-metric": "hop-count"
+ }
+ }
+
+.. note::
+ here, the <otn-node-id> corresponds to the node-id as appearing in "openroadm-network" topology
+ layer
+
+Checking ODU4 service connectivity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "service-name": "something",
+ "resource-reserve": "true",
+ "service-handler-header": {
+ "request-id": "request1"
+ },
+ "service-a-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "ODU",
+ "node-id": "<otn-node-id>"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "ODU",
+ "node-id": "<otn-node-id>"
+ },
+ "pce-metric": "hop-count"
+ }
+ }
+
+.. note::
+ here, the <otn-node-id> corresponds to the node-id as appearing in "otn-topology" layer
+
+Checking 10GE/ODU2e service connectivity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "service-name": "something",
+ "resource-reserve": "true",
+ "service-handler-header": {
+ "request-id": "request1"
+ },
+ "service-a-end": {
+ "service-rate": "10",
+ "clli": "<clli-node>",
+ "service-format": "Ethernet",
+ "node-id": "<otn-node-id>"
+ },
+ "service-z-end": {
+ "service-rate": "10",
+ "clli": "<clli-node>",
+ "service-format": "Ethernet",
+ "node-id": "<otn-node-id>"
+ },
+ "pce-metric": "hop-count"
+ }
+ }
+
+.. note::
+ here, the <otn-node-id> corresponds to the node-id as appearing in "otn-topology" layer
+
+
+odl-transportpce-tapi
+---------------------
+
+This feature allows TransportPCE application to expose at its northbound interface other APIs than
+those defined by the OpenROADM MSA. With this feature, TransportPCE provides part of the Transport-API
+specified by the Open Networking Foundation. More specifically, the Topology Service and Connectivity
+Service components are implemented, allowing to expose to higher level applications an abstraction of
+its OpenROADM topologies in the form of topologies respecting the T-API modelling, as well as
+creating/deleting connectivity services between the Service Interface Points (SIPs) exposed by the
+T-API topology. The current version of TransportPCE implements the *tapi-topology.yang* and
+*tapi-connectivity.yang* models in the revision 2018-12-10 (T-API v2.1.2).
+
+Additionally, support for the Notification Service component will be added in future releases, which
+will allow higher level applications to create/delete a Notification Subscription Service to receive
+several T-API notifications as defined in the *tapi-notification.yang* model.
+
+T-API Topology Service
+~~~~~~~~~~~~~~~~~~~~~~
+
+- RPC calls implemented:
+
+ - get-topology-details
+
+ - get-node-details
+
+ - get-node-edge-point-details
+
+ - get-link-details
+
+ - get-topology-list
+
+
+As in IETF or OpenROADM topologies, T-API topologies are composed of lists of nodes and links that
+abstract a set of network resources. T-API specifies the *T0 - Multi-layer topology* which is, as
+indicated by its name, a single topology that collapses network logical abstraction for all network
+layers. Thus, an OpenROADM device as, for example, an OTN xponder that manages the following network
+layers ETH, ODU, OTU, Optical wavelength, will be represented in T-API T0 topology by two nodes:
+one *DSR/ODU* node and one *Photonic Media* node. Each of them are linked together through one or
+several *transitional links* depending on the number of network/line ports on the device.
+
+Aluminium SR2 comes with a complete refactoring of this module, handling the same way multi-layer
+abstraction of any Xponder terminal device, whether it is a 100G transponder, an OTN muxponder or
+again an OTN switch. For all these devices, the implementation manages the fact that only relevant
+ports must appear in the resulting TAPI topology abstraction. In other words, only client/network ports
+that are undirectly/directly connected to the ROADM infrastructure are considered for the abstraction.
+Moreover, the whole ROADM infrastructure of the network is also abstracted towards a single photonic
+node. Therefore, a pair of unidirectional xponder-output/xponder-input links present in *openroadm-topology*
+is represented by a bidirectional *OMS* link in TAPI topology.
+In the same way, a pair of unidirectional OTN links (OTU4, ODU4) present in *otn-topology* is also
+represented by a bidirectional OTN link in TAPI topology, while retaining their available bandwidth
+characteristics.
+
+Phosphorus SR0 extends the T-API topology service implementation by bringing a fully described topology.
+*T0 - Full Multi-layer topology* is derived from the existing *T0 - Multi-layer topology*. But the ROADM
+infrastructure is not abstracted and the higher level application can get more details on the composition
+of the ROADM infrastructure controlled by TransportPCE. Each ROADM node found in the *openroadm-network*
+is converted into a *Photonic Media* node. The details of these T-API nodes are obtained from the
+*openroadm-topology*. Therefore, the external traffic ports of *Degree* and *SRG* nodes are represented
+with a set of Network Edge Points (NEPs) and SIPs belonging to the *Photonic Media* node and a pair of
+roadm-to-roadm links present in *openroadm-topology* is represented by a bidirectional *OMS* link in TAPI
+topology.
+Additionally, T-API topology related information is stored in TransportPCE datastore in the same way as
+OpenROADM topology layers. When a node is connected to the controller through the corresponding *REST API*,
+the T-API topology context gets updated dynamically and stored.
+
+.. note::
+
+ A naming nomenclature is defined to be able to map T-API and OpenROADM data.
+ i.e., T-API_roadm_Name = OpenROADM_roadmID+T-API_layer
+ i.e., T-API_roadm_nep_Name = OpenROADM_roadmID+T-API_layer+OpenROADM_terminationPointID
+
+Three kinds of topologies are currently implemented. The first one is the *"T0 - Multi-layer topology"*
+defined in the reference implementation of T-API. This topology gives an abstraction from data coming
+from openroadm-topology and otn-topology. Such topology may be rather complex since most of devices are
+represented through several nodes and links.
+Another topology, named *"Transponder 100GE"*, is also implemented. That latter provides a higher level
+of abstraction, much simpler, for the specific case of 100GE transponder, in the form of a single
+DSR node.
+Lastly, the *T0 - Full Multi-layer topology* topology was added. This topology collapses the data coming
+from openroadm-network, openroadm-topology and otn-topology. It gives a complete view of the optical
+network as defined in the reference implementation of T-API
+
+The figure below shows an example of TAPI abstractions as performed by TransportPCE starting from Aluminium SR2.
+
+.. figure:: ./images/TransportPCE-tapi-abstraction.jpg
+ :alt: Example of T0-multi-layer TAPI abstraction in TransportPCE
+
+In this specific case, as far as the "A" side is concerned, we connect TransportPCE to two xponder
+terminal devices at the netconf level :
+- XPDR-A1 is a 100GE transponder and is represented by XPDR-A1-XPDR1 node in *otn-topology*
+- SPDR-SA1 is an otn xponder that actually contains in its device configuration datastore two otn
+xponder nodes (the otn muxponder 10GE=>100G SPDR-SA1-XPDR1 and the otn switch 4x100GE => 4x100G SPDR-SA1-XPDR2)
+As represented on the bottom part of the figure, only one network port of XPDR-A1-XPDR1 is connected
+to the ROADM infrastructure, and only one network port of the otn muxponder is also attached to the
+ROADM infrastructure.
+Such network configuration will result in the TAPI *T0 - Multi-layer topology* abstraction as
+represented in the center of the figure. Let's notice that the otn switch (SPDR-SA1-XPDR2), not
+being attached to the ROADM infrastructure, is not abstracted.
+Moreover, 100GE transponder being connected, the TAPI *Transponder 100GE* topology will result in a
+single layer DSR node with only the two Owned Node Edge Ports representing the two 100GE client ports
+of respectively XPDR-A1-XPDR1 and XPDR-C1-XPDR1...
+
+
+**REST API** : *POST /restconf/operations/tapi-topology:get-topology-details*
+
+This request builds the TAPI *T0 - Multi-layer topology* abstraction with regard to the current
+state of *openroadm-topology* and *otn-topology* topologies stored in OpenDaylight datastores.
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "tapi-topology:input": {
+ "tapi-topology:topology-id-or-name": "T0 - Multi-layer topology"
+ }
+ }
+
+This request builds the TAPI *Transponder 100GE* abstraction with regard to the current state of
+*openroadm-topology* and *otn-topology* topologies stored in OpenDaylight datastores.
+Its main interest is to simply and directly retrieve 100GE client ports of 100G Transponders that may
+be connected together, through a point-to-point 100GE service running over a wavelength.
+
+.. code:: json
+
+ {
+ "tapi-topology:input": {
+ "tapi-topology:topology-id-or-name": "Transponder 100GE"
+ }
+ }
+
+
+.. note::
+
+ As for the *T0 multi-layer* topology, only 100GE client port whose their associated 100G line
+ port is connected to Add/Drop nodes of the ROADM infrastructure are retrieved in order to
+ abstract only relevant information.
+
+This request builds the TAPI *T0 - Full Multi-layer* topology with respect to the information existing in
+the T-API topology context stored in OpenDaylight datastores.
+
+.. code:: json
+
+ {
+ "tapi-topology:input": {
+ "tapi-topology:topology-id-or-name": "T0 - Full Multi-layer topology"
+ }
+ }
+
+**REST API** : *POST /restconf/operations/tapi-topology:get-node-details*
+
+This request returns the information, stored in the Topology Context, of the corresponding T-API node.
+The user can provide, either the Uuid associated to the attribute or its name.
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "tapi-topology:input": {
+ "tapi-topology:topology-id-or-name": "T0 - Full Multi-layer topology",
+ "tapi-topology:node-id-or-name": "ROADM-A1+PHOTONINC_MEDIA"
+ }
+ }
+
+**REST API** : *POST /restconf/operations/tapi-topology:get-node-edge-point-details*
+
+This request returns the information, stored in the Topology Context, of the corresponding T-API NEP.
+The user can provide, either the Uuid associated to the attribute or its name.
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "tapi-topology:input": {
+ "tapi-topology:topology-id-or-name": "T0 - Full Multi-layer topology",
+ "tapi-topology:node-id-or-name": "ROADM-A1+PHOTONINC_MEDIA",
+ "tapi-topology:ep-id-or-name": "ROADM-A1+PHOTONINC_MEDIA+DEG1-TTP-TXRX"
+ }
+ }
+
+**REST API** : *POST /restconf/operations/tapi-topology:get-link-details*
+
+This request returns the information, stored in the Topology Context, of the corresponding T-API link.
+The user can provide, either the Uuid associated to the attribute or its name.
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "tapi-topology:input": {
+ "tapi-topology:topology-id-or-name": "T0 - Full Multi-layer topology",
+ "tapi-topology:link-id-or-name": "ROADM-C1-DEG1-DEG1-TTP-TXRXtoROADM-A1-DEG2-DEG2-TTP-TXRX"
+ }
+ }
+
+T-API Connectivity & Common Services
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Phosphorus SR0 extends the T-API interface support by implementing the T-API connectivity Service.
+This interface enables a higher level controller or an orchestrator to request the creation of
+connectivity services as defined in the *tapi-connectivity* model. As it is necessary to indicate the
+two (or more) SIPs (or endpoints) of the connectivity service, the *tapi-common* model is implemented
+to retrieve from the datastore all the innformation related to the SIPs in the tapi-context.
+Current implementation of the connectivity service maps the *connectivity-request* into the appropriate
+*openroadm-service-create* and relies on the Service Handler to perform path calculation and configuration
+of devices. Results received from the PCE and the Rendererare mapped back into T-API to create the
+corresponding Connection End Points (CEPs) and Connections in the T-API Connectivity Context and store it
+in the datastore.
+
+This first implementation includes the creation of:
+
+- ROADM-to-ROADM tapi-connectivity service (MC connectivity service)
+- OTN tapi-connectivity services (OCh/OTU, OTSi/OTU & ODU connectivity services)
+- Ethernet tapi-connectivity services (DSR connectivity service)
+
+- RPC calls implemented
+
+ - create-connectivity-service
+
+ - get-connectivity-service-details
+
+ - get-connection-details
+
+ - delete-connectivity-service
+
+ - get-connection-end-point-details
+
+ - get-connectivity-service-list
+
+ - get-service-interface-point-details
+
+ - get-service-interface-point-list
+
+Creating a T-API Connectivity service
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the *tapi* interface to create any end-to-end connectivity service on a T-API based
+network. Two kind of end-to-end "optical" connectivity services are managed by TransportPCE T-API module:
+- 10GE service from client port to client port of two OTN Xponders (MUXPDR or SWITCH)
+- Media Channel (MC) connectivity service from client add/drop port (PP port of SRG) to
+client add/drop port of two ROADMs.
+
+As mentioned earlier, T-API module interfaces with the Service Handler to automatically invoke the
+*renderer* module to create all required tapi connections and cross-connection on each device
+supporting the service.
+
+Before creating a low-order OTN connectivity service (1GE or 10GE services terminating on
+client port of MUXPDR or SWITCH), the user must ensure that a high-order ODU4 container
+exists and has previously been configured (it means structured to support low-order otn services)
+to support low-order OTN containers.
+
+Thus, OTN connectivity service creation implies three steps:
+1. OTSi/OTU connectivity service from network port to network port of two OTN Xponders (MUXPDR or SWITCH in Photonic media layer)
+2. ODU connectivity service from network port to network port of two OTN Xponders (MUXPDR or SWITCH in DSR/ODU layer)
+3. 10GE connectivity service creation from client port to client port of two OTN Xponders (MUXPDR or SWITCH in DSR/ODU layer)
+
+The first step corresponds to the OCH-OTU4 service from network port to network port of OpenROADM.
+The corresponding T-API cross and top connections are created between the CEPs of the T-API nodes
+involved in each request.
+
+Additionally, an *MC connectivity service* could be created between two ROADMs to create an optical
+tunnel and reserve resources in advance. This kind of service corresponds to the OC service creation
+use case described earlier.
+
+The management of other OTN services through T-API (1GE-ODU0, 100GE...) is planned for future releases.
+
+Any-Connectivity service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+As for the Service Creation described for OpenROADM, the initial steps are the same:
+
+- Connect netconf devices to the controller
+- Create XPDR-RDM links and configure RDM-to-RDM links (in openroadm topologies)
+
+Bidirectional T-API links between xpdr and rdm nodes must be created manually. To that end, use the
+following REST RPCs:
+
+From xpdr <--> rdm:
+^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-tapinetworkutils:init-xpdr-rdm-tapi-link*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "xpdr-node": "<XPDR_OpenROADM_id>",
+ "network-tp": "<XPDR_TP_OpenROADM_id>",
+ "rdm-node": "<ROADM_OpenROADM_id>",
+ "add-drop-tp": "<ROADM_TP_OpenROADM_id>"
+ }
+ }
+
+Use the following REST RPC to invoke T-API module in order to create a bidirectional connectivity
+service between two devices. The network should be composed of two ROADMs and two Xponders (SWITCH or MUX)
+
+**REST API** : *POST /restconf/operations/tapi-connectivity:create-connectivity-service*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "tapi-connectivity:input": {
+ "tapi-connectivity:end-point": [
+ {
+ "tapi-connectivity:layer-protocol-name": "<Node_TAPI_Layer>",
+ "tapi-connectivity:service-interface-point": {
+ "tapi-connectivity:service-interface-point-uuid": "<SIP_UUID_of_NEP>"
+ },
+ "tapi-connectivity:administrative-state": "UNLOCKED",
+ "tapi-connectivity:operational-state": "ENABLED",
+ "tapi-connectivity:direction": "BIDIRECTIONAL",
+ "tapi-connectivity:role": "SYMMETRIC",
+ "tapi-connectivity:protection-role": "WORK",
+ "tapi-connectivity:local-id": "<OpenROADM node ID>",
+ "tapi-connectivity:name": [
+ {
+ "tapi-connectivity:value-name": "OpenROADM node id",
+ "tapi-connectivity:value": "<OpenROADM node ID>"
+ }
+ ]
+ },
+ {
+ "tapi-connectivity:layer-protocol-name": "<Node_TAPI_Layer>",
+ "tapi-connectivity:service-interface-point": {
+ "tapi-connectivity:service-interface-point-uuid": "<SIP_UUID_of_NEP>"
+ },
+ "tapi-connectivity:administrative-state": "UNLOCKED",
+ "tapi-connectivity:operational-state": "ENABLED",
+ "tapi-connectivity:direction": "BIDIRECTIONAL",
+ "tapi-connectivity:role": "SYMMETRIC",
+ "tapi-connectivity:protection-role": "WORK",
+ "tapi-connectivity:local-id": "<OpenROADM node ID>",
+ "tapi-connectivity:name": [
+ {
+ "tapi-connectivity:value-name": "OpenROADM node id",
+ "tapi-connectivity:value": "<OpenROADM node ID>"
+ }
+ ]
+ }
+ ],
+ "tapi-connectivity:connectivity-constraint": {
+ "tapi-connectivity:service-layer": "<TAPI_Service_Layer>",
+ "tapi-connectivity:service-type": "POINT_TO_POINT_CONNECTIVITY",
+ "tapi-connectivity:service-level": "Some service-level",
+ "tapi-connectivity:requested-capacity": {
+ "tapi-connectivity:total-size": {
+ "value": "<CAPACITY>",
+ "unit": "GB"
+ }
+ }
+ },
+ "tapi-connectivity:state": "Some state"
+ }
+ }
+
+As for the previous RPC, MC and OTSi correspond to PHOTONIC_MEDIA layer services,
+ODU to ODU layer services and 10GE/DSR to DSR layer services. This RPC invokes the
+*Service Handler* module to trigger the *PCE* to compute a path over the
+*otn-topology* that must contains ODU4 links with valid bandwidth parameters. Once the path is computed
+and validated, the T-API CEPs (associated with a NEP), cross connections and top connections will be created
+according to the service request and the topology objects inside the computed path. Then, the *renderer* and
+*OLM* are invoked to implement the end-to-end path into the devices and to update the status of the connections
+and connectivity service.
+
+.. note::
+ Refer to the "Unconstrained E2E Service Provisioning" use cases from T-API Reference Implementation to get
+ more details about the process of connectivity service creation
+
+Deleting a connectivity service
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *TAPI* module in order to delete a given optical
+connectivity service.
+
+**REST API** : *POST /restconf/operations/tapi-connectivity:delete-connectivity-service*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "tapi-connectivity:input": {
+ "tapi-connectivity:service-id-or-name": "<Service_UUID_or_Name>"
+ }
+ }
+
+.. note::
+ Deleting OTN connectivity services implies proceeding in the reverse way to their creation. Thus, OTN
+ connectivity service deletion must respect the three following steps:
+ 1. delete first all 10GE services supported over any ODU4 to be deleted
+ 2. delete ODU4
+ 3. delete MC-OTSi supporting the just deleted ODU4
+
+T-API Notification Service
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In future releases, the T-API notification service will be implemented. The objective will be to write and read
+T-API notifications stored in topics of a Kafka server as explained later in the odl-transportpce-nbinotifications
+section, but T-API based.
+
+
+odl-transportpce-dmaap-client
+-----------------------------
+
+This feature allows TransportPCE application to send notifications on ONAP Dmaap Message router
+following service request results.
+This feature listens on NBI notifications and sends the PublishNotificationService content to
+Dmaap on the topic "unauthenticated. TPCE" through a POST request on /events/unauthenticated.TPCE
+It uses Jackson to serialize the notification to JSON and jersey client to send the POST request.
+
+odl-transportpce-nbinotifications
+---------------------------------
+
+This feature allows TransportPCE application to write and read notifications stored in topics of a Kafka server.
+It is basically composed of two kinds of elements. First are the 'publishers' that are in charge of sending a notification to
+a Kafka server. To protect and only allow specific classes to send notifications, each publisher
+is dedicated to an authorized class.
+There are the 'subscribers' that are in charge of reading notifications from a Kafka server.
+So when the feature is called to write notification to a Kafka server, it will serialize the notification
+into JSON format and then will publish it in a topic of the server via a publisher.
+And when the feature is called to read notifications from a Kafka server, it will retrieve it from
+the topic of the server via a subscriber and will deserialize it.
+
+For now, when the REST RPC service-create is called to create a bidirectional end-to-end service,
+depending on the success or the fail of the creation, the feature will notify the result of
+the creation to a Kafka server. The topics that store these notifications are named after the connection type
+(service, infrastructure, roadm-line). For instance, if the RPC service-create is called to create an
+infrastructure connection, the service notifications related to this connection will be stored in
+the topic 'infrastructure'.
+
+The figure below shows an example of the application nbinotifications in order to notify the
+progress of a service creation.
+
+.. figure:: ./images/TransportPCE-nbinotifications-service-example.jpg
+ :alt: Example of service notifications using the feature nbinotifications in TransportPCE
+
+
+Depending on the status of the service creation, two kinds of notifications can be published
+to the topic 'service' of the Kafka server.
+
+If the service was correctly implemented, the following notification will be published :
+
+
+- **Service implemented !** : Indicates that the service was successfully implemented.
+ It also contains all information concerning the new service.
+
+
+Otherwise, this notification will be published :
+
+
+- **ServiceCreate failed ...** : Indicates that the process of service-create failed, and also contains
+ the failure cause.
+
+
+To retrieve these service notifications stored in the Kafka server :
+
+**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-process-service*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "connection-type": "service",
+ "id-consumer": "consumer",
+ "group-id": "test"
+ }
+ }
+
+.. note::
+ The field 'connection-type' corresponds to the topic that stores the notifications.
+
+Another implementation of the notifications allows to notify any modification of operational state made about a service.
+So when a service breaks down or is restored, a notification alarming the new status will be sent to a Kafka Server.
+The topics that store these notifications in the Kafka server are also named after the connection type
+(service, infrastructure, roadm-line) accompanied of the string 'alarm'.
+
+To retrieve these alarm notifications stored in the Kafka server :
+
+**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-alarm-service*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "connection-type": "infrastructure",
+ "id-consumer": "consumer",
+ "group-id": "test"
+ }
+ }
+
+.. note::
+ This sample is used to retrieve all the alarm notifications related to infrastructure services.
+
+Help
+----