Skip to main content

Interworking of GMPLS Control and Centralized Controller System

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Haomian Zheng , Xianlong Luo , Yang Zhao , Yunbin Xu , Sergio Belotti , Dieter Beller
Last updated 2018-12-06
Replaces draft-zheng-ccamp-gmpls-controller-inter-work
Replaced by draft-ietf-teas-gmpls-controller-inter-work, draft-ietf-teas-gmpls-controller-inter-work
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
TEAS Working Group                                        Haomian Zheng 
Internet Draft                                             Xianlong Luo 
Category: Informational                             Huawei Technologies  
                                                              Yang Zhao 
                                                           China Mobile 
                                                              Yunbin Xu 
                                                         Sergio Belotti 
                                                          Dieter Beller 
Expires: June 6, 2019                                  December 6, 2018 
     Interworking of GMPLS Control and Centralized Controller System 

   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-   

   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 June 2019                    [Page 1] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

   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 

   The list of Internet-Draft Shadow Directories can be accessed at 

   This Internet-Draft will expire on June 6, 2019. 

Copyright Notice 

   Copyright (c) 2018 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 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. 5 
   3. Link Management Protocol .................................... 6 
   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 April 2019                   [Page 2] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

      7.1. Topology Collection & Synchronization .................. 8 
      7.2. Multi-domain/layer Service Provisioning ................ 9 
      7.3. Recovery ............................................... 9 
      7.4. Controller Reliability ................................ 10 
   8. Manageability Considerations ............................... 10 
   9. Security Considerations .................................... 10 
   10. IANA Considerations........................................ 10 
   11. References ................................................ 11 
      11.1. Normative References ................................. 11 
      11.2. Informative References ............................... 12 
   12. Authors' Addresses ........................................ 14 
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 

   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 April 2019                   [Page 3] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

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 such as ACTN 
   [RFC8453]. In centralized controller systems, a controller is aware 
   of the network topology and is responsible for provisioning incoming 
   service requests. In ACTN, multiple abstraction levels are designed 
   and controllers at different levels implement different functions. 
   This kind of abstraction enables multi-vendor, multi-domain, and 
   multi-technology control. 

   For example in ACTN, an MDSC coordinates several PNCs controlling 
   different domains. Each PNC provides a topological view of the 
   domain it controls, which can be abstracted, to the MDSC, so that 
   the MDSC learns the topology of the network encompassing multiple 
   domains. When a multi-domain service request arrives at the MDSC, 
   the MDSC first computes an end-to-end path based on the abstracted 
   topology view provided by the PNCs. Then, the MDSC splits this path 
   to multiple segment according to domain boundaries and allocate each 
   segment to corresponding PNC for detailed path computation and LSP 
   segment setup. When each PNC has reported the establishment of its 
   LSP segment, the multi-domain service is established. 

Zheng et. al             Expires April 2019                   [Page 4] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

2.3. GMPLS Control Interwork with Centralized Controller System 

   The ACTN framework [RFC8453] defines a hierarchical controller 
   architecture and describes how these controllers communicate with 
   each other in order to control a multi-domain transport network. The 
   controllers at the different levels in the hierarchy typically 
   perform network abstraction of the domain they control and provide 
   an abstracted view of their domain to the controller at the next 
   level in the hierarchy. The controllers at the different 
   hierarchical levels also interact with each other during end-to-end 
   service establishment, which can span multiple domains. Within each 
   domain, GMPLS control can be applied to each NE. The bottom-level 
   central controller like PNC can act as a NE to collect network 
   information and initiate LSP. Figure 1 shows an example of GMPLS 
   interworking with ACTN. 

                        |   MDSC   | 
                          ^      ^ 
                          |      | 
                +---------+      +---------+ 
                |  RESTConf / YANG models  | 
                V                          V 
           +---------+                +---------+ 
           |   PNC   |                |   PNC   | 
           +---------+                +---------+ 
              ^   ^                      ^   ^ 
              |   |                      |   | 
       OSPF-TE|   |PCEP           OSPF-TE|   |PCEP 
       Netconf|   |               Netconf|   | 
              V   V                      V   V 
         .-------------.   Inter-   .-------------. 
        /               \  domain  /               \ 
       |       LMP       |  link  |       LMP       | 
      |      OSPF-TE     ==========     OSPF-TE      | 
       |     RSVP-TE     |        |     RSVP-TE     | 
        \               /          \               / 
          `------------`             `------------` 
           GMPLS domain               GMPLS domain 

       Figure 1: Example of GMPLS interworks with ACTN 

   In Figure 1, each domain has the GMPLS control plane enabled at the 
   physical network level. The PNC can listen to the IGP routing 
   protocol messages (OSPF LSAs for example) that the GMPLS control 
Zheng et. al             Expires April 2019                   [Page 5] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

   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 
   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 [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 Yang tunnel model together 
   with the technology-specific YANG model augmentations.  

3. Link Management Protocol 

   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. In this way, link 
   resources, which are fundamental resources in the network, are 
   discovered by both ends of the link. 

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 

   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 April 2019                   [Page 6] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

   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 MDSC may not have sufficient 
   information to compute the optimal path. In this case, the MDSC can 
   interact with different domain 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 April 2019                   [Page 7] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

   computed path may be infeasible if there is a diversity requirement, 
   because stateless PCE has no knowledge about the former computed 

   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 

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

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 
   information, while the topology on the controller can be either raw 
Zheng et. al             Expires April 2019                   [Page 8] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

   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 with YANG model.  

7.2. Multi-domain/layer 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/layer service provisioning would request coordination 
   among the controller hierarchies. Given the service request, the 
   end-to-end delivery procedure may include interactions on MPI and 
   SBI. The computation for a cross-domain/layer path is usually 
   completed by MDSC, who has a global view of the topologies. Then the 
   configuration is decomposed into lower layer controllers, including 
   both MDSC and PNCs, to configure the network elements to set up the 

   A combination of the centralized and distributed protocols may be 
   necessary for the interaction between network elements and 
   controller. 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.  

7.3. 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]. 
Zheng et. al             Expires April 2019                   [Page 9] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

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

Zheng et. al             Expires April 2019                  [Page 10] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

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. 

   [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 

Zheng et. al             Expires April 2019                  [Page 11] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

   [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 

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

   [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 



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. 

   [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. 
Zheng et. al             Expires April 2019                  [Page 12] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 

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

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

Zheng et. al             Expires April 2019                  [Page 13] 

Internet-Draft        GMPLS and Controller Interwork        December 2018 


12. Authors' Addresses 

   Haomian Zheng 
   Huawei Technologies 
   F3 R&D Center, Huawei Industrial Base, 
   Bantian, Longgang District, 
   Shenzhen 518129 P.R.China 
   Xianlong Luo 
   Huawei Technologies 
   F3 R&D Center, Huawei Industrial Base, 
   Bantian, Longgang District, 
   Shenzhen 518129 P.R.China 
   Yunbin Xu 
   Yang Zhao 
   China Mobile 
   Sergio Belotti  
   Dieter Beller 

Zheng et. al             Expires April 2019                  [Page 14]