TEAS Working Group Haomian Zheng Internet Draft Xianlong Luo Category: Informational Huawei Technologies Yang Zhao China Mobile Yunbin Xu CAICT Sergio Belotti Dieter Beller Nokia Expires: January 8, 2020 July 8, 2019 Interworking of GMPLS Control and Centralized Controller System draft-ietf-teas-gmpls-controller-inter-work-01 Abstract Generalized Multi-Protocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing and signaling in a distributed manner. On the other hand, with the development of software-defined transport networking technology, a set of NEs can be controlled via centralized controller hierarchies to address the issue from multi- domain, multi-vendor and multi-technology. An example of such centralized architecture is ACTN controller hierarchy described in RFC 8453. Instead of competing with each other, both the distributed and the centralized control plane have their own advantages, and should be complementary in the system. This document describes how the GMPLS distributed control plane can interwork with a centralized controller system in a transport network. 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 months and may be updated, replaced, or obsoleted by other documents Zheng, et al. Expires January 2020 [Page 1] Internet-Draft GMPLS and Controller Interwork July 2019 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 http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2020. Copyright Notice Copyright (c) 2019 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Conventions used in this document Table of Contents 1. Introduction...................................................3 2. Overview.......................................................4 2.1. Overview of GMPLS Control Plane..............................4 2.2. Overview of Centralized Controller System....................4 2.3. GMPLS Control Interwork with Centralized Controller System...4 3. Link Management Protocol............Error! Bookmark not defined. 4. Routing Options................................................6 4.1. OSPF-TE...................................................6 4.2. ISIS-TE...................................................7 4.3. Netconf/RESTconf..........................................7 5. Path Computation...............................................7 5.1. Constraint-based Path Computing in GMPLS Control..........7 5.2. Path Computation Element (PCE)............................7 6. Signaling Options..............................................8 6.1. RSVP-TE...................................................8 7. Interworking Scenarios.........................................8 Zheng et. al Expires January 2020 [Page 2] Internet-Draft GMPLS and Controller Interwork July 2019 7.1. Topology Collection & Synchronization.....................8 7.2. Multi-domain Service Provisioning.........................9 7.3. Multi-layer Service Provisioning.........................11 7.4. Recovery.................................................11 7.5. Controller Reliability...................................11 8. Manageability Considerations..................................12 9. Security Considerations.......................................12 10. IANA Considerations..........................................12 11. References...................................................12 11.1. Normative References....................................12 11.2. Informative References..................................14 12. Authors' Addresses ...........................................16 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS to support different classes of interfaces and switching capabilities such as Time-Division Multiplex Capable (TDM), Lambda Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network element (NE) running a GMPLS control plane collects network information from other NEs and supports service provisioning through signaling in a distributed manner. More generic description for Traffic-engineering networking information exchange can be found in [RFC7926]. On the other hand, Software-Defined Networking (SDN) technologies have been introduced to control the transport network in a centralized manner. Central controllers can collect network information from each node and provision services to corresponding nodes. One of the examples is the Abstraction and Control of Traffic Engineered Networks (ACTN) [RFC8453], which defines a hierarchical architecture with Provisioning Network Controller(PNC), Multi-domain Service Coordinator(MDSC) and Customer Network Controller(CNC) as central controllers for different network abstraction levels. A Path Computation Element (PCE) based approach has been proposed as Application-Based Network Operations (ABNO) in [RFC7491]. In such centralized controller architectures, GMPLS can be applied for the NE-level control. A central controller may support GMPLS enabled domains and may interact with a GMPLS enabled domain where the GMPLS control plane does the service provisioning from ingress to egress. In this case the centralized controller sends the request to the ingress node and does not have to configure all NEs along the path through the domain from ingress to egress thus leveraging the GMPLS control plane. This document describes how GMPLS control interworks with centralized controller system in transport network. Zheng et. al Expires January 2020 [Page 3] Internet-Draft GMPLS and Controller Interwork July 2019 2. Overview In this section, overviews of GMPLS control plane and centralized controller system are discussed as well as the interactions between the GMPLS control plane and centralized controllers. 2.1. 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 controller can also collect 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 GMPLS control [RFC3945] including link management [RFC4204], signaling [RFC3471], and routing [RFC4202] protocols. The controllers applying these protocols communicate with each other to exchange resource information and establish Label Switched Paths (LSPs). In this way, controllers in different nodes in the network have the same view of the network topology and provision services based on local policies. 2.2. 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 [RFC8453]. 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 implementing 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 standard API (e.g., generated from RESTconf/YANG) is used. 2.3. GMPLS Control Interwork with Centralized Controller System Besides the 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 central controller can act as a NE to collect network information and initiate LSP. Figure 1 shows Zheng et. al Expires January 2020 [Page 4] Internet-Draft GMPLS and Controller Interwork July 2019 an example of GMPLS interworking with centralized controllers (ACTN terminologies are used in the figure). +--------------------+ | Orchestrator | +--------------------+ ^ ^ ^ | | | +-------------+ | +------------+ | | RESTConf/YANG models | V V V +----------+ +----------+ +----------+ |Controller| |Controller| |Controller| +----------+ +----------+ +----------+ ^ ^ ^ ^ ^ | | | | | Netconf| |PCEP Netconf| |PCEP | IF* /YANG | | /YANG | | | 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 Figure 1: Example of GMPLS/non-GMPLS interworks with Controllers Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS domain. This system supports the interworking among non-GMPLS domain, GMPLS domain and the controller hierarchies. For domain 1, the network element were not enabled with GMPLS so the control can be purely from the controller, via Netconf/YANG and/or PCEP. For domain 2 and 3, each domain has the GMPLS control plane enabled at the physical network level. The PNC can exploit GMPLS capability implemented in the domain to listen to the IGP routing protocol messages (OSPF LSAs for example) that the GMPLS control plane instances are disseminating into the network and thus learn the network topology. For path computation in the domain with PNC implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP to ask the PNC for a path and get replies. The MDSC communicates with PNCs using for example REST/RESTConf based on YANG data models. As a PNC has learned its domain topology, it can report the topology Zheng et. al Expires January 2020 [Page 5] Internet-Draft GMPLS and Controller Interwork July 2019 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 e.g.[TE-topo] Yang model and the technology-specific YANG model 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 abstracted view to the MDSC. Based on the topology retrieved from multiple PNCs, the MDSC can create topology graph of the multi-domain network, and can use it for path computation. To setup a service, the MDSC can exploit e.g.[TE- Tunnel] Yang model together with the technology-specific YANG model augmentations. 3. Discovery Options In GMPLS control, the link connectivity need to 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. 3.1. LMP Link management protocol (LMP) [RFC4204] runs between a pair of nodes and is used to manage 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 property. 4. Routing Options In GMPLS control, link state information is flooded within the network as defined in [RFC4202]. Each node in the network can build the network topology according to the flooded link state information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE [RFC5307] have been extended to support different interfaces in GMPLS. In centralized controller system, central controller can be placed at the GMPLS network and passively receive the information flooded in the network. In this way, the central controller can construct and update the network topology. 4.1. OSPF-TE OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions have been defined in [RFC4203] to enable the capability of link state information for GMPLS network. Based on this work, OSPF protocol has been extended to support technology-specific routing. Zheng et. al Expires January 2020 [Page 6] Internet-Draft GMPLS and Controller Interwork July 2019 The routing protocol for OTN, WSON and optical flexi-grid network are defined in [RFC7138], [RFC7688] and [RFC8363], respectively. 4.2. ISIS-TE ISIS-TE is introduced for TE networks in [RFC5305] and is extended to support GMPLS routing functions [RFC5307], and has been updated to [RFC7074] to support the latest GMPLS switching capability and Types fields. 4.3. Netconf/RESTconf Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally used for network configuration. Besides, these protocols can also be used for topology retrieval by using topology-related YANG models, such as [RFC8345] and [TE-topo]. These protocols provide a powerful mechanism for notification that permits to notify the client about topology changes. 5. 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 Yang Path Computation requests [PAT-COMP] to compute a set of potential optimal paths and then, based on its own constraints, policy and specific knowledge (e.g. cost of access link) can choose the more feasible path for service e2e 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. 5.1. Constraint-based Path Computing in GMPLS Control In GMPLS control, a routing path is computed by the ingress node [RFC3473] and is based on the ingress node TED. Constraint-based path computation is performed according to the local policy of the ingress node. 5.2. Path Computation Element (PCE) PCE has been introduced in [RFC4655] as a functional component that provides services to compute path in a network. In [RFC5440], the path computation is accomplished by using the Traffic Engineering Database (TED), which maintains the link resources in the network. The emergence of PCE efficiently improve the quality of network planning and offline computation, but there is a risk that the Zheng et. al Expires January 2020 [Page 7] Internet-Draft GMPLS and Controller Interwork July 2019 computed path may be infeasible if there is a diversity requirement, because stateless PCE has no knowledge about the former computed paths. To address this issue, stateful PCE has been proposed in [RFC8231]. Besides the TED, an additional LSP Database (LSP-DB) is introduced to archive each LSP computed by the PCE. In this way, PCE can easily figure out the relationship between the computing path and former computed paths. In this approach, PCE provides computed paths to PCC, and then PCC decides which path is deployed and when to be established. In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to 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 centralized controller system, the PCE can be implemented in a central controller, and the central controller performs path computation according to its local policies. On the other hand, the PCE can also be placed outside of the central controller. In this case, the central controller acts as a PCC to request path computation to the PCE through PCEP. One of the reference architecture can be found at [RFC7491]. 6. Signaling Options Signaling mechanisms are used to setup 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 RSVP-TE [RFC3473] have been extended to support different interfaces in GMPLS. 6.1. RSVP-TE RSVP-TE is introduced in [RFC3209] and extended to support GMPLS signaling in [RFC3473]. Several label formats are defined for a generalized label request, a generalized label, suggested label and label sets. Based on [RFC3473], RSVP-TE has been extended to support technology-specific signaling. The RSVP-TE extensions for OTN, WSON, optical flexi-grid network are defined in [RFC7139], [RFC7689], and [RFC7792], respectively. 7. Interworking Scenarios 7.1. Topology Collection & Synchronization Topology information is necessary on both network elements and controllers. The topology on network element is usually raw Zheng et. al Expires January 2020 [Page 8] Internet-Draft GMPLS and Controller Interwork July 2019 information, while the topology on the controller can be either raw or abstracted. Three different abstraction methods have been described in [RFC8453], and different controllers can select the corresponding method depending on application. When there are changes in the network topology, the impacted network element(s) 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 section 3 and 4. The topology synchronization between NEs and controllers can either be achieved by routing protocols OSPF- TE/PCEP-LS in [PCEP-LS] or Netconf protocol notifications with YANG model. 7.2. Multi-domain Service Provisioning Based on the topology information on controllers and network elements, service provisioning can be deployed. Plenty of methods have been specified for single domain service provisioning, such as using PCEP and RSVP-TE. Multi-domain service provisioning would request 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 hierachy 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 layer controllers, to configure the network elements to set up the path. A combination of the centralized and distributed protocols may be necessary for the interaction between network elements and controller. Several methods can be used to create the inter-domain path: 1) One end-to-end RSVP-TE session: In this method, an end-to-end RSVP-TE session from the source NE to the destination NE 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 to the first-end node, and then trigger a RSVP procedure along the path. Similarly, the interaction between the controller and the ingress node of a domain can be achieved by Netconf protocol with corresponding YANG models, and then completed by running RSVP among the network elements. Zheng et. al Expires January 2020 [Page 9] Internet-Draft GMPLS and Controller Interwork July 2019 This method requires the interworking of RSVP-TE protocols between different domains. 2) Multiple RSVP-TE sessions for multiple path segments: In this method, each SDN controller is responsible to create the path segment within its domain. Note that path segments in the source domain and the destination domain are "asymmetrical" segments, because the configuration of client signal mapping into server layer tunnel is needed at only one end of the segment, while configuration of server layer cross- connect is needed at the other end of the segment. For example, the path segment 1 and 3 in Figure 3 are asymmetrical segments, because one end of the segment requires mapping GE into ODU0, while the other end of the segment requires setting up ODU0 cross-connect. +-----------------+ +----------------+ +-----------------+ |Client | | | | Client| |Signal Domain 1| | Domain 2 | |Domain 3 Signal| |(GE) | | | | (GE) | | | ODU0 tunnel| | | | | | |+-+-+ ^ | | | | +-+-+| || | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | || || | | | | || || || | | | | || || | | | | | || || ******************************************************** || || | | | | || . || | | | | || . || | | | | || |+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+| +-----------------+ . +----------------+ . +-----------------+ . . . . .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->. . . . . Figure 3: Example of asymmetrical path segment The PCEP / GMPLS protocols should support creation of such asymmetrical segment. Note also that mechanisms to assign the labels in the inter-domain links are also needed to be considered. There are two possible methods: 2.1) Inter-domain labels assigned by NEs: The concept of 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 BRPC and H-PCE PCInitiate procedure, i.e., the ingress boarder node of each downstream domain assigns the stitching label for the inter-domain link between the downstream domain and its Zheng et. al Expires January 2020 [Page 10] Internet-Draft GMPLS and Controller Interwork July 2019 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 SDN controller: If the resource of inter-domain links are managed by the multi- domain SDN controller, each single-domain SDN controller can provide to the multi-domain SDN controller the list of available labels (e.g. timeslots if OTN is the scenario) using IETF Topology model and related technology specific extension. Once that multi-domain SDN controller has computed e2e path RSVP-TE or PCEP can be used in the different domains to setup related segment tunnel consisting with label inter-domain information, e.g. for PCEP the label ERO can be included in the PCInitiate message to indicate the inter-domain labels, so that each boarder node of each domain can configure the correct cross-connect within itself. 7.3. Multi-layer Service Provisioning For further study. Plan to be updated in the next version. 7.4. Recovery The GMPLS recovery functions are described in [RFC4426]. Two models, 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 is described in [RFC4872]. The extensions in [RFC4872] include protection, restoration, preemption, and rerouting mechanisms for an end-to-end LSP. Besides end-to-end recovery, a GMPLS segment recovery mechanism is defined in [RFC4873]. By introducing secondary record route objects, LSP segment can be switched to another path like fast reroute [RFC4090]. For the recovery with controllers, timely interaction between controller and network elements are required. Usually the re-routing can be decomposed into path computation and delivery, the controller can take some advantage in the path computation due to the global topology view. And the delivery can be achieved by the procedure described in section 7.2. 7.5. Controller Reliability Given the important role in the network, the reliability of controller is critical. Once a controller is shut down, the network should operate as well. It can be either achieved by controller back up or functionality back up. There are several of controller backup or federation mechanisms in the literature. It is also more reliable Zheng et. al Expires January 2020 [Page 11] Internet-Draft GMPLS and Controller Interwork July 2019 to have some function back up in the network element, to guarantee the performance in the network. 8. Manageability Considerations Each entity in the network, including both controllers and network elements, should be managed properly as it will interact with other entities. The manageability considerations in controller hierarchies and network elements still apply respectively. For the protocols applied in the network, manageability is also requested. The responsibility of each entity should be clarified. The control of function and policy among different controllers should be consistent via proper negotiation process. 9. Security Considerations This document provides the interwork between the GMPLS and controller hierarchies. The security requirements in both system still applies respectively. Protocols referenced in this document also have various security considerations, which is also expected to be satisfied. Other considerations on the interface between the controller and the network element are also important. Such security includes the functions to authenticate and authorize the control access to the controller from multiple network elements. Security mechanisms on the controller are also required to safeguard the underlying network elements against attacks on the control plane and/or unauthorized usage of data transport resources. 10. IANA Considerations This document requires no IANA actions. 11. References 11.1. Normative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Zheng et. al Expires January 2020 [Page 12] Internet-Draft GMPLS and Controller Interwork July 2019 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS Switching Capability and Type Fields", RFC 7074, November 2013. [RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for Application-Based Network Operations", RFC7491, March 2015. [RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D. and Zhang, X., "Problem Statement and Architecture for Information Exchange between Interconnected Traffic- Engineered Networks", RFC7926, July 2016. Zheng et. al Expires January 2020 [Page 13] Internet-Draft GMPLS and Controller Interwork July 2019 [RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF Protocol", RFC 8040, January 2017. [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Control of Traffic Engineered Networks", RFC 8453, August 2018. 11.2. Informative References [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label witching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, J.P., Farrel, A., "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February, 2008. [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, March 2014. [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, March 2014. Zheng et. al Expires January 2020 [Page 14] Internet-Draft GMPLS and Controller Interwork July 2019 [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, November 2015. [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., and H. Harai, "Signaling Extensions for Wavelength Switched Optical Networks", RFC 7689, November 2015. [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., and D. Ceccarelli, "RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7792, March 2016. [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, September 2017. [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", RFC 8281, October 2017. [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., Liu, X., "A YANG Data Model for Network Topologies", RFC 8345, March 2018. [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D. Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi- grid DWDM networks", RFC8363, February 2017. [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., Gonzalez De Dios, O., "YANG Data Model for Traffic Engineering (TE) Topologies", draft-ietf-teas-yang-te- topo-19, work in progress. [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang model for requesting Path Computation", draft-ietf-teas- yang-path-computation-04, work in progress. [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for Distribution of Link-State and TE Information", draft- dhodylee-pce-pcep-ls, work in progress. [TE-Tunnel] Saad, T. et al., "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. Zheng et. al Expires January 2020 [Page 15] Internet-Draft GMPLS and Controller Interwork July 2019 [sPCE-ID] Dugeon, O. et al., "PCEP Extension for Stateful Inter- Domain Tunnels", draft-dugeon-pce-stateful-interdomain, work in progress. 12. Authors' Addresses Haomian Zheng Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District, Shenzhen 518129 P.R.China Email: zhenghaomian@huawei.com Xianlong Luo Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District, Shenzhen 518129 P.R.China Email: luoxianlong@huawei.com Yunbin Xu CAICT Email: xuyunbin@ritt.cn Yang Zhao China Mobile Email: zhaoyangyjy@chinamobile.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Dieter Beller Nokia Email: Dieter.Beller@nokia.com Zheng et. al Expires January 2020 [Page 16]