X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2Fdeveloper-guide.rst;h=7380ac54bd61411e01cf0b6d455aaebad9c3eea9;hb=4fc7683a8eefbd3121f6c90c1444394b91973e8a;hp=7ea61b67d9b2277d1333dfd8b237137dd00d6141;hpb=1cc3251d3fcf2dbb3bf431a75cf6c9a915e2db0f;p=transportpce.git diff --git a/docs/developer-guide.rst b/docs/developer-guide.rst index 7ea61b67d..7380ac54b 100644 --- a/docs/developer-guide.rst +++ b/docs/developer-guide.rst @@ -1340,6 +1340,180 @@ Checking 10GE/ODU2e service connectivity here, the 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, part of the Topology Service component +is implemented, allowing to expose to higher level applications an abstraction of its OpenROADM +topologies in the form of topologies respecting the T-API modelling. The current version of TransportPCE +implements the *tapi-topology.yang* model in the revision 2018-12-10 (T-API v2.1.2). + + +- RPC call + + - get-topology-details + +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. + +Two 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. + +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. + +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. +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. +When the feature is called to read notifications from a Kafka server, it will retrieve it from +the topic of the server 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 progression 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 of the success of the service creation, different notifications will be published +to the topic 'service' of the Kafka server. + + +- **ServiceCreate request received** : Indicates that TransportPCE received an RPC request service-create + and started the process of creation. The notification contains all information concerning + the new service to create. + + +If the service was correctly implemented, these notifications will be published : + + +- **PCE calculation done OK !** : Indicates that the PCE calculation requested by the service-create + was successful. It also contains all information concerning the new service to create. +- **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. + It contains the failure response. + +To retrieve these service notifications stored in the Kafka server : + +**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-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 store the notifications. + Help ----