PCEP Extension for Distribution of Link-State and TE Information for Optical Networks
draft-lee-pce-pcep-ls-optical-14
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yang Zhao , Young Lee , Haomian Zheng , Daniele Ceccarelli , Wei Wang , Peter Choongul Park , Bin Yeong Yoon | ||
| Last updated | 2024-07-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lee-pce-pcep-ls-optical-14
PCE Working Group Y. Zhao
Internet-Draft China Mobile
Intended status: Experimental Y. Lee
Expires: 8 January 2025 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
July 2024
PCEP Extension for Distribution of Link-State and TE Information for
Optical Networks
draft-lee-pce-pcep-ls-optical-14
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/.
Zhao, et al. Expires 8 January 2025 [Page 1]
Internet-Draft PCEP-LS for Optical Networks July 2024
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.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for PCEP Extension . . . . . . . . . . . . . . . 4
3.1. Reachable Source-Destination . . . . . . . . . . . . . . 5
3.2. Optical Latency . . . . . . . . . . . . . . . . . . . . . 5
4. PCEP-LS Extensions for Optical Networks . . . . . . . . . . . 6
4.1. Node Attributes TLV . . . . . . . . . . . . . . . . . . . 6
4.2. Link Attributes TLV . . . . . . . . . . . . . . . . . . . 6
4.3. PCEP-LS for Optical Network Extension . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Contributor's Address . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Zhao, et al. Expires 8 January 2025 [Page 2]
Internet-Draft PCEP-LS for Optical Networks July 2024
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.
Zhao, et al. Expires 8 January 2025 [Page 3]
Internet-Draft PCEP-LS for Optical Networks July 2024
2. Applicability
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 of more
rapidly than the IGP allows.
- A PCE may receive full information or an incremental update (as
opposed to the entire TE information of 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 [RFC6805] and [RFC8751]. 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
[RFC8453].
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
Zhao, et al. Expires 8 January 2025 [Page 4]
Internet-Draft PCEP-LS for Optical Networks July 2024
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.
Zhao, et al. Expires 8 January 2025 [Page 5]
Internet-Draft PCEP-LS for Optical Networks July 2024
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.2. Link Attributes TLV
The Link-Attributes TLV is defined in Section 9.3.9.2 of
[I-D.ietf-pce-pcep-ls]. This TLV is applicable for the LS Link
Object-Type as defined in [I-D.ietf-pce-pcep-ls].
Zhao, et al. Expires 8 January 2025 [Page 6]
Internet-Draft PCEP-LS for Optical Networks July 2024
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 Link-Attribute TLV. There is no
support for optical networks defined for BGP-LS, so the 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 [RFC4203].
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 [RFC4203] and [RFC7138].
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 [RFC4203] and
[RFC7688].
TBD10 The Flexi-grid SCSI Sub-TLV is used to describe the Flexi-grid
Switching Capability Specific Information as defined in [RFC8363].
TBD11 The Port Label Restriction Sub-TLV is used as defined in
[RFC7579], [RFC7580], and [RFC8363].
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.
Zhao, et al. Expires 8 January 2025 [Page 7]
Internet-Draft PCEP-LS for Optical Networks July 2024
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.
Zhao, et al. Expires 8 January 2025 [Page 8]
Internet-Draft PCEP-LS for Optical Networks July 2024
+-----------+--------------------------------------------------
| 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, 16 May 2024,
<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, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Zhao, et al. Expires 8 January 2025 [Page 9]
Internet-Draft PCEP-LS for Optical Networks July 2024
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<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, November 2015,
<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,
May 2017, <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, October 2005,
<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, August 2006,
<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, November 2012,
<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, March 2014,
<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, June 2015,
<https://www.rfc-editor.org/info/rfc7579>.
Zhao, et al. Expires 8 January 2025 [Page 10]
Internet-Draft PCEP-LS for Optical Networks July 2024
[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, June 2015,
<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, October 2017,
<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, May 2018,
<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, August 2018,
<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, March 2020,
<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, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Authors' Addresses
Yang Zhao
China Mobile
Email: zhaoyangyjy@chinamobile.com
Young Lee
Samsung
Email: younglee.tx@gmail.com
Haomian Zheng
Huawei Technologies Co., Ltd.
Email: zhenghaomian@huawei.com
Zhao, et al. Expires 8 January 2025 [Page 11]
Internet-Draft PCEP-LS for Optical Networks July 2024
Daniele Ceccarelli
Cisco
Email: dceccare@cisco.com
Wei Wang
Beijing University of Posts and Telecom
Email: weiw@bupt.edu.cn
Peter Park
KT
Email: peter.park@kt.com
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr
Zhao, et al. Expires 8 January 2025 [Page 12]