...
- Agreed - A "Yes" in this columns means that the requirement is agreed among the contributors and therefore is a valid requirement for the project.
- Comments - Comments from TransportPCE contributors
| Id | Slogan | Description | Reference | Priority | Agreed | Comments |
|---|---|---|---|---|---|---|
| 1 | Architecture and Interfaces | |||||
| 1.1 | RESTconf API | The PCE shall use a RESTconf API to provide path computation services to its clients | not agreed | Discussion ongoing. Orange: requirement becomes probably irrelevant if we talk about interface with service handler since both function will be colocated. PCEP or another API with similar data model is probably fine. | ||
| 1.2 | Capability to modify path feasibility verification algorithm | Path feasibility function shall be easily accessible for modification | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 | R1 | Keeping the topology model unchanged, an operator may want to improve the path feasibility algorithm with its own one for typically longer reach calculations [Coriant]or to include validation of equipment switching capabilities/restrictions. Therefore, this function must be easibily identified and modified if need be. Discussion ongoing | |
| 1.3 | Statefulness | PCE must be stateful. This means that it, besides topology, stores all the information related to the existing paths and is capable to use them for path computation, as needed | draft-ietf-pce-stateful-pce-15 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | Discussion ongoing |
| 1.4 | Path information management | PCE stores and manages information about the paths deployed in the network, allowing to add, modify and remove that information | draft-ietf-pce-stateful-pce-15 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 | R1 | Please note that PCE should NOT store path information and mark network resources as in use at the moment of successful path computation. The client application shall be instead in charge of deploying the path and eventually update the PCE |
| 1.5 | path identification | PCE must manage unique identifier associated to each path. This id must be assigned by the client, is under client’s responsibility and must remain constant across all the life of the path | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P2 | R1 | ||
| 1.6 | Multi-layer path computation | PCE must support multi-layer (and multi-technology) path computation. This means that a multi-layer/multi-technology network may be represented in its topology database, and path computation can return multi-layer/multi-technology paths, that is paths whose route includes hops from different layers/technologies | [E///]P1 [Telia]P1 [Orange]P2 [Coriant]P1 [Nokia] P2 | R2 | Orange: P2 simply because OTN will come with release 2 of openroadm and first release will probably focus on WDM but will have to be multi-layer in the end for sure. | |
| 1.6.1 | DWDM switching support | PCE must manage DWDM technology | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | ||
| 1.6.2 | OTN switching support | PCE must manage OTN technology | [E///]P1 [Telia]? [Orange]P2 [Coriant]P1 [Nokia] P2 | R2 | Orange: for the reason above. OTN in PE to come not earlier than openroadm | |
| 1.6.3 | Mixed-technology networks : OTN/DWDM | OTN over photonic layering must be supported | [E///]P1 [Telia]P1 [Orange]P2 [Coriant]P1 [Nokia] P2 | R2 | Discussion ongoing | |
| 1.7 | Topology database | PCE get updates about the topology from the topology DB of the controller [Coriant], including nodes, ports and links availability | [E///]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | Discussion ongoing | |
| 1.8 | MD-SAL API | The PCE shall be provided as an ODL bundle, supporting MD-SAL API | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 | R1 | Orange: OK with ODL bundle. Not sure about MD-SAL API. PCE resides in network services, not in MD-SAL, correct? And REST API is important for Service handler. | |
| 1.9 | PCE tracing and debugging | The PCE shall provide a tracing facility where it shall be possible to have details about the path computation operations | [E///]P2 [Telia]P3 [Orange]P1 [Nokia] P3 | R2 | Orange: useful to understand PCE behavior | |
| 1.10 | PCE monitoring and performance measurements | The PCE supports measurements of performances, keeping track of the number of requests, minimum, maximum and medium time for the path computation operations | RFC 5886 | [E///]P2 [Telia]P2 [Orange]P3 [Coriant]P3 [Nokia] P3 | R2 | |
| 2 | Request Parameters | |||||
| 2.1 | Single path path computation | PCE must support the computation of a single path | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | |
| 2.2 | Single path optimization | PCE must support the optimization of a single path. The optimization shall compute an alternative path with a better metric allowing the reuse of resources allocated to the original path | RFC 5440 | [E///]P2 [Telia]P2 [Orange]P2 [Coriant]P2 [Nokia] P3 | R2 | |
| 2.3 | Multiple path path computation for diversity | PCE must support the computation (or optimization) of a bundle of paths, according to the wanted diversity, meaning that PCE shall be capable to compute multiple paths in diversity each other. Diversity attributes are defined as Node, Link, or SRLG. | RFC 5440 | [E///]P1 [Telia]P2 [Orange]P1 [Coriant]P2 [Nokia] P1 | R1 | Orange: SRG (add-drop group) should also be included in the list of diversity attributes |
| 2.4 | Multiple path path computation for global optimization | PCE must support the computation (or optimization) of a bundle of paths, according to objective functions | RFC 5441 RFC 5557 | [E///]P3 [Telia]P3 [Orange]P3 [Coriant]P3 [Nokia] P3 | R3 | |
| 2.5 | Multiple path path computation for computing multiple paths assigning separate resources | PCE must support the computation of multiple paths without any cross-path constraint. In this case the multiple paths shall be assigned different non-overlapping resources | RFC 5440 | [E///]P2 [Telia]P3 [Orange]P3 [Coriant]P3 [Nokia] P3 | R3 | |
| 2.6 | Constrained path computation | PCE must support the specification of multiple optional parameters to specify constraints for the path computation (or optimization). A flag must be included for each one of these parameters in order to specify whether the PCE will return failure or not when the relevant constraint cannot be satisfied. | RFC 5440 | [E///]P1 [Telia]P2 [Orange]P1 [Coriant]P2 | R1 | Discussion ongoing |
| 2.7 | Path computation result | PCE must be capable to return the result of the path computation (success, failure) | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | |
| 2.8 | Path computation result : unsatisfied constraints | In case not all the requested constraints can be satisfied, the PCE must report the unsatisfied ones | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P2 [Nokia] P3 | R1 | [Coriant] It would be useful also to be able to specify soft and hard constraints and support the auto relaxation of soft constraints [E///] See requirement 2.6 |
| 2.9 | Bidirectional path computation | PCE must support the computation (or optimization) of point-to-point bidirectional paths | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | |
| 2.10 | Unidirectional path computation | PCE must support the computation (or optimization) of point-to-point unidirectional paths | RFC 5440 | [E///]P3 [Telia]P3 [Orange]P3 [Coriant]P3 [Nokia] P3 | R3 | Discussion ongoing |
| 2.11 | End points | The request shall include the end points of the path to be computed. End-point information must include at least the specification of the node or interface of the end-point and optionally (depending on the technology of the network) unnumbered interface id and Label | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | Discussion ongoing |
| 2.11.1 | End points | The request shall include the clli without node / port information. It is up to the PCE to select the most appropriate resource at the edges.l | RFC 5440 | [Orange]P2 [Coriant]P1 [E///]P2 | R2 | Comes from discussion 2.11. Discussion ongoing |
| 2.12 | Bandwidth/Type of signal specification | PCE must allow specifying the bandwidth of the requested path.Bandwidth specification shall include the type of the signal (according to the technology type) | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 | R1 | Discussion ongoing |
| 2.13 | Metrics for path computation | PCE must allow specifying the metric to be optimized when performing path computation. Possible metrics are at least IGP metric, TE metric, Hop count, and propagation delay (latency). If no metric is specified, the IGP metric (administrative cost) shall be used by default. Additional constraints due to technology (e.g. optical path feasibility) may be implicitly considered by the PCE as needed | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P1 [Nokia] P1 | R1 | Discussion ongoing |
| 2.14 | Metric bound constraint | PCE must allow specifying the upper bound for a given metric (possibly a metric different from the one to be optimized). If no path with the given metric under the upper bound is found, the request must fail | RFC 5440 | [E///]P1 [Telia]P2 [Orange]P2 [Coriant]P2 [Nokia] P2 | R1 | |
| 2.15 | Computed metric returned as result | PCE must allow specifying the metrics to be returned for the computed path, as successful. In that case the relevant metrics of the computed path shall be included in the response. No metric is returned if not requested | RFC 5440 | [E///]P2 [Telia]P2 [Orange]P1 [Coriant]P2 [Nokia] P3 | R2 | |
| 2.16 | Use of local protected links in path computation | PCE must allow specifying whether the path computation shall use locally protected links | RFC 5440 | [E///]P3 [Telia]P2 [Orange]P2 [Coriant]P2 [Nokia] P3 | R2 | [Coriant] I think it is more than just locally protected links since it possible to use SNC type protection as end-to-end resiliency mechanism. Ideally, the different protection mechanisms available on the optical layer (DWDM/OTN) should be available and selected based on a requested parameter |
| 2.17 | Affinities | PCE allows specifying the affinities to be included or excluded by the path computation. Affinities (aka administrative colors) are coded as 32 bit masks. They are attributes of TE-links. It must be possible to specify the following conditions; Include-any: links are included if any of the bits set in the mask are set also in the relevant link affinities; Exclude-any: links are excluded if any of the bits set in the mask are set also in the relevant link affinities; Exclude-all: links are excluded if all the bits set in the mask are set also in the relevant link affinities | RFC 5440 | [E///]P1 [Telia]P1 [Orange]P1 [Nokia] P2 | R1 | Discussion ongoing |
| 2.18 | Include resources specification | PCE allows specifying the IRO, which is the list of network resources (nodes, links, interfaces) to be included in the computed path. The resulting path must pass through the elements in the IRO list according to their order. | RFC 5440 | [E///]P2 [Telia]P2 [Orange]P1 [Coriant]P2 [Nokia] P2 | R2 | |
| 2.19 | Exclude resources specification | PCE must allow specifying the XRO, which is the list of network resources (nodes, links, interfaces, SRLGs), to be excluded by the computed path. The resulting path must not pass through the elements in the list. | RFC 5521 | [E///]P1 [Telia]P1 [Orange]P1 [Coriant]P2 [Nokia] P1 | R1 | |
| 2.20 | Path profiles | PCE supports path profiles, that is specifications of set of request parameters and policies bundled all together and associated to a unique identifier. Mentioning that identifier in a request allows getting all the relevant parameters without the need to specify them explicitly | draft-alvarez-pce-path-profiles-04 | [E///]P3 [Telia]P3 [Orange]P3 [Coriant]P3 [Nokia] P3 | R3 | This is an expired draft, an alternative way to embed policies in a request is available in the recent draft-sivabalan-pce-policy-identifier-00 |
| 2.21 | Policy management | PCE supports the management of policies, that is directions/parameters affecting its behavior. | RFC 3060 RFC 3460 RFC 5394 | [E///]P2 [Telia]P2 [Orange]P2 [Coriant]P2 [Nokia] P3 | R2 | E.g. policies to set the priority among multiple constraints in the same request, to affect how forwarding adjacencies are created or removed, to configure traffic engineering parameters, to set strategies for optical resource allocation, and more |
| 2.21.1 | Policy interface | Policies are objects which can be created, read, updated and deleted. Multiple policies can be associated to a path request (inside a path profile) | RFC 3060 RFC 3460 RFC 5394 | [E///]P2 [Telia]P2 [Orange]P2 [Coriant]P2 [Nokia] P3 | R2 | |
| 2.22 | Time constraint management | For BoD or calendaring applications, it is of interest of specifying time boundaries and frequency for path. | P2 [Telia]P3 [Coriant]P2 [E///]P3 [Nokia] P3 | R2 | Orange: suggest to move this requirement to service handler specification (PCE in charge of calculating a path according to existing resources at the time of path request) | |
| 2.23 | Path computation w/wo path implementation | It is of interest to sollicit the PCE for path computation without network implementation. Conversely, it is important to be able to specify the CPE that the path must be implemented immediately | [Telia]? [Coriant]P1 [Nokia] P1 | R1 | Orange: suggest to move this requirement to service handler specification (PCE in charge of calculating a path and shall not care if it is further implemented or not (is told later not by a notification from service inventory) [E///]Our view is that PCE should be in charge of path computation task only. What is named "PCE" in a lot of documents is actually a controller. According to the architecture discussed so far, we separate the role of path computation from the one of actual deployment of the traffic in the network. Therefore path implementation option should not be supported by the PCE (instead a command to communicate to the PCE the deployment of a path in the network should be foreseen). | |
| 2.24 | Path computation wo resource reservation | It is of interest to be able to verify if a path is feasible but compute it in stateless way, without resource reservation. | [Coriant]P2 [Nokia] P3 | R2 | Typical use case is testing path feasibility across multiple domains or analyse different path options [E///] See comment on requirement 1.4. In our view this should be the normal PCE behavior. | |
| 2.25 | Path computation with control of the used layers for reuse/creation | It is of interest to be able to control if multi layer path computation should consider creation of lower layer server paths or only reuse already existing server paths. | [Coriant]P2 [E///]P2 [Nokia] P2 [Orange] P2 | R2 | Typical use case is be able to request paths that do not require creation of optical infrastructure (new optical channels) and therefore able to be implemented instantly. [E///] Not directly supported by PCEP, we have implemented it as a policy. Agreed for P2 as it will become useful when we'll have multiple layers. | |
| 2.26 | Vendor-dependent wavelength-map | PCE shal be able to get the wavelength-map according to the vendor/node types (correspondance between channel-number and central frequency/channel width) | RFC6205/ 694.1 | [Orange]P1 | Wavelength-map is not standardized among vendors and PCE needs to get the knowledge of wavelength map that is available in device model. |