Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China zhenghaomian@huawei.com

Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China yi.lin@huawei.com

China Mobile

zhaoyangyjy@chinamobile.com

CAICT

xuyunbin@caict.ac.cn

Nokia

Dieter.Beller@nokia.com

RTG teas architecture ACTN control plane Generalized Multiprotocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing, and signaling in a distributed manner. The advancement of software-defined transport networking technology enables a group of NEs to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic-Engineered Networks (ACTN) controller hierarchy, as described in RFC 8453. Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than compete. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Abbreviations
• .  Overview
  • .  Overview of GMPLS Control Plane
  • .  Overview of Centralized Controller System
  • .  GMPLS Control Interworking with a Centralized Controller System
• .  Discovery Options
  • .  LMP
• .  Routing Options
  • .  OSPF-TE
  • .  IS-IS-TE
  • .  NETCONF/RESTCONF
• .  Path Computation
  • .  Controller-Based Path Computation
  • .  Constraint-Based Path Computing in GMPLS Control
  • .  Path Computation Element (PCE)
• .  Signaling Options
  • .  RSVP-TE
• .  Interworking Scenarios
  • .  Topology Collection and Synchronization
  • .  Multi-Domain Service Provisioning
  • .  Multi-Layer Service Provisioning
    • .  Multi-Layer Path Computation
    • .  Cross-Layer Path Creation
    • .  Link Discovery
  • .  Recovery
    • .  Span Protection
    • .  LSP Protection
    • .  Single-Domain LSP Restoration
    • .  Multi-Domain LSP Restoration
    • .  Fast Reroute
  • .  Controller Reliability
• .  Manageability Considerations
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction Generalized Multiprotocol Label Switching (GMPLS) extends MPLS to support different classes of interfaces and switching capabilities such as Time-Division Multiplex Capable (TDM), Lambda Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network element (NE) running a GMPLS control plane collects network information from other NEs and supports service provisioning through signaling in a distributed manner. A more generic description of traffic-engineering networking information exchange can be found in . On the other hand, Software-Defined Networking (SDN) technologies have been introduced to control the transport network centrally. Centralized controllers can collect network information from each node and provision services on corresponding nodes. One example is the Abstraction and Control of Traffic-Engineered Networks (ACTN) , which defines a hierarchical architecture with the Provisioning Network Controller (PNC), Multi-Domain Service Coordinator (MDSC), and Customer Network Controller (CNC) as centralized controllers for different network abstraction levels. A PCE-based approach has been proposed in : Application-Based Network Operations (ABNO). GMPLS can be used to control network elements (NEs) in such centralized controller architectures. A centralized controller may support GMPLS-enabled domains and communicate with a GMPLS-enabled domain where the GMPLS control plane handles service provisioning from ingress to egress. In this scenario, the centralized controller sends a request to the entry node and does not need to configure all NEs along the path within the domain from ingress to egress, thus leveraging the GMPLS control plane. This document describes how the GMPLS control plane interworks with a centralized controller system in a transport network.

Abbreviations The following abbreviations are used in this document.

ACTN:

Abstraction and Control of Traffic-Engineered Networks

APS:

Automatic Protection Switching

BRPC:

Backward Recursive PCE-Based Computation

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

H-PCE:

Hierarchical PCE

IDS:

Intrusion Detection System

IGP:

Interior Gateway Protocol

IoCs:

Indicators of Compromise

IPS:

Intrusion Prevention System

IS-IS:

Intermediate System to Intermediate System

LMP:

Link Management Protocol

LSP:

Label Switched Path

LSP-DB:

LSP Database

MD:

multi-domain

MDSC:

Multi-Domain Service Coordinator

MITM:

Man in the Middle

ML:

multi-layer

MPI:

MDSC to PNC Interface

NE:

network element

NETCONF:

Network Configuration Protocol

NMS:

Network Management System

OSPF:

Open Shortest Path First

PCC:

Path Computation Client

PCE:

Path Computation Element

PCEP:

PCE Communication Protocol

PCEP-LS:

Link State PCEP

PLR:

Point of Local Repair

PNC:

Provisioning Network Controller

RSVP:

Resource Reservation Protocol

SBI:

Southbound Interface

SDN:

Software-Defined Networking

TE:

Traffic Engineering

TED:

Traffic Engineering Database

TLS:

Transport Layer Security

VNTM:

Virtual Network Topology Manager

Overview This section provides an overview of the GMPLS control plane, centralized controller systems, and their interactions in transport networks. A transport network is a server-layer network designed to provide connectivity services for client-layer connectivity. This setup allows client traffic to be carried seamlessly across the server-layer network resources.

