<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" ipr="trust200902" submissionType="IETF" docName="draft-ietf-teas-gmpls-controller-inter-work-17" number="9730" obsoletes="" updates="" tocInclude="true" symRefs="true" sortRefs="true" xml:lang="en" prepTime="2025-03-04T11:36:29" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-controller-inter-work-17" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9730" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="GMPLS and Controller Interwork">Interworking of GMPLS Control and Centralized Controller Systems</title>
    <seriesInfo name="RFC" value="9730" stream="IETF"/>
    <author initials="H." surname="Zheng" fullname="Haomian Zheng">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>
    <author initials="Y." surname="Lin" fullname="Yi Lin">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <email>yi.lin@huawei.com</email>
      </address>
    </author>
    <author initials="Y." surname="Zhao" fullname="Yang Zhao">
      <organization showOnFrontPage="true">China Mobile</organization>
      <address>
        <email>zhaoyangyjy@chinamobile.com</email>
      </address>
    </author>
    <author initials="Y." surname="Xu" fullname="Yunbin Xu">
      <organization showOnFrontPage="true">CAICT</organization>
      <address>
        <email>xuyunbin@caict.ac.cn</email>
      </address>
    </author>
    <author initials="D." surname="Beller" fullname="Dieter Beller">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <email>Dieter.Beller@nokia.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>teas</workgroup>
    <keyword>architecture</keyword>
    <keyword>ACTN</keyword>
    <keyword>control plane</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
Generalized Multiprotocol Label Switching (GMPLS) control allows
each network element (NE) to perform local resource discovery,
routing, and signaling in a distributed manner.</t>
      <t indent="0" pn="section-abstract-2">
The advancement of software-defined transport networking technology
enables a group of NEs to be managed through centralized controller
hierarchies. This helps to tackle challenges arising from multiple
domains, vendors, and technologies. An example of such a centralized
architecture is the Abstraction and Control of Traffic-Engineered
Networks (ACTN) controller hierarchy, as described in RFC 8453.</t>
      <t indent="0" pn="section-abstract-3">
Both the distributed and centralized control planes have their
respective advantages and should complement each other in the
system, rather than compete. This document outlines how the GMPLS
distributed control plane can work together with a centralized
controller system in a transport network.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9730" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abbreviations">Abbreviations</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-gmpls-control-p">Overview of GMPLS Control Plane</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-centralized-con">Overview of Centralized Controller System</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gmpls-control-interworking-">GMPLS Control Interworking with a Centralized Controller System</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discovery-options">Discovery Options</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lmp">LMP</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-options">Routing Options</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ospf-te">OSPF-TE</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-is-is-te">IS-IS-TE</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-netconf-restconf">NETCONF/RESTCONF</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-computation">Path Computation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-controller-based-path-compu">Controller-Based Path Computation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-constraint-based-path-compu">Constraint-Based Path Computing in GMPLS Control</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-computation-element-pc">Path Computation Element (PCE)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-options">Signaling Options</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rsvp-te">RSVP-TE</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interworking-scenarios">Interworking Scenarios</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-topology-collection-and-syn">Topology Collection and Synchronization </xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-domain-service-provis">Multi-Domain Service Provisioning</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-layer-service-provisi">Multi-Layer Service Provisioning</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.3.2">
                  <li pn="section-toc.1-1.8.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.1.1"><xref derivedContent="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-layer-path-computatio">Multi-Layer Path Computation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.2.1"><xref derivedContent="8.3.2" format="counter" sectionFormat="of" target="section-8.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cross-layer-path-creation">Cross-Layer Path Creation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.3.2.3.1"><xref derivedContent="8.3.3" format="counter" sectionFormat="of" target="section-8.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-link-discovery">Link Discovery</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recovery">Recovery</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.4.2">
                  <li pn="section-toc.1-1.8.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.1.1"><xref derivedContent="8.4.1" format="counter" sectionFormat="of" target="section-8.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-span-protection">Span Protection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.2.1"><xref derivedContent="8.4.2" format="counter" sectionFormat="of" target="section-8.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lsp-protection">LSP Protection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.3.1"><xref derivedContent="8.4.3" format="counter" sectionFormat="of" target="section-8.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-domain-lsp-restorati">Single-Domain LSP Restoration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.4">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.4.1"><xref derivedContent="8.4.4" format="counter" sectionFormat="of" target="section-8.4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-domain-lsp-restoratio">Multi-Domain LSP Restoration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.4.2.5">
                    <t indent="0" pn="section-toc.1-1.8.2.4.2.5.1"><xref derivedContent="8.4.5" format="counter" sectionFormat="of" target="section-8.4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fast-reroute">Fast Reroute</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-controller-reliability">Controller Reliability</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
Generalized Multiprotocol Label Switching (GMPLS) <xref target="RFC3945" format="default" sectionFormat="of" derivedContent="RFC3945"/> extends
MPLS to support different classes of interfaces and switching
capabilities such as Time-Division Multiplex Capable (TDM), Lambda
Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network
element (NE) running a GMPLS control plane collects network
information from other NEs and supports service provisioning through
signaling in a distributed manner. A more generic description of
traffic-engineering networking information exchange can be found in
<xref target="RFC7926" format="default" sectionFormat="of" derivedContent="RFC7926"/>.</t>
      <t indent="0" pn="section-1-2">
On the other hand, Software-Defined Networking (SDN) technologies
have been introduced to control the transport network centrally.
Centralized controllers can collect network information from each
node and provision services on corresponding nodes. One example is
the Abstraction and Control of Traffic-Engineered Networks (ACTN)
<xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/>, which defines a hierarchical architecture with
the Provisioning Network Controller (PNC), Multi-Domain Service
Coordinator (MDSC), and Customer Network Controller (CNC) as
centralized controllers for different network abstraction levels. A
PCE-based approach has been proposed in <xref target="RFC7491" format="default" sectionFormat="of" derivedContent="RFC7491"/>:
Application-Based Network Operations (ABNO).</t>
      <t indent="0" pn="section-1-3">
GMPLS can be used to control network elements (NEs) in such
centralized controller architectures. A centralized controller may
support GMPLS-enabled domains and communicate with a GMPLS-enabled
domain where the GMPLS control plane handles service provisioning
from ingress to egress. In this scenario, the centralized controller
sends a request to the entry node and does not need to configure all
NEs along the path within the domain from ingress to egress, thus
leveraging the GMPLS control plane. This document describes how the
GMPLS control plane interworks with a centralized controller system
in a transport network.</t>
    </section>
    <section anchor="Abbreviations" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-abbreviations">Abbreviations</name>
      <t indent="0" pn="section-2-1">The following abbreviations are used in this document.</t>
      <dl spacing="normal" newline="false" indent="3" pn="section-2-2">
        <dt pn="section-2-2.1">ACTN:</dt>
        <dd pn="section-2-2.2">Abstraction and Control of Traffic-Engineered
	    Networks <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/></dd>
        <dt pn="section-2-2.3">APS:</dt>
        <dd pn="section-2-2.4">Automatic Protection Switching <xref target="G.808.1" format="default" sectionFormat="of" derivedContent="G.808.1"/></dd>
        <dt pn="section-2-2.5">BRPC:</dt>
        <dd pn="section-2-2.6">Backward Recursive PCE-Based Computation <xref target="RFC5441" format="default" sectionFormat="of" derivedContent="RFC5441"/></dd>
        <dt pn="section-2-2.7">CSPF:</dt>
        <dd pn="section-2-2.8">Constrained Shortest Path First</dd>
        <dt pn="section-2-2.9">DoS:</dt>
        <dd pn="section-2-2.10">Denial of Service</dd>
        <dt pn="section-2-2.11">E2E:</dt>
        <dd pn="section-2-2.12">end to end</dd>
        <dt pn="section-2-2.13">ERO:</dt>
        <dd pn="section-2-2.14">Explicit Route Object</dd>
        <dt pn="section-2-2.15">FA:</dt>
        <dd pn="section-2-2.16">Forwarding Adjacency</dd>
        <dt pn="section-2-2.17">FRR:</dt>
        <dd pn="section-2-2.18">Fast Reroute</dd>
        <dt pn="section-2-2.19">GMPLS:</dt>
        <dd pn="section-2-2.20">Generalized Multiprotocol Label Switching <xref target="RFC3945" format="default" sectionFormat="of" derivedContent="RFC3945"/></dd>
        <dt pn="section-2-2.21">H-PCE:</dt>
        <dd pn="section-2-2.22">Hierarchical PCE <xref target="RFC8685" format="default" sectionFormat="of" derivedContent="RFC8685"/></dd>
        <dt pn="section-2-2.23">IDS:</dt>
        <dd pn="section-2-2.24">Intrusion Detection System</dd>
        <dt pn="section-2-2.25">IGP:</dt>
        <dd pn="section-2-2.26">Interior Gateway Protocol</dd>
        <dt pn="section-2-2.27">IoCs:</dt>
        <dd pn="section-2-2.28">Indicators of Compromise <xref target="RFC9424" format="default" sectionFormat="of" derivedContent="RFC9424"/></dd>
        <dt pn="section-2-2.29">IPS:</dt>
        <dd pn="section-2-2.30">Intrusion Prevention System</dd>
        <dt pn="section-2-2.31">IS-IS:</dt>
        <dd pn="section-2-2.32">Intermediate System to Intermediate System</dd>
        <dt pn="section-2-2.33">LMP:</dt>
        <dd pn="section-2-2.34">Link Management Protocol <xref target="RFC4204" format="default" sectionFormat="of" derivedContent="RFC4204"/></dd>
        <dt pn="section-2-2.35">LSP:</dt>
        <dd pn="section-2-2.36">Label Switched Path</dd>
        <dt pn="section-2-2.37">LSP-DB:</dt>
        <dd pn="section-2-2.38">LSP Database</dd>
        <dt pn="section-2-2.39">MD:</dt>
        <dd pn="section-2-2.40">multi-domain</dd>
        <dt pn="section-2-2.41">MDSC:</dt>
        <dd pn="section-2-2.42">Multi-Domain Service Coordinator <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/></dd>
        <dt pn="section-2-2.43">MITM:</dt>
        <dd pn="section-2-2.44">Man in the Middle</dd>
        <dt pn="section-2-2.45">ML:</dt>
        <dd pn="section-2-2.46">multi-layer</dd>
        <dt pn="section-2-2.47">MPI:</dt>
        <dd pn="section-2-2.48">MDSC to PNC Interface <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/></dd>
        <dt pn="section-2-2.49">NE:</dt>
        <dd pn="section-2-2.50">network element</dd>
        <dt pn="section-2-2.51">NETCONF:</dt>
        <dd pn="section-2-2.52">Network Configuration Protocol <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/></dd>
        <dt pn="section-2-2.53">NMS:</dt>
        <dd pn="section-2-2.54">Network Management System</dd>
        <dt pn="section-2-2.55">OSPF:</dt>
        <dd pn="section-2-2.56">Open Shortest Path First</dd>
        <dt pn="section-2-2.57">PCC:</dt>
        <dd pn="section-2-2.58">Path Computation Client <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/></dd>
        <dt pn="section-2-2.59">PCE:</dt>
        <dd pn="section-2-2.60">Path Computation Element <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/></dd>
        <dt pn="section-2-2.61">PCEP:</dt>
        <dd pn="section-2-2.62">PCE Communication Protocol <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/></dd>
        <dt pn="section-2-2.63">PCEP-LS:</dt>
        <dd pn="section-2-2.64">Link State PCEP <xref target="I-D.ietf-pce-pcep-ls" format="default" sectionFormat="of" derivedContent="PCEP-LS"/></dd>
        <dt pn="section-2-2.65">PLR:</dt>
        <dd pn="section-2-2.66">Point of Local Repair</dd>
        <dt pn="section-2-2.67">PNC:</dt>
        <dd pn="section-2-2.68">Provisioning Network Controller <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/></dd>
        <dt pn="section-2-2.69">RSVP:</dt>
        <dd pn="section-2-2.70">Resource Reservation Protocol</dd>
        <dt pn="section-2-2.71">SBI:</dt>
        <dd pn="section-2-2.72">Southbound Interface</dd>
        <dt pn="section-2-2.73">SDN:</dt>
        <dd pn="section-2-2.74">Software-Defined Networking</dd>
        <dt pn="section-2-2.75">TE:</dt>
        <dd pn="section-2-2.76">Traffic Engineering</dd>
        <dt pn="section-2-2.77">TED:</dt>
        <dd pn="section-2-2.78">Traffic Engineering Database</dd>
        <dt pn="section-2-2.79">TLS:</dt>
        <dd pn="section-2-2.80">Transport Layer Security <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/></dd>
        <dt pn="section-2-2.81">VNTM:</dt>
        <dd pn="section-2-2.82">Virtual Network Topology Manager <xref target="RFC5623" format="default" sectionFormat="of" derivedContent="RFC5623"/></dd>
      </dl>
    </section>
    <section anchor="Overview" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-3-1">
This section provides an overview of the GMPLS control plane,
centralized controller systems, and their interactions in transport
networks.</t>
      <t indent="0" pn="section-3-2">
A transport network <xref target="RFC5654" format="default" sectionFormat="of" derivedContent="RFC5654"/> is a server-layer network designed to
provide connectivity services for client-layer connectivity. This
setup allows client traffic to be carried seamlessly across the
server-layer network resources.</t>
      <section anchor="overview-GMPLS-control-plane" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-overview-of-gmpls-control-p">Overview of GMPLS Control Plane</name>
        <t indent="0" pn="section-3.1-1">
