which defines interoperability specifications, consisting of both Optical
interoperability and Yang data models.
-Experimental support of OTN layer is introduced in Magnesium release of
-OpenDaylight. By experimental, we mean not all features can be accessed through
-northbound API based on RESTCONF encoded OpenROADM Service model. In the meanwhile,
-"east/west" APIs shall be used to trigger a path computation in the PCE (using
-path-computation-request RPC) and to create services (using otn-service-path RPC).
-With Magnesium SR2, TransportPCE starts to manage some end-to-end OTN services, as for example,
-OCH-OTU4, structured ODU4 or again 10GE-ODU2e services.
-OTN support will continue to be improved in the following releases.
+End to end OTN services such as OCH-OTU4, structured ODU4 or 10GE-ODU2e
+services are supported since Magnesium SR2. OTN support will continue to be
+improved in the following releases of Magnesium and Aluminium.
+An experimental support of Flexgrid is introduced in Aluminium. Depending on
+OpenROADM device models, optical interfaces can be created according to the
+initial fixed grid (for R1.2.1, 96 channels regularly spaced of 50 GHz), or to
+a flexgrid (for R2.2.1 use of specific number of subsequent frequency slots of
+6.25 GHz depending on one side of ROADMs and transponders capabilities and on
+the other side of the rate of the channel. The full support of Flexgrid,
+including path computation and the creation of B100G (Beyond 100 Gbps) higher
+rate interfaces will be added in the following releases of Aluminium.
Module description
HO-ODU4 services. Moreover, once these two kinds of OTN infrastructure service created, it is
possible to manage some LO-ODU services (for the time being, only 10GE-ODU2e services).
The full support of OTN services, including 1GE-ODU0 or 100GE, will be introduced along next
-releases.
+releases (Mg/Al).
+
+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.
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. 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 ROADM MSA. The support of unidirectional ports is
-also added. PCE handles the following constraints as hard constraints:
+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.
+
+PCE handles the following constraints as hard constraints:
- **Node exclusion**
- **SRLG exclusion**
Add/Drop modules ("SRGs") are separated from the degrees which includes line
amplifiers and WSS that switch wavelengths from one to another degree**
- **OTN layer introduced in Magnesium includes transponders as well as switch-ponders and
- mux-ponders having the ability to switch OTN containers from client to line cards. SR0 release
- includes creation of the switching pool (used to model cross-connect matrices),
+ mux-ponders having the ability to switch OTN containers from client to line cards. Mg SR0
+ release includes creation of the switching pool (used to model cross-connect matrices),
tributary-ports and tributary-slots at the initial connection of NETCONF devices.
The population of OTN links (OTU4 and ODU4), and the adjustment of the tributary ports/slots
pool occupancy when OTN services are created is supported since Magnesium SR2.**
+Since Silicon release, the Topology Management module process NETCONF event received through an
+event stream (as defined in RFC 5277) between devices and the NETCONF adapter of the controller.
+Current implementation detects device configuration changes and updates the topology datastore accordingly.
+Then, it sends a TopologyUpdateNotification to the *Service Handler* to indicate that a change has been
+detected in the network that may affect some of the already existing services.
Renderer
^^^^^^^^
- PCE to Topology Management
- Service Handler to Renderer
- Renderer to OLM
+- Network Model to Service Handler
Pce Service
^^^^^^^^^^^
- 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.
+ Stubs are used for development purposes and can be used for some of the functional tests.
Interfaces to external software
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
----
Code Review / transportpce.git / blobdiff