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).
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.**
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, 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.
+
Help
----
Code Review / transportpce.git / blobdiff