Network Working Group T. Otani
Internet-Draft KDDI
Intended status: Informational K. Ogaki
Expires: September 13, 2013 KDDI R&D Labs.
D. Caviglia
Ericsson
F. Zhang
Huawei Technologies Co., Ltd.
C. Cyril
Nokia Siemens Networks Optical
GmbH
March 12, 2013
Requirements for GMPLS applications of PCE
draft-ietf-pce-gmpls-aps-req-07.txt
Abstract
The initial effort of the PCE WG is specifically focused on MPLS
(Multi-protocol label switching). As a next step, this draft
describes functional requirements for GMPLS (Generalized MPLS)
application of PCE (Path computation element).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 13, 2013.
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
Otani, et al. Expires September 13, 2013 [Page 1]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. GMPLS applications of PCE . . . . . . . . . . . . . . . . . . 3
2.1. Path computation in GMPLS network . . . . . . . . . . . . 3
2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . . 6
2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 6
3. Requirements for GMPLS application of PCE . . . . . . . . . . 6
3.1. Requirements on Path Computation Request . . . . . . . . . 6
3.2. Requirements on Path Computation Reply . . . . . . . . . . 7
3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Otani, et al. Expires September 13, 2013 [Page 2]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
1. Introduction
The initial effort of the PCE WG is focused on solving the path
computation problem within a domain or over different domains in MPLS
networks. As the same case with MPLS, service providers (SPs) have
also come up with requirements for path computation in GMPLS-
controlled networks such as wavelength, TDM-based or Ethernet-based
networks as well.
[RFC4655] and [RFC4657] discuss the framework and requirements for
PCE on both packet MPLS networks and GMPLS-controlled networks. This
document complements these RFCs by providing some considerations of
GMPLS applications in the intra-domain and inter-domain networking
environments and indicating a set of requirements for the extended
definition of PCE-related protocols.
Note that the requirements for inter-layer traffic engineering
described in [RFC6457] are outside of the scope of this document.
Constraint-based 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 and so forth
need to be considered to establish GMPLS LSPs. GMPLS signaling
protocol [RFC3473] is designed taking into account bi-directionality,
switching type, encoding type, SRLGs and protection attributes of the
TE links spanned by the path, as well as LSP encoding and switching
type of the end points, appropriately.
This document provides the investigated results of GMPLS applications
of PCE for the support of GMPLS path computation. This document also
provides requirements for GMPLS applications of PCE in GMPLS intra-
domain and inter-domain environments.
2. GMPLS applications of PCE
2.1. Path computation in GMPLS network
Figure 1 depicts a typical GMPLS network, consisting of an ingress
link, a transit link as well as an egress link, to investigate a
consistent guideline for GMPLS path computation. Each link at each
interface has its own switching capability, encoding type and
bandwidth.
Otani, et al. Expires September 13, 2013 [Page 3]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
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 below 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 a LSP to be created.
(3) Encoding-types of all transit links are consistent with encoding
type of a 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, for example, GMPLS-based TDM networks, are described
in Figure 2. In order to simplify the description, this document
just discusses the scenario in SDH networks as an example. The
scenarios in SONET or G.709 ODUk layer networks are similar to this
scenario.
Otani, et al. Expires September 13, 2013 [Page 4]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
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. Assume that one Ethernet service
with 100M bandwidth is required from A1 to A2 over this network. The
client Ethernet service could be provided by a VC4 connection from N1
to N4, and it could also be provided by three concatenated VC3
connections (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 connections (one VC4 or
three concatenated VC3) could be determined by PCC (e.g., N1 or NMS),
but could also be determined by PCE automatically based on policy
[RFC5394]. If it is determined by PCC, 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
message. PCE should consider those parameters during path
computation. The route information (co-route or separated-route)
should be specified in a PCRep message if path computation is
performed successfully.
As described above, PCC should be capable of specifying TE attributes
defined in the next section and PCE should compute a path
accordingly.
Where a GMPLS network is consisting of inter-domain (e.g., inter-AS
or inter-area) GMPLS-controlled networks, requirements on the path
computation follows [RFC5376] and [RFC4726].
Otani, et al. Expires September 13, 2013 [Page 5]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
2.2. Unnumbered Interface
GMPLS supports unnumbered interface ID that is defined in [RFC3477],
which 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 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.
2.3. Asymmetric Bandwidth Path Computation
As per [RFC6387], GMPLS signaling can be used for setting up an
asymmetric bandwidth bidirectional LSP. If a PCE is responsible for
the path computation, the PCE should be capable of computing a path
for the bidirectional LSP with asymmetric bandwidth. It means that
the PCC should be able to indicate the asymmetric bandwidth
requirements in forward and reverse directions in the PCReq message.
3. Requirements for GMPLS application of PCE
3.1. Requirements on Path Computation Request
As for path computation in GMPLS-controlled networks as discussed in
section 2, the PCE should consider the GMPLS TE attributes
appropriately once a PCC or another PCE requests a path computation.
Indeed, 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 to RSVP procedures like
explicit label control(ELC),the additional attributes introduced are
as follows:
(1) Switching capability: PSC1-4, L2SC, DCSC [RFC6002], EVPL
[RFC6004], 802_1 PBB-TE [RFC6060], TDM, lambda, LSC, FSC
(2) Encoding type: as defined in [RFC4202], [RFC4203], e.g.,
Ethernet, SONET/SDH, Lambda, etc.
(3) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with different
granularity have been defined in SONET/SDH and G.709 ODUk, such as
VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3 in G.709
ODUk. See [RFC4606], [RFC4328] and [OSPF-G709] or [RSVP-TE-G709].
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two
kinds of concatenation modes are defined: contiguous concatenation
which requires co-route for each member signal and requires all the
Otani, et al. Expires September 13, 2013 [Page 6]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
interfaces along the path to support this capability, and virtual
concatenation which allows diverse routes for the member signals and
only requires the ingress and egress interfaces to support this
capability. Note that for the virtual concatenation, it also may
specify co-routed or separated-routed. 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) such as defined in [RFC4606],
[RFC6060], [RFC6002] or [RFC6205].
(7) 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 request: as defined in [RFC6387]
(12)Support for explicit label control during the path computation.
(13)Support of label restrictions in the requests/responses,
similarly to RSVP-TE ERO and XRO as defined in [RFC3473] and
[RFC4874].
3.2. Requirements on Path Computation Reply
As described above, a PCE should compute the path that satisfies the
constraints which are specified in the PCReq message. Then the PCE
should send a PCRep message including the computation result to the
PCC. For Path Computation Reply message (PCRep) in GMPLS networks,
there are some additional requirements. The PCEP 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
Otani, et al. Expires September 13, 2013 [Page 7]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
support contiguous concatenation capability. Therefore, the PCE
should compute a path based on the contiguous concatenation
capability of each interface and only one ERO which 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.
In the case where one ERO represents several member signals among the
total member signals, the number of member signals along the route of
the ERO must be specified.
(2) Label constraint
In the case that a PCC does not specify the exact label(s) when
requesting a label-resctricted 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 in GMPLS-controlled networks label switching and selection
constraints may apply and a PCC may request a PCE to take label
constraint into account and return an ERO containing the label or set
of label that fulfil 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.
3.3. GMPLS PCE Management
PCE-related Management Information Bases must consider extensions to
be satisfied with requirements for GMPLS applications. For
extensions, [RFC4802] are defined to manage TE database and may be
referred to so as to accommodate GMPLS TE attributes in the PCE.
4. Security Considerations
PCEP extensions to support GMPLS should be considered under the same
security as current PCE work. This extension will not change the
underlying security issues.
Otani, et al. Expires September 13, 2013 [Page 8]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgement
The author would like to express the thanks to Ramon Casellas, Julien
Meulic and Shuichi Okamoto for their comments.
7. References
7.1. Normative References
[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
Otani, et al. Expires September 13, 2013 [Page 9]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
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.
[RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
for Metro Ethernet Forum and G.8011 Ethernet Service
Switching", RFC 6004, 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.
7.2. Informative References
[OSPF-G709]
Ceccarelli, D., "Traffic Engineering Extensions to OSPF
for Generalized MPLS(GMPLS) Control of Evolving G.709 OTN
Networks", draft-ietf-ccamp-gmpls-ospf-g709v3-05 (work in
progress), January 2013.
Otani, et al. Expires September 13, 2013 [Page 10]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
[PCE-WSON-REQ]
Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON
Routing and Wavelength Assignment",
draft-ietf-pce-wson-routing-wavelength-08 (work in
progress), October 2012.
[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.
[RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
Discovery Requirements for Inter-Layer Traffic
Engineering", RFC 6457, December 2011.
[RSVP-TE-G709]
Zhang, F., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Extensions for the evolving G.709
Optical Transport Networks Control",
draft-ietf-ccamp-gmpls-signaling-g709v3-06 (work in
progress), January 2013.
Otani, et al. Expires September 13, 2013 [Page 11]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
Authors' Addresses
Tomohiro Otani
KDDI Corporation
2-3-2 Nishi-shinjuku
Shinjuku-ku, Tokyo
Japan
Phone: +81-(3) 3347-6006
Email: tm-otani@kddi.com
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara
Kamifukuoka, Saitama
Japan
Phone: +81-(49) 278-7897
Email: ogaki@kddilabs.jp
Diego Caviglia
Ericsson
16153 Genova Cornigliano
Italy
Phone: +390106003736
Email: diego.caviglia@ericsson.com
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: zhangfatai@huawei.com
Otani, et al. Expires September 13, 2013 [Page 12]
Internet-Draft Reqs for GMPLS apps of PCE March 2013
Cyril Margaria
Nokia Siemens Networks Optical GmbH
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com
Otani, et al. Expires September 13, 2013 [Page 13]