...
A service can be permanent or non permanent with due-date and end-date. In order to reserve resources before service activation, a temporary service can be created (with exact same characteristics) and activated until the due-date is reached for the service.
| Type of service | Priority | Agreed | Comments |
|---|---|---|---|
| Service | [orange] P1 [Telia]P1 | ||
| Temp-service | [orange] P2 [Telia]P2, if as comment | Orange: For time-constrainted services, it is suggested to have it in P1 without resource reservation in a first step. |
Service header
By default, all non-optional parameters have to be managed unless further notice. Optional parameters are reviewed for implementation. Reviewers are free to add other optional parameters for P1 implementation
| leaf | Priority | comment |
|---|---|---|
| sdnc-request-header/request-id | [Orange] P1 [Telia]P1 | |
| sdnc-request-header/system-id | [Orange] P1 [Telia]P1 | useful to determine which application has asked for the service |
| administrative-state | [Orange] P1 [Telia]P1 | |
| operational-state | [Orange] P1 [Telia]P1 |
Service a&z ends
| Leaf | Priority | Comment |
|---|---|---|
| node-id | [Orange] P1 [Telia]P1 | for compliancy with PCE spec, node-id spec is required (service-handler will not determine by itself the node on which implementig the service) |
| Tx & Rx / port / port-type | [Orange] P2 [Telia]P2 | Useful since it specifies the type of expected port |
| Tx & Rx / port / port-name | [Orange] P1 [Telia]P2 | Important and needed for the same reason as node-id (port-name is the info available from topology model). Other info do not seem crucial from service description point of view. Still useful to have it all in one place. Otherwise, a visit to device model is needed. |
| Tx & Rx / lgx / xxx | [Orange] P2 [Telia] - | Defines the link from the transponder line-side up to the port pair of the add-drop through a cross-connect. Since we already know from topology (network model) on which port-pair the transponder is connected, what is the added value to give the LGX here ? |
| Tx & Rx / tail / xxx | [Orange] P2 [Telia]P2 | Defines the link from the transponder client-side up to the client equipment. We could imagine a tail model (not available from openroadm) that potentially limits connectivity (through connectivity matrix) between client equipment and client port of transponder. However, I suggests starting without constraint from the tail segment and start service from the transponder client-port in a first step. |
| user-label | [Orange] P1 [Telia]P1 | Label for service endpoint, defined by the user |
Hard & Soft constraints
keep them all
...
fiber-span-srlg are listed in "other section". Therefore, this section focuses on nodes. Service model lists the set of devices being used by the service.
| Leaf | Priority | Comment |
|---|---|---|
| SRG-number | [Orange] P1 | mandatory info when node is edge ROADM |
| degree-number | [Orange] P1 | mandatory info when node is ROADM |
Other
| Leaf | Priority | Comment |
|---|---|---|
| due-date / end-date | [Orange] P1 [Telia]P2 | useful for BoD / calendaring use cases |
| customer/customer-contact/operator-contact | [Orange] P2 [Telia]P2 | |
| Latency | [Orange] P1 [Telia]P1 | |
| SRG numbers | [Orange] P1 [Telia]P1 |
Interface A - YANG API
Beyond the get-config / edit-config (or their equivalent in REST) on service model, following RPC are requested :
| RPC | Priority | Comment |
|---|---|---|
| service-create | [Orange] P1 | regarding inputs/outputs, cf service model |
| service-feasibility-check | [Orange] P1 | |
| equipment-notification | [Orange] ? | don't remember the purpose of this RPC... |
| service-delete | [Orange] P1 | |
| temp-service-create | [Orange] P3 | |
| temp-service-delete | [Orange] P3 | |
| service-roll | [Orange] P2 | |
| service-reconfigure | [Orange] P2 | |
| service-restoration | [Orange] P1 | |
| service-reversion | [Orange] P1 | |
| service-reroute | [Orange] P3 ? | don't see the big difference with service-roll |
| service-reroute-confirm | [Orange] P3 ? | don't see the big difference with service-roll |
| Notifications | Priority | Comment |
|---|---|---|
| service-rpc-result | what is the added valuue compared to the output of the rpc ? | |
| service-traffic-flow | [Orange] P1 | How can we change administrative state of services ? through "edit-config" (or some equivalent in REST) of the service ? |
| service-notification | [Orange] P1 | This Notification that a service has been added, modified or removed. |
Issues to be discussed :
- response-code type is string. This is not accurate enough for an API. Should be enum (invalid, created, pending,...) ?
- ack-final-indicator: shold be enum also
...
- D interface is addressed in service-handler section (https://wiki-archive.opendaylight.org/view/TransportPCE:service_requestServiceHandler/servicerequest).
- the device interface is the netconf Yang interface based on Openroadm 1.2 device model.
...