Overview of GMPLS Control Plane GMPLS separates the control plane and the data plane to support time-division, wavelength, and spatial switching, which are significant in transport networks. For the NE level control in GMPLS, each node runs a GMPLS control plane instance. Functionalities such as service provisioning, protection, and restoration can be performed via GMPLS communication among multiple NEs. At the same time, the GMPLS control plane instance can also collect information about node and link resources in the network to construct the network topology and compute routing paths for serving service requests. Several protocols have been designed for the GMPLS control plane , including link management , signaling , and routing protocols. The GMPLS control plane instances applying these protocols communicate with each other to exchange resource information and establish LSPs. In this way, GMPLS control plane instances in different nodes in the network have the same view of the network topology and provision services based on local policies.

Overview of Centralized Controller System With the development of SDN technologies, a centralized controller architecture has been introduced to transport networks. One example architecture can be found in ACTN . In such systems, a controller is aware of the network topology and is responsible for provisioning incoming service requests. Multiple hierarchies of controllers are designed at different levels to implement different functions. This kind of architecture enables multi-vendor, multi-domain, and multi-technology control. For example, a higher-level controller coordinates several lower-level controllers controlling different domains for topology collection and service provisioning. Vendor-specific features can be abstracted between controllers, and a standard API (e.g., generated from RESTCONF / YANG ) may be used.

GMPLS Control Interworking with a Centralized Controller System Besides GMPLS and the interactions among the controller hierarchies, it is also necessary for the controllers to communicate with the network elements. Within each domain, GMPLS control can be applied to each NE. The bottom-level centralized controller can act as an NE to collect network information and initiate LSPs. shows an example of GMPLS interworking with centralized controllers (ACTN terminologies are used in the figure).

Example of GMPLS/non-GMPLS Interworking with Controllers +-------------------+ | Orchestrator | | (MDSC) | +-------------------+ ^ ^ ^ | | | +-------------+ | +--------------+ | |RESTCONF/YANG modules | V V V +-------------+ +-------------+ +-------------+ |Controller(N)| |Controller(G)| |Controller(G)| | (PNC) | | (PNC) | | (PNC) | +-------------+ +-------------+ +-------------+ ^ ^ ^ ^ ^ ^ | | | | | | NETCONF| |PCEP NETCONF| |PCEP NETCONF| |PCEP /YANG | | /YANG | | /YANG | | V V V V V V .----------. Inter- .----------. Inter- .----------. / \ domain / \ domain / \ | | link | LMP | link | LMP | | |======| OSPF-TE |======| OSPF-TE | | | | RSVP-TE | | RSVP-TE | \ / \ / \ / `----------` `----------` `----------` Non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3

Controller(N):

A domain controller controlling a non-GMPLS domain

Controller(G):

A domain controller controlling a GMPLS domain

shows the scenario with two GMPLS domains and one non-GMPLS domain. This system supports the interworking among non-GMPLS domains, GMPLS domains, and the controller hierarchies. For domain 1, the network elements were not enabled with GMPLS, so the control is purely from the controller, via Network Configuration Protocol (NETCONF) with a YANG data model and/or PCE Communication Protocol (PCEP) . For domains 2 and 3:

• Each domain has the GMPLS control plane enabled at the physical network level. The Provisioning Network Controller (PNC) can exploit GMPLS capabilities implemented in the domain to listen to the IGP routing protocol messages (for example, OSPF Link State Advertisements (LSAs)) that the GMPLS control plane instances are disseminating into the network and thus learn the network topology. For path computation in the domain with the PNC implementing a PCE, Path Computation Clients (PCCs) (e.g., NEs, other controllers/PCEs) use PCEP to ask the PNC for a path and get replies. The Multi-Domain Service Coordinator (MDSC) communicates with PNCs using, for example, Representational State Transfer (REST) / RESTCONF based on YANG data models. As a PNC has learned its domain topology, it can report the topology to the MDSC. When a service arrives, the MDSC computes the path and coordinates PNCs to establish the corresponding LSP segment.
• Alternatively, the NETCONF protocol can be used to retrieve topology information utilizing the YANG module in and the technology-specific YANG module augmentations required for the specific network technology. The PNC can retrieve topology information from any NE (the GMPLS control plane instance of each NE in the domain has the same topological view), construct the topology of the domain, and export an abstract view to the MDSC. Based on the topology retrieved from multiple PNCs, the MDSC can create a topology graph of the multi-domain network and can use it for path computation. To set up a service, the MDSC can exploit the YANG module in together with the technology-specific YANG module augmentations.

This document focuses on the interworking between GMPLS and the centralized controller system, including:

• the interworking between the GMPLS domains and the centralized controllers (including the orchestrator, if it exists) controlling the GMPLS domains and
• the interworking between a non-GMPLS domain (which is controlled by a centralized controller system) and a GMPLS domain, through the controller hierarchy architecture.

For convenience, this document uses the following terminologies for the controller and the orchestrator:

Controller(G):

A domain controller controlling a GMPLS domain (the Controller(G) of the GMPLS domains 2 and 3 in )

Controller(N):

A domain controller controlling a non-GMPLS domain (the Controller(N) of the non-GMPLS domain 1 in )

H-Controller(G):

A domain controller controlling the higher-layer GMPLS domain, in the context of multi-layer networks

