Skip to main content

Interworking of GMPLS Control and Centralized Controller System
draft-zheng-ccamp-gmpls-controller-inter-work-00

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 , Zheyu Fan , Yi Lin
Last updated 2017-10-30
Replaced by draft-zheng-teas-gmpls-controller-inter-work
RFC stream (None)
Formats
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)
draft-zheng-ccamp-gmpls-controller-inter-work-00
CCAMP Working Group                                       Haomian Zheng 
Internet Draft                                             Xianlong Luo 
Category: Informational                                       Zheyu Fan 
                                                                 Yi Lin 
                                                    Huawei Technologies 
Expires: April 30, 2018                                October 30, 2017 
                                    
                                    
     Interworking of GMPLS Control and Centralized Controller System 
                                    
                                    
              draft-zheng-ccamp-gmpls-controller-inter-work-00 

Abstract 
 
   Generalized Multi-Protocol Label Switching (GMPLS) control allows 
   each network element (NE) to perform resource discovery, routing and 
   signaling in a distributed manner. On the other hand, with the 
   development of software-defined transport networking technology, 
   central controllers are introduced to transport networks to control 
   a set of NEs.  

   In transport networks, the GMPLS control has many mature mechanisms 
   such as RSVP-TE, OSPF-TE, and LMP, so that GMPLS can be applied for 
   the NE-level control in the centralized controller systems.  

   This document describes how GMPLS control interworks with 
   centralized controller systems (e.g. ACTN) in 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 
   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. 
 
 
Zheng, et al.            Expires April 2018                    [Page 1] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

   This Internet-Draft will expire on April 30, 2018. 

Copyright Notice 

   Copyright (c) 2017 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 .................................................... 3 
   2.1. Overview of GMPLS Control Plane ........................... 3 
   2.2. Overview of Centralized Controller System ................. 4 
   2.3. GMPLS Control Interwork with Centralized Controller System  4 
   3. Link Management Protocol .................................... 5 
   4. Routing Options ............................................. 6 
      4.1. OSPF-TE ................................................ 6 
      4.2. ISIS-TE ................................................ 6 
   5. Path Computation ............................................ 6 
      5.1. Constraint-based Path Computing in GMPLS Control ....... 6 
      5.2. Path Computation Element (PCE) ......................... 7 
   6. Signaling Options ........................................... 7 
      6.1. RSVP-TE ................................................ 8 
      6.2. CR-LDP ................................................. 8 
   7. Recovery .................................................... 8 
   8. Network Management .......................................... 8 
   9. IANA Considerations ......................................... 8 
 
 
Zheng                    Expires April 2018                   [Page 2] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

   10. References ................................................. 9 
      10.1. Normative References .................................. 9 
      10.2. Informative References ............................... 11 
   11. Authors' Addresses ........................................ 11 
 
 
 
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 control plane collects network information 
   from other NEs and provisions services 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, which can locate outside of 
   the network, 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 systems, GMPLS can be applied for the 
   NE-level control. Introducing GMPLS in centralized controller system 
   can reuse the mature mechanisms defined for GMPLS and be practical 
   for legacy transport networks. This document describes how GMPLS 
   control interworks with centralized controller system in transport 
   network. 

2. Overview 

   In this section, overviews of GMPLS control plane and centralized 
   controller system are discussed as well as the cooperation between 
   GMPLS control plane and centralized controller system. 

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 has its controller to perform service provisioning, 
 
 
Zheng                    Expires April 2018                   [Page 3] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

   protection, and restoration. At the same time, the controller can 
   negotiate available link resources with controllers in adjacent 
   nodes, and it 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 by their local policies. 

2.2. Overview of Centralized Controller System 

   With the development of SDN technologies, centralized controller 
   system has been introduced to transport networks such as ACTN. 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 reports its topology, which can be 
   abstracted, to the MDSC, so that the MDSC learns the picture of 
   multiple domains. When a multi-domain service arrives at the MDSC, 
   the MDSC first computes an end-to-end routing path. 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. After each PNC reporting the 
   establishment of corresponding LSP segment, this multi-domain 
   service is accommodated. 

2.3. GMPLS Control Interwork with Centralized Controller System 

   Centralized controller system as ACTN provides the architecture and 
   communication between central controllers of different abstraction 
   levels to coordinate 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. 

 
 
Zheng                    Expires April 2018                   [Page 4] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

                        +----------+ 
                        |   MDSC   | 
                        +----------+ 
                          ^      ^ 
                          |      | 
                +---------+      +---------+ 
                |  RESTConf / YANG models  | 
                V                          V 
           +---------+                +---------+ 
           |   PNC   |                |   PNC   | 
           +---------+                +---------+ 
              ^   ^                      ^   ^ 
              |   |                      |   | 
       OSPF-TE|   |PCEP           OSPF-TE|   |PCEP 
              |   |                      |   | 
              |   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 runs GMPLS control. The PNC listens LSAs 
   flooded in the domain and learns the topology. For path computation 
   in the domain with PNC implementing a PCE, NEs use PCEP to ask the 
   PNC for a path and get replies. The MDSC communicates with PNCs 
   using RESTConf or YANG 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. 

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 

 
 
Zheng                    Expires April 2018                   [Page 5] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

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

5. Path Computation 

   Once a controller learn the network topology, it can utilize the 
   available resources to serve service requests by performing path 
   computation. 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 
 
 
Zheng                    Expires April 2018                   [Page 6] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

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

   In centralized controller system, the central controller can manage 
   LSPs by using PCE-initiation [I-D.ietf-pce-pce-initiated-lsp] to 

 
 
Zheng                    Expires April 2018                   [Page 7] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

   notify the corresponding ingress node. The ingress node will 
   maintain the LSP through GMPLS signaling. 

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. 

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. 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 rereoute 
   [RFC4090]. 

8. Network Management 

   TBD. 

9. Security Considerations 

   TBD. 

10. IANA Considerations 

   This document requires no IANA actions. 

 
 
Zheng                    Expires April 2018                   [Page 8] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

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 April 2018                   [Page 9] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

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

   [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 April 2018                   [Page 10] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

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

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

   [I-D.ietf-pce-pce-initiated-lsp]  Crabbe, E., Minei, I., Sivabalan, 
             S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 
             Setup in a Stateful PCE Model", draft-ietf-pce-pce-
             initiated-lsp-11 (work in progress), October 2017. 

   [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-11 
             (work in progress), October 2017. 

    

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 

 
 
Zheng                    Expires April 2018                   [Page 11] 


Internet-Draft        GMPLS and Controller Interwork        October 2017 

   F3 R&D Center, Huawei Industrial Base, 
   Bantian, Longgang District, 
   Shenzhen 518129 P.R.China 
   Email: luoxianlong@huawei.com 
    
   Zheyu Fan 
   Huawei Technologies 
   F3 R&D Center, Huawei Industrial Base, 
   Bantian, Longgang District, 
   Shenzhen 518129 P.R.China 
   Email: fanzheyu2@huawei.com 
    
   Yi Lin 
   Huawei Technologies 
   F3 R&D Center, Huawei Industrial Base, 
   Bantian, Longgang District, 
   Shenzhen 518129 P.R.China 
   Email: yi.lin@huawei.com 
    
 

 
 
Zheng                    Expires April 2018                   [Page 12]