RFC7025
Internet Engineering Task Force (IETF) T. Otani Request for Comments: 7025 K. Ogaki Category: Informational KDDI ISSN: 2070-1721 D. Caviglia
Ericsson
F. Zhang
Huawei Technologies
C. Margaria
Coriant R&D GmbH
September 2013
Requirements for GMPLS Applications of PCE
Abstract
The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7025.
Copyright Notice
Copyright (c) 2013 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.
Contents
Introduction
The initial effort of the PCE (Path Computation Element) WG focused mainly on solving the path computation problem within a domain or over different domains in MPLS networks. As with MPLS, service providers (SPs) have also come up with requirements for path computation in GMPLS-controlled networks RFC3945, such as those based on Wavelength Division Multiplexing (WDM), Time Division Multiplexing (TDM), or Ethernet.
RFC4655 and RFC4657 discuss the framework and requirements for PCE on both packet MPLS networks and GMPLS-controlled networks. This document complements those RFCs by providing considerations of GMPLS applications in the intradomain and interdomain networking environments and indicating a set of requirements for the extended definition of PCE-related protocols.
Note that the requirements for interlayer and inter-area traffic engineering (TE) described in RFC6457 and RFC4927 are outside of the scope of this document.
Constrained Shortest Path First (CSPF) computation within a domain or over domains for signaling GMPLS Label Switched Paths (LSPs) is usually more stringent than that of MPLS TE LSPs RFC4216, because the additional constraints, e.g., interface switching capability, link encoding, link protection capability, Shared Risk Link Group (SRLG) RFC4202, and so forth, need to be considered to establish GMPLS LSPs. The GMPLS signaling protocol RFC3473 is designed taking into account bidirectionality, switching type, encoding type, and protection attributes of the TE links spanned by the path, as well as LSP encoding and switching type of the endpoints, appropriately.
This document provides requirements for GMPLS applications of PCE in support of GMPLS path computation, included are requirements for both intradomain and interdomain environments.
GMPLS Applications of PCE
Path Computation in GMPLS Networks
Figure 1 depicts a model GMPLS network, consisting of an ingress link, a transit link, as well as an egress link. We will use this model to investigate consistent guidelines for GMPLS path computation. Each link at each interface has its own switching capability, encoding type, and bandwidth.
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ |Node1|------------>|Node2|------------>|Node3|------------>|Node4| | |<------------| |<------------| |<------------| | +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 1: Path Computation in GMPLS Networks
For the simplicity in consideration, the following basic assumptions are made when the LSP is created.
(1) Switching capabilities of outgoing links from the ingress and
egress nodes (link1-2 and link4-3 in Figure 1) are consistent
with each other.
(2) Switching capabilities of all transit links, including incoming
links to the ingress and egress nodes (link2-1 and link3-4) are
consistent with switching type of an LSP to be created.
(3) Encoding types of all transit links are consistent with the
encoding type of an LSP to be created.
GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are usually responsible for transmitting data for the client layer. These GMPLS-controlled networks can provide different types of connections for customer services based on different service bandwidth requests.
The applications and the corresponding additional requirements for applying PCE to GMPLS-based TDM networks are described in this section. In order to simplify the description, this document only discusses the scenario in Synchronous Digital Hierarchy (SDH) networks as an example (see Figure 2). The scenarios in Synchronous Optical Network (SONET) or Optical Transport Network (OTN) are similar.
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
Figure 2: A Simple TDM (SDH) Network
Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, N4, and N5 are all SDH switches; A1 and A2 are client devices (e.g., Ethernet switches). Assume that one Ethernet service with 100 Mbit/s bandwidth is required from A1 to A2 over this network. The client Ethernet service could be provided by a Virtual Container 4 (VC-4) container from N1 to N4; it could also be provided by three concatenated VC-3s (contiguous or virtual concatenation) from N1 to N4.
In this scenario, when the ingress node (e.g., N1) receives a client service transmitting request, the type of containers (one VC-4 or three concatenated VC-3s) could be determined by the PCC (Path Computation Client), e.g., N1 or Network Management System (NMS). However, it could also be determined automatically by the PCE based on policy RFC5394. If it is determined by the PCC, then the PCC should be capable of specifying the ingress node and egress node, signal type, the type of the concatenation, and the number of the concatenation in a PCReq (Path Computation Request) message. The PCE should consider those parameters during path computation. The route information (co-routing or diverse routing) should be specified in a PCRep (Path Computation Reply) message if path computation is performed successfully.
As described above, the PCC should be capable of specifying TE attributes defined in the next section, and the PCE should compute a path accordingly.
Where a GMPLS network consists of interdomain (e.g., inter-AS or inter-area) GMPLS-controlled networks, requirements on the path computation follow RFC5376 and RFC4726.
Unnumbered Interface
GMPLS supports unnumbered interface IDs as defined in RFC3477; this means that the endpoints of the path may be unnumbered. It should also be possible to request a path consisting of the mixture of numbered links and unnumbered links, or a P2MP (Point-to-Multipoint) path with different types of endpoints. Therefore, the PCC should be capable of indicating the unnumbered interface ID of the endpoints in the PCReq message.
Asymmetric Bandwidth Path Computation
Per RFC6387, GMPLS signaling can be used for setting up an asymmetric bandwidth bidirectional LSP. If a PCE is responsible for path computation, it should be capable of computing a path for the bidirectional LSP with asymmetric bandwidth. This means that the PCC should be able to indicate the asymmetric bandwidth requirements in forward and reverse directions in the PCReq message.
Requirements for GMPLS Applications of PCE
Requirements on Path Computation Request
As for path computation in GMPLS-controlled networks as discussed in Section 2, the PCE should appropriately consider the GMPLS TE attributes listed below once a PCC or another PCE requests a path computation. The path calculation request message from the PCC or the PCE must contain the information specifying appropriate attributes. According to RFC5440, [PCE-WSON-REQ], and RSVP procedures such as explicit label control (ELC), the additional attributes introduced are as follows:
(1) Switching capability/type: as defined in RFC3471, RFC4203,
and all current and future values.
(2) Encoding type: as defined in RFC3471, RFC4203, and all
current and future values.
(3) Signal type: as defined in RFC4606 and all current and future
values.
(4) Concatenation type: In SDH/SONET and OTN, two kinds of
concatenation modes are defined: contiguous concatenation,
which requires co-routing for each member signal and that all
the interfaces along the path support this capability, and
virtual concatenation, which allows diverse routing for member
signals and requires that only the ingress and egress
interfaces support this capability. Note that for the virtual
concatenation, it may also specify co-routing or diverse
routing. See RFC4606 and RFC4328 about concatenation
information.
(5) Concatenation number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also
see RFC4606 and RFC4328.
(6) Technology-specific label(s): as defined in RFC4606,
RFC6060, RFC6002, or RFC6205.
(7) End-to-End (E2E) path protection type: as defined in RFC4872,
e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting,
etc.
(8) Administrative group: as defined in RFC3630.
(9) Link protection type: as defined in RFC4203.
(10) Support for unnumbered interfaces: as defined in RFC3477.
(11) Support for asymmetric bandwidth requests: as defined in
RFC6387.
(12) Support for explicit label control during the path computation.
(13) Support of label restrictions in the requests/responses,
similar to RSVP-TE ERO (Explicit Route Object) and XRO (Exclude
Route Object), as defined in RFC3473 and RFC4874.
Requirements on Path Computation Reply
As described above, a PCE should compute the path that satisfies the constraints specified in the PCReq message. Then, the PCE should send a PCRep message, including the computation result, to the PCC. For a Path Computation Reply message (PCRep) in GMPLS networks, there are some additional requirements. The PCEP (PCE communication protocol) PCRep message must be extended to meet the following requirements.
(1) Path computation with concatenation
In the case of path computation involving concatenation, when a
PCE receives the PCReq message specifying the concatenation
constraints described in Section 3.1, the PCE should compute a
path accordingly.
For path computation involving contiguous concatenation, a
single route is required, and all the interfaces along the route
should support contiguous concatenation capability. Therefore,
the PCE should compute a path based on the contiguous
concatenation capability of each interface and only one ERO that
should carry the route information for the response.
For path computation involving virtual concatenation, only the
ingress/egress interfaces need to support virtual concatenation
capability, and there may be diverse routes for the different
member signals. Therefore, multiple EROs may be needed for the
response. Each ERO may represent the route of one or multiple
member signals. When one ERO represents multiple member
signals, the number must be specified.
(2) Label constraint
In the case that a PCC does not specify the exact label(s) when
requesting a label-restricted path and the PCE is capable of
performing the route computation and label assignment
computation procedure, the PCE needs to be able to specify the
label of the path in a PCRep message.
Wavelength restriction is a typical case of label restriction.
More generally, label switching and selection constraints may
apply in GMPLS-controlled networks, and a PCC may request a PCE
to take label constraint into account and return an ERO
containing the label or set of labels that fulfill the PCC
request.
(3) Roles of the routes
When a PCC specifies the protection type of an LSP, the PCE
should compute the working route and the corresponding
protection route(s). Therefore, the PCRep should allow to
distinguish the working (nominal) and the protection routes.
According to these routes, the RSVP-TE procedure appropriately
creates both the working and the protection LSPs, for example,
with the ASSOCIATION object RFC6689.
GMPLS PCE Management
This document does not change any of the management or operational details for networks that utilize PCE. (Please refer to RFC4655 for manageability considerations for a PCE-based architecture.) However, this document proposes the introduction of several PCEP objects and data for the better integration of PCE with GMPLS networks. Those protocol elements will need to be visible in any management tools that apply to the PCE, PCC, and PCEP. That includes, but is not limited to, adding appropriate objects to existing PCE MIB modules that are used for modeling and monitoring PCEP deployments [PCEP-MIB]. Ideas for what objects are needed may be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB RFC4802.
Security Considerations
PCEP extensions to support GMPLS should be considered under the same security as current PCE work, and this extension will not change the underlying security issues. Section 10 of RFC5440 describes the list of security considerations in PCEP. At the time RFC5440 was published, TCP Authentication Option (TCP-AO) had not been fully
specified for securing the TCP connections that underlie PCEP sessions. TCP-AO RFC5925 has now been published, and PCEP implementations should fully support TCP-AO according to RFC6952.
Acknowledgement
The authors would like to express thanks to Ramon Casellas, Julien Meuric, Adrian Farrel, Yaron Sheffer, and Shuichi Okamoto for their comments.
References
Normative References
RFC3471 Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, January 2003.
RFC3473 Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
RFC3477 Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, 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., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
RFC4202 Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
RFC4203 Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
RFC4328 Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
RFC4606 Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
RFC4802 Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
Switching (GMPLS) Traffic Engineering Management
Information Base", RFC 4802, February 2007.
RFC4872 Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
RFC4927 Le Roux, J., "Path Computation Element Communication
Protocol (PCECP) Specific Requirements for Inter-Area MPLS
and GMPLS Traffic Engineering", RFC 4927, June 2007.
RFC5376 Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November 2008.
RFC5440 Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
RFC6002 Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
Channel Switching Capable (DCSC) and Channel Set Label
Extensions", RFC 6002, October 2010.
RFC6060 Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering
(PBB-TE)", RFC 6060, March 2011.
RFC6205 Otani, T. and D. Li, "Generalized Labels for Lambda-
Switch-Capable (LSC) Label Switching Routers", RFC 6205, March 2011.
RFC6387 Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, September 2011.
RFC6689 Berger, L., "Usage of the RSVP ASSOCIATION Object",
RFC 6689, July 2012.
Informative References
[PCE-WSON-REQ]
Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
Tsuritani, T., and O. Dios, "PCEP Requirements for WSON
Routing and Wavelength Assignment", Work in Progress,
June 2013.
[PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "PCE communication protocol (PCEP) Management
Information Base", Work in Progress, July 2013.
RFC4216 Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
RFC4655 Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
RFC4657 Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, September 2006.
RFC4726 Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
RFC4874 Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
RFC5394 Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
RFC5925 Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
RFC6457 Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
Discovery Requirements for Inter-Layer Traffic
Engineering", RFC 6457, December 2011.
RFC6952 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
Authors' Addresses
Tomohiro Otani KDDI Corporation 2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo Japan Phone: +81-(3) 3347-6006 EMail: [email protected]
Kenichi Ogaki KDDI Corporation 3-10-10 Iidabashi Chiyoda-ku, Tokyo Japan Phone: +81-(3) 6678-0284 EMail: [email protected]
Diego Caviglia Ericsson 16153 Genova Cornigliano Italy Phone: +390106003736 EMail: [email protected]
Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District, Shenzhen 518129 P.R. China Phone: +86-755-28972912 EMail: [email protected]
Cyril Margaria Coriant R&D GmbH St Martin Strasse 76 Munich 81541 Germany Phone: +49 89 5159 16934 EMail: [email protected]
