docs/release-notes/projects/transportpce.rst

   1 =============
   2 Transport PCE
   3 =============
   4
   5 Overview
   6 ========
   7
   8 Transport PCE is an application running on top of the OpenDaylight controller. Its primary function
   9 is to control an optical transport infrastructure using a non-proprietary South Bound Interface (SBI).
  10
  11 The controlled transport infrastructure includes a WDM (Wave Division Multiplexing) layer and an OTN
  12 (optical transport network) layer. The WDM layer is built from ROADMs (reconfigurable optical add-drop multiplexer)
  13 with colorless, directionless and contention-less features. The OTN layer is built from transponders,
  14 muxponders or switchponders which include OTN switching functionalities.
  15
  16 Transport PCE leverages OpenROADM Multi-Source-Agreement (MSA), which defines interoperability specifications,
  17 consisting of both optical interoperability and YANG data models.
  18
  19 The TransportPCE implementation includes:
  20
  21 .. list-table:: Transport PCE implementation
  22    :widths: 20 50
  23    :header-rows: 1
  24
  25    * - **Feature**
  26      - **Description**
  27
  28    * - **Northbound API**
  29      - These APIs are for higher level applications, implemented in the Service Handler bundle.
  30        It relies on the service model defined in the MSA.
  31        A minimal experimental support of TAPI topology is also proposed but is not installed by default.
  32    * - **Renderer and OLM**
  33      - The renderer and OLM (Optical Line Management) bundles allow configuring OpenROADM devices
  34        through a southbound NETCONF/YANG interface (based on the MSA device models).
  35        This release supports the OpenROADM devices version 1.2.1 version 2.2.1.
  36    * - **Topology Management**
  37      - This feature is based on the defined MSA network model.
  38    * - **Path Calculation Engine (PCE)**
  39      - PCE here has a different meaning than the BGPCEP project since it is not based on (G)MPLS.
  40        This bundle allows to compute path across the topology to create services. Impairment aware path computation
  41        can be delegated to a GNPy server (hardcoded server address configuration and limited support at that time)
  42    * - **Inventory**
  43      - This feature is not installed by default.
  44        It proposes an experimental support for an external inventory DB currently limited to 1.2.1 OpenROADM devices.
  45
  46 The internal RPCs between those modules are defined in the Transport Service Path models.
  47
  48
  49 Behavior/Feature Changes
  50 ========================
  51
  52 TransportPCE Phosphorus release provides an improved End to End support of high rates services (100GE, OTU4 and 400GE over OTUC4).
  53 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 and service contexts are maintained in the MDSAL.
  54 Service state is managed, monitoring device port state changes. Associated notifications are handled through Kafka and  DMaaP clients.
  55
  56 Changes planned in Phosphorus release stream
  57 ============================================
  58
  59 Impairment aware path calculation relying on GNPy for End to End high rate services (beyond 100G) will be introduced across the Phosphorus release train.
  60 As for OTN use cases, additional use cases with more complex network configurations will be managed:
  61 - 100GE service terminated on an OTN switch
  62 - use of a 100G OTN switch as intermediate otn switch (with low order or high order odu switching) along a 1GE or 10GE service
  63 - management of OTN services (100GE, ODU4) supported by several OTU4s.
  64 T-API models should evolve towards version 2.1.3.
  65 Finally, Phosphorus release stream will bring end to end management of services for intermediate higher rates, as 200GE or 300GE.
  66
  67 P-SR1 brings as new functionality the management of 100GE services terminated on an OTN switch.
  68 P-SR1 also consolidates the T-API topology implementations (especially the topology named "Full Multi-layer topology"), strengthening the tests (JUnit and python functional tests) of this functionality.
  69 Python code of the functional test part has also been improved, and the migration of our functional tests towards the RFC8040 has just started.
  70 Finally, P-SR1 also brings some code improvements (highlighted by sonar) and few fixes.
  71
  72 New Features
  73 ============
  74
  75 There are no new features.
  76
  77 Deprecated Features
  78 ===================
  79
  80 There are no deprecated or removed features.
  81
  82 Resolved Issues
  83 ===============
  84
  85 The following table lists the issues resolved in this release.
  86
  87 .. jira_fixed_issues::
  88    :project: TRNSPRTPCE
  89    :versions: Phosphorus-Phosphorus
  90
  91 Known Issues
  92 ============
  93
  94 The following table lists the known issues that exist in this release.
  95
  96 .. jira_known_issues::
  97    :project: TRNSPRTPCE
  98    :versions: Phosphorus-Phosphorus