draft-ietf-pce-gmpls-pcep-extensions-06.txt   draft-ietf-pce-gmpls-pcep-extensions-07.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: January 16, 2013 Telefonica Investigacion y Expires: April 24, 2013 Telefonica Investigacion y
Desarrollo Desarrollo
F. Zhang, Ed. F. Zhang, Ed.
Huawei Technologies Huawei Technologies
July 15, 2012 October 21, 2012
PCEP extensions for GMPLS PCEP extensions for GMPLS
draft-ietf-pce-gmpls-pcep-extensions-06 draft-ietf-pce-gmpls-pcep-extensions-07
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 January 16, 2013. This Internet-Draft will expire on April 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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. Current GMPLS support and limitation of existing PCEP
objects . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6
2.1. RP object extension . . . . . . . . . . . . . . . . . . . 7 2.1. RP object extension . . . . . . . . . . . . . . . . . . . 7
2.2. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 8 2.2. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 8
2.3. Traffic parameters encoding, GENERALIZED-LOAD-BALANCING . 10 2.3. Traffic parameters encoding, GENERALIZED-LOAD-BALANCING . 10
2.4. END-POINTS Object extensions . . . . . . . . . . . . . . . 13 2.4. END-POINTS Object extensions . . . . . . . . . . . . . . . 13
2.4.1. Generalized Endpoint Object Type . . . . . . . . . . . 14 2.4.1. Generalized Endpoint Object Type . . . . . . . . . . . 14
2.4.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 17 2.4.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 17
2.5. IRO extension . . . . . . . . . . . . . . . . . . . . . . 20 2.5. IRO extension . . . . . . . . . . . . . . . . . . . . . . 20
2.6. XRO extension . . . . . . . . . . . . . . . . . . . . . . 21 2.6. XRO extension . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 36 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 9.1. Normative References . . . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . . 40 9.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
PCEP RFCs [RFC5440], [RFC5521], [RFC5541], [RFC5520] are focused on Although [RFC4655] defines the PCE architecture and framework for
path computation requests in MPLS networks, and [RFC4655] defines the both MPLS and GMPLS networks, current PCEP RFCs [RFC5440], [RFC5521],
PCE framework also for GMPLS networks. This document complements [RFC5541], [RFC5520] are focused on MPLS networks, and do not cover
these RFCs by providing some consideration of GMPLS applications and the wide range of GMPLS networks. This document complements these
RFCs by addressing the extensions required for GMPLS applications and
routing requests, for example for OTN and WSON networks. routing requests, for example for OTN and WSON networks.
The functional requirements to be considered by the PCEP extensions The functional requirements to be considered by the PCEP extensions
to support those application are described in to support those application are described in
[I-D.ietf-pce-gmpls-aps-req] and [I-D.ietf-pce-gmpls-aps-req] and
[I-D.ietf-pce-wson-routing-wavelength]. [I-D.ietf-pce-wson-routing-wavelength].
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
The document [I-D.ietf-pce-gmpls-aps-req] describes what are the set The document [I-D.ietf-pce-gmpls-aps-req] describes the set of PCEP
of PCEP PCEP requirements to support GMPLS TE-LSPs. When requesting requirements to support GMPLS TE-LSPs. When a PCC requests a PCE to
a path computation (PCReq) to a PCE, the PCC should be able to perform a path computation (by means of a PCReq message), the PCC
indicate the following additional information: should be able to indicate the following additional information:
Which data flow is switched by the LSP: a combination of Switching o Which data flow is switched by the LSP: a combination of Switching
capability (for instance L2SC or TDM), Switching Encoding (e.g., Type (for instance L2SC or TDM), Switching Encoding (e.g.,
Ethernet, SONET/SDH) and sometimes the Signal Type (in case of Ethernet, SONET/SDH) and sometimes the Signal Type (e.g. in case
TDM/LSC switching capability) of TDM/LSC switching capability)
Data flow specific traffic parameters, which is technology o Data flow specific traffic parameters, which are technology
specific. For instance, in SDH/SONET and G.709 OTN networks the specific. For instance, in SDH/SONET and G.709 OTN networks the
Concatenation Type and the Concatenation Number have an influence Concatenation Type and the Concatenation Number have an influence
on the switched data and on which link it can be supported on the switched data and on which link it can be supported
Support for asymmetric bandwidth requests. o Support for asymmetric bandwidth requests.
Support for unnumbered interface identifiers: as defined in o Support for unnumbered interface identifiers, as defined in
[RFC3477] [RFC3477]
Label information and technology specific label(s) such as o Label information and technology specific label(s) such as
wavelength label as defined in [RFC6205]. A PCC should also be wavelength labels as defined in [RFC6205]. A PCC should also be
able to specify Label restriction similar to the one supported by able to specify a Label restriction similar to the one supported
RSVP. by RSVP.
Ability to indicate the requested granularity for the path ERO: o Ability to indicate the requested granularity for the path ERO:
node, link, label. This is to allow the use of the explicit label node, link or label. This is to allow the use of the explicit
control of RSVP. label control feature of RSVP-TE.
We describe in this document a set of PCEP protocol extensions, We describe in this document a set of PCEP protocol extensions,
including new objects, TLVs, encodings, error codes and procedures, including new objects, TLVs, encodings, error codes and procedures,
in order to fulfill the aforementioned requirements. in order to fulfill the aforementioned requirements.
1.3. PCEP existing objects related to GMPLS 1.3. Current GMPLS support and limitation of existing PCEP objects
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 objects, included in requests and responses supports the following objects, included in requests and responses
related to the described requirements. related to the described requirements.
From [RFC5440]: From [RFC5440]:
o ENDPOINTS: only numbered endpoints are considered. The context o ENDPOINTS: only numbered endpoints are considered. The context
specifies whether they are node identifiers or numbered specifies whether they are node identifiers or numbered
interfaces. interfaces.
o BANDWIDTH: the data rate is encoded in the bandwidth object (as o BANDWIDTH: the data rate is encoded in the bandwidth object (as
IEEE 32 bit float). [RFC5440] does not include the ability to IEEE 32 bit float). [RFC5440] does not include the ability to
convey a (Intserv) TSPEC object. convey a (Intserv) TSPEC object.
o ERO o ERO : Unnumbered endpoints are supported.
o LSPA: LSP attributes (setup and holding priorities) o LSPA: LSP attributes (setup and holding priorities)
From [RFC5521] definition of the XRO object and a new semantic flag(F From [RFC5521] :
bit):
o This object allows to exclude (strict or not) resources; XRO o XRO object :
includes the diversity level (node, link, SRLG). The requested
diversity is expressed in the XRO
o When the F bit is set, the request indicates that the existing * This object allows excluding (strict or not) resources, and
route has failed and the resources present in the RRO can be includes the requested diversity (node, link or SRLG).
reused.
* When the F bit is set, the request indicates that the existing
route has failed and the 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 whether 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
be used to represent the RSVP-TE generalized label request be used to represent the RSVP-TE generalized label request
o REQ-ADAP-CAP : indicates the adaptation capabilities requested, o REQ-ADAP-CAP : indicates the adaptation capabilities requested,
can also be used for the endpoints in case of mono-layer can also be used for the endpoints in case of mono-layer
computation computation
The shortcomings of the existing PCEP object definition and encodings The shortcomings of the existing PCEP object are:
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 potential label restrictions on the interface. interface, nor potential label restrictions on the interface.
Those parameters are of interest in case of switching constraints. Those parameters are of interest in case of switching constraints.
The IRO/XRO objects do not allow inclusion/exclusion of labels The IRO/XRO objects do not allow the inclusion/exclusion of labels
Current attributes do not allow expressing the requested link Current attributes do not allow expressing the requested link
protection level and/or the end-to-end protection attributes. protection level and/or the 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,
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 A new TLV type for label is allowed in IRO and XRO objects.
In order to indicate the used routing granularity in the response, In order to indicate the used routing granularity in the response,
a new flag in the RP object is added. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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 PCEP request and response with the proposed extensions (GENERALIZED-
(GENERALIZED-BANDWIDTH, GENERALIZED-LOAD-BALANCING, SUGGESTED-LABEL- BANDWIDTH, GENERALIZED-LOAD-BALANCING, SUGGESTED-LABEL-SET and LABEL-
SET and LABEL-SET) is as follows: SET) is as follows:
<request>::= <RP> <request>::= <RP>
<segment-computation>|<path-key-expansion> <segment-computation>|<path-key-expansion>
<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>]
[<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>]
skipping to change at page 6, line 49 skipping to change at page 6, line 48
Where: Where:
<attribute-list>::=[<LSPA>] <attribute-list>::=[<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<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 grammar is:
<segment-computation> ::= <segment-computation> ::=
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<GENERALIZED-BANDWIDTH>...] [<GENERALIZED-BANDWIDTH>...]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
[<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>]
[< GENERALIZED-BANDWIDTH>...][<RRO-List>] [<GENERALIZED-BANDWIDTH>...][<RRO-List>]
2.1. RP object extension 2.1. RP object extension
Explicit label control (ELC) is a procedure supported by RSVP-TE, Explicit label control (ELC) is a procedure supported by RSVP-TE,
where the outgoing label(s) is(are) encoded in the ERO. In where the outgoing label(s) is(are) encoded in the ERO. In
consequence, the PCE may be able to provide such label(s) directly in consequence, the PCE may be able to provide such label(s) directly in
the path ERO. The PCC, depending on policies or switching layer, may the path ERO. The PCC, depending on policies or switching layer, may
be required to use explicit label control or expect explicit link, be required to use explicit label control or expect explicit link,
thus it need to indicate in the PCReq which granularity it is thus it need to indicate in the PCReq which granularity it is
expecting in the ERO. This correspond to requirement 11 of expecting in the ERO. This correspond to requirement 12 of
[I-D.ietf-pce-gmpls-aps-req] The possible granularities can be node, [I-D.ietf-pce-gmpls-aps-req] The possible granularities can be node,
link, label. The granularities are inter-dependent, in the sense link or label. The granularities are inter-dependent, in the sense
that link granularity imply the presence of node information in the that link granularity implies the presence of node information in the
ERO, similarly a label granularity imply that the ERO contain node, ERO; similarly, a label granularity implies that the ERO contains
link and label information. node, link and label information.
A new 2-bit routing granularity (RG) flag is defined in the RP A new 2-bit routing granularity (RG) flag is defined in the RP
object. The values are defined as follows object. The values are defined as follows
0 : node 0 : node
1 : link 1 : link
2 : label 2 : label
3 : reserved 3 : reserved
The flag in the RP object indicates the requested route granularity. The flag in the RP object indicates the requested route granularity.
The PCE MAY try to follow this granularity and MAY return a NO-PATH The PCE MAY try to follow this granularity and MAY return a NO-PATH
if the requested granularity cannot be provided. The PCE MAY return if the requested granularity cannot be provided. The PCE MAY return
more details on the route based on its policy. The PCC can decide if finer granularity on the route based on its policy. The PCC can
the ERO is acceptable based on its content. decide if the ERO is acceptable based on its content.
If a PCE honored the the requested routing granularity for a request, If a PCE honored the the requested routing granularity for a request,
it MUST indicate the selected routing granularity in the RP object it SHOULD indicate the selected routing granularity in the RP object
included in the response . The RG flag is backward-compatible with included in the response . The RG flag is backward-compatible with
[RFC5440]: the value sent by an implementation (PCC or PCE) not [RFC5440]: the value sent by an implementation (PCC or PCE) not
supporting it will indicate a node granularity. A new capability supporting it will indicate a node granularity.
flag in the 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 object does not describe the details of the signal The PCEP BANDWIDTH object does not describe the details of the signal
(for example NVC, multiplier), hence the bandwidth information should (for example NVC, multiplier), hence the bandwidth information should
be extended to use the RSVP Tspec object encoding. The PCEP be extended to use the RSVP Tspec object encoding. The PCEP
BANDWIDTH object defines two types: 1 and 2. C-Type 2 is BANDWIDTH object defines two types: 1 and 2. C-Type 2 is
representing the existing bandwidth in case of re-optimization. representing the existing bandwidth in case of re-optimization.
The following possibilities cannot be represented in the BANDWIDTH The following possibilities cannot be represented in the BANDWIDTH
object: object:
o Asymmetric bandwidth (different bandwidth in forward and reverse o Asymmetric bandwidth (different bandwidth in forward and reverse
direction), as described in [RFC6387] direction), as described in [RFC6387]
o GMPLS (SDH/SONET, G.709, ATM, MEF etc) parameters are not o GMPLS (SDH/SONET, G.709, ATM, MEF etc) parameters are not
supported. supported.
This correspond to requirement 3,4,5 and 10 of This correspond to requirement 3,4,5 and 11 of
[I-D.ietf-pce-gmpls-aps-req]. [I-D.ietf-pce-gmpls-aps-req].
According to [RFC5440] the BANDWIDTH object has no TLV and has a According to [RFC5440] the BANDWIDTH object has no TLV and has a
fixed size of 4 bytes. This definition does not allow extending it fixed size of 4 bytes. This definition does not allow extending it
with the required information. To express this information, a new with the required information. To express this information, a new
object named GENERALIZED-BANDWIDTH with Object Type 1, having the object named GENERALIZED-BANDWIDTH with Object Type 1, having the
following format is defined. The definitions below apply for Object following format is defined. The definitions below apply for Object
Type 1. Type 1. The payload of the GENERALIZED-BANDWIDTH is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Spec Length | TSpec Type | Reserved |R|O| | Traffic Spec Length | TSpec Type | Reserved |R|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Traffic Spec ~ ~ Traffic Spec ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 30 skipping to change at page 9, line 30
length field indicates the length of the Traffic spec field. The length field indicates the length of the Traffic spec field. The
bits R and O have the following meaning: bits R and O have the following meaning:
O bit : when set the value refers to the previous bandwidth in O bit : when set the value refers to the previous bandwidth in
case of re-optimization case of re-optimization
R bit : when set the value refers to the bandwidth of the reverse R bit : when set the value refers to the bandwidth of the reverse
direction direction
The TSpec Type field determines which type of bandwidth is The TSpec Type field determines which type of bandwidth is
represented by the object. The following values are defined to match represented by the object.
RSVP space (same C-Type as defined for RSVP Object class 12
(SENDER_TSPEC) )
1. Reserved
2. Intserv
3. Reserved
4. SONET/SDH
5. G.709
6. Ethernet The TSpec Type types correspond to the RSVPT-TE SENDER_TSPEC (Object
Class 12) C-Types
The encoding of the field Traffic Spec is the same as in RSVP-TE, it The encoding of the field Traffic Spec is the same as in RSVP-TE, it
can be found in the following references. can be found in the following references.
Object Type Name Reference Object Type Name Reference
2 Intserv [RFC2210] 2 Intserv [RFC2210]
4 SONET/SDH [RFC4606] 4 SONET/SDH [RFC4606]
skipping to change at page 11, line 17 skipping to change at page 10, line 50
The GENERALIZED-LOAD-BALANCING object, as the LOAD-BALANCING object, The GENERALIZED-LOAD-BALANCING object, as the LOAD-BALANCING object,
allows the PCC to request a set of TE-LSP having in total the allows the PCC to request a set of TE-LSP having in total the
GENERALIZED-BANDWIDTH traffic specification with potentially Max-Lsp, GENERALIZED-BANDWIDTH traffic specification with potentially Max-Lsp,
each TE-LSP having a minimum of Min Traffic spec. The GENERALIZED- each TE-LSP having a minimum of Min Traffic spec. The GENERALIZED-
LOAD-BALANCING is optional. LOAD-BALANCING is optional.
GENERALIZED-LOAD-BALANCING Object-Class is to be assigned by IANA. GENERALIZED-LOAD-BALANCING Object-Class is to be assigned by IANA.
GENERALIZED-LOAD-BALANCING Object Type 1 is defined below. The TSpec GENERALIZED-LOAD-BALANCING Object Type 1 is defined below. The TSpec
Type field determines which type of minimum bandwidth is represented Type field determines which type of minimum bandwidth is represented
by the object. The following object types are defined: by the object.
1. Reserved
2. Intserv
3. Reserved
4. SONET/SDH
5. G.709
6. Ethernet
The GENERALIZED-LOAD-BALANCING has a variable length. The GENERALIZED-LOAD-BALANCING has a variable length.
The format of the GENERALIZED-LOAD-BALANCING object body is as The format of the GENERALIZED-LOAD-BALANCING object body is as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic spec length | TSpec Type | Flags |R| | Traffic spec length | TSpec Type | Flags |R|
skipping to change at page 12, line 6 skipping to change at page 11, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Optional TLVs ~ ~ Optional TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic spec length (16 bits): the total length of the min traffic Traffic spec length (16 bits): the total length of the min traffic
specification. It should be noted that the RSVP traffic specification. It should be noted that the RSVP traffic
specification may also include TLV different than the PCEP TLVs. specification may also include TLV different than the PCEP TLVs.
TSpec Type (8 bits) : the traffic specification type, the same as the TSpec Type (8 bits) : the traffic specification type, it correspond
C-Types defined for RSVP Object class 12 (SENDER_TSPEC) to the RSVPT-TE SENDER_TSPEC (Object Class 12) C-Types
Flags (8 bits): The undefined Flags field MUST be set to zero on Flags (8 bits): The undefined Flags field MUST be set to zero on
transmission and MUST be ignored on receipt. The following flag is transmission and MUST be ignored on receipt. The following flag is
defined: defined:
R Flag : (1 bit) set when the value refer to the bandwidth of the R Flag : (1 bit) set when the value refer to the bandwidth of the
reverse direction reverse direction
Max-LSP (8 bits): maximum number of TE LSPs in the set. Max-LSP (8 bits): maximum number of TE LSPs in the set.
Min-Traffic spec (variable): Specifies the minimum traffic spec of Min-Traffic spec (variable): Specifies the minimum traffic spec of
each element of the set of TE LSPs. each element of the set of TE LSPs.
The encoding of the field Traffic Spec is the same as in RSVP-TE, it The encoding of the field Min Traffic Spec is the same as in RSVP-TE,
can be found in the following references. it can be found in the following references.
Object Type Name Reference Object Type Name Reference
2 Intserv [RFC2210] 2 Intserv [RFC2210]
4 SONET/SDH [RFC4606] 4 SONET/SDH [RFC4606]
5 G.709 [RFC4328] 5 G.709 [RFC4328]
6 Ethernet [RFC6003] 6 Ethernet [RFC6003]
skipping to change at page 13, line 30 skipping to change at page 13, line 10
use the GENERALIZED-LOAD-BALANCING. In case the V4 components can use the GENERALIZED-LOAD-BALANCING. In case the V4 components can
use different paths, the GENERALIZED-BANDWIDTH will contain a traffic use different paths, the GENERALIZED-BANDWIDTH will contain a traffic
specification indicating the complete n x VC4 traffic specification specification indicating the complete n x VC4 traffic specification
and the GENERALIZED-LOAD-BALANCING the minimum co-signaled VC4. For and the GENERALIZED-LOAD-BALANCING the minimum co-signaled VC4. For
a SDH network, a request to have a TE-LSP group with 10 VC4 a SDH network, a request to have a TE-LSP group with 10 VC4
container, each path using at minimum 2VC4 container, can be container, each path using at minimum 2VC4 container, can be
represented with a GENERALIZED-BANDWIDTH object with OT=4, the represented with a GENERALIZED-BANDWIDTH object with OT=4, the
content of the Traffic specification is ST=6,RCC=0,NCC=0,NVC=10,MT=1. content of the Traffic specification is ST=6,RCC=0,NCC=0,NVC=10,MT=1.
The GENERALIZED-LOAD-BALANCING, OT=4,R=0,Max-LSP=5, min Traffic spec The GENERALIZED-LOAD-BALANCING, OT=4,R=0,Max-LSP=5, min Traffic spec
is (ST=6,RCC=0,NCC=0,NVC=2,MT=1). The PCE can respond with a is (ST=6,RCC=0,NCC=0,NVC=2,MT=1). The PCE can respond with a
response with maximum 5 path, each of then having a GENERALIZED- response with maximum 5 path, each of them having a GENERALIZED-
BANDWIDTH OT=4,R=0, and traffic spec matching the minimum traffic BANDWIDTH OT=4,R=0, and traffic spec matching the minimum traffic
spec from the GENERALIZED-LOAD-BALANCING object of the corresponding spec from the GENERALIZED-LOAD-BALANCING object of the corresponding
request. request.
2.4. END-POINTS Object extensions 2.4. END-POINTS Object extensions
The END-POINTS object is used in a PCEP request message to specify The END-POINTS object is used in a PCEP request message to specify
the source and the destination of the path for which a path the source and the destination of the path for which a path
computation is requested. From [RFC3471] the source IP address and computation is requested. From [RFC5440]the source IP address and
the destination IP address are used to identify those. A new Object the destination IP address are used to identify those. A new Object
Type is defined to address the following possibilities: Type is defined to address the following possibilities:
o Different source and destination endpoint types. o Different source and destination endpoint types.
o Label restrictions on the endpoint. o Label restrictions on the endpoint.
o Specification of unnumbered endpoints type as seen in GMPLS o Specification of unnumbered endpoints type as seen in GMPLS
networks. networks.
The Object encoding is described in the following sections. The Object encoding is described in the following sections.
In path computation withing a GMPLS context the endpoints can: In path computation within a GMPLS context the endpoints can:
o Be unnumbered as described in [RFC3477]. o Be unnumbered as described in [RFC3477].
o Have label(s) associated to them, specifying a set of constraints o Have label(s) associated to them, specifying a set of constraints
in the allocation of labels. in the allocation of labels.
o May have different switching capabilities o May have different switching capabilities
The IPv4 and IPv6 endpoints are used to represent the source and The IPv4 and IPv6 endpoints are used to represent the source and
destination IP addresses. The scope of the IP address (Node or destination IP addresses. The scope of the IP address (Node or
numbered Link) is not explicitly stated. It should also be possible numbered Link) is not explicitly stated. It is also possible to
to request a Path between a numbered link and an unnumbered link, or request a Path between a numbered link and an unnumbered link, or a
a P2MP path between different type of endpoints. P2MP path between different type of endpoints.
Since the PCEP END-POINTS object only support endpoints of the same This new C-Type also supports the specification of constraints on the
type (IP-address) a new C-Type is proposed that support different endpoint label to be use. The PCE might know the interface
endpoint types, including unnumbered. This new C-Type also supports restrictions but this is not a requirement. This corresponds to
the specification of constraints on the endpoint label to be use. requirements 6 and 10 of [I-D.ietf-pce-gmpls-aps-req].
The PCE might know the interface restrictions but this is not a
requirement. On the path calculation request only the Tspec and
switch layer need to be coherent, the endpoint labels could be
different (supporting a different Tspec). Hence the label
restrictions include a Generalized label request in order to
interpret the labels. This correspond to requirement 6 and 9 of
[I-D.ietf-pce-gmpls-aps-req].
2.4.1. Generalized Endpoint Object Type 2.4.1. Generalized Endpoint Object Type
The Generalized Endpoint object type format consists of a body and a The Generalized Endpoint object type format consists of a body and a
list of TLVs scoped to this object type object. The TLVs give the list of TLVs scoped to this object type object. The TLVs give the
details of the endpoints and are described in Section 2.4.2. For details of the endpoints and are described in Section 2.4.2. For
each endpoint type, a different grammar is defined. The TLVs defined each endpoint type, a different grammar is defined. The TLVs defined
to describe an endpoint are: to describe an endpoint are:
1. IPv4 address. 1. IPv4 address endpoint.
2. IPv6 address. 2. IPv6 address endpoint.
3. Unnumbered endpoint. 3. Unnumbered endpoint.
4. Label set. 4. Label set restriction.
5. Suggested label set. 5. Suggested label set restriction.
The Label Set and Suggested label set TLVs are used to restrict the The Label Set and Suggested label set TLVs are used to restrict the
label allocation in the PCE. Those TLVs express the the set of label allocation in the PCE. Those TLVs express the set of
restrictions provided by signaling. Label restriction support are restrictions provided by signaling. Label restriction support can be
explicit value (Label set describing one label), mandatory range an explicit value (Label set describing one label), mandatory range
restrictions (Label set), optional range restriction (suggested label restrictions (Label set), optional range restriction (suggested label
set) and dingle suggested value is using the suggested label set. set) and single suggested value is using the suggested label set.
The label range restrictions are valid in GMPLS networks, either by Endpoints label restriction may not be part of the RRO or IRO, they
PCC policy or depending on the switching technology used, for may be included when following [RFC4003] in signaling for egress
instance on given Ethernet or ODU equipment having limited hardware endpoint, but ingress endpoint properties may be local to the PCC and
capabilities restricting the label range. Label set restriction also not signaled. To support this case the label set allows to indicate
applies to WSON networks where the optical sender and receivers are which label are used in case of reoptimization. The label range
limited in their frequency tunability ranges, restricting then in restrictions are valid in GMPLS networks, either by PCC policy or
GMPLS the possible label ranges on the interface. The END-POINTS depending on the switching technology used, for instance on given
Object with Generalized Endpoint object type is encoded as follow: Ethernet or ODU equipment having limited hardware capabilities
restricting the label range. 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 15, line 50 skipping to change at page 15, line 29
modified/reoptimized modified/reoptimized
4 Old leaves whose path must be left 4 Old leaves whose path must be left
unchanged unchanged
5-244 Reserved 5-244 Reserved
245-255 Experimental range 245-255 Experimental range
The endpoint type is used to cover both point-to-point and different The endpoint type is used to cover both point-to-point and different
point-to-multipoint endpoint semantic. Endpoint type 0 MAY be point-to-multipoint endpoints. Endpoint type 0 MAY be accepted by
accepted by the PCE, other endpoint type MAY be supported if the PCE the PCE, other endpoint type MAY be supported if the PCE
implementation supports P2MP path calculation. A PCE not supporting implementation supports P2MP path calculation. A PCE not supporting
a given endpoint type MUST respond with a PCErr with error code "Path a given endpoint type MUST respond with a PCErr with error code "Path
computation failure", error type "Unsupported endpoint type in END- computation failure", error type "Unsupported endpoint type in END-
POINTS Generalized Endpoint object type". The TLVs present in the POINTS Generalized Endpoint object type". The TLVs present in the
request object body MUST follow the following grammar: request object body MUST follow the following grammar:
<generalized-endpoint-tlvs>::= <generalized-endpoint-tlvs>::=
<p2p-endpoints> | <p2mp-endpoints> <p2p-endpoints> | <p2mp-endpoints>
<p2p-endpoints> ::= <p2p-endpoints> ::=
skipping to change at page 18, line 37 skipping to change at page 18, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV MAY be ignored, in which case a PCRep with NO-PATH should be This TLV MAY be ignored, in which case a PCRep with NO-PATH should be
responded, as described in Section 2.4.1. responded, as described in Section 2.4.1.
2.4.2.4. LABEL-REQUEST TLV 2.4.2.4. LABEL-REQUEST TLV
The LABEL-REQUEST TLV indicates the switching capability and encoding The LABEL-REQUEST TLV indicates the switching capability and encoding
type of the following label restriction list. Its format is the same type of the following label restriction list for the endpoint. Its
as described in [RFC3471] Section 3.1 Generalized label request. The format is the same as described in [RFC3471] Section 3.1 Generalized
LABEL-REQUEST TLV use TLV-Type=TBA. The fields are encoded as in the label request. The LABEL-REQUEST TLV use TLV-Type=TBA. The fields
RSVP-TE. The Encoding Type indicates the encoding type, e.g., SONET/ are encoded as in the RSVP-TE. The Encoding Type indicates the
SDH/GigE etc., that will be used with the data associated with the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the
LSP. The Switching type indicates the type of switching that is data associated. The Switching type indicates the type of switching
being requested on the link. G-PID identifies the payload of the TE- that is being requested on the endpoint. G-PID identifies the
LSP. This TLV and the following one are introduced to satisfy payload. This TLV and the following one are introduced to satisfy
requirement 13 for the endpoint. requirement 13 for the endpoint. It is not directly related to the
TE-LSP label request, which is expressed by the SWITCH-LAYER object.
This TLV MAY be ignored, in which case a PCRep with NO-PATH should be On the path calculation request only the Tspec and switch layer need
responded, as described in Section 2.4.1. to be coherent, the endpoint labels could be different (supporting a
different Tspec). Hence the label restrictions include a Generalized
label request in order to interpret the labels. This TLV MAY be
ignored, in which case a PCRep with NO-PATH should be responded, as
described in Section 2.4.1.
2.4.2.5. Labels TLV 2.4.2.5. Labels TLV
Label or label range restrictions may be specified for the TE-LSP Label or label range restrictions may be specified for the TE-LSP
endpoints. Those are encoded using the LABEL-SET TLV. The label endpoints. Those are encoded using the LABEL-SET TLV. The label
value need to be interpreted with a description on the Encoding and value need to be interpreted with a description on the Encoding and
switching type. The REQ-ADAP-CAP object from switching type. The REQ-ADAP-CAP object from
[I-D.ietf-pce-inter-layer-ext] can be used in case of mono-layer [I-D.ietf-pce-inter-layer-ext] can be used in case of mono-layer
request, however in case of multilayer it is possible to have in the request, however in case of multilayer it is possible to have in the
future more than one object, so it is better to have a dedicated TLV future more than one object, so it is better to have a dedicated TLV
skipping to change at page 20, line 19 skipping to change at page 20, line 17
O: Old Label: set when the TLV represent the old label in case in O: Old Label: set when the TLV represent the old label in case in
case of re-optimization. This Bit SHOULD be set to 0 in a case of re-optimization. This Bit SHOULD be set to 0 in a
SUGGESTED-LABEL-SET TLV Set. This Label MAY be reused. The R bit SUGGESTED-LABEL-SET TLV Set. This Label MAY be reused. The R bit
of the RP object MUST be set. When this bit is set the Action of the RP object MUST be set. When this bit is set the Action
field MUST be set to 0 (Inclusive List) and the Label Set MUST field MUST be set to 0 (Inclusive List) and the Label Set MUST
contain one subchannel. contain one subchannel.
Several LABEL_SET TLVs MAY be present with the 0 bit cleared. At Several LABEL_SET TLVs MAY be present with the 0 bit cleared. At
most 2 LABEL_SET TLV SHOULD be present with the 0 bit set, at most most 2 LABEL_SET TLV SHOULD be present with the 0 bit set, at most
one with te U bit set and at most one with the U bit cleared. For a one with the U bit set and at most one with the U bit cleared. For a
given U bit value if more than one LABEL_SET TLV with the O bit set given U bit value if more than one LABEL_SET TLV with the O bit set
is present, the first TLV SHOULD be processed and the following TLV is present, the first TLV SHOULD be processed and the following TLV
with the same U and O bit SHOULD be ignored. with the same U and O bit SHOULD be ignored.
A SUGGESTED-LABEL-SET TLV with the O bit set MUST trigger a PCErr A SUGGESTED-LABEL-SET TLV with the O bit set MUST trigger a PCErr
message with error type="Reception of an invalid object" error message with error type="Reception of an invalid object" error
value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 0 bit value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 0 bit
set". set".
A LABEL-SET TLV with the O bit set and an Action Field not set to 0 A LABEL-SET TLV with the O bit set and an Action Field not set to 0
skipping to change at page 23, line 4 skipping to change at page 22, line 35
Type Sub-object Type Sub-object
3 LABEL 3 LABEL
The L bit of such sub-object has no meaning within an XRO. 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 of
input for route and label selection. The LSPA object can be extended [I-D.ietf-pce-gmpls-aps-req] section 4.1 and requirement 3 of
by a protection TLV type: Type TBA: PROTECTION-ATTRIBUTE [I-D.ietf-pce-gmpls-aps-req] section 4.2 and may be used as a policy
input for route and label selection on request. The LSPA object MAY
carry a PROTECTION-ATTRIBUTE TLV defined as : 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is as defined in [RFC4872], [RFC4873]. The content is as defined in [RFC4872], [RFC4873].
LSP Flags can be considered for routing policy based on the LSP Flags can be considered for routing policy based on the
protection type. The other attributes are only meaningful for a protection type. The other attributes are only meaningful for a
s_ateful PCE. stateful PCE.
This TLV is optional and MAY be ignored by the PCE, in which case it This TLV is optional and MAY be ignored by the PCE, in which case it
MUST NOT include the TLV in the LSPA, if present, of the response. MUST NOT include the TLV in the LSPA, if present, of the response.
When the TLV is used by the PCE, a LSPA object and the PROTECTION- When the TLV is used by the PCE, a LSPA object and the PROTECTION-
ATTRIBUTE TLV MUST be included in the response. Fields that were not ATTRIBUTE TLV MUST be included in the response. Fields that were not
considered MUST be set to 0. considered MUST be set to 0.
2.8. NO-PATH Object Extension 2.8. NO-PATH Object Extension
The NO-PATH object is used in PCRep messages in response to an The NO-PATH object is used in PCRep messages in response to an
skipping to change at page 39, line 27 skipping to change at page 39, line 27
January 2003. January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006. Transport Networks Control", RFC 4328, January 2006.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006. Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
skipping to change at page 39, line 48 skipping to change at page 39, line 51
Information Base", RFC 4802, February 2007. Information Base", RFC 4802, February 2007.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi- Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007. May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation Topology Confidentiality in Inter-Domain Path Computation
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
skipping to change at page 41, line 9 skipping to change at page 41, line 4
Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions
to the Path Computation Element communication Protocol to the Path Computation Element communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic (PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-ext-07 (work in Engineering", draft-ietf-pce-inter-layer-ext-07 (work in
progress), July 2012. progress), July 2012.
[I-D.ietf-pce-wson-routing-wavelength] [I-D.ietf-pce-wson-routing-wavelength]
Lee, Y., Bernstein, G., Martensson, J., Takeda, T., Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
Tsuritani, T., and O. Dios, "PCEP Requirements for WSON Tsuritani, T., and O. Dios, "PCEP Requirements for WSON
Routing and Wavelength Assignment", Routing and Wavelength Assignment",
draft-ietf-pce-wson-routing-wavelength-07 (work in draft-ietf-pce-wson-routing-wavelength-08 (work in
progress), April 2012. progress), October 2012.
[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.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123, Computation Element (PCE) Working Group Drafts", RFC 6123,
 End of changes. 60 change blocks. 
155 lines changed or deleted 132 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/