ERO:

Explicit Route Object

IRO:

Include Route Object

L2SC:

Layer 2 Switch Capable [RFC 3471]

LSC:

Lambda Switch Capable [RFC 3471]

LSP:

Label Switched Path

LSPA:

LSP Attribute

MEF:

Metro Ethernet Forum

MT:

Multiplier [RFC 4328] [RFC 4606]

NCC:

Number of Contiguous Components [RFC 4606]

NVC:

Number of Virtual Components [RFC 4328] [RFC 4606]

ODU:

Optical Data Unit [G.709-v3]

OTN:

Optical Transport Network [G.709-v3]

P2MP:

Point-to-Multipoint

PCC:

Path Computation Client

PCRep:

Path Computation Reply [RFC 5440]

PCReq:

Path Computation Request [RFC 5440]

RCC:

Requested Contiguous Concatenation [RFC 4606]

RRO:

Record Route Object

RSVP-TE:

Resource Reservation Protocol - Traffic Engineering

SDH:

Synchronous Digital Hierarchy

SONET:

Synchronous Optical Network

SRLG:

Shared Risk Link Group

SSON:

Spectrum-Switched Optical Network

TDM:

Time-Division Multiplex Capable [RFC 3471]

TE-LSP:

Traffic Engineered LSP

XRO:

Exclude Route Object

• Which data flow is switched by the LSP: a combination of a switching type (for instance, L2SC or TDM), an LSP encoding type (e.g., Ethernet, SONET/SDH), and sometimes the signal type (e.g., in case of a TDM or an LSC switching capability).
• Data-flow-specific traffic parameters, which are technology specific. For instance, in SDH/SONET and OTN networks [G.709-v3], the concatenation type and the concatenation number have an influence on the switched data and on which link it can be supported.
• Support for asymmetric bandwidth requests.
• Support for unnumbered interface identifiers, as defined in [RFC 3477].
• Label information and technology-specific label(s) such as wavelength labels as defined in [RFC 6205]. A PCC should also be able to specify a label restriction similar to the one supported by RSVP-TE in [RFC 3473].
• Ability to indicate the requested granularity for the path ERO: node, link, or label. This is to allow the use of the explicit label control feature of RSVP-TE.

(1)

Switching capability/type: As described in [RFC 3471], this piece of information is used with the encoding type and signal type to fully describe the switching technology and data carried by the TE-LSP. This is applicable to the TE-LSP itself and also to the TE-LSP endpoint (carried in the END-POINTS object for MPLS networks in [RFC 5440]) when considering multiple network layers. Inter-layer path computation requirements are addressed in [RFC 8282], which focuses on the TE-LSP itself but does not address the TE-LSP endpoints.

(2)

Encoding type: See (1).

(3)

Signal type: See (1).

(4)

Concatenation type: This parameter and the concatenation number (see (5)) are specific to some TDM (SDH and ODU) switching technologies. They MUST be described together and are used to derive the requested resource allocation for the TE-LSP. It is scoped to the TE-LSP and is related to the BANDWIDTH object [RFC 5440] in MPLS networks. See concatenation information in [RFC 4606] and [RFC 4328].

(5)

Concatenation number: See (4).

(6)

Technology-specific label(s): As described in [RFC 3471], the GMPLS labels are specific to each switching technology. They can be specified on each link and also on the TE-LSP endpoints, in WSON networks, for instance, as described in [RFC 6163]. The label restriction can apply to endpoints, and on each hop, the related PCEP objects are END-POINTS, IRO, XRO, and RRO.

(7)

End-to-End (E2E) path protection type: As defined in [RFC 4872], this is applicable to the TE-LSP. In MPLS networks, the related PCEP object is LSPA (carrying local protection information).

(8)

Administrative group: As defined in [RFC 3630], this information is already carried in the LSPA object.

(9)

Link protection type: As defined in [RFC 4872], this is applicable to the TE-LSP and is carried in association with the E2E path protection type.

(10)

Support for unnumbered interfaces: As defined in [RFC 3477]. Its scope and related objects are the same as labels.

(11)

Support for asymmetric bandwidth requests: As defined in [RFC 6387], the scope is similar to (4).

(12)

Support for explicit label control during the path computation: This affects the TE-LSP and the amount of information returned in the ERO.

(13)

Support of label restrictions in the requests/responses: This is described in (6).

(1)

Path computation with concatenation: This is related to the Path Computation request requirement (4). In addition, there is a specific type of concatenation, called virtual concatenation, that allows different routes to be used between the endpoints. It is similar to the semantic and scope of the LOAD-BALANCING in MPLS networks.

(2)

Label constraint: The PCE should be able to include labels in the path returned to the PCC; the related object is the ERO object.

(3)