L-Controller(G):

A domain controller controlling the lower-layer GMPLS domain, in the context of multi-layer networks

H-Controller(N):

A domain controller controlling the higher-layer non-GMPLS domain, in the context of multi-layer networks

L-Controller(N):

A domain controller controlling the lower-layer non-GMPLS domain, in the context of multi-layer networks

Orchestrator(MD):

An orchestrator used to orchestrate the multi-domain networks

Orchestrator(ML):

An orchestrator used to orchestrate the multi-layer networks

Discovery Options In GMPLS control, the link connectivity must be verified between each pair of nodes. In this way, link resources, which are fundamental resources in the network, are discovered by both ends of the link.

LMP The Link Management Protocol (LMP) runs between nodes and manages TE links. In addition to the setup and maintenance of control channels, LMP can be used to verify the data link connectivity and correlate the link properties.

Routing Options In GMPLS control, link state information is flooded within the network as defined in . Each node in the network can build the network topology according to the flooded link state information. Routing protocols such as OSPF-TE and IS-IS-TE have been extended to support different interfaces in GMPLS. In a centralized controller system, the centralized controller can be placed in the GMPLS network and passively receives the IGP information flooded in the network. In this way, the centralized controller can construct and update the network topology.

OSPF-TE OSPF-TE is introduced for TE networks in . OSPF extensions have been defined in to enable the capability of link state information for the GMPLS network. Based on this work, OSPF has been extended to support technology-specific routing. The routing protocols for the Optical Transport Network (OTN), Wavelength Switched Optical Network (WSON), and optical flexi-grid networks are defined in , , and , respectively.

IS-IS-TE IS-IS-TE is introduced for TE networks in , is extended to support GMPLS routing functions , and has been updated to support the latest GMPLS switching capability and Types fields.

NETCONF/RESTCONF NETCONF and RESTCONF protocols are originally used for network configuration. These protocols can also utilize topology-related YANG modules, such as those in and . These protocols provide a powerful mechanism for the notification (in addition to the provisioning and monitoring) of topology changes to the client.

Path Computation

Controller-Based Path Computation Once a controller learns the network topology, it can utilize the available resources to serve service requests by performing path computation. Due to abstraction, the controllers may not have sufficient information to compute the optimal path. In this case, the controller can interact with other controllers by sending, for example, YANG-based path computation requests or PCEP to compute a set of potential optimal paths; and then, based on its constraints, policy, and specific knowledge (e.g., cost of access link), the controller can choose the more feasible path for end-to-end (E2E) service path setup. Path computation is one of the key objectives in various types of controllers. In the given architecture, it is possible for different components that have the capability to compute the path.

Constraint-Based Path Computing in GMPLS Control In GMPLS control, a routing path may be computed by the ingress node based on the ingress node Traffic Engineering Database (TED). In this case, constraint-based path computation is performed according to the local policy of the ingress node.

Path Computation Element (PCE) The PCE was first introduced in as a functional component that offers services for computing paths within a network. In , path computation is achieved using the TED, which maintains a view of the link resources in the network. The introduction of the PCE has significantly improved the quality of network planning and offline computation. However, there is a potential risk that the computed path may be infeasible when there is a diversity requirement, as a stateless PCE lacks knowledge about previously computed paths. To address this issue, a stateful PCE has been proposed in . Besides the TED, an additional LSP Database (LSP-DB) is introduced to archive each LSP computed by the PCE. This way, the PCE can easily determine the relationship between the computing path and former computed paths. In this approach, the PCE provides computed paths to the PCC, and then the PCC decides which path is deployed and when it is to be established. With PCE-initiated LSPs , the PCE can trigger the PCC to perform setup, maintenance, and teardown of the PCE-initiated LSP under the stateful PCE model. This would allow a dynamic network that is centrally controlled and deployed. In a centralized controller system, the PCE can be implemented within the centralized controller. The centralized controller then calculates paths based on its local policies. Alternatively, the PCE can be located outside of the centralized controller. In this scenario, the centralized controller functions as a PCC and sends a path computation request to the PCE using the PCEP. A reference architecture for this can be found in .

Signaling Options Signaling mechanisms are used to set up LSPs in GMPLS control. Messages are sent hop by hop between the ingress node and the egress node of the LSP to allocate labels. Once the labels are allocated along the path, the LSP setup is accomplished. Signaling protocols such as Resource Reservation Protocol - Traffic Engineering (RSVP-TE) have been extended to support different interfaces in GMPLS.

RSVP-TE RSVP-TE is introduced in and extended to support GMPLS signaling in . Several label formats are defined for a generalized label request, a generalized label, a suggested label, and label sets. Based on , RSVP-TE has been extended to support technology-specific signaling. The RSVP-TE extensions for the OTN, WSON, and optical flexi-grid network are defined in , , and , respectively.

Interworking Scenarios

