CCAMP 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: December 27, 2018                                June 27, 2018


     Interworking of GMPLS Control and Centralized Controller System


              draft-zheng-ccamp-gmpls-controller-inter-work-02


Abstract

   Generalized Multi-Protocol Label Switching (GMPLS) control allows
   each network element (NE) to perform local resource discovery (e.g.,
   LMP), routing (e.g., OSPF-TE) and signaling (e.g., RSVP-TE) 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 [I-D.ietf-
   teas-actn-framework].

   Instead of competing with each other, both the distributed and the
   centralized control plane have their own advantage, 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 December 2018                  [Page 1]


Internet-Draft        GMPLS and Controller Interwork        June 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
   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 December 27, 2018.

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
   (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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



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
   5. Path Computation ............................................ 7
      5.1. Constraint-based Path Computing in GMPLS Control........ 7


Zheng                  Expires September 2018                 [Page 2]


Internet-Draft        GMPLS and Controller Interwork        June 2018


      5.2. Path Computation Element (PCE) ......................... 7
   6. Signaling Options ........................................... 8
      6.1. RSVP-TE ................................................ 8
      6.2. CR-LDP ................................................. 9
   7. Interworking Scenarios....................................... 9
      7.1. Topology Collection & Synchronization .................. 9
      7.2. Multi-domain/layer Service Provisioning ................ 9
      7.3. Recovery .............................................. 10
      7.4. Controller Reliability................................. 10
   8. Network Management ......................................... 10
   9. Security Considerations .................................... 10
   10. IANA Considerations........................................ 10
   11. References ................................................ 11
      11.1. Normative References ................................. 11
      11.2. Informative References................................ 14
   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.

   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) [I-D.ietf-teas-actn-framework], which
   defines a hierarchical architecture with PNC, MDSC and CNC as
   central controllers for different network abstraction levels.

   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                  Expires September 2018                 [Page 3]


Internet-Draft        GMPLS and Controller Interwork        June 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 LSP. In this way, controllers in different
   nodes in the network have the same 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
   [I-D.ietf-teas-actn-framework]. In centralized controller system, 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                  Expires September 2018                 [Page 4]


Internet-Draft        GMPLS and Controller Interwork        June 2018


2.3. GMPLS Control Interwork with Centralized Controller System

   The ACTN framework [I-D.ietf-teas-actn-framework] 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. Following figure 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


Zheng                  Expires September 2018                 [Page 5]


Internet-Draft        GMPLS and Controller Interwork        June 2018


   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
   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 setup and
   maintain 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
   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


Zheng                  Expires September 2018                 [Page 6]


Internet-Draft        GMPLS and Controller Interwork        June 2018


   state information for GMPLS network. Based on this work, OSPF
   protocol has been extended to support technology-specific routing.
   The routing protocol for OTN, WSON and optical flexi-grid network
   are defined in [RFC7138], [RFC7688] and [I-D.ietf-ccamp-flexible-
   grid-ospf-ext], 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 learn 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


Zheng                  Expires September 2018                 [Page 7]


Internet-Draft        GMPLS and Controller Interwork        June 2018


   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
   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 [I-D.ietf-pce-pce-initiated-lsp], 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 mechanism is 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] and CR-LDP [RFC3472] 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.





Zheng                  Expires September 2018                 [Page 8]


Internet-Draft        GMPLS and Controller Interwork        June 2018


6.2. CR-LDP

   In order to support the label formats and signaling mechanism
   defined in [RFC3471], CR-LDP is extended in [RFC3472]. Several label
   formats are defined and bidirectional LSPs are supported.

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
   or abstracted. Three different abstraction method has been described
   in [I-D.ietf-teas-actn-framework], 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
   path.

   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



Zheng                  Expires September 2018                 [Page 9]


Internet-Draft        GMPLS and Controller Interwork        June 2018


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

   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. Network Management

   TBD.

9. Security Considerations

   TBD.

10. IANA Considerations

   This document requires no IANA actions.







Zheng                  Expires September 2018                [Page 10]


Internet-Draft        GMPLS and Controller Interwork        June 2018


11. References

11.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

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

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Functional Description", RFC
             3471, January 2003.

   [RFC3472]  Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized
             Multi-Protocol Label Switching (GMPLS) Signaling
             Constraint-based Routed Label Distribution Protocol (CR-
             LDP) Extensions", RFC 3472, January 2003.

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

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

   [RFC4203]  Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4203, October 2005.

   [RFC4204]  Lang, J., Ed., "Link Management Protocol (LMP)", RFC
             4204, October 2005.





Zheng                  Expires September 2018                [Page 11]


Internet-Draft        GMPLS and Controller Interwork        June 2018


   [RFC4426]  Lang, J., Ed., Rajagopalan, B., Ed., and D.
             Papadimitriou, Ed., "Generalized Multi-Protocol Label
             witching (GMPLS) Recovery Functional Specification", RFC
             4426, March 2006.

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

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

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


Zheng                  Expires September 2018                [Page 12]


Internet-Draft        GMPLS and Controller Interwork        June 2018


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

   [RFC8040]  Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF
             Protocol", RFC 8040, January 2017.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
             Computation Element Communication Protocol (PCEP)
             Extensions for Stateful PCE", RFC 8231, September 2017.

   [I-D.ietf-ccamp-flexible-grid-ospf-ext]  Zhang, X., Zheng, H.,
             Casellas, R., Dios, O., and D. Ceccarelli, "GMPLS OSPF-TE
             Extensions in support of Flexi-grid DWDM networks", draft-
             ietf-ccamp-flexible-grid-ospf-ext-09 (work in progress),
             February 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.

   [I-D.ietf-teas-actn-framework]  Ceccarelli, D. and Y. Lee,
             "Framework for Abstraction and Control of Traffic
             Engineered Networks", draft-ietf-teas-actn-framework work
             in progress.

   [I-D. dhodylee-pce-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-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-15, 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-01, work in progress.


Zheng                  Expires September 2018                [Page 13]


Internet-Draft        GMPLS and Controller Interwork        June 2018






11.2. Informative References



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                  Expires September 2018                [Page 14]