rfc9730.original   rfc9730.txt 
TEAS Working Group Haomian Zheng
Internet Draft Yi Lin
Category: Informational Huawei Technologies
Yang Zhao
China Mobile
Yunbin Xu
CAICT
Dieter Beller
Nokia
Expires: March 7, 2025 September 3, 2024
Interworking of GMPLS Control and Centralized Controller Systems Internet Engineering Task Force (IETF) H. Zheng
Request for Comments: 9730 Y. Lin
Category: Informational Huawei Technologies
ISSN: 2070-1721 Y. Zhao
China Mobile
Y. Xu
CAICT
D. Beller
Nokia
March 2025
draft-ietf-teas-gmpls-controller-inter-work-17 Interworking of GMPLS Control and Centralized Controller Systems
Abstract Abstract
Generalized Multi-Protocol Label Switching (GMPLS) control allows Generalized Multiprotocol Label Switching (GMPLS) control allows each
each network element (NE) to perform local resource discovery, network element (NE) to perform local resource discovery, routing,
routing and signaling in a distributed manner. and signaling in a distributed manner.
The advancement of software-defined transport networking technology The advancement of software-defined transport networking technology
enables a group of NEs to be managed through centralized controller enables a group of NEs to be managed through centralized controller
hierarchies. This helps to tackle challenges arising from multiple hierarchies. This helps to tackle challenges arising from multiple
domains, vendors, and technologies. An example of such a centralized domains, vendors, and technologies. An example of such a centralized
architecture is the Abstraction and Control of Traffic Engineered architecture is the Abstraction and Control of Traffic-Engineered
Networks (ACTN) controller hierarchy, as described in RFC 8453. Networks (ACTN) controller hierarchy, as described in RFC 8453.
Both the distributed and centralized control planes have their Both the distributed and centralized control planes have their
respective advantages and should complement each other in the respective advantages and should complement each other in the system,
system, rather than competing. This document outlines how the GMPLS rather than compete. This document outlines how the GMPLS
distributed control plane can work together with a centralized distributed control plane can work together with a centralized
controller system in a transport network. controller system in a transport network.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document is not an Internet Standards Track specification; it is
months and may be updated, replaced, or obsoleted by other documents published for informational purposes.
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on March 7, 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9730.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Revised BSD License text as described in Section 4.e of the
Section 4.e of the Trust Legal Provisions and are provided without Trust Legal Provisions and are provided without warranty as described
warranty as described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction ................................................... 3 1. Introduction
2. Abbreviations .................................................. 4 2. Abbreviations
3. Overview ....................................................... 5 3. Overview
3.1. Overview of GMPLS Control Plane ........................... 5 3.1. Overview of GMPLS Control Plane
3.2. Overview of Centralized Controller System ................. 5 3.2. Overview of Centralized Controller System
3.3. GMPLS Control Interworking with a Centralized Controller 3.3. GMPLS Control Interworking with a Centralized Controller
System ......................................................... 6 System
4. Discovery Options .............................................. 8 4. Discovery Options
4.1. LMP ....................................................... 8 4.1. LMP
5. Routing Options ................................................ 8 5. Routing Options
5.1. OSPF-TE ................................................... 9 5.1. OSPF-TE
5.2. IS-IS-TE .................................................. 9 5.2. IS-IS-TE
5.3. NETCONF/RESTCONF .......................................... 9 5.3. NETCONF/RESTCONF
6. Path Computation ............................................... 9 6. Path Computation
6.1. Controller-based Path Computation ......................... 9 6.1. Controller-Based Path Computation
6.2. Constraint-based Path Computing in GMPLS Control ......... 10 6.2. Constraint-Based Path Computing in GMPLS Control
6.3. Path Computation Element (PCE) ........................... 10 6.3. Path Computation Element (PCE)
7. Signaling Options ............................................. 10 7. Signaling Options
7.1. RSVP-TE .................................................. 11 7.1. RSVP-TE
8. Interworking Scenarios ........................................ 11 8. Interworking Scenarios
8.1. Topology Collection & Synchronization .................... 11 8.1. Topology Collection and Synchronization
8.2. Multi-domain Service Provisioning ........................ 11 8.2. Multi-Domain Service Provisioning
8.3. Multi-layer Service Provisioning ......................... 15 8.3. Multi-Layer Service Provisioning
8.3.1. Multi-layer Path Computation ........................ 15 8.3.1. Multi-Layer Path Computation
8.3.2. Cross-layer Path Creation ........................... 18 8.3.2. Cross-Layer Path Creation
8.3.3. Link Discovery ...................................... 19 8.3.3. Link Discovery
8.4. Recovery ................................................. 19 8.4. Recovery
8.4.1. Span Protection ..................................... 20 8.4.1. Span Protection
8.4.2. LSP Protection ...................................... 20 8.4.2. LSP Protection
8.4.3. Single-domain LSP Restoration ....................... 20 8.4.3. Single-Domain LSP Restoration
8.4.4. Multi-domain LSP Restoration ........................ 21 8.4.4. Multi-Domain LSP Restoration
8.4.5. Fast Reroute ........................................ 25 8.4.5. Fast Reroute
8.5. Controller Reliability ................................... 25 8.5. Controller Reliability
9. Manageability Considerations .................................. 26 9. Manageability Considerations
10. Security Considerations ...................................... 26 10. Security Considerations
11. IANA Considerations........................................... 27 11. IANA Considerations
12. References ................................................... 27 12. References
12.1. Normative References .................................... 27 12.1. Normative References
12.2. Informative References .................................. 29 12.2. Informative References
13. Contributors ................................................. 32 Acknowledgements
14. Authors' Addresses ........................................... 32 Contributors
Acknowledgements ................................................. 32 Authors' Addresses
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] extends
MPLS to support different classes of interfaces and switching MPLS to support different classes of interfaces and switching
capabilities such as Time-Division Multiplex Capable (TDM), Lambda capabilities such as Time-Division Multiplex Capable (TDM), Lambda
Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network
element (NE) running a GMPLS control plane collects network element (NE) running a GMPLS control plane collects network
information from other NEs and supports service provisioning through information from other NEs and supports service provisioning through
signaling in a distributed manner. A more generic description of signaling in a distributed manner. A more generic description of
Traffic-engineering networking information exchange can be found in traffic-engineering networking information exchange can be found in
[RFC7926]. [RFC7926].
On the other hand, Software-Defined Networking (SDN) technologies On the other hand, Software-Defined Networking (SDN) technologies
have been introduced to control the transport network centrally. have been introduced to control the transport network centrally.
Centralized controllers can collect network information from each Centralized controllers can collect network information from each
node and provision services on corresponding nodes. One example is node and provision services on corresponding nodes. One example is
the Abstraction and Control of Traffic Engineered Networks (ACTN) the Abstraction and Control of Traffic-Engineered Networks (ACTN)
[RFC8453], which defines a hierarchical architecture with [RFC8453], which defines a hierarchical architecture with the
Provisioning Network Controller (PNC), Multi-domain Service Provisioning Network Controller (PNC), Multi-Domain Service
Coordinator (MDSC) and Customer Network Controller (CNC) as Coordinator (MDSC), and Customer Network Controller (CNC) as
centralized controllers for different network abstraction levels. A centralized controllers for different network abstraction levels. A
Path Computation Element (PCE) based approach has been proposed as PCE-based approach has been proposed in [RFC7491]: Application-Based
Application-Based Network Operations (ABNO) in [RFC7491]. Network Operations (ABNO).
GMPLS can be used to control Network Elements (NEs) in such GMPLS can be used to control network elements (NEs) in such
centralized controller architectures. A centralized controller may centralized controller architectures. A centralized controller may
support GMPLS-enabled domains and communicate with a GMPLS-enabled support GMPLS-enabled domains and communicate with a GMPLS-enabled
domain where the GMPLS control plane handles service provisioning domain where the GMPLS control plane handles service provisioning
from ingress to egress. In this scenario, the centralized controller from ingress to egress. In this scenario, the centralized controller
sends a request to the entry node and does not need to configure all 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 NEs along the path within the domain from ingress to egress, thus
leveraging the GMPLS control plane. This document describes how the leveraging the GMPLS control plane. This document describes how the
GMPLS control plane interworks with a centralized controller system GMPLS control plane interworks with a centralized controller system
in a transport network. in a transport network.
2. Abbreviations 2. Abbreviations
The following abbreviations are used in this document. The following abbreviations are used in this document.
ACTN Abstraction and Control of Traffic Engineered Networks ACTN: Abstraction and Control of Traffic-Engineered Networks
([RFC8453]) [RFC8453]
APS Automatic Protection Switching ([G.808.1])
BRPC Backward-Recursive PCE-Based Computation ([RFC5441])
CSPF Constraint-based Shortest Path First
DoS Denial-of-Service
E2E End-to-end
ERO Explicit Route Object
FA Forwarding Adjacency
FRR Fast Reroute
GMPLS Generalized Multi-Protocol Label Switching ([RFC3945])
H-PCE Hierarchical PCE ([RFC8685])
IDS Intrusion Detection System
IGP Interior Gateway Protocol
IoC Indicators of Compromise ([RFC9424])
IPS Intrusion Prevention System
IS-IS Intermediate System to Intermediate System protocol
LMP Link Management Protocol ([RFC4204])
LSP Label Switched Path
LSP-DB LSP Database
MD Multi-domain
MDSC Multi-domain Service Coordinator([RFC8453])
MITM Man-In-The-Middle
ML Multi-layer
MPI MDSC to PNC Interface ([RFC8453])
NE Network element
NETCONF Network Configuration Protocol ([RFC6241])
NMS Network Management System
OSPF Open Shortest Path First protocol
PCC Path Computation Client ([RFC4655])
PCE Path Computation Element ([RFC4655])
PCEP Path Computation Element communication Protocol ([RFC5440])
PCEP-LS Link-state PCEP ([PCEP-LS])
PLR Point of Local Repair
PNC Provisioning Network Controller ([RFC8453])
RSVP Resource Reservation Protocol
SBI Southbound Interface
SDN Software-Defined Networking
TE Traffic Engineering
TED Traffic Engineering Database
TLS Transport Layer Security ([RFC8446])
VNTM Virtual Network Topology Manager ([RFC5623])
3. Overview APS: Automatic Protection Switching [G.808.1]
BRPC: Backward Recursive PCE-Based Computation [RFC5441]
CSPF: Constrained Shortest Path First
DoS: Denial of Service
E2E: end to end
ERO: Explicit Route Object
FA: Forwarding Adjacency
FRR: Fast Reroute
GMPLS: Generalized Multiprotocol Label Switching [RFC3945]
H-PCE: Hierarchical PCE [RFC8685]
IDS: Intrusion Detection System
IGP: Interior Gateway Protocol
IoCs: Indicators of Compromise [RFC9424]
IPS: Intrusion Prevention System
IS-IS: Intermediate System to Intermediate System
LMP: Link Management Protocol [RFC4204]
LSP: Label Switched Path
LSP-DB: LSP Database
MD: multi-domain
MDSC: Multi-Domain Service Coordinator [RFC8453]
MITM: Man in the Middle
ML: multi-layer
MPI: MDSC to PNC Interface [RFC8453]
NE: network element
NETCONF: Network Configuration Protocol [RFC6241]
NMS: Network Management System
OSPF: Open Shortest Path First
PCC: Path Computation Client [RFC4655]
PCE: Path Computation Element [RFC4655]
PCEP: PCE Communication Protocol [RFC5440]
PCEP-LS: Link State PCEP [PCEP-LS]
PLR: Point of Local Repair
PNC: Provisioning Network Controller [RFC8453]
RSVP: Resource Reservation Protocol
SBI: Southbound Interface
SDN: Software-Defined Networking
TE: Traffic Engineering
TED: Traffic Engineering Database
TLS: Transport Layer Security [RFC8446]
VNTM: Virtual Network Topology Manager [RFC5623]
3. Overview
This section provides an overview of the GMPLS control plane, This section provides an overview of the GMPLS control plane,
centralized controller systems and their interactions in transport centralized controller systems, and their interactions in transport
networks. networks.
A transport network [RFC5654] is a server-layer network designed to A transport network [RFC5654] is a server-layer network designed to
provide connectivity services for client-layer connectivity. This provide connectivity services for client-layer connectivity. This
setup allows client traffic to be carried seamlessly across the setup allows client traffic to be carried seamlessly across the
server-layer network resources. server-layer network resources.
3.1. Overview of GMPLS Control Plane 3.1. Overview of GMPLS Control Plane
GMPLS separates the control plane and the data plane to support GMPLS separates the control plane and the data plane to support time-
time-division, wavelength, and spatial switching, which are division, wavelength, and spatial switching, which are significant in
significant in transport networks. For the NE level control in transport networks. For the NE level control in GMPLS, each node
GMPLS, each node runs a GMPLS control plane instance. runs a GMPLS control plane instance. Functionalities such as service
Functionalities such as service provisioning, protection, and provisioning, protection, and restoration can be performed via GMPLS
restoration can be performed via GMPLS communication among multiple communication among multiple NEs. At the same time, the GMPLS
NEs. At the same time, the GMPLS control plane instance can also control plane instance can also collect information about node and
collect information about node and link resources in the network to link resources in the network to construct the network topology and
construct the network topology and compute routing paths for serving compute routing paths for serving service requests.
service requests.
Several protocols have been designed for the GMPLS control plane Several protocols have been designed for the GMPLS control plane
[RFC3945], including link management [RFC4204], signaling [RFC3471], [RFC3945], including link management [RFC4204], signaling [RFC3471],
and routing [RFC4202] protocols. The GMPLS control plane instances and routing [RFC4202] protocols. The GMPLS control plane instances
applying these protocols communicate with each other to exchange applying these protocols communicate with each other to exchange
resource information and establish Label Switched Paths (LSPs). In resource information and establish LSPs. In this way, GMPLS control
this way, GMPLS control plane instances in different nodes in the plane instances in different nodes in the network have the same view
network have the same view of the network topology and provision of the network topology and provision services based on local
services based on local policies. policies.
3.2. Overview of Centralized Controller System 3.2. Overview of Centralized Controller System
With the development of SDN technologies, a centralized controller With the development of SDN technologies, a centralized controller
architecture has been introduced to transport networks. One example architecture has been introduced to transport networks. One example
architecture can be found in ACTN [RFC8453]. In such systems, a architecture can be found in ACTN [RFC8453]. In such systems, a
controller is aware of the network topology and is responsible for controller is aware of the network topology and is responsible for
provisioning incoming service requests. provisioning incoming service requests.
Multiple hierarchies of controllers are designed at different levels Multiple hierarchies of controllers are designed at different levels
to implement different functions. This kind of architecture enables to implement different functions. This kind of architecture enables
multi-vendor, multi-domain, and multi-technology control. For multi-vendor, multi-domain, and multi-technology control. For
example, a higher-level controller coordinates several lower-level example, a higher-level controller coordinates several lower-level
controllers controlling different domains, for topology collection controllers controlling different domains for topology collection and
and service provisioning. Vendor-specific features can be abstracted service provisioning. Vendor-specific features can be abstracted
between controllers, and a standard API (e.g., generated from between controllers, and a standard API (e.g., generated from
RESTCONF [RFC8040] / YANG [RFC7950]) may be used. RESTCONF [RFC8040] / YANG [RFC7950]) may be used.
3.3. GMPLS Control Interworking with a Centralized Controller System 3.3. GMPLS Control Interworking with a Centralized Controller System
Besides GMPLS and the interactions among the controller hierarchies, Besides GMPLS and the interactions among the controller hierarchies,
it is also necessary for the controllers to communicate with the it is also necessary for the controllers to communicate with the
network elements. Within each domain, GMPLS control can be applied network elements. Within each domain, GMPLS control can be applied
to each NE. The bottom-level centralized controller can act as an NE to each NE. The bottom-level centralized controller can act as an NE
to collect network information and initiate LSPs. Figure 1 shows an to collect network information and initiate LSPs. Figure 1 shows an
example of GMPLS interworking with centralized controllers (ACTN example of GMPLS interworking with centralized controllers (ACTN
terminologies are used in the figure). terminologies are used in the figure).
+-------------------+ +-------------------+
| Orchestrator | | Orchestrator |
| (MDSC) | | (MDSC) |
+-------------------+ +-------------------+
^ ^ ^ ^ ^ ^
| | | | | |
+-------------+ | +-------------+ +-------------+ | +--------------+
| |RESTCONF/YANG models | | |RESTCONF/YANG modules |
V V V V V V
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
|Controller(N)| |Controller(G)| |Controller(G)| |Controller(N)| |Controller(G)| |Controller(G)|
| (PNC) | | (PNC) | | (PNC) | | (PNC) | | (PNC) | | (PNC) |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | |
NETCONF| |PCEP NETCONF| |PCEP NETCONF| |PCEP NETCONF| |PCEP NETCONF| |PCEP NETCONF| |PCEP
/YANG | | /YANG | | /YANG | | /YANG | | /YANG | | /YANG | |
V V V V V V V V V V V V
.----------. Inter- .----------. Inter- .----------. .----------. Inter- .----------. Inter- .----------.
/ \ domain / \ domain / \ / \ domain / \ domain / \
| | link | LMP | link | LMP | | | link | LMP | link | LMP |
| |======| OSPF-TE |======| OSPF-TE | | |======| OSPF-TE |======| OSPF-TE |
| | | RSVP-TE | | RSVP-TE | | | | RSVP-TE | | RSVP-TE |
\ / \ / \ / \ / \ / \ /
`----------` `----------` `----------` `----------` `----------` `----------`
Non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3 Non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3
Controller(N): A domain controller controlling a non-GMPLS domain Figure 1: Example of GMPLS/non-GMPLS Interworking with Controllers
Controller(G): A domain controller controlling a GMPLS domain
Figure 1: Example of GMPLS/non-GMPLS interworking with Controllers Controller(N): A domain controller controlling a non-GMPLS domain
Controller(G): A domain controller controlling a GMPLS domain
Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS
domain. This system supports the interworking among non-GMPLS domain. This system supports the interworking among non-GMPLS
domain, GMPLS domain and the controller hierarchies. domains, GMPLS domains, and the controller hierarchies.
For domain 1, the network elements were not enabled with GMPLS so For domain 1, the network elements were not enabled with GMPLS, so
the control is purely from the controller, via Network Configuration the control is purely from the controller, via Network Configuration
Protocol (NETCONF) [RFC6241] / YANG and/or PCE Communication Protocol (NETCONF) [RFC6241] with a YANG data model [RFC7950] and/or
Protocol (PCEP) [RFC5440]. PCE Communication Protocol (PCEP) [RFC5440].
For domains 2 and 3: For domains 2 and 3:
- Each domain has the GMPLS control plane enabled at the physical * Each domain has the GMPLS control plane enabled at the physical
network level. The Provisioning Network Controller (PNC) can network level. The Provisioning Network Controller (PNC) can
exploit GMPLS capabilities implemented in the domain to listen to exploit GMPLS capabilities implemented in the domain to listen to
the IGP routing protocol messages (OSPF LSAs, for example) that the IGP routing protocol messages (for example, OSPF Link State
the GMPLS control plane instances are disseminating into the Advertisements (LSAs)) that the GMPLS control plane instances are
network and thus learn the network topology. For path computation disseminating into the network and thus learn the network
in the domain with PNC implementing a PCE, Path Computation topology. For path computation in the domain with the PNC
Clients (PCCs) (e.g. NEs, other controller/PCE) use PCEP to ask implementing a PCE, Path Computation Clients (PCCs) (e.g., NEs,
the PNC for a path and get replies. The Multi-Domain Service other controllers/PCEs) use PCEP to ask the PNC for a path and get
Coordinator (MDSC) communicates with PNCs using, for example replies. The Multi-Domain Service Coordinator (MDSC) communicates
REST/RESTCONF based on YANG data models. As a PNC has learned its with PNCs using, for example, Representational State Transfer
domain topology, it can report the topology to the MDSC. When a (REST) / RESTCONF based on YANG data models. As a PNC has learned
service arrives, the MDSC computes the path and coordinates PNCs its domain topology, it can report the topology to the MDSC. When
to establish the corresponding LSP segment; a service arrives, the MDSC computes the path and coordinates PNCs
to establish the corresponding LSP segment.
- Alternatively, the NETCONF protocol can be used to retrieve * Alternatively, the NETCONF protocol can be used to retrieve
topology information utilizing the [RFC8795] YANG model and the topology information utilizing the YANG module in [RFC8795] and
technology-specific YANG model augmentations required for the the technology-specific YANG module augmentations required for the
specific network technology. The PNC can retrieve topology specific network technology. The PNC can retrieve topology
information from any NE (the GMPLS control plane instance of each information from any NE (the GMPLS control plane instance of each
NE in the domain has the same topological view), construct the NE in the domain has the same topological view), construct the
topology of the domain, and export an abstract view to the MDSC. topology of the domain, and export an abstract view to the MDSC.
Based on the topology retrieved from multiple PNCs, the MDSC can Based on the topology retrieved from multiple PNCs, the MDSC can
create a topology graph of the multi-domain network, and can use create a topology graph of the multi-domain network and can use it
it for path computation. To set up a service, the MDSC can exploit for path computation. To set up a service, the MDSC can exploit
the [TE-Tunnel] YANG model together with the technology-specific the YANG module in [YANG-TE] together with the technology-specific
YANG model augmentations. YANG module augmentations.
This document focuses on the interworking between GMPLS and the This document focuses on the interworking between GMPLS and the
centralized controller system, including: centralized controller system, including:
- The interworking between the GMPLS domains and the centralized * the interworking between the GMPLS domains and the centralized
controllers (including the orchestrator, if it exists) controlling controllers (including the orchestrator, if it exists) controlling
the GMPLS domains; the GMPLS domains and
- The interworking between a non-GMPLS domain (which is controlled * the interworking between a non-GMPLS domain (which is controlled
by a centralized controller system) and a GMPLS domain, through by a centralized controller system) and a GMPLS domain, through
the controller hierarchy architecture. the controller hierarchy architecture.
For convenience, this document uses the following terminologies for For convenience, this document uses the following terminologies for
the controller and the orchestrator: the controller and the orchestrator:
- Controller(G): A domain controller controlling a GMPLS domain (the Controller(G): A domain controller controlling a GMPLS domain (the
controller(G) of the GMPLS domains 2 and 3 in Figure 1); Controller(G) of the GMPLS domains 2 and 3 in Figure 1)
- Controller(N): A domain controller controlling a non-GMPLS domain Controller(N): A domain controller controlling a non-GMPLS domain
(the controller(N) of the non-GMPLS domain 1 in Figure 1); (the Controller(N) of the non-GMPLS domain 1 in Figure 1)
- H-Controller(G): A domain controller controlling the higher-layer H-Controller(G): A domain controller controlling the higher-layer
GMPLS domain, in the context of multi-layer networks; GMPLS domain, in the context of multi-layer networks
- L-Controller(G): A domain controller controlling the lower-layer L-Controller(G): A domain controller controlling the lower-layer
GMPLS domain, in the context of multi-layer networks; GMPLS domain, in the context of multi-layer networks
- H-Controller(N): A domain controller controlling the higher-layer H-Controller(N): A domain controller controlling the higher-layer
non-GMPLS domain, in the context of multi-layer networks; non-GMPLS domain, in the context of multi-layer networks
- L-Controller(N): A domain controller controlling the lower-layer L-Controller(N): A domain controller controlling the lower-layer
non-GMPLS domain, in the context of multi-layer networks; non-GMPLS domain, in the context of multi-layer networks
- Orchestrator(MD): An orchestrator used to orchestrate the multi- Orchestrator(MD): An orchestrator used to orchestrate the multi-
domain networks; domain networks
- Orchestrator(ML): An orchestrator used to orchestrate the multi- Orchestrator(ML): An orchestrator used to orchestrate the multi-
layer networks. layer networks
4. Discovery Options 4. Discovery Options
In GMPLS control, the link connectivity must be verified between In GMPLS control, the link connectivity must be verified between each
each pair of nodes. In this way, link resources, which are pair of nodes. In this way, link resources, which are fundamental
fundamental resources in the network, are discovered by both ends of resources in the network, are discovered by both ends of the link.
the link.
4.1. LMP 4.1. LMP
Link management protocol (LMP) [RFC4204] runs between nodes and The Link Management Protocol (LMP) [RFC4204] runs between nodes and
manages TE links. In addition to the setup and maintenance of manages TE links. In addition to the setup and maintenance of
control channels, LMP can be used to verify the data link control channels, LMP can be used to verify the data link
connectivity and correlate the link properties. connectivity and correlate the link properties.
5. Routing Options 5. Routing Options
In GMPLS control, link state information is flooded within the In GMPLS control, link state information is flooded within the
network as defined in [RFC4202]. Each node in the network can build network as defined in [RFC4202]. Each node in the network can build
the network topology according to the flooded link state the network topology according to the flooded link state information.
information. Routing protocols such as OSPF-TE [RFC4203] and IS-IS- Routing protocols such as OSPF-TE [RFC4203] and IS-IS-TE [RFC5307]
TE [RFC5307] have been extended to support different interfaces in have been extended to support different interfaces in GMPLS.
GMPLS.
In a centralized controller system, the centralized controller can In a centralized controller system, the centralized controller can be
be placed in the GMPLS network and passively receives the IGP placed in the GMPLS network and passively receives the IGP
information flooded in the network. In this way, the centralized information flooded in the network. In this way, the centralized
controller can construct and update the network topology. controller can construct and update the network topology.
5.1. OSPF-TE 5.1. OSPF-TE
OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions
have been defined in [RFC4203] to enable the capability of link have been defined in [RFC4203] to enable the capability of link state
state information for the GMPLS network. Based on this work, OSPF information for the GMPLS network. Based on this work, OSPF has been
has been extended to support technology-specific routing. The extended to support technology-specific routing. The routing
routing protocol for Optical Transport Network (OTN), Wavelength protocols for the Optical Transport Network (OTN), Wavelength
Switched Optical Network (WSON) and optical flexi-grid networks are Switched Optical Network (WSON), and optical flexi-grid networks are
defined in [RFC7138], [RFC7688] and [RFC8363], respectively. defined in [RFC7138], [RFC7688], and [RFC8363], respectively.
5.2. IS-IS-TE 5.2. IS-IS-TE
IS-IS-TE is introduced for TE networks in [RFC5305] and is extended IS-IS-TE is introduced for TE networks in [RFC5305], is extended to
to support GMPLS routing functions [RFC5307], and has been updated support GMPLS routing functions [RFC5307], and has been updated
to [RFC7074] to support the latest GMPLS switching capability and [RFC7074] to support the latest GMPLS switching capability and Types
Types fields. fields.
5.3. NETCONF/RESTCONF 5.3. NETCONF/RESTCONF
NETCONF [RFC6241] and RESTCONF [RFC8040] protocols are originally NETCONF [RFC6241] and RESTCONF [RFC8040] protocols are originally
used for network configuration. These protocols can also utilize used for network configuration. These protocols can also utilize
topology-related YANG models, such as [RFC8345] and [RFC8795]. These topology-related YANG modules, such as those in [RFC8345] and
protocols provide a powerful mechanism for notification (in addition [RFC8795]. These protocols provide a powerful mechanism for the
to provisioning and monitoring) of topology changes to the client. notification (in addition to the provisioning and monitoring) of
topology changes to the client.
6. Path Computation 6. Path Computation
6.1. Controller-based Path Computation 6.1. Controller-Based Path Computation
Once a controller learns the network topology, it can utilize the Once a controller learns the network topology, it can utilize the
available resources to serve service requests by performing path available resources to serve service requests by performing path
computation. Due to abstraction, the controllers may not have computation. Due to abstraction, the controllers may not have
sufficient information to compute the optimal path. In this case, sufficient information to compute the optimal path. In this case,
the controller can interact with other controllers by sending, for the controller can interact with other controllers by sending, for
example, YANG-based Path Computation requests [PAT-COMP] or PCEP, to example, YANG-based path computation requests [PATH-COMP] or PCEP to
compute a set of potential optimal paths and then, based on its compute a set of potential optimal paths; and then, based on its
constraints, policy, and specific knowledge (e.g. cost of access constraints, policy, and specific knowledge (e.g., cost of access
link) can choose the more feasible path for end-to-end (E2E) service link), the controller can choose the more feasible path for end-to-
path setup. end (E2E) service path setup.
Path computation is one of the key objectives in various types of Path computation is one of the key objectives in various types of
controllers. In the given architecture, it is possible for different controllers. In the given architecture, it is possible for different
components that have the capability to compute the path. components that have the capability to compute the path.
6.2. Constraint-based Path Computing in GMPLS Control 6.2. Constraint-Based Path Computing in GMPLS Control
In GMPLS control, a routing path may be computed by the ingress node In GMPLS control, a routing path may be computed by the ingress node
([RFC3473]) based on the ingress node Traffic Engineering Database [RFC3473] based on the ingress node Traffic Engineering Database
(TED). In this case, constraint-based path computation is performed (TED). In this case, constraint-based path computation is performed
according to the local policy of the ingress node. according to the local policy of the ingress node.
6.3. Path Computation Element (PCE) 6.3. Path Computation Element (PCE)
The PCE was first introduced in [RFC4655] as a functional component The PCE was first introduced in [RFC4655] as a functional component
that offers services for computing paths within a network. In that offers services for computing paths within a network. In
[RFC5440], path computation is achieved using the TED, which [RFC5440], path computation is achieved using the TED, which
maintains a view of the link resources in the network. The maintains a view of the link resources in the network. The
introduction of PCE has significantly improved the quality of introduction of the PCE has significantly improved the quality of
network planning and offline computation. However, there is a network planning and offline computation. However, there is a
potential risk that the computed path may be infeasible when there potential risk that the computed path may be infeasible when there is
is a diversity requirement, as stateless PCE lacks knowledge about a diversity requirement, as a stateless PCE lacks knowledge about
previously computed paths. previously computed paths.
To address this issue, stateful PCE has been proposed in [RFC8231]. To address this issue, a stateful PCE has been proposed in [RFC8231].
Besides the TED, an additional LSP Database (LSP-DB) is introduced Besides the TED, an additional LSP Database (LSP-DB) is introduced to
to archive each LSP computed by the PCE. This way, PCE can easily archive each LSP computed by the PCE. This way, the PCE can easily
determine the relationship between the computing path and former determine the relationship between the computing path and former
computed paths. In this approach, PCE provides computed paths to computed paths. In this approach, the PCE provides computed paths to
PCC, and then PCC decides which path is deployed and when to be the PCC, and then the PCC decides which path is deployed and when it
established. is to be established.
With PCE-Initiated LSPs [RFC8281], PCE can trigger the PCC to With PCE-initiated LSPs [RFC8281], the PCE can trigger the PCC to
perform setup, maintenance, and teardown of the PCE-initiated LSP perform setup, maintenance, and teardown of the PCE-initiated LSP
under the stateful PCE model. This would allow a dynamic network under the stateful PCE model. This would allow a dynamic network
that is centrally controlled and deployed. that is centrally controlled and deployed.
In a centralized controller system, the PCE can be implemented In a centralized controller system, the PCE can be implemented within
within the centralized controller. The centralized controller then the centralized controller. The centralized controller then
calculates paths based on its local policies. Alternatively, the PCE calculates paths based on its local policies. Alternatively, the PCE
can be located outside of the centralized controller. In this can be located outside of the centralized controller. In this
scenario, the centralized controller functions as a PCC and sends a scenario, the centralized controller functions as a PCC and sends a
path computation request to the PCE using the PCEP. A reference path computation request to the PCE using the PCEP. A reference
architecture for this can be found in [RFC7491]. architecture for this can be found in [RFC7491].
7. Signaling Options 7. Signaling Options
Signaling mechanisms are used to set up LSPs in GMPLS control. Signaling mechanisms are used to set up LSPs in GMPLS control.
Messages are sent hop by hop between the ingress node and the egress 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 node of the LSP to allocate labels. Once the labels are allocated
along the path, the LSP setup is accomplished. Signaling protocols along the path, the LSP setup is accomplished. Signaling protocols
such as Resource Reservation Protocol - Traffic Engineering (RSVP- such as Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
TE) [RFC3473] have been extended to support different interfaces in [RFC3473] have been extended to support different interfaces in
GMPLS. GMPLS.
7.1. RSVP-TE 7.1. RSVP-TE
RSVP-TE is introduced in [RFC3209] and extended to support GMPLS RSVP-TE is introduced in [RFC3209] and extended to support GMPLS
signaling in [RFC3473]. Several label formats are defined for a signaling in [RFC3473]. Several label formats are defined for a
generalized label request, a generalized label, a suggested label generalized label request, a generalized label, a suggested label,
and label sets. Based on [RFC3473], RSVP-TE has been extended to and label sets. Based on [RFC3473], RSVP-TE has been extended to
support technology-specific signaling. The RSVP-TE extensions for support technology-specific signaling. The RSVP-TE extensions for
OTN, WSON, and optical flexi-grid network are defined in [RFC7139], the OTN, WSON, and optical flexi-grid network are defined in
[RFC7689], and [RFC7792], respectively. [RFC7139], [RFC7689], and [RFC7792], respectively.
8. Interworking Scenarios 8. Interworking Scenarios
8.1. Topology Collection & Synchronization 8.1. Topology Collection and Synchronization
Topology information is necessary on both network elements and Topology information is necessary on both network elements and
controllers. The topology on a network element is usually raw controllers. The topology on a network element is usually raw
information, while the topology used by the controller can be either information, while the topology used by the controller can be either
raw, reduced, or abstracted. Three different abstraction methods raw, reduced, or abstracted. Three different abstraction methods
have been described in [RFC8453], and different controllers can have been described in [RFC8453], and different controllers can
select the corresponding method depending on the application. select the corresponding method depending on the application.
When there are changes in the network topology, the impacted network When there are changes in the network topology, the impacted network
elements need to report changes to all the other network elements, elements need to report changes to all the other network elements,
together with the controller, to sync up the topology information. together with the controller, to sync up the topology information.
The inter-NE synchronization can be achieved via protocols mentioned The inter-NE synchronization can be achieved via protocols mentioned
in Sections 4 and 5. The topology synchronization between NEs and in Sections 4 and 5. The topology synchronization between NEs and
controllers can either be achieved by routing protocols OSPF- controllers can either be achieved by routing protocols OSPF-TE/PCEP-
TE/PCEP-LS in [PCEP-LS] or NETCONF protocol notifications with YANG LS in [PCEP-LS] or NETCONF protocol notifications with a YANG module.
model.
8.2. Multi-domain Service Provisioning 8.2. Multi-Domain Service Provisioning
Service provisioning can be deployed based on the topology Service provisioning can be deployed based on the topology
information on controllers and network elements. Many methods have information on controllers and network elements. Many methods have
been specified for single-domain service provisioning, such as the been specified for single-domain service provisioning, such as the
PCEP and RSVP-TE methods. PCEP and RSVP-TE methods.
Multi-domain service provisioning would require coordination among Multi-domain service provisioning would require coordination among
the controller hierarchies. Given the service request, the end-to- the controller hierarchies. Given the service request, the end-to-
end delivery procedure may include interactions at any level (i.e. end delivery procedure may include interactions at any level (i.e.,
interface) in the hierarchy of the controllers (e.g. MPI and SBI for interface) in the hierarchy of the controllers (e.g., MPI and SBI for
ACTN). The computation for a cross-domain path is usually completed ACTN). The computation for a cross-domain path is usually completed
by controllers who have a global view of the topologies. Then the by controllers who have a global view of the topologies. Then the
configuration is decomposed into lower-level controllers, to configuration is decomposed into lower-level controllers to configure
configure the network elements to set up the path. the network elements to set up the path.
A combination of centralized and distributed protocols may be A combination of centralized and distributed protocols may be
necessary to interact between network elements and controllers. necessary to interact between network elements and controllers.
Several methods can be used to create the inter-domain path: Several methods can be used to create the inter-domain path:
1) With end-to-end RSVP-TE session: 1) With an end-to-end RSVP-TE session:
In this method, all the domains need to support the RSVP-TE protocol In this method, all the domains need to support the RSVP-TE
and thus need to be GMPLS domains. The Controller(G) of the source protocol and thus need to be GMPLS domains. The Controller(G) of
domain triggers the source node to create the end-to-end RSVP-TE the source domain triggers the source node to create the end-to-
session, and the assignment and distribution of the labels on the end RSVP-TE session; and the assignment and distribution of the
inter-domain links are done by the border nodes of each domain, labels on the inter-domain links are done by the border nodes of
using RSVP-TE protocol. Therefore, this method requires the each domain, using RSVP-TE protocol. Therefore, this method
interworking of RSVP-TE protocols between different domains. requires the interworking of RSVP-TE protocols between different
domains.
There are two possible methods: There are two possible methods:
1.1) One single end-to-end RSVP-TE session 1.1) One single end-to-end RSVP-TE session:
In this method, an end-to-end RSVP-TE session from the source node In this method, an end-to-end RSVP-TE session from the
to the destination node will be used to create the inter-domain source node to the destination node will be used to create
path. A typical example would be the PCE Initiation scenario, in the inter-domain path. A typical example would be the PCE
which a PCE message (PCInitiate) is sent from the controller(G) to initiation scenario, in which a PCE message (PCInitiate) is
the source node, triggering an RSVP procedure along the path. sent from the Controller(G) to the source node, triggering
Similarly, the interaction between the controller and the source an RSVP procedure along the path. Similarly, the
node of the source domain can be achieved by using the NETCONF interaction between the controller and the source node of
protocol with corresponding YANG models, and then it can be the source domain can be achieved by using the NETCONF
completed by running RSVP among the network elements. protocol with corresponding YANG modules, and then it can
be completed by running RSVP among the network elements.
1.2) LSP Stitching 1.2) LSP Stitching:
The LSP stitching method defined in [RFC5150] can also create the The LSP stitching method defined in [RFC5150] can also
E2E LSP. I.e., when the source node receives an end-to-end path create the E2E LSP. That is, when the source node receives
creation request (e.g., using PCEP or NETCONF protocol), the source an end-to-end path creation request (e.g., using PCEP or
node starts an end-to-end RSVP-TE session along the endpoints of NETCONF protocol), the source node starts an end-to-end
each LSP segment (refers to S-LSP in [RFC5150]) of each domain, to RSVP-TE session along the endpoints of each LSP segment
assign the labels on the inter-domain links between each pair of (S-LSP) (refers to S-LSP in [RFC5150]) of each domain, to
neighbor S-LSPs, and stitch the end-to-end LSP to each S-LSP. See assign the labels on the inter-domain links between each
Figure 2 as an example. Note that the S-LSP in each domain can be pair of neighbor S-LSPs and to stitch the end-to-end LSP to
either created by its Controller(G) in advance, or created each S-LSP. See Figure 2 as an example.
dynamically triggered by the end-to-end RSVP-TE session.
+------------------------+ Note that the S-LSP in each domain can be either created by
| Orchestrator(MD) | its Controller(G) in advance or created dynamically
+-----------+------------+ triggered by the end-to-end RSVP-TE session.
|
+---------------+ +------V-------+ +---------------+
| Controller(G) | | Controller(G)| | Controller(G) |
+-------+-------+ +------+-------+ +-------+-------+
| | |
+--------V--------+ +-------V--------+ +--------V--------+
|Client | | | | Client|
|Signal Domain 1| | Domain 2 | |Domain 3 Signal|
| | | | | | | |
|+-+-+ | | | | +-+-+|
|| | | +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | | || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || || | | | | || || | | | | ||
|+---+ +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ +---+|
+-----------------+ +----------------+ +-----------------+
| . . . . . . |
| .<-S-LSP 1->. .<- S-LSP 2 -->. .<-S-LSP 3->. |
| . . . . |
|-------------->.---->.------------->.---->.-------------->|
|<--------------.<----.<-------------.<----.<--------------|
| End-to-end RSVP-TE session for LSP stitching |
Figure 2: LSP stitching +------------------------+
| Orchestrator(MD) |
+-----------+------------+
|
+---------------+ +------V-------+ +---------------+
| Controller(G) | | Controller(G)| | Controller(G) |
+-------+-------+ +------+-------+ +-------+-------+
| | |
+--------V--------+ +-------V--------+ +--------V--------+
|Client | | | | Client|
|Signal Domain 1| | Domain 2 | |Domain 3 Signal|
| | | | | | | |
|+-+-+ | | | | +-+-+|
|| | | +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | | || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || || | | | | || || | | | | ||
|+---+ +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ +---+|
+-----------------+ +----------------+ +-----------------+
| . . . . . . |
| .<-S-LSP 1->. .<- S-LSP 2 -->. .<-S-LSP 3->. |
| . . . . |
|-------------->.---->.------------->.---->.-------------->|
|<--------------.<----.<-------------.<----.<--------------|
| End-to-end RSVP-TE session for LSP stitching |
2) Without end-to-end RSVP-TE session: Figure 2: LSP Stitching
In this method, each domain can be a GMPLS domain or a non-GMPLS 2) Without an end-to-end RSVP-TE session:
domain. Each controller (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 end-to-end RSVP-TE session through multiple domains is not
required, and the interworking of RSVP-TE protocol between different
domains is not needed.
Note that path segments in the source domain and the destination In this method, each domain can be a GMPLS domain or a non-GMPLS
domain are "asymmetrical" segments, because the configuration of domain. Each controller (which may be a Controller(G) or a
client signal mapping into server layer tunnel is needed at only one Controller(N)) is responsible for creating the path segment
end of the segment, while configuration of server layer cross- within its domain. The border node does not need to communicate
connect is needed at the other end of the segment. See the example with other border nodes in other domains for the distribution of
in Figure 3. 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.
+------------------------+ Note that path segments in the source domain and the destination
| Orchestrator(MD) | 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-
+---------------+ +------V-------+ +---------------+ layer cross-connect is needed at the other end of the segment.
| Controller | | Controller | | Controller | See the example in Figure 3.
+-------+-------+ +------+-------+ +-------+-------+
| | |
+--------V--------+ +-------V--------+ +--------V--------+
|Client Domain 1| | Domain 2 | | Domain 3 Client|
|Signal | | | | Signal|
| | Server layer| | | | | |
| | tunnel | | | | | |
|+-+-+ ^ | | | | +-+-+|
|| | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | || || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || . || | | | | || . || | | | | ||
|+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+|
+-----------------+ . +----------------+ . +-----------------+
. . . .
.<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.
Figure 3: Example of asymmetrical path segment +------------------------+
| Orchestrator(MD) |
+-----------+------------+
|
+---------------+ +------V-------+ +---------------+
| Controller | | Controller | | Controller |
+-------+-------+ +------+-------+ +-------+-------+
| | |
+--------V--------+ +-------V--------+ +--------V--------+
|Client Domain 1| | Domain 2 | | Domain 3 Client|
|Signal | | | | Signal|
| | Server layer| | | | | |
| | tunnel | | | | | |
|+-+-+ ^ | | | | +-+-+|
|| | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | || || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || . || | | | | || . || | | | | ||
|+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+|
+-----------------+ . +----------------+ . +-----------------+
. . . .
.<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.
The PCEP / GMPLS protocols should support the creation of such Figure 3: Example of an Asymmetrical Path Segment
asymmetrical segments.
Note also that mechanisms to assign the labels in the inter-domain The PCEP / GMPLS protocols should support the creation of such
links also need to be considered. There are two possible methods: asymmetrical segments.
2.1) Inter-domain labels assigned by NEs: Note also that mechanisms to assign the labels in the inter-
domain links also need to be considered. There are two possible
methods:
The concept of Stitching Label that allows stitching local path 2.1) Inter-domain labels assigned by NEs:
segments was introduced in [RFC5150] and [sPCE-ID], in order to form
the inter-domain path crossing several different domains. It also
describes the Backward-Recursive PCE-Based Computation (BRPC)
[RFC5441] and Hierarchical Path Computation Element (H-PCE)
[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.
2.2) Inter-domain labels assigned by controller: The concept of a stitching label that allows stitching
local path segments was introduced in [RFC5150] and
[SPCE-ID], in order to form the inter-domain path crossing
several different domains. It also describes the Backward
Recursive PCE-Based Computation (BRPC) [RFC5441] and
Hierarchical PCE (H-PCE) [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.
If the resources of inter-domain links are managed by the 2.2) Inter-domain labels assigned by the controller:
orchestrator(MD), each domain controller can provide to the
orchestrator(MD) the list of available labels (e.g. timeslots if OTN
is the scenario) using the IETF Topology YANG model and related
technology specific extension. 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 label
inter-domain information, e.g. 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.
8.3. Multi-layer Service Provisioning 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.
8.3. Multi-Layer Service Provisioning
GMPLS can interwork with centralized controller systems in multi- GMPLS can interwork with centralized controller systems in multi-
layer networks. layer networks.
+----------------+ +----------------+
|Orchestrator(ML)| |Orchestrator(ML)|
+------+--+------+ +------+--+------+
| | Higher-layer Network | | Higher-layer Network
| | .--------------------. | | .--------------------.
| | / \ | | / \
skipping to change at page 15, line 39 skipping to change at line 749
| . . | . .
| .---.------------.---. | .---.------------.---.
| / . . \ | / . . \
| +--------------+ | +--+ +--+ +--+ | | +--------------+ | +--+ +--+ +--+ |
+----->| L-Controller +----->| | ============== | | +----->| L-Controller +----->| | ============== | |
+--------------+ | +--+ +--+ +--+ | +--------------+ | +--+ +--+ +--+ |
\ H-LSP / \ H-LSP /
`-------------------` `-------------------`
Lower-layer Network Lower-layer Network
Figure 4: GMPLS-controller interworking in multi-layer networks Figure 4: GMPLS-controller Interworking in Multi-Layer Networks
An example with two layers of network is shown in Figure 4. In this An example with two layers of network is shown in Figure 4. In this
example, the GMPLS control plane is enabled in at least one layer example, the GMPLS control plane is enabled in at least one layer
network (otherwise, it is out of the scope of this document) and network (otherwise, it is out of the scope of this document) and
interworks with the controller of its domain (H-Controller and L- interworks with the controller of its domain (H-Controller and
Controller, respectively). The Orchestrator(ML) is used to L-Controller, respectively). The Orchestrator(ML) is used to
coordinate the control of the multi-layer network. coordinate the control of the multi-layer network.
8.3.1. Multi-layer Path Computation 8.3.1. Multi-Layer Path Computation
[RFC5623] describes three inter-layer path computation models and [RFC5623] describes three inter-layer path computation models and
four inter-layer path control models: four inter-layer path control models:
- 3 Path computation: * 3 path computation models:
o Single PCE path computation model - Single PCE path computation model
o Multiple PCE path computation with inter-PCE communication - Multiple PCE path computation with inter-PCE communication
model model
o Multiple PCE path computation without inter-PCE communication - Multiple PCE path computation without inter-PCE communication
model model
- 4 Path control: * 4 path control models:
o PCE-Virtual Network Topology Manager (PCE-VNTM) cooperation - PCE Virtual Network Topology Manager (PCE-VNTM) cooperation
model model
o Higher-layer signaling trigger model - Higher-layer signaling trigger model
o Network Management System-VNTM (NMS-VNTM) cooperation model - Network Management System VNTM (NMS-VNTM) cooperation model
(integrated flavor) (integrated flavor)
o NMS-VNTM cooperation model (separate flavor) - NMS-VNTM cooperation model (separate flavor)
Section 4.2.4 of [RFC5623] also provides all the possible Section 4.2.4 of [RFC5623] also provides all the possible
combinations of inter-layer path computation and inter-layer path combinations of inter-layer path computation and inter-layer path
control models. control models.
To apply [RFC5623] in multi-layer network with GMPLS-controller To apply [RFC5623] in a multi-layer network with GMPLS-controller
interworking, the H-Controller and the L-Controller can act as the interworking, the H-Controller and the L-Controller can act as the
PCE Hi and PCE Lo respectively, and typically, the Orchestrator(ML) 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 can act as a VNTM because it has the abstracted view of both the
higher-layer and lower-layer networks. higher-layer and lower-layer networks.
Table 1 shows all possible combinations of path computation and path Table 1 shows all possible combinations of path computation and path
control models in multi-layer network with GMPLS-controller control models in multi-layer network with GMPLS-controller
interworking: interworking:
Table 1: Combinations of path computation and path control models +======================+========+================+===============+
| Path computation / | Single | Multiple PCE | Multiple PCE |
| Path control | PCE | with inter-PCE | w/o inter-PCE |
+======================+========+================+===============+
| PCE-VNTM cooperation | N/A | Yes | Yes |
+----------------------+--------+----------------+---------------+
| Higher-layer | N/A | Yes | Yes |
| signaling trigger | | | |
+----------------------+--------+----------------+---------------+
| NMS-VNTM cooperation | N/A | Yes (1) | No (1) |
| (integrated flavor) | | | |
+----------------------+--------+----------------+---------------+
| NMS-VNTM cooperation | N/A | No (1) | Yes (1) |
| (separate flavor) | | | |
+----------------------+--------+----------------+---------------+
--------------------------------------------------------- Table 1: Combinations of Path Computation and Path Control Models
| Path computation |Single PCE | Multiple | Multiple |
| \ | (Not | PCE with | PCE w/o |
| Path control |applicable)| inter-PCE | inter-PCE |
|---------------------+-----------+-----------+-----------|
| PCE-VNTM | ...... | | |
| cooperation | . -- . | Yes | Yes |
| | . . | | |
|---------------------+--.----.---+-----------+-----------|
| Higher-layer | . . | | |
| signaling trigger | . -- . | Yes | Yes |
| | . . | | |
|---------------------+--.----.---+-----------+-----------|
| NMS-VNTM | . . | .........|....... |
| cooperation | . -- . | .Yes | No . |
| (integrated flavor) | . . | . | . |
|---------------------+--.----.---+--.--------+------.----|
| NMS-VNTM | . . | . | . |
| cooperation | . -- . | .No | Yes. |
| (separate flavor) | ...... | .........|....... |
---------------------+----|------+--------|--+-----------
V V
Not applicable because Typical models to be used
there are multiple PCEs
Note that: Note that:
- Since there is one PCE in each layer network, the path computation * Since there is one PCE in each layer network, the path computation
model "Single PCE path computation" is not applicable. model "Single PCE path computation" is not applicable (N/A).
- For the other two path computation models "Multiple PCE with * For the other two path computation models "Multiple PCE with
inter-PCE" and "Multiple PCE w/o inter-PCE", the possible inter-PCE" and "Multiple PCE w/o inter-PCE", the possible
combinations are the same as defined in [RFC5623]. More combinations are the same as defined in [RFC5623]. More
specifically: specifically:
o The path control models "NMS-VNTM cooperation (integrated - (1) The path control models "NMS-VNTM cooperation (integrated
flavor)" and "NMS-VNTM cooperation (separate flavor)" are the flavor)" and "NMS-VNTM cooperation (separate flavor)" are the
typical models to be used in multi-layer network with GMPLS- typical models to be used in a multi-layer network with GMPLS-
controller interworking. This is because in these two models, controller interworking. This is because, in these two models,
the path computation is triggered by the NMS or VNTM. And in the path computation is triggered by the NMS or VNTM. And in
the centralized controller system, the path computation the centralized controller system, the path computation
requests are typically from the Orchestrator(ML) (acts as requests are typically from the Orchestrator(ML) (acts as
VNTM). VNTM).
o For the other two path control models "PCE-VNTM cooperation" - For the other two path control models "PCE-VNTM cooperation"
and "Higher-layer signaling trigger", the path computation is and "Higher-layer signaling trigger", the path computation is
triggered by the NEs, i.e., NE performs PCC functions. These triggered by the NEs, i.e., the NE performs PCC functions. It
two models are still possible to be used, although they are not is still possible to use these two models, although they are
the main methods. not the main methods.
8.3.2. Cross-layer Path Creation 8.3.2. Cross-Layer Path Creation
In a multi-layer network, a lower-layer LSP in the lower-layer 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 network can be created, which will construct a new link in the
higher-layer network. Such lower-layer LSP is called Hierarchical higher-layer network. Such a lower-layer LSP is called Hierarchical
LSP, or H-LSP for short, see [RFC6107]. LSP, or H-LSP for short; see [RFC6107].
The new link constructed by the H-LSP can then be used by the The new link constructed by the H-LSP can then be used by the higher-
higher-layer network to create new LSPs. layer network to create new LSPs.
As described in [RFC5212], two methods are introduced to create the As described in [RFC5212], two methods are introduced to create the
H-LSP: the static (pre-provisioned) method and the dynamic H-LSP: the static (pre-provisioned) method and the dynamic
(triggered) method. (triggered) method.
1) Static (pre-provisioned) method 1) Static (pre-provisioned) method:
In this method, the H-LSP in the lower-layer network is created in In this method, the H-LSP in the lower-layer network is created
advance. After that, the higher-layer network can create LSPs using in advance. After that, the higher-layer network can create LSPs
the resource of the link constructed by the H-LSP. using the resource of the link constructed by the H-LSP.
The Orchestrator(ML) is responsible to decide the creation of H-LSP The Orchestrator(ML) is responsible to decide the creation of
in the lower-layer network if it acts as a VNTM. It then requests H-LSP in the lower-layer network if it acts as a VNTM. Then it
the L-Controller to create the H-LSP via, for example, MPI interface requests the L-Controller to create the H-LSP via, for example,
under the ACTN architecture. See Section 3.3.2 of [TE-Tunnel]. an MPI under the ACTN architecture.
If the lower-layer network is a GMPLS domain, the L-Controller(G) 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 can trigger the GMPLS control plane to create the H-LSP. As a
typical example, the PCInitiate message can be used for the typical example, the PCInitiate message can be used for the
communication between the L-Controller and the source node of the H- communication between the L-Controller and the source node of the
LSP. And the source node of the H-LSP can trigger the RSVP-TE 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 [RFC6107]. signaling procedure to create the H-LSP, as described in
[RFC6107].
If the lower-layer network is a non-GMPLS domain, other methods may If the lower-layer network is a non-GMPLS domain, other methods
be used by the L-Controller(N) to create the H-LSP, which is out of may be used by the L-Controller(N) to create the H-LSP, which is
scope of this document. out of scope of this document.
2) Dynamic (triggered) method 2) Dynamic (triggered) method:
In this method, the signaling of LSP creation in the higher-layer 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 will trigger the creation of H-LSP in the lower-layer
network dynamically, if it is necessary. Therefore, both the higher- network dynamically, if it is necessary. Therefore, both the
layer and lower-layer networks need to support the RSVP-TE protocol higher-layer and lower-layer networks need to support the RSVP-TE
and thus need to be GMPLS domains. protocol and thus need to be GMPLS domains.
In this case, after the cross-layer path is computed, the In this case, after the cross-layer path is computed, the
Orchestrator(ML) requests the H-Controller(G) for the cross-layer Orchestrator(ML) requests the H-Controller(G) for the cross-layer
LSP creation. As a typical example, the MPI interface under the ACTN LSP creation. As a typical example, the MPI under the ACTN
architecture could be used. architecture could be used.
The H-Controller(G) can trigger the GMPLS control plane to create The H-Controller(G) can trigger the GMPLS control plane to create
the LSP in the higher-layer network. As a typical example, the the LSP in the higher-layer network. As a typical example, the
PCInitiate message can be used for the communication between the H- PCInitiate message can be used for the communication between the
Controller(G) and the source node of the Higher-layer LSP, as H-Controller(G) and the source node of the higher-layer LSP, as
described in Section 4.3 of [RFC8282]. At least two sets of ERO described in Section 4.3 of [RFC8282]. At least two sets of ERO
information should be included to indicate the routes of higher- information should be included to indicate the routes of higher-
layer LSP and lower-layer H-LSP. layer LSP and lower-layer H-LSP.
The source node of the Higher-layer LSP follows the procedure The source node of the higher-layer LSP follows the procedure
defined in Section 4 of [RFC6001], to trigger the GMPLS control defined in Section 4 of [RFC6001] to trigger the GMPLS control
plane in both higher-layer network and lower-layer network to create plane in both the higher-layer network and the lower-layer
the higher-layer LSP and the lower-layer H-LSP. network to create the higher-layer LSP and the lower-layer H-LSP.
On success, the source node of the H-LSP should report the 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, information of the H-LSP to the L-Controller(G) via, for example,
PCRpt message. the PCRpt message.
8.3.3. Link Discovery 8.3.3. Link Discovery
If the higher-layer network and the lower-layer network are under If the higher-layer network and the lower-layer network are under the
the same GMPLS control plane instance, the H-LSP can be a Forwarding same GMPLS control plane instance, the H-LSP can be a Forwarding
Adjacency LSP (FA-LSP). Then the information of the link constructed Adjacency LSP (FA-LSP). Then the information of the link constructed
by this FA-LSP, called Forwarding Adjacency (FA), can be advertised by this FA-LSP can be advertised in the routing instance, so that the
in the routing instance, so that the H-Controller can be aware of H-Controller can be aware of this new FA. [RFC4206] and the
this new FA. [RFC4206] and the following updates to it (including following updates to it (including [RFC6001] and [RFC6107]) describe
[RFC6001] and [RFC6107]) describe the detailed extensions to support the detailed extensions to support advertisement of an FA.
advertisement of an FA.
If the higher-layer network and the lower-layer network are under If the higher-layer network and the lower-layer network are under
separate GMPLS control plane instances, or one of the layer networks separate GMPLS control plane instances or if one of the layer
is a non-GMPLS domain, after an H-LSP is created in the lower-layer networks is a non-GMPLS domain, after an H-LSP is created in the
network, the link discovery procedure will be triggered in the lower-layer network, the link discovery procedure will be triggered
higher-layer network to discover the information of the link in the higher-layer network to discover the information of the link
constructed by the H-LSP. LMP protocol defined in [RFC4204] can be constructed by the H-LSP. The LMP defined in [RFC4204] can be used
used if the higher-layer network supports GMPLS. The information of if the higher-layer network supports GMPLS. The information of this
this new link will be advertised to the H-Controller. new link will be advertised to the H-Controller.
8.4. Recovery 8.4. Recovery
The GMPLS recovery functions are described in [RFC4426]. Span The GMPLS recovery functions are described in [RFC4426]. Span
protection, end-to-end protection and restoration, are discussed protection and end-to-end protection and restoration are discussed
with different protection schemes and message exchange requirements. with different protection schemes and message exchange requirements.
Related RSVP-TE extensions to support end-to-end recovery is Related RSVP-TE extensions to support end-to-end recovery are
described in [RFC4872]. The extensions in [RFC4872] include described in [RFC4872]. The extensions in [RFC4872] include
protection, restoration, preemption, and rerouting mechanisms for an protection, restoration, preemption, and rerouting mechanisms for an
end-to-end LSP. Besides end-to-end recovery, a GMPLS segment end-to-end LSP. Besides end-to-end recovery, a GMPLS segment
recovery mechanism is defined in [RFC4873], which also intends to be recovery mechanism is defined in [RFC4873], which also intends to be
compatible with Fast Reroute (FRR) (see [RFC4090] which defines compatible with Fast Reroute (FRR) (see [RFC4090], which defines
RSVP-TE extensions for the FRR mechanism, and [RFC8271] which RSVP-TE extensions for the FRR mechanism, and [RFC8271], which
described the updates of GMPLS RSVP-TE protocol for FRR of GMPLS TE- describes the updates of the GMPLS RSVP-TE protocol for FRR of GMPLS
LSPs). TE-LSPs).
8.4.1. Span Protection 8.4.1. Span Protection
Span protection refers to the protection of the link between two Span protection refers to the protection of the link between two
neighboring switches. The main protocol requirements include: neighboring switches. The main protocol requirements include:
- Link management: Link property correlation on the link protection * Link management: Link property correlation on the link protection
type; type
- Routing: announcement of the link protection type; * Routing: Announcement of the link protection type
- Signaling: indication of link protection requirement for that LSP. * Signaling: Indication of link protection requirement for that LSP
GMPLS already supports the above requirements, and there are no new GMPLS already supports the above requirements, and there are no new
requirements in the scenario of interworking between GMPLS and requirements in the scenario of interworking between GMPLS and a
centralized controller system. centralized controller system.
8.4.2. LSP Protection 8.4.2. LSP Protection
The LSP protection includes end-to-end and segment LSP protection. The LSP protection includes end-to-end and segment LSP protection.
For both cases: For both cases:
- In the provisioning phase: * In the provisioning phase:
In both single-domain and multi-domain scenarios, the disjoint In both single-domain and multi-domain scenarios, the disjoint
path computation can be done by the centralized controller system, path computation can be done by the centralized controller system,
as it has the global topology and resource view. And the path as it has the global topology and resource view. And the path
creation can be done by the procedure described in Section 8.2. creation can be done by the procedure described in Section 8.2.
- In the protection switchover phase: * In the protection switchover phase:
In both single-domain and multi-domain scenarios, the existing In both single-domain and multi-domain scenarios, the existing
standards provide the distributed way to trigger the protection standards provide the distributed way to trigger the protection
switchover. For example, data plane Automatic Protection Switching switchover, for example, the data plane Automatic Protection
(APS) mechanism described in [G.808.1], [RFC7271] and [RFC8234], Switching (APS) mechanism described in [G.808.1], [RFC7271], and
or GMPLS Notify mechanism described in [RFC4872] and [RFC4873]. In [RFC8234] or the GMPLS Notify mechanism described in [RFC4872] and
the scenario of interworking between GMPLS and centralized [RFC4873]. In the scenario of interworking between GMPLS and a
controller system, using these distributed mechanisms rather than centralized controller system, using these distributed mechanisms
centralized mechanism (i.e., the controller triggers the rather than a centralized mechanism (i.e., the controller triggers
protection switchover) can significantly shorten the protection the protection switchover) can significantly shorten the
switching time. protection switching time.
8.4.3. Single-domain LSP Restoration 8.4.3. Single-Domain LSP Restoration
- Pre-planned LSP protection (including shared-mesh restoration): * Pre-planned LSP protection (including shared-mesh restoration):
In pre-planned protection, the protecting LSP is established only In pre-planned protection, the protecting LSP is established only
in the control plane in the provisioning phase, and will be in the control plane in the provisioning phase and will be
activated in the data plane once failure occurs. activated in the data plane once failure occurs.
In the scenario of interworking between GMPLS and centralized In the scenario of interworking between GMPLS and a centralized
controller system, the route of protecting LSP can be computed by controller system, the route of protecting LSP can be computed by
the centralized controller system. This takes the advantage of the centralized controller system. This takes the advantage of
making better use of network resource, especially for the resource making better use of network resources, especially for the
sharing in shared-mesh restoration. resource-sharing in shared-mesh restoration.
- Full LSP rerouting: * Full LSP rerouting:
In full LSP rerouting, the normal traffic will be switched to an In full LSP rerouting, the normal traffic will be switched to an
alternate LSP that is fully established only after failure alternate LSP that is fully established only after a failure
occurrence. occurrence.
As described in [RFC4872] and [RFC4873], the alternate route can As described in [RFC4872] and [RFC4873], the alternate route can
be computed on demand when failure occurrence, or pre-computed and be computed on demand when there is a failure occurrence or can be
stored before failure occurrence. pre-computed and stored before a failure occurrence.
In a fully distributed scenario, the pre-computation method offers In a fully distributed scenario, the pre-computation method offers
faster restoration time, but has the risk that the pre-computed 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 alternate route may become out-of-date due to the changes of the
network. network.
In the scenario of interworking between GMPLS and centralized In the scenario of interworking between GMPLS and a centralized
controller system, the pre-computation of the alternate route controller system, the pre-computation of the alternate route
could take place in the centralized controller (and may be stored 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, 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 any changes in the network can trigger the refreshment of the
alternate route by the centralized controller. This makes sure alternate route by the centralized controller. This makes sure
that the alternate route will not become out of date. that the alternate route will not become out-of-date.
8.4.4. Multi-domain LSP Restoration 8.4.4. Multi-Domain LSP Restoration
A working LSP may traverse multiple domains, each of which may or A working LSP may traverse multiple domains, each of which may or may
may not support GMPLS distributed control plane. not support a GMPLS distributed control plane.
If all the domains support GMPLS, both the end-to-end rerouting If all the domains support GMPLS, both the end-to-end rerouting
method and the domain segment rerouting method could be used. method and the domain segment rerouting method could be used.
If only some domains support GMPLS, the domain segment rerouting If only some domains support GMPLS, the domain segment rerouting
method could be used in those GMPLS domains. For other domains which method could be used in those GMPLS domains. For other domains that
do not support GMPLS, other mechanisms may be used to protect the do not support GMPLS, other mechanisms may be used to protect the LSP
LSP segments, which are out of scope of this document. segments, which are out of scope of this document.
1) End-to-end rerouting: 1) End-to-end rerouting:
In this scenario, a failure on the working LSP inside any domain or In this scenario, a failure on the working LSP inside any domain
on the inter-domain links will trigger the end-to-end restoration. or on the inter-domain links will trigger the end-to-end
restoration.
In both pre-planned and full LSP rerouting, the end-to-end In both pre-planned and full LSP rerouting, the end-to-end
protecting LSP could be computed by the centralized controller protecting LSP could be computed by the centralized controller
system, and could be created by the procedure described in Section system and could be created by the procedure described in
8.2. Note that the end-to-end protecting LSP may traverse different Section 8.2. Note that the end-to-end protecting LSP may
domains from the working LSP, depending on the result of multi- traverse different domains from the working LSP, depending on the
domain path computation for the protecting LSP. result of multi-domain path computation for the protecting LSP.
+----------------+ +----------------+
|Orchestrator(MD)| |Orchestrator(MD)|
+-------.--------+ +-------.--------+
............................................ ............................................
. . . . . . . .
+----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+
|Controller| |Controller| |Controller| |Controller| |Controller| |Controller| |Controller| |Controller|
| (G) 1 | | (G) 2 | | (G) 3 | | (G) 4 | | (G) 1 | | (G) 2 | | (G) 3 | | (G) 4 |
+----.-----+ +-------.--+ +-------.--+ +----.-----+ +----.-----+ +-------.--+ +-------.--+ +----.-----+
. . . . . . . .
+----V--------+ +-V-----------+ . +-------V-----+ +----V--------+ +-V-----------+ . +-------V-----+
| Domain 1 | | Domain 2 | . | Domain 4 | | Domain 1 | | Domain 2 | . | Domain 4 |
|+---+ +---+| |+---+ +---+| . |+---+ +---+| |+---+ +---+| |+---+ +---+| . |+---+ +---+|
|| ===/~/======/~~~/================================ || || ===/~/======/~~~/================================ ||
|+-*-+ +---+| |+---+ +---+| . |+---+ +-*-+| |+-*-+ +---+| |+---+ +---+| . |+---+ +-*-+|
| * | +-------------+ . | * | | * | +-------------+ . | * |
| * | . | * | | * | . | * |
| * | +-------------+ . | * | | * | +-------------+ . | * |
| * | | Domain 3 <... | * | | * | | Domain 3 <... | * |
|+-*-+ +---+| |+---+ +---+| |+---+ +-*-+| |+-*-+ +---+| |+---+ +---+| |+---+ +-*-+|
|| ************************************************* || || ************************************************* ||
|+---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+|
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
====: Working LSP ****: Protecting LSP /~/: Failure ====: Working LSP ****: Protecting LSP /~/: Failure
Figure 5: End-to-end restoration Figure 5: End-to-End Restoration
2) Domain segment rerouting: 2) Domain segment rerouting:
2.1) Intra-domain rerouting: 2.1) Intra-domain rerouting:
If failure occurs on the working LSP segment in a GMPLS domain, the If failure occurs on the working LSP segment in a GMPLS
segment rerouting ([RFC4873]) could be used for the working LSP domain, the segment rerouting [RFC4873] could be used for
segment in that GMPLS domain. Figure 6 shows an example of intra- the working LSP segment in that GMPLS domain. Figure 6
domain rerouting. shows an example of intra-domain rerouting.
The intra-domain rerouting of a non-GMPLS domain is out of scope of The intra-domain rerouting of a non-GMPLS domain is out of
this document. scope of this document.
+----------------+ +----------------+
|Orchestrator(MD)| |Orchestrator(MD)|
+-------.--------+ +-------.--------+
............................................ ............................................
. . . . . . . .
+----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+ +----V-----+
|Controller| |Controller| |Controller| |Controller| |Controller| |Controller| |Controller| |Controller|
| (G) 1 | |(G)/(N) 2 | |(G)/(N) 3 | |(G)/(N) 4 | | (G) 1 | |(G)/(N) 2 | |(G)/(N) 3 | |(G)/(N) 4 |
+----.-----+ +-------.--+ +-------.--+ +----.-----+ +----.-----+ +-------.--+ +-------.--+ +----.-----+
. . . . . . . .
+----V--------+ +-V-----------+ . +-------V-----+ +----V--------+ +-V-----------+ . +-------V-----+
| Domain 1 | | Domain 2 | . | Domain 4 | | Domain 1 | | Domain 2 | . | Domain 4 |
|+---+ +---+| |+---+ +---+| . |+---+ +---+| |+---+ +---+| |+---+ +---+| . |+---+ +---+|
|| ===/~/=========================================== || || ===/~/=========================================== ||
|+-*-+ +-*-+| |+---+ +---+| . |+---+ +---+| |+-*-+ +-*-+| |+---+ +---+| . |+---+ +---+|
| * * | +-------------+ . | | | * * | +-------------+ . | |
| * * | . | | | * * | . | |
| * * | +-------------+ . | | | * * | +-------------+ . | |
| * * | | Domain 3 <... | | | * * | | Domain 3 <... | |
|+-*-+ +-*-+| |+---+ +---+| |+---+ +---+| |+-*-+ +-*-+| |+---+ +---+| |+---+ +---+|
|| ********* || || | | || || | | || || ********* || || | | || || | | ||
|+---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+|
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
====: Working LSP ****: Rerouting LSP segment /~/: Failure ====: Working LSP ****: Rerouting LSP segment /~/: Failure
Figure 6: Intra-domain segment rerouting Figure 6: Intra-Domain Segment Rerouting
2.2) Inter-domain rerouting: 2.2) Inter-domain rerouting:
If intra-domain segment rerouting failed (e.g., due to lack of If intra-domain segment rerouting failed (e.g., due to lack
resource in that domain), or if failure occurs on the working LSP on of resource in that domain), or if failure occurs on the
an inter-domain link, the centralized controller system may working LSP on an inter-domain link, the centralized
coordinate with other domain(s), to find an alternative path or path controller system may coordinate with other domain(s) to
segment to bypass the failure, and then trigger the inter-domain find an alternative path or path segment to bypass the
rerouting procedure. Note that the rerouting path or path segment failure and then trigger the inter-domain rerouting
may traverse different domains from the working LSP. procedure. Note that the rerouting path or path segment
may traverse different domains from the working LSP.
The domains involved in the inter-domain rerouting procedure need to The domains involved in the inter-domain rerouting
be GMPLS domains, which support the RSVP-TE signaling for the procedure need to be GMPLS domains, which support the RSVP-
creation of rerouting LSP segment. TE signaling for the creation of a rerouting LSP segment.
For inter-domain rerouting, the interaction between GMPLS and For inter-domain rerouting, the interaction between GMPLS
centralized controller system is needed: and a centralized controller system is needed:
- Report of the result of intra-domain segment rerouting to its * A report of the result of intra-domain segment rerouting
Controller(G), and then to the Orchestrator(MD). The former one to its Controller(G) and then to the Orchestrator(MD).
could be supported by the PCRpt message in [RFC8231], while the The former could be supported by the PCRpt message in
latter one could be supported by the MPI interface of ACTN. [RFC8231], while the latter could be supported by the
MPI of ACTN.
- Report of inter-domain link failure to the two Controllers (e.g., * A report of inter-domain link failure to the two
Controller(G) 1 and Controller(G) 2 in Figure 7) by which the two Controllers (e.g., Controller(G) 1 and Controller(G) 2
ends of the inter-domain link are controlled respectively, and in Figure 7) by which the two ends of the inter-domain
then to the Orchestrator(MD). The former one could be done as link are controlled, respectively, and then to the
described in Section 8.1 of this document, while the latter one Orchestrator(MD). The former could be done as described
could be supported by the MPI interface of ACTN. in Section 8.1, while the latter could be supported by
the MPI of ACTN.
- Computation of rerouting path or path segment crossing multi- * The computation of a rerouting path or path segment
domains by the centralized controller system (see [PAT-COMP]); crossing multi-domains by the centralized controller
system (see [PATH-COMP]);
- Creation of rerouting LSP segment in each related domain. The * The creation of a rerouting LSP segment in each related
Orchestrator(MD) can send the LSP segment rerouting request to the domain. The Orchestrator(MD) can send the LSP segment
source Controller(G) (e.g., Controller(G) 1 in Figure 7) via MPI rerouting request to the source Controller(G) (e.g.,
interface, and then the Controller(G) can trigger the creation of Controller(G) 1 in Figure 7) via MPI interface, and then
rerouting LSP segment through multiple GMPLS domains using GMPLS the Controller(G) can trigger the creation of a
rerouting signaling. Note that the rerouting LSP segment may rerouting LSP segment through multiple GMPLS domains
traverse a new domain which the working LSP does not traverse using GMPLS rerouting signaling. Note that the
(e.g., Domain 3 in Figure 7). rerouting LSP segment may traverse a new domain that the
working LSP does not traverse (e.g., Domain 3 in
Figure 7).
+----------------+ +----------------+
|Orchestrator(MD)| |Orchestrator(MD)|
+-------.--------+ +-------.--------+
.................................................. ..................................................
. . . . . . . .
+-----V------+ +-----V------+ +-----V------+ +-----V------+ +-----V------+ +-----V------+ +-----V------+ +-----V------+
| Controller | | Controller | | Controller | | Controller | | Controller | | Controller | | Controller | | Controller |
| (G) 1 | | (G) 2 | | (G) 3 | | (G)/(N) 4 | | (G) 1 | | (G) 2 | | (G) 3 | | (G)/(N) 4 |
+-----.------+ +------.-----+ +-----.------+ +-----.------+ +-----.------+ +------.-----+ +-----.------+ +-----.------+
. . . . . . . .
+-----V-------+ +----V--------+ . +------V------+ +-----V-------+ +----V--------+ . +------V------+
| Domain 1 | | Domain 2 | . | Domain 4 | | Domain 1 | | Domain 2 | . | Domain 4 |
|+---+ +---+| |+---+ +---+| . |+---+ +---+| |+---+ +---+| |+---+ +---+| . |+---+ +---+|
|| | | || || | | || . || | | || || | | || || | | || . || | | ||
|| ============/~/========================================== || || ============/~/========================================== ||
|| * | | || || | | * || . || | | || || * | | || || | | * || . || | | ||
|+-*-+ +---+| |+---+ +-*-+| . |+---+ +---+| |+-*-+ +---+| |+---+ +-*-+| . |+---+ +---+|
| * | +----------*--+ . | | | * | +----------*--+ . | |
| * | ***** . | | | * | ***** . | |
| * | +----------*-----V----+ | | | * | +----------*-----V----+ | |
| * | | *Domain 3 | | | | * | | *Domain 3 | | |
|+-*-+ +---+| |+---+ +-*-+ +---+| |+---+ +---+| |+-*-+ +---+| |+---+ +-*-+ +---+| |+---+ +---+|
|| * | | || || | | * | | || || | | || || * | | || || | | * | | || || | | ||
|| ******************************* | | || || | | || || ******************************* | | || || | | ||
|| | | || || | | | | || || | | || || | | || || | | | | || || | | ||
|+---+ +---+| |+---+ +---+ +---+| |+---+ +---+| |+---+ +---+| |+---+ +---+ +---+| |+---+ +---+|
+-------------+ +---------------------+ +-------------+ +-------------+ +---------------------+ +-------------+
====: Working LSP ****: Rerouting LSP segment /~/: Failure ====: Working LSP ****: Rerouting LSP segment /~/: Failure
Figure 7: Inter-domain segment rerouting Figure 7: Inter-Domain Segment Rerouting
8.4.5. Fast Reroute 8.4.5. Fast Reroute
[RFC4090] defines two methods of fast reroute, the one-to-one backup [RFC4090] defines two methods of fast reroute: the one-to-one backup
method and the facility backup method. For both methods: method and the facility backup method. For both methods:
1) Path computation of protecting LSP: 1) Path computation of protecting LSP:
In Section 6.2 of [RFC4090], the protecting LSP (detour LSP in one- In Section 6.2 of [RFC4090], the protecting LSP (detour LSP in
to-one backup, or bypass tunnel in facility backup) could be one-to-one backup or bypass tunnel in facility backup) could be
computed by the Point of Local Repair (PLR) using, for example, computed by the Point of Local Repair (PLR) using, for example, a
Constraint-based Shortest Path First (CSPF) computation. In the Constrained Shortest Path First (CSPF) computation. In the
scenario of interworking between GMPLS and centralized controller scenario of interworking between GMPLS and a centralized
system, the protecting LSP could also be computed by the centralized controller system, the protecting LSP could also be computed by
controller system, as it has the global view of the network the centralized controller system, as it has the global view of
topology, resource and information of LSPs. the network topology, resources, and information of LSPs.
2) Protecting LSP creation: 2) Protecting LSP creation:
In the scenario of interworking between GMPLS and centralized In the scenario of interworking between GMPLS and a centralized
controller system, the Protecting LSP could still be created by the controller system, the protecting LSP could still be created by
RSVP-TE signaling protocol as described in [RFC4090] and [RFC8271]. the RSVP-TE signaling protocol as described in [RFC4090] and
[RFC8271].
In addition, if the protecting LSP is computed by the centralized In addition, if the protecting LSP is computed by the centralized
controller system, the Secondary Explicit Route Object defined in controller system, the Secondary Explicit Route Object defined in
[RFC4873] could be used to explicitly indicate the route of the [RFC4873] could be used to explicitly indicate the route of the
protecting LSP. protecting LSP.
3) Failure detection and traffic switchover: 3) Failure detection and traffic switchover:
If a PLR detects that failure occurs, it may significantly shorten If a PLR detects that failure occurs, it may significantly
the protection switching time by using the distributed mechanisms shorten the protection switching time by using the distributed
described in [RFC4090] to switch the traffic to the related detour mechanisms described in [RFC4090] to switch the traffic to the
LSP or bypass tunnel, rather than in a centralized way. related detour LSP or bypass tunnel rather than doing so in a
centralized way.
8.5. Controller Reliability 8.5. Controller Reliability
The reliability of the controller is crucial due to its important The reliability of the controller is crucial due to its important
role in the network. It is essential that if the controller is shut role in the network. It is essential that if the controller is shut
down or disconnected from the network, all currently provisioned down or disconnected from the network, all currently provisioned
services in the network continue to function and carry traffic. In services in the network continue to function and carry traffic. In
addition, protection switching to pre-established paths should also addition, protection switching to pre-established paths should also
work. It is desirable to have protection mechanisms, such as work. It is desirable to have protection mechanisms, such as
redundancy, to maintain full operational control even if one redundancy, to maintain full operational control even if one instance
instance of the controller fails. This can be achieved through of the controller fails. This can be achieved through controller
controller backup or functionality backup. There are several backup or functionality backup. There are several controller backup
controller backup or federation mechanisms in the literature. It is or federation mechanisms in the literature. It is also more reliable
also more reliable to have function backup in the network element to to have function backup in the network element to guarantee
guarantee performance in the network. performance in the network.
9. Manageability Considerations 9. Manageability Considerations
Each network entity, including controllers and network elements, Each network entity, including controllers and network elements,
should be managed properly and with the relevant trust and security should be managed properly and with the relevant trust and security
policies applied (see Section 10 of this document), as they will policies applied (see Section 10), as they will interact with other
interact with other entities. The manageability considerations in entities. The manageability considerations in controller hierarchies
controller hierarchies and network elements still apply, and network elements still apply, respectively. The overall
respectively. The overall manageability of the protocols applied in manageability of the protocols applied in the network should also be
the network should also be a key consideration. a key consideration.
The responsibility of each entity should be clarified. The control The responsibility of each entity should be clarified. The control
of function and policy among different controllers should be of function and policy among different controllers should be
consistent via a proper negotiation process. consistent via a proper negotiation process.
10. Security Considerations 10. Security Considerations
This document outlines the interworking between GMPLS and controller This document outlines the interworking between GMPLS and controller
hierarchies. The security requirements specific to both systems hierarchies. The security requirements specific to both systems
remain applicable. Protocols referenced herein possess security remain applicable. Protocols referenced herein possess security
considerations, which must be adhered to, with their core considerations, which must be adhered to, with their core
specifications and identified risks detailed earlier in this specifications and identified risks detailed earlier in this
document. document.
Security is a critical aspect in both GMPLS and controller-based Security is a critical aspect in both GMPLS and controller-based
networks. Ensuring robust security mechanisms in these environments networks. Ensuring robust security mechanisms in these environments
is paramount to safeguard against potential threats and is paramount to safeguard against potential threats and
vulnerabilities. Below are expanded security considerations and some vulnerabilities. Below are expanded security considerations and some
relevant IETF RFC references. relevant IETF RFC references.
- Authentication and Authorization: It is essential to implement * Authentication and Authorization: It is essential to implement
strong authentication and authorization mechanisms to control strong authentication and authorization mechanisms to control
access to the controller from multiple network elements. This access to the controller from multiple network elements. This
ensures that only authorized devices and users can interact with ensures that only authorized devices and users can interact with
the controller, preventing unauthorized access that could lead to the controller, preventing unauthorized access that could lead to
network disruptions or data breaches. Transport Layer Security network disruptions or data breaches. "The Transport Layer
(TLS) Protocol [RFC8446] and Enrollment over Secure Transport Security (TLS) Protocol Version 1.3" [RFC8446] and "Enrollment
[RFC7030] provide guidelines on secure communication and over Secure Transport" [RFC7030] provide guidelines on secure
certificate-based authentication that can be leveraged for these communication and certificate-based authentication that can be
purposes. leveraged for these purposes.
- Controller Security: The controller's security is crucial as it * Controller Security: The controller's security is crucial as it
serves as the central control point for the network elements. The serves as the central control point for the network elements. The
controller must be protected against various attacks, such as controller must be protected against various attacks, such as
Denial-of-Service (DoS), Man-In-The-Middle (MITM), and Denial of Service (DoS), Man in the Middle (MITM), and
unauthorized access. Security mechanisms should include regular unauthorized access. Security mechanisms should include regular
security audits, application of security patches, and firewalls security audits, application of security patches, firewalls, and
and Intrusion Detection/Prevention Systems (IDS/IPS). Intrusion Detection Systems (IDSs) / Intrusion Prevention Systems
(IPSs).
- Data Transport Security: Security mechanisms on the controller * Data Transport Security: Security mechanisms on the controller
should also safeguard the underlying network elements against should also safeguard the underlying network elements against
unauthorized usage of data transport resources. This includes unauthorized usage of data transport resources. This includes
encryption of data in transit to prevent eavesdropping and encryption of data in transit to prevent eavesdropping and
tampering, as well as ensuring data integrity and confidentiality. tampering as well as ensuring data integrity and confidentiality.
- Secure Protocol Implementation: Protocols used within the GMPLS * Secure Protocol Implementation: Protocols used within the GMPLS
and controller frameworks must be implemented with security in and controller frameworks must be implemented with security in
mind. Known vulnerabilities should be addressed, and secure mind. Known vulnerabilities should be addressed, and secure
versions of protocols should be used wherever possible. versions of protocols should be used wherever possible.
Finally, robust network security often depends on Indicators of Finally, robust network security often depends on Indicators of
Compromise (IoCs) to detect, trace, and prevent malicious activities Compromise (IoCs) to detect, trace, and prevent malicious activities
in networks or endpoints. These are described in [RFC9424] along in networks or endpoints. These are described in [RFC9424] along
with the fundamentals, opportunities, operational limitations, and with the fundamentals, opportunities, operational limitations, and
recommendations for IoC use. recommendations for IoC use.
11. IANA Considerations 11. IANA Considerations
This document requires no IANA actions. This document has no IANA actions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003. DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630,
2003. DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004. Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<https://www.rfc-editor.org/info/rfc3945>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC4206] Kompella, K. and Rekhter Y., "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4655, August 2006. Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007. Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008. (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6001] Papadimitriou D., Vigoureux M., Shiomoto K., Brungard D. [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
and Le Roux JL., "Generalized MPLS (GMPLS) Protocol D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks Extensions for Multi-Layer and Multi-Region Networks (MLN/
(MLN/MRN)", RFC 6001, October 2010. MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010,
<https://www.rfc-editor.org/info/rfc6001>.
[RFC6107] Shiomoto K. and Farrel A., "Procedures for Dynamically [RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for
Signaled Hierarchical Label Switched Paths", RFC 6107, Dynamically Signaled Hierarchical Label Switched Paths",
February 2011. RFC 6107, DOI 10.17487/RFC6107, February 2011,
<https://www.rfc-editor.org/info/rfc6107>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
"Network Configuration Protocol (NETCONF)", RFC 6241, June and A. Bierman, Ed., "Network Configuration Protocol
2011. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7030] Pritikin, M., Yee, P. and Harkins, D., "Enrollment over [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
Secure Transport", RFC 7030, October 2013. "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS
Switching Capability and Type Fields", RFC 7074, November Switching Capability and Type Fields", RFC 7074,
2013. DOI 10.17487/RFC7074, November 2013,
<https://www.rfc-editor.org/info/rfc7074>.
[RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, March Application-Based Network Operations", RFC 7491,
2015. DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>.
[RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
D. and Zhang, X., "Problem Statement and Architecture for Ceccarelli, D., and X. Zhang, "Problem Statement and
Information Exchange between Interconnected Traffic- Architecture for Information Exchange between
Engineered Networks", RFC 7926, July 2016. Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
7950, August 2016. RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017. Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8271] Taillon M., Saad T., Gandhi R., Ali Z. and Bhatia M., [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
"Updates to the Resource Reservation Protocol for Fast M. Bhatia, "Updates to the Resource Reservation Protocol
Reroute of Traffic Engineering GMPLS Label Switched for Fast Reroute of Traffic Engineering GMPLS Label
Paths", RFC 8271, October 2017. Switched Paths (LSPs)", RFC 8271, DOI 10.17487/RFC8271,
October 2017, <https://www.rfc-editor.org/info/rfc8271>.
[RFC8282] Oki E., Takeda T., Farrel A. and Zhang F., "Extensions to [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions
the Path Computation Element Communication Protocol (PCEP) to the Path Computation Element Communication Protocol
for Inter-Layer MPLS and GMPLS Traffic Engineering", RFC (PCEP) for Inter-Layer MPLS and GMPLS Traffic
8282, December 2017. Engineering", RFC 8282, DOI 10.17487/RFC8282, December
2017, <https://www.rfc-editor.org/info/rfc8282>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018. Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Control of Traffic Engineered Networks", RFC 8453, August Abstraction and Control of TE Networks (ACTN)", RFC 8453,
2018. DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8685] Zhang F., Zhao Q., Gonzalez de Dios O., Casellas R. and [RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
King D., "Path Computation Element Communication Protocol and D. King, "Path Computation Element Communication
(PCEP) Extensions for the Hierarchical Path Computation Protocol (PCEP) Extensions for the Hierarchical Path
Element (H-PCE) Architecture", RFC 8685, December 2019. Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
Gonzalez De Dios, O., "YANG Data Model for Traffic O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795, August 2020. Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[RFC9424] Paine, K., Whitehouse, O., Sellwood, J. and Shaw, A., [RFC9424] Paine, K., Whitehouse, O., Sellwood, J., and A. Shaw,
"Indicators of Compromise (IoCs) and Their Role in Attack "Indicators of Compromise (IoCs) and Their Role in Attack
Defence", RFC 9424, August 2023. Defence", RFC 9424, DOI 10.17487/RFC9424, August 2023,
<https://www.rfc-editor.org/info/rfc9424>.
12.2. Informative References 12.2. Informative References
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label [G.808.1] ITU-T, "Generic protection switching - Linear trail and
Switching (GMPLS) Signaling Functional Description", RFC subnetwork protection", ITU-T Recommendation G.808.1, May
3471, January 2003. 2014, <https://www.itu.int/rec/T-REC-G.808.1-201405-I/en>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [PATH-COMP]
in Support of Generalized Multi-Protocol Label Switching Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y.
(GMPLS)", RFC 4202, October 2005. Shi, "A YANG Data Model for requesting path computation",
Work in Progress, Internet-Draft, draft-ietf-teas-yang-
path-computation-24, 13 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-path-computation-24>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, [PCEP-LS] Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A.,
October 2005. and G. S. Mishra, "PCEP extensions for Distribution of
Link-State and TE Information", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-ls-02, 20 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-ls-02>.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Ed., "Generalized Multi-Protocol Label witching (GMPLS) Switching (GMPLS) Signaling Functional Description",
Recovery Functional Specification", RFC 4426, March 2006. RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A., [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
"Label Switched Path Stitching with Generalized in Support of Generalized Multi-Protocol Label Switching
Multiprotocol Label Switching Traffic Engineering (GMPLS (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
TE)", RFC 5150, February, 2008. <https://www.rfc-editor.org/info/rfc4202>.
[RFC5212] Shiomoto K., Papadimitriou D., Le Roux JL., Vigoureux M. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
and Brungard D., "Requirements for GMPLS-Based Multi- DOI 10.17487/RFC4204, October 2005,
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July <https://www.rfc-editor.org/info/rfc4204>.
2008.
[RFC5441] Vasseur JP., Zhang R., Bitar N. and Le Roux JL., "A [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Backward-Recursive PCE-Based Computation (BRPC) Procedure Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
to Compute Shortest Constrained Inter-Domain Traffic Recovery Functional Specification", RFC 4426,
Engineering Label Switched Paths", RFC 5441, April 2009. DOI 10.17487/RFC4426, March 2006,
<https://www.rfc-editor.org/info/rfc4426>.
[RFC5623] Oki E., Takeda T., Le Roux JL. and Farrel A., "Framework [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
for PCE-Based Inter-Layer MPLS and GMPLS Traffic "Label Switched Path Stitching with Generalized
Engineering", RFC 5623, September 2009. Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
<https://www.rfc-editor.org/info/rfc5150>.
[RFC5654] Niven-Jenkins B., Ed., Brungard D., Ed., Betts M., Ed., [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
Sprecher N., Ueno S., "Requirements of an MPLS Transport M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Profile", RFC 5654, September 2009. Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008,
<https://www.rfc-editor.org/info/rfc5212>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
J. Drake, "Traffic Engineering Extensions to OSPF for "A Backward-Recursive PCE-Based Computation (BRPC)
GMPLS Control of Evolving G.709 Optical Transport Procedure to Compute Shortest Constrained Inter-Domain
Networks", RFC 7138, March 2014. Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
and K. Pithewan, "GMPLS Signaling Extensions for Control "Framework for PCE-Based Inter-Layer MPLS and GMPLS
of Evolving G.709 Optical Transport Networks", RFC 7139, Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
March 2014. September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
D'Alessandro, A., Cheung, T., and Osborne, E., "MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
Operational Expectations of Synchronous Digital Hierarchy, September 2009, <https://www.rfc-editor.org/info/rfc5654>.
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, June 2014.
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
Enhancement for Signal and Network Element Compatibility J. Drake, "Traffic Engineering Extensions to OSPF for
for Wavelength Switched Optical Networks", RFC 7688, GMPLS Control of Evolving G.709 Optical Transport
November 2015. Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and H. Harai, "Signaling Extensions for Wavelength and K. Pithewan, "GMPLS Signaling Extensions for Control
Switched Optical Networks", RFC 7689, November 2015. of Evolving G.709 Optical Transport Networks", RFC 7139,
DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/info/rfc7139>.
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Support of Flexi-Grid Dense Wavelength Division Transport Profile (MPLS-TP) Linear Protection to Match the
Multiplexing (DWDM) Networks", RFC 7792, March 2016. Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<https://www.rfc-editor.org/info/rfc7271>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF
Computation Element Communication Protocol (PCEP) Enhancement for Signal and Network Element Compatibility
Extensions for Stateful PCE", RFC 8231, September 2017. for Wavelength Switched Optical Networks", RFC 7688,
DOI 10.17487/RFC7688, November 2015,
<https://www.rfc-editor.org/info/rfc7688>.
[RFC8234] Ryoo, J., Cheung, T., van Helvoort, H., Busi, I. and Wen [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
G., "Updates to MPLS Transport Profile (MPLS-TP) Linear and H. Harai, "Signaling Extensions for Wavelength
Protection in Automatic Protection Switching (APS) Mode", Switched Optical Networks", RFC 7689,
RFC 8234, August 2017. DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
Extensions for PCE-initiated LSP Setup in a Stateful PCE and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Model", RFC 8281, October 2017. Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Ananthakrishnan, H., Liu, X., "A YANG Data Model for Computation Element Communication Protocol (PCEP)
Network Topologies", RFC 8345, March 2018. Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. [RFC8234] Ryoo, J., Cheung, T., van Helvoort, H., Busi, I., and G.
Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- Wen, "Updates to MPLS Transport Profile (MPLS-TP) Linear
grid DWDM networks", RFC 8363, February 2017. Protection in Automatic Protection Switching (APS) Mode",
RFC 8234, DOI 10.17487/RFC8234, August 2017,
<https://www.rfc-editor.org/info/rfc8234>.
[PAT-COMP] Busi, I., Belotti, S., Gonzalez de Dios, O., Sharma, A., [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Shi, Y., "Yang model for requesting Path Computation", Computation Element Communication Protocol (PCEP)
draft-ietf-teas-yang-path-computation, work in progress. Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[PCEP-LS] Dhody, D., Peng S., Lee, Y., Ceccarelli, D., Wang A. and [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Mishra G., "PCEP Extensions for Distribution of Link-State Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
and TE Information", draft-ietf-pce-pcep-ls, work in Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
progress. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic [RFC8363] Zhang, X., Zheng, H., Casellas, R., Gonzalez de Dios, O.,
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- and D. Ceccarelli, "GMPLS OSPF-TE Extensions in Support of
te, work in progress. Flexi-Grid Dense Wavelength Division Multiplexing (DWDM)
Networks", RFC 8363, DOI 10.17487/RFC8363, May 2018,
<https://www.rfc-editor.org/info/rfc8363>.
[sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter- [SPCE-ID] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Domain Tunnels", draft-ietf-pce-stateful-interdomain, work Extension for Stateful Inter-Domain Tunnels", Work in
in progress. Progress, Internet-Draft, draft-ietf-pce-stateful-
interdomain-07, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
stateful-interdomain-07>.
[G.808.1] ITU-T, "Generic protection switching - Linear trail and [YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
subnetwork protection", G.808.1, May 2014. Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>.
13. Contributors Acknowledgements
The authors would like to thank Jim Guichard, Area Director of IETF
Routing Area; Vishnu Pavan Beeram, Chair of TEAS WG; Jia He and
Stewart Bryant, RTGDIR reviewers; Thomas Fossati, Gen-ART reviewer;
Yingzhen Qu, OPSDIR reviewer; David Mandelberg, SECDIR reviewer;
David Dong, IANA Services Sr. Specialist; and Éric Vyncke and Murray
Kucherawy, IESG reviewers for their reviews and comments on this
document.
Contributors
Xianlong Luo Xianlong Luo
Huawei Technologies Huawei Technologies
G1, Huawei Xiliu Beipo Village, Songshan Lake G1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan Dongguan
Guangdong, 523808 China Guangdong, 523808
China
Email: luoxianlong@huawei.com Email: luoxianlong@huawei.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
14. Authors' Addresses Authors' Addresses
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan Dongguan
Guangdong, 523808 China Guangdong, 523808
China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Yunbin Xu Yi Lin
CAICT Huawei Technologies
Email: xuyunbin@caict.ac.cn H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: yi.lin@huawei.com
Yang Zhao Yang Zhao
China Mobile China Mobile
Email: zhaoyangyjy@chinamobile.com Email: zhaoyangyjy@chinamobile.com
Yunbin Xu
CAICT
Email: xuyunbin@caict.ac.cn
Dieter Beller Dieter Beller
Nokia Nokia
Email: Dieter.Beller@nokia.com Email: Dieter.Beller@nokia.com
Yi Lin
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808 China
Email: yi.lin@huawei.com
Acknowledgements
The authors would like to thank Jim Guichard, Area Director of IETF
Routing Area, Vishnu Pavan Beeram, Chair of TEAS WG, Jia He and
Stewart Bryant, rtgdir reviewers, Thomas Fossati, Gen-ART reviewer,
Yingzhen Qu, opsdir reviewer, David Mandelberg, secdir reviewer,
David Dong, IANA Services Sr. Specialist, and Éric Vyncke and Murray
Kucherawy, IESG reviewers, for their reviews and comments on this
document.
 End of changes. 311 change blocks. 
993 lines changed or deleted 1131 lines changed or added

This html diff was produced by rfcdiff 1.48.