Topology Collection and Synchronization Topology information is necessary on both network elements and controllers. The topology on a network element is usually raw information, while the topology used by the controller can be either raw, reduced, or abstracted. Three different abstraction methods have been described in , and different controllers can select the corresponding method depending on the application. When there are changes in the network topology, the impacted network elements need to report changes to all the other network elements, together with the controller, to sync up the topology information. The inter-NE synchronization can be achieved via protocols mentioned in Sections and . The topology synchronization between NEs and controllers can either be achieved by routing protocols OSPF-TE/PCEP-LS in or NETCONF protocol notifications with a YANG module.

Multi-Domain Service Provisioning Service provisioning can be deployed based on the topology information on controllers and network elements. Many methods have been specified for single-domain service provisioning, such as the PCEP and RSVP-TE methods. Multi-domain service provisioning would require coordination among the controller hierarchies. Given the service request, the end-to-end delivery procedure may include interactions at any level (i.e., interface) in the hierarchy of the controllers (e.g., MPI and SBI for ACTN). The computation for a cross-domain path is usually completed by controllers who have a global view of the topologies. Then the configuration is decomposed into lower-level controllers to configure the network elements to set up the path. A combination of centralized and distributed protocols may be necessary to interact between network elements and controllers. Several methods can be used to create the inter-domain path:

1. With an end-to-end RSVP-TE session: In this method, all the domains need to support the RSVP-TE protocol and thus need to be GMPLS domains. The Controller(G) of the source domain triggers the source node to create the end-to-end RSVP-TE session; and the assignment and distribution of the labels on the inter-domain links are done by the border nodes of each domain, using RSVP-TE protocol. Therefore, this method requires the interworking of RSVP-TE protocols between different domains. There are two possible methods:
   1. One single end-to-end RSVP-TE session: In this method, an end-to-end RSVP-TE session from the source node to the destination node will be used to create the inter-domain path. A typical example would be the PCE initiation scenario, in which a PCE message (PCInitiate) is sent from the Controller(G) to the source node, triggering an RSVP procedure along the path. Similarly, the interaction between the controller and the source node of the source domain can be achieved by using the NETCONF protocol with corresponding YANG modules, and then it can be completed by running RSVP among the network elements.
   2. LSP Stitching: The LSP stitching method defined in can also create the E2E LSP. That is, when the source node receives an end-to-end path creation request (e.g., using PCEP or NETCONF protocol), the source node starts an end-to-end RSVP-TE session along the endpoints of each LSP segment (S-LSP) (refers to S-LSP in ) of each domain, to assign the labels on the inter-domain links between each pair of neighbor S-LSPs and to stitch the end-to-end LSP to each S-LSP. See as an example. Note that the S-LSP in each domain can be either created by its Controller(G) in advance or created dynamically triggered by the end-to-end RSVP-TE session.

      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 an end-to-end RSVP-TE session: In this method, each domain can be a GMPLS domain or a non-GMPLS domain. Each controller (which may be a Controller(G) or a Controller(N)) is responsible for creating the path segment within its domain. The border node does not need to communicate with other border nodes in other domains for the distribution of labels on inter-domain links, so an end-to-end RSVP-TE session through multiple domains is not required, and the interworking of the RSVP-TE protocol between different domains is not needed. Note that path segments in the source domain and the destination domain are "asymmetrical" segments, because the configuration of client signal mapping into the server-layer tunnel is needed at only one end of the segment, while configuration of the server-layer cross-connect is needed at the other end of the segment. See the example in .

   Example of an 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 asymmetrical segments. Note also that mechanisms to assign the labels in the inter-domain links also need to be considered. There are two possible methods:
   1. Inter-domain labels assigned by NEs: The concept of a stitching label that allows stitching local path segments was introduced in and , in order to form the inter-domain path crossing several different domains. It also describes the Backward Recursive PCE-Based Computation (BRPC) and Hierarchical PCE (H-PCE) 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. Inter-domain labels assigned by the controller: 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.

Multi-Layer Service Provisioning GMPLS can interwork with centralized controller systems in multi-layer networks.

GMPLS-controller Interworking in Multi-Layer Networks +----------------+ |Orchestrator(ML)| +------+--+------+ | | Higher-layer Network | | .--------------------. | | / \ | | +--------------+ | +--+ Link +--+ | | +-->| H-Controller +----->| | |**********| | | | +--------------+ | +--+ +--+ | | \ . . / | `--.------------.---` | . . | .---.------------.---. | / . . \ | +--------------+ | +--+ +--+ +--+ | +----->| L-Controller +----->| | ============== | | +--------------+ | +--+ +--+ +--+ | \ H-LSP / `-------------------` Lower-layer Network

An example with two layers of network is shown in . In this example, the GMPLS control plane is enabled in at least one layer network (otherwise, it is out of the scope of this document) and interworks with the controller of its domain (H-Controller and L-Controller, respectively). The Orchestrator(ML) is used to coordinate the control of the multi-layer network.

Multi-Layer Path Computation describes three inter-layer path computation models and four inter-layer path control models:

