draft-ietf-pce-gmpls-aps-req-06.txt   draft-ietf-pce-gmpls-aps-req-07.txt 
Network Working Group Tomohiro Otani
Internet-Draft KDDI Network Working Group T. Otani
Intended status: Informational Kenichi Ogaki Internet-Draft KDDI
KDDI R&D Labs Intended status: Informational K. Ogaki
Diego Caviglia Expires: September 13, 2013 KDDI R&D Labs.
Ericsson D. Caviglia
Fatai Zhang Ericsson
Huawei F. Zhang
Expires: December 27, 2012 June 27, 2012 Huawei Technologies Co., Ltd.
C. Cyril
Nokia Siemens Networks Optical
GmbH
March 12, 2013
Requirements for GMPLS applications of PCE Requirements for GMPLS applications of PCE
draft-ietf-pce-gmpls-aps-req-07.txt
Document: draft-ietf-pce-gmpls-aps-req-06.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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
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, 2012. 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."
Abstract This Internet-Draft will expire on September 13, 2013.
The initial effort of PCE WG is specifically focused on MPLS (Multi- Copyright Notice
protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element).
Conventions used in this document Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is subject to BCP 78 and the IETF Trust's Legal
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Provisions Relating to IETF Documents
document are to be interpreted as described in RFC-2119 [RFC2119]. (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 Table of Contents
1. Introduction ................................................. 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology .................................................. 3 2. GMPLS applications of PCE . . . . . . . . . . . . . . . . . . 3
3. GMPLS applications of PCE .................................... 3 2.1. Path computation in GMPLS network . . . . . . . . . . . . 3
3.1. GMPLS network model ..................................... 3 2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . . 6
3.2. Path computation in GMPLS network ....................... 4 2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 6
3.3. Unnumbered Interfaces ................................... 6 3. Requirements for GMPLS application of PCE . . . . . . . . . . 6
3.4. Asymmetric Bandwidth Path Computation ................... 6 3.1. Requirements on Path Computation Request . . . . . . . . . 6
4. Requirements for GMPLS application of PCE .................... 6 3.2. Requirements on Path Computation Reply . . . . . . . . . . 7
4.1. Requirements of Path Computation Request ................ 6 3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . . 8
4.2. Requirements of Path Computation Reply .................. 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.3. GMPLS PCE Management .................................... 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security consideration ....................................... 9 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations .......................................... 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgement .............................................. 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8. References ................................................... 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
8.1. Normative References..................................... 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References................................... 11
9. Authors' Addresses ........................................... 13
1. Introduction 1. Introduction
The initial effort of PCE WG is focused on solving the path The initial effort of the PCE WG is focused on solving the path
computation problem within a domain or over different domains in computation problem within a domain or over different domains in MPLS
MPLS networks. As the same case with MPLS, service providers (SPs) networks. As the same case with MPLS, service providers (SPs) have
have also come up with requirements for path computation in GMPLS also come up with requirements for path computation in GMPLS-
networks such as wavelength, TDM-based or Ethernet-based networks as controlled networks such as wavelength, TDM-based or Ethernet-based
well. networks as well.
[RFC4655] and [RFC4657] discuss the framework and requirements for [RFC4655] and [RFC4657] discuss the framework and requirements for
PCE on both packet MPLS networks and (non-packet switch capable) PCE on both packet MPLS networks and GMPLS-controlled networks. This
GMPLS networks. This document complements these documents by document complements these RFCs by providing some considerations of
providing some considerations of GMPLS applications in the intra- GMPLS applications in the intra-domain and inter-domain networking
domain and inter-domain networking environments and indicating a set environments and indicating a set of requirements for the extended
of requirements for the extended definition of series of PCE related definition of PCE-related protocols.
protocols.
Note that the requirements for inter-layer traffic engineering Note that the requirements for inter-layer traffic engineering
described in [RFC6457] are outside of the scope of this document. described in [RFC6457] are outside of the scope of this document.
Constraint based shortest path first (CSPF) computation within a Constraint-based shortest path first (CSPF) computation within a
domain or over domains for signaling GMPLS Label Switched Paths domain or over domains for signaling GMPLS Label Switched Paths
(LSPs) is more stringent than that of MPLS TE LSPs [RFC4216], (LSPs) is usually more stringent than that of MPLS TE LSPs [RFC4216],
because the additional constraints, e.g., interface switching because the additional constraints, e.g., interface switching
capability, link encoding, link protection capability and so forth capability, link encoding, link protection capability and so forth
need to be considered to establish GMPLS LSPs [CSPF]. GMPLS need to be considered to establish GMPLS LSPs. GMPLS signaling
signaling protocol [RFC3471, RFC3473] is designed taking into protocol [RFC3473] is designed taking into account bi-directionality,
account bi-directionality, switching type, encoding type, SRLG, and switching type, encoding type, SRLGs and protection attributes of the
protection attributes of the TE links spanned by the path, as well TE links spanned by the path, as well as LSP encoding and switching
as LSP encoding and switching type for the end points, appropriately. 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. Terminology
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].
3. GMPLS applications of PCE
3.1. GMPLS network model
Figure 1 depicts a typical network, consisting of several GMPLS
domains, assumed in this document. D1, D2, D3 and D4 have multiple
inter-domain links, while D5 has only one inter-domain link. These
domains follow the definition in [RFC4726].
+---------+
+---------|GMPLS D2|----------+
| +----+----+ |
+----+----+ | +----+----+ +---------+
|GMPLS D1| | |GMPLS D4|---|GMPLS D5|
+----+----+ | +----+----+ +---------+
| +----+----+ |
+---------|GMPLS D3|----------+
+---------+
Figure 1: GMPLS Inter-domain network model. 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.
Each domain is configured using various switching and link 2. GMPLS applications of PCE
technologies defined in [RFC3945] and an end-to-end route needs to
respect TE link attributes like switching capability, encoding type,
etc., making the problem a bit different from the case of classical
(packet) MPLS. In order to route from one GMPLS domain to another
GMPLS domain appropriately, each domain manages traffic engineering
database (TED) by PCE, and exchanges or provides route information
of paths, while concealing its internal topology information.
3.2. Path computation in GMPLS network 2.1. Path computation in GMPLS network
[CSPF] describes consideration of GMPLS TE attributes during path Figure 1 depicts a typical GMPLS network, consisting of an ingress
computation. Figure 2 depicts a typical GMPLS network, consisting of link, a transit link as well as an egress link, to investigate a
an ingress link, a transit link as well as an egress link, to consistent guideline for GMPLS path computation. Each link at each
investigate a consistent guideline for GMPLS path computation. Each interface has its own switching capability, encoding type and
link at each interface has its own switching capability, encoding bandwidth.
type and bandwidth.
Ingress Transit Egress Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4| |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| | | |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 2: Path computation in GMPLS networks. Figure 1: Path computation in GMPLS networks
For the simplicity in consideration, the below basic assumptions are For the simplicity in consideration, the below basic assumptions are
made when the LSP is created. made when the LSP is created.
(1) Switching capabilities of outgoing links from the ingress and (1) Switching capabilities of outgoing links from the ingress and
egress nodes (link1-2 and link4-3 in Figure 2) must be consistent egress nodes (link1-2 and link4-3 in Figure 1) are consistent with
with each other. each other.
(2) Switching capabilities of all transit links including incoming (2) Switching capabilities of all transit links including incoming
links to the ingress and egress nodes (link2-1 and link3-4) should links to the ingress and egress nodes (link2-1 and link3-4) are
be consistent with switching type of a LSP to be created. consistent with switching type of a LSP to be created.
(3) Encoding-types of all transit links should be consistent with
encoding type of a LSP to be created.
[CSPF] indicates the possible tables of switching capability, (3) Encoding-types of all transit links are consistent with encoding
encoding type and bandwidth at the ingress link, transiting links type of a LSP to be created.
and the egress link which need to be satisfied with GMPLS path
computation of the created LSP.
The non-packet GMPLS networks (e.g., GMPLS-based TDM networks) are GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are
usually responsible for transmitting data for the client layer. usually responsible for transmitting data for the client layer.
These GMPLS networks can provide different types of connections for These GMPLS-controlled networks can provide different types of
customer services based on different service bandwidth requests. connections for customer services based on different service
bandwidth requests.
The applications and the corresponding additional requirements for The applications and the corresponding additional requirements for
applying PCE to non-packet networks, for example, GMPLS-based TDM applying PCE to, for example, GMPLS-based TDM networks, are described
networks, are described in Figure 3. In order to simplify the in Figure 2. In order to simplify the description, this document
description, this document just discusses the scenario in SDH just discusses the scenario in SDH networks as an example. The
networks as an example. The scenarios in SONET or G.709 ODUk layer scenarios in SONET or G.709 ODUk layer networks are similar to this
networks are similar to this scenario. scenario.
N1 N2
+-----+ +------+ +------+ N1 N2
| |-------| |--------------| | +-------+ +-----+ +------+ +------+
+-----+ | |---| | | | | | |-------| |--------------| | +-------+
A1 +------+ | +------+ | | +-----+ | |---| | | | |
| | | +-------+ A1 +------+ | +------+ | |
| | | PCE | | | +-------+
| | | | | | PCE
| +------+ | | | |
| | | | | +------+ |
| | |-----| | | | | |
| +------+ | | | | |-----| |
| N5 | | | +------+ | |
| | | | N5 | |
+------+ +------+ | | |
| | | | +-----+ +------+ +------+
| |--------------| |--------| | | | | | +-----+
+------+ +------+ +-----+ | |--------------| |--------| |
N3 N4 A2 +------+ +------+ +-----+
N3 N4 A2
Figure 3: A simple TDM(SDH) network Figure 2: A simple TDM (SDH) network
Figure 3 shows a simple TDM(SDH) network topology, where N1, N2, N3, 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 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 with 100M bandwidth is required from A1 to A2 over this network. The
client Ethernet service could be provided by a VC4 connection from client Ethernet service could be provided by a VC4 connection from N1
N1 to N4, and it could also be provided by three concatenated VC3 to N4, and it could also be provided by three concatenated VC3
connections (Contiguous or Virtual concatenation) from N1 to N4. connections (Contiguous or Virtual concatenation) from N1 to N4.
In this scenario, when the ingress node (e.g., N1) receives a client In this scenario, when the ingress node (e.g., N1) receives a client
service transmitting request, the type of connections (one VC4 or service transmitting request, the type of connections (one VC4 or
three concatenated VC3) could be determined by PCC (e.g., N1 or NMS), three concatenated VC3) could be determined by PCC (e.g., N1 or NMS),
but could also be determined by PCE automatically based on policy but could also be determined by PCE automatically based on policy
[RFC5394]. If it is determined by PCC, PCC should be capable of [RFC5394]. If it is determined by PCC, PCC should be capable of
specifying the ingress node and egress node, signal type, the type specifying the ingress node and egress node, signal type, the type of
of the concatenation and the number of the concatenation in a PCReq the concatenation and the number of the concatenation in a PCReq
message. PCE should consider those parameters during path message. PCE should consider those parameters during path
computation. The route information (co-route or separated-route) computation. The route information (co-route or separated-route)
should be specified in a PCRep message if path computation is should be specified in a PCRep message if path computation is
performed successfully. performed successfully.
3.3. Unnumbered Interfaces As described above, PCC should be capable of specifying TE attributes
defined in the next section and PCE should compute a path
accordingly.
GMPLS supports unnumbered interface ID that is defined in [RFC 3477], Where a GMPLS network is consisting of inter-domain (e.g., inter-AS
which means that the endpoints of the path may be unnumbered. It or inter-area) GMPLS-controlled networks, requirements on the path
computation follows [RFC5376] and [RFC4726].
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 should also be possible to request a path consisting of the mixture
of numbered links and unnumbered links, or a P2MP path with of numbered links and unnumbered links, or a P2MP path with different
different types of endpoints. Therefore, the PCC should be capable types of endpoints. Therefore, the PCC should be capable of
of indicating the unnumbered interface ID of the endpoints in the indicating the unnumbered interface ID of the endpoints in the PCReq
PCReq message. message.
3.4. Asymmetric Bandwidth Path Computation 2.3. Asymmetric Bandwidth Path Computation
As per [RFC6387], GMPLS signaling can be used for setting up an As per [RFC6387], GMPLS signaling can be used for setting up an
asymmetric bandwidth bidirectional LSP. If a PCE is responsible for asymmetric bandwidth bidirectional LSP. If a PCE is responsible for
the path computation, the PCE should be capable of computing a path the path computation, the PCE should be capable of computing a path
for the bidirectional LSP with asymmetric bandwidth. It means that for the bidirectional LSP with asymmetric bandwidth. It means that
the PCC should be able to indicate the asymmetric bandwidth the PCC should be able to indicate the asymmetric bandwidth
requirements in forward and reverse directions in the PCReq message. requirements in forward and reverse directions in the PCReq message.
4. Requirements for GMPLS application of PCE 3. Requirements for GMPLS application of PCE
In this section, we describe requirements for GMPLS applications of 3.1. Requirements on Path Computation Request
PCE in order to establish GMPLS LSP.
4.1. Requirements of 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:
As for path computation in GMPLS networks as discussed in section 3, (1) Switching capability: PSC1-4, L2SC, DCSC [RFC6002], EVPL
the PCE should consider the GMPLS TE attributes appropriately [RFC6004], 802_1 PBB-TE [RFC6060], TDM, lambda, LSC, FSC
according to tables in [CSPF] 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],[PCEP-EXT],[ PCE-
WSON-REQ] and to RSVP procedures like explicit label
control(ELC),the additional attributes introduced are as follows:
[RFC5440]
(1) Switching capability: PSC1-4, L2SC, DCSC [RFC6002], 802_1 PBB-TE
[RFC6060], TDM, LSC, FSC
(2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g.,
Ethernet, SONET/SDH, Lambda, etc. Ethernet, SONET/SDH, Lambda, etc.
(3) Signal Type: Indicates the type of elementary signal that (3) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with different constitutes the requested LSP. A lot of signal types with different
granularity have been defined in SONET/SDH and G.709 ODUk, such as 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 VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3 in G.709
G.709 ODUk. See[RFC4606] , [RFC4328]and [OSPF-G709] or [RSVP-TE- ODUk. See [RFC4606], [RFC4328] and [OSPF-G709] or [RSVP-TE-G709].
G709].
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two
kinds of concatenation modes are defined: contiguous concatenation kinds of concatenation modes are defined: contiguous concatenation
which requires co-route for each member signal and requires all the which requires co-route for each member signal and requires all the
interfaces along the path to support this capability, and virtual interfaces along the path to support this capability, and virtual
concatenation which allows diverse routes for the member signals and concatenation which allows diverse routes for the member signals and
only requires the ingress and egress interfaces to support this only requires the ingress and egress interfaces to support this
capability. Note that for the virtual concatenation, it also may capability. Note that for the virtual concatenation, it also may
specify co-routed or separated-routed. See [RFC4606] and [RFC4328] specify co-routed or separated-routed. See [RFC4606] and [RFC4328]
about concatenation information. about concatenation information.
(5) Concatenation Number: Indicates the number of signals that are (5) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see requested to be contiguously or virtually concatenated. Also see
[RFC4606] and [RFC4328]. [RFC4606] and [RFC4328].
(6) Technology specific label(s) such as wavelength label as defined (6) Technology-specific label(s) such as defined in [RFC4606],
in [RFC6205], or labels defined in [RFC4606], [RFC6060] or [RFC6002]. [RFC6060], [RFC6002] or [RFC6205].
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc. protection, 1:1 protection, (pre-planned) rerouting, etc.
(8) Administrative group: as defined in [RFC3630]. (8) Administrative group: as defined in [RFC3630]
(9) Link Protection type: as defined in [RFC4203]. (9) Link Protection type: as defined in [RFC4203]
(10)Support for unnumbered interfaces: as defined in [RFC3477]. (10)Support for unnumbered interfaces: as defined in [RFC3477]
(11)Support for asymmetric bandwidth request: as defined in (11)Support for asymmetric bandwidth request: as defined in [RFC6387]
[RFC6387].
(12)Support for explicit label control during the path computation. (12)Support for explicit label control during the path computation.
(13) The PCC/PCE should be able to provide label restrictions (13)Support of label restrictions in the requests/responses,
similar to RSVP on the requests/responses similarly to RSVP-TE ERO and XRO as defined in [RFC3473] and
[RFC4874].
4.2. Requirements of Path Computation Reply 3.2. Requirements on Path Computation Reply
As described above, a PCC must support to initiate a PCReq message As described above, a PCE should compute the path that satisfies the
specifying above mentioned attributes. The PCE should compute the constraints which are specified in the PCReq message. Then the PCE
path that satisfies the constraints which are specified in the PCReq should send a PCRep message including the computation result to the
message. Then the PCE should send a PCRep message including the PCC. For Path Computation Reply message (PCRep) in GMPLS networks,
computation result to the PCC. For Path Computation Reply message there are some additional requirements. The PCEP PCRep message must
(PCRep) in GMPLS networks, there are some additional requirements. be extended to meet the following requirements.
The PCEP PCRep message must be extended to meet the following
requirements.
(1) Concatenation path computation (1) Path computation with concatenation
In the case of concatenation path computation, when a PCE receives In the case of path computation involving concatenation, when a PCE
the PCReq message specifying the concatenation constraints described receives the PCReq message specifying the concatenation constraints
in section 4.1, the PCE should compute the path which satisfies the described in section 3.1, the PCE should compute a path accordingly.
specified concatenation constraints.
For contiguous concatenation path computation, the routes of each For path computation involving contiguous concatenation, a single
member signal must be co-routed and all the interfaces along the route is required and all the interfaces along the route should
route should support contiguous concatenation capability. Therefore, support contiguous concatenation capability. Therefore, the PCE
the PCE should compute a path based on the contiguous concatenation should compute a path based on the contiguous concatenation
capability of each interface and only one ERO which should carry the capability of each interface and only one ERO which should carry the
route information for the response. route information for the response.
For virtual concatenation path computation, only the ingress/egress For path computation involving virtual concatenation, only the
interfaces need to support virtual concatenation capability and ingress/egress interfaces need to support virtual concatenation
maybe there are diverse routes for the different member signals. capability and there may be diverse routes for the different member
Therefore, multiple EROs may be needed for the response. Each ERO signals. Therefore, multiple EROs may be needed for the response.
may represent the route of one or multiple member signals. In the Each ERO may represent the route of one or multiple member signals.
case that one ERO represents several member signals among the total In the case where one ERO represents several member signals among the
member signals, the number of member signals along the route of the total member signals, the number of member signals along the route of
ERO must be specified. the ERO must be specified.
(2) Label constraint
In the case that a PCC doesn't specify the label when requesting a (2) Label constraint
label-resctricted path and the PCE is capable of performing the
route 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 but is In the case that a PCC does not specify the exact label(s) when
only one instance of it. More generally in GMPLS networks label requesting a label-resctricted path and the PCE is capable of
switching and selection constraint may apply and a PCC may request a performing the route computation and label assignment computation
PCE to take label constraint into account and return an ERO procedure, the PCE needs to be able to specify the label of the path
containing the labels or set of label that fulfill the PCC request. in a PCRep message.
The PCReq aspects are covered in section 4.1 in the requirements 6, Wavelength restriction is a typical case of label restriction. More
12 and 13. 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 (3) Roles of the routes
When a PCC specifies the protection type of an LSP, the PCE should When a PCC specifies the protection type of an LSP, the PCE should
compute the working route and the corresponding protection route(s). compute the working route and the corresponding protection route(s).
Therefore, the PCRep should be capable of indicating which one is Therefore, the PCRep should allow to distinguish the working
working or protection route. (nominal) and the protection routes.
4.3. GMPLS PCE Management 3.3. GMPLS PCE Management
PCE related Management Information Bases must consider extensions to PCE-related Management Information Bases must consider extensions to
be satisfied with requirements for GMPLS applications. For be satisfied with requirements for GMPLS applications. For
extensions, [RFC4802] are defined to manage TE database and may be extensions, [RFC4802] are defined to manage TE database and may be
referred to accommodate GMPLS TE attributes in the PCE. referred to so as to accommodate GMPLS TE attributes in the PCE.
5. Security consideration 4. Security Considerations
PCE extensions to support GMPLS should be considered under the same PCEP extensions to support GMPLS should be considered under the same
security as current PCE work. This extension will not change the security as current PCE work. This extension will not change the
underlying security issues. underlying security issues.
6. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgement 6. Acknowledgement
The author would like to express the thanks to Shuichi Okamoto for
their comments.
8. References The author would like to express the thanks to Ramon Casellas, Julien
Meulic and Shuichi Okamoto for their comments.
8.1. Normative References 7. References
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate 7.1. Normative References
requirements levels", RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Resource ReserVation Protocol-Traffic
January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
(MPLS) Signaling - Resource ReserVation Protocol Traffic in Resource ReSerVation Protocol - Traffic Engineering
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] K.Kompella,et al,"Signalling Unnumbered Links in Resource [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
ReSerVation Protocol-Traffic Engineering(RSVP-TE)",January (TE) Extensions to OSPF Version 2", RFC 3630,
2003. September 2003.
[RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
OSPF Version 2", RFC3630, September 2003. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] E. Mannie, et al, "Generalized Multi-Protocol Label [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Switching Architecture", RFC3945, October, 2004. Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
Support of Generalized Multi-Protocol Label Switching", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC4202, Oct. 2005. RFC 4203, October 2005.
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
of Generalized Multi-Protocol Label Switching", RFC4203, Switching (GMPLS) Signaling Extensions for G.709 Optical
Oct. 2005. Transport Networks Control", RFC 4328, January 2006.
[RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Switching (GMPLS) Signaling Extensions for G.709 Optical Protocol Label Switching (GMPLS) Extensions for
Transport Networks Control", RFC4328, January 2006. Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switching (GMPLS) Traffic Engineering Management
Switched Paths (LSPs)", RFC 6387, September 2011. Information Base", RFC 4802, February 2007.
[RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi- [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Protocol Label Switching (GMPLS) Extensions for Extensions in Support of End-to-End Generalized Multi-
Synchronous Optical Network (SONET) and Synchronous Protocol Label Switching (GMPLS) Recovery", RFC 4872,
Digital Hierarchy (SDH) Control", RFC4606, August 2006. May 2007.
[RFC4802] T. Nadeau and A. Farrel, Ed., "Generalized Multiprotocol [RFC4927] Le Roux, J., "Path Computation Element Communication
Label Switching (GMPLS) Traffic Engineering Management Protocol (PCECP) Specific Requirements for Inter-Area MPLS
Information Base", RFC4802, Feb. 2007. and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to- [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
End Generalized Multi-Protocol Label Switching (GMPLS) Requirements for the Path Computation Element
Recovery", RFC4872, May 2007. Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5440] J.P. Vasseur, et al, "Path Computation Element (PCE) [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
Communication Protocol (PCEP)", RFC5440, March 2009. (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC6002] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel [RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
Switching Capable (DCSC) and Channel Set Label Extensions", Channel Switching Capable (DCSC) and Channel Set Label
RFC6002, October 2010. Extensions", RFC 6002, October 2010.
[RFC6060] Don Fedyk, et al., "Generalized Multiprotocol Label [RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
Switching (GMPLS) control of Ethernet PBB-TE", RFC6060, for Metro Ethernet Forum and G.8011 Ethernet Service
March 2011. Switching", RFC 6004, October 2010.
[RFC6205] T. Otani, Ed., "Generalized Labels for G.694 Lambda- [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
Switching Capable Label Switching Routers", RFC6205, March "Generalized Multiprotocol Label Switching (GMPLS) Control
2011 of Ethernet Provider Backbone Traffic Engineering
(PBB-TE)", RFC 6060, March 2011.
[RFC6387] Takacs, et. al., "GMPLS Asymmetric Bandwidth Bidirectional [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda-
Label Switched Paths (LSPs)", RFC6387, September 2011 Switch-Capable (LSC) Label Switching Routers", RFC 6205,
March 2011.
8.2. Informative References [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, September 2011.
[RFC4216] R. Zhan, et al, "MPLS Inter-Autonomous System (AS) Traffic 7.2. Informative References
Engineering (TE) Requirements", RFC4216, November 2005.
[RFC4655] A. Farrel, et al, "A Path Computation Element (PCE)-Based [OSPF-G709]
Architecture", RFC4655, Aug., 2006. 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.
[RFC4657] J. Ash, et al, "Path computation element (PCE) [PCE-WSON-REQ]
communication protocol generic requirements", RFC4657, Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
Sept., 2007. 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.
[RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
traffic engineering", RFC4726, November 2006. (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
[RFC5394] I. Bryskin et al., "Policy-Enabled Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Framework", RFC5394, December 2008. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC6457] T.Takeda,et al,"PCC-PCE Communication and PCE [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Discovery Requirements for Inter-Layer Communication Protocol Generic Requirements", RFC 4657,
Engineering",RFC6457,December 2011. September 2006.
[CSPF] T. Otani, et al, "Considering Generalized Multiprotocol [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Label Switching Traffic Engineering Attributes During Path Inter-Domain Multiprotocol Label Switching Traffic
Computation", draft-otani-ccamp-gmpls-cspf-constraints- Engineering", RFC 4726, November 2006.
07.txt, Feb., 2008.
[PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-ietf- [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
pce-gmpls-PCEP-EXTs, in progress. Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
Wavelength Assignment",draft-ietf-pce-wson-routing- "Policy-Enabled Path Computation Framework", RFC 5394,
wavelength, in progress. December 2008.
[OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to [RFC6457] Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
OSPF for Generalized MPLS(GMPLS) Control of Evolving G.709 Discovery Requirements for Inter-Layer Traffic
OTN Networks", in progress. Engineering", RFC 6457, December 2011.
[RSVP-TE-G709] Fatai Zhang,et al,"Generalized Multi-Protocol Label [RSVP-TE-G709]
Switching(GMPLS) Signaling Extensions for the evolving Zhang, F., "Generalized Multi-Protocol Label Switching
G.709 Optical Transport Network Control", in progress. (GMPLS) Signaling Extensions for the evolving G.709
Optical Transport Networks Control",
draft-ietf-ccamp-gmpls-signaling-g709v3-06 (work in
progress), January 2013.
9. Authors' Addresses Authors' Addresses
Tomohiro Otani Tomohiro Otani
KDDI Corporation KDDI Corporation
2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan 2-3-2 Nishi-shinjuku
Phone: +81-3-3347-6006 Shinjuku-ku, Tokyo
Email: tm-otani@kddi.com Japan
Phone: +81-(3) 3347-6006
Email: tm-otani@kddi.com
Kenichi Ogaki Kenichi Ogaki
KDDI R&D Laboratories, Inc. KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino-shi, Saitama 356-8502 Japan 2-1-15 Ohara
Phone: +81-49-278-7897 Kamifukuoka, Saitama
Email: ogaki@kddilabs.jp Japan
Phone: +81-(49) 278-7897
Email: ogaki@kddilabs.jp
Diego Caviglia Diego Caviglia
Ericsson Ericsson
16153 Genova Cornigliano, ITALY 16153 Genova Cornigliano
Italy
Phone: +390106003736 Phone: +390106003736
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District, Shenzhen 518129
Shenzhen 518129 P.R.China P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Cyril Margaria Cyril Margaria
Nokia Siemens Networks Nokia Siemens Networks Optical GmbH
St Martin Strasse 76 St Martin Strasse 76
Munich, 81541 Munich, 81541
Germany Germany
Phone: +49 89 5159 16934 Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com Email: cyril.margaria@nsn.com
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions
of these Legal Provisions that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect
and shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2010 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.
 End of changes. 112 change blocks. 
366 lines changed or deleted 349 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/