Roles of the routes: As defined in [RFC 4872], this is applicable to the TE-LSP and is carried in association with the E2E path protection type.

• END-POINTS:

  related to requirements 1, 2, 3, 6, 10, and 13. The object only supports numbered endpoints. The context specifies whether they are node identifiers or numbered interfaces.

  BANDWIDTH:

  related to requirements 4, 5, and 11. The data rate is encoded in the BANDWIDTH object (as an IEEE 32-bit float). [RFC 5440] does not include the ability to convey an encoding proper to all GMPLS-controlled networks.

  ERO:

  related to requirements 6, 10, 12, and 13. The ERO content is defined in RSVP in [RFC 3209], [RFC 3473], [RFC 3477], and [RFC 7570] and already supports all of the requirements.

  LSPA:

  related to requirements 7, 8, and 9. Requirement 8 (Administrative group) is already supported.

• XRO:
  • This object allows excluding (strict or not) resources and is related to requirements 6, 10, and 13. It also includes the requested diversity (node, link, or SRLG).
  • When the F bit is set, the request indicates that the existing path has failed, and the resources present in the RRO can be reused.

• SWITCH-LAYER:

  addresses requirements 1, 2, and 3 for the TE-LSP and indicates which layer(s) should be considered. The object can be used to represent the RSVP-TE Generalized Label Request. It does not address the endpoints case of requirements 1, 2, and 3.

  REQ-ADAP-CAP:

  indicates the adaptation capabilities requested; it can also be used for the endpoints in case of mono-layer computation.

• The BANDWIDTH and LOAD-BALANCING objects do not describe the details of the traffic request (requirements 4 and 5, for example, NVC and multiplier) in the context of GMPLS networks, for instance, in TDM or OTN networks.
• The END-POINTS object does not allow specifying an unnumbered interface, nor potential label restrictions on the interface (requirements 6, 10, and 13). Those parameters are of interest in case of switching constraints.
• The IROs/XROs do not allow the inclusion/exclusion of labels (requirements 6, 10, and 13).
• Base attributes do not allow expressing the requested link protection level and/or the end-to-end protection attributes.

• Two new object types are defined for the BANDWIDTH object (Generalized bandwidth and Generalized bandwidth of an existing TE-LSP for which a reoptimization is requested).
• A new object type is defined for the LOAD-BALANCING object (Generalized Load Balancing).
• A new object type is defined for the END-POINTS object (Generalized Endpoint).
• A new TLV is added to the Open message for capability negotiation.
• A new TLV is added to the LSPA object.
• The Label subobject is now allowed in the IRO and XRO objects.
• In order to indicate the routing granularity used in the response, a new flag is added in the RP object.

• 0:

  reserved

  1:

  node

  2:

  link

  3:

  label

• Asymmetric bandwidth (different bandwidth in forward and reverse direction), as described in [RFC 6387].
• GMPLS (SDH/SONET, G.709, ATM, MEF, etc.) parameters.