• 3 path computation models:
  • Single PCE path computation model
  • Multiple PCE path computation with inter-PCE communication model
  • Multiple PCE path computation without inter-PCE communication model
• 4 path control models:
  • PCE Virtual Network Topology Manager (PCE-VNTM) cooperation model
  • Higher-layer signaling trigger model
  • Network Management System VNTM (NMS-VNTM) cooperation model (integrated flavor)
  • NMS-VNTM cooperation model (separate flavor)

also provides all the possible combinations of inter-layer path computation and inter-layer path control models. To apply in a multi-layer network with GMPLS-controller interworking, the H-Controller and the L-Controller can act as the PCE Hi and PCE Lo, respectively; and typically, the Orchestrator(ML) can act as a VNTM because it has the abstracted view of both the higher-layer and lower-layer networks. shows all possible combinations of path computation and path control models in multi-layer network with GMPLS-controller interworking: Combinations of Path Computation and Path Control Models

Path computation / Path control	Single PCE	Multiple PCE with inter-PCE	Multiple PCE w/o inter-PCE
PCE-VNTM cooperation	N/A	Yes	Yes
Higher-layer signaling trigger	N/A	Yes	Yes
NMS-VNTM cooperation (integrated flavor)	N/A	Yes (1)	No (1)
NMS-VNTM cooperation (separate flavor)	N/A	No (1)	Yes (1)

Note that:

• Since there is one PCE in each layer network, the path computation model "Single PCE path computation" is not applicable (N/A).
• For the other two path computation models "Multiple PCE with inter-PCE" and "Multiple PCE w/o inter-PCE", the possible combinations are the same as defined in . More specifically:
  • (1) The path control models "NMS-VNTM cooperation (integrated flavor)" and "NMS-VNTM cooperation (separate flavor)" are the typical models to be used in a multi-layer network with GMPLS-controller interworking. This is because, in these two models, the path computation is triggered by the NMS or VNTM. And in the centralized controller system, the path computation requests are typically from the Orchestrator(ML) (acts as VNTM).
  • For the other two path control models "PCE-VNTM cooperation" and "Higher-layer signaling trigger", the path computation is triggered by the NEs, i.e., the NE performs PCC functions. It is still possible to use these two models, although they are not the main methods.

Cross-Layer Path Creation In a multi-layer network, a lower-layer LSP in the lower-layer network can be created, which will construct a new link in the higher-layer network. Such a lower-layer LSP is called Hierarchical LSP, or H-LSP for short; see . The new link constructed by the H-LSP can then be used by the higher-layer network to create new LSPs. As described in , two methods are introduced to create the H-LSP: the static (pre-provisioned) method and the dynamic (triggered) method.

1. Static (pre-provisioned) method: In this method, the H-LSP in the lower-layer network is created in advance. After that, the higher-layer network can create LSPs using the resource of the link constructed by the H-LSP. The Orchestrator(ML) is responsible to decide the creation of H-LSP in the lower-layer network if it acts as a VNTM. Then it requests the L-Controller to create the H-LSP via, for example, an MPI under the ACTN architecture. If the lower-layer network is a GMPLS domain, the L-Controller(G) can trigger the GMPLS control plane to create the H-LSP. As a typical example, the PCInitiate message can be used for the communication between the L-Controller and the source node of the H-LSP. And the source node of the H-LSP can trigger the RSVP-TE signaling procedure to create the H-LSP, as described in . If the lower-layer network is a non-GMPLS domain, other methods may be used by the L-Controller(N) to create the H-LSP, which is out of scope of this document.
2. Dynamic (triggered) method: In this method, the signaling of LSP creation in the higher-layer network will trigger the creation of H-LSP in the lower-layer network dynamically, if it is necessary. Therefore, both the higher-layer and lower-layer networks need to support the RSVP-TE protocol and thus need to be GMPLS domains. In this case, after the cross-layer path is computed, the Orchestrator(ML) requests the H-Controller(G) for the cross-layer LSP creation. As a typical example, the MPI under the ACTN architecture could be used. The H-Controller(G) can trigger the GMPLS control plane to create the LSP in the higher-layer network. As a typical example, the PCInitiate message can be used for the communication between the H-Controller(G) and the source node of the higher-layer LSP, as described in . At least two sets of ERO information should be included to indicate the routes of higher-layer LSP and lower-layer H-LSP. The source node of the higher-layer LSP follows the procedure defined in to trigger the GMPLS control plane in both the higher-layer network and the lower-layer network to create the higher-layer LSP and the lower-layer H-LSP. On success, the source node of the H-LSP should report the information of the H-LSP to the L-Controller(G) via, for example, the PCRpt message.

