| PCE Working Group | I. Minei |
| Internet-Draft | Google, Inc. |
| Intended status: Standards Track | E. Crabbe |
| Expires: December 29, 2017 | Individual Contributor |
| S. Sivabalan | |
| Cisco Systems, Inc. | |
| H. Ananthakrishnan | |
| Packet Design | |
| D. Dhody | |
| Huawei | |
| Y. Tanaka | |
| NTT Communications Corporation | |
| June 27, 2017 |
PCEP Extensions for Establishing Relationships Between Sets of LSPs
draft-ietf-pce-association-group-03
This document introduces a generic mechanism to create a grouping of LSPs in the context of a PCE. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to stateful PCE (active and passive modes) and stateless PCE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC5440] describes the Path Computation Element Protocol PCEP. PCEP enables the communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) as well as Generalzied MPLS (GMPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.
Stateful pce specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657] and focuses on a model where LSPs are configured on the PCC and control over them is delegated to the PCE. The model of operation where LSPs are initiated from the PCE is described in [I-D.ietf-pce-pce-initiated-lsp].
This document introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to stateful PCE (active and passive modes) and stateless PCE. The associations could be created dynamically and conveyed to a PCEP peer within PCEP, or it could be configured by an operator on the PCEP peers. Refer Section 3.2 for more details.
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer.
This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation.
This document uses the following terms defined in [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, LSP State Report, LSP Update Request.
This document uses the following terms defined in [I-D.ietf-pce-pce-initiated-lsp]: PCE-initiated LSP, LSP Initiate.
The following term is defined in this document:
Association Timeout Interval: when a PCEP session is terminated, a PCC waits for this time period before deleting associations created by the PCEP peer.
Stateful PCE provides the ability to update existing LSPs and to instantiate new ones. To enable support for PCE-controlled make-before-break and for protection, there is a need to define associations between LSPs. For example, the association between the original and the re-optimized path in the make-before break scenario, or between the working and protection path in end-to-end protection. Another use for LSP grouping is for applying a common set of configuration parameters or behaviors to a set of LSPs.
For a stateless PCE, it might be useful to associate a path computation request to an association group, thus enabling it to associate a common set of policy, configuration parameters or behaviors with the request.
Some associations could be created dynamically, such as association between the working and protections LSPs of a tunnel. Whereas some association could be created by the operator manually, such as policy based association, where the LSP could join an operator-configured existing association.
Rather than creating separate mechanisms for each use case, this draft defines a generic mechanism that can be reused as needed.
LSPs are associated with other LSPs with which they interact by adding them to a common association group. Association groups as defined in this document can be applied to LSPs originating at the same head end or different head ends.
Some associations could be created dynamically by a PCEP speaker and the associations (along with the set of LSPs) are conveyed to a PCEP peer. Whereas, some associations are configured by the operator on the PCEP peers involved before hand, a PCEP speaker then could ask for a LSP to join the operator-configured association. Usage of dynamic and configured is usually dependent on the type of the association.
For the operator-configured association, the association identifier, type, as well as the association source IP address is manually configured by the operator. In case of dynamic association, the association identifier is allocated dynamically by the PCEP speaker.
The dynamically created association can be reported to the PCEP peer via the PCEP messages as per the stateful extensions. While the operator-configured association are known to the PCEP peer before hand, a PCEP peer could ask for a LSP to join the operator-configured association via the stateful PCEP messages.
The association are properties of the LSP and thus could be stored in the LSP state database. The dynamic association exist as long as the LSP state. In case of PCEP session termination, the LSP state clean up SHOULD also take care of associations.
Multiple types of associations can exist, each with their own association identifier space. The definition of the different association types and their behaviors is outside the scope of this document. The establishment and removal of the association relationship can be done on a per LSP basis. An LSP may join multiple association groups, of different or of the same association type.
Some association types are dynamic, some are operator-configured and some could be both. For the association types that could be dynamic and operator-configured, it is necessary to configure a range of association identifiers that are marked for operator-configured associations to avoid any association identifier clash.
A range of association identifier for each association-type are kept for the operator-configured associations. Dynamic associations MUST NOT use the association identifier from this range.
This range needs to be communicated to a PCEP peer in the Open Message. A new TLV is defined in this specification for this purpose (Section 4).
This section defines PCEP extension to support the advertisement of the Operator-configured Association Range used for an association-type.
A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried within an OPEN object. This way, during PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the Operator-configured Association Range for an association type.
The PCEP OP-CONF-ASSOC-RANGE TLV is optional. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length field defines the length of the value portion in octets.
The PCEP OP-CONF-ASSOC-RANGE TLV has the following format:
TYPE: TBD
LENGTH: N * 8 (where N is the number of association types)
VALUE:
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 | Assoc-type #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Assoc-ID #1 | Range #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Assoc-type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Assoc-ID #N | Range #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The OP-CONF-ASSOC-RANGE TLV format
The Value portion includes the following fields, repeated for each association type:
A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise the Operator-configured Association Range for an association type. The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message).
As specified in [RFC5440], a PCEP peer that does not recognize the OP-CONF-ASSOC-RANGE TLV will silently ignore it.
The Operator-configured Association Range SHOULD be included for each association type that could be both dynamic and operator-configured. For associations that are only dynamic or only operator-configured can be skipped, in which case the full range of association identifier is considered dynamic or operator-configured respectively. Each association type (that are defined in separate documents) can specify the default value for the operator-configured association range for their respective association type.
The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be interpreted as an absence of explicit Operator-configured Association Range at the PCEP peer. In which case, the default behavior as per each association type would be applied.
Association groups and their memberships are defined using a new ASSOCIATION object.
ASSOCIATION Object-Class is to be assigned by IANA (TBD).
ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in Figure 2:
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 | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv4 ASSOCIATION Object format
ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The IPv6 ASSOCIATION Object format
Reserved (2-byte): MUST be set to 0 and ignored upon receipt.
Flags (2-byte): The following flags are currently defined:
Association type (2-byte): the association type (for example protection). The association type are defined in separate documents.
Association ID (2-byte): the identifier of the association group. When combined with Type and Association Source, this value uniquely identifies an association group. The value 0xffff and 0x0 are reserved. The value 0xffff is used to indicate all association groups.
Association Source: 4 or 16 bytes - An IPv4 or IPv6 address. This could be the IP address of the PCEP speaker that created a dynamic association, an operator configured IP address, or an IP address selected as per the local policy. The value such as 0.0.0.0 or ::/128 are acceptable.
Optional TLVs: The optional TLVs follow the PCEP TLV format of [RFC5440]. This document defines two optional TLVs. Other documents can define more TLVs.
The Global Association Source TLV is an optional TLV for use in the Association Object.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Global Association Source TLV format
Type: To be allocated by IANA.
Length: Fixed value of 4 bytes.
Global Association Source: as defined in [RFC6780].
The Extended Association ID TLV is an optional TLV except for Operator-configured Associations, for use in the Association Object.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Association ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Extended Association ID TLV format
Type: To be allocated by IANA.
Length: variable.
Extended Association ID: as defined in [RFC6780].
The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path Computation Update (PCUpd), Path Computation Report (PCRpt) and Path Computation Initiate (PCInitiate) messages.
When carried in PCRpt message, it is used to report the association group membership information pertaining to a LSP to a stateful PCE. It can also be used to remove an LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object. Unless, a PCE wants to delete an association from an LSP, it does not need to carry the ASSOCIATION object in future messages.
The PCRpt message is defined in [I-D.ietf-pce-stateful-pce] and updated as below:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<association-list>]
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>]
When an LSP is delegated to a stateful PCE, the stateful PCE can initiate a new association group for this LSP, or associate it with one or more existing association groups. This is done by including the ASSOCIATION Object in a PCUpd message. A stateful PCE can also remove a delegated LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object.
The PCUpd message is defined in [I-D.ietf-pce-stateful-pce] and updated as below:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
[<association-list>]
<path>
Where:
<path>::= <intended-path><intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>]
A PCE initiating a new LSP, can include the association group information. This is done by including the ASSOCIATION Object in a PCInitiate message. The PCInitiate message is defined in [I-D.ietf-pce-pce-initiated-lsp] and updated as below:
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<association-list>]
[<attribute-list>]
Where:
<association-list> ::= <ASSOCIATION> [<association-list>]
In case of passive stateful or stateless PCE, the ASSOCIATION Object is OPTIONAL and MAY be carried in the Path Computation Request (PCReq) message.
When carried in a PCReq message, the ASSOCIATION Object is used to associate the path computation request to an association group. The association (and the other LSPs) should be known to the PCE before hand. These could be operator-configured or dynamically learned before. The R flag in ASSOCIATION object within PCReq message MUST be set to 0 while sending and ignored on receipt.
The PCReq message is defined in [RFC5440] and updated in [I-D.ietf-pce-stateful-pce], it is further updated below for association:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<svec-list>::= <SVEC>[<svec-list>]
<request-list>::= <request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<association-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
Where:
<association-list> ::= <ASSOCIATION> [<association-list>]
Note that LSP object MAY be present for the passive stateful PCE mode.
Association groups can be operator-configured on the necessary PCC and PCE. In addition, a PCC or a PCE can create association groups dynamically. The PCEP speaker can reports the association to its peer via PCEP messages. If a PCEP speaker does not recognize the ASSOCIATION object, it MUST return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440]. If a PCEP speaker understand the ASSOCIATION object but does not support the association-type, it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 1 "Association-type is not supported". On receiving a PCEP message with ASSOCIATION, if a PCEP speaker finds that too many LSPs belong to the association group, it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 2 "Too many LSPs in the association group". If a PCEP speaker cannot handle a new associations, it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 3 "Too many association groups". These number MAY be set by operator or decided based on a local policy.
If a PCE speaker receives ASSOCIATION in PCReq message, and the association information is not known (association is not configured, or created dynamically, or learned from a PCEP peer), it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 4 "Association unknown". If the association information received from the peer does not match with the local operator configured information, it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 5 "Operator-configured association information mismatch". On receiving association information that does not match with the association information previously received about the same association from a peer, it MUST return a PCErr message with Error-Type TBD "Association Error" and Error-Value 6 "Association information mismatch". If a PCE peer is unwilling or unable to process the ASSOCIATION object, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440].
The association information is cleared along with the LSP state information as per the [I-D.ietf-pce-stateful-pce]. When a PCEP session is terminated, after expiry of State Timeout Interval at PCC, the LSP state associated with that PCEP session is reverted to operator-defined default parameters or behaviors. Same procedure is also followed for the association information. On session termination at the PCE, when the LSP state reported by PCC is cleared, the association information is also cleared. Where there are no LSPs in a association group, the association is considered to be deleted.
In case the LSP is delegated to another PCE on session failure, the association information set by the PCE remains intact, unless updated by the new PCE.
Upon LSP delegation revocation, the PCC MAY clear the association created by the PCE, but in order to avoid traffic loss, it can perform this in a make-before-break fashion, which is the same as what is defined in [I-D.ietf-pce-stateful-pce] for handling LSP state cleanup.
The "PCEP Parameters" registry contains a subregistry "PCEP Objects". This document request IANA to allocate the values from this registry.
| Object-Class Value | Name | Reference |
|---|---|---|
| TBD | Association | [This I-D] |
| Object-Type | ||
| 0: Reserved | ||
| 1: IPv4 | ||
| 2: IPv6 |
IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows:
| Value | Meaning | Reference |
|---|---|---|
| TBD | Operator-configured Association Range | [This I-D] |
| TBD | Global Association Source | [This I-D] |
| TBD | Extended Association Id | [This I-D] |
This document requests IANA to create a subregistry of the "PCEP Parameters" for the bits carried in the Flags field of the ASSOCIATION object. The subregistry is called "ASSOCIATION Flags Field".
The field contains 12 bits numbered from bit 0 as the most significant bit.
| Bit | Name | Description | Reference |
|---|---|---|---|
| 15 | R | Removal | [This I-D] |
This document requests IANA to create a subregistry of the "PCEP Parameters" for the Association Type field of the the ASSOCIATION object. The subregistry is called "ASSOCIATION Type Field".
There are no association type specified in this document, future document should request the assignment of association types from this subregistry.
IANA is requested to allocate new error values within the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows:
Error-Type Meaning
TBD Association Error [This I-D]
Error-value=1:
Association-type is not supported
Error-value=2:
Too many LSPs in the association group
Error-value=3:
Too many association groups
Error-value=4:
Association unknown
Error-value=5:
Operator-configured association
information mismatch
Error-value=6:
Association information mismatch
The security considerations described in [I-D.ietf-pce-stateful-pce] and [RFC5440] apply to the extensions described in this document as well. Additional considerations related to a malicious PCEP speaker are introduced, as associations could be spoofed and could be used as an attack vector. An attacker could report too many associations in an attempt to load the PCEP peer. The PCEP peer responds with PCErr as described in Section 5.3. An attacker could impact LSP operations by creating bogus associations. Further, association information could provides an adversary with the opportunity to eavesdrop on the relationship between the LSPs. Thus securing the PCEP session using Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED.
All manageability requirements and considerations listed in [RFC5440] and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
A PCE or PCC implementation MUST allow operator-configured associations as described in this document. The identifier MUST be from the operator-configured identifier range Section 3.3.
An implementation SHOULD allow the operator to view the associations configured or created dynamically. Further implementation SHOULD allow to view associations reported by each peer, and the current set of LSPs in the association . To serve this purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to include association information.
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [I-D.ietf-pce-stateful-pce].
Mechanisms defined in this document do not imply any new requirements on other protocols.
Mechanisms defined in [RFC5440] and [I-D.ietf-pce-stateful-pce] also apply to PCEP extensions defined in this document.
We would like to thank Yuji Kamite and Joshua George for their contributions to this document. Also thanks to Venugopal Reddy, Cyril Margaria and Rakesh Gandhi for their useful comments.
Stephane Litkowski Orange Email: stephane.litkowski@orange.com Xian Zhang Huawei Technologies F3-1-B RnD Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Email: zhang.xian@huawei.com Mustapha Aissaoui Nokia Email: mustapha.aissaoui@nokia.com
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009. |
| [RFC6780] | Berger, L., Le Faucheur, F. and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012. |
| [I-D.ietf-pce-stateful-pce] | Crabbe, E., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-21, June 2017. |
| [I-D.ietf-pce-pce-initiated-lsp] | Crabbe, E., Minei, I., Sivabalan, S. and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Internet-Draft draft-ietf-pce-pce-initiated-lsp-10, June 2017. |
| [RFC4657] | Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006. |
| [RFC7525] | Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015. |
| [RFC8051] | Zhang, X. and I. Minei, "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017. |
| [I-D.ietf-pce-pceps] | Lopez, D., Dios, O., Wu, Q. and D. Dhody, "Secure Transport for PCEP", Internet-Draft draft-ietf-pce-pceps-14, May 2017. |
| [I-D.ietf-pce-pcep-yang] | Dhody, D., Hardwick, J., Beeram, V. and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Internet-Draft draft-ietf-pce-pcep-yang-02, March 2017. |