+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.
+
+
Code Review / transportpce.git / commitdiff