Link Discovery If the higher-layer network and the lower-layer network are under the same GMPLS control plane instance, the H-LSP can be a Forwarding Adjacency LSP (FA-LSP). Then the information of the link constructed by this FA-LSP can be advertised in the routing instance, so that the H-Controller can be aware of this new FA. and the following updates to it (including and ) describe the detailed extensions to support advertisement of an FA. If the higher-layer network and the lower-layer network are under separate GMPLS control plane instances or if one of the layer networks is a non-GMPLS domain, after an H-LSP is created in the lower-layer network, the link discovery procedure will be triggered in the higher-layer network to discover the information of the link constructed by the H-LSP. The LMP defined in can be used if the higher-layer network supports GMPLS. The information of this new link will be advertised to the H-Controller.

Recovery The GMPLS recovery functions are described in . Span protection and end-to-end protection and restoration are discussed with different protection schemes and message exchange requirements. Related RSVP-TE extensions to support end-to-end recovery are described in . The extensions in include protection, restoration, preemption, and rerouting mechanisms for an end-to-end LSP. Besides end-to-end recovery, a GMPLS segment recovery mechanism is defined in , which also intends to be compatible with Fast Reroute (FRR) (see , which defines RSVP-TE extensions for the FRR mechanism, and , which describes the updates of the GMPLS RSVP-TE protocol for FRR of GMPLS TE-LSPs).

Span Protection Span protection refers to the protection of the link between two neighboring switches. The main protocol requirements include:

• Link management: Link property correlation on the link protection type
• Routing: Announcement of the link protection type
• Signaling: Indication of link protection requirement for that LSP

GMPLS already supports the above requirements, and there are no new requirements in the scenario of interworking between GMPLS and a centralized controller system.

LSP Protection The LSP protection includes end-to-end and segment LSP protection. For both cases:

• In the provisioning phase: In both single-domain and multi-domain scenarios, the disjoint path computation can be done by the centralized controller system, as it has the global topology and resource view. And the path creation can be done by the procedure described in .
• In the protection switchover phase: In both single-domain and multi-domain scenarios, the existing standards provide the distributed way to trigger the protection switchover, for example, the data plane Automatic Protection Switching (APS) mechanism described in , , and or the GMPLS Notify mechanism described in and . In the scenario of interworking between GMPLS and a centralized controller system, using these distributed mechanisms rather than a centralized mechanism (i.e., the controller triggers the protection switchover) can significantly shorten the protection switching time.

Single-Domain LSP Restoration

• Pre-planned LSP protection (including shared-mesh restoration): In pre-planned protection, the protecting LSP is established only in the control plane in the provisioning phase and will be activated in the data plane once failure occurs. In the scenario of interworking between GMPLS and a centralized controller system, the route of protecting LSP can be computed by the centralized controller system. This takes the advantage of making better use of network resources, especially for the resource-sharing in shared-mesh restoration.
• Full LSP rerouting: In full LSP rerouting, the normal traffic will be switched to an alternate LSP that is fully established only after a failure occurrence. As described in and , the alternate route can be computed on demand when there is a failure occurrence or can be pre-computed and stored before a failure occurrence. In a fully distributed scenario, the pre-computation method offers a faster restoration time but has the risk that the pre-computed alternate route may become out-of-date due to the changes of the network. In the scenario of interworking between GMPLS and a centralized controller system, the pre-computation of the alternate route could take place in the centralized controller (and may be stored in the controller or the head-end node of the LSP). In this way, any changes in the network can trigger the refreshment of the alternate route by the centralized controller. This makes sure that the alternate route will not become out-of-date.

Multi-Domain LSP Restoration A working LSP may traverse multiple domains, each of which may or may not support a GMPLS distributed control plane. If all the domains support GMPLS, both the end-to-end rerouting method and the domain segment rerouting method could be used. If only some domains support GMPLS, the domain segment rerouting method could be used in those GMPLS domains. For other domains that do not support GMPLS, other mechanisms may be used to protect the LSP segments, which are out of scope of this document.

1. End-to-end rerouting: In this scenario, a failure on the working LSP inside any domain or on the inter-domain links will trigger the end-to-end restoration. In both pre-planned and full LSP rerouting, the end-to-end protecting LSP could be computed by the centralized controller system and could be created by the procedure described in . Note that the end-to-end protecting LSP may traverse different domains from the working LSP, depending on the result of multi-domain path computation for the protecting LSP.

   End-to-End Restoration +----------------+ |Orchestrator(MD)| +-------.--------+ ............................................ . . . . +----V-----+ +----V-----+ +----V-----+ +----V-----+ |Controller| |Controller| |Controller| |Controller| | (G) 1 | | (G) 2 | | (G) 3 | | (G) 4 | +----.-----+ +-------.--+ +-------.--+ +----.-----+ . . . . +----V--------+ +-V-----------+ . +-------V-----+ | Domain 1 | | Domain 2 | . | Domain 4 | |+---+ +---+| |+---+ +---+| . |+---+ +---+| || ===/~/======/~~~/================================ || |+-*-+ +---+| |+---+ +---+| . |+---+ +-*-+| | * | +-------------+ . | * | | * | . | * | | * | +-------------+ . | * | | * | | Domain 3 <... | * | |+-*-+ +---+| |+---+ +---+| |+---+ +-*-+| || ************************************************* || |+---+ +---+| |+---+ +---+| |+---+ +---+| +-------------+ +-------------+ +-------------+ ====: Working LSP ****: Protecting LSP /~/: Failure

