relying on open models, each of them communicating through published APIs.
-.. figure:: ./images/tpce_architecture.jpg
+.. figure:: ./images/TransportPCE-Diagramm-Magnesium.jpg
:alt: TransportPCE architecture
TransportPCE architecture
different suppliers. Thus, interoperability in the optical layer is a key
element to get the benefit of automated control.
-Initial design of TransportPCE leverages Open ROADM Multi-Source-Agreement (MSA)
+Initial design of TransportPCE leverages OpenROADM Multi-Source-Agreement (MSA)
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.
-OTN support will be improved in the following magnesium 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
service. The service-list is updated following a successful service deletion. In Neon SR0 is
added the support for service from ROADM to ROADM, which brings additional flexibility and
notably allows reserving resources when transponders are not in place at day one.
-The full support of OTN services, including OTU, HO-ODU and LO-ODU will be introduced
-in next release of Magnesium.
+Magnesium SR2 fully supports end-to-end OTN services which are part of the OTN infrastructure.
+It concerns the management of OCH-OTU4 (also part of the optical infrastructure) and structured
+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 (Mg/Al).
PCE
-^^^^^^^^^^^^^^
+^^^
The Path Computation Element (PCE) is the component responsible for path
calculation. An interface allows the Service Handler or external components such as an
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 RAODM 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**
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 metric for this path using its own library which includes models for OpenROADM.
+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
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.
+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
-^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^
Topology management module builds the Topology according to the Network model
defined in OpenROADM. The topology is aligned with IETF I2RS RFC8345 model.
- **Topology layer introduces a second level of disaggregation where ROADMs
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
- 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),
+- **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. 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.
- However, the population of OTN links, and the adjustment of the tributary ports/slots
- pull occupancy when OTN services are created will be handled in later Magnesium release.**
+ 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.**
Renderer
Portmapping module also allows to keep the topology independant from the devices releases.
In Neon (SR0), portmapping module has been enriched to support both openroadm 1.2.1 and 2.2.1
device models. The full support of openroadm 2.2.1 device models (both in the topology management
-and the renderingfunction) has been added in Neon SR1. In Magnesium, portmapping is enriched with
+and the rendering function) has been added in Neon SR1. In Magnesium, portmapping is enriched with
the supported-interface-capability, OTN supporting-interfaces, and switching-pools (reflecting
cross-connection capabilities of OTN switch-ponders).
(as they were before invoking the Renderer).
Magnesium brings the support of OTN services. SR0 supports the creation of OTU4, ODU4, ODU2/ODU2e
-and ODU1 interfaces. The creation of these interfaces must be triggered through otn-service-path
-RPC. Full support (service-implementation-request /service delete rpc, topology alignement after
-the service has been created) will be provided in later releases of Magnesium.
+and ODU0 interfaces. The creation of these low-order otn interfaces must be triggered through
+otn-service-path RPC. Magnesium SR2 fully supports end-to-end otn service implementation into devices
+(service-implementation-request /service delete rpc, topology alignement after the service has been created).
OLM
-^^^^^^^^
+^^^
Optical Line Management module implements two main features: it is responsible
for setting up the optical power levels on the different interfaces, and is in
PM retrieved from the device to verify that the setting was correctly applied
and the configuration was successfully completed.
+
+Inventory
+^^^^^^^^^
+
+TransportPCE Inventory module is responsible to keep track of devices connected in an external MariaDB database.
+Other databases may be used as long as they comply with SQL and are compatible with OpenDaylight (for example MySQL).
+At present, the module supports extracting and persisting inventory of devices OpenROADM MSA version 1.2.1.
+Inventory module changes to support newer device models (2.2.1, etc) and other models (network, service, etc)
+will be progressively included.
+
+The inventory module can be activated by the associated karaf feature (odl-transporpce-inventory)
+The database properties are supplied in the “opendaylight-release” and “opendaylight-snapshots” profiles.
+Below is the settings.xml with properties included in the distribution.
+The module can be rebuild from sources with different parameters.
+
+Sample entry in settings.xml to declare an external inventory database:
+::
+
+ <profiles>
+ <profile>
+ <id>opendaylight-release</id>
+ [..]
+ <properties>
+ <transportpce.db.host><<hostname>>:3306</transportpce.db.host>
+ <transportpce.db.database><<databasename>></transportpce.db.database>
+ <transportpce.db.username><<username>></transportpce.db.username>
+ <transportpce.db.password><<password>></transportpce.db.password>
+ <karaf.localFeature>odl-transportpce-inventory</karaf.localFeature>
+ </properties>
+ </profile>
+ [..]
+ <profile>
+ <id>opendaylight-snapshots</id>
+ [..]
+ <properties>
+ <transportpce.db.host><<hostname>>:3306</transportpce.db.host>
+ <transportpce.db.database><<databasename>></transportpce.db.database>
+ <transportpce.db.username><<username>></transportpce.db.username>
+ <transportpce.db.password><<password>></transportpce.db.password>
+ <karaf.localFeature>odl-transportpce-inventory</karaf.localFeature>
+ </properties>
+ </profile>
+ </profiles>
+
+
+Once the project built and when karaf is started, the cfg file is generated in etc folder with the corresponding
+properties supplied in settings.xml. When devices with OpenROADM 1.2.1 device model are mounted, the device listener in
+the inventory module loads several device attributes to various tables as per the supplied database.
+The database structure details can be retrieved from the file tests/inventory/initdb.sql inside project sources.
+Installation scripts and a docker file are also provided.
+
Key APIs and Interfaces
-----------------------
- service-delete (given service-name)
- - otn-service-path (given service-name, service-aend, service-zend) used in SR0 as
- an intermediate solution to address directly the renderer from a REST NBI for
- otn-service creation. Otn service-creation through service-implementation-request
- call from the Service Handler will be supported in later Magnesium releases
-
- Data structure
- service path list : composed of service paths
- service-path-rpc-result : result of service RPC
+Device Renderer
+^^^^^^^^^^^^^^^
+
+- RPC call
+
+ - service-path used in SR0 as an intermediate solution to address directly the renderer
+ from a REST NBI to create OCH-OTU4-ODU4 interfaces on network port of otn devices.
+
+ - otn-service-path used in SR0 as an intermediate solution to address directly the renderer
+ from a REST NBI for otn-service creation. Otn service-creation through
+ service-implementation-request call from the Service Handler will be supported in later
+ Magnesium releases
+
Topology Management Service
^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Data structure
- network list : composed of networks(openroadm-topology, netconf-topology)
- - node list : composed of node-id
- - link list : composed of link-id
+ - node list : composed of nodes identified by their node-id
+ - link list : composed of links identified by their link-id
- node : composed of roadm, xponder
link : composed of links of different types (roadm-to-roadm, express, add-drop ...)
OTN topology
~~~~~~~~~~~~
-Before creating an OTN service, your topology must contain at least two xpdr devices of MUXPDR or
-SWITCH type connected to two different rdm devices. To check that these xpdr are present in the
+Before creating an OTN service, your topology must contain at least two xpdr devices of MUXPDR
+or SWITCH type connected to two different rdm devices. To check that these xpdr are present in the
OTN topology, use the following command on the REST API :
**REST API** : *GET /restconf/config/ietf-network:network/otn-topology*
-An optical connectivity service shall have been created in a first setp. In Magnesium SR0, the OTN
-links are not automatically populated in the topology after the Och, OTU4 and ODU4 interfaces have
-been created on the two network ports of the xpdr. Thus the otn link must be posted manually through
-the REST API (APIDoc).
-
-**REST API** : *POST /restconf/config/ietf-network:network/otn-topology/link*
-**REST API** : to complete
-
+An optical connectivity service shall have been created in a first setp. Since Magnesium SR2, the OTN
+links are automatically populated in the topology after the Och, OTU4 and ODU4 interfaces have
+been created on the two network ports of the xpdr.
Creating a service
~~~~~~~~~~~~~~~~~~
-In Magnesium SR0, two different kind of services can be created with transportPCE using the Northbound
-REST API:
+Use the *service handler* module to create any end-to-end connectivity service on an OpenROADM
+network. Two kind of end-to-end "optical" services are managed by TransportPCE:
+- 100GE service from client port to client port of two transponders (TPDR)
+- Optical Channel (OC) service from client add/drop port (PP port of SRG) to client add/drop port of
+two ROADMs.
+
+For these services, TransportPCE automatically invokes *renderer* module to create all required
+interfaces and cross-connection on each device supporting the service.
+As an example, the creation of a 100GE service implies among other things, the creation of OCH, OTU4
+and ODU4 interfaces on the Network port of TPDR devices.
-- 100GE services from client port to client port of two transponders (TPDR)
-- an OTU-4/ODU-4 service from network port to network port of two Xponders (MUXPDR/SWITCH)
+Since Magnesium SR2, the *service handler* module directly manages some end-to-end otn
+connectivity services.
+Before creating a low-order OTN 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 service creation implies three steps:
+1. OCH-OTU4 service from network port to network port of two OTN Xponders (MUXPDR or SWITCH)
+2. HO-ODU4 service from network port to network port of two OTN Xponders (MUXPDR or SWITCH)
+3. 10GE service creation from client port to client port of two OTN Xponders (MUXPDR or SWITCH)
-For the creation of 1GE and 10GE services the user has to check using internal API the connectivity
-between nodes and the possibility to create a service through the path-computation-request rpc. The
-service creation is performed using internal otn-service-path rpc.
+The management of other OTN services (1GE-ODU0, 100GE...) is planned for future releases.
-100GE service creation:
-^^^^^^^^^^^^^^^^^^^^^^^
+
+100GE service creation
+^^^^^^^^^^^^^^^^^^^^^^
Use the following REST RPC to invoke *service handler* module in order to create a bidirectional
end-to-end optical connectivity service between two xpdr over an optical network composed of rdm
on xpdr nodes.This RPC invokes the *PCE* module to compute a path over the *openroadm-topology* and
then invokes *renderer* and *OLM* to implement the end-to-end path into the devices.
-OTU4/ODU4 service creation :
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+OC service creation
+^^^^^^^^^^^^^^^^^^^
Use the following REST RPC to invoke *service handler* module in order to create a bidirectional
-end-to-end optical connectivity service between two xpdr over an optical network composed of rdm
-nodes.
+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.
-XXXXXXXXXXXXXXX (TO BE COMPLETED )XXXXXXXXXXXXXXXXX
+**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
+**Sample JSON Data**
-1GE/ODU0 and 10GE/ODU2e service creation :
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. code:: json
-Use the following REST RPC to invoke *PCE* module in order to check connectivity between xponder
-nodes and the availability of a supporting optical connectivity between the network-ports of the
-nodes.
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "roadm-line",
+ "service-a-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OC",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OC",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-client-port>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-number>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "due-date": "yyyy-mm-ddT00:00:01Z",
+ "operator-contact": "some-contact-info"
+ }
+ }
-**REST API** : to complete
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*openroadm-topology* and then invokes *renderer* and *OLM* to implement the end-to-end path into
+the devices.
-After end-to-end optical connectivity between the two xpdr has been checked, use the otn-service-path
-rpc to invoke the *Renderer* and create the corresponding interfaces :
+OTN OCH-OTU4 service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 1GE and ODU0 interfaces for 1GE services
-- 10GE and ODU2e interfaces for 10GE services
+Use the following REST RPC to invoke *service handler* module in order to create over the optical
+infrastructure a bidirectional end-to-end OTU4 over an optical wavelength connectivity service
+between two optical network ports of OTN Xponder (MUXPDR or SWITCH). Such service configure the
+optical network infrastructure composed of rdm nodes.
-The following example corresponds to the creation of a 10GE service
+**REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
-**REST API** : to complete
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "infrastructure",
+ "service-a-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OTU",
+ "otu-service-rate": "org-openroadm-otn-common-types:OTU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "OTU",
+ "otu-service-rate": "org-openroadm-otn-common-types:OTU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "due-date": "yyyy-mm-ddT00:00:01Z",
+ "operator-contact": "some-contact-info"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*openroadm-topology* and then invokes *renderer* and *OLM* to implement the end-to-end path into
+the devices.
+
+OTN HO-ODU4 service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *service handler* module in order to create over the optical
+infrastructure a bidirectional end-to-end ODU4 OTN service over an OTU4 and structured to support
+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*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "infrastructure",
+ "service-a-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "ODU",
+ "otu-service-rate": "org-openroadm-otn-common-types:ODU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "ODU",
+ "otu-service-rate": "org-openroadm-otn-common-types:ODU4",
+ "clli": "<ccli-name>",
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-network-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "due-date": "yyyy-mm-ddT00:00:01Z",
+ "operator-contact": "some-contact-info"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*otn-topology* that must contains OTU4 links with valid bandwidth parameters, and then
+invokes *renderer* and *OLM* to implement the end-to-end path into the devices.
+
+OTN 10GE-ODU2e service creation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use the following REST RPC to invoke *service handler* module in order to create over the OTN
+infrastructure a bidirectional end-to-end 10GE-ODU2e OTN service over an ODU4.
+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*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "sdnc-request-header": {
+ "request-id": "request-1",
+ "rpc-action": "service-create",
+ "request-system-id": "appname"
+ },
+ "service-name": "something",
+ "common-id": "commonId",
+ "connection-type": "service",
+ "service-a-end": {
+ "service-rate": "10",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "Ethernet",
+ "clli": "<ccli-name>",
+ "subrate-eth-sla": {
+ "subrate-eth-sla": {
+ "committed-info-rate": "10000",
+ "committed-burst-size": "64"
+ }
+ },
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "service-z-end": {
+ "service-rate": "10",
+ "node-id": "<xpdr-node-id>",
+ "service-format": "Ethernet",
+ "clli": "<ccli-name>",
+ "subrate-eth-sla": {
+ "subrate-eth-sla": {
+ "committed-info-rate": "10000",
+ "committed-burst-size": "64"
+ }
+ },
+ "tx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "rx-direction": {
+ "port": {
+ "port-device-name": "<xpdr-node-id-in-otn-topology>",
+ "port-type": "fixed",
+ "port-name": "<xpdr-client-port-in-otn-topology>",
+ "port-rack": "000000.00",
+ "port-shelf": "Chassis#1"
+ },
+ "lgx": {
+ "lgx-device-name": "Some lgx-device-name",
+ "lgx-port-name": "Some lgx-port-name",
+ "lgx-port-rack": "000000.00",
+ "lgx-port-shelf": "00"
+ }
+ },
+ "optic-type": "gray"
+ },
+ "due-date": "yyyy-mm-ddT00:00:01Z",
+ "operator-contact": "some-contact-info"
+ }
+ }
+
+As for the previous RPC, this RPC invokes the *PCE* module to compute a path over the
+*otn-topology* that must contains ODU4 links with valid bandwidth parameters, and then
+invokes *renderer* and *OLM* to implement the end-to-end path into the devices.
-.. note::
- OTN links are not automatically populated in the topology after the ODU2e interfaces have
- been created on the two client ports of the xpdr. The otn link can be posted manually through
- the REST API (APIDoc).
.. note::
- With Magnesium SR0, the service-list corresponding to 1GE/10GE and OTU4/ODU4 services is not
- updated in the datastore after the interfaces have been created in the device.
+ Since Magnesium SR2, the service-list corresponding to OCH-OTU4, ODU4 or again 10GE-ODU2e services is
+ updated in the service-list datastore.
+.. note::
+ trib-slot is used when the equipment supports contiguous trib-slot allocation (supported from
+ Magnesium SR0). The trib-slot provided corresponds to the first of the used trib-slots.
+ complex-trib-slots will be used when the equipment does not support contiguous trib-slot
+ allocation. In this case a list of the different trib-slots to be used shall be provided.
+ The support for non contiguous trib-slot allocation is planned for later Magnesium release.
Deleting a service
~~~~~~~~~~~~~~~~~~
-**REST API** : to complete according to what can be done with 100GE/OTU4/1GE/10GE services
-
-Deleting a 100GE service
-^^^^^^^^^^^^^^^^^^^^^^^^
+Deleting any kind of service
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use the following REST RPC to invoke *service handler* module in order to delete a given optical
connectivity service.
"notification-url": "http://localhost:8585/NotificationServer/notify"
},
"service-delete-req-info": {
- "service-name": "test1",
+ "service-name": "something",
"tail-retention": "no"
}
}
Most important parameters for this REST RPC is the *service-name*.
+.. note::
+ Deleting OTN services implies proceeding in the reverse way to their creation. Thus, OTN
+ 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 OCH-OTU4 supporting the just deleted ODU4
+
+Invoking PCE module
+~~~~~~~~~~~~~~~~~~~
+
+Use the following REST RPCs to invoke *PCE* module in order to check connectivity between xponder
+nodes and the availability of a supporting optical connectivity between the network-ports of the
+nodes.
+
+Checking OTU4 service connectivity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "service-name": "something",
+ "resource-reserve": "true",
+ "service-handler-header": {
+ "request-id": "request1"
+ },
+ "service-a-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "OTU",
+ "node-id": "<otn-node-id>"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "OTU",
+ "node-id": "<otn-node-id>"
+ },
+ "pce-metric": "hop-count"
+ }
+ }
+
+.. note::
+ here, the <otn-node-id> corresponds to the node-id as appearing in "openroadm-network" topology
+ layer
+
+Checking ODU4 service connectivity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "service-name": "something",
+ "resource-reserve": "true",
+ "service-handler-header": {
+ "request-id": "request1"
+ },
+ "service-a-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "ODU",
+ "node-id": "<otn-node-id>"
+ },
+ "service-z-end": {
+ "service-rate": "100",
+ "clli": "<clli-node>",
+ "service-format": "ODU",
+ "node-id": "<otn-node-id>"
+ },
+ "pce-metric": "hop-count"
+ }
+ }
+
+.. note::
+ here, the <otn-node-id> corresponds to the node-id as appearing in "otn-topology" layer
+
+Checking 10GE/ODU2e service connectivity
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *POST /restconf/operations/transportpce-pce:path-computation-request*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "input": {
+ "service-name": "something",
+ "resource-reserve": "true",
+ "service-handler-header": {
+ "request-id": "request1"
+ },
+ "service-a-end": {
+ "service-rate": "10",
+ "clli": "<clli-node>",
+ "service-format": "Ethernet",
+ "node-id": "<otn-node-id>"
+ },
+ "service-z-end": {
+ "service-rate": "10",
+ "clli": "<clli-node>",
+ "service-format": "Ethernet",
+ "node-id": "<otn-node-id>"
+ },
+ "pce-metric": "hop-count"
+ }
+ }
+
+.. note::
+ 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.
+
+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
----
-- `TransportPCE Wiki archive <https://wiki-archive.opendaylight.org/view/TransportPCE:Main>`__
-
-- TransportPCE Mailing List
- (`developer <https://lists.opendaylight.org/mailman/listinfo/transportpce-dev>`__)
+- `TransportPCE Wiki <https://wiki.opendaylight.org/display/ODL/TransportPCE>`__
Code Review / transportpce.git / blobdiff