• 3:

  Generalized bandwidth

  4:

  Generalized bandwidth of an existing TE-LSP for which a reoptimization is requested

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Bandwidth Spec Length      | Rev. Bandwidth Spec Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Bw Spec Type  |   Reserved                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Generalized Bandwidth                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~            Reverse Generalized Bandwidth (optional)           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Optional TLVs                           ~ 
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Bandwidth Spec Length      | Reverse Bandwidth Spec Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Bw Spec Type  |  Max-LSP      | Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Min Bandwidth Spec                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Min Reverse Bandwidth Spec (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Optional TLVs                            ~ 
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

Bandwidth Spec Length (16 bits):

the total length of the Min Bandwidth Spec field. The length MUST be strictly greater than 0.

Reverse Bandwidth Spec Length (16 bits):

the total length of the Min Reverse Bandwidth Spec field. It MAY be equal to 0.

Bw Spec Type (8 bits):

the bandwidth specification type; it corresponds to RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.

Max-LSP (8 bits):

the maximum number of TE-LSPs in the set.

Min Bandwidth Spec (variable):

specifies the minimum bandwidth specification of each element of the TE-LSP set.

Min Reverse Bandwidth Spec (variable):

specifies the minimum reverse bandwidth specification of each element of the TE-LSP set.

• Different source and destination endpoint types.
• Label restrictions on the endpoint.
• Specification of unnumbered endpoints type as seen in GMPLS networks.

• Be unnumbered as described in [RFC 3477].
• Have labels associated to them, specifying a set of constraints on the allocation of labels.
• Have different switching capabilities.

1. IPV4-ADDRESS
2. IPV6-ADDRESS
3. UNNUMBERED-ENDPOINT
4. LABEL-REQUEST
5. LABEL-SET

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Reserved                                 | Endpoint Type |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           TLVs                                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             

  <generalized-endpoint-tlvs>::=
    <p2p-endpoints> | <p2mp-endpoints>

  <p2p-endpoints> ::=
    <endpoint> [<endpoint-restriction-list>]
    <endpoint> [<endpoint-restriction-list>]

  <p2mp-endpoints> ::=
    <endpoint> [<endpoint-restriction-list>]
    <endpoint> [<endpoint-restriction-list>]
    [<endpoint> [<endpoint-restriction-list>]]...

 <endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT>
 <endpoint-restriction-list> ::= <endpoint-restriction>
                  [<endpoint-restriction-list>]

 <endpoint-restriction> ::=
                  [<LABEL-REQUEST>][<label-restriction-list>]

 <label-restriction-list> ::= <label-restriction>
                              [<label-restriction-list>]
 <label-restriction> ::= <LABEL-SET>

  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  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Action     |    Reserved |L|O|U|        Label Type         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Subchannel 1                         |
 |                              ...                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                               :                               :
 :                               :                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Subchannel N                         |
 |                              ...                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

• U:

  Upstream direction. Set for the upstream (reverse) direction in case of bidirectional LSP.

  O:

  Old label. Set when the TLV represents the old (previously allocated) label in case of reoptimization. The R bit of the RP object MUST be set to 1. If the L bit is set, this bit SHOULD be set to 0 and ignored on receipt. When this bit is set, the Action field MUST be set to 0 (Inclusive List), and the LABEL-SET MUST contain one subchannel.

  L:

  Loose label. Set when the TLV indicates to the PCE that a set of preferred (ordered) labels are to be used. The PCE MAY use those labels for label allocation.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|    Type=10  |    Length     |U|   Reserved  |   C-Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Label                             |
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

X (1 bit):

See [RFC 5521]. The X bit indicates whether the exclusion is mandatory or desired. 0 indicates that the resource specified MUST be excluded from the path computed by the PCE. 1 indicates that the resource specified SHOULD be excluded from the path computed by the PCE, but it MAY be included subject to the PCE policy and the absence of a viable path that meets the other constraints and excludes the resource.

Type (7 bits):

The type of the XRO Label subobject is 10.

Length (8 bits):

See [RFC 5521]. 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 RFC 3471, Section 6.1.

C-Type (8 bits):

The C-Type of the included Label object as defined in [RFC 3473].

Label:

See [RFC 3471].

• Bit number 18:

  Protection Mismatch (1 bit). Specifies the mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in the request.

  Bit number 17:

  No Resource (1 bit). Specifies that the resources are not currently sufficient to provide the path.

  Bit number 16:

  Granularity not supported (1 bit). Specifies that the PCE is not able to provide a path with the requested granularity.

  Bit number 15:

  No endpoint label resource (1 bit). Specifies that the PCE is not able to provide a path because of the endpoint label restriction.

  Bit number 14:

  No endpoint label resource in range (1 bit). Specifies that the PCE is not able to provide a path because of the endpoint label set restriction.

  Bit number 13:

  No label resource in range (1 bit). Specifies that the PCE is not able to provide a path because of the label set restriction.

  Bit number 12:

  LOAD-BALANCING could not be performed with the bandwidth constraints (1 bit). Specifies that the PCE is not able to provide a path because it could not map the BANDWIDTH into the parameters specified by the LOAD-BALANCING.

• Accepted RG in the RP object.
• Default RG to use (overriding the one present in the PCReq).
• Accepted BANDWIDTH object type 3 and 4 parameters in the request and default mapping to use when not specified in the request.
• Accepted LOAD-BALANCING object type 2 parameters in request.
• Accepted endpoint type and allowed TLVs in object END-POINTS with the object type Generalized Endpoint.
• Accepted range for label restrictions in END-POINTS or IRO/XRO objects.
• Acceptance and suppression of the PROTECTION-ATTRIBUTE TLV.

• Value
• Type
• Defining RFC

• Bit number (counting from bit 0 as the most significant bit)
• Capability description
• Defining RFC

• PCE Identity theft:

  A legitimate PCC could request a path for a GMPLS LSP to a malicious PCE, which poses as a legitimate PCE. The response may be that the LSP traverses some geographical place known to the attacker where confidentiality (sniffing), integrity (traffic modification), or availability (traffic drop) attacks could be performed by use of an attacker-controlled middlebox device. Also, the resulting LSP can omit constraints given in the requests (e.g., excluding certain fibers and avoiding some SRLGs), which could make the LSP that will be set up later look perfectly fine, but it will be in a risky situation. Also, the result can lead to the creation of an LSP that does not provide the desired quality and gives less resources than necessary.

  PCC Identity theft:

  A malicious PCC, acting as a legitimate PCC, requesting LSP paths to a legitimate PCE can obtain a good knowledge of the physical topology of a critical infrastructure. It could learn enough details to plan a later physical attack.

  Message inspection:

  As in the previous case, knowledge of an infrastructure can be obtained by sniffing PCEP messages.

[G.709-v3]

ITU-T, "Interfaces for the optical transport network", June 2016,
<https://www.itu.int/rec/T-REC-G.709-201606-I/en>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2210]

J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, DOI 10.17487/RFC2210, September 1997,
<https://www.rfc-editor.org/info/rfc2210>.

[RFC3209]

D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.

[RFC3471]

L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>.

[RFC3473]

L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.

[RFC3477]

K. Kompella, and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<https://www.rfc-editor.org/info/rfc3477>.

[RFC3630]

D. Katz, K. Kompella, and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.

[RFC4003]

L. Berger, "GMPLS Signaling Procedure for Egress Control", RFC 4003, DOI 10.17487/RFC4003, February 2005,
<https://www.rfc-editor.org/info/rfc4003>.

[RFC4328]

D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006,
<https://www.rfc-editor.org/info/rfc4328>.

[RFC4606]

E. Mannie, and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, DOI 10.17487/RFC4606, August 2006,
<https://www.rfc-editor.org/info/rfc4606>.

[RFC4802]

T. Nadeau, and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, DOI 10.17487/RFC4802, February 2007,
<https://www.rfc-editor.org/info/rfc4802>.

[RFC4872]

J.P. Lang, Y. Rekhter, and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.

[RFC4873]

L. Berger, I. Bryskin, D. Papadimitriou, and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007,
<https://www.rfc-editor.org/info/rfc4873>.

[RFC5088]

JL. Le Roux, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008,
<https://www.rfc-editor.org/info/rfc5088>.

[RFC5089]

JL. Le Roux, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008,
<https://www.rfc-editor.org/info/rfc5089>.

[RFC5440]

JP. Vasseur, and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.

[RFC5511]

A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009,
<https://www.rfc-editor.org/info/rfc5511>.

[RFC5520]

R. Bradford, JP. Vasseur, and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009,
<https://www.rfc-editor.org/info/rfc5520>.

[RFC5521]

E. Oki, T. Takeda, and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009,
<https://www.rfc-editor.org/info/rfc5521>.

[RFC5541]

JL. Le Roux, JP. Vasseur, and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.

[RFC6001]

D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010,
<https://www.rfc-editor.org/info/rfc6001>.

[RFC6003]

D. Papadimitriou, "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>.

[RFC6205]

T. Otani, and D. Li, "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011,
<https://www.rfc-editor.org/info/rfc6205>.

[RFC6387]

A. Takacs, L. Berger, D. Caviglia, D. Fedyk, and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, September 2011,
<https://www.rfc-editor.org/info/rfc6387>.

[RFC7139]

F. Zhang, G. Zhang, S. Belotti, D. Ceccarelli, and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/info/rfc7139>.

[RFC7570]

C. Margaria, G. Martinelli, S. Balls, and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015,
<https://www.rfc-editor.org/info/rfc7570>.

[RFC7792]

F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, and D. Ceccarelli, "RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7792, DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8253]

D. Lopez, O. Gonzalez de Dios, Q. Wu, and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.

[RFC8282]

E. Oki, T. Takeda, A. Farrel, and F. Zhang, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 8282, DOI 10.17487/RFC8282, December 2017,
<https://www.rfc-editor.org/info/rfc8282>.

[RFC8306]

Q. Zhao, D. Dhody, R. Palleti, and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>.

[RFC4655]

A. Farrel, J.-P. Vasseur, and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.

[RFC4657]

J. Ash, and J.L. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006,
<https://www.rfc-editor.org/info/rfc4657>.

[RFC5920]

L. Fang, "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.

[RFC6123]

A. Farrel, "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.

[RFC6163]

Y. Lee, G. Bernstein, and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011,
<https://www.rfc-editor.org/info/rfc6163>.

[RFC7025]

T. Otani, K. Ogaki, D. Caviglia, F. Zhang, and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, DOI 10.17487/RFC7025, September 2013,
<https://www.rfc-editor.org/info/rfc7025>.

[RFC7449]

Y. Lee, G. Bernstein, J. Martensson, T. Takeda, T. Tsuritani, and O. Gonzalez de Dios, "Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment", RFC 7449, DOI 10.17487/RFC7449, February 2015,
<https://www.rfc-editor.org/info/rfc7449>.

Elie Sfeir

Franz Rambach

Francisco Javier Jimenez Chico

Suresh Babu

Young Lee

Senthil Kumar S

Jun Sun

Ramon Casellas

Cyril Margaria

Oscar Gonzalez de Dios

Fatai Zhang