GMPLS separates the control plane and the data plane to support
time-division, wavelength, and spatial switching, which are
significant in transport networks. For the NE level control in
GMPLS, each node runs a GMPLS control plane instance.
Functionalities such as service provisioning, protection, and
restoration can be performed via GMPLS communication among multiple
NEs. At the same time, the GMPLS control plane instance can also
collect information about node and link resources in the network to
construct the network topology and compute routing paths for serving
service requests.</t>
        <t indent="0" pn="section-3.1-2">
Several protocols have been designed for the GMPLS control plane
<xref target="RFC3945" format="default" sectionFormat="of" derivedContent="RFC3945"/>, including link management <xref target="RFC4204" format="default" sectionFormat="of" derivedContent="RFC4204"/>, signaling <xref target="RFC3471" format="default" sectionFormat="of" derivedContent="RFC3471"/>,
and routing <xref target="RFC4202" format="default" sectionFormat="of" derivedContent="RFC4202"/> protocols. The GMPLS control plane instances
applying these protocols communicate with each other to exchange
resource information and establish LSPs. In
this way, GMPLS control plane instances in different nodes in the
network have the same view of the network topology and provision
services based on local policies.</t>
      </section>
      <section anchor="controller-sys" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-overview-of-centralized-con">Overview of Centralized Controller System</name>
        <t indent="0" pn="section-3.2-1">
With the development of SDN technologies, a centralized controller
architecture has been introduced to transport networks. One example
architecture can be found in ACTN <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/>. In such systems, a
controller is aware of the network topology and is responsible for
provisioning incoming service requests.</t>
        <t indent="0" pn="section-3.2-2">
Multiple hierarchies of controllers are designed at different levels
to implement different functions. This kind of architecture enables
multi-vendor, multi-domain, and multi-technology control. For
example, a higher-level controller coordinates several lower-level
controllers controlling different domains for topology collection
and service provisioning. Vendor-specific features can be abstracted
between controllers, and a standard API (e.g., generated from
RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/> / YANG <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/>) may be used.</t>
      </section>
      <section anchor="control-sys" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-gmpls-control-interworking-">GMPLS Control Interworking with a Centralized Controller System</name>
        <t indent="0" pn="section-3.3-1">
Besides GMPLS and the interactions among the controller hierarchies,
it is also necessary for the controllers to communicate with the
network elements. Within each domain, GMPLS control can be applied
to each NE. The bottom-level centralized controller can act as an NE
to collect network information and initiate LSPs. <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows an
example of GMPLS interworking with centralized controllers (ACTN
terminologies are used in the figure).</t>
        <figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-example-of-gmpls-non-gmpls-">Example of GMPLS/non-GMPLS Interworking with Controllers</name>
          <artwork align="left" pn="section-3.3-2.1">
                        +-------------------+
                        |    Orchestrator   |
                        |       (MDSC)      |
                        +-------------------+
                          ^       ^       ^
                          |       |       |
            +-------------+       |       +--------------+
            |                     |RESTCONF/YANG modules |
            V                     V                      V
      +-------------+      +-------------+       +-------------+
      |Controller(N)|      |Controller(G)|       |Controller(G)|
      |    (PNC)    |      |    (PNC)    |       |    (PNC)    |
      +-------------+      +-------------+       +-------------+
           ^  ^                  ^  ^                  ^  ^
           |  |                  |  |                  |  |
    NETCONF|  |PCEP       NETCONF|  |PCEP       NETCONF|  |PCEP
     /YANG |  |            /YANG |  |            /YANG |  |
           V  V                  V  V                  V  V
       .----------.  Inter-  .----------.  Inter-  .----------.
      /            \ domain /            \ domain /            \
     |              | link |     LMP      | link |     LMP      |
     |              |======|   OSPF-TE    |======|   OSPF-TE    |
     |              |      |   RSVP-TE    |      |   RSVP-TE    |
      \            /        \            /        \            /
       `----------`          `----------`          `----------`
    Non-GMPLS domain 1      GMPLS domain 2        GMPLS domain 3</artwork>
        </figure>
        <dl indent="3" newline="false" spacing="normal" pn="section-3.3-3">
          <dt pn="section-3.3-3.1">Controller(N):</dt>
          <dd pn="section-3.3-3.2">A domain controller controlling a non-GMPLS domain</dd>
          <dt pn="section-3.3-3.3">Controller(G):</dt>
          <dd pn="section-3.3-3.4">A domain controller controlling a GMPLS domain</dd>
        </dl>
        <t indent="0" pn="section-3.3-4">
   <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows the scenario with two GMPLS domains and one non-GMPLS
   domain. This system supports the interworking among non-GMPLS
   domains, GMPLS domains, and the controller hierarchies.</t>
        <t indent="0" pn="section-3.3-5">
   For domain 1, the network elements were not enabled with GMPLS, so the
   control is purely from the controller, via Network Configuration Protocol
   (NETCONF) <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> with a YANG data model <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> and/or PCE Communication Protocol (PCEP) <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.</t>
        <t indent="0" pn="section-3.3-6">For domains 2 and 3:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.3-7">
          <li pn="section-3.3-7.1">Each domain has the GMPLS control plane enabled at the physical
      network level. The Provisioning Network Controller (PNC) can
      exploit GMPLS capabilities implemented in the domain to listen to
      the IGP routing protocol messages (for example, OSPF Link State Advertisements (LSAs)) that
      the GMPLS control plane instances are disseminating into the
      network and thus learn the network topology. For path computation
      in the domain with the PNC implementing a PCE, Path Computation
      Clients (PCCs) (e.g., NEs, other controllers/PCEs) use PCEP to ask
      the PNC for a path and get replies. The Multi-Domain Service
      Coordinator (MDSC) communicates with PNCs using, for example,
      Representational State Transfer (REST) / RESTCONF based on YANG data models. As a PNC has learned its
      domain topology, it can report the topology to the MDSC. When a
      service arrives, the MDSC computes the path and coordinates PNCs
      to establish the corresponding LSP segment.</li>
          <li pn="section-3.3-7.2">Alternatively, the NETCONF protocol can be used to retrieve
	topology information utilizing the YANG module in <xref target="RFC8795" format="default" sectionFormat="of" derivedContent="RFC8795"/>
	and the technology-specific YANG module augmentations required for the
	specific network technology. The PNC can retrieve topology information
	from any NE (the GMPLS control plane instance of each NE in the domain
	has the same topological view), construct the topology of the domain,
	and export an abstract view to the MDSC.  Based on the topology
	retrieved from multiple PNCs, the MDSC can create a topology graph of
	the multi-domain network and can use it for path computation. To set
	up a service, the MDSC can exploit the YANG module in <xref target="I-D.ietf-teas-yang-te" format="default" sectionFormat="of" derivedContent="YANG-TE"/> together with the technology-specific
	YANG module augmentations.</li>
        </ul>
        <t indent="0" pn="section-3.3-8">This document focuses on the interworking between GMPLS and the
	centralized controller system, including:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.3-9">
          <li pn="section-3.3-9.1">the interworking between the GMPLS domains and the centralized
	  controllers (including the orchestrator, if it exists) controlling
	  the GMPLS domains and</li>
          <li pn="section-3.3-9.2">the interworking between a non-GMPLS domain (which is controlled
	  by a centralized controller system) and a GMPLS domain, through the
	  controller hierarchy architecture.</li>
        </ul>
        <t indent="0" pn="section-3.3-10">
   For convenience, this document uses the following terminologies for
   the controller and the orchestrator:</t>
        <dl spacing="normal" newline="false" indent="3" pn="section-3.3-11">
          <dt pn="section-3.3-11.1">Controller(G):</dt>
          <dd pn="section-3.3-11.2"> A domain controller controlling a GMPLS
	  domain (the Controller(G) of the GMPLS domains 2 and 3 in <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>)</dd>
          <dt pn="section-3.3-11.3">Controller(N):</dt>
          <dd pn="section-3.3-11.4"> A domain controller controlling a
	  non-GMPLS domain (the Controller(N) of the non-GMPLS domain 1 in
	  <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>)</dd>
          <dt pn="section-3.3-11.5">H-Controller(G):</dt>
          <dd pn="section-3.3-11.6"> A domain controller controlling the
	  higher-layer GMPLS domain, in the context of multi-layer
	  networks</dd>
          <dt pn="section-3.3-11.7">L-Controller(G):</dt>
          <dd pn="section-3.3-11.8"> A domain controller controlling the
	  lower-layer GMPLS domain, in the context of multi-layer
	  networks</dd>
          <dt pn="section-3.3-11.9">H-Controller(N):</dt>
          <dd pn="section-3.3-11.10"> A domain controller controlling the
	  higher-layer non-GMPLS domain, in the context of multi-layer
	  networks</dd>
          <dt pn="section-3.3-11.11">L-Controller(N):</dt>
          <dd pn="section-3.3-11.12"> A domain controller controlling the
	  lower-layer non-GMPLS domain, in the context of multi-layer
	  networks</dd>
          <dt pn="section-3.3-11.13">Orchestrator(MD):</dt>
          <dd pn="section-3.3-11.14"> An orchestrator used to orchestrate
	  the multi-domain networks</dd>
          <dt pn="section-3.3-11.15">Orchestrator(ML):</dt>
          <dd pn="section-3.3-11.16"> An orchestrator used to orchestrate
	  the multi-layer networks</dd>
        </dl>
      </section>
    </section>
    <section anchor="discovery-opt" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-discovery-options">Discovery Options</name>
      <t indent="0" pn="section-4-1">
   In GMPLS control, the link connectivity must be verified between
   each pair of nodes. In this way, link resources, which are
   fundamental resources in the network, are discovered by both ends of
   the link.</t>
      <section anchor="LMP" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-lmp">LMP</name>
        <t indent="0" pn="section-4.1-1">
   The Link Management Protocol (LMP) <xref target="RFC4204" format="default" sectionFormat="of" derivedContent="RFC4204"/> runs between nodes and
   manages TE links. In addition to the setup and maintenance of
   control channels, LMP can be used to verify the data link
   connectivity and correlate the link properties.</t>
      </section>
    </section>
    <section anchor="routing-options" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-routing-options">Routing Options</name>
      <t indent="0" pn="section-5-1">
   In GMPLS control, link state information is flooded within the network as
   defined in <xref target="RFC4202" format="default" sectionFormat="of" derivedContent="RFC4202"/>. Each node in the network can build the
   network topology according to the flooded link state information. Routing
   protocols such as OSPF-TE <xref target="RFC4203" format="default" sectionFormat="of" derivedContent="RFC4203"/> and IS-IS-TE <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/> have been extended to support different interfaces in
   GMPLS.</t>
      <t indent="0" pn="section-5-2">
   In a centralized controller system, the centralized controller can
   be placed in the GMPLS network and passively receives the IGP
   information flooded in the network. In this way, the centralized
   controller can construct and update the network topology.</t>
      <section anchor="OSPF-TE" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-ospf-te">OSPF-TE</name>
        <t indent="0" pn="section-5.1-1">
   OSPF-TE is introduced for TE networks in <xref target="RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/>. OSPF extensions
   have been defined in <xref target="RFC4203" format="default" sectionFormat="of" derivedContent="RFC4203"/> to enable the capability of link
   state information for the GMPLS network. Based on this work, OSPF
   has been extended to support technology-specific routing. The
   routing protocols for the Optical Transport Network (OTN), Wavelength
   Switched Optical Network (WSON), and optical flexi-grid networks are
   defined in <xref target="RFC7138" format="default" sectionFormat="of" derivedContent="RFC7138"/>, <xref target="RFC7688" format="default" sectionFormat="of" derivedContent="RFC7688"/>, and <xref target="RFC8363" format="default" sectionFormat="of" derivedContent="RFC8363"/>, respectively.</t>
      </section>
      <section anchor="is-is-te" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-is-is-te">IS-IS-TE</name>
        <t indent="0" pn="section-5.2-1">
   IS-IS-TE is introduced for TE networks in <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>, is extended
   to support GMPLS routing functions <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/>, and has been updated
   <xref target="RFC7074" format="default" sectionFormat="of" derivedContent="RFC7074"/> to support the latest GMPLS switching capability and
   Types fields.</t>
      </section>
      <section anchor="netconf-restconf" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-netconf-restconf">NETCONF/RESTCONF</name>
        <t indent="0" pn="section-5.3-1">
   NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> and RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/> protocols are originally
   used for network configuration. These protocols can also utilize
   topology-related YANG modules, such as those in <xref target="RFC8345" format="default" sectionFormat="of" derivedContent="RFC8345"/> and <xref target="RFC8795" format="default" sectionFormat="of" derivedContent="RFC8795"/>. These
   protocols provide a powerful mechanism for the notification (in addition
   to the provisioning and monitoring) of topology changes to the client.</t>
      </section>
    </section>
    <section anchor="path-computation" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-path-computation">Path Computation</name>
      <section anchor="controller-based-path-comp" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-controller-based-path-compu">Controller-Based Path Computation</name>
        <t indent="0" pn="section-6.1-1">
   Once a controller learns the network topology, it can utilize the
   available resources to serve service requests by performing path
   computation. Due to abstraction, the controllers may not have
   sufficient information to compute the optimal path. In this case,
   the controller can interact with other controllers by sending, for
   example, YANG-based path computation requests <xref target="I-D.ietf-teas-yang-path-computation" format="default" sectionFormat="of" derivedContent="PATH-COMP"/> or PCEP to
   compute a set of potential optimal paths; and then, based on its
   constraints, policy, and specific knowledge (e.g., cost of access
   link), the controller can choose the more feasible path for end-to-end (E2E) service
   path setup.</t>
        <t indent="0" pn="section-6.1-2">
   Path computation is one of the key objectives in various types of
   controllers. In the given architecture, it is possible for different
   components that have the capability to compute the path.</t>
      </section>
      <section anchor="constraint-based-path-comp" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-constraint-based-path-compu">Constraint-Based Path Computing in GMPLS Control</name>
        <t indent="0" pn="section-6.2-1">
   In GMPLS control, a routing path may be computed by the ingress node
   <xref target="RFC3473" format="default" sectionFormat="of" derivedContent="RFC3473"/> based on the ingress node Traffic Engineering Database
   (TED). In this case, constraint-based path computation is performed
   according to the local policy of the ingress node.</t>
      </section>
      <section anchor="pce" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-path-computation-element-pc">Path Computation Element (PCE)</name>
        <t indent="0" pn="section-6.3-1">
   The PCE was first introduced in <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/> as a functional component
   that offers services for computing paths within a network. In
   <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>, path computation is achieved using the TED, which
   maintains a view of the link resources in the network. The
   introduction of the PCE has significantly improved the quality of
   network planning and offline computation. However, there is a
   potential risk that the computed path may be infeasible when there
   is a diversity requirement, as a stateless PCE lacks knowledge about
   previously computed paths.</t>
        <t indent="0" pn="section-6.3-2">
   To address this issue, a stateful PCE has been proposed in <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>.
   Besides the TED, an additional LSP Database (LSP-DB) is introduced
   to archive each LSP computed by the PCE. This way, the PCE can easily
   determine the relationship between the computing path and former
   computed paths. In this approach, the PCE provides computed paths to
   the PCC, and then the PCC decides which path is deployed and when it is to be
   established.</t>
        <t indent="0" pn="section-6.3-3">
   With PCE-initiated LSPs <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>, the PCE can trigger the PCC to
   perform setup, maintenance, and teardown of the PCE-initiated LSP
   under the stateful PCE model. This would allow a dynamic network
   that is centrally controlled and deployed.</t>
        <t indent="0" pn="section-6.3-4">
   In a centralized controller system, the PCE can be implemented
   within the centralized controller. The centralized controller then
   calculates paths based on its local policies. Alternatively, the PCE
   can be located outside of the centralized controller. In this
   scenario, the centralized controller functions as a PCC and sends a
   path computation request to the PCE using the PCEP. A reference
   architecture for this can be found in <xref target="RFC7491" format="default" sectionFormat="of" derivedContent="RFC7491"/>.</t>
      </section>
    </section>
    <section anchor="sign-opt" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-signaling-options">Signaling Options</name>
      <t indent="0" pn="section-7-1">
   Signaling mechanisms are used to set up LSPs in GMPLS control.  Messages
   are sent hop by hop between the ingress node and the egress node of the LSP
   to allocate labels. Once the labels are allocated along the path, the LSP
   setup is accomplished. Signaling protocols such as Resource Reservation Protocol - Traffic Engineering (RSVP-TE) <xref target="RFC3473" format="default" sectionFormat="of" derivedContent="RFC3473"/> have been extended to support different interfaces in
   GMPLS.</t>
      <section anchor="RSVP-TE" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-rsvp-te">RSVP-TE</name>
        <t indent="0" pn="section-7.1-1">
   RSVP-TE is introduced in <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/> and extended to support GMPLS
   signaling in <xref target="RFC3473" format="default" sectionFormat="of" derivedContent="RFC3473"/>. Several label formats are defined for a
   generalized label request, a generalized label, a suggested label,
   and label sets. Based on <xref target="RFC3473" format="default" sectionFormat="of" derivedContent="RFC3473"/>, RSVP-TE has been extended to
   support technology-specific signaling. The RSVP-TE extensions for the
   OTN, WSON, and optical flexi-grid network are defined in <xref target="RFC7139" format="default" sectionFormat="of" derivedContent="RFC7139"/>,
   <xref target="RFC7689" format="default" sectionFormat="of" derivedContent="RFC7689"/>, and <xref target="RFC7792" format="default" sectionFormat="of" derivedContent="RFC7792"/>, respectively.</t>
      </section>
    </section>
    <section anchor="interworking-scenarios" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-interworking-scenarios">Interworking Scenarios</name>
      <section anchor="top-collection-synch" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-topology-collection-and-syn">Topology Collection and Synchronization </name>
        <t indent="0" pn="section-8.1-1"> Topology information is necessary on both network elements and
	controllers. The topology on a network element is usually raw
	information, while the topology used by the controller can be either
	raw, reduced, or abstracted. Three different abstraction methods have
	been described in <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/>, and different controllers
	can select the corresponding method depending on the application.</t>
        <t indent="0" pn="section-8.1-2">When there are changes in the network topology, the impacted
	network elements need to report changes to all the other network
	elements, together with the controller, to sync up the topology
	information.  The inter-NE synchronization can be achieved via
	protocols mentioned in Sections <xref target="discovery-opt" format="counter" sectionFormat="of" derivedContent="4"/> and <xref target="routing-options" format="counter" sectionFormat="of" derivedContent="5"/>. The topology synchronization between NEs and
	controllers can either be achieved by routing protocols
	OSPF-TE/PCEP-LS in <xref target="I-D.ietf-pce-pcep-ls" format="default" sectionFormat="of" derivedContent="PCEP-LS"/> or NETCONF
	protocol notifications with a YANG module.</t>
      </section>
      <section anchor="multi-domain-service-provision" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-multi-domain-service-provis">Multi-Domain Service Provisioning</name>
        <t indent="0" pn="section-8.2-1">Service provisioning can be deployed based on the topology information on
