PCEP Extensions for Distribution of Link-State and TE Information for Optical Networks
draft-lee-pce-pcep-ls-optical-17

PCE Working Group                                                Y. Zhao
Internet-Draft                                              China Mobile
Intended status: Experimental                              D. Ceccarelli
Expires: 11 August 2026                                            Cisco
                                                                   X. Li
                                           Huawei Technologies Co., Ltd.
                                                              B. Y. Yoon
                                                                    ETRI
                                                               A. Farrel
                                                      Old Dog Consulting
                                                           February 2026

 PCEP Extensions for Distribution of Link-State and TE Information for
                            Optical Networks
                    draft-lee-pce-pcep-ls-optical-17

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.

   Link-State (LS) and Traffic Engineering (TE) Information can also be
   carried in Path Computation Element Communication Protocol (PCEP)
   using exensions known as PCEP-LS.  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 5 August 2026.

Zhao, et al.             Expires 11 August 2026                 [Page 1]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

Copyright Notice

   Copyright (c) 2026 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Experimental Scope  . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements for PCEP Extension . . . . . . . . . . . . . . .   5
     3.1.  Reachable Source-Destination  . . . . . . . . . . . . . .   5
     3.2.  Optical Latency . . . . . . . . . . . . . . . . . . . . .   6
   4.  PCEP-LS Extensions for Optical Networks . . . . . . . . . . .   6
     4.1.  Node Attributes TLV . . . . . . . . . . . . . . . . . . .   6
     4.2.  Link Attributes TLV . . . . . . . . . . . . . . . . . . .   7
     4.3.  PCEP-LS for Optical Network Extension . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Contributor's Address . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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.

Zhao, et al.             Expires 11 August 2026                 [Page 2]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

   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 extensions 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.
   Because [I-D.ietf-pce-pcep-ls] is presented as an Experimental
   document, the extensions defined here are also experimental.

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.

1.2.  Experimental Scope

   The procedures described in this document are experimental.  The
   experiment builds on the experiment described in
   [I-D.ietf-pce-pcep-ls] and is intended to enable research on the
   usage of PCEP to populate the Link-State and TE Information from a
   PCC to the PCE in an optical network.  For this purpose, this
   document extends the PCEP message, PCEP object, and PCEP TLVs defined

Zhao, et al.             Expires 11 August 2026                 [Page 3]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

   in [I-D.ietf-pce-pcep-ls] by defining 11 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
   [I-D.ietf-pce-pcep-ls] 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 [RFC5440].  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
   [I-D.ietf-pce-pcep-ls] 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.

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,

Zhao, et al.             Expires 11 August 2026                 [Page 4]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

      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
   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

Zhao, et al.             Expires 11 August 2026                 [Page 5]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

   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 Messages, Objects, and 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

Zhao, et al.             Expires 11 August 2026                 [Page 6]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

      [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].

   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].

Zhao, et al.             Expires 11 August 2026                 [Page 7]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

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

Zhao, et al.             Expires 11 August 2026                 [Page 8]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

   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

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

8.  Contributor's Address

Zhao, et al.             Expires 11 August 2026                 [Page 9]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

      Dhruv Dhody
      Email: dhruv.ietf@gmail.com

      Haomian Zheng
      Email: zhenghaomian@huawei.com

      Wei Wang
      Email: weiw@bupt.edu.cn

      Peter Park
      Email: peter.park@kt.com

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-04, 14 October
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              pce-pcep-ls-04>.

   [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>.

   [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

Zhao, et al.             Expires 11 August 2026                [Page 10]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

   [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>.

   [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>.

Zhao, et al.             Expires 11 August 2026                [Page 11]
Internet-Draft        PCEP-LS for Optical Networks         February 2026

   [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

   Daniele Ceccarelli
   Cisco
   Email: daniele.ietf@gmail.com

   Xiao Li
   Huawei Technologies Co., Ltd.
   Email: lixiao33@huawei.com

   Bin Yeong Yoon
   ETRI
   Email: byyun@etri.re.kr

   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk

Zhao, et al.             Expires 11 August 2026                [Page 12]