Phosphorus consolidates end to end support for high rate services (ODUC4, OTUC4),
allowing service creation and deletion from the NBI. The support of path
-computation for high rate services (OTUC4) will be added through the different P
+computation for high rate services (OTUC4) has been added through the different P
releases, relying on GNPy for impairment aware path computation. An experimental
support of T-API is provided allowing service-create/delete from a T-API version
2.1.1 compliant NBI. A T-API network topology, with different levels of abstraction
monitoring device port state changes. Associated notifications are handled through
Kafka and DMaaP clients.
+Sulfur is introducing OpenROADM service and network models 10.1, which include the
+operational-modes catalog, needed for future support of Alien Wavelength use cases.
+It also offers T-API notification support, handling the RPC associated with the
+notification subscription service.
+
+The Chlorine release brings structural changes to the project. indeed, all the official
+yang models of the OpenROADM and ONF-TAPI communities are no longer managed directly
+in the TransportPCE project but in a dedicated sub-project: transportpce/models.
+Also, the implementation of these models which is made in TransportPCE now imports
+the models already compiled by maven dependency.
+From a functional point of view, Chlorine supports the autonomous reroute of WDM services
+terminated on 100G or 400G Transponders, as well as the beginning of developments around
+the OpenROAM catalog management.
+
+The Argon release provides autonomous impairment aware path computation, relying on
+OpenROADM operational-modes catalog. It is used in a first step of the path validation,
+to evaluate the Optical Signal to Noise Ratio as well as the penalty associated with the
+signal across the calculated pass. Validation of the optical path by GNPy is still
+triggered, in a second step, leveraging advanced calculation of non linear contribution.
+
Module description
~~~~~~~~~~~~~~~~~~
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.
+the topology update and the *odl-transportpce-nbinotifications* feature is installed, the Service
+Handler will send a notification to a Kafka server with the service update information.
PCE
^^^
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. Central wavelength is assigned considering a fixed
-grid of 96 wavelengths 50 GHz spaced. The assignment of wavelengths according to a flexible
-grid considering 768 subsequent slots of 6,25 GHz (total spectrum of 4.8 Thz), and their
-occupation by existing services is planned for later releases.
-In Neon SR0, the PCE calculates the OSNR, on the base of incremental noise specifications
-provided in Open ROADM MSA. The support of unidirectional ports is also added.
+count (default) or the propagation delay. The support of a flexible grid was introduced in Aluminium.
+The central wavelength assignment depends on the capabilities of the different devices on the path.
+If one of the elements only supports a fixed grid, the wavelength is assigned considering a grid of
+96 wavelengths 50 GHz spaced. If all the devices on the path support a flexible grid, the assignment
+of wavelengths is done according to a flexible grid considering 768 subsequent slots of 6,25 GHz
+(total spectrum of 4.8 Thz).
-PCE handles the following constraints as hard constraints:
+The PCE module handles the following constraints as hard constraints:
- **Node exclusion**
- **SRLG exclusion**
- **Maximum latency**
-In Magnesium SR0, the interconnection of the PCE with GNPY (Gaussian Noise Python), an
-open-source library developed in the scope of the Telecom Infra Project for building route
-planning and optimizing performance in optical mesh networks, is fully supported. Impairment
-aware path computation for service of higher rates (Beyond 100G) is planned across Phoshorus
-releases. It implies to make B100G OpenROADM specifications available in GNPy libraries.
-
-If the OSNR calculated by the PCE is too close to the limit defined in OpenROADM
-specifications, the PCE forwards through a REST interface to GNPY external tool the topology
-and the pre-computed path translated in routing constraints. GNPy calculates a set of Quality of
-Transmission metrics for this path using its own library which includes models for OpenROADM.
-The result is sent back to the PCE. If the path is validated, the PCE sends back a response to
-the service handler. In case of invalidation of the path by GNPY, the PCE sends a new request to
-GNPY, including only the constraints expressed in the path-computation-request initiated by the
-Service Handler. GNPy then tries to calculate a path based on these relaxed constraints. The
-result of the path computation is provided to the PCE which translates the path according to the
-topology handled in transportPCE and forwards the results to the Service Handler.
-
-GNPy relies on SNR and takes into account the linear and non-linear impairments
-to check feasibility. In the related tests, GNPy module runs externally in a
-docker and the communication with T-PCE is ensured via HTTPs.
+In Neon SR0, the PCE calculates the OSNR, on the base of incremental noise specifications provided
+in Open ROADM MSA. The support of unidirectional ports is also added. The interconnection of the PCE
+with GNPY (Gaussian Noise Python), an open-source library developed in the scope of the Telecom Infra
+Project for building route planning and optimizing performance in optical mesh networks, is supported
+since Magnesium SR0. This allowed introducing impairment aware path computation for (Beyond 100G)
+services across Phoshorus releases.
+
+In Argon, we introduce autonomous impairment aware path computation, leveraging OpenROADM yang
+specification catalog (R10.1), which translates the optical specifications provided in the MSA into
+models understandable by the controller. To each disaggregated element crossed along the path
+(Transponders, ROADM add/drop modules and degrees), is associated an operational mode, for which each
+physical parameters is described in the catalog. This allows evaluating the degradations that each
+element, whether it is a device of fiber span, brings to the signal transmission. The resulting
+Optical Signal to Noise Ratio is calculated, as well as the penalties associated with the cumulated
+chromatic dispersion, Polarisation Mode Dispersion (PMD), Polarization Dependant Loss (PDL)… and the
+non-linear contribution is evaluated.
+
+All of this is done in accordance with OpenROADM optical specifications. Handling OpenROADM specification
+catalogs improves the upgradability of the code, since the future evolution of the specifications only
+implies to add new operational modes to the catalog while the associated code remains unchanged.
+
+In Argon SR0, to benefit from this new functionality, the specification catalog must be manually loaded
+into the data store. The catalog includes 2 different parts, the first being dedicated to the
+translation of OpenROADM specifications, the second (optional) being dedicated to specific operational
+modes for transponders used in “bookended” mode (same transponders on both ends of the path). The
+automatic filling of the first part of the catalog is planned in Ar SR1. In this release will also be
+supported the 2 RPCs used to fill the different parts of the catalog :
+- **add-openroadm-operational-mode-to-catalog**
+- **add-specific-operational-mode-to-catalog**
+
+Autonomous impairment aware path computation is triggered in Argon for any path at the WDM layer,
+whatever is the service rate. The transmission margin is evaluated in both direction and the result is
+provided in INFO Logs. GNPy is used in a second step to enforce path validation. Indeed, it gives
+complementary information to the calculation made from OpenROADM specifications, with a finer assessment
+of non-linear contribution, and potentially a consideration of the interaction with other channels
+already provisioned on the network. This last capability will be added across Argon releases.
+The PCE forwards through a REST interface to GNPY external tool the topology and the pre-computed path
+translated in routing constraints. GNPy calculates a set of Quality of Transmission metrics for this path
+using its own library which includes models for OpenROADM. The result is sent back to the PCE. If the
+path is validated, the PCE sends back a response to the service handler. In case of invalidation of the
+path by GNPY, the PCE sends a new request to GNPY, including only the constraints expressed in the
+path-computation-request initiated by the Service Handler. GNPy then tries to calculate a path based on
+these relaxed constraints. The result of the path computation is provided to the PCE which translates
+the path according to the topology handled in transportPCE and forwards the results to the Service
+Handler.
+
+GNPy relies on SNR and takes into account the linear and non-linear impairments to check feasibility.
+In the related tests, GNPy module runs externally in a docker and the communication with T-PCE is
+ensured via HTTPs.
Topology Management
^^^^^^^^^^^^^^^^^^^
North API, interconnecting the Service Handler to higher level applications
relies on the Service Model defined in the MSA. The Renderer and the OLM are
-developed to allow configuring Open ROADM devices through a southbound
+developed to allow configuring OpenROADM devices through a southbound
Netconf/Yang interface and rely on the MSA’s device model.
ServiceHandler Service
In the current version, only optical equipment compliant with open ROADM datamodels are managed
by transportPCE.
+ Since Chlorine release, the bierman implementation of RESTCONF is no longer supported for the benefit of the RFC8040.
+ Thus REST API must be compliant to the RFC8040 format.
+
Connecting nodes
~~~~~~~~~~~~~~~~
end-to-end optical connectivity service between two xpdr over an optical network composed of rdm
nodes.
-**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-create*
**Sample JSON Data**
"node-id": "<xpdr-node-id>",
"service-format": "Ethernet",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"service-z-end": {
"node-id": "<xpdr-node-id>",
"service-format": "Ethernet",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"due-date": "yyyy-mm-ddT00:00:01Z",
end-to end Optical Channel (OC) connectivity service between two add/drop ports (PP port of SRG
node) over an optical network only composed of rdm nodes.
-**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-create*
**Sample JSON Data**
"node-id": "<xpdr-node-id>",
"service-format": "OC",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"service-z-end": {
"node-id": "<xpdr-node-id>",
"service-format": "OC",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-client-port>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"due-date": "yyyy-mm-ddT00:00:01Z",
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*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-create*
**Sample JSON Data**
"service-format": "OTU",
"otu-service-rate": "org-openroadm-otn-common-types:OTU4",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"service-z-end": {
"service-format": "OTU",
"otu-service-rate": "org-openroadm-otn-common-types:OTU4",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"due-date": "yyyy-mm-ddT00:00:01Z",
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*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-create*
**Sample JSON Data**
"service-format": "OTU",
"otu-service-rate": "org-openroadm-otn-common-types:OTUCn",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"service-z-end": {
"service-format": "OTU",
"otu-service-rate": "org-openroadm-otn-common-types:OTUCn",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"due-date": "yyyy-mm-ddT00:00:01Z",
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*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-create*
**Sample JSON Data**
"service-format": "ODU",
"otu-service-rate": "org-openroadm-otn-common-types:ODU4",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"service-z-end": {
"service-format": "ODU",
"otu-service-rate": "org-openroadm-otn-common-types:ODU4",
"clli": "<ccli-name>",
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"due-date": "yyyy-mm-ddT00:00:01Z",
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*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-create*
**Sample JSON Data**
"committed-burst-size": "64"
}
},
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"service-z-end": {
"committed-burst-size": "64"
}
},
- "tx-direction": {
+ "tx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
- "rx-direction": {
+ },
+ "index": 0
+ }],
+ "rx-direction": [{
"port": {
"port-device-name": "<xpdr-node-id-in-otn-topology>",
"port-type": "fixed",
"lgx-port-name": "Some lgx-port-name",
"lgx-port-rack": "000000.00",
"lgx-port-shelf": "00"
- }
- },
+ },
+ "index": 0
+ }],
"optic-type": "gray"
},
"due-date": "yyyy-mm-ddT00:00:01Z",
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*
+**REST API** : *POST /rests/operations/org-openroadm-service:service-delete*
**Sample JSON Data**
Checking OTU4 service connectivity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+**REST API** : *POST /rests/operations/transportpce-pce:path-computation-request*
**Sample JSON Data**
"service-format": "OTU",
"node-id": "<otn-node-id>"
},
- "pce-metric": "hop-count"
+ "pce-routing-metric": "hop-count"
}
}
Checking ODU4 service connectivity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+**REST API** : *POST /rests/operations/transportpce-pce:path-computation-request*
**Sample JSON Data**
"service-format": "ODU",
"node-id": "<otn-node-id>"
},
- "pce-metric": "hop-count"
+ "pce-routing-metric": "hop-count"
}
}
Checking 10GE/ODU2e service connectivity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+**REST API** : *POST /rests/operations/transportpce-pce:path-computation-request*
**Sample JSON Data**
"service-format": "Ethernet",
"node-id": "<otn-node-id>"
},
- "pce-metric": "hop-count"
+ "pce-routing-metric": "hop-count"
}
}
of respectively XPDR-A1-XPDR1 and XPDR-C1-XPDR1...
-**REST API** : *POST /restconf/operations/tapi-topology:get-topology-details*
+**REST API** : *POST /rests/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.
}
}
-**REST API** : *POST /restconf/operations/tapi-topology:get-node-details*
+**REST API** : *POST /rests/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.
}
}
-**REST API** : *POST /restconf/operations/tapi-topology:get-node-edge-point-details*
+**REST API** : *POST /rests/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.
}
}
-**REST API** : *POST /restconf/operations/tapi-topology:get-link-details*
+**REST API** : *POST /rests/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.
From xpdr <--> rdm:
^^^^^^^^^^^^^^^^^^^
-**REST API** : *POST /restconf/operations/transportpce-tapinetworkutils:init-xpdr-rdm-tapi-link*
+**REST API** : *POST /rests/operations/transportpce-tapinetworkutils:init-xpdr-rdm-tapi-link*
**Sample JSON Data**
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*
+**REST API** : *POST /rests/operations/tapi-connectivity:create-connectivity-service*
**Sample JSON Data**
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*
+**REST API** : *POST /rests/operations/tapi-connectivity:delete-connectivity-service*
**Sample JSON Data**
In the current implementation, only Connectivity Service related notification are supported.
-**REST API** : *POST /restconf/operations/tapi-notification:get-supported-notification-types*
+**REST API** : *POST /rests/operations/tapi-notification:get-supported-notification-types*
The response body will include the type of notifications supported and the object types
Use the following RPC to create a Notification Subscription Service.
-**REST API** : *POST /restconf/operations/tapi-notification:create-notification-subscription-service*
+**REST API** : *POST /rests/operations/tapi-notification:create-notification-subscription-service*
**Sample JSON Data**
To retrieve these tapi connectivity service notifications stored in the kafka server:
-**REST API** : *POST /restconf/operations/tapi-notification:get-notification-list*
+**REST API** : *POST /rests/operations/tapi-notification:get-notification-list*
**Sample JSON Data**
To retrieve these service notifications stored in the Kafka server :
-**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-process-service*
+**REST API** : *POST /rests/operations/nbi-notifications:get-notifications-process-service*
**Sample JSON Data**
To retrieve these alarm notifications stored in the Kafka server :
-**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-alarm-service*
+**REST API** : *POST /rests/operations/nbi-notifications:get-notifications-alarm-service*
**Sample JSON Data**
Code Review / transportpce.git / blobdiff