controllers and network elements. Many methods have been specified for
single-domain service provisioning, such as the PCEP and RSVP-TE methods.</t>
        <t indent="0" pn="section-8.2-2">Multi-domain service provisioning would require coordination among the
controller hierarchies. Given the service request, the end-to-end delivery
procedure may include interactions at any level (i.e., interface) in the
hierarchy of the controllers (e.g., MPI and SBI for ACTN). The computation for
a cross-domain path is usually completed by controllers who have a global view
of the topologies. Then the configuration is decomposed into lower-level
controllers to configure the network elements to set up the path.</t>
        <t indent="0" pn="section-8.2-3">A combination of centralized and distributed protocols may be necessary to
interact between network elements and controllers.  Several methods can be
used to create the inter-domain path:</t>
        <ol type="%d)" group="8.2" start="1" indent="adaptive" spacing="normal" pn="section-8.2-4">
   <li pn="section-8.2-4.1" derivedCounter="1)">
            <t indent="0" pn="section-8.2-4.1.1">With an end-to-end RSVP-TE session:</t>
            <t indent="0" pn="section-8.2-4.1.2">In this method, all the domains need to support the RSVP-TE protocol
     and thus need to be GMPLS domains. The Controller(G) of the source domain
     triggers the source node to create the end-to-end RSVP-TE session; and
     the assignment and distribution of the labels on the inter-domain links
     are done by the border nodes of each domain, using RSVP-TE
     protocol. Therefore, this method requires the interworking of RSVP-TE
     protocols between different domains.</t>
            <t indent="0" pn="section-8.2-4.1.3">There are two possible methods:</t>
            <ol type="1.%d)" indent="adaptive" spacing="normal" start="1" pn="section-8.2-4.1.4">
       <li pn="section-8.2-4.1.4.1" derivedCounter="1.1)">
                <t indent="0" pn="section-8.2-4.1.4.1.1">One single end-to-end RSVP-TE session:</t>
                <t indent="0" pn="section-8.2-4.1.4.1.2">In this method, an end-to-end RSVP-TE session from the source node
	 to the destination node will be used to create the inter-domain
	 path. A typical example would be the PCE initiation scenario, in
	 which a PCE message (PCInitiate) is sent from the Controller(G) to
	 the source node, triggering an RSVP procedure along the path.
	 Similarly, the interaction between the controller and the source node
	 of the source domain can be achieved by using the NETCONF protocol
	 with corresponding YANG modules, and then it can be completed by
	 running RSVP among the network elements.</t>
              </li>
              <li pn="section-8.2-4.1.4.2" derivedCounter="1.2)">
                <t indent="0" pn="section-8.2-4.1.4.2.1">LSP Stitching:</t>
                <t indent="0" pn="section-8.2-4.1.4.2.2">The LSP stitching method defined in <xref target="RFC5150" format="default" sectionFormat="of" derivedContent="RFC5150"/> can
	 also create the E2E LSP. That is, when the source node receives
	 an end-to-end path creation request (e.g., using PCEP or NETCONF
	 protocol), the source node starts an end-to-end RSVP-TE session along
	 the endpoints of each LSP segment (S-LSP) (refers to S-LSP in <xref target="RFC5150" format="default" sectionFormat="of" derivedContent="RFC5150"/>) of each domain, to assign the labels on the
	 inter-domain links between each pair of neighbor S-LSPs and to stitch
	 the end-to-end LSP to each S-LSP. See <xref target="ure-lsp-stitching" format="default" sectionFormat="of" derivedContent="Figure 2"/> as an example.</t>
                <t indent="0" pn="section-8.2-4.1.4.2.3">Note that the S-LSP in each domain can be either created by its
	 Controller(G) in advance or created dynamically triggered by the
	 end-to-end RSVP-TE session.</t>
                <figure anchor="ure-lsp-stitching" align="left" suppress-title="false" pn="figure-2">
                  <name slugifiedName="name-lsp-stitching">LSP Stitching</name>
                  <artwork align="left" pn="section-8.2-4.1.4.2.4.1">
                  +------------------------+
                  |    Orchestrator(MD)    |
                  +-----------+------------+
                              |
 +---------------+     +------V-------+     +---------------+
 | Controller(G) |     | Controller(G)|     | Controller(G) |
 +-------+-------+     +------+-------+     +-------+-------+
         |                    |                     |
+--------V--------+   +-------V--------+   +--------V--------+
|Client           |   |                |   |           Client|
|Signal   Domain 1|   |    Domain 2    |   |Domain 3   Signal|
|  |              |   |                |   |              |  |
|+-+-+            |   |                |   |            +-+-+|
|| | |  +--+  +--+|   |+--+  +--+  +--+|   |+--+  +--+  | | ||
|| | |  |  |  |  ||   ||  |  |  |  |  ||   ||  |  |  |  | | ||
|| ******************************************************** ||
||   |  |  |  |  ||   ||  |  |  |  |  ||   ||  |  |  |  |   ||
|+---+  +--+  +--+|   |+--+  +--+  +--+|   |+--+  +--+  +---+|
+-----------------+   +----------------+   +-----------------+
 |   .           .     .              .     .           .   |
 |   .&lt;-S-LSP 1-&gt;.     .&lt;- S-LSP 2 --&gt;.     .&lt;-S-LSP 3-&gt;.   |
 |               .     .              .     .               |
 |--------------&gt;.----&gt;.-------------&gt;.----&gt;.--------------&gt;|
 |&lt;--------------.&lt;----.&lt;-------------.&lt;----.&lt;--------------|
 |       End-to-end RSVP-TE session for LSP stitching       |</artwork>
                </figure>
              </li>
            </ol>
          </li>
          <li pn="section-8.2-4.2" derivedCounter="2)">
            <t indent="0" pn="section-8.2-4.2.1">Without an end-to-end RSVP-TE session:</t>
            <t indent="0" pn="section-8.2-4.2.2">In this method, each domain can be a GMPLS domain or a non-GMPLS
     domain. Each controller (which may be a Controller(G) or a Controller(N)) is
     responsible for creating the path segment within its domain. The border
     node does not need to communicate with other border nodes in other
     domains for the distribution of labels on inter-domain links, so an
     end-to-end RSVP-TE session through multiple domains is not required, and
     the interworking of the RSVP-TE protocol between different domains is not
     needed.</t>
            <t indent="0" pn="section-8.2-4.2.3">Note that path segments in the source domain and the destination
     domain are "asymmetrical" segments, because the configuration of client
     signal mapping into the server-layer tunnel is needed at only one end of the
     segment, while configuration of the server-layer cross-connect is needed at
     the other end of the segment. See the example in <xref target="ure-example-of-asymmetrical-path-segment" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
            <figure anchor="ure-example-of-asymmetrical-path-segment" align="left" suppress-title="false" pn="figure-3">
              <name slugifiedName="name-example-of-an-asymmetrical-">Example of an Asymmetrical Path Segment</name>
              <artwork align="left" pn="section-8.2-4.2.4.1">
                  +------------------------+
                  |    Orchestrator(MD)    |
                  +-----------+------------+
                              |
 +---------------+     +------V-------+     +---------------+
 |  Controller   |     |  Controller  |     |  Controller   |
 +-------+-------+     +------+-------+     +-------+-------+
         |                    |                     |