2. Domain segment rerouting:
   1. Intra-domain rerouting: If failure occurs on the working LSP segment in a GMPLS domain, the segment rerouting could be used for the working LSP segment in that GMPLS domain. shows an example of intra-domain rerouting. The intra-domain rerouting of a non-GMPLS domain is out of scope of this document.

      Intra-Domain Segment Rerouting +----------------+ |Orchestrator(MD)| +-------.--------+ ............................................ . . . . +----V-----+ +----V-----+ +----V-----+ +----V-----+ |Controller| |Controller| |Controller| |Controller| | (G) 1 | |(G)/(N) 2 | |(G)/(N) 3 | |(G)/(N) 4 | +----.-----+ +-------.--+ +-------.--+ +----.-----+ . . . . +----V--------+ +-V-----------+ . +-------V-----+ | Domain 1 | | Domain 2 | . | Domain 4 | |+---+ +---+| |+---+ +---+| . |+---+ +---+| || ===/~/=========================================== || |+-*-+ +-*-+| |+---+ +---+| . |+---+ +---+| | * * | +-------------+ . | | | * * | . | | | * * | +-------------+ . | | | * * | | Domain 3 <... | | |+-*-+ +-*-+| |+---+ +---+| |+---+ +---+| || ********* || || | | || || | | || |+---+ +---+| |+---+ +---+| |+---+ +---+| +-------------+ +-------------+ +-------------+ ====: Working LSP ****: Rerouting LSP segment /~/: Failure

   2. Inter-domain rerouting: If intra-domain segment rerouting failed (e.g., due to lack of resource in that domain), or if failure occurs on the working LSP on an inter-domain link, the centralized controller system may coordinate with other domain(s) to find an alternative path or path segment to bypass the failure and then trigger the inter-domain rerouting procedure. Note that the rerouting path or path segment may traverse different domains from the working LSP. The domains involved in the inter-domain rerouting procedure need to be GMPLS domains, which support the RSVP-TE signaling for the creation of a rerouting LSP segment. For inter-domain rerouting, the interaction between GMPLS and a centralized controller system is needed:
      • A report of the result of intra-domain segment rerouting to its Controller(G) and then to the Orchestrator(MD). The former could be supported by the PCRpt message in , while the latter could be supported by the MPI of ACTN.
      • A report of inter-domain link failure to the two Controllers (e.g., Controller(G) 1 and Controller(G) 2 in ) by which the two ends of the inter-domain link are controlled, respectively, and then to the Orchestrator(MD). The former could be done as described in , while the latter could be supported by the MPI of ACTN.
      • The computation of a rerouting path or path segment crossing multi-domains by the centralized controller system (see );
      • The creation of a rerouting LSP segment in each related domain. The Orchestrator(MD) can send the LSP segment rerouting request to the source Controller(G) (e.g., Controller(G) 1 in ) via MPI interface, and then the Controller(G) can trigger the creation of a rerouting LSP segment through multiple GMPLS domains using GMPLS rerouting signaling. Note that the rerouting LSP segment may traverse a new domain that the working LSP does not traverse (e.g., Domain 3 in ).

      Inter-Domain Segment Rerouting +----------------+ |Orchestrator(MD)| +-------.--------+ .................................................. . . . . +-----V------+ +-----V------+ +-----V------+ +-----V------+ | Controller | | Controller | | Controller | | Controller | | (G) 1 | | (G) 2 | | (G) 3 | | (G)/(N) 4 | +-----.------+ +------.-----+ +-----.------+ +-----.------+ . . . . +-----V-------+ +----V--------+ . +------V------+ | Domain 1 | | Domain 2 | . | Domain 4 | |+---+ +---+| |+---+ +---+| . |+---+ +---+| || | | || || | | || . || | | || || ============/~/========================================== || || * | | || || | | * || . || | | || |+-*-+ +---+| |+---+ +-*-+| . |+---+ +---+| | * | +----------*--+ . | | | * | ***** . | | | * | +----------*-----V----+ | | | * | | *Domain 3 | | | |+-*-+ +---+| |+---+ +-*-+ +---+| |+---+ +---+| || * | | || || | | * | | || || | | || || ******************************* | | || || | | || || | | || || | | | | || || | | || |+---+ +---+| |+---+ +---+ +---+| |+---+ +---+| +-------------+ +---------------------+ +-------------+ ====: Working LSP ****: Rerouting LSP segment /~/: Failure

Fast Reroute defines two methods of fast reroute: the one-to-one backup method and the facility backup method. For both methods:

