docs/developer-guide.rst

   1 .. _transportpce-dev-guide:
   2
   3 TransportPCE Developer Guide
   4 ============================
   5
   6 Overview
   7 --------
   8
   9 TransportPCE describes an application running on top of the OpenDaylight
  10 controller. Its primary function is to control an optical transport
  11 infrastructure using a non-proprietary South Bound Interface (SBI). It may be
  12 interconnected with Controllers of different layers (L2, L3 Controller…), a
  13 higher layer Controller and/or an Orchestrator through non-proprietary
  14 Application Programing Interfaces (APIs). Control includes the capability to
  15 configure the optical equipment, and to provision services according to a
  16 request coming from a higher layer controller and/or an orchestrator.
  17 This capability may rely on the controller only or it may be delegated to
  18 distributed (standardized) protocols.
  19
  20
  21 Architecture
  22 ------------
  23
  24 TransportPCE modular architecture is described on the next diagram. Each main
  25 function such as Topology management, Path Calculation Engine (PCE), Service
  26 handler, Renderer \_responsible for the path configuration through optical
  27 equipment\_ and Optical Line Management (OLM) is associated with a generic block
  28 relying on open models, each of them communicating through published APIs.
  29
  30
  31 .. figure:: ./images/tpce_architecture.jpg
  32    :alt: TransportPCE architecture
  33
  34    TransportPCE architecture
  35
  36 Fluorine, Neon and Sodium releases of transportPCE are dedicated to the control
  37 of WDM transport infrastructure. The WDM layer is built from colorless ROADMs
  38 and transponders.
  39
  40 The interest of using a controller to provision automatically services strongly
  41 relies on its ability to handle end to end optical services that spans through
  42 the different network domains, potentially equipped with equipment coming from
  43 different suppliers. Thus, interoperability in the optical layer is a key
  44 element to get the benefit of automated control.
  45
  46 Initial design of TransportPCE leverages Open ROADM Multi-Source-Agreement (MSA)
  47 which defines interoperability specifications, consisting of both Optical
  48 interoperability and Yang data models.
  49
  50 Experimental support of OTN layer is introduced in Magnesium release of
  51 OpenDaylight. By experimental, we mean not all features can be accessed through
  52 northbound API based on RESTCONF encoded OpenROADM Service model. In the meanwhile,
  53 "east/west" APIs shall be used to trigger a path computation in the PCE (using
  54 path-computation -request RPC) and to create services (using otn-service-path RPC.
  55 OTN support will be improved in the following magnesium releases.
  56
  57
  58
  59 Module description
  60 ~~~~~~~~~~~~~~~~~~
  61
  62 ServiceHandler
  63 ^^^^^^^^^^^^^^
  64
  65 Service Handler handles request coming from a higher level controller or an orchestrator
  66 through the northbound API, as defined in the Open ROADM service model. Current
  67 implementation addresses the following rpcs: service-create, temp-service-create,
  68 service–delete, temp-service-delete, service-reroute, and service-restoration. It checks the
  69 request consistency and trigs path calculation sending rpcs to the PCE. If a valid path is
  70 returned by the PCE, path configuration is initiated relying on Renderer and OLM. At the
  71 confirmation of a successful service creation, the Service Handler updates the service-
  72 list/temp-service-list in the MD-SAL. For service deletion, the Service Handler relies on the
  73 Renderer and the OLM to delete connections and reset power levels associated with the
  74 service. The service-list is updated following a successful service deletion. In Neon SR0 is
  75 added the support for service from ROADM to ROADM, which brings additional flexibility and
  76 notably allows reserving resources when transponders are not in place at day one.
  77 The full support of OTN services, including OTU, HO-ODU and LO-ODU will be introduced
  78 in next release of Magnesium.
  79
  80 PCE
  81 ^^^^^^^^^^^^^^
  82
  83 The Path Computation Element (PCE) is the component responsible for path
  84 calculation. An interface allows the Service Handler or external components such as an
  85 orchestrator to request a path computation and get a response from the PCE
  86 including the computed path(s) in case of success, or errors and indication of
  87 the reason for the failure in case the request cannot be satisfied. Additional
  88 parameters can be provided by the PCE in addition to the computed paths if
  89 requested by the client module. An interface to the Topology Management module
  90 allows keeping PCE aligned with the latest changes in the topology. Information
  91 about current and planned services is available in the MD-SAL data store.
  92
  93 Current implementation of PCE allows finding the shortest path, minimizing either the hop
  94 count (default) or the propagation delay. Wavelength is assigned considering a fixed grid of
  95 96 wavelengths. In Neon SR0, the PCE calculates the OSNR, on the base of incremental
  96 noise specifications provided in Open RAODM MSA. The support of unidirectional ports is
  97 also added. PCE handles the following constraints as hard constraints:
  98
  99 -   **Node exclusion**
 100 -   **SRLG exclusion**
 101 -   **Maximum latency**
 102
 103 In Magnesium SR0, the interconnection of the PCE with GNPY (Gaussian Noise Python), an
 104 open-source library developed in the scope of the Telecom Infra Project for building route
 105 planning and optimizing performance in optical mesh networks, is fully supported.
 106
 107 If the OSNR calculated by the PCE is too close to the limit defined in OpenROADM
 108 specifications, the PCE forwards through a REST interface to GNPY external tool the topology
 109 and the pre-computed path translated in routing constraints. GNPy calculates a set of Quality of
 110 Transmission metric for this path using its own library which includes models for OpenROADM.
 111 The result is sent back to the PCE. If the path is validated, the PCE sends back a response to
 112 the service handler. In case of invalidation of the path by GNPY, the PCE sends a new request to
 113 GNPY, including only the constraints expressed in the path-computation-request initiated by the
 114 Service Handler. GNPy then tries to calculate a path based on these relaxed constraints. The result
 115 of the path computation is provided to the PCE which translates the path according to the topology
 116 handled in transportPCE and forwards the results to the Service Handler.
 117
 118 GNPy relies on SNR and takes into account the linear and non-linear impairments to check feasibility.
 119 In the related tests, GNPy module runs externally in a docker and the communication with T-PCE is
 120 ensured via HTTPs.
 121
 122 Topology Management
 123 ^^^^^^^^^^^^^^^^^^^^^^^^
 124
 125 Topology management module builds the Topology according to the Network model
 126 defined in OpenROADM. The topology is aligned with IETF I2RS RFC8345 model.
 127 It includes several network layers:
 128
 129 -  **CLLI layer corresponds to the locations that host equipment**
 130 -  **Network layer corresponds to a first level of disaggregation where we
 131    separate Xponders (transponder, muxponders or switchponders) from ROADMs**
 132 -  **Topology layer introduces a second level of disaggregation where ROADMs
 133    Add/Drop modules ("SRGs") are separated from the degrees which includes line
 134    amplifiers and WSS that switch wavelengths from one to another degree**
 135 -  **OTN layer introduced in Magnesium includes transponders as well as switch-ponders
 136    having the ability to switch OTN containers from client to line cards. SR0 release
 137    includes creation of the switching pool (used to model cross-connect matrices),
 138    tributary-ports and tributary-slots at the initial connection of NETCONF devices.
 139    However, the population of OTN links, and the adjustment of the tributary ports/slots
 140    pull occupancy when OTN services are created will be handled in later Magnesium release.**
 141
 142
 143 Renderer
 144 ^^^^^^^^
 145
 146 The Renderer module, on request coming from the Service Handler through a service-
 147 implementation-request /service delete rpc, sets/deletes the path corresponding to a specific
 148 service between A and Z ends. The path description provided by the service-handler to the
 149 renderer is based on abstracted resources (nodes, links and termination-points), as provided
 150 by the PCE module. The renderer converts this path-description in a path topology based on
 151 device resources (circuit-packs, ports,…).
 152
 153 The conversion from abstracted resources to device resources is performed relying on the
 154 portmapping module which maintains the connections between these different resource types.
 155 Portmapping module also allows to keep the topology independant from the devices releases.
 156 In Neon (SR0), portmapping module has been enriched to support both openroadm 1.2.1 and 2.2.1
 157 device models. The full support of openroadm 2.2.1 device models (both in the topology management
 158 and the renderingfunction) has been added in Neon SR1. In Magnesium, portmapping is enriched with
 159 the supported-interface-capability, OTN supporting-interfaces, and switching-pools (reflecting
 160 cross-connection capabilities of OTN switch-ponders).
 161
 162 After the path is provided, the renderer first checks what are the existing interfaces on the
 163 ports of the different nodes that the path crosses. It then creates missing interfaces. After all
 164 needed interfaces have been created it sets the connections required in the nodes and
 165 notifies the Service Handler on the status of the path creation. Path is created in 2 steps
 166 (from A to Z and Z to A). In case the path between A and Z could not be fully created, a
 167 rollback function is called to set the equipment on the path back to their initial configuration
 168 (as they were before invoking the Renderer).
 169
 170 Magnesium brings the support of OTN services. SR0 supports the creation of OTU4, ODU4, ODU2/ODU2e
 171 and ODU1 interfaces. The creation of these interfaces must be triggered through otn-service-path
 172 RPC. Full support (service-implementation-request /service delete rpc, topology alignement after
 173 the service has been created) will be provided in later releases of Magnesium.
 174
 175
 176 OLM
 177 ^^^^^^^^
 178
 179 Optical Line Management module implements two main features: it is responsible
 180 for setting up the optical power levels on the different interfaces, and is in
 181 charge of adjusting these settings across the life of the optical
 182 infrastructure.
 183
 184 After the different connections have been established in the ROADMS, between 2
 185 Degrees for an express path, or between a SRG and a Degree for an Add or Drop
 186 path; meaning the devices have set WSS and all other required elements to
 187 provide path continuity, power setting are provided as attributes of these
 188 connections. This allows the device to set all complementary elements such as
 189 VOAs, to guaranty that the signal is launched at a correct power level
 190 (in accordance to the specifications) in the fiber span. This also applies
 191 to X-Ponders, as their output power must comply with the specifications defined
 192 for the Add/Drop ports (SRG) of the ROADM. OLM has the responsibility of
 193 calculating the right power settings, sending it to the device, and check the
 194 PM retrieved from the device to verify that the setting was correctly applied
 195 and the configuration was successfully completed.
 196
 197 Key APIs and Interfaces
 198 -----------------------
 199
 200 External API
 201 ~~~~~~~~~~~~
 202
 203 North API, interconnecting the Service Handler to higher level applications
 204 relies on the Service Model defined in the MSA. The Renderer and the OLM are
 205 developed to allow configuring Open ROADM devices through a southbound
 206 Netconf/Yang interface and rely on the MSA’s device model.
 207
 208 ServiceHandler Service
 209 ^^^^^^^^^^^^^^^^^^^^^^
 210
 211 -  RPC call
 212
 213    -  service-create (given service-name, service-aend, service-zend)
 214
 215    -  service-delete (given service-name)
 216
 217    -  service-reroute (given service-name, service-aend, service-zend)
 218
 219    -  service-restoration (given service-name, service-aend, service-zend)
 220
 221    -  temp-service-create (given common-id, service-aend, service-zend)
 222
 223    -  temp-service-delete (given common-id)
 224
 225 -  Data structure
 226
 227    -  service list : made of services
 228    -  temp-service list : made of temporary services
 229    -  service : composed of service-name, topology wich describes the detailed path (list of used resources)
 230
 231 -  Notification
 232
 233    - service-rpc-result : result of service RPC
 234    - service-notification : service has been added, modified or removed
 235
 236 Netconf Service
 237 ^^^^^^^^^^^^^^^
 238
 239 -  RPC call
 240
 241    -  connect-device : PUT
 242    -  disconnect-device : DELETE
 243    -  check-connected-device : GET
 244
 245 -  Data Structure
 246
 247    -  node list : composed of netconf nodes in topology-netconf
 248
 249 Internal APIs
 250 ~~~~~~~~~~~~~
 251
 252 Internal APIs define REST APIs to interconnect TransportPCE modules :
 253
 254 -   Service Handler to PCE
 255 -   PCE to Topology Management
 256 -   Service Handler to Renderer
 257 -   Renderer to OLM
 258
 259 Pce Service
 260 ^^^^^^^^^^^
 261
 262 -  RPC call
 263
 264    -  path-computation-request (given service-name, service-aend, service-zend)
 265
 266    -  cancel-resource-reserve (given service-name)
 267
 268 -  Notification
 269
 270    - service-path-rpc-result : result of service RPC
 271
 272 Renderer Service
 273 ^^^^^^^^^^^^^^^^
 274
 275 -  RPC call
 276
 277    -  service-implementation-request (given service-name, service-aend, service-zend)
 278
 279    -  service-delete (given service-name)
 280
 281    -  otn-service-path (given service-name, service-aend, service-zend) used in SR0 as
 282       an intermediate solution to address directly the renderer from a REST NBI for
 283       otn-service creation. Otn service-creation through service-implementation-request
 284       call from the Service Handler will be supported in later Magnesium releases
 285
 286 -  Data structure
 287
 288    -  service path list : composed of service paths
 289    -  service path : composed of service-name, path description giving the list of abstracted elements (nodes, tps, links)
 290
 291 -  Notification
 292
 293    - service-path-rpc-result : result of service RPC
 294
 295 Topology Management Service
 296 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 297
 298 -  Data structure
 299
 300    -  network list : composed of networks(openroadm-topology, netconf-topology)
 301    -  node list : composed of node-id
 302    -  link list : composed of link-id
 303    -  node : composed of roadm, xponder
 304       link : composed of links of different types (roadm-to-roadm, express, add-drop ...)
 305
 306 OLM Service
 307 ^^^^^^^^^^^
 308
 309 -  RPC call
 310
 311    -  get-pm (given node-id)
 312
 313    -  service-power-setup
 314
 315    -  service-power-turndown
 316
 317    -  service-power-reset
 318
 319    -  calculate-spanloss-base
 320
 321    -  calculate-spanloss-current
 322
 323 odl-transportpce-stubmodels
 324 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 325
 326    -  This feature provides function to be able to stub some of TransportPCE modules, pce and
 327       renderer (Stubpce and Stubrenderer).
 328       Stubs are used for development purposes and can be used for some of the functionnal tests.
 329
 330 Interfaces to external software
 331 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 332
 333 It defines the interfaces implemented to interconnect TransportPCE modules with other software in
 334 order to perform specific tasks
 335
 336 GNPy interface
 337 ^^^^^^^^^^^^^^
 338
 339 -  Request structure
 340
 341    -  topology : composed of list of elements and connections
 342    -  service : source, destination, explicit-route-objects, path-constraints
 343
 344 -  Response structure
 345
 346    -  path-properties/path-metric : OSNR-0.1nm, OSNR-bandwidth, SNR-0.1nm, SNR-bandwidth,
 347    -  path-properties/path-route-objects : composed of path elements
 348
 349
 350 Running transportPCE project
 351 ----------------------------
 352
 353 To use transportPCE controller, the first step is to connect the controller to optical nodes
 354 through the NETCONF connector.
 355
 356 .. note::
 357
 358     In the current version, only optical equipment compliant with open ROADM datamodels are managed
 359     by transportPCE.
 360
 361
 362 Connecting nodes
 363 ~~~~~~~~~~~~~~~~
 364
 365 To connect a node, use the following JSON RPC
 366
 367 **REST API** : *POST /restconf/config/network-topology:network-topology/topology/topology-netconf/node/<node-id>*
 368
 369 **Sample JSON Data**
 370
 371 .. code:: json
 372
 373     {
 374         "node": [
 375             {
 376                 "node-id": "<node-id>",
 377                 "netconf-node-topology:tcp-only": "false",
 378                 "netconf-node-topology:reconnect-on-changed-schema": "false",
 379                 "netconf-node-topology:host": "<node-ip-address>",
 380                 "netconf-node-topology:default-request-timeout-millis": "120000",
 381                 "netconf-node-topology:max-connection-attempts": "0",
 382                 "netconf-node-topology:sleep-factor": "1.5",
 383                 "netconf-node-topology:actor-response-wait-time": "5",
 384                 "netconf-node-topology:concurrent-rpc-limit": "0",
 385                 "netconf-node-topology:between-attempts-timeout-millis": "2000",
 386                 "netconf-node-topology:port": "<netconf-port>",
 387                 "netconf-node-topology:connection-timeout-millis": "20000",
 388                 "netconf-node-topology:username": "<node-username>",
 389                 "netconf-node-topology:password": "<node-password>",
 390                 "netconf-node-topology:keepalive-delay": "300"
 391             }
 392         ]
 393     }
 394
 395
 396 Then check that the netconf session has been correctly established between the controller and the
 397 node. the status of **netconf-node-topology:connection-status** must be **connected**
 398
 399 **REST API** : *GET /restconf/operational/network-topology:network-topology/topology/topology-netconf/node/<node-id>*
 400
 401
 402 Node configuration discovery
 403 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 404
 405 Once the controller is connected to the node, transportPCE application automatically launchs a
 406 discovery of the node configuration datastore and creates **Logical Connection Points** to any
 407 physical ports related to transmission. All *circuit-packs* inside the node configuration are
 408 analyzed.
 409
 410 Use the following JSON RPC to check that function internally named *portMapping*.
 411
 412 **REST API** : *GET /restconf/config/portmapping:network*
 413
 414 .. note::
 415
 416     In ``org-openroadm-device.yang``, four types of optical nodes can be managed:
 417         * rdm: ROADM device (optical switch)
 418         * xpdr: Xponder device (device that converts client to optical channel interface)
 419         * ila: in line amplifier (optical amplifier)
 420         * extplug: external pluggable (an optical pluggable that can be inserted in an external unit such as a router)
 421
 422     TransportPCE currently supports rdm and xpdr
 423
 424 Depending on the kind of open ROADM device connected, different kind of *Logical Connection Points*
 425 should appear, if the node configuration is not empty:
 426
 427 -  DEG<degree-number>-TTP-<port-direction>: created on the line port of a degree on a rdm equipment
 428 -  SRG<srg-number>-PP<port-number>: created on the client port of a srg on a rdm equipment
 429 -  XPDR<number>-CLIENT<port-number>: created on the client port of a xpdr equipment
 430 -  XPDR<number>-NETWORK<port-number>: created on the line port of a xpdr equipment
 431
 432     For further details on openROADM device models, see `openROADM MSA white paper <https://0201.nccdn.net/1_2/000/000/134/c50/Open-ROADM-MSA-release-2-Device-White-paper-v1-1.pdf>`__.
 433
 434 Optical Network topology
 435 ~~~~~~~~~~~~~~~~~~~~~~~~
 436
 437 Before creating an optical connectivity service, your topology must contain at least two xpdr
 438 devices connected to two different rdm devices. Normally, the *openroadm-topology* is automatically
 439 created by transportPCE. Nevertheless, depending on the configuration inside optical nodes, this
 440 topology can be partial. Check that link of type *ROADMtoROADM* exists between two adjacent rdm
 441 nodes.
 442
 443 **REST API** : *GET /restconf/config/ietf-network:network/openroadm-topology*
 444
 445 If it is not the case, you need to manually complement the topology with *ROADMtoROADM* link using
 446 the following REST RPC:
 447
 448
 449 **REST API** : *POST /restconf/operations/networkutils:init-roadm-nodes*
 450
 451 **Sample JSON Data**
 452
 453 .. code:: json
 454
 455     {
 456       "networkutils:input": {
 457         "networkutils:rdm-a-node": "<node-id-A>",
 458         "networkutils:deg-a-num": "<degree-A-number>",
 459         "networkutils:termination-point-a": "<Logical-Connection-Point>",
 460         "networkutils:rdm-z-node": "<node-id-Z>",
 461         "networkutils:deg-z-num": "<degree-Z-number>",
 462         "networkutils:termination-point-z": "<Logical-Connection-Point>"
 463       }
 464     }
 465
 466 *<Logical-Connection-Point> comes from the portMapping function*.
 467
 468 Unidirectional links between xpdr and rdm nodes must be created manually. To that end use the two
 469 following REST RPCs:
 470
 471 From xpdr to rdm:
 472 ^^^^^^^^^^^^^^^^^
 473
 474 **REST API** : *POST /restconf/operations/networkutils:init-xpdr-rdm-links*
 475
 476 **Sample JSON Data**
 477
 478 .. code:: json
 479
 480     {
 481       "networkutils:input": {
 482         "networkutils:links-input": {
 483           "networkutils:xpdr-node": "<xpdr-node-id>",
 484           "networkutils:xpdr-num": "1",
 485           "networkutils:network-num": "<xpdr-network-port-number>",
 486           "networkutils:rdm-node": "<rdm-node-id>",
 487           "networkutils:srg-num": "<srg-number>",
 488           "networkutils:termination-point-num": "<Logical-Connection-Point>"
 489         }
 490       }
 491     }
 492
 493 From rdm to xpdr:
 494 ^^^^^^^^^^^^^^^^^
 495
 496 **REST API** : *POST /restconf/operations/networkutils:init-rdm-xpdr-links*
 497
 498 **Sample JSON Data**
 499
 500 .. code:: json
 501
 502     {
 503       "networkutils:input": {
 504         "networkutils:links-input": {
 505           "networkutils:xpdr-node": "<xpdr-node-id>",
 506           "networkutils:xpdr-num": "1",
 507           "networkutils:network-num": "<xpdr-network-port-number>",
 508           "networkutils:rdm-node": "<rdm-node-id>",
 509           "networkutils:srg-num": "<srg-number>",
 510           "networkutils:termination-point-num": "<Logical-Connection-Point>"
 511         }
 512       }
 513     }
 514
 515 OTN topology
 516 ~~~~~~~~~~~~
 517
 518 Before creating an OTN service, your topology must contain at least two xpdr devices of MUXPDR or
 519 SWITCH type connected to two different rdm devices. To check that these xpdr are present in the
 520 OTN topology, use the following command on the REST API :
 521
 522 **REST API** : *GET /restconf/config/ietf-network:network/otn-topology*
 523
 524 An optical connectivity service shall have been created in a first setp. In Magnesium SR0, the OTN
 525 links are not automatically populated in the topology after the Och, OTU4 and ODU4 interfaces have
 526 been created on the two network ports of the xpdr. Thus the otn link must be posted manually through
 527 the REST API (APIDoc).
 528
 529 **REST API** : *POST /restconf/config/ietf-network:network/otn-topology/link*
 530 **REST API** : to complete
 531
 532
 533 Creating a service
 534 ~~~~~~~~~~~~~~~~~~
 535
 536 In Magnesium SR0, two different kind of services can be created with transportPCE using the Northbound
 537 REST API:
 538
 539 - 100GE services from client port to client port of two transponders (TPDR)
 540 - an OTU-4/ODU-4 service from network port to network port of two Xponders (MUXPDR/SWITCH)
 541
 542 For the creation of 1GE and 10GE services the user has to check using internal API the connectivity
 543 between nodes and the possibility to create a service through the path-computation-request rpc. The
 544 service creation is performed using internal otn-service-path rpc.
 545
 546 100GE service creation:
 547 ^^^^^^^^^^^^^^^^^^^^^^^
 548
 549 Use the following REST RPC to invoke *service handler* module in order to create a bidirectional
 550 end-to-end optical connectivity service between two xpdr over an optical network composed of rdm
 551 nodes.
 552
 553 **REST API** : *POST /restconf/operations/org-openroadm-service:service-create*
 554
 555 **Sample JSON Data**
 556
 557 .. code:: json
 558
 559     {
 560         "input": {
 561             "sdnc-request-header": {
 562                 "request-id": "request-1",
 563                 "rpc-action": "service-create",
 564                 "request-system-id": "appname"
 565             },
 566             "service-name": "test1",
 567             "common-id": "commonId",
 568             "connection-type": "service",
 569             "service-a-end": {
 570                 "service-rate": "100",
 571                 "node-id": "<xpdr-node-id>",
 572                 "service-format": "Ethernet",
 573                 "clli": "<ccli-name>",
 574                 "tx-direction": {
 575                     "port": {
 576                         "port-device-name": "<xpdr-client-port>",
 577                         "port-type": "fixed",
 578                         "port-name": "<xpdr-client-port-number>",
 579                         "port-rack": "000000.00",
 580                         "port-shelf": "Chassis#1"
 581                     },
 582                     "lgx": {
 583                         "lgx-device-name": "Some lgx-device-name",
 584                         "lgx-port-name": "Some lgx-port-name",
 585                         "lgx-port-rack": "000000.00",
 586                         "lgx-port-shelf": "00"
 587                     }
 588                 },
 589                 "rx-direction": {
 590                     "port": {
 591                         "port-device-name": "<xpdr-client-port>",
 592                         "port-type": "fixed",
 593                         "port-name": "<xpdr-client-port-number>",
 594                         "port-rack": "000000.00",
 595                         "port-shelf": "Chassis#1"
 596                     },
 597                     "lgx": {
 598                         "lgx-device-name": "Some lgx-device-name",
 599                         "lgx-port-name": "Some lgx-port-name",
 600                         "lgx-port-rack": "000000.00",
 601                         "lgx-port-shelf": "00"
 602                     }
 603                 },
 604                 "optic-type": "gray"
 605             },
 606             "service-z-end": {
 607                 "service-rate": "100",
 608                 "node-id": "<xpdr-node-id>",
 609                 "service-format": "Ethernet",
 610                 "clli": "<ccli-name>",
 611                 "tx-direction": {
 612                     "port": {
 613                         "port-device-name": "<xpdr-client-port>",
 614                         "port-type": "fixed",
 615                         "port-name": "<xpdr-client-port-number>",
 616                         "port-rack": "000000.00",
 617                         "port-shelf": "Chassis#1"
 618                     },
 619                     "lgx": {
 620                         "lgx-device-name": "Some lgx-device-name",
 621                         "lgx-port-name": "Some lgx-port-name",
 622                         "lgx-port-rack": "000000.00",
 623                         "lgx-port-shelf": "00"
 624                     }
 625                 },
 626                 "rx-direction": {
 627                     "port": {
 628                         "port-device-name": "<xpdr-client-port>",
 629                         "port-type": "fixed",
 630                         "port-name": "<xpdr-client-port-number>",
 631                         "port-rack": "000000.00",
 632                         "port-shelf": "Chassis#1"
 633                     },
 634                     "lgx": {
 635                         "lgx-device-name": "Some lgx-device-name",
 636                         "lgx-port-name": "Some lgx-port-name",
 637                         "lgx-port-rack": "000000.00",
 638                         "lgx-port-shelf": "00"
 639                     }
 640                 },
 641                 "optic-type": "gray"
 642             },
 643             "due-date": "yyyy-mm-ddT00:00:01Z",
 644             "operator-contact": "some-contact-info"
 645         }
 646     }
 647
 648 Most important parameters for this REST RPC are the identification of the two physical client ports
 649 on xpdr nodes.This RPC invokes the *PCE* module to compute a path over the *openroadm-topology* and
 650 then invokes *renderer* and *OLM* to implement the end-to-end path into the devices.
 651
 652 OTU4/ODU4 service creation :
 653 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 654
 655 Use the following REST RPC to invoke *service handler* module in order to create a bidirectional
 656 end-to-end optical connectivity service between two xpdr over an optical network composed of rdm
 657 nodes.
 658
 659 XXXXXXXXXXXXXXX (TO BE COMPLETED )XXXXXXXXXXXXXXXXX
 660
 661
 662 1GE/ODU0 and 10GE/ODU2e service creation :
 663 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 664
 665 Use the following REST RPC to invoke *PCE* module in order to check connectivity between xponder
 666 nodes and the availability of a supporting optical connectivity between the network-ports of the
 667 nodes.
 668
 669 **REST API** : to complete
 670
 671 After end-to-end optical connectivity between the two xpdr has been checked, use the otn-service-path
 672 rpc to invoke the *Renderer* and create the corresponding interfaces :
 673
 674 - 1GE and ODU0 interfaces for 1GE services
 675 - 10GE and ODU2e interfaces for 10GE services
 676
 677 The following example corresponds to the creation of a 10GE service
 678
 679 **REST API** : to complete
 680
 681 .. note::
 682     OTN links are not automatically populated in the topology after the ODU2e interfaces have
 683     been created on the two client ports of the xpdr. The otn link can be posted manually through
 684     the REST API (APIDoc).
 685
 686 .. note::
 687     With Magnesium SR0, the service-list corresponding to 1GE/10GE and OTU4/ODU4 services is not
 688     updated in the datastore after the interfaces have been created in the device.
 689
 690
 691 Deleting a service
 692 ~~~~~~~~~~~~~~~~~~
 693
 694 **REST API** : to complete according to what can be done with 100GE/OTU4/1GE/10GE services
 695
 696 Deleting a 100GE service
 697 ^^^^^^^^^^^^^^^^^^^^^^^^
 698
 699 Use the following REST RPC to invoke *service handler* module in order to delete a given optical
 700 connectivity service.
 701
 702 **REST API** : *POST /restconf/operations/org-openroadm-service:service-delete*
 703
 704 **Sample JSON Data**
 705
 706 .. code:: json
 707
 708     {
 709         "input": {
 710             "sdnc-request-header": {
 711                 "request-id": "request-1",
 712                 "rpc-action": "service-delete",
 713                 "request-system-id": "appname",
 714                 "notification-url": "http://localhost:8585/NotificationServer/notify"
 715             },
 716             "service-delete-req-info": {
 717                 "service-name": "test1",
 718                 "tail-retention": "no"
 719             }
 720         }
 721     }
 722
 723 Most important parameters for this REST RPC is the *service-name*.
 724
 725
 726 Help
 727 ----
 728
 729 -  `TransportPCE Wiki archive <https://wiki-archive.opendaylight.org/view/TransportPCE:Main>`__
 730
 731 -  TransportPCE Mailing List
 732    (`developer <https://lists.opendaylight.org/mailman/listinfo/transportpce-dev>`__)