+--------V--------+   +-------V--------+   +--------V--------+
|Client   Domain 1|   |    Domain 2    |   | Domain 3  Client|
|Signal           |   |                |   |           Signal|
|  |  Server layer|   |                |   |              |  |
|  |     tunnel   |   |                |   |              |  |
|+-+-+       ^    |   |                |   |            +-+-+|
|| | |  +--+ |+--+|   |+--+  +--+  +--+|   |+--+  +--+  | | ||
|| | |  |  | ||  ||   ||  |  |  |  |  ||   ||  |  |  |  | | ||
|| ******************************************************** ||
||   |  |  |  |  || . ||  |  |  |  |  || . ||  |  |  |  |   ||
|+---+  +--+  +--+| . |+--+  +--+  +--+| . |+--+  +--+  +---+|
+-----------------+ . +----------------+ . +-----------------+
 .                  .                    .                  .
 .&lt;-Path Segment 1-&gt;.&lt;--Path Segment 2--&gt;.&lt;-Path Segment 3-&gt;.</artwork>
            </figure>
            <t indent="0" pn="section-8.2-4.2.5">The PCEP / GMPLS protocols should support the creation of such
   asymmetrical segments.</t>
            <t indent="0" pn="section-8.2-4.2.6">Note also that mechanisms to assign the labels in the inter-domain
   links also need to be considered. There are two possible methods:</t>
            <ol type="2.%d)" indent="adaptive" spacing="normal" start="1" pn="section-8.2-4.2.7">
     <li pn="section-8.2-4.2.7.1" derivedCounter="2.1)">
                <t indent="0" pn="section-8.2-4.2.7.1.1">Inter-domain labels assigned by NEs:</t>
                <t indent="0" pn="section-8.2-4.2.7.1.2"> The concept of a stitching label that allows stitching local path
       segments was introduced in <xref target="RFC5150" format="default" sectionFormat="of" derivedContent="RFC5150"/> and <xref target="I-D.ietf-pce-stateful-interdomain" format="default" sectionFormat="of" derivedContent="SPCE-ID"/>, in order to form the
       inter-domain path crossing several different domains. It also describes
       the Backward Recursive PCE-Based Computation (BRPC) <xref target="RFC5441" format="default" sectionFormat="of" derivedContent="RFC5441"/> and Hierarchical PCE (H-PCE)
       <xref target="RFC8685" format="default" sectionFormat="of" derivedContent="RFC8685"/> PCInitiate procedure, i.e., the ingress node
       of each downstream domain assigns the stitching label for the
       inter-domain link between the downstream domain and its upstream
       neighbor domain; and this stitching label will be passed to the
       upstream neighbor domain by PCE protocol, which will be used for the
       path segment creation in the upstream neighbor domain.</t>
              </li>
              <li pn="section-8.2-4.2.7.2" derivedCounter="2.2)">
                <t indent="0" pn="section-8.2-4.2.7.2.1">Inter-domain labels assigned by the controller:</t>
                <t indent="0" pn="section-8.2-4.2.7.2.2">If the resources of inter-domain links are managed by the
       Orchestrator(MD), each domain controller can provide to the
       Orchestrator(MD) the list of available labels (e.g., time slots if the
       OTN is the scenario) using topology-related YANG modules and specific
       technology-related extensions.  Once the orchestrator(MD) has computed
       the E2E path, RSVP-TE or PCEP can be used in the different domains to
       set up the related segment tunnel consisting of information about
       inter-domain labels; for example, for PCEP, the label Explicit Route
       Object (ERO) can be included in the PCInitiate message to indicate the
       inter-domain labels so that each border node of each domain can
       configure the correct cross-connect within itself.</t>
              </li>
            </ol>
          </li>
        </ol>
      </section>
      <section anchor="multi-layer-service-provision" numbered="true" removeInRFC="false" toc="include" pn="section-8.3">
        <name slugifiedName="name-multi-layer-service-provisi">Multi-Layer Service Provisioning</name>
        <t indent="0" pn="section-8.3-1">GMPLS can interwork with centralized controller systems in
	  multi-layer networks.</t>
        <figure anchor="ure-gmpls-controller-interworking-in-multi-layer-networks" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-gmpls-controller-interworki">GMPLS-controller Interworking in Multi-Layer Networks</name>
          <artwork align="left" pn="section-8.3-2.1">
+----------------+
|Orchestrator(ML)|
+------+--+------+
       |  |                            Higher-layer Network
       |  |                           .--------------------.
       |  |                          /                      \
       |  |   +--------------+      |   +--+   Link   +--+   |
       |  +--&gt;| H-Controller +-----&gt;|   |  |**********|  |   |
       |      +--------------+      |   +--+          +--+   |
       |                             \    .            .    /
       |                               `--.------------.---`
       |                                  .            .
       |                              .---.------------.---.
       |                             /    .            .    \
       |      +--------------+      |   +--+   +--+   +--+   |
       +-----&gt;| L-Controller +-----&gt;|   | ============== |   |
              +--------------+      |   +--+   +--+   +--+   |
                                     \         H-LSP        /
                                       `-------------------`
                                        Lower-layer Network</artwork>
        </figure>
        <t indent="0" pn="section-8.3-3">An example with two layers of network is shown in <xref target="ure-gmpls-controller-interworking-in-multi-layer-networks" format="default" sectionFormat="of" derivedContent="Figure 4"/>. In
	this example, the GMPLS control plane is enabled in at least one layer
	network (otherwise, it is out of the scope of this document) and
	interworks with the controller of its domain (H-Controller and
	L-Controller, respectively). The Orchestrator(ML) is used to
	coordinate the control of the multi-layer network.</t>
        <section anchor="multi-layer-path-comp" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.1">
          <name slugifiedName="name-multi-layer-path-computatio">Multi-Layer Path Computation</name>
          <t indent="0" pn="section-8.3.1-1"><xref target="RFC5623" format="default" sectionFormat="of" derivedContent="RFC5623"/> describes three inter-layer path
	  computation models and four inter-layer path control models:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.3.1-2">
            <li pn="section-8.3.1-2.1">
              <t indent="0" pn="section-8.3.1-2.1.1">3 path computation models:</t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.3.1-2.1.2">
                <li pn="section-8.3.1-2.1.2.1">Single PCE path computation model</li>
                <li pn="section-8.3.1-2.1.2.2">Multiple PCE path computation with inter-PCE communication
            model</li>
                <li pn="section-8.3.1-2.1.2.3">Multiple PCE path computation without inter-PCE communication
            model</li>
              </ul>
            </li>
            <li pn="section-8.3.1-2.2">
              <t indent="0" pn="section-8.3.1-2.2.1">4 path control models:</t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.3.1-2.2.2">
                <li pn="section-8.3.1-2.2.2.1">PCE Virtual Network Topology Manager (PCE-VNTM)
            cooperation model</li>
                <li pn="section-8.3.1-2.2.2.2">Higher-layer signaling trigger model</li>
                <li pn="section-8.3.1-2.2.2.3">Network Management System VNTM (NMS-VNTM) cooperation model
            (integrated flavor)</li>
                <li pn="section-8.3.1-2.2.2.4">NMS-VNTM cooperation model (separate flavor)</li>
              </ul>
            </li>
          </ul>
          <t indent="0" pn="section-8.3.1-3">
   <xref target="RFC5623" sectionFormat="of" section="4.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5623#section-4.2.4" derivedContent="RFC5623"/> also provides
   all the possible combinations of inter-layer path computation and
   inter-layer path control models.</t>
          <t indent="0" pn="section-8.3.1-4">
   To apply <xref target="RFC5623" format="default" sectionFormat="of" derivedContent="RFC5623"/> in a multi-layer network with
   GMPLS-controller interworking, the H-Controller and the L-Controller can
   act as the PCE Hi and PCE Lo, respectively; and typically, the
   Orchestrator(ML) can act as a VNTM because it has the abstracted view of
   both the higher-layer and lower-layer networks.</t>
          <t indent="0" pn="section-8.3.1-5">
   <xref target="tab-fig" format="default" sectionFormat="of" derivedContent="Table 1"/> shows all possible combinations of path
   computation and path control models in multi-layer network with
   GMPLS-controller interworking:</t>
          <table anchor="tab-fig" align="center" pn="table-1">
            <name slugifiedName="name-combinations-of-path-comput">Combinations of Path Computation and Path Control Models</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Path computation / Path control</th>
                <th align="left" colspan="1" rowspan="1">Single PCE</th>
                <th align="left" colspan="1" rowspan="1">Multiple PCE with inter-PCE</th>
                <th align="left" colspan="1" rowspan="1">Multiple PCE w/o inter-PCE</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">PCE-VNTM cooperation</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
                <td align="left" colspan="1" rowspan="1">Yes</td>
                <td align="left" colspan="1" rowspan="1">Yes</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Higher-layer signaling trigger</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
                <td align="left" colspan="1" rowspan="1">Yes</td>
                <td align="left" colspan="1" rowspan="1">Yes</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">NMS-VNTM cooperation (integrated flavor)</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
                <td align="left" colspan="1" rowspan="1">Yes (1)</td>
                <td align="left" colspan="1" rowspan="1">No (1)</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">NMS-VNTM cooperation (separate flavor)</td>
                <td align="left" colspan="1" rowspan="1">N/A</td>
                <td align="left" colspan="1" rowspan="1">No (1)</td>
                <td align="left" colspan="1" rowspan="1">Yes (1)</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-8.3.1-7">Note that:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.3.1-8">
            <li pn="section-8.3.1-8.1">
              <t indent="0" pn="section-8.3.1-8.1.1">Since there is one PCE in each layer network, the path computation
  model "Single PCE path computation" is not applicable (N/A).</t>
            </li>
            <li pn="section-8.3.1-8.2">
              <t indent="0" pn="section-8.3.1-8.2.1">For the other two path computation models "Multiple PCE with
  inter-PCE" and "Multiple PCE w/o inter-PCE", the possible combinations are
  the same as defined in <xref target="RFC5623" format="default" sectionFormat="of" derivedContent="RFC5623"/>. More specifically:</t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.3.1-8.2.2">
                <li pn="section-8.3.1-8.2.2.1">
                  <t indent="0" pn="section-8.3.1-8.2.2.1.1">(1) The path control models "NMS-VNTM cooperation (integrated
    flavor)" and "NMS-VNTM cooperation (separate flavor)" are the typical
    models to be used in a multi-layer network with GMPLS-controller
    interworking. This is because, in these two models, the path computation is
    triggered by the NMS or VNTM. And in the centralized controller system,
    the path computation requests are typically from the Orchestrator(ML)
    (acts as VNTM).</t>
                </li>
                <li pn="section-8.3.1-8.2.2.2">
                  <t indent="0" pn="section-8.3.1-8.2.2.2.1">For the other two path control models "PCE-VNTM cooperation" and
    "Higher-layer signaling trigger", the path computation is triggered by the
    NEs, i.e., the NE performs PCC functions.  It is still possible to use
    these two models, although they are not the main methods.</t>
                </li>
              </ul>
            </li>
          </ul>
        </section>
        <section anchor="cross-layer-path-creation" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.2">
          <name slugifiedName="name-cross-layer-path-creation">Cross-Layer Path Creation</name>
          <t indent="0" pn="section-8.3.2-1"> In a multi-layer network, a lower-layer LSP in the lower-layer network can
be created, which will construct a new link in the higher-layer network. Such
a lower-layer LSP is called Hierarchical LSP, or H-LSP for short; see <xref target="RFC6107" format="default" sectionFormat="of" derivedContent="RFC6107"/>.</t>
          <t indent="0" pn="section-8.3.2-2"> The new link constructed by the H-LSP can then be used by the higher-layer
network to create new LSPs.</t>
          <t indent="0" pn="section-8.3.2-3">As described in <xref target="RFC5212" format="default" sectionFormat="of" derivedContent="RFC5212"/>, two methods are introduced to
   create the H-LSP: the static (pre-provisioned) method and the dynamic
   (triggered) method.</t>
          <ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="section-8.3.2-4">
<li pn="section-8.3.2-4.1" derivedCounter="1)">
              <t indent="0" pn="section-8.3.2-4.1.1">Static (pre-provisioned) method:</t>
              <t indent="0" pn="section-8.3.2-4.1.2">In this method, the H-LSP in the lower-layer network is created in
advance. After that, the higher-layer network can create LSPs using the
resource of the link constructed by the H-LSP.</t>
              <t indent="0" pn="section-8.3.2-4.1.3">The Orchestrator(ML) is responsible to decide the creation of H-LSP in the
lower-layer network if it acts as a VNTM. Then it requests the L-Controller to
create the H-LSP via, for example, an MPI under the ACTN
architecture.</t>
              <t indent="0" pn="section-8.3.2-4.1.4">If the lower-layer network is a GMPLS domain, the L-Controller(G) can
trigger the GMPLS control plane to create the H-LSP. As a typical example, the
PCInitiate message can be used for the communication between the L-Controller
and the source node of the H-LSP. And the source node of the H-LSP can trigger
the RSVP-TE signaling procedure to create the H-LSP, as described in <xref target="RFC6107" format="default" sectionFormat="of" derivedContent="RFC6107"/>.</t>
              <t indent="0" pn="section-8.3.2-4.1.5"> If the lower-layer network is a non-GMPLS domain, other methods may be
used by the L-Controller(N) to create the H-LSP, which is out of scope of this
document.</t>
            </li>
            <li pn="section-8.3.2-4.2" derivedCounter="2)">
              <t indent="0" pn="section-8.3.2-4.2.1">Dynamic (triggered) method:</t>
              <t indent="0" pn="section-8.3.2-4.2.2">In this method, the signaling of LSP creation in the higher-layer network
will trigger the creation of H-LSP in the lower-layer network dynamically, if
it is necessary. Therefore, both the higher-layer and lower-layer networks
need to support the RSVP-TE protocol and thus need to be GMPLS domains.</t>
              <t indent="0" pn="section-8.3.2-4.2.3">In this case, after the cross-layer path is computed, the Orchestrator(ML)
requests the H-Controller(G) for the cross-layer LSP creation. As a typical
example, the MPI under the ACTN architecture could be used.</t>
              <t indent="0" pn="section-8.3.2-4.2.4">The H-Controller(G) can trigger the GMPLS control plane to create the LSP
in the higher-layer network. As a typical example, the PCInitiate message can
be used for the communication between the H-Controller(G) and the source node
of the higher-layer LSP, as described in <xref target="RFC8282" sectionFormat="of" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8282#section-4.3" derivedContent="RFC8282"/>. At least two sets of ERO information
should be included to indicate the routes of higher-layer LSP and lower-layer
H-LSP.</t>
              <t indent="0" pn="section-8.3.2-4.2.5">The source node of the higher-layer LSP follows the procedure defined in
<xref target="RFC6001" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6001#section-4" derivedContent="RFC6001"/> to trigger
the GMPLS control plane in both the higher-layer network and the lower-layer
network to create the higher-layer LSP and the lower-layer H-LSP.</t>
              <t indent="0" pn="section-8.3.2-4.2.6">On success, the source node of the H-LSP should report the information of