1. Path computation of protecting LSP: In , the protecting LSP (detour LSP in one-to-one backup or bypass tunnel in facility backup) could be computed by the Point of Local Repair (PLR) using, for example, a Constrained Shortest Path First (CSPF) computation. In the scenario of interworking between GMPLS and a centralized controller system, the protecting LSP could also be computed by the centralized controller system, as it has the global view of the network topology, resources, and information of LSPs.
2. Protecting LSP creation: In the scenario of interworking between GMPLS and a centralized controller system, the protecting LSP could still be created by the RSVP-TE signaling protocol as described in and . In addition, if the protecting LSP is computed by the centralized controller system, the Secondary Explicit Route Object defined in could be used to explicitly indicate the route of the protecting LSP.
3. Failure detection and traffic switchover: If a PLR detects that failure occurs, it may significantly shorten the protection switching time by using the distributed mechanisms described in to switch the traffic to the related detour LSP or bypass tunnel rather than doing so in a centralized way.

Controller Reliability The reliability of the controller is crucial due to its important role in the network. It is essential that if the controller is shut down or disconnected from the network, all currently provisioned services in the network continue to function and carry traffic. In addition, protection switching to pre-established paths should also work. It is desirable to have protection mechanisms, such as redundancy, to maintain full operational control even if one instance of the controller fails. This can be achieved through controller backup or functionality backup. There are several controller backup or federation mechanisms in the literature. It is also more reliable to have function backup in the network element to guarantee performance in the network.

Manageability Considerations Each network entity, including controllers and network elements, should be managed properly and with the relevant trust and security policies applied (see ), as they will interact with other entities. The manageability considerations in controller hierarchies and network elements still apply, respectively. The overall manageability of the protocols applied in the network should also be a key consideration. The responsibility of each entity should be clarified. The control of function and policy among different controllers should be consistent via a proper negotiation process.

Security Considerations This document outlines the interworking between GMPLS and controller hierarchies. The security requirements specific to both systems remain applicable. Protocols referenced herein possess security considerations, which must be adhered to, with their core specifications and identified risks detailed earlier in this document. Security is a critical aspect in both GMPLS and controller-based networks. Ensuring robust security mechanisms in these environments is paramount to safeguard against potential threats and vulnerabilities. Below are expanded security considerations and some relevant IETF RFC references.

• Authentication and Authorization: It is essential to implement strong authentication and authorization mechanisms to control access to the controller from multiple network elements. This ensures that only authorized devices and users can interact with the controller, preventing unauthorized access that could lead to network disruptions or data breaches. "" and "" provide guidelines on secure communication and certificate-based authentication that can be leveraged for these purposes.
• Controller Security: The controller's security is crucial as it serves as the central control point for the network elements. The controller must be protected against various attacks, such as Denial of Service (DoS), Man in the Middle (MITM), and unauthorized access. Security mechanisms should include regular security audits, application of security patches, firewalls, and Intrusion Detection Systems (IDSs) / Intrusion Prevention Systems (IPSs).
• Data Transport Security: Security mechanisms on the controller should also safeguard the underlying network elements against unauthorized usage of data transport resources. This includes encryption of data in transit to prevent eavesdropping and tampering as well as ensuring data integrity and confidentiality.
• Secure Protocol Implementation: Protocols used within the GMPLS and controller frameworks must be implemented with security in mind. Known vulnerabilities should be addressed, and secure versions of protocols should be used wherever possible.

Finally, robust network security often depends on Indicators of Compromise (IoCs) to detect, trace, and prevent malicious activities in networks or endpoints. These are described in along with the fundamentals, opportunities, operational limitations, and recommendations for IoC use.

IANA Considerations This document has no IANA actions.

References Normative References This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK] This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK] This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK] This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. [PROPOSED STANDARD] Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK] This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK] This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK] Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307. Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane. The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures. This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security. Informative References ITU-T Huawei Technologies Nokia Telefonica Google China Unicom There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. Work in Progress Huawei Huawei Samsung Electronics Cisco China Telecom Verizon Inc. In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way. Work in Progress This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK] This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK] For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK] This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK] In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK] Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community. The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK] A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community. This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T. The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK] This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203. ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility. This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals. This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms. This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as "flexi-grid". Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. Orange Innovation Orange Innovation Samsung Electronics Cisco This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. It delivers a new tool in the PCE toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, new PCEP communication Protocol (PCEP) Capability, new PCE Errors Type and new PCE Notifications Type. Work in Progress Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Work in Progress

Acknowledgements The authors would like to thank , Area Director of IETF Routing Area; , Chair of TEAS WG; and , RTGDIR reviewers; , Gen-ART reviewer; , OPSDIR reviewer; , SECDIR reviewer; , IANA Services Sr. Specialist; and and , IESG reviewers for their reviews and comments on this document.

Contributors Huawei Technologies

G1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China luoxianlong@huawei.com

Nokia

sergio.belotti@nokia.com

Authors' Addresses Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China zhenghaomian@huawei.com

Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China yi.lin@huawei.com

China Mobile

zhaoyangyjy@chinamobile.com

CAICT

xuyunbin@caict.ac.cn

Nokia

Dieter.Beller@nokia.com