PCEP Extensions for Distribution of Link-State and TE Information for Optical Networks

describes an experimental mechanism by which Link State (LS) and Traffic Engineering (TE) information can be collected from packet networks and shared with a Path Computation Element (PCE) through the Path Computation Element Communication Protocol (PCEP). This approach is called PCEP-LS and uses a dedicated PCEP message format. Problems in optical networks (such as Optical Transport Networks (OTN)) are becoming more significant owing to the growth in scale of such networks. Such growth is also challenging the requirement for memory/storage on each network element because it is important to retain information about the whole network in order to successfully achieve dynamic network operations. The use of a PCE can offload responsiblity for path computation and relieve the network nodes of the need to perform that function themselves and, therefore, the need to retain full network state information. But a PCE needs to have access to a full set of information about the network for which it computes paths. PCEP-LS provides a mechanism to gather that information from packet networks that is an alternative to passive participation in the link state routing protocol or the use of BGP-LS . In an optical network, more information is needed in order to successfully determine optimal end-to-end paths across the network than is provided in the topology and bandwidth parameters shared in PCEP-LS. Not all optical networks run an IGP to exchange reachability and TE information: in some deployments, this information is known a priori or is collected through the management plane. Further, the use of BGP-LS is not a good proposition for optical equipment that already implements PCEP, does not usually include support for BGP, and has constrained protocol processing capablities. This document describes extensions to PCEP-LS for use in optical networks, and explains how encodings defined in can be used in optical network contexts. Because is presented as an Experimental document, the extensions defined here are also experimental.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The procedures described in this document are experimental. The experiment builds on the experiment described in and is intended to enable research on the usage of PCEP to populate the Link-State and TE Information from a Path Computation Client (PCC) to the PCE in an optical network. For this purpose, this document extends the PCEP message, PCEP object, and PCEP TLVs defined in by defining new PCEP TLVs specifically for carrying information about optical networks. This experiment is an extension of the PCEP-LS experiment. Therefore, interaction with implementations that do not support the PCEP-LS extensions will be exactly as defined in Nodes that participate in the PCEP-LS experiment, but that do not support the TLVs defined in this document will not understand those TLVs and so will ignore them as specified in . Thus, nodes that understand PCEP-LS but do not participate in this experiment will not be harmed, but including them in the network will reduce the value of this experiment. The experiment will end three years after the RFC is published. Note, however, that the experiment described in is planned to last three years after that document is published as an RFC. This may mean that this experiment is curtailed if the core PCEP-LS experiment ends and is declared a failure. In consequence, it is very important that the observations of this experiment be fed into the results of the PCEP-LS experiment. At the conclusion of this experiment, the authors will attempt to determine how widely this specification has been implemented and deployed. When the results of implementation and deployment are available and posted as an Internet-Draft, and assuming that the results are positive, this document (or part thereof) will be updated and refined, and could be moved from Experimental to Standards Track.

There are three main applicabilities of the mechanism described in this document:

Case 1: There is an IGP running in the optical network, but there is a need to collect LS and TE resource information at a PCE from individual or specific optical nodes more frequently or more rapidly than the IGP allows.
- A PCE may receive full information or an incremental update (as opposed to the entire TE information for the node/link).
Case 2: There is no IGP running in the optical network and there is a need to collect link-state and TE resource information from the optical nodes for use by the PCE.
Case 3: There is a need to share abstract optical link-state and TE information from a child PCE to a parent PCE in a hierarchical PCE (H-PCE) system per and . Alternatively, this requirement may exist between a Physical Network Controller (PNC) and a Multi-Domain Service Coordinator (MDSC) in the Abstraction and Control of TE Networks (ACTN) architecture .

Note: The applicability for Case 3 may arise as a consequence of Cases 1 and 2. When TE information changes occur in the optical network, this may also affect abstracted TE information and thus needs to be updated to the parent PCE/MSDC from each child PCE/PNC.

The key requirements associated with link-state and TE information distribution are identified for PCEP and listed in Section 4 of . The new functions introduced to PCEP to support distribution of link-state (and TE) information are described in Section 5 of . Details of PCEP messages and related Objects/TLVs are specified in Sections 8 and 9 of . The key requirements and new functions specified in are equally applicable to optical networks. Besides the generic requirements specified in , optical-specific features also need to be considered. Optical networks are connection-oriented so there are specific parameters, such as the reachability table, optical latency, wavelength consistency, etc., that need to be included during the collection of topology information. Without these additional parameters, path computation may be inaccurate or produce paths that cannot be realised in the deployment. Therefore this information needs to be included in the PCEP-LS messages. The procedure for using the optical parameters is described in following sections.

The reachable source-destination node pair indicates that there is an optical channel (OCh) path between two nodes. The reachability is restricted by impairment, wavelength consistency, and so on. Knowledge of the reachable source-destination node pair and the impairment restrictions is necessary at the PCE to ensure that the path computed between source and destination nodes is feasible. In this scenario, the PCE is responsible for determining the set of OCh paths available to support connections between source and destination node. Moreover, if a set of optical wavelengths is indicated in the path computation request, the PCE also determines whether a wavelength from the set of preselected optical wavelengths is available for the connection between source and destination. To enable the PCE to complete these functions, the reachable relationship and optical multiplex section (OMS) link information need to be reported to the PCE. Once the PCE detects that a wavelength is available, the corresponding OMS link is marked in the PCE's database as a candidate link in the optical network, which can then be used for path computation in the future. Moreover, in a hierarchical PCE architecture, all of this information needs to be reported from child PCE to parent PCE, which acts as a service coordinator.

It is the usual case that the PCC indicates the desired maximum latency when requesting a path computation. In optical networks, latency is a very sensitive parameter and there is often a stricter requirement on end-to-end path latency. The PCE needs to determine which of the avilable OCh paths meet the requested latency threshold. A PCE may run an algorithm to verify the performance of the computed path. During the path computation, the delay factor may be converted into a kind of link weight. After the algorithm provides a set of candidate paths between the source and destination nodes, the PCE selects the best path by computing the total path propagation delay.

This section provides the additional PCEP-LS extensions necessary to support optical networks. All Messages, Objects, and TLVs defined in are applicable to optical networks.

The Node-Attributed TLV is defined in Section 9.3.9.1 of . This TLV is applicable for LS Node Object-Type as defined in . This TLV contains a number of Sub-TLVs. defines that any Node-Attribute defined for BGP-LS can be used as a Sub-TLV of the PCEP Node-Attribute TLV. There is no support for optical networks defined for BGP-LS, so the additional Node-Attribute Sub-TLVs shown below are defined in this document for use in PCEP-LS for optical networks.

TBD1: The Connectivity Matrix Sub-TLV is used as defined in .
TBD2: The Resource Block Information Sub-TLV is used as defined in .
TBD3: The Resource Block Accessibility Sub-TLV is used as defined in .
TBD4: The Resource Block Wavelength Constraint Sub-TLV is used as defined in .
TBD5: The Resource Block Pool State Sub-TLV is used as defined in .
TBD6: The Resource Block Shared Access Wavelength Availability Sub-TLV is used as defined in .

The Link-Attributes TLV is defined in Section 9.3.9.2 of . This TLV is applicable for the LS Link Object-Type as defined in . This TLV contains a number of Sub-TLVs. defines that any Node-Attribute defined for BGP-LS can be used as a Sub-TLV of the PCEP Link-Attribute TLV. There is no support for optical networks defined for BGP-LS, so the additional Link-Attribute Sub-TLVs shown below are defined in this document for use in PCEP-LS for optical networks.

TBD7: The ISCD Sub-TLV is used to describe the Interface Switching Capability Descriptor as defined in .
TBD8: The OTN-TDM SCSI Sub-TLV is used to describe the Optical Transport Network Time Division Multiplexing Switching Capability Specific Information as defined in and .
TBD9: The WSON-LSC SCSI Sub-TLV is used to describe the Wavelength Switched Optical Network Lambda Switch Capable Switching Capability Specific Information as defined in and .
TBD10: The Flexi-grid SCSI Sub-TLV is used to describe the Flexi-grid Switching Capability Specific Information as defined in .
TBD11: The Port Label Restriction Sub-TLV is used as defined in , , and .

This section provides additional PCEP-LS extensions necessary to support the optical network parameters discussed in and . Collection of LS and TE information is necessary before the path computation processing can be done. The procedure can be divided into:

Link state collection by periodically receiving the corresponding topology information.
Path computation on the PCE, triggered by receiving a path computation request message from a PCC, and completed by transmitting a path computation reply with the path computation result, per .

For OTN networks, maximum bandwidth available may be aggregated across all optical data unit (ODU) switching levels (i.e., ODUj/k) or considered per ODU 0/1/2/3 switching level. For Wavelength Switched Optical Networks (WSON), Routing and Wavelength Assignment (RWA) information collected from Network Elements would be utilized to compute optical paths. The list of information collected can be found in . More specifically, the maximum bandwidth available may be per lambda/frequency (OCh) or aggregated across all lambdas/frequencies. Per OCh-level abstraction gives more detailed data to the P-PCE at the expense of more information processing. Either the OCh-level or the aggregated-level abstraction in the RWA constraint (i.e., wavelength continuity) needs to be taken into account by the PCE during path computation. Resource Block Accessibility (i.e., wavelength conversion information) in needs to be taken into account in order to guarantee the reliability of optical path computation.

This document extends PCEP-LS information distribution in optical networks by including a set of Sub-TLVs to be carried in existing TLVs of existing messages. Procedures and protocol extensions defined in this document do not affect the overall PCEP security model (see and ). The PCE implementation SHOULD provide mechanisms to prevent strain on the network and operational tools caused by network flaps and the amount of LS (and TE) information: these concerns are discussed in . Thus, any mechanism used for securing the transmission of other PCEP message SHOULD be applied here as well. As a general precaution, it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions belonging to the same administrative authority.

contains detailed operational considerations for the use of PCEP-LS in a packet network. Those considerations apply equally to the use of PCEP-LS in an optical network. In particular, the manageability considerations listed in [RFC5440] continue to apply to these PCEP extensions. Further specific considerations for the use of PCEP-LS in optical networks are given below

observes that a PCE or PCC implementation MUST allow configuring the PCEP-LS capabilities described in that document. It is RECOMMENDED that implementations, especially PCE implementations make packet and optical PCEP-LS support separately configurable as implementations may support both packet and optical forwarding.

As noted in , the use of PCP-LS may cause the movement of large amounts of data between PCCs and a PCE. This could congest the network around the PCE and might cause overload at the PCE itself. Although optical networks are typically smaller than packet networks (fewer links and nodes), it is possible that the reported information about optical channels represents a large amount of data. Given that processing elements in optical networks may be of low capacity and that management channels might be low bandwidth, care must be taken to protect these parts of the network from becoming overloaded. Appropriate protection includes setting reporting thresholds so that changes are only notified after large changes in status, avoiding updates of data when there has been no change, and pacing updates to achieve a regular flow rather than bursts. Initially, these considerations should be enabled in implementations. Then operators can preform appropriate configuration within their networks.

This document requests IANA actions to allocate code points for the protocol elements defined in this document.

requests IANA to create a registry of "PCEP-LS Sub-TLV Type Indicators". IANA is requested to make the following allocations from this registry using the range 1 to 255.

Thanks to Young Lee for a lot of the drive behind this work.