the H-LSP to the L-Controller(G) via, for example, the PCRpt message.</t>
            </li>
          </ol>
        </section>
        <section anchor="link-discovery" numbered="true" removeInRFC="false" toc="include" pn="section-8.3.3">
          <name slugifiedName="name-link-discovery">Link Discovery</name>
          <t indent="0" pn="section-8.3.3-1">If the higher-layer network and the lower-layer network are under the same
GMPLS control plane instance, the H-LSP can be a Forwarding Adjacency LSP
(FA-LSP). Then the information of the link constructed by this FA-LSP can be
advertised in the routing instance, so that the H-Controller can be aware of
this new FA. <xref target="RFC4206" format="default" sectionFormat="of" derivedContent="RFC4206"/> and the following updates to it
(including <xref target="RFC6001" format="default" sectionFormat="of" derivedContent="RFC6001"/> and <xref target="RFC6107" format="default" sectionFormat="of" derivedContent="RFC6107"/>) describe the
detailed extensions to support advertisement of an FA.</t>
          <t indent="0" pn="section-8.3.3-2">If the higher-layer network and the lower-layer network are under separate
GMPLS control plane instances or if one of the layer networks is a non-GMPLS
domain, after an H-LSP is created in the lower-layer network, the link
discovery procedure will be triggered in the higher-layer network to discover
the information of the link constructed by the H-LSP. The LMP defined in
<xref target="RFC4204" format="default" sectionFormat="of" derivedContent="RFC4204"/> can be used if the higher-layer network supports
GMPLS. The information of this new link will be advertised to the
H-Controller.</t>
        </section>
      </section>
      <section anchor="recovery" numbered="true" removeInRFC="false" toc="include" pn="section-8.4">
        <name slugifiedName="name-recovery">Recovery</name>
        <t indent="0" pn="section-8.4-1"> The GMPLS recovery functions are described in <xref target="RFC4426" format="default" sectionFormat="of" derivedContent="RFC4426"/>. Span protection and end-to-end protection and restoration
are discussed with different protection schemes and message exchange
requirements.  Related RSVP-TE extensions to support end-to-end recovery are
described in <xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/>. The extensions in <xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/> include protection, restoration, preemption, and rerouting
mechanisms for an end-to-end LSP. Besides end-to-end recovery, a GMPLS segment
recovery mechanism is defined in <xref target="RFC4873" format="default" sectionFormat="of" derivedContent="RFC4873"/>, which also intends
to be compatible with Fast Reroute (FRR) (see <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/>, which
defines RSVP-TE extensions for the FRR mechanism, and <xref target="RFC8271" format="default" sectionFormat="of" derivedContent="RFC8271"/>,
which describes the updates of the GMPLS RSVP-TE protocol for FRR of GMPLS
TE-LSPs).</t>
        <section anchor="span-protection" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.1">
          <name slugifiedName="name-span-protection">Span Protection</name>
          <t indent="0" pn="section-8.4.1-1">Span protection refers to the protection of the link between two
neighboring switches. The main protocol requirements include:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.4.1-2">
            <li pn="section-8.4.1-2.1">
              <t indent="0" pn="section-8.4.1-2.1.1">Link management: Link property correlation on the link protection
     type</t>
            </li>
            <li pn="section-8.4.1-2.2">Routing: Announcement of the link protection type</li>
            <li pn="section-8.4.1-2.3">Signaling: Indication of link protection requirement for that LSP</li>
          </ul>
          <t indent="0" pn="section-8.4.1-3"> GMPLS already supports the above requirements, and there are no new
   requirements in the scenario of interworking between GMPLS and a centralized
   controller system.</t>
        </section>
        <section anchor="lsp-protection" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.2">
          <name slugifiedName="name-lsp-protection">LSP Protection</name>
          <t indent="0" pn="section-8.4.2-1">The LSP protection includes end-to-end and segment LSP protection.  For
both cases:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.4.2-2">
            <li pn="section-8.4.2-2.1">
              <t indent="0" pn="section-8.4.2-2.1.1">In the provisioning phase:</t>
              <t indent="0" pn="section-8.4.2-2.1.2">In both single-domain and multi-domain scenarios, the disjoint
          path computation can be done by the centralized controller system,
          as it has the global topology and resource view. And the path
          creation can be done by the procedure described in <xref target="multi-domain-service-provision" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t>
            </li>
            <li pn="section-8.4.2-2.2">
              <t indent="0" pn="section-8.4.2-2.2.1">In the protection switchover phase:</t>
              <t indent="0" pn="section-8.4.2-2.2.2">In both single-domain and multi-domain scenarios, the existing
          standards provide the distributed way to trigger the protection
          switchover, for example, the data plane Automatic Protection Switching
          (APS) mechanism described in <xref target="G.808.1" format="default" sectionFormat="of" derivedContent="G.808.1"/>, <xref target="RFC7271" format="default" sectionFormat="of" derivedContent="RFC7271"/>, and <xref target="RFC8234" format="default" sectionFormat="of" derivedContent="RFC8234"/> or the GMPLS Notify
          mechanism described in <xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/> and <xref target="RFC4873" format="default" sectionFormat="of" derivedContent="RFC4873"/>. In the scenario of interworking between GMPLS
          and a centralized controller system, using these distributed
          mechanisms rather than a centralized mechanism (i.e., the controller
          triggers the protection switchover) can significantly shorten the
          protection switching time.</t>
            </li>
          </ul>
        </section>
        <section anchor="single-domain-LSP-restore" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.3">
          <name slugifiedName="name-single-domain-lsp-restorati">Single-Domain LSP Restoration</name>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.4.3-1">
            <li pn="section-8.4.3-1.1">
              <t indent="0" pn="section-8.4.3-1.1.1">Pre-planned LSP protection (including shared-mesh restoration):</t>
              <t indent="0" pn="section-8.4.3-1.1.2">In pre-planned protection, the protecting LSP is established
            only in the control plane in the provisioning phase and will be
            activated in the data plane once failure occurs.</t>
              <t indent="0" pn="section-8.4.3-1.1.3">In the scenario of interworking between GMPLS and a centralized
	    controller system, the route of protecting LSP can be computed by
	    the centralized controller system. This takes the advantage of
	    making better use of network resources, especially for the
	    resource-sharing in shared-mesh restoration.  </t>
            </li>
            <li pn="section-8.4.3-1.2">
              <t indent="0" pn="section-8.4.3-1.2.1">Full LSP rerouting:</t>
              <t indent="0" pn="section-8.4.3-1.2.2">In full LSP rerouting, the normal traffic will be switched to
            an alternate LSP that is fully established only after a failure
            occurrence.</t>
              <t indent="0" pn="section-8.4.3-1.2.3">As described in <xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/> and <xref target="RFC4873" format="default" sectionFormat="of" derivedContent="RFC4873"/>, the alternate route can be computed on demand
	    when there is a failure occurrence or can be pre-computed and
	    stored before a failure occurrence.</t>
              <t indent="0" pn="section-8.4.3-1.2.4">In a fully distributed scenario, the pre-computation method
	    offers a faster restoration time but has the risk that the
	    pre-computed alternate route may become out-of-date due to the
	    changes of the network.</t>
              <t indent="0" pn="section-8.4.3-1.2.5">In the scenario of interworking between GMPLS and a centralized
	    controller system, the pre-computation of the alternate route
	    could take place in the centralized controller (and may be stored
	    in the controller or the head-end node of the LSP). In this way,
	    any changes in the network can trigger the refreshment of the
	    alternate route by the centralized controller. This makes sure
	    that the alternate route will not become out-of-date.  </t>
            </li>
          </ul>
        </section>
        <section anchor="multi-domain-LSP-restore" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.4">
          <name slugifiedName="name-multi-domain-lsp-restoratio">Multi-Domain LSP Restoration</name>
          <t indent="0" pn="section-8.4.4-1"> A working LSP may traverse multiple domains, each of which may or may not
support a GMPLS distributed control plane.</t>
          <t indent="0" pn="section-8.4.4-2"> If all the domains support GMPLS, both the end-to-end rerouting method and
the domain segment rerouting method could be used.</t>
          <t indent="0" pn="section-8.4.4-3">If only some domains support GMPLS, the domain segment rerouting method
could be used in those GMPLS domains. For other domains that do not support
GMPLS, other mechanisms may be used to protect the LSP segments, which are out
of scope of this document.</t>
          <ol type="%d)" group="8.4.4" start="1" indent="adaptive" spacing="normal" pn="section-8.4.4-4">
<li pn="section-8.4.4-4.1" derivedCounter="1)">
              <t indent="0" pn="section-8.4.4-4.1.1">End-to-end rerouting:</t>
              <t indent="0" pn="section-8.4.4-4.1.2">In this scenario, a failure on the working LSP inside any domain or on the
inter-domain links will trigger the end-to-end restoration.</t>
              <t indent="0" pn="section-8.4.4-4.1.3">In both pre-planned and full LSP rerouting, the end-to-end protecting LSP
could be computed by the centralized controller system and could be created
by the procedure described in <xref target="multi-domain-service-provision" format="default" sectionFormat="of" derivedContent="Section 8.2"/>. Note that the end-to-end protecting
LSP may traverse different domains from the working LSP, depending on the
result of multi-domain path computation for the protecting LSP.</t>
              <figure align="left" suppress-title="false" pn="figure-5">
                <name slugifiedName="name-end-to-end-restoration">End-to-End Restoration</name>
                <artwork align="left" pn="section-8.4.4-4.1.4.1">
                    +----------------+
                    |Orchestrator(MD)|
                    +-------.--------+
       ............................................
       .             .              .             .
  +----V-----+  +----V-----+   +----V-----+  +----V-----+
  |Controller|  |Controller|   |Controller|  |Controller|
  |  (G) 1   |  |  (G) 2   |   |  (G) 3   |  |  (G) 4   |
  +----.-----+  +-------.--+   +-------.--+  +----.-----+
       .                .              .          .
  +----V--------+     +-V-----------+  .  +-------V-----+
  |  Domain 1   |     |  Domain 2   |  .  |  Domain 4   |
  |+---+   +---+|     |+---+   +---+|  .  |+---+   +---+|
  || ===/~/======/~~~/================================ ||
  |+-*-+   +---+|     |+---+   +---+|  .  |+---+   +-*-+|
  |  *          |     +-------------+  .  |          *  |
  |  *          |                      .  |          *  |
  |  *          |     +-------------+  .  |          *  |
  |  *          |     |  Domain 3   &lt;...  |          *  |
  |+-*-+   +---+|     |+---+   +---+|     |+---+   +-*-+|
  || ************************************************* ||
  |+---+   +---+|     |+---+   +---+|     |+---+   +---+|
  +-------------+     +-------------+     +-------------+

  ====: Working LSP   ****: Protecting LSP   /~/: Failure
</artwork>
              </figure>
            </li>
            <li pn="section-8.4.4-4.2" derivedCounter="2)">
              <t indent="0" pn="section-8.4.4-4.2.1">Domain segment rerouting:</t>
              <ol type="2.%d)" indent="adaptive" spacing="normal" start="1" pn="section-8.4.4-4.2.2">
<li pn="section-8.4.4-4.2.2.1" derivedCounter="2.1)">
                  <t indent="0" pn="section-8.4.4-4.2.2.1.1">Intra-domain rerouting:</t>
                  <t indent="0" pn="section-8.4.4-4.2.2.1.2"> If failure occurs on the working LSP segment in a GMPLS domain, the
segment rerouting <xref target="RFC4873" format="default" sectionFormat="of" derivedContent="RFC4873"/> could be used for the working LSP
segment in that GMPLS domain. <xref target="fig6" format="default" sectionFormat="of" derivedContent="Figure 6"/> shows an example of
intra-domain rerouting.</t>
                  <t indent="0" pn="section-8.4.4-4.2.2.1.3">The intra-domain rerouting of a non-GMPLS domain is out of scope of this
document.</t>
                  <figure anchor="fig6" align="left" suppress-title="false" pn="figure-6">
                    <name slugifiedName="name-intra-domain-segment-rerout">Intra-Domain Segment Rerouting</name>
                    <artwork align="left" pn="section-8.4.4-4.2.2.1.4.1">
                    +----------------+
                    |Orchestrator(MD)|
                    +-------.--------+
       ............................................
       .             .              .             .
  +----V-----+  +----V-----+   +----V-----+  +----V-----+
  |Controller|  |Controller|   |Controller|  |Controller|
  |  (G) 1   |  |(G)/(N) 2 |   |(G)/(N) 3 |  |(G)/(N) 4 |
  +----.-----+  +-------.--+   +-------.--+  +----.-----+
       .                .              .          .
  +----V--------+     +-V-----------+  .  +-------V-----+
  |  Domain 1   |     |  Domain 2   |  .  |  Domain 4   |
  |+---+   +---+|     |+---+   +---+|  .  |+---+   +---+|
  || ===/~/=========================================== ||
  |+-*-+   +-*-+|     |+---+   +---+|  .  |+---+   +---+|
  |  *       *  |     +-------------+  .  |             |
  |  *       *  |                      .  |             |
  |  *       *  |     +-------------+  .  |             |
  |  *       *  |     |  Domain 3   &lt;...  |             |
  |+-*-+   +-*-+|     |+---+   +---+|     |+---+   +---+|
  || ********* ||     ||   |   |   ||     ||   |   |   ||
  |+---+   +---+|     |+---+   +---+|     |+---+   +---+|
  +-------------+     +-------------+     +-------------+

