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]