draft-ietf-pce-gmpls-pcep-extensions-04.txt   draft-ietf-pce-gmpls-pcep-extensions-05.txt 
Network Working Group C. Margaria, Ed. Network Working Group C. Margaria, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track O. Gonzalez de Dios, Ed. Intended status: Standards Track O. Gonzalez de Dios, Ed.
Expires: May 2, 2012 Telefonica Investigacion y Expires: September 9, 2012 Telefonica Investigacion y
Desarrollo Desarrollo
F. Zhang, Ed. F. Zhang, Ed.
Huawei Technologies Huawei Technologies
October 30, 2011 March 8, 2012
PCEP extensions for GMPLS PCEP extensions for GMPLS
draft-ietf-pce-gmpls-pcep-extensions-04 draft-ietf-pce-gmpls-pcep-extensions-05
Abstract Abstract
This memo provides extensions for the Path Computation Element This memo provides extensions for the Path Computation Element
communication Protocol (PCEP) for the support of GMPLS control plane. communication Protocol (PCEP) for the support of GMPLS control plane.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2012. This Internet-Draft will expire on September 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3
1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3 1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3
1.3. PCEP existing objects related to GMPLS . . . . . . . . . . 4 1.3. PCEP existing objects related to GMPLS . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 7 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6
2.1. RP object extension . . . . . . . . . . . . . . . . . . . 8 2.1. RP object extension . . . . . . . . . . . . . . . . . . . 7
2.2. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 9 2.2. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 8
2.3. Traffic parameters encoding, GENERALIZED-LOAD-BALANCING . 11 2.3. Traffic parameters encoding, GENERALIZED-LOAD-BALANCING . 10
2.4. END-POINTS Object extensions . . . . . . . . . . . . . . . 14 2.4. END-POINTS Object extensions . . . . . . . . . . . . . . . 13
2.4.1. Generalized Endpoint Object Type . . . . . . . . . . . 15 2.4.1. Generalized Endpoint Object Type . . . . . . . . . . . 14
2.4.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 18 2.4.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 17
2.5. LABEL-SET object . . . . . . . . . . . . . . . . . . . . . 21 2.5. IRO TLV extension . . . . . . . . . . . . . . . . . . . . 20
2.6. SUGGESTED-LABEL-SET object . . . . . . . . . . . . . . . . 22 2.6. XRO TLV extension . . . . . . . . . . . . . . . . . . . . 21
2.7. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 22 2.7. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 22
2.8. NO-PATH Object Extension . . . . . . . . . . . . . . . . . 23 2.8. NO-PATH Object Extension . . . . . . . . . . . . . . . . . 23
2.8.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . . 23 2.8.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . . 23
3. Additional Error Type and Error Values Defined . . . . . . . . 25 3. Additional Error Type and Error Values Defined . . . . . . . . 25
4. Manageability Considerations . . . . . . . . . . . . . . . . . 27 4. Manageability Considerations . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. END-POINTS object, Object Type Generalized Endpoint . . . 29 5.2. END-POINTS object, Object Type Generalized Endpoint . . . 29
5.3. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 30 5.3. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 29
5.4. RP Object Flag Field . . . . . . . . . . . . . . . . . . . 31 5.4. RP Object Flag Field . . . . . . . . . . . . . . . . . . . 30
5.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 31 5.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 31
5.6. New NO-PATH-VECTOR TLV Fields . . . . . . . . . . . . . . 33 5.6. New NO-PATH-VECTOR TLV Fields . . . . . . . . . . . . . . 32
5.7. New Subobject for the Include Route Object . . . . . . . . 32
5.8. New Subobject for the Exclude Route Object . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 35 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . . 39 9.2. Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
skipping to change at page 3, line 26 skipping to change at page 3, line 26
1.1. Contributing Authors 1.1. Contributing Authors
Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier
Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR,
Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon
Casellas (CTTC) Casellas (CTTC)
1.2. PCEP requirements for GMPLS 1.2. PCEP requirements for GMPLS
This section provides a set of PCEP requirements to support GMPLS The document [I-D.ietf-pce-gmpls-aps-req] describe what are the set
LSPs and assure signal compatibility in the path. When requesting a of PCEP PCEP requirements to support GMPLS TE-LSPs. When requesting
path computation (PCReq) to PCE, the PCC should be able to indicate, a path computation (PCReq) to PCE, the PCC should be able to indicate
according to [I-D.ietf-pce-gmpls-aps-req] and to RSVP procedures like the following additional information:
explicit label control (ELC), the following additional attributes:
(1) Switching capability: for instance PSC1-4, L2SC, TDM, 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 [RFC4606], [RFC4328] and other signal types
like the one defined in [I-D.ceccarelli-ccamp-gmpls-ospf-g709] or
[I-D.zhang-ccamp-gmpls-evolving-g709] .
(4) Concatenation Type: In SDH/SONET and G.709 OTN networks, two
kinds of concatenation modes are defined: contiguous concatenation
which requires co-route for each member signal and requires all
the 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. See also
[RFC4606] and [RFC4328].
(6) Technology specific label(s) such as wavelength label as
defined in [RFC6205]
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc.
(8) Link Protection type: as defined in [RFC4203] Which data flow is switched by the LSP: a combination of Switching
capability (for instance L2SC or TDM), Switching Encoding (e.g.,
Ethernet, SONET/SDH) and sometime Signal Type (in case of TDM/LSC
switching capability)
(9) Support for unnumbered interfaces: as defined in [RFC3477] Data flow specific traffic parameter, which can vary a lot, for
instance In SDH/SONET and G.709 OTN networks the Concatenation
Type, Concatenation Number have influence on the switched data and
on which link it can be supported
(10) Support for asymmetric bandwidth requests. Support for asymmetric bandwidth requests.
(11) Ability to indicate the requested granularity for the path Support for unnumbered interfaces: as defined in [RFC3477]
ERO: node, link, label. This is to allow the use of the explicit
label control of RSVP.
(12) In order to support the label control the Path computation Label information and technology specific label(s) such as
response should provide label information matching signaling wavelength label as defined in [RFC6205]. PCC should also be able
capabilities to specify Label restriction similar to the one supported by RSVP.
(13) The PCC should be able to provide label restrictions similar Ability to indicate the requested granularity for the path ERO:
to RSVP on the requests. node, link, label. This is to allow the use of the explicit label
control of RSVP.
We describe in this document a proposal to fulfill those We describe in this document a proposal to fulfill those
requirements. requirements.
1.3. PCEP existing objects related to GMPLS 1.3. PCEP existing objects related to GMPLS
PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext], PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext],
supports the following information (in the PCReq and PCRep) related supports the following information (in the PCReq and PCRep) related
to the described requirements. to the described requirements.
skipping to change at page 5, line 4 skipping to change at page 4, line 23
From [RFC5440]: From [RFC5440]:
o numbered endpoints o numbered endpoints
o bandwidth (encoded as IEEE float) o bandwidth (encoded as IEEE float)
o ERO o ERO
o LSP attributes (setup and holding priorities) o LSP attributes (setup and holding priorities)
o Request attribute (include some LSP attributes) o Request attribute (include some LSP attributes)
From [RFC5521],Extensions to PCEP for Route Exclusions, definition of From [RFC5521],Extensions to PCEP for Route Exclusions, definition of
a XRO object and a new semantic (F bit): a XRO object and a new semantic (F bit):
o This object also allows to exclude (strict or not) resources; XRO o This object also allows to exclude (strict or not) resources; XRO
include the diversity level (node, link, SRLG). The requested includes the diversity level (node, link, SRLG). The requested
diversity is expressed in the XRO diversity is expressed in the XRO
o This Object with the F bit set indicates that the existing route o This Object with the F bit set indicates that the existing route
is failed and resources present in the RRO can be reused. is failed and resources present in the RRO can be reused.
From [I-D.ietf-pce-inter-layer-ext]: From [I-D.ietf-pce-inter-layer-ext]:
o INTER-LAYER : indicates if inter-layer computation is allowed o INTER-LAYER : indicates if inter-layer computation is allowed
o SWITCH-LAYER : indicates which layer(s) should be considered, can o SWITCH-LAYER : indicates which layer(s) should be considered, can
skipping to change at page 5, line 37 skipping to change at page 5, line 9
The shortcomings of the existing PCEP information are: The shortcomings of the existing PCEP information are:
The BANDWIDTH and LOAD-BALANCING objects do not describe the The BANDWIDTH and LOAD-BALANCING objects do not describe the
details of the traffic request (for example NVC, multiplier) in details of the traffic request (for example NVC, multiplier) in
the context of GMPLS networks, for instance TDM or OTN networks. the context of GMPLS networks, for instance TDM or OTN networks.
The END-POINTS object does not allow specifying an unnumbered The END-POINTS object does not allow specifying an unnumbered
interface, nor the labels on the interface. Those parameters are interface, nor the labels on the interface. Those parameters are
of interest in case of switching constraints. of interest in case of switching constraints.
The IRO/XRO objects do not allow to include/exclude labels
Current attributes do not allow to express the requested link level Current attributes do not allow to express the requested link level
protection and end-to-end protection attributes. protection and end-to-end protection attributes.
The covered PCEP extensions are: The covered PCEP extensions are:
New objects are introduced (GENERALIZED-BANDWIDTH and GENERALIZED- New objects are introduced (GENERALIZED-BANDWIDTH and GENERALIZED-
LOAD-BALANCING) for flexible bandwidth encoding, LOAD-BALANCING) for flexible bandwidth encoding,
New Objects are introduced (LABEL-SET and SUGGESTED-LABEL-SET) on
order to allow the PCC to restrict/influence the range of labels
returned
A new object type is introduced for the END-POINTS object A new object type is introduced for the END-POINTS object
(generalized-endpoint), (generalized-endpoint),
A new TLV is added to the LSPA object. A new TLV is added to the LSPA object.
A new TLV type is allowed in IRO
In order to indicate the mandatory routing granularity in the In order to indicate the mandatory routing granularity in the
response, a new flag in the RP object is added. response, a new flag in the RP object is added.
1.4. Requirements Language 1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC 2119.
2. PCEP objects and extensions 2. PCEP objects and extensions
This section describes the required PCEP objects and extensions. The This section describes the required PCEP objects and extensions. The
PCReq and PCRep messages are defined in [RFC5440]. The format of the PCReq and PCRep messages are defined in [RFC5440]. The format of the
request and response messages with the proposed extensions request and response messages with the proposed extensions
(GENERALIZED-BANDWIDTH, GENERALIZED-LOAD-BALANCING, SUGGESTED-LABEL- (GENERALIZED-BANDWIDTH, GENERALIZED-LOAD-BALANCING, SUGGESTED-LABEL-
SET and LABEL-SET) is as follows: SET and LABEL-SET) is as follows:
<request>::= <RP> <request>::= <RP>
skipping to change at page 7, line 25 skipping to change at page 6, line 25
<segment-computation> ::= <segment-computation> ::=
<END-POINTS> <END-POINTS>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>...] [<GENERALIZED-BANDWIDTH>...]
[<metric-list>] [<metric-list>]
[<OF>] [<OF>]
[<RRO> [<BANDWIDTH>] [<GENERALIZED-BANDWIDTH>...]] [<RRO> [<BANDWIDTH>] [<GENERALIZED-BANDWIDTH>...]]
[<IRO>] [<IRO>]
[<SUGGESTED-LABEL-SET>]
[<LABEL-SET>...]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
[<GENERALIZED-LOAD-BALANCING>...] [<GENERALIZED-LOAD-BALANCING>...]
[<XRO>] [<XRO>]
<path-key-expansion> ::= <PATH-KEY> <path-key-expansion> ::= <PATH-KEY>
<response>::=<RP> <response>::=<RP>
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
[<path-list>] [<path-list>]
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list> <path>::= <ERO><attribute-list>
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
Where: Where:
<attribute-list>::=[<LSPA>] <attribute-list>::=[<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<LABEL-SET>...]
[<SUGGESTED-LABEL-SET>...]
[<GENERALIZED-BANDWIDTH>...] [<GENERALIZED-BANDWIDTH>...]
[<GENERALIZED-LOAD-BALANCING>...] [<GENERALIZED-LOAD-BALANCING>...]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
For point-to-multipoint(P2MP) computations, the proposed grammar is: For point-to-multipoint(P2MP) computations, the proposed grammar is:
<segment-computation> ::= <segment-computation> ::=
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>...] [<GENERALIZED-BANDWIDTH>...]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
[<SUGGESTED-LABEL-SET>]
[<LABEL-SET>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
[<GENERALIZED-LOAD-BALANCING>...] [<GENERALIZED-LOAD-BALANCING>...]
[<XRO>] [<XRO>]
<end-point-rro-pair-list>::= <end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>] <END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>...] [<GENERALIZED-BANDWIDTH>...]
[<end-point-rro-pair-list>] [<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>] <RRO-List>::=<RRO>[<BANDWIDTH>]
skipping to change at page 9, line 19 skipping to change at page 8, line 19
3 : reserved 3 : reserved
When the RP object appears in a request within a PCReq message the When the RP object appears in a request within a PCReq message the
flag indicates the requested route granularity. The PCE MAY try to flag indicates the requested route granularity. The PCE MAY try to
follow this granularity and MAY return a NO-PATH if the requested follow this granularity and MAY return a NO-PATH if the requested
granularity cannot be provided. The PCE MAY return more details on granularity cannot be provided. The PCE MAY return more details on
the route based on its policy. The PCC can decide if the ERO is the route based on its policy. The PCC can decide if the ERO is
acceptable based on its content. acceptable based on its content.
If a PCE did use the requested routing granularity in a PCReq is MUST If a PCE did use the requested routing granularity in a PCReq it MUST
indicate the routing granularity in the PCRep. The RG flag is indicate the routing granularity in the PCRep. The RG flag is
backward-compatible with previous RFCs: the value sent by an backward-compatible with previous RFCs: the value sent by an
implementation not supporting it will indicate a node granularity. implementation not supporting it will indicate a node granularity.
This flag is optional for responses. A new capability flag in the This flag is optional for responses. A new capability flag in the
PCE-CAP-FLAGS from [RFC5088] and [RFC5089] may be added. PCE-CAP-FLAGS from [RFC5088] and [RFC5089] may be added.
2.2. Traffic parameters encoding, GENERALIZED-BANDWIDTH 2.2. Traffic parameters encoding, GENERALIZED-BANDWIDTH
The PCEP BANDWIDTH does not describe the details of the signal (for The PCEP BANDWIDTH does not describe the details of the signal (for
example NVC, multiplier), hence the bandwidth information should be example NVC, multiplier), hence the bandwidth information should be
skipping to change at page 11, line 13 skipping to change at page 10, line 13
can be found in the following references. can be found in the following references.
Object Type Name Reference Object Type Name Reference
0 Reserved 0 Reserved
1 Reserved 1 Reserved
2 Intserv [RFC2210] 2 Intserv [RFC2210]
3 Reserved 3 Re served
4 SONET/SDH [RFC4606] 4 SONET/SDH [RFC4606]
5 G.709 [RFC4328] 5 G.709 [RFC4328]
6 Ethernet [RFC6003] 6 Ethernet [RFC6003]
Traffic Spec field encoding Traffic Spec field encoding
The GENERALIZED-BANDWIDTH MAY appear more than once in a PCReq The GENERALIZED-BANDWIDTH MAY appear more than once in a PCReq
message. If more than one GENERALIZED-BANDWIDTH have the same Object message. If more than one GENERALIZED-BANDWIDTH have the same Object
Type, Reserved, R and O values, only the first one is processed, the Type, Reserved, R and O values, only the first one is processed, the
others are ignored. others are ignored.
a PCE MAY ignore GENERALIZED-BANDWIDTH objects, a PCC that requires a A PCE MAY ignore GENERALIZED-BANDWIDTH objects, a PCC that requires a
GENERALIZED-BANDWIDTH to be used can set the P (Processing) bit in GENERALIZED-BANDWIDTH to be used can set the P (Processing) bit in
the object header. the object header.
When a PCC needs to get a bi-directional path with asymmetric When a PCC needs to get a bi-directional path with asymmetric
bandwidth, it SHOULD specify the different bandwidth in forward and bandwidth, it SHOULD specify the different bandwidth in forward and
reverse directions through two separate GENERALIZED-BANDWIDTH reverse directions through two separate GENERALIZED-BANDWIDTH
objects. If the PCC set the P bit on both object the PCE MUST objects. If the PCC set the P bit on both object the PCE MUST
compute a path that satisfies the asymmetric bandwidth constraint and compute a path that satisfies the asymmetric bandwidth constraint and
return the path to PCC if the path computation is successful. If the return the path to PCC if the path computation is successful. If the
P bit on the reverse GENERALIZED-BANDWIDTH object the PCE MAY ignore P bit on the reverse GENERALIZED-BANDWIDTH object the PCE MAY ignore
this constraint. this constraint.
a PCE MAY include the GENERALIZED-BANDWIDTH objects in the response A PCE MAY include the GENERALIZED-BANDWIDTH objects in the response
to indicate the GENERALIZED-BANDWIDTH of the path to indicate the GENERALIZED-BANDWIDTH of the path
Optional TLVs may be included within the object body to specify more Optional TLVs may be included within the object body to specify more
specific bandwidth requirements. The specification of such TLVs is specific bandwidth requirements. The specification of such TLVs is
outside the scope of this document. outside the scope of this document.
2.3. Traffic parameters encoding, GENERALIZED-LOAD-BALANCING 2.3. Traffic parameters encoding, GENERALIZED-LOAD-BALANCING
The LOAD-BALANCING object is used to request a set of maximum Max-LSP The LOAD-BALANCING object is used to request a set of maximum Max-LSP
TE-LSP having in total the bandwidth specified in BANDWIDTH, each TE- TE-LSP having in total the bandwidth specified in BANDWIDTH, each TE-
skipping to change at page 15, line 38 skipping to change at page 14, line 38
different (supporting a different Tspec). Hence the label different (supporting a different Tspec). Hence the label
restrictions include a Generalized label request in order to restrictions include a Generalized label request in order to
interpret the labels. This correspond to requirement 6 and 9 of interpret the labels. This correspond to requirement 6 and 9 of
[I-D.ietf-pce-gmpls-aps-req]. [I-D.ietf-pce-gmpls-aps-req].
The proposed object format consists of a body and a list of TLVs, The proposed object format consists of a body and a list of TLVs,
which give the details of the endpoints and are described in which give the details of the endpoints and are described in
Section 2.4.2. For each endpoint type, a different grammar is Section 2.4.2. For each endpoint type, a different grammar is
defined. The TLVs defined to describe an endpoint are: defined. The TLVs defined to describe an endpoint are:
1. IPv4 address. 1. IPv4 address.
2. IPv6 address. 2. IPv6 address.
3. Unnumbered endpoint. 3. Unnumbered endpoint.
4. Label request. 4. Label request.
5. Label. 5. Label.
6. Upstream label. 6. Upstream label.
7. Label set. 7. Old Label.
8. Suggested label set. 8. Old Upstream label.
9. Label set.
10. Suggested label set.
The labels TLV are used to restrict the label allocation in the PCE. The labels TLV are used to restrict the label allocation in the PCE.
They follow the set of restrictions provided by signaling with They follow the set of restrictions provided by signaling with
explicit value (label and upstream label), mandatory range explicit value (label and upstream label), mandatory range
restrictions (Label set) and optional range restriction (suggested restrictions (Label set) and optional range restriction (suggested
label set). Single suggested value is using the suggested label set. label set). Single suggested value is using the suggested label set.
The label range restriction are valid in GMPLS networks, either by The Old Label and Old Upstream Labels are used to represent existing
PCC policy or depending on the switching technology used, for label(s) when requesting a re-optimization. The Old Label and Old
instance on given Ethernet or ODU equipment having limited hardware upstream Label MAY be present only when the Reoptimization flag (R)
capabilities restricting the label range. Label set restriction also of the RP object is set. The label range restrictions are valid in
applies to WSON networks where the optical sender and receivers are GMPLS networks, either by PCC policy or depending on the switching
limited in their frequency tunability ranges, restricting then in technology used, for instance on given Ethernet or ODU equipment
GMPLS the possible label ranges on the interface. The END-POINTS having limited hardware capabilities restricting the label range.
Object with Generalized Endpoint object type is encoded as follow: Label set restriction also applies to WSON networks where the optical
sender and receivers are limited in their frequency tunability
ranges, restricting then in GMPLS the possible label ranges on the
interface. The END-POINTS Object with Generalized Endpoint object
type is encoded as follow:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | endpoint type | | Reserved | endpoint type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 10 skipping to change at page 17, line 10
<endpoint> [<endpoint-restriction-list>] <endpoint> [<endpoint-restriction-list>]
[<endpoint> [<endpoint-restriction-list>]]... [<endpoint> [<endpoint-restriction-list>]]...
For endpoint type Point-to-Multipoint several endpoint objects may be For endpoint type Point-to-Multipoint several endpoint objects may be
present in the message and represent a leave, exact meaning depend on present in the message and represent a leave, exact meaning depend on
the endpoint type defined of the object. the endpoint type defined of the object.
An endpoint is defined as follows: An endpoint is defined as follows:
<endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT> <endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT>
<endpoint-restriction-list> ::= <endpoint-restriction-list> ::= <endpoint-restriction>
<endpoint-restriction>
[<endpoint-restriction-list>] [<endpoint-restriction-list>]
<endpoint-restriction> ::= <endpoint-restriction> ::=
<LABEL-REQUEST><label-restriction-list> <LABEL-REQUEST><label-restriction-list>
<label-restriction-list> ::= <label-restriction> <label-restriction-list> ::= <label-restriction>
[<label-restriction-list>] [<label-restriction-list>]
<label-restriction> ::= <LABEL>|<UPSTREAM-LABEL>| <label-restriction> ::= <LABEL>|<UPSTREAM-LABEL>|
<OLD-LABEL>|<OLD-UPSTREAM-LABEL>|
<LABEL-SET>| <LABEL-SET>|
<SUGGESTED-LABEL-SET> <SUGGESTED-LABEL-SET>
The different TLVs are described in the following sections. A PCE The different TLVs are described in the following sections. A PCE
MAY support IPV4-ADDRESS,IPV6-ADDRESS or UNNUMBERED-ENDPOINT TLV. A MAY support IPV4-ADDRESS,IPV6-ADDRESS or UNNUMBERED-ENDPOINT TLV. A
PCE not supporting one of those TLV in a PCReq MUST respond with a PCE not supporting one of those TLV in a PCReq MUST respond with a
PCRep with NO-PATH with the bit "Unknown destination" or "Unknown PCRep with NO-PATH with the bit "Unknown destination" or "Unknown
source" in the NO-PATH-VECTOR TLV, the PCRep MUST include the source" in the NO-PATH-VECTOR TLV, the PCRep MUST include the
ENDPOINT object in the response with only the TLV it did not ENDPOINT object in the response with only the TLV it did not
understood. understood.
A PCE MAY support LABEL-REQUEST, LABEL, UPSTREAM-LABEL, LABEL-SET or A PCE MAY support LABEL-REQUEST, LABEL, UPSTREAM-LABEL, OLD-LABEL,
SUGGESTED-LABEL-SET TLV. For non supported TLV in the END-POINTS a OLD-UPSTREAM-LABEL, LABEL-SET or SUGGESTED-LABEL-SET TLV. If the TLV
PCE MUST respond with a PCErr message with error type="Path OLD-LABEL or OLD-UPSTREAM-LABEL are present the R bit of the RP
object MUST be set or a PCErr message with error type="Reception of
an invalid object" error value="OLD-LABEL or OLD-UPSTREAM-LABEL TLV
present without R bit set in RP" For non supported TLV in the END-
POINTS a PCE MUST respond with a PCErr message with error type="Path
computation failure" error value="Unsupported TLV present in END- computation failure" error value="Unsupported TLV present in END-
POINTS Generalized Endpoint object type" and the message MUST include POINTS Generalized Endpoint object type" and the message MUST include
the ENDPOINT object in the response with only the endpoint and the ENDPOINT object in the response with only the endpoint and
endpoint restriction TLV it did not understood. A PCE not supporting endpoint restriction TLV it did not understood. A PCE not supporting
being able to fulfill the label restriction MUST respond with a PCRep being able to fulfill the label restriction MUST respond with a PCRep
with NO-PATH with the bit "No endpoint label resource" or "No with NO-PATH with the bit "No endpoint label resource" or "No
endpoint label resource in range" in the NO-PATH-VECTOR TLV, the endpoint label resource in range" in the NO-PATH-VECTOR TLV, the
PCRep MUST include the ENDPOINT object in the response with only the PCRep MUST include the ENDPOINT object in the response with only the
TLV where it could not met the the constraint. TLV where it could not met the constraint.
2.4.2. END-POINTS TLVs extensions 2.4.2. END-POINTS TLVs extensions
All endpoint TLVs have the standard PCEP TLV header as defined in All endpoint TLVs have the standard PCEP TLV header as defined in
[RFC5440] section 7.1 [RFC5440] section 7.1
2.4.2.1. IPV4-ADDRESS 2.4.2.1. IPV4-ADDRESS
This TLV represent a numbered endpoint using IPv4 numbering, the This TLV represent a numbered endpoint using IPv4 numbering, the
format of the IPv4-ADDRESS TLV value (TLV-Type=TBA) is as follows: format of the IPv4-ADDRESS TLV value (TLV-Type=TBA) is as follows:
skipping to change at page 20, line 42 skipping to change at page 19, line 42
Section 2.4.1. TLVs are encoded as follow (following [RFC5440]) : Section 2.4.1. TLVs are encoded as follow (following [RFC5440]) :
o LABEL TLV, Type=TBA. The TLV Length is variable, the value is the o LABEL TLV, Type=TBA. The TLV Length is variable, the value is the
same as [RFC3471] Section 3.2 Generalized label. This represent same as [RFC3471] Section 3.2 Generalized label. This represent
the downstream label the downstream label
o UPSTREAM-LABEL TLV, Type=TBA, The TLV Length is variable, the o UPSTREAM-LABEL TLV, Type=TBA, The TLV Length is variable, the
value is the same as [RFC3471] Section 3.2 Generalized label. value is the same as [RFC3471] Section 3.2 Generalized label.
This represent the upstream label This represent the upstream label
o OLD-LABEL TLV, Type=TBA. The TLV Length is variable, the value is
the same as [RFC3471] Section 3.2 Generalized label. This
represent the old downstream label in case of re-optimization.
This Label MAY be reused. The R bit of the RP object MUST be set
o OLD-UPSTREAM-LABEL TLV, Type=TBA, The TLV Length is variable, the
value is the same as [RFC3471] Section 3.2 Generalized label.
This represent the old upstream label in case of re-optimization.
This Label MAY be reused. The R bit of the RP object MUST be set
o LABEL-SET TLV, Type=TBA. The TLV Length is variable, Encoding o LABEL-SET TLV, Type=TBA. The TLV Length is variable, Encoding
follow [RFC3471] Section 3.5 "Label set" with the addition of a U follow [RFC3471] Section 3.5 "Label set" with the addition of a U
bit : the U bit is set for upstream direction in case of bit : the U bit is set for upstream direction in case of
bidirectional LSP. bidirectional LSP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |U| Label Type | | Action | Reserved |U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 40 skipping to change at page 20, line 45
by [RFC3471] section 3.5.1 A SUGGESTED-LABEL-SET TLV has the same by [RFC3471] section 3.5.1 A SUGGESTED-LABEL-SET TLV has the same
encoding as the LABEL-SET TLV, it indicates to the PCE a set of encoding as the LABEL-SET TLV, it indicates to the PCE a set of
preferred (ordered) set of labels to be used. the PCE MAY use those preferred (ordered) set of labels to be used. the PCE MAY use those
labels for label allocation. labels for label allocation.
The U bit has the following meaning: The U bit has the following meaning:
U: Upstream direction: set when the label or label set is in the U: Upstream direction: set when the label or label set is in the
reverse direction reverse direction
2.5. LABEL-SET object 2.5. IRO TLV extension
The LABEL-SET object is carried in a request within a PCReq message The IRO as defined in [RFC5440] is used to include specific objects
to restrict the set of labels to be assigned during the path in the path. RSVP allows to include label definition, in order to
computation. This is introduced to satisfy requirement 13. fulfill requirement 13 the IRO should support the new TLV Type as
defined in [RFC3473]:
When the P bit is set and the object accepted any label allocated by Type Sub-object
the PCE (and included in the ERO object on the response) MUST be in
the range stated in the LABEL-SET. When no path satisfy this
constraint a PCRep with a NO-PATH should be responded wit a NO-PATH-
VECTOR TLV with the bit "No label resource in range" set and the
LABEL-SET object MAY be included to indicate the set of constraint
that could not be satisfied.
When the P bit is not set a PCE MAY consider constraint, the PCC can 3 LABEL
verify that the constraint was applied by checking the ERO returned
The LABEL-SET Object encoding is defined as following The L bit of such sub-object has no meaning within an IRO.
0 1 2 3 The Label subobject MUST follow a subobject identifying a link ,
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 currently an IP address subobject (Type 1 or 2) or an interface id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (type 4) subobject. The procedure associated with this subobject is
| | as follow
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where TLVs follow the following grammar If the PCE allocate labels the PCE MUST allocate one label of within
the set of label values for the given link. If the PCE does not
assign labels an error
<label-set-tlvs> ::= <LABEL-REQUEST><LABEL-SET>[<LABEL-SET>] 2.6. XRO TLV extension
The LABEL-REQUEST and LABEL-SET TLVs are as defined in The XRO as defined in [RFC5521] is used to exclude specific objects
Section 2.4.2.5, See also [RFC3471] and [RFC3473] for the definitions in the path. RSVP allows to exclude labels ([RFC6001], in order to
of the fields. fulfill requirement 13 the XRO should support a new TLV for the label
exclusion.
It is allowed to have more than one LABEL-SET object per request The encoding of the XRO Label subobject is identical follow the
within a PCReq message (for example in case of multiple SWITCH-LAYER encoding of the Label ERO subobject defined in [RFC3473] and XRO TLVs
present). defined in [RFC5521]. The XRO Label subobject is defined as follows:
2.6. SUGGESTED-LABEL-SET object XRO Subobject Type 3: Label Subobject.
Similar to the endpoint restriction SUGGESTED-LABEL-SET TLV, but with 0 1 2 3
end-to-end scope the SUGGESTED-LABEL-SET object indicate an optional 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
set of label that the PCE MAY use when selecting the labels. The +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SUGGESTED-LABEL-SET object is carried within a PCReq or PCRep message |X| Type=3 | Length |U| Reserved | C-Type |
to indicate the preferred set of label to be assigned during the path +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
computation. The encoding is the same as the LABEL-SET object. It | Label |
is allowed to have more than one SUGGESTED LABEL-SET object per PCReq | ... |
(for example in case of multiple SWITCH-LAYER present). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object is introduced similarly to the LABEl-SET to satisfy the X (1 bit)
requirement 6 and 13, more specifically the ability to indicate
optional preference for the label selection support by RSVP using the See [RFC5521].
SUGGESTED_LABEL.
Type (7 bits)
The Type of the XRO Label subobject is 3.
Length (8 bits)
See [RFC5521],The total length of the subobject in bytes
(including the Type and Length fields). The Length is always
divisible by 4.
U (1 bit)
See [RFC3471].
C-Type (8 bits)
The C-Type of the included Label Object. Copied from the Label
Object (see [RFC3471]).
Label
See [RFC3471].
XRO Label subobjects MUST follow the numbered or unnumbered interface
subobjects to which they refer. Several XRO Labels subobject MAY be
present.
Type Sub-object
3 LABEL
The L bit of such sub-object has no meaning within an XRO.
2.7. LSPA extensions 2.7. LSPA extensions
The LSPA carries the LSP attributes. In the end-to-end protection The LSPA carries the LSP attributes. In the end-to-end protection
context this also includes the protection state information. This context this also includes the protection state information. This
object is introduced to fulfill requirement 7 and is used as a policy object is introduced to fulfill requirement 7 and is used as a policy
input for route and label selection. The LSPA object can be extended input for route and label selection. The LSPA object can be extended
by a protection TLV type: Type TBA: PROTECTION-ATTRIBUTE by a protection TLV type: Type TBA: PROTECTION-ATTRIBUTE
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved | |I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 20 skipping to change at page 25, line 5
granularity. granularity.
Bit number TBA - No endpoint label resource (1-bit). Specifies Bit number TBA - No endpoint label resource (1-bit). Specifies
that the PCE is not able to provide a route because of the that the PCE is not able to provide a route because of the
endpoint label restriction. endpoint label restriction.
Bit number TBA - No endpoint label resource in range (1-bit). Bit number TBA - No endpoint label resource in range (1-bit).
Specifies that the PCE is not able to provide a route because of Specifies that the PCE is not able to provide a route because of
the endpoint label set restriction. the endpoint label set restriction.
Bit number TBA - No label resource in range (1-bit). Specifies
that the PCE is not able to provide a route because of the label
set restriction.
3. Additional Error Type and Error Values Defined 3. Additional Error Type and Error Values Defined
A PCEP-ERROR object is used to report a PCEP error and is A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies the type of error while characterized by an Error-Type that specifies the type of error while
Error-value that provides additional information about the error Error-value that provides additional information about the error
type. An additional error type and few error values are defined to type. An additional error type and few error values are defined to
represent some of the errors related to the newly identified objects represent some of the errors related to the newly identified objects
related to SDH networks. For each PCEP error, an Error-Type and an related to SDH networks. For each PCEP error, an Error-Type and an
Error-value are defined. Error-Type 1 to 10 are already defined in Error-value are defined. Error-Type 1 to 10 are already defined in
[RFC5440]. Additional Error- values are defined for Error-Type 10 [RFC5440]. Additional Error- values are defined for Error-Type 10
skipping to change at page 25, line 39 skipping to change at page 25, line 39
Error-value=TBA: Unsupported Secondary LSP Protection Error-value=TBA: Unsupported Secondary LSP Protection
Flags in PROTECTION-ATTRIBUTE TLV. Flags in PROTECTION-ATTRIBUTE TLV.
Error-value=TBA: Unsupported Link Protection Type in Error-value=TBA: Unsupported Link Protection Type in
PROTECTION-ATTRIBUTE TLV. PROTECTION-ATTRIBUTE TLV.
Error-value=TBA: Unsupported Link Protection Type in Error-value=TBA: Unsupported Link Protection Type in
PROTECTION-ATTRIBUTE TLV. PROTECTION-ATTRIBUTE TLV.
Error-value=TBA: OLD-LABEL or OLD-UPSTREAM-LABEL TLV
present without R bit set in RP.
TBA Path computation TBA Path computation
failure failure
Error-value=TBA: Unacceptable request message. Error-value=TBA: Unacceptable request message.
Error-value=TBA: Generalized bandwidth object not Error-value=TBA: Generalized bandwidth object not
supported. supported.
Error-value=TBA: Label Set constraint could not be met. Error-value=TBA: Label Set constraint could not be met.
skipping to change at page 28, line 34 skipping to change at page 28, line 34
Reference This document (section Section 2.2) Reference This document (section Section 2.2)
Object Class to be assigned Object Class to be assigned
Name GENERALIZED-LOAD-BALANCING Name GENERALIZED-LOAD-BALANCING
Object-Type 0 to 6 Object-Type 0 to 6
Reference This document (section Section 2.3) Reference This document (section Section 2.3)
Object Class to be assigned
Name LABEL-SET
Object-Type 0
Reference This document (section Section 2.5)
Object Class to be assigned
Name SUGGESTED-LABEL-SET
Object-Type 0
Reference This document (section Section 2.6)
As described in Section 2.4.1 a new Object type is defined IANA is As described in Section 2.4.1 a new Object type is defined IANA is
requested to make the following Object-Type allocations from the requested to make the following Object-Type allocations from the
"PCEP Objects" sub-registry. The values here are suggested for use "PCEP Objects" sub-registry. The values here are suggested for use
by IANA. by IANA.
Object Class 4 Object Class 4
Name END-POINTS Name END-POINTS
Object-Type 5 : Generalized Endpoint Object-Type 5 : Generalized Endpoint
skipping to change at page 30, line 33 skipping to change at page 30, line 7
5.3. New PCEP TLVs 5.3. New PCEP TLVs
IANA manages the PCEP TLV code point registry (see [RFC5440]). This IANA manages the PCEP TLV code point registry (see [RFC5440]). This
is maintained as the "PCEP TLV Type Indicators" sub-registry of the is maintained as the "PCEP TLV Type Indicators" sub-registry of the
"Path Computation Element Protocol (PCEP) Numbers" registry. This "Path Computation Element Protocol (PCEP) Numbers" registry. This
document defines new PCEP TLVs, to be carried in the END-POINTS document defines new PCEP TLVs, to be carried in the END-POINTS
object with Generalized Endpoint object Type. IANA is requested to object with Generalized Endpoint object Type. IANA is requested to
do the following allocation. The values here are suggested for use do the following allocation. The values here are suggested for use
by IANA. by IANA.
Value Meaning Reference Value Meaning Reference
7 IPv4 endpoint This document (section 7 IPv4 endpoint This document (section
Section 2.4.2.1) Section 2.4.2.1)
8 IPv6 endpoint This document (section 8 IPv6 endpoint This document (section
Section 2.4.2.2) Section 2.4.2.2)
9 Unnumbered endpoint This document (section 9 Unnumbered endpoint This document (section
Section 2.4.2.3) Section 2.4.2.3)
10 Label request This document (section 10 Label request This document (section
Section 2.4.2.4) Section 2.4.2.4)
11 Requested GMPLS Label This document (section 11 Requested GMPLS Label This document (section
Section 2.4.2.5) Section 2.4.2.5)
12 Requested GMPLS Upstream This document (section 12 Requested GMPLS Upstream This document (section
Label Section 2.4.2.5) Label Section 2.4.2.5)
13 Requested GMPLS Label Set This document (section 13 Requested GMPLS Label Set This document (section
Section 2.4.2.5) Section 2.4.2.5)
14 Suggested GMPLS Label Set This document (section 14 Suggested GMPLS Label Set This document (section
Section 2.4.2.5) Section 2.4.2.5)
15 LSP Protection Information This document (section Section 2.7) 15 Old Requested GMPLS Label This document (section
Section 2.4.2.5)
16 Old Requested GMPLS Upstream This document (section
Label Section 2.4.2.5)
15 LSP Protection Information This document (section
Section 2.7)
5.4. RP Object Flag Field 5.4. RP Object Flag Field
As described in Section 2.1 new flag are defined in the RP Object As described in Section 2.1 new flag are defined in the RP Object
Flag IANA is requested to make the following Object-Type allocations Flag IANA is requested to make the following Object-Type allocations
from the "RP Object Flag Field" sub-registry. The values here are from the "RP Object Flag Field" sub-registry. The values here are
suggested for use by IANA. suggested for use by IANA.
Bit Description Reference Bit Description Reference
skipping to change at page 32, line 27 skipping to change at page 31, line 38
Value=5: Unsupported Secondary LSP Protection Flags in This Value=5: Unsupported Secondary LSP Protection Flags in This
PROTECTION-ATTRIBUTE TLV. Document PROTECTION-ATTRIBUTE TLV. Document
Value=6: Unsupported Link Protection Type in This Value=6: Unsupported Link Protection Type in This
PROTECTION-ATTRIBUTE TLV. Document PROTECTION-ATTRIBUTE TLV. Document
Value=7: Unsupported Link Protection Type in This Value=7: Unsupported Link Protection Type in This
PROTECTION-ATTRIBUTE TLV. Document PROTECTION-ATTRIBUTE TLV. Document
Value=8: OLD-LABEL or OLD-UPSTREAM-LABEL TLV present This
without R bit set in RP. Document
Type=14 Path computation failure This Type=14 Path computation failure This
Document Document
Value=1: Unacceptable request message. This Value=1: Unacceptable request message. This
Document Document
Value=2: Generalized bandwidth object not supported. This Value=2: Generalized bandwidth object not supported. This
Document Document
Value=3: Label Set constraint could not be met. This Value=3: Label Set constraint could not be met. This
skipping to change at page 33, line 31 skipping to change at page 32, line 43
granularity. granularity.
Bit number 20 - No endpoint label resource (1-bit). Specifies Bit number 20 - No endpoint label resource (1-bit). Specifies
that the PCE is not able to provide a route because of the that the PCE is not able to provide a route because of the
endpoint label restriction. endpoint label restriction.
Bit number 19 - No endpoint label resource in range (1-bit). Bit number 19 - No endpoint label resource in range (1-bit).
Specifies that the PCE is not able to provide a route because of Specifies that the PCE is not able to provide a route because of
the endpoint label set restriction. the endpoint label set restriction.
Bit number 18 - No label resource in range (1-bit). Specifies 5.7. New Subobject for the Include Route Object
that the PCE is not able to provide a route because of the label
set restriction.
Bit number 17 - Not supported endpoint restriction (1-bit). The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
Specifies that the PCE is not able to provide a route because of a with an entry for the Include Route Object (IRO).
not supported endpoint restriction.
IANA is requested to add a further subobject that can be carried in
the IRO as follows:
Subobject type Reference
3 Label suboject [RFC3473]
5.8. New Subobject for the Exclude Route Object
The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
with an entry for the XRO object (Exclude Route Object).
IANA is requested to add a further subobject that can be carried in
the XRO as follows:
Subobject type Reference
3 Label suboject [RFC3473]
6. Security Considerations 6. Security Considerations
None. None.
7. Contributing Authors 7. Contributing Authors
Nokia Siemens Networks: Nokia Siemens Networks:
Elie Sfeir Elie Sfeir
skipping to change at page 37, line 10 skipping to change at page 37, line 10
08860 Castelldefels (Barcelona) 08860 Castelldefels (Barcelona)
Spain Spain
Phone: (34) 936452916 Phone: (34) 936452916
Email: ramon.casellas@cttc.es Email: ramon.casellas@cttc.es
8. Acknowledgments 8. Acknowledgments
The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar
Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these
results has received funding from the European Community's Seventh results has received funding from the European Community's Seventh
Framework Programme FP7/2007-2013 under grant agreement no 247674. Framework Program FP7/2007-2013 under grant agreement no 247674.
The authors would like to thank Lyndon Ong for his useful comments to
the document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
skipping to change at page 39, line 27 skipping to change at page 39, line 27
Using a Path-Key-Based Mechanism", RFC 5520, April 2009. Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009. Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009. Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks (MLN/
MRN)", RFC 6001, October 2010.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, October 2010. RFC 6003, October 2010.
[RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda-
Switch-Capable (LSC) Label Switching Routers", RFC 6205, Switch-Capable (LSC) Label Switching Routers", RFC 6205,
March 2011. 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.
9.2. Informative References 9.2. Informative References
[I-D.ceccarelli-ccamp-gmpls-ospf-g709] [I-D.ceccarelli-ccamp-gmpls-ospf-g709]
Ceccarelli, D., Caviglia, D., Zhang, F., Li, D., Belotti, Ceccarelli, D., Caviglia, D., Zhang, F., Li, D., Belotti,
S., Grandi, P., Rao, R., Pithewan, K., and J. Drake, S., Grandi, P., Rao, R., Pithewan, K., and J. Drake,
"Traffic Engineering Extensions to OSPF for Generalized "Traffic Engineering Extensions to OSPF for Generalized
MPLS (GMPLS) Control of Evolving G.709 OTN Networks", MPLS (GMPLS) Control of Evolving G.709 OTN Networks",
draft-ceccarelli-ccamp-gmpls-ospf-g709-07 (work in draft-ceccarelli-ccamp-gmpls-ospf-g709-07 (work in
progress), September 2011. progress), September 2011.
[I-D.ietf-pce-gmpls-aps-req] [I-D.ietf-pce-gmpls-aps-req]
Otani, T., Ogaki, K., Caviglia, D., and F. Zhang, Caviglia, D., Zhang, F., Ogaki, K., and T. Otani,
"Requirements for GMPLS applications of PCE", "Document:", draft-ietf-pce-gmpls-aps-req-05 (work in
draft-ietf-pce-gmpls-aps-req-04 (work in progress), progress), January 2012.
June 2011.
[I-D.ietf-pce-inter-layer-ext] [I-D.ietf-pce-inter-layer-ext]
Oki, E., Takeda, T., Roux, J., Farrel, A., and F. Zhang, Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions
"Extensions to the Path Computation Element communication to the Path Computation Element communication Protocol
Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic (PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-ext-05 (work in Engineering", draft-ietf-pce-inter-layer-ext-06 (work in
progress), June 2011. progress), January 2012.
[I-D.ietf-pce-wson-routing-wavelength] [I-D.ietf-pce-wson-routing-wavelength]
Lee, Y., Bernstein, G., Martensson, J., Takeda, T., Bernstein, G., Martensson, J., Dios, O., Tsuritani, T.,
Tsuritani, T., and O. Dios, "PCEP Requirements for WSON Takeda, T., and Y. Lee, "PCEP Requirements for WSON
Routing and Wavelength Assignment", Routing and Wavelength Assignment",
draft-ietf-pce-wson-routing-wavelength-06 (work in draft-ietf-pce-wson-routing-wavelength-06 (work in
progress), October 2011. progress), October 2011.
[I-D.zhang-ccamp-gmpls-evolving-g709] [I-D.zhang-ccamp-gmpls-evolving-g709]
Zhang, F., Zhang, G., Belotti, S., Ceccarelli, D., and K. Zhang, F., Zhang, G., Belotti, S., Ceccarelli, D., and K.
Pithewan, "Generalized Multi-Protocol Label Switching Pithewan, "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Extensions for the evolving G.709 (GMPLS) Signaling Extensions for the evolving G.709
Optical Transport Networks Control", Optical Transport Networks Control",
draft-zhang-ccamp-gmpls-evolving-g709-09 (work in draft-zhang-ccamp-gmpls-evolving-g709-09 (work in
progress), August 2011. progress), August 2011.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
September 2006. September 2006.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, September 2011.
Authors' Addresses Authors' Addresses
Cyril Margaria (editor) Cyril Margaria (editor)
Nokia Siemens Networks Nokia Siemens Networks
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
 End of changes. 80 change blocks. 
207 lines changed or deleted 239 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/