====: Working LSP  ****: Rerouting LSP segment  /~/: Failure</artwork>
                  </figure>
                </li>
                <li pn="section-8.4.4-4.2.2.2" derivedCounter="2.2)">
                  <t indent="0" pn="section-8.4.4-4.2.2.2.1">Inter-domain rerouting:</t>
                  <t indent="0" pn="section-8.4.4-4.2.2.2.2">If intra-domain segment rerouting failed (e.g., due to lack of resource in
that domain), or if failure occurs on the working LSP on an inter-domain link,
the centralized controller system may coordinate with other domain(s) to find
an alternative path or path segment to bypass the failure and then trigger
the inter-domain rerouting procedure. Note that the rerouting path or path
segment may traverse different domains from the working LSP.</t>
                  <t indent="0" pn="section-8.4.4-4.2.2.2.3">The domains involved in the inter-domain rerouting procedure need to be
GMPLS domains, which support the RSVP-TE signaling for the creation of a 
rerouting LSP segment.</t>
                  <t indent="0" pn="section-8.4.4-4.2.2.2.4">For inter-domain rerouting, the interaction between GMPLS and a centralized
controller system is needed:</t>
                  <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8.4.4-4.2.2.2.5">
                    <li pn="section-8.4.4-4.2.2.2.5.1">
                      <t indent="0" pn="section-8.4.4-4.2.2.2.5.1.1">A report of the result of intra-domain segment rerouting to its
Controller(G) and then to the Orchestrator(MD). The former could be supported
by the PCRpt message in <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, while the latter could be
supported by the MPI of ACTN.</t>
                    </li>
                    <li pn="section-8.4.4-4.2.2.2.5.2">
                      <t indent="0" pn="section-8.4.4-4.2.2.2.5.2.1">A report of inter-domain link failure to the two Controllers (e.g.,
Controller(G) 1 and Controller(G) 2 in <xref target="fig7" format="default" sectionFormat="of" derivedContent="Figure 7"/>) by which the two
ends of the inter-domain link are controlled, respectively, and then to the
Orchestrator(MD). The former could be done as described in <xref target="top-collection-synch" format="default" sectionFormat="of" derivedContent="Section 8.1"/>, while the latter could be supported by
the MPI of ACTN.</t>
                    </li>
                    <li pn="section-8.4.4-4.2.2.2.5.3">
                      <t indent="0" pn="section-8.4.4-4.2.2.2.5.3.1">The computation of a rerouting path or path segment crossing multi-domains by
the centralized controller system (see <xref target="I-D.ietf-teas-yang-path-computation" format="default" sectionFormat="of" derivedContent="PATH-COMP"/>);</t>
                    </li>
                    <li pn="section-8.4.4-4.2.2.2.5.4">
                      <t indent="0" pn="section-8.4.4-4.2.2.2.5.4.1">The creation of a rerouting LSP segment in each related domain. The
