Internet-Draft PCEP-LS for Optical Networks July 2024
Zhao, et al. Expires 8 January 2025 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-lee-pce-pcep-ls-optical-14
Published:
Intended Status:
Experimental
Expires:
Authors:
Y. Zhao
China Mobile
Y. Lee
Samsung
H. Zheng
Huawei Technologies Co., Ltd.
D. Ceccarelli
Cisco
W. Wang
Beijing University of Posts and Telecom
P. Park
KT
B. Y. Yoon
ETRI

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

Abstract

In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions.

An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 2 January 2025.

Table of Contents

1. Introduction

[I-D.ietf-pce-pcep-ls] 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 new PCEP message format.

Problems in the 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 operation.

The use of PCE can offload responsiblity for path computation and relieve the network nodes of the need to perform that function themselves, 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 [RFC9552].

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 an experimental extension to PCEP-LS for use in optical networks, and explains how encodings defined in [I-D.ietf-pce-pcep-ls] can be used in optical network contexts.

1.1. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Applicability

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

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.

3. Requirements for PCEP Extension

The key requirements associated with link-state and TE information distribution are identified for PCEP and listed in Section 4 of [I-D.ietf-pce-pcep-ls]. The new functions introduced to PCEP to support distribution of link-state (and TE) information are described in Section 5 of [I-D.ietf-pce-pcep-ls]. Details of PCEP messages and related Objects/TLVs are specified in Sections 8 and 9 of [I-D.ietf-pce-pcep-ls]. The key requirements and new functions specified in [I-D.ietf-pce-pcep-ls] are equally applicable to optical networks.

Besides the generic requirements specified in [I-D.ietf-pce-pcep-ls], optical-specific features also need to be considered. Optical networks are connection-based 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.

3.1. Reachable Source-Destination

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.

3.2. Optical Latency

It is the usual case that the PCC indicates the desired maximum latency when requesting a path computation. In optical networks the latency is a very sensitive parameter and there is often stricter requirement on latency. The PCE needs to determine which of the avilable OCh path meet the requested latency threshold.

A PCE may run an algorithm running to verify the performance of the computed path. During the 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.

4. PCEP-LS Extensions for Optical Networks

This section provides the additional PCEP-LS extensions necessary to support optical networks. All Objects/TLVs defined in [I-D.ietf-pce-pcep-ls] are applicable to optical networks.

4.1. Node Attributes TLV

The Node-Attributed TLV is defined in Section 9.3.9.1 of [I-D.ietf-pce-pcep-ls]. This TLV is applicable for LS Node Object-Type as defined in [I-D.ietf-pce-pcep-ls].

This TLV contains a number of Sub-TLVs. [I-D.ietf-pce-pcep-ls] defines that any Node-Attribute defined for BGP-LS [RFC9552] 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 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 [RFC7579].
TBD2
The Resource Block Information Sub-TLV is used as defined in [RFC7688].
TBD3
The Resource Block Accessibility Sub-TLV is used as defined in [RFC7688].
TBD4
The Resource Block Wavelength Constraint Sub-TLV is used as defined in [RFC7688].
TBD5
The Resource Block Pool State Sub-TLV is used as defined in [RFC7688].
TBD6
The Resource Block Shared Access Wavelength Availability Sub-TLV is used as defined in [RFC7688].

4.3. PCEP-LS for Optical Network Extension

This section provides additional PCEP-LS extension necessary to support the optical network parameters discussed in Section 3.1 and Section 3.2.

Collection of LS and TE information is necessary before the path computation processing can be done. The procedure can be divided into:

  1. Link state collection by receiving the corresponding topology information in periodically
  2. 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 [RFC4655].

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 [RFC7688]. 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 [RFC7688] needs to be taken into account in order to guarantee the reliability of optical path computation.

5. Security Considerations

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 [RFC5440] and [RFC8253]). The PCE implementation SHOULD provide mechanisms to prevent strains created by network flaps and amount of LS (and TE) information as defined in [I-D.ietf-pce-pcep-ls]. 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.

6. IANA Considerations

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

6.1. PCEP-LS Sub-TLV Type Indicators

[I-D.ietf-pce-pcep-ls] 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.


   +-----------+--------------------------------------------------
   |  Sub-TLV  | Meaning
   +-----------+--------------------------------------------------
   |    TBD1   | Connectivity Matrix
   |    TBD2   | Resource Block Information
   |    TBD3   | Resource Block Accessibility
   |    TBD4   | Resource Block Wavelength Constraint
   |    TBD5   | Resource Block Pool State
   |    TBD6   | Resource Block Shared Access Wavelength Available
   |    TBD7   | ISCD
   |    TBD8   | OTN-TDM SCSI
   |    TBD9   | WSON-LSC SCSI
   |    TBD10  | Flexi-grid SCSI
   |    TBD11  | Port Label Restriction

7. Acknowledgements

TBD

8. Contributor's Address


   Dhruv Dhody
   Email: dhruv.ietf@gmail.com

   Adrian Farrel
   Email: adran@olddog.co.uk

9. References

9.1. Normative References

[I-D.ietf-pce-pcep-ls]
Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A., and G. S. Mishra, "PCEP extensions for Distribution of Link-State and TE Information", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-ls-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-ls-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/info/rfc5440>.
[RFC7688]
Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, DOI 10.17487/RFC7688, , <https://www.rfc-editor.org/info/rfc7688>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[RFC4203]
Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, , <https://www.rfc-editor.org/info/rfc4203>.
[RFC4655]
Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, , <https://www.rfc-editor.org/info/rfc4655>.
[RFC6805]
King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, , <https://www.rfc-editor.org/info/rfc6805>.
[RFC7138]
Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, DOI 10.17487/RFC7138, , <https://www.rfc-editor.org/info/rfc7138>.
[RFC7579]
Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, , <https://www.rfc-editor.org/info/rfc7579>.
[RFC7580]
Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, "OSPF-TE Extensions for General Network Element Constraints", RFC 7580, DOI 10.17487/RFC7580, , <https://www.rfc-editor.org/info/rfc7580>.
[RFC8253]
Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, , <https://www.rfc-editor.org/info/rfc8253>.
[RFC8363]
Zhang, X., Zheng, H., Casellas, R., Gonzalez de Dios, O., and D. Ceccarelli, "GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 8363, DOI 10.17487/RFC8363, , <https://www.rfc-editor.org/info/rfc8363>.
[RFC8453]
Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, , <https://www.rfc-editor.org/info/rfc8453>.
[RFC8751]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, , <https://www.rfc-editor.org/info/rfc8751>.
[RFC9552]
Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, , <https://www.rfc-editor.org/info/rfc9552>.

Authors' Addresses

Yang Zhao
China Mobile
Young Lee
Samsung
Haomian Zheng
Huawei Technologies Co., Ltd.
Daniele Ceccarelli
Cisco
Wei Wang
Beijing University of Posts and Telecom
Peter Park
KT
Bin Yeong Yoon
ETRI