Orchestrator(MD) can send the LSP segment rerouting request to the source
Controller(G) (e.g., Controller(G) 1 in <xref target="fig7" format="default" sectionFormat="of" derivedContent="Figure 7"/>) via MPI
interface, and then the Controller(G) can trigger the creation of a rerouting
LSP segment through multiple GMPLS domains using GMPLS rerouting
signaling. Note that the rerouting LSP segment may traverse a new domain that
the working LSP does not traverse (e.g., Domain 3 in <xref target="fig7" format="default" sectionFormat="of" derivedContent="Figure 7"/>).</t>
                    </li>
                  </ul>
                  <figure anchor="fig7" align="left" suppress-title="false" pn="figure-7">
                    <name slugifiedName="name-inter-domain-segment-rerout">Inter-Domain Segment Rerouting </name>
                    <artwork align="left" pn="section-8.4.4-4.2.2.2.6.1">
                         +----------------+
                         |Orchestrator(MD)|
                         +-------.--------+
        ..................................................
        .               .                .               .
  +-----V------+  +-----V------+   +-----V------+  +-----V------+
  | Controller |  | Controller |   | Controller |  | Controller |
  |   (G) 1    |  |   (G) 2    |   |   (G) 3    |  | (G)/(N) 4  |
  +-----.------+  +------.-----+   +-----.------+  +-----.------+
        .                .               .               .
  +-----V-------+   +----V--------+      .        +------V------+
  |  Domain 1   |   |  Domain 2   |      .        |  Domain 4   |
  |+---+   +---+|   |+---+   +---+|      .        |+---+   +---+|
  ||   |   |   ||   ||   |   |   ||      .        ||   |   |   ||
  || ============/~/========================================== ||
  || * |   |   ||   ||   |   | * ||      .        ||   |   |   ||
  |+-*-+   +---+|   |+---+   +-*-+|      .        |+---+   +---+|
  |  *          |   +----------*--+      .        |             |
  |  *          |              *****     .        |             |
  |  *          |       +----------*-----V----+   |             |
  |  *          |       |          *Domain 3  |   |             |
  |+-*-+   +---+|       |+---+   +-*-+   +---+|   |+---+   +---+|
  || * |   |   ||       ||   |   | * |   |   ||   ||   |   |   ||
  || ******************************* |   |   ||   ||   |   |   ||
  ||   |   |   ||       ||   |   |   |   |   ||   ||   |   |   ||
  |+---+   +---+|       |+---+   +---+   +---+|   |+---+   +---+|
  +-------------+       +---------------------+   +-------------+

   ====: Working LSP  ****: Rerouting LSP segment  /~/: Failure</artwork>
                  </figure>
                </li>
              </ol>
            </li>
          </ol>
        </section>
        <section anchor="fast-reroute" numbered="true" removeInRFC="false" toc="include" pn="section-8.4.5">
          <name slugifiedName="name-fast-reroute">Fast Reroute</name>
          <t indent="0" pn="section-8.4.5-1">
   <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> defines two methods of fast reroute: the one-to-one backup
   method and the facility backup method. For both methods:</t>
          <ol spacing="normal" type="%d)" indent="adaptive" start="1" pn="section-8.4.5-2">
  <li pn="section-8.4.5-2.1" derivedCounter="1)">
              <t indent="0" pn="section-8.4.5-2.1.1">Path computation of protecting LSP:</t>
              <t indent="0" pn="section-8.4.5-2.1.2"> In <xref target="RFC4090" sectionFormat="of" section="6.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4090#section-6.2" derivedContent="RFC4090"/>, the
    protecting LSP (detour LSP in one-to-one backup or bypass tunnel in
    facility backup) could be computed by the Point of Local Repair (PLR)
    using, for example, a Constrained Shortest Path First (CSPF)
    computation. In the scenario of interworking between GMPLS and a centralized
    controller system, the protecting LSP could also be computed by the
    centralized controller system, as it has the global view of the network
    topology, resources, and information of LSPs.</t>
            </li>
            <li pn="section-8.4.5-2.2" derivedCounter="2)">
              <t indent="0" pn="section-8.4.5-2.2.1">Protecting LSP creation:</t>
              <t indent="0" pn="section-8.4.5-2.2.2"> In the scenario of interworking between GMPLS and a centralized
    controller system, the protecting LSP could still be created by the
    RSVP-TE signaling protocol as described in <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> and
    <xref target="RFC8271" format="default" sectionFormat="of" derivedContent="RFC8271"/>.</t>
              <t indent="0" pn="section-8.4.5-2.2.3">In addition, if the protecting LSP is computed by the centralized
    controller system, the Secondary Explicit Route Object defined in <xref target="RFC4873" format="default" sectionFormat="of" derivedContent="RFC4873"/> could be used to explicitly indicate the route of the
    protecting LSP.</t>
            </li>
            <li pn="section-8.4.5-2.3" derivedCounter="3)">
              <t indent="0" pn="section-8.4.5-2.3.1">Failure detection and traffic switchover:</t>
              <t indent="0" pn="section-8.4.5-2.3.2">If a PLR detects that failure occurs, it may significantly shorten the
    protection switching time by using the distributed mechanisms described in
    <xref target="RFC4090" format="default" sectionFormat="of" derivedContent="RFC4090"/> to switch the traffic to the related detour LSP
    or bypass tunnel rather than doing so in a centralized way.</t>
            </li>
          </ol>
        </section>
      </section>
      <section anchor="controller-reliability" numbered="true" removeInRFC="false" toc="include" pn="section-8.5">
        <name slugifiedName="name-controller-reliability">Controller Reliability</name>
        <t indent="0" pn="section-8.5-1">
   The reliability of the controller is crucial due to its important
   role in the network. It is essential that if the controller is shut
   down or disconnected from the network, all currently provisioned
   services in the network continue to function and carry traffic. In
   addition, protection switching to pre-established paths should also
   work. It is desirable to have protection mechanisms, such as
   redundancy, to maintain full operational control even if one
   instance of the controller fails. This can be achieved through
   controller backup or functionality backup. There are several
   controller backup or federation mechanisms in the literature. It is
   also more reliable to have function backup in the network element to
   guarantee performance in the network.</t>
      </section>
    </section>
    <section anchor="manageability-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t indent="0" pn="section-9-1">
   Each network entity, including controllers and network elements,
   should be managed properly and with the relevant trust and security
   policies applied (see <xref target="sec-cons" format="default" sectionFormat="of" derivedContent="Section 10"/>), as they will
   interact with other entities. The manageability considerations in
   controller hierarchies and network elements still apply,
   respectively. The overall manageability of the protocols applied in
   the network should also be a key consideration.</t>
      <t indent="0" pn="section-9-2">
   The responsibility of each entity should be clarified. The control
   of function and policy among different controllers should be
   consistent via a proper negotiation process.</t>
    </section>
    <section anchor="sec-cons" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">
   This document outlines the interworking between GMPLS and controller
   hierarchies. The security requirements specific to both systems
   remain applicable. Protocols referenced herein possess security
   considerations, which must be adhered to, with their core
   specifications and identified risks detailed earlier in this
   document.</t>
      <t indent="0" pn="section-10-2">
   Security is a critical aspect in both GMPLS and controller-based
   networks. Ensuring robust security mechanisms in these environments
   is paramount to safeguard against potential threats and
   vulnerabilities. Below are expanded security considerations and some
   relevant IETF RFC references.</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10-3">
        <li pn="section-10-3.1">
          <t indent="0" pn="section-10-3.1.1">Authentication and Authorization: It is essential to
	implement strong authentication and authorization mechanisms to
	control access to the controller from multiple network elements. This
	ensures that only authorized devices and users can interact with the
	controller, preventing unauthorized access that could lead to network
	disruptions or data breaches.  "<xref target="RFC8446" format="title" sectionFormat="of" derivedContent="The Transport Layer Security (TLS) Protocol Version 1.3"/>" <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> and "<xref target="RFC7030" format="title" sectionFormat="of" derivedContent="Enrollment over Secure Transport"/>" <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> provide guidelines on
	secure communication and certificate-based authentication that can be
	leveraged for these purposes.</t>
        </li>
        <li pn="section-10-3.2">
          <t indent="0" pn="section-10-3.2.1">Controller Security: The controller's security is crucial as it
	serves as the central control point for the network elements. The
	controller must be protected against various attacks, such as
	Denial of Service (DoS), Man in the Middle (MITM), and unauthorized
	access. Security mechanisms should include regular security audits,
	application of security patches, firewalls, and Intrusion
	Detection Systems (IDSs) / Intrusion Prevention Systems (IPSs).</t>
        </li>
        <li pn="section-10-3.3">
          <t indent="0" pn="section-10-3.3.1">Data Transport Security: Security mechanisms on the controller
	should also safeguard the underlying network elements against
	unauthorized usage of data transport resources. This includes
	encryption of data in transit to prevent eavesdropping and tampering
	as well as ensuring data integrity and confidentiality.</t>
        </li>
        <li pn="section-10-3.4">
          <t indent="0" pn="section-10-3.4.1">Secure Protocol Implementation: Protocols used within the GMPLS
	and controller frameworks must be implemented with security in
	mind. Known vulnerabilities should be addressed, and secure versions
	of protocols should be used wherever possible.</t>
        </li>
      </ul>
      <t indent="0" pn="section-10-4">
   Finally, robust network security often depends on Indicators of
   Compromise (IoCs) to detect, trace, and prevent malicious activities
   in networks or endpoints. These are described in <xref target="RFC9424" format="default" sectionFormat="of" derivedContent="RFC9424"/> along
   with the fundamentals, opportunities, operational limitations, and
   recommendations for IoC use.</t>
    </section>
    <section anchor="iana-cons" numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-11-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-pce-pcep-ls" to="PCEP-LS"/>
    <displayreference target="I-D.ietf-teas-yang-te" to="YANG-TE"/>
    <displayreference target="I-D.ietf-teas-yang-path-computation" to="PATH-COMP"/>
    <displayreference target="I-D.ietf-pce-stateful-interdomain" to="SPCE-ID"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author fullname="D. Awduche" initials="D." surname="Awduche"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="D. Gan" initials="D." surname="Gan"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <date month="December" year="2001"/>
            <abstract>
              <t indent="0">This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC3473" target="https://www.rfc-editor.org/info/rfc3473" quoteTitle="true" derivedAnchor="RFC3473">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="January" year="2003"/>
            <abstract>
              <t indent="0">This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3473"/>
          <seriesInfo name="DOI" value="10.17487/RFC3473"/>
        </reference>
        <reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3630" quoteTitle="true" derivedAnchor="RFC3630">
          <front>
            <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="D. Yeung" initials="D." surname="Yeung"/>
            <date month="September" year="2003"/>
            <abstract>
              <t indent="0">This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3630"/>
          <seriesInfo name="DOI" value="10.17487/RFC3630"/>
        </reference>
        <reference anchor="RFC3945" target="https://www.rfc-editor.org/info/rfc3945" quoteTitle="true" derivedAnchor="RFC3945">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Architecture</title>
            <author fullname="E. Mannie" initials="E." role="editor" surname="Mannie"/>
            <date month="October" year="2004"/>
            <abstract>
              <t indent="0">Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.</t>
              <t indent="0">This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3945"/>
          <seriesInfo name="DOI" value="10.17487/RFC3945"/>
        </reference>
        <reference anchor="RFC4090" target="https://www.rfc-editor.org/info/rfc4090" quoteTitle="true" derivedAnchor="RFC4090">
          <front>
            <title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
            <author fullname="P. Pan" initials="P." role="editor" surname="Pan"/>
            <author fullname="G. Swallow" initials="G." role="editor" surname="Swallow"/>
            <author fullname="A. Atlas" initials="A." role="editor" surname="Atlas"/>
            <date month="May" year="2005"/>
            <abstract>
              <t indent="0">This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.</t>
              <t indent="0">Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4090"/>
          <seriesInfo name="DOI" value="10.17487/RFC4090"/>
        </reference>
        <reference anchor="RFC4203" target="https://www.rfc-editor.org/info/rfc4203" quoteTitle="true" derivedAnchor="RFC4203">
          <front>
            <title>OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4203"/>
          <seriesInfo name="DOI" value="10.17487/RFC4203"/>
        </reference>
        <reference anchor="RFC4206" target="https://www.rfc-editor.org/info/rfc4206" quoteTitle="true" derivedAnchor="RFC4206">
          <front>
            <title>Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).</t>
              <t indent="0">This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4206"/>
          <seriesInfo name="DOI" value="10.17487/RFC4206"/>
        </reference>
        <reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655" quoteTitle="true" derivedAnchor="RFC4655">
          <front>
            <title>A Path Computation Element (PCE)-Based Architecture</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur"/>
            <author fullname="J. Ash" initials="J." surname="Ash"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
              <t indent="0">This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4655"/>
          <seriesInfo name="DOI" value="10.17487/RFC4655"/>
        </reference>
        <reference anchor="RFC4872" target="https://www.rfc-editor.org/info/rfc4872" quoteTitle="true" derivedAnchor="RFC4872">
          <front>
            <title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery</title>
            <author fullname="J.P. Lang" initials="J.P." role="editor" surname="Lang"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
            <date month="May" year="2007"/>
            <abstract>
              <t indent="0">This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4872"/>
          <seriesInfo name="DOI" value="10.17487/RFC4872"/>
        </reference>
        <reference anchor="RFC4873" target="https://www.rfc-editor.org/info/rfc4873" quoteTitle="true" derivedAnchor="RFC4873">
          <front>
            <title>GMPLS Segment Recovery</title>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
            <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="May" year="2007"/>
            <abstract>
              <t indent="0">This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4873"/>
          <seriesInfo name="DOI" value="10.17487/RFC4873"/>
        </reference>
        <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305" quoteTitle="true" derivedAnchor="RFC5305">
          <front>
            <title>IS-IS Extensions for Traffic Engineering</title>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="H. Smit" initials="H." surname="Smit"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5305"/>
          <seriesInfo name="DOI" value="10.17487/RFC5305"/>
        </reference>
        <reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5307" quoteTitle="true" derivedAnchor="RFC5307">
          <front>
            <title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5307"/>
          <seriesInfo name="DOI" value="10.17487/RFC5307"/>
        </reference>
        <reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5440" quoteTitle="true" derivedAnchor="RFC5440">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
            <date month="March" year="2009"/>
            <abstract>
              <t indent="0">This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC6001" target="https://www.rfc-editor.org/info/rfc6001" quoteTitle="true" derivedAnchor="RFC6001">
          <front>
            <title>Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)</title>
            <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
            <author fullname="M. Vigoureux" initials="M." surname="Vigoureux"/>
            <author fullname="K. Shiomoto" initials="K." surname="Shiomoto"/>
            <author fullname="D. Brungard" initials="D." surname="Brungard"/>
            <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
            <date month="October" year="2010"/>
            <abstract>
              <t indent="0">There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).</t>
              <t indent="0">This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6001"/>
          <seriesInfo name="DOI" value="10.17487/RFC6001"/>
        </reference>
        <reference anchor="RFC6107" target="https://www.rfc-editor.org/info/rfc6107" quoteTitle="true" derivedAnchor="RFC6107">
          <front>
            <title>Procedures for Dynamically Signaled Hierarchical Label Switched Paths</title>
            <author fullname="K. Shiomoto" initials="K." role="editor" surname="Shiomoto"/>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <date month="February" year="2011"/>
            <abstract>
              <t indent="0">Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.</t>
              <t indent="0">Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6107"/>
          <seriesInfo name="DOI" value="10.17487/RFC6107"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7030" quoteTitle="true" derivedAnchor="RFC7030">
          <front>
            <title>Enrollment over Secure Transport</title>
            <author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin"/>
            <author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
            <author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/>
            <date month="October" year="2013"/>
            <abstract>
              <t indent="0">This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7030"/>
          <seriesInfo name="DOI" value="10.17487/RFC7030"/>
        </reference>
        <reference anchor="RFC7074" target="https://www.rfc-editor.org/info/rfc7074" quoteTitle="true" derivedAnchor="RFC7074">
          <front>
            <title>Revised Definition of the GMPLS Switching Capability and Type Fields</title>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <author fullname="J. Meuric" initials="J." surname="Meuric"/>
            <date month="November" year="2013"/>
            <abstract>
              <t indent="0">GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7074"/>
          <seriesInfo name="DOI" value="10.17487/RFC7074"/>
        </reference>
        <reference anchor="RFC7491" target="https://www.rfc-editor.org/info/rfc7491" quoteTitle="true" derivedAnchor="RFC7491">
          <front>
            <title>A PCE-Based Architecture for Application-Based Network Operations</title>
            <author fullname="D. King" initials="D." surname="King"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.</t>
              <t indent="0">This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7491"/>
          <seriesInfo name="DOI" value="10.17487/RFC7491"/>
        </reference>
        <reference anchor="RFC7926" target="https://www.rfc-editor.org/info/rfc7926" quoteTitle="true" derivedAnchor="RFC7926">
          <front>
            <title>Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks</title>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <author fullname="X. Zhang" initials="X." surname="Zhang"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.</t>
              <t indent="0">In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.</t>
              <t indent="0">This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="206"/>
          <seriesInfo name="RFC" value="7926"/>
          <seriesInfo name="DOI" value="10.17487/RFC7926"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8271" target="https://www.rfc-editor.org/info/rfc8271" quoteTitle="true" derivedAnchor="RFC8271">
          <front>
            <title>Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)</title>
            <author fullname="M. Taillon" initials="M." surname="Taillon"/>
            <author fullname="T. Saad" initials="T." role="editor" surname="Saad"/>
            <author fullname="R. Gandhi" initials="R." role="editor" surname="Gandhi"/>
            <author fullname="Z. Ali" initials="Z." surname="Ali"/>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8271"/>
          <seriesInfo name="DOI" value="10.17487/RFC8271"/>
        </reference>
        <reference anchor="RFC8282" target="https://www.rfc-editor.org/info/rfc8282" quoteTitle="true" derivedAnchor="RFC8282">
          <front>
            <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering</title>
            <author fullname="E. Oki" initials="E." surname="Oki"/>
            <author fullname="T. Takeda" initials="T." surname="Takeda"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="F. Zhang" initials="F." surname="Zhang"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</t>
              <t indent="0">MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.</t>
              <t indent="0">The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8282"/>
          <seriesInfo name="DOI" value="10.17487/RFC8282"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8453" target="https://www.rfc-editor.org/info/rfc8453" quoteTitle="true" derivedAnchor="RFC8453">
          <front>
            <title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
            <author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</t>
              <t indent="0">Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</t>
              <t indent="0">This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8453"/>
          <seriesInfo name="DOI" value="10.17487/RFC8453"/>
        </reference>
        <reference anchor="RFC8685" target="https://www.rfc-editor.org/info/rfc8685" quoteTitle="true" derivedAnchor="RFC8685">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture</title>
            <author fullname="F. Zhang" initials="F." surname="Zhang"/>
            <author fullname="Q. Zhao" initials="Q." surname="Zhao"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="R. Casellas" initials="R." surname="Casellas"/>
            <author fullname="D. King" initials="D." surname="King"/>
            <date month="December" year="2019"/>
            <abstract>
              <t indent="0">The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.</t>
              <t indent="0">This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8685"/>
          <seriesInfo name="DOI" value="10.17487/RFC8685"/>
        </reference>
        <reference anchor="RFC8795" target="https://www.rfc-editor.org/info/rfc8795" quoteTitle="true" derivedAnchor="RFC8795">
          <front>
            <title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
            <author fullname="V. Beeram" initials="V." surname="Beeram"/>
            <author fullname="T. Saad" initials="T." surname="Saad"/>
            <author fullname="H. Shah" initials="H." surname="Shah"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <date month="August" year="2020"/>
            <abstract>
              <t indent="0">This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8795"/>
          <seriesInfo name="DOI" value="10.17487/RFC8795"/>
        </reference>
        <reference anchor="RFC9424" target="https://www.rfc-editor.org/info/rfc9424" quoteTitle="true" derivedAnchor="RFC9424">
          <front>
            <title>Indicators of Compromise (IoCs) and Their Role in Attack Defence</title>
            <author fullname="K. Paine" initials="K." surname="Paine"/>
            <author fullname="O. Whitehouse" initials="O." surname="Whitehouse"/>
            <author fullname="J. Sellwood" initials="J." surname="Sellwood"/>
            <author fullname="A. Shaw" initials="A." surname="Shaw"/>
            <date month="August" year="2023"/>
            <abstract>
              <t indent="0">Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9424"/>
          <seriesInfo name="DOI" value="10.17487/RFC9424"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="G.808.1" target="https://www.itu.int/rec/T-REC-G.808.1-201405-I/en" quoteTitle="true" derivedAnchor="G.808.1">
          <front>
            <title>Generic protection switching - Linear trail and subnetwork protection</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="May" year="2014"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.808.1"/>
        </reference>
        <reference anchor="I-D.ietf-teas-yang-path-computation" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-24" quoteTitle="true" derivedAnchor="PATH-COMP">
          <front>
            <title>A YANG Data Model for requesting path computation</title>
            <author initials="I." surname="Busi" fullname="Italo Busi">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="S." surname="Belotti" fullname="Sergio Belotti">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author initials="O. G." surname="de Dios" fullname="Oscar Gonzalez de Dios">
              <organization showOnFrontPage="true">Telefonica</organization>
            </author>
            <author initials="A." surname="Sharma" fullname="Anurag Sharma">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="Y." surname="Shi" fullname="Yan Shi">
              <organization showOnFrontPage="true">China Unicom</organization>
            </author>
            <date month="February" day="13" year="2025"/>
            <abstract>
              <t indent="0">   There are scenarios, typically in a hierarchical Software-Defined
   Networking (SDN) context, where the topology information provided by
   a Traffic Engineering (TE) network provider may be insufficient for
   its client to perform multi-domain path computation.  In these cases
   the client would need to request the TE network provider to compute
   some intra-domain paths to be used by the client to choose the
   optimal multi-domain paths.

   This document provides a mechanism to request path computation by
   augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY.

   [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of
   draft-ietf-teas-yang-te once it has been published.

   Moreover, this document describes some use cases where the path
   computation request, via YANG-based protocols (e.g., NETCONF or
   RESTCONF), can be needed.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-path-computation-24"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-pce-pcep-ls" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-ls-02" quoteTitle="true" derivedAnchor="PCEP-LS">
          <front>
            <title>PCEP extensions for Distribution of Link-State and TE Information</title>
            <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="S." surname="Peng" fullname="Shuping Peng">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="Y." surname="Lee" fullname="Young Lee">
              <organization showOnFrontPage="true">Samsung Electronics</organization>
            </author>
            <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <author initials="A." surname="Wang" fullname="Aijun Wang">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="G. S." surname="Mishra" fullname="Gyan Mishra">
              <organization showOnFrontPage="true">Verizon Inc.</organization>
            </author>
            <date month="October" day="20" year="2024"/>
            <abstract>
              <t indent="0">   In order to compute and provide optimal paths, Path Computation
   Elements (PCEs) require an accurate and timely Traffic Engineering
   Database (TED).  Traditionally, this TED has been obtained from a
   link state (LS) routing protocol supporting the traffic engineering
   extensions.

   This document extends the Path Computation Element Communication
   Protocol (PCEP) with Link-State and TE Information as an experimental
   extension to allow gathering more deployment and implementation
   feedback on the use of PCEP in this way.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-ls-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3471" target="https://www.rfc-editor.org/info/rfc3471" quoteTitle="true" derivedAnchor="RFC3471">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="January" year="2003"/>
            <abstract>
              <t indent="0">This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3471"/>
          <seriesInfo name="DOI" value="10.17487/RFC3471"/>
        </reference>
        <reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202" quoteTitle="true" derivedAnchor="RFC4202">
          <front>
            <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4202"/>
          <seriesInfo name="DOI" value="10.17487/RFC4202"/>
        </reference>
        <reference anchor="RFC4204" target="https://www.rfc-editor.org/info/rfc4204" quoteTitle="true" derivedAnchor="RFC4204">
          <front>
            <title>Link Management Protocol (LMP)</title>
            <author fullname="J. Lang" initials="J." role="editor" surname="Lang"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4204"/>
          <seriesInfo name="DOI" value="10.17487/RFC4204"/>
        </reference>
        <reference anchor="RFC4426" target="https://www.rfc-editor.org/info/rfc4426" quoteTitle="true" derivedAnchor="RFC4426">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification</title>
            <author fullname="J. Lang" initials="J." role="editor" surname="Lang"/>
            <author fullname="B. Rajagopalan" initials="B." role="editor" surname="Rajagopalan"/>
            <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
            <date month="March" year="2006"/>
            <abstract>
              <t indent="0">This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4426"/>
          <seriesInfo name="DOI" value="10.17487/RFC4426"/>
        </reference>
        <reference anchor="RFC5150" target="https://www.rfc-editor.org/info/rfc5150" quoteTitle="true" derivedAnchor="RFC5150">
          <front>
            <title>Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)</title>
            <author fullname="A. Ayyangar" initials="A." surname="Ayyangar"/>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="February" year="2008"/>
            <abstract>
              <t indent="0">In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).</t>
              <t indent="0">This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.</t>
              <t indent="0">It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5150"/>
          <seriesInfo name="DOI" value="10.17487/RFC5150"/>
        </reference>
        <reference anchor="RFC5212" target="https://www.rfc-editor.org/info/rfc5212" quoteTitle="true" derivedAnchor="RFC5212">
          <front>
            <title>Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)</title>
            <author fullname="K. Shiomoto" initials="K." surname="Shiomoto"/>
            <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
            <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
            <author fullname="M. Vigoureux" initials="M." surname="Vigoureux"/>
            <author fullname="D. Brungard" initials="D." surname="Brungard"/>
            <date month="July" year="2008"/>
            <abstract>
              <t indent="0">Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.</t>
              <t indent="0">In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5212"/>
          <seriesInfo name="DOI" value="10.17487/RFC5212"/>
        </reference>
        <reference anchor="RFC5441" target="https://www.rfc-editor.org/info/rfc5441" quoteTitle="true" derivedAnchor="RFC5441">
          <front>
            <title>A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="R. Zhang" initials="R." surname="Zhang"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
            <date month="April" year="2009"/>
            <abstract>
              <t indent="0">The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5441"/>
          <seriesInfo name="DOI" value="10.17487/RFC5441"/>
        </reference>
        <reference anchor="RFC5623" target="https://www.rfc-editor.org/info/rfc5623" quoteTitle="true" derivedAnchor="RFC5623">
          <front>
            <title>Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering</title>
            <author fullname="E. Oki" initials="E." surname="Oki"/>
            <author fullname="T. Takeda" initials="T." surname="Takeda"/>
            <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.</t>
              <t indent="0">This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5623"/>
          <seriesInfo name="DOI" value="10.17487/RFC5623"/>
        </reference>
        <reference anchor="RFC5654" target="https://www.rfc-editor.org/info/rfc5654" quoteTitle="true" derivedAnchor="RFC5654">
          <front>
            <title>Requirements of an MPLS Transport Profile</title>
            <author fullname="B. Niven-Jenkins" initials="B." role="editor" surname="Niven-Jenkins"/>
            <author fullname="D. Brungard" initials="D." role="editor" surname="Brungard"/>
            <author fullname="M. Betts" initials="M." role="editor" surname="Betts"/>
            <author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
            <author fullname="S. Ueno" initials="S." surname="Ueno"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).</t>
              <t indent="0">This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.</t>
              <t indent="0">The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5654"/>
          <seriesInfo name="DOI" value="10.17487/RFC5654"/>
        </reference>
        <reference anchor="RFC7138" target="https://www.rfc-editor.org/info/rfc7138" quoteTitle="true" derivedAnchor="RFC7138">
          <front>
            <title>Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks</title>
            <author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
            <author fullname="F. Zhang" initials="F." surname="Zhang"/>
            <author fullname="S. Belotti" initials="S." surname="Belotti"/>
            <author fullname="R. Rao" initials="R." surname="Rao"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <date month="March" year="2014"/>
            <abstract>
              <t indent="0">This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7138"/>
          <seriesInfo name="DOI" value="10.17487/RFC7138"/>
        </reference>
        <reference anchor="RFC7139" target="https://www.rfc-editor.org/info/rfc7139" quoteTitle="true" derivedAnchor="RFC7139">
          <front>
            <title>GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks</title>
            <author fullname="F. Zhang" initials="F." role="editor" surname="Zhang"/>
            <author fullname="G. Zhang" initials="G." surname="Zhang"/>
            <author fullname="S. Belotti" initials="S." surname="Belotti"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <author fullname="K. Pithewan" initials="K." surname="Pithewan"/>
            <date month="March" year="2014"/>
            <abstract>
              <t indent="0">ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.</t>
              <t indent="0">This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7139"/>
          <seriesInfo name="DOI" value="10.17487/RFC7139"/>
        </reference>
        <reference anchor="RFC7271" target="https://www.rfc-editor.org/info/rfc7271" quoteTitle="true" derivedAnchor="RFC7271">
          <front>
            <title>MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators</title>
            <author fullname="J. Ryoo" initials="J." role="editor" surname="Ryoo"/>
            <author fullname="E. Gray" initials="E." role="editor" surname="Gray"/>
            <author fullname="H. van Helvoort" initials="H." surname="van Helvoort"/>
            <author fullname="A. D'Alessandro" initials="A." surname="D'Alessandro"/>
            <author fullname="T. Cheung" initials="T." surname="Cheung"/>
            <author fullname="E. Osborne" initials="E." surname="Osborne"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.</t>
              <t indent="0">This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.</t>
              <t indent="0">This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.</t>
              <t indent="0">This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7271"/>
          <seriesInfo name="DOI" value="10.17487/RFC7271"/>
        </reference>
        <reference anchor="RFC7688" target="https://www.rfc-editor.org/info/rfc7688" quoteTitle="true" derivedAnchor="RFC7688">
          <front>
            <title>GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks</title>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
            <author fullname="G. Bernstein" initials="G." role="editor" surname="Bernstein"/>
            <date month="November" year="2015"/>
            <abstract>
              <t indent="0">This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.</t>
              <t indent="0">This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7688"/>
          <seriesInfo name="DOI" value="10.17487/RFC7688"/>
        </reference>
        <reference anchor="RFC7689" target="https://www.rfc-editor.org/info/rfc7689" quoteTitle="true" derivedAnchor="RFC7689">
          <front>
            <title>Signaling Extensions for Wavelength Switched Optical Networks</title>
            <author fullname="G. Bernstein" initials="G." role="editor" surname="Bernstein"/>
            <author fullname="S. Xu" initials="S." surname="Xu"/>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
            <author fullname="G. Martinelli" initials="G." surname="Martinelli"/>
            <author fullname="H. Harai" initials="H." surname="Harai"/>
            <date month="November" year="2015"/>
            <abstract>
              <t indent="0">This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7689"/>
          <seriesInfo name="DOI" value="10.17487/RFC7689"/>
        </reference>
        <reference anchor="RFC7792" target="https://www.rfc-editor.org/info/rfc7792" quoteTitle="true" derivedAnchor="RFC7792">
          <front>
            <title>RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks</title>
            <author fullname="F. Zhang" initials="F." surname="Zhang"/>
            <author fullname="X. Zhang" initials="X." surname="Zhang"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7792"/>
          <seriesInfo name="DOI" value="10.17487/RFC7792"/>
        </reference>
        <reference anchor="RFC8231" target="https://www.rfc-editor.org/info/rfc8231" quoteTitle="true" derivedAnchor="RFC8231">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="September" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t indent="0">Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8231"/>
          <seriesInfo name="DOI" value="10.17487/RFC8231"/>
        </reference>
        <reference anchor="RFC8234" target="https://www.rfc-editor.org/info/rfc8234" quoteTitle="true" derivedAnchor="RFC8234">
          <front>
            <title>Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode</title>
            <author fullname="J. Ryoo" initials="J." surname="Ryoo"/>
            <author fullname="T. Cheung" initials="T." surname="Cheung"/>
            <author fullname="H. van Helvoort" initials="H." surname="van Helvoort"/>
            <author fullname="I. Busi" initials="I." surname="Busi"/>
            <author fullname="G. Wen" initials="G." surname="Wen"/>
            <date month="August" year="2017"/>
            <abstract>
              <t indent="0">This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8234"/>
          <seriesInfo name="DOI" value="10.17487/RFC8234"/>
        </reference>
        <reference anchor="RFC8281" target="https://www.rfc-editor.org/info/rfc8281" quoteTitle="true" derivedAnchor="RFC8281">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t indent="0">The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8281"/>
          <seriesInfo name="DOI" value="10.17487/RFC8281"/>
        </reference>
        <reference anchor="RFC8345" target="https://www.rfc-editor.org/info/rfc8345" quoteTitle="true" derivedAnchor="RFC8345">
          <front>
            <title>A YANG Data Model for Network Topologies</title>
            <author fullname="A. Clemm" initials="A." surname="Clemm"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <author fullname="N. Bahadur" initials="N." surname="Bahadur"/>
            <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8345"/>
          <seriesInfo name="DOI" value="10.17487/RFC8345"/>
        </reference>
        <reference anchor="RFC8363" target="https://www.rfc-editor.org/info/rfc8363" quoteTitle="true" derivedAnchor="RFC8363">
          <front>
            <title>GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks</title>
            <author fullname="X. Zhang" initials="X." surname="Zhang"/>
            <author fullname="H. Zheng" initials="H." surname="Zheng"/>
            <author fullname="R. Casellas" initials="R." surname="Casellas"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as "flexi-grid".</t>
              <t indent="0">Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8363"/>
          <seriesInfo name="DOI" value="10.17487/RFC8363"/>
        </reference>
        <reference anchor="I-D.ietf-pce-stateful-interdomain" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-interdomain-07" quoteTitle="true" derivedAnchor="SPCE-ID">
          <front>
            <title>PCEP Extension for Stateful Inter-Domain Tunnels</title>
            <author initials="O." surname="Dugeon" fullname="Olivier Dugeon">
              <organization showOnFrontPage="true">Orange Innovation</organization>
            </author>
            <author initials="J." surname="Meuric" fullname="Julien Meuric">
              <organization showOnFrontPage="true">Orange Innovation</organization>
            </author>
            <author initials="Y." surname="Lee" fullname="Young Lee">
              <organization showOnFrontPage="true">Samsung Electronics</organization>
            </author>
            <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <date month="March" day="3" year="2025"/>
            <abstract>
              <t indent="0">   This document specifies how to use a Backward Recursive or
   Hierarchical method to derive inter-domain paths in the context of
   stateful Path Computation Element (PCE).  The mechanism relies on the
   PCInitiate message to set up independent paths per domain.  Combining
   these different paths together enables them to be operated as end-to-
   end inter-domain paths, without the need for a signaling session
   between inter-domain border routers.  It delivers a new tool in the
   PCE toolbox in order for operator to build Intent-Based Networking.
   For this purpose, this document defines a new Stitching Label, new
   Association Type, new PCEP communication Protocol (PCEP) Capability,
   new PCE Errors Type and new PCE Notifications Type.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-stateful-interdomain-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-teas-yang-te" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-37" quoteTitle="true" derivedAnchor="YANG-TE">
          <front>
            <title>A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces</title>
            <author initials="T." surname="Saad" fullname="Tarek Saad">
              <organization showOnFrontPage="true">Cisco Systems Inc</organization>
            </author>
            <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
              <organization showOnFrontPage="true">Cisco Systems Inc</organization>
            </author>
            <author initials="X." surname="Liu" fullname="Xufeng Liu">
              <organization showOnFrontPage="true">Alef Edge</organization>
            </author>
            <author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="I." surname="Bryskin" fullname="Igor Bryskin">
              <organization showOnFrontPage="true">Individual</organization>
            </author>
            <date month="October" day="9" year="2024"/>
            <abstract>
              <t indent="0">   This document defines a YANG data model for the provisioning and
   management of Traffic Engineering (TE) tunnels, Label Switched Paths
   (LSPs), and interfaces.  The model covers data that is independent of
   any technology or dataplane encapsulation and is divided into two
   YANG modules that cover device-specific, and device independent data.

   This model covers data for configuration, operational state, remote
   procedural calls, and event notifications.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-te-37"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="acks" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
   The authors would like to thank <contact fullname="Jim Guichard"/>, Area
   Director of IETF Routing Area; <contact fullname="Vishnu Pavan Beeram"/>,
   Chair of TEAS WG; <contact fullname="Jia He"/> and <contact fullname="Stewart Bryant"/>, RTGDIR reviewers; <contact fullname="Thomas    Fossati"/>, Gen-ART reviewer; <contact fullname="Yingzhen Qu"/>, OPSDIR
   reviewer; <contact fullname="David Mandelberg"/>, SECDIR reviewer; <contact fullname="David Dong"/>, IANA Services Sr. Specialist; and <contact fullname="Éric Vyncke"/> and <contact fullname="Murray Kucherawy"/>, IESG
   reviewers for their reviews and comments on this document.</t>
    </section>
    <section anchor="contribs" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Xianlong Luo">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>G1, Huawei Xiliu Beipo Village, Songshan Lake</street>
            <city>Dongguan</city>
            <region>Guangdong</region>
            <code>523808</code>
            <country>China</country>
          </postal>
          <email>luoxianlong@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Sergio Belotti">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>sergio.belotti@nokia.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="H." surname="Zheng" fullname="Haomian Zheng">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
            <city>Dongguan</city>
            <region>Guangdong</region>
            <code>523808</code>
            <country>China</country>
          </postal>
          <email>zhenghaomian@huawei.com</email>
        </address>
      </author>
      <author initials="Y." surname="Lin" fullname="Yi Lin">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
            <city>Dongguan</city>
            <region>Guangdong</region>
            <code>523808</code>
            <country>China</country>
          </postal>
          <email>yi.lin@huawei.com</email>
        </address>
      </author>
      <author initials="Y." surname="Zhao" fullname="Yang Zhao">
        <organization showOnFrontPage="true">China Mobile</organization>
        <address>
          <email>zhaoyangyjy@chinamobile.com</email>
        </address>
      </author>
      <author initials="Y." surname="Xu" fullname="Yunbin Xu">
        <organization showOnFrontPage="true">CAICT</organization>
        <address>
          <email>xuyunbin@caict.ac.cn</email>
        </address>
      </author>
      <author initials="D." surname="Beller" fullname="Dieter Beller">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>Dieter.Beller@nokia.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
