draft-ietf-pce-rfc6006bis-04.txt   rfc8306.txt 
PCE Working Group Q. Zhao Internet Engineering Task Force (IETF) Q. Zhao
Internet-Draft D. Dhody, Ed. Request for Comments: 8306 D. Dhody, Ed.
Intended status: Standards Track R. Palleti Obsoletes: 6006 R. Palleti
Obsoletes: 6006 (if approved) Huawei Technology Category: Standards Track Huawei Technologies
Expires: March 30, 2018 D. King ISSN: 2070-1721 D. King
Old Dog Consulting Old Dog Consulting
September 26, 2017 November 2017
Extensions to Extensions to
the Path Computation Element Communication Protocol (PCEP) the Path Computation Element Communication Protocol (PCEP)
for Point-to-Multipoint Traffic Engineering Label Switched Paths for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-rfc6006bis-04 Abstract
Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the identified as an appropriate technology for the determination of the
paths of point-to-multipoint (P2MP) TE LSPs. paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE communication Protocol This document describes extensions to the PCE Communication Protocol
(PCEP) to handle requests and responses for the computation of paths (PCEP) to handle requests and responses for the computation of paths
for P2MP TE LSPs. for P2MP TE LSPs.
This document obsoletes RFC 6006. This document obsoletes RFC 6006.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 30, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8306.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 34 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology ................................................5
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements . . . . . . . . . . . . . . 5 2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 6 3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 6 3.1. P2MP Capability Advertisement ..............................7
3.1.1. P2MP Computation TLV in the Existing PCE Discovery 3.1.1. IGP Extensions for P2MP Capability Advertisement ....7
Protocol . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Open Message Extension ..............................7
3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 8 3.2. Efficient Presentation of P2MP LSPs ........................8
3.2. Efficient Presentation of P2MP LSPs . . . . . . . . . . . 8 3.3. P2MP Path Computation Request/Reply Message Extensions .....9
3.3. P2MP Path Computation Request/Reply Message Extensions . . 9 3.3.1. The Extension of the RP Object ......................9
3.3.1. The Extension of the RP Object . . . . . . . . . . . . 9 3.3.2. The P2MP END-POINTS Object .........................11
3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 10 3.4. Request Message Format ....................................13
3.4. Request Message Format . . . . . . . . . . . . . . . . . . 13 3.5. Reply Message Format ......................................15
3.5. Reply Message Format . . . . . . . . . . . . . . . . . . . 14 3.6. P2MP Objective Functions and Metric Types .................16
3.6. P2MP Objective Functions and Metric Types . . . . . . . . 15 3.6.1. Objective Functions ................................16
3.6.1. New Objective Functions . . . . . . . . . . . . . . . 15 3.6.2. METRIC Object-Type Values ..........................17
3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 16 3.7. Non-Support of P2MP Path Computation ......................17
3.7. Non-Support of P2MP Path Computation . . . . . . . . . . . 16 3.8. Non-Support by Back-Level PCE Implementations .............17
3.8. Non-Support by Back-Level PCE Implementations . . . . . . 18 3.9. P2MP TE Path Reoptimization Request .......................17
3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . . 18 3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........18
3.10. Adding and Pruning Leaves to/from the P2MP Tree . . . . . 19 3.11. Discovering Branch Nodes .................................22
3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . 22 3.11.1. Branch Node Object ................................22
3.11.1. Branch Node Object . . . . . . . . . . . . . . . . . 22 3.12. Synchronization of P2MP TE Path Computation Requests .....22
3.12. Synchronization of P2MP TE Path Computation Requests . . 22 3.13. Request and Response Fragmentation .......................23
3.13. Request and Response Fragmentation . . . . . . . . . . . 23 3.13.1. Request Fragmentation Procedure ...................24
3.13.1. Request Fragmentation Procedure . . . . . . . . . . . 24 3.13.2. Response Fragmentation Procedure ..................24
3.13.2. Response Fragmentation Procedure . . . . . . . . . . 24 3.13.3. Fragmentation Example .............................24
3.13.3. Fragmentation Examples . . . . . . . . . . . . . . . 24 3.14. UNREACH-DESTINATION Object ...............................25
3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . 25 3.15. P2MP PCEP-ERROR Objects and Types ........................27
3.15. P2MP PCEP-ERROR Objects and Types . . . . . . . . . . . . 26 3.16. PCEP NO-PATH Indicator ...................................28
3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . 27 4. Manageability Considerations ...................................28
4. Manageability Considerations . . . . . . . . . . . . . . . . . 28 4.1. Control of Function and Policy ............................28
4.1. Control of Function and Policy . . . . . . . . . . . . . . 28 4.2. Information and Data Models ...............................28
4.2. Information and Data Models . . . . . . . . . . . . . . . 28 4.3. Liveness Detection and Monitoring .........................29
4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 28 4.4. Verifying Correct Operation ...............................29
4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 29 4.5. Requirements for Other Protocols and Functional
4.5. Requirements for Other Protocols and Functional Components ................................................29
Components . . . . . . . . . . . . . . . . . . . . . . . . 30 4.6. Impact on Network Operation ...............................29
4.6. Impact on Network Operation . . . . . . . . . . . . . . . 30 5. Security Considerations ........................................30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations ............................................31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6.1. PCEP TLV Type Indicators ..................................31
6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 31 6.2. Request Parameter Bit Flags ...............................31
6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . . 31 6.3. Objective Functions .......................................31
6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 31 6.4. METRIC Object-Type Values .................................32
6.4. Metric Object Types . . . . . . . . . . . . . . . . . . . 32 6.5. PCEP Objects ..............................................32
6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 32 6.6. PCEP-ERROR Objects and Types ..............................34
6.6. PCEP-ERROR Objects and Types . . . . . . . . . . . . . . . 33 6.7. PCEP NO-PATH Indicator ....................................35
6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 34 6.8. SVEC Object Flag ..........................................35
6.8. SVEC Object Flag . . . . . . . . . . . . . . . . . . . . . 34 6.9. OSPF PCE Capability Flag ..................................35
6.9. OSPF PCE Capability Flag . . . . . . . . . . . . . . . . . 35 7. References .....................................................36
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Normative References ......................................36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2. Informative References ....................................37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 Appendix A. Summary of Changes from RFC 6006 ......................39
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 Appendix A.1. RBNF Changes from RFC 6006 ..........................39
Appendix A. Summary of the all Changes from RFC 6006 . . . . . . . 40 Acknowledgements ..................................................41
Appendix A.1 RBNF Changes from RFC 6006 . . . . . . . . . . . . . 40 Contributors ......................................................42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses ................................................43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) as defined in [RFC4655] is an
that is capable of computing a network path or route based on a entity that is capable of computing a network path or route based on
network graph, and applying computational constraints. A Path a network graph and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. computed.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The PCE has been identified as a suitable application for the The PCE has been identified as a suitable application for the
computation of paths for P2MP TE LSPs [RFC5671]. computation of paths for P2MP TE LSPs [RFC5671].
The PCE communication Protocol (PCEP) is designed as a communication The PCE Communication Protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [RFC5440]. However, that computations and is defined in [RFC5440]. However, that
specification does not provide a mechanism to request path specification does not provide a mechanism to request path
computation of P2MP TE LSPs. computation of P2MP TE LSPs.
A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.
These S2L sub-LSPs are set up between ingress and egress Label These S2L sub-LSPs are set up between ingress and egress Label
Switching Routers (LSRs) and are appropriately overlaid to construct Switching Routers (LSRs) and are appropriately overlaid to construct
a P2MP TE LSP. During path computation, the P2MP TE LSP may be a P2MP TE LSP. During path computation, the P2MP TE LSP may be
determined as a set of S2L sub-LSPs that are computed separately and determined as a set of S2L sub-LSPs that are computed separately and
combined to give the path of the P2MP LSP, or the entire P2MP TE LSP combined to give the path of the P2MP LSP, or the entire P2MP TE LSP
may be determined as a P2MP tree in a single computation. may be determined as a P2MP tree in a single computation.
This document relies on the mechanisms of PCEP to request path This document relies on the mechanisms of PCEP to request path
computation for P2MP TE LSPs. One path computation request message computation for P2MP TE LSPs. One Path Computation Request message
from a PCC may request the computation of the whole P2MP TE LSP, or from a PCC may request the computation of the whole P2MP TE LSP, or
the request may be limited to a sub-set of the S2L sub-LSPs. In the the request may be limited to a subset of the S2L sub-LSPs. In the
extreme case, the PCC may request the S2L sub-LSPs to be computed extreme case, the PCC may request the S2L sub-LSPs to be computed
individually with it being the PCC's responsibility to decide whether individually; the PCC is responsible for deciding whether to signal
to signal individual S2L sub-LSPs or combine the computation results individual S2L sub-LSPs or combine the computation results to signal
to signal the entire P2MP TE LSP. Hence the PCC may use one path the entire P2MP TE LSP. Hence, the PCC may use one Path Computation
computation request message or may split the request across multiple Request message or may split the request across multiple path
path computation messages. computation messages.
This document obsoletes [RFC6006] and incorporates all outstanding This document obsoletes [RFC6006] and incorporates the following
Errata: errata:
o Erratum with IDs: 3819, 3830, 3836, 4867, 4868 and 4956. o Erratum IDs 3819, 3830, 3836, 4867, and 4868 for [RFC6006]
o Erratum ID 4956 for [RFC5440]
All changes from [RFC6006] are listed in Appendix A. All changes from [RFC6006] are listed in Appendix A.
1.1. Terminology 1.1. Terminology
Terminology used in this document: Terminology used in this document:
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
LSR: Label Switching Router. LSR: Label Switching Router.
OF: Objective Function: A set of one or more optimization criteria OF: Objective Function. A set of one or more optimization criteria
used for the computation of a single path (e.g., path cost used for the computation of a single path (e.g., path cost
minimization), or for the synchronized computation of a set of minimization) or for the synchronized computation of a set of
paths (e.g., aggregate bandwidth consumption minimization). paths (e.g., aggregate bandwidth consumption minimization).
P2MP: Point-to-Multipoint. P2MP: Point-to-Multipoint.
P2P: Point-to-Point. P2P: Point-to-Point.
This document also uses the terminology defined in [RFC4655], This document also uses the terminology defined in [RFC4655],
[RFC4875], and [RFC5440]. [RFC4875], and [RFC5440].
1.2. Requirements Language 1.2. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. PCC-PCE Communication Requirements 2. PCC-PCE Communication Requirements
This section summarizes the PCC-PCE communication requirements for This section summarizes the PCC-PCE communication requirements as met
P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system by the protocol extension specified in this document for P2MP MPLS-TE
corresponds to the requirement numbers used in [RFC5862]. LSPs. The numbering system in the list below corresponds to the
requirement numbers (e.g., R1, R2) used in [RFC5862].
1. The PCC MUST be able to specify that the request is a P2MP path 1. The PCC MUST be able to specify that the request is a P2MP path
computation request. computation request.
2. The PCC MUST be able to specify that objective functions are to 2. The PCC MUST be able to specify that objective functions are to
be applied to the P2MP path computation request. be applied to the P2MP path computation request.
3. The PCE MUST have the capability to reject a P2MP path request 3. The PCE MUST have the capability to reject a P2MP path
and indicate non-support of P2MP path computation. computation request and indicate non-support of P2MP path
computation.
4. The PCE MUST provide an indication of non-support of P2MP path 4. The PCE MUST provide an indication of non-support of P2MP path
computation by back-level PCE implementations. computation by back-level PCE implementations.
5. A P2MP path computation request MUST be able to list multiple 5. A P2MP path computation request MUST be able to list multiple
destinations. destinations.
6. A P2MP path computation response MUST be able to carry the path 6. A P2MP path computation response MUST be able to carry the path
of a P2MP LSP. of a P2MP LSP.
skipping to change at page 6, line 41 skipping to change at page 7, line 7
P2MP path. P2MP path.
3. Protocol Procedures and Extensions 3. Protocol Procedures and Extensions
The following section describes the protocol extensions required to The following section describes the protocol extensions required to
satisfy the requirements specified in Section 2 ("PCC-PCE satisfy the requirements specified in Section 2 ("PCC-PCE
Communication Requirements") of this document. Communication Requirements") of this document.
3.1. P2MP Capability Advertisement 3.1. P2MP Capability Advertisement
3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 3.1.1. IGP Extensions for P2MP Capability Advertisement
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF
Router Information Link State Advertisement (LSA) defined in Router Information Link State Advertisement (LSA) as defined in
[RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088]
specifies that no new sub-TLVs may be added to the PCED TLV. This specifies that no new sub-TLVs may be added to the PCED TLV. This
document defines a new flag in the OSPF PCE Capability Flags to document defines a flag in the OSPF PCE Capability Flags to indicate
indicate the capability of P2MP computation. the capability of P2MP computation.
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
Discovery using IS-IS. This document will use the same flag discovery using IS-IS. This document will use the same flag for the
requested for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate the
indicate the capability of P2MP computation. capability of P2MP computation.
The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag
is documented in Section 6.9 ("OSPF PCE Capability Flag") of this is documented in Section 6.9 ("OSPF PCE Capability Flag") of this
document. document.
PCEs wishing to advertise that they support P2MP path computation PCEs wishing to advertise that they support P2MP path computation
would set the bit (10) accordingly. PCCs that do not understand this would set the bit (10) accordingly. PCCs that do not understand this
bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not
support P2MP will leave the bit clear (per the default behavior support P2MP will leave the bit clear (per the default behavior
defined in [RFC5088] and [RFC5089]). defined in [RFC5088] and [RFC5089]).
PCEs that set the bit to indicate support of P2MP path computation PCEs that set the bit to indicate support of P2MP path computation
MUST follow the procedures in Section 3.3.2 ("The New P2MP END-POINTS MUST follow the procedures in Section 3.3.2 ("The P2MP END-POINTS
Object") to further qualify the level of support. Object") to further qualify the level of support.
3.1.2. Open Message Extension 3.1.2. Open Message Extension
Based on the Capabilities Exchange requirement described in Based on the Capabilities Exchange requirement described in
[RFC5862], if a PCE does not advertise its P2MP capability during [RFC5862], if a PCE does not advertise its P2MP capability during
discovery, PCEP should be used to allow a PCC to discover, during the discovery, PCEP should be used to allow a PCC to discover, during the
Open Message Exchange, which PCEs are capable of supporting P2MP path Open Message Exchange, which PCEs are capable of supporting P2MP path
computation. computation.
To satisfy this requirement, we extend the PCEP OPEN object by To satisfy this requirement, we extend the PCEP OPEN object by
defining a new optional TLV to indicate the PCE's capability to defining an optional TLV to indicate the PCE's capability to perform
perform P2MP path computations. P2MP path computations.
IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub- IANA has allocated value 6 from the "PCEP TLV Type Indicators"
registry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). subregistry, as documented in Section 6.1 ("PCEP TLV Type
The description is "P2MP capable", and the length value is 2 bytes. Indicators"). The description is "P2MP capable", and the length
The value field is set to default value 0. value is 2 bytes. The value field is set to default value 0.
The inclusion of this TLV in an OPEN object indicates that the sender The inclusion of this TLV in an OPEN object indicates that the sender
can perform P2MP path computations. can perform P2MP path computations.
The capability TLV is meaningful only for a PCE, so it will typically The capability TLV is meaningful only for a PCE, so it will typically
appear only in one of the two Open messages during PCE session appear only in one of the two Open messages during PCE session
establishment. However, in case of PCE cooperation (e.g., establishment. However, in the case of PCE cooperation (e.g.,
inter-domain), when a PCE behaving as a PCC initiates a PCE session inter-domain), when a PCE behaving as a PCC initiates a PCE session
it SHOULD also indicate its path computation capabilities. it SHOULD also indicate its path computation capabilities.
3.2. Efficient Presentation of P2MP LSPs 3.2. Efficient Presentation of P2MP LSPs
When specifying additional leaves, or optimizing existing P2MP TE When specifying additional leaves or when optimizing existing P2MP TE
LSPs as specified in [RFC5862], it may be necessary to pass existing LSPs as specified in [RFC5862], it may be necessary to pass existing
P2MP LSP route information between the PCC and PCE in the request and P2MP LSP route information between the PCC and PCE in the request and
reply messages. In each of these scenarios, we need new path objects reply messages. In each of these scenarios, we need path objects for
for efficiently passing the existing P2MP LSP between the PCE and efficiently passing the existing P2MP LSP between the PCE and PCC.
PCC.
We specify the use of the Resource Reservation Protocol Traffic We specify the use of the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to
encode the explicit route of a TE LSP through the network. PCEP ERO encode the explicit route of a TE LSP through the network. PCEP ERO
sub-object types correspond to RSVP-TE ERO sub-object types. The sub-object types correspond to RSVP-TE ERO sub-object types. The
format and content of the ERO object are defined in [RFC3209] and format and content of the ERO are defined in [RFC3209] and [RFC3473].
[RFC3473].
The Secondary Explicit Route Object (SERO) is used to specify the The Secondary Explicit Route Object (SERO) is used to specify the
explicit route of a S2L sub-LSP. The path of each subsequent S2L explicit route of an S2L sub-LSP. The path of each subsequent S2L
sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO.
The format of the SERO is the same as an ERO defined in [RFC3209] and The format of the SERO is the same as the format of an ERO as defined
[RFC3473]. in [RFC3209] and [RFC3473].
The Secondary Record Route Object (SRRO) is used to record the The Secondary Record Route Object (SRRO) is used to record the
explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the
same as the SRRO defined in [RFC4873]. same as the class of the SRRO as defined in [RFC4873].
The SERO and SRRO are used to report the route of an existing TE LSP The SERO and SRRO are used to report the route of an existing TE LSP
for which a reoptimization is desired. The format and content of the for which a reoptimization is desired. The format and content of the
SERO and SRRO are defined in [RFC4875]. SERO and SRRO are defined in [RFC4875].
A new PCEP object class and type are requested for SERO and SRRO. PCEP Object-Class and Object-Type values for the SERO and SRRO have
been assigned:
Object-Class Value 29 Object-Class Value 29
Name SERO Name SERO
Object-Type 0: Reserved Object-Type 0: Reserved
1: SERO 1: SERO
2-15: Unassigned 2-15: Unassigned
Reference [This I-D] Reference RFC 8306
Object-Class Value 30 Object-Class Value 30
Name SRRO Name SRRO
Object-Type 0: Reserved Object-Type 0: Reserved
1: SRRO 1: SRRO
2-15: Unassigned 2-15: Unassigned
Reference [This I-D] Reference RFC 8306
The IANA assignment is documented in Section 6.5 ("PCEP Objects"). The IANA assignments are documented in Section 6.5 ("PCEP Objects").
Since the explicit path is available for immediate signaling by the Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO. and fields in this object are identical to those defined for the ERO.
3.3. P2MP Path Computation Request/Reply Message Extensions 3.3. P2MP Path Computation Request/Reply Message Extensions
This document extends the existing P2P RP (Request Parameters) object This document extends the existing P2P RP (Request Parameters) object
so that a PCC can signal a P2MP path computation request to the PCE so that a PCC can signal a P2MP path computation request to the PCE
receiving the PCEP request. The END-POINTS object is also extended receiving the PCEP request. The END-POINTS object is also extended
to improve the efficiency of the message exchange between PCC and PCE to improve the efficiency of the message exchange between the PCC and
in the case of P2MP path computation. PCE in the case of P2MP path computation.
3.3.1. The Extension of the RP Object 3.3.1. The Extension of the RP Object
The PCE path computation request and reply messages will need the The PCE path computation request and reply messages will need the
following additional parameters to indicate to the receiving PCE that following additional parameters to indicate to the receiving PCE
the request and reply messages have been fragmented across multiple (1) that the request and reply messages have been fragmented across
messages, that they have been requested for a P2MP path, and whether multiple messages, (2) that they have been requested for a P2MP path,
the route is represented in the compressed or uncompressed format. and (3) whether the route is represented in the compressed or
uncompressed format.
This document adds the following flags to the RP Object: This document adds the following flags to the RP object:
The F-bit is added to the flag bits of the RP object to indicate to The F-bit is added to the flag bits of the RP object to indicate to
the receiver that the request is part of a fragmented request, or is the receiver that the request is part of a fragmented request or
not a fragmented request. is not a fragmented request.
o F (RP fragmentation bit - 1 bit): o F (RP fragmentation bit - 1 bit):
0: This indicates that the RP is not fragmented or it is the last 0: This indicates that the RP is not fragmented or it is the last
piece of the fragmented RP. piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not the 1: This indicates that the RP is fragmented and this is not the
last piece of the fragmented RP. The receiver needs to wait last piece of the fragmented RP. The receiver needs to wait
for additional fragments until it receives an RP with the same for additional fragments until it receives an RP with the same
RP-ID and with the F-bit set to 0. RP-ID and with the F-bit set to 0.
The N-bit is added in the flag bits field of the RP object to signal The N-bit is added in the flag bits field of the RP object to signal
the receiver of the message that the request/reply is for P2MP or is the receiver of the message that the request/reply is for P2MP or
not for P2MP. is not for P2MP.
o N (P2MP bit - 1 bit): o N (P2MP bit - 1 bit):
0: This indicates that this is not a PCReq or PCRep message for 0: This indicates that this is not a Path Computation Request
P2MP. (PCReq) or Path Computation Reply (PCRep) message for P2MP.
1: This indicates that this is a PCReq or PCRep message for P2MP. 1: This indicates that this is a PCReq or PCRep message for P2MP.
The E-bit is added in the flag bits field of the RP object to signal The E-bit is added in the flag bits field of the RP object to signal
the receiver of the message that the route is in the compressed the receiver of the message that the route is in the compressed
format or is not in the compressed format. By default, the path format or is not in the compressed format. By default, the path
returned by the PCE SHOULD use the compressed format. returned by the PCE SHOULD use the compressed format.
o E (ERO-compression bit - 1 bit): o E (ERO-compression bit - 1 bit):
0: This indicates that the route is not in the compressed format. 0: This indicates that the route is not in the compressed format.
1: This indicates that the route is in the compressed format. 1: This indicates that the route is in the compressed format.
The IANA assignment is documented in Section 6.2 ("Request Parameter The IANA assignments are documented in Section 6.2 ("Request
Bit Flags") of this document. Parameter Bit Flags") of this document.
3.3.2. The New P2MP END-POINTS Object 3.3.2. The P2MP END-POINTS Object
The END-POINTS object is used in a PCReq message to specify the The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the path for source IP address and the destination IP address of the path for
which a path computation is requested. To represent the end points which a path computation is requested. To represent the end points
for a P2MP path efficiently, we define two new types of END-POINTS for a P2MP path efficiently, we define two types of END-POINTS
objects for the P2MP path: objects for the P2MP path:
o Old leaves whose path can be modified/reoptimized; o Old leaves whose path can be modified/reoptimized.
o Old leaves whose path must be left unchanged. o Old leaves whose path must be left unchanged.
With the new END-POINTS object, the PCE path computation request With the P2MP END-POINTS object, the PCE Path Computation Request
message is expanded in a way that allows a single request message to message is expanded in a way that allows a single request message to
list multiple destinations. list multiple destinations.
In total, there are now 4 possible types of leaves in a P2MP request: In total, there are now four possible types of leaves in a
P2MP request:
o New leaves to add (leaf type = 1) o New leaves to add (leaf type = 1)
o Old leaves to remove (leaf type = 2) o Old leaves to remove (leaf type = 2)
o Old leaves whose path can be modified/reoptimized (leaf type = 3) o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o Old leaves whose path must be left unchanged (leaf type = 4) o Old leaves whose path must be left unchanged (leaf type = 4)
A given END-POINTS object gathers the leaves of a given type. The A given END-POINTS object gathers the leaves of a given type. The
type of leaf in a given END-POINTS object is identified by the END- type of leaf in a given END-POINTS object is identified by the
POINTS object leaf type field. END-POINTS object leaf type field.
Using the new END-POINTS object, the END-POINTS portion of a request Using the P2MP END-POINTS object, the END-POINTS portion of a request
message for the multiple destinations can be reduced by up to 50% for message for the multiple destinations can be reduced by up to 50% for
a P2MP path where a single source address has a very large number of a P2MP path where a single source address has a very large number of
destinations. destinations.
Note that a P2MP path computation request can mix the different types Note that a P2MP path computation request can mix the different types
of leaves by including several END-POINTS objects per RP object as of leaves by including several END-POINTS objects per RP object as
shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format
in Section 3.4 ("Request Message Format"). in Section 3.4 ("Request Message Format").
The format of the new END-POINTS object body for IPv4 (Object-Type 3) The format of the P2MP END-POINTS object body for IPv4
is as follows: (Object-Type 3) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The New P2MP END-POINTS Object Body Format for IPv4 Figure 1: The P2MP END-POINTS Object Body Format for IPv4
The format of the END-POINTS object body for IPv6 (Object-Type 4) is The format of the END-POINTS object body for IPv6 (Object-Type 4) is
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 12, line 47 skipping to change at page 12, line 47
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The New P2MP END-POINTS Object Body Format for IPv6 Figure 2: The P2MP END-POINTS Object Body Format for IPv6
The END-POINTS object body has a variable length. These are The END-POINTS object body has a variable length. These are
multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4
bytes, for IPv6. o multiples of 4 bytes for IPv4
o multiples of 16 bytes, plus 4 bytes, for IPv6
3.4. Request Message Format 3.4. Request Message Format
As per [RFC5440], a Path Computation Request message (also referred As per [RFC5440], a Path Computation Request message (also referred
to as a PCReq message) is a PCEP message sent by a PCC to a PCE to to as a PCReq message) is a PCEP message sent by a PCC to a PCE to
request a path computation. A PCReq message may carry more than one request a path computation. A PCReq message may carry more than one
path computation request. path computation request.
As per [RFC5541], the OF object MAY be carried within a PCReq As per [RFC5541], the OF object MAY be carried within a PCReq
message. If an objective function is to be applied to a set of message. If an objective function is to be applied to a set of
synchronized path computation requests, the OF object MUST be carried synchronized path computation requests, the OF object MUST be carried
just after the corresponding SVEC (Synchronization VECtor) object and just after the corresponding SVEC (Synchronization Vector) object and
MUST NOT be repeated for each elementary request. MUST NOT be repeated for each elementary request.
The PCReq message is encoded as follows using RBNF as defined in The PCReq message is encoded as follows using RBNF as defined in
[RFC5511]. [RFC5511].
Below is the message format for the request message: Below is the message format for the request message:
<PCReq Message>::= <Common Header> <PCReq Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
where: where:
<svec-list>::=<SVEC> <svec-list> ::= <SVEC>
[<OF>] [<OF>]
[<metric-list>] [<metric-list>]
[<svec-list>] [<svec-list>]
<request-list>::=<request>[<request-list>] <request-list> ::= <request>[<request-list>]
<request>::= <RP> <request> ::= <RP>
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<OF>] [<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>|<BNC>] [<IRO>|<BNC>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
where: where:
<end-point-rro-pair-list>::= <end-point-rro-pair-list> ::=
<END-POINTS>[<RRO-List>[<BANDWIDTH>]] <END-POINTS>[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>] [<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>] <RRO-List> ::= (<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list> ::= <METRIC>[<metric-list>]
Figure 3. The Message Format for the Request Message Figure 3: The Message Format for the Request Message
Note that we preserve compatibility with the [RFC5440] definition of Note that we preserve compatibility with the definition of <request>
<request>. At least one instance of <endpoints> MUST be present in provided in [RFC5440]. At least one instance of <END-POINTS> MUST be
this message. present in this message.
We have documented the IANA assignment of additional END-POINTS We have documented the IANA assignment of additional END-POINTS
Object-Types in Section 6.5 ("PCEP Objects") of this document. Object-Type values in Section 6.5 ("PCEP Objects") of this document.
3.5. Reply Message Format 3.5. Reply Message Format
The PCEP Path Computation Reply message (also referred to as a PCRep The PCEP Path Computation Reply message (also referred to as a
message) is a PCEP message sent by a PCE to a requesting PCC in PCRep message) is a PCEP message sent by a PCE to a requesting PCC in
response to a previously received PCReq message. PCEP supports the response to a previously received PCReq message. PCEP supports the
bundling of multiple replies to a set of path computation requests bundling of multiple replies to a set of path computation requests
within a single PCRep message. within a single PCRep message.
The PCRep message is encoded as follows using RBNF as defined in The PCRep message is encoded as follows using RBNF as defined in
[RFC5511]. [RFC5511].
Below is the message format for the reply message: Below is the message format for the reply message:
<PCRep Message>::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
where: where:
<response-list>::=<response>[<response-list>] <response-list> ::= <response>[<response-list>]
<response>::=<RP> <response> ::= <RP>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
[<NO-PATH>] [<NO-PATH>]
[<UNREACH-DESTINATION>] [<UNREACH-DESTINATION>]
[<attribute-list>] [<attribute-list>]
<end-point-path-pair-list>::= <end-point-path-pair-list> ::=
[<END-POINTS>]<path> [<END-POINTS>]<path>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>] <path> ::= (<ERO>|<SERO>) [<path>]
where: where:
<attribute-list>::=[<OF>] <attribute-list> ::= [<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
Figure 4. The Message Format for the Reply Message Figure 4: The Message Format for the Reply Message
The optional END-POINTS object in the reply message is used to The optional END-POINTS object in the reply message is used to
specify which paths are removed, changed, not changed, or added for specify which paths are removed, changed, not changed, or added for
the request. The path is only needed for the end points that are the request. The path is only needed for the end points that are
added or changed. added or changed.
If the E-bit (ERO-Compress bit) was set to 1 in the request, then the If the E-bit (ERO-Compress bit) was set to 1 in the request, then the
path will be formed by an ERO followed by a list of SEROs. path will be formed by an ERO followed by a list of SEROs.
Note that we preserve compatibility with the [RFC5440] definition of Note that we preserve compatibility with the definition of <response>
<response> and the optional <end-point-path-pair-list> and <path>. provided in [RFC5440] and with the optional
<end-point-path-pair-list> and <path>.
3.6. P2MP Objective Functions and Metric Types 3.6. P2MP Objective Functions and Metric Types
3.6.1. New Objective Functions 3.6.1. Objective Functions
Six objective functions have been defined in [RFC5541] for P2P path Six objective functions have been defined in [RFC5541] for P2P path
computation. computation.
This document defines two additional objective functions -- namely, This document defines two additional objective functions -- namely,
SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to SPT (Shortest-Path Tree) and MCT (Minimum-Cost Tree) -- that apply to
P2MP path computation. Hence two new objective function codes have P2MP path computation. Hence, two objective function codes are
to be defined. defined as follows:
The description of the two new objective functions is as follows.
Objective Function Code: 7 Objective Function Code: 7
Name: Shortest Path Tree (SPT) Name: Shortest-Path Tree (SPT)
Description: Minimize the maximum source-to-leaf cost with respect Description: Minimize the maximum source-to-leaf cost with respect
to a specific metric or to the TE metric used as the default to a specific metric or to the TE metric used as the default
metric when the metric is not specified (e.g., TE or IGP metric). metric when the metric is not specified (e.g., TE or IGP metric).
Objective Function Code: 8 Objective Function Code: 8
Name: Minimum Cost Tree (MCT) Name: Minimum-Cost Tree (MCT)
Description: Minimize the total cost of the tree, that is the sum Description: Minimize the total cost of the tree (i.e., the sum of
of the costs of tree links, with respect to a specific metric or the costs of tree links) with respect to a specific metric or to
to the TE metric used as the default metric when the metric is not the TE metric used as the default metric when the metric is not
specified. specified.
Processing these two new objective functions is subject to the rules Processing these two objective functions is subject to the rules
defined in [RFC5541]. defined in [RFC5541].
3.6.2. New Metric Object Types 3.6.2. METRIC Object-Type Values
There are three types defined for the <METRIC> object in [RFC5440] -- There are three types defined for the METRIC object in [RFC5440] --
namely, the IGP metric, the TE metric, and the hop count metric. This namely, the IGP metric, the TE metric, and Hop Counts. This document
document defines three additional types for the <METRIC> object: the defines three additional types for the METRIC object: the P2MP IGP
P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. metric, the P2MP TE metric, and the P2MP hop count metric. They
They encode the sum of the metrics of all links of the tree. We encode the sum of the metrics of all links of the tree. The
propose the following values for these new metric types: following values for these metric types have been assigned; see
Section 6.4.
o P2MP IGP metric: T=8 o P2MP IGP metric: T=8
o P2MP TE metric: T=9 o P2MP TE metric: T=9
o P2MP hop count metric: T=10 o P2MP hop count metric: T=10
3.7. Non-Support of P2MP Path Computation 3.7. Non-Support of P2MP Path Computation
o If a PCE receives a P2MP path request and it understands the P2MP o If a PCE receives a P2MP path computation request and it
flag in the RP object, but the PCE is not capable of P2MP understands the P2MP flag in the RP object, but the PCE is not
computation, the PCE MUST send a PCErr message with a PCEP-ERROR capable of P2MP computation, the PCE MUST send a PCErr message
object and corresponding Error-Value. The request MUST then be with a PCEP-ERROR object and corresponding Error-value. The
cancelled at the PCC. New Error-Types and Error-Values are request MUST then be cancelled at the PCC. The Error-Types and
requested in Section 6 ("IANA Considerations") of this document. Error-values have been assigned; see Section 6 ("IANA
Considerations") of this document.
o If the PCE does not understand the P2MP flag in the RP object, o If the PCE does not understand the P2MP flag in the RP object,
then the PCE MUST send a PCErr message with Error-value=2 then the PCE would send a PCErr message with Error-Type=2
(capability not supported). (Capability not supported) as per [RFC5440].
3.8. Non-Support by Back-Level PCE Implementations 3.8. Non-Support by Back-Level PCE Implementations
If a PCE receives a P2MP request and the PCE does not understand the If a PCE receives a P2MP request and the PCE does not understand the
P2MP flag in the RP object, and therefore the PCEP P2MP extensions, P2MP flag in the RP object, and therefore the PCEP P2MP extensions,
then the PCE SHOULD reject the request. then the PCE SHOULD reject the request.
3.9. P2MP TE Path Reoptimization Request 3.9. P2MP TE Path Reoptimization Request
A reoptimization request for a P2MP TE path is specified by the use A reoptimization request for a P2MP TE path is specified by the use
of the R-bit within the RP object as defined in [RFC5440] and is of the R-bit within the RP object as defined in [RFC5440] and is
similar to the reoptimization request for a P2P TE path. The only similar to the reoptimization request for a P2P TE path. The only
difference is that the PCC MUST insert the list of RROs and SRROs difference is that the PCC MUST insert the list of Record Route
after each type of END-POINTS in the PCReq message, as described in Objects (RROs) and SRROs after each instance of the END-POINTS object
the "Request Message Format" section (Section 3.4) of this document. in the PCReq message, as described in Section 3.4 ("Request Message
Format") of this document.
An example of a reoptimization request and subsequent PCReq message An example of a reoptimization request and subsequent PCReq message
is described below: is described below:
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 5. PCReq Message Example 1 for Optimization Figure 5: PCReq Message Example 1 for Optimization
In this example, we request reoptimization of the path to all leaves In this example, we request reoptimization of the path to all leaves
without adding or pruning leaves. The reoptimization request would without adding or pruning leaves. The reoptimization request would
use an END-POINT type 3. The RRO list would represent the P2MP LSP use an END-POINTS object with leaf type 3. The RRO list would
before the optimization, and the modifiable path leaves would be represent the P2MP LSP before the optimization, and the modifiable
indicated in the END-POINTS object. path leaves would be indicated in the END-POINTS object.
It is also possible to specify distinct leaves whose path cannot be It is also possible to specify distinct leaves whose path cannot be
modified. An example of the PCReq message in this scenario would be: modified. An example of the PCReq message in this scenario would be:
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Figure 6. PCReq Message Example 2 for Optimization Figure 6: PCReq Message Example 2 for Optimization
3.10. Adding and Pruning Leaves to/from the P2MP Tree 3.10. Adding and Pruning Leaves to/from the P2MP Tree
When adding new leaves to or removing old leaves from the existing When adding new leaves to or removing old leaves from the existing
P2MP tree, by supplying a list of existing leaves, it is possible to P2MP tree, by supplying a list of existing leaves, it is possible to
optimize the existing P2MP tree. This section explains the methods optimize the existing P2MP tree. This section explains the methods
for adding new leaves to or removing old leaves from the existing for adding new leaves to or removing old leaves from the existing
P2MP tree. P2MP tree.
To add new leaves, the PCC MUST build a P2MP request using END- To add new leaves, the PCC MUST build a P2MP request using END-POINTS
POINTS with leaf type 1. with leaf type 1.
To remove old leaves, the PCC MUST build a P2MP request using END- To remove old leaves, the PCC MUST build a P2MP request using
POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE END-POINTS with leaf type 2. If no type-2 END-POINTS exist, then the
MUST send an error type 17, value=1: The PCE is not capable of PCE MUST send Error-Type 17, Error-value 1: the PCE cannot satisfy
satisfying the request due to no END-POINTS with leaf type 2. the request due to no END-POINTS with leaf type 2.
When adding new leaves to or removing old leaves from the existing When adding new leaves to or removing old leaves from the existing
P2MP tree, the PCC MUST also provide the list of old leaves, if any, P2MP tree, the PCC MUST also provide the list of old leaves, if any,
including END-POINTS with leaf type 3, leaf type 4, or both. New including END-POINTS with leaf type 3, leaf type 4, or both.
PCEP-ERROR objects and types are necessary for reporting when certain Specific PCEP-ERROR objects and types are used when certain
conditions are not satisfied (i.e., when there are no END-POINTS with conditions are not satisfied (i.e., when there are no END-POINTS with
leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1
or 2). A generic "Inconsistent END-POINT" error will be used if a or 2). A generic "Inconsistent END-POINTS" error will be used if a
PCC receives a request that has an inconsistent END-POINT (i.e., if a PCC receives a request that has an inconsistent END-POINTS setting
leaf specified as type 1 already exists). These IANA assignments are (i.e., if a leaf specified as type 1 already exists). These IANA
documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this assignments are documented in Section 6.6 ("PCEP-ERROR Objects and
document. Types") of this document.
For old leaves, the PCC MUST provide the old path as a list of RROs For old leaves, the PCC MUST provide the old path as a list of RROs
that immediately follows each END-POINTS object. This document that immediately follows each END-POINTS object. This document
specifies error values when specific conditions are not satisfied. specifies Error-values when specific conditions are not satisfied.
The following examples demonstrate full and partial reoptimization of The following examples demonstrate full and partial reoptimization of
existing P2MP LSPs: existing P2MP LSPs:
Case 1: Adding leaves with full reoptimization of existing paths Case 1: Adding leaves with full reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Case 2: Adding leaves with partial reoptimization of existing paths Case 2: Adding leaves with partial reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Case 3: Adding leaves without reoptimization of existing paths Case 3: Adding leaves without reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Case 4: Pruning Leaves with full reoptimization of existing paths Case 4: Pruning leaves with full reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Case 5: Pruning leaves with partial reoptimization of existing paths Case 5: Pruning leaves with partial reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Case 6: Pruning leaves without reoptimization of existing paths Case 6: Pruning leaves without reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Case 7: Adding and pruning leaves with full reoptimization of Case 7: Adding and pruning leaves with full reoptimization of
existing paths existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Case 8: Adding and pruning leaves with partial reoptimization of Case 8: Adding and pruning leaves with partial reoptimization of
existing paths existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Case 9: Adding and pruning leaves without reoptimization of existing Case 9: Adding and pruning leaves without reoptimization of existing
paths paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
END-POINTS for leaf type 2 END-POINTS for leaf type 2
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
3.11. Discovering Branch Nodes 3.11. Discovering Branch Nodes
Before computing the P2MP path, a PCE may need to be provided means Before computing the P2MP path, a PCE may need to be provided means
to know which nodes in the network are capable of acting as branch to know which nodes in the network are capable of acting as branch
LSRs. A PCE can discover such capabilities by using the mechanisms LSRs. A PCE can discover such capabilities by using the mechanisms
defined in [RFC5073]. defined in [RFC5073].
3.11.1. Branch Node Object 3.11.1. Branch Node Object
The PCC can specify a list of nodes that can be used as branch nodes The PCC can specify a list of nodes that can be used as branch nodes
or a list of nodes that cannot be used as branch nodes by using the or a list of nodes that cannot be used as branch nodes by using the
Branch Node Capability (BNC) Object. The BNC Object has the same Branch Node Capability (BNC) object. The BNC object has the same
format as the Include Route Object (IRO) defined in [RFC5440], except format as the Include Route Object (IRO) as defined in [RFC5440],
that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- except that it only supports IPv4 and IPv6 prefix sub-objects. Two
types are also defined: Object-Type parameters are also defined:
o Branch node list: List of nodes that can be used as branch nodes. o Branch node list: List of nodes that can be used as branch nodes.
o Non-branch node list: List of nodes that cannot be used as branch o Non-branch node list: List of nodes that cannot be used as branch
nodes. nodes.
The object can only be carried in a PCReq message. A Path Request The object can only be carried in a PCReq message. A path
may carry at most one Branch Node Object. computation request may carry at most one Branch Node object.
The Object-Class and Object-types have been allocated by IANA. The The Object-Class and Object-Type values have been allocated by IANA.
IANA assignment is documented in Section 6.5 ("PCEP Objects"). The IANA assignments are documented in Section 6.5 ("PCEP Objects").
3.12. Synchronization of P2MP TE Path Computation Requests 3.12. Synchronization of P2MP TE Path Computation Requests
There are cases when multiple P2MP LSPs' computations need to be There are cases when multiple P2MP LSPs' computations need to be
synchronized. For example, one P2MP LSP is the designated backup of synchronized. For example, one P2MP LSP is the designated backup of
another P2MP LSP. In this case, path diversity for these dependent another P2MP LSP. In this case, path diversity for these dependent
LSPs may need to be considered during the path computation. LSPs may need to be considered during the path computation.
The synchronization can be done by using the existing Synchronization The synchronization can be done by using the existing SVEC
VECtor (SVEC) functionality defined in [RFC5440]. functionality as defined in [RFC5440].
An example of synchronizing two P2MP LSPs, each having two leaves for An example of synchronizing two P2MP LSPs, each having two leaves for
Path Computation Request Messages, is illustrated below: Path Computation Request messages, is illustrated below:
Common Header Common Header
SVEC for sync of LSP1 and LSP2 SVEC for sync of LSP1 and LSP2
OF (optional) OF (optional)
RP for LSP1 RP for LSP1
END-POINTS1 for LSP1 END-POINTS1 for LSP1
RRO1 list RRO1 list
RP for LSP2 RP for LSP2
END-POINTS2 for LSP2 END-POINTS2 for LSP2
RRO2 list RRO2 list
Figure 7. PCReq Message Example for Synchronization Figure 7: PCReq Message Example for Synchronization
This specification also defines two new flags to the SVEC Object Flag This specification also defines two flags for the SVEC Object Flag
Field for P2MP path dependent computation requests. The first new Field for P2MP path-dependent computation requests. The first flag
flag is to allow the PCC to request that the PCE should compute a allows the PCC to request that the PCE should compute a secondary
secondary P2MP path tree with partial path diversity for specific P2MP path tree with partial path diversity for specific leaves or a
leaves or a specific S2L sub-path to the primary P2MP path tree. The specific S2L sub-path to the primary P2MP path tree. The second flag
second flag, would allow the PCC to request that partial paths should allows the PCC to request that partial paths should be
be link direction diverse. link direction diverse.
The following flags are added to the SVEC object body in this The following flags are added to the SVEC object body in this
document: document:
o P (Partial Path Diverse bit - 1 bit): o P (Partial Path Diverse bit - 1 bit):
When set, this would indicate a request for path diversity for a When set, this would indicate a request for path diversity for a
specific leaf, a set of leaves, or all leaves. specific leaf, a set of leaves, or all leaves.
o D (Link Direction Diverse bit - 1 bit): o D (Link Direction Diverse bit - 1 bit):
When set, this would indicate a request that a partial path or When set, this would indicate a request that a partial path or
paths should be link direction diverse. paths should be link direction diverse.
The IANA assignment is referenced in Section 6.8 of this document. The IANA assignments are referenced in Section 6.8 of this document.
3.13. Request and Response Fragmentation 3.13. Request and Response Fragmentation
The total PCEP message length, including the common header, is The total PCEP message length, including the common header, is
16 bytes. In certain scenarios the P2MP computation request may not 16 bytes. In certain scenarios, the P2MP computation request may not
fit into a single request or response message. For example, if a fit into a single request or response message. For example, if a
tree has many hundreds or thousands of leaves, then the request or tree has many hundreds or thousands of leaves, then the request or
response may need to be fragmented into multiple messages. response may need to be fragmented into multiple messages.
The F-bit has been outlined in "The Extension of the RP Object" The F-bit is outlined in Section 3.3.1 ("The Extension of the RP
(Section 3.3.1) of this document. The F-bit is used in the RP object Object") of this document. The F-bit is used in the RP object to
to signal that the initial request or response was too large to fit signal that the initial request or response was too large to fit into
into a single message and will be fragmented into multiple messages. a single message and will be fragmented into multiple messages. In
In order to identify the single request or response, each message order to identify the single request or response, each message will
will use the same request ID. use the same request ID.
3.13.1. Request Fragmentation Procedure 3.13.1. Request Fragmentation Procedure
If the initial request is too large to fit into a single request If the initial request is too large to fit into a single request
message, the PCC will split the request over multiple messages. Each message, the PCC will split the request over multiple messages. Each
message sent to the PCE, except the last one, will have the F-bit set message sent to the PCE, except the last one, will have the F-bit set
in the RP object to signify that the request has been fragmented into in the RP object to signify that the request has been fragmented into
multiple messages. In order to identify that a series of request multiple messages. In order to identify that a series of request
messages represents a single request, each message will use the same messages represents a single request, each message will use the same
request ID. request ID.
skipping to change at page 24, line 39 skipping to change at page 24, line 39
single response message, the PCE will split the response over single response message, the PCE will split the response over
multiple messages. Each message sent by the PCE, except the last multiple messages. Each message sent by the PCE, except the last
one, will have the F-bit set in the RP object to signify that the one, will have the F-bit set in the RP object to signify that the
response has been fragmented into multiple messages. In order to response has been fragmented into multiple messages. In order to
identify that a series of response messages represents a single identify that a series of response messages represents a single
response, each message will use the same response ID. response, each message will use the same response ID.
Again, the assumption is that response messages are reliably Again, the assumption is that response messages are reliably
delivered and in sequence, since PCEP relies on TCP. delivered and in sequence, since PCEP relies on TCP.
3.13.3. Fragmentation Examples 3.13.3. Fragmentation Example
The following example illustrates the PCC sending a request message The following example illustrates the PCC sending a request message
with Req-ID1 to the PCE, in order to add one leaf to an existing tree with Req-ID1 to the PCE, in order to add one leaf to an existing tree
with 1200 leaves. The assumption used for this example is that one with 1200 leaves. The assumption used for this example is that one
request message can hold up to 800 leaves. In this scenario, the request message can hold up to 800 leaves. In this scenario, the
original single message needs to be fragmented and sent using two original single message needs to be fragmented and sent using two
smaller messages, which have the Req-ID1 specified in the RP object, smaller messages, which have Req-ID1 specified in the RP object, and
and with the F-bit set on the first message, and cleared on the with the F-bit set on the first message and the F-bit cleared on the
second message. second message.
Common Header Common Header
RP1 with Req-ID1 and P2MP=1 and F-bit=1 RP1 with Req-ID1 and P2MP=1 and F-bit=1
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
Common Header Common Header
RP2 with Req-ID1 and P2MP=1 and F-bit=0 RP2 with Req-ID1 and P2MP=1 and F-bit=0
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
Figure 8. PCReq Message Fragmentation Example Figure 8: PCReq Message Fragmentation Example
To handle a scenario where the last fragmented message piece is lost, To handle a scenario where the last fragmented message piece is lost,
the receiver side of the fragmented message may start a timer once it the receiver side of the fragmented message may start a timer once it
receives the first piece of the fragmented message. When the timer receives the first piece of the fragmented message. If the timer
expires and it has not received the last piece of the fragmented expires and it still has not received the last piece of the
message, it should send an error message to the sender to signal that fragmented message, it should send an error message to the sender to
it has received an incomplete message. The relevant error message is signal that it has received an incomplete message. The relevant
documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). error message is documented in Section 3.15 ("P2MP PCEP-ERROR Objects
and Types").
3.14. UNREACH-DESTINATION Object 3.14. UNREACH-DESTINATION Object
The PCE path computation request may fail because all or a subset of The PCE path computation request may fail because all or a subset of
the destinations are unreachable. the destinations are unreachable.
In such a case, the UNREACH-DESTINATION object allows the PCE to In such a case, the UNREACH-DESTINATION object allows the PCE to
optionally specify the list of unreachable destinations. optionally specify the list of unreachable destinations.
This object can be present in PCRep messages. There can be up to one This object can be present in PCRep messages. There can be up to one
such object per RP. such object per RP.
The following UNREACH-DESTINATION objects will be required: The following UNREACH-DESTINATION objects (for IPv4 and IPv6) are
defined:
UNREACH-DESTINATION Object-Class is 28. UNREACH-DESTINATION Object-Class is 28.
UNREACH-DESTINATION Object-Type for IPv4 is 1. UNREACH-DESTINATION Object-Type for IPv4 is 1.
UNREACH-DESTINATION Object-Type for IPv6 is 2. UNREACH-DESTINATION Object-Type for IPv6 is 2.
The format of the UNREACH-DESTINATION object body for IPv4 (Object- The format of the UNREACH-DESTINATION object body for IPv4
Type=1) is as follows: (Object-Type=1) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. UNREACH-DESTINATION Object Body for IPv4 Figure 9: UNREACH-DESTINATION Object Body for IPv4
The format of the UNREACH-DESTINATION object body for IPv6 (Object- The format of the UNREACH-DESTINATION object body for IPv6
Type=2) is as follows: (Object-Type=2) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. UNREACH-DESTINATION Object Body for IPv6 Figure 10: UNREACH-DESTINATION Object Body for IPv6
3.15. P2MP PCEP-ERROR Objects and Types 3.15. P2MP PCEP-ERROR Objects and Types
To indicate an error associated with policy violation, a new error To indicate an error associated with a policy violation, the
value "P2MP Path computation not allowed" should be added to the Error-value "P2MP Path computation is not allowed" has been added to
existing error code for policy violation (Error-Type=5) as defined in the existing error code for Error-Type 5 ("Policy violation") as
[RFC5440]: defined in [RFC5440] (see also Section 6.6 of this document):
Error-Type=5; Error-Value=7: if a PCE receives a P2MP path Error-Type=5; Error-value=7: if a PCE receives a P2MP path
computation request that is not compliant with administrative computation request that is not compliant with administrative
privileges (i.e., "The PCE policy does not support P2MP path privileges (i.e., "The PCE policy does not support P2MP path
computation"), the PCE MUST send a PCErr message with a PCEP-ERROR computation"), the PCE MUST send a PCErr message with a PCEP-ERROR
object (Error-Type=5) and an Error-Value (Error-Value=7). The object (Error-Type=5) and an Error-value of 7. The corresponding
corresponding P2MP path computation request MUST also be cancelled. P2MP path computation request MUST also be cancelled.
To indicate capability errors associated with the P2MP path request, To indicate capability errors associated with the P2MP path
a new Error-Type (16) and subsequent error-values are defined as computation request, Error-Type (16) and subsequent Error-values are
follows for inclusion in the PCEP-ERROR object: defined as follows for inclusion in the PCEP-ERROR object:
Error-Type=16; Error-Value=1: if a PCE receives a P2MP path request Error-Type=16; Error-value=1: if a PCE receives a P2MP path
and the PCE is not capable of satisfying the request due to computation request and the PCE is not capable of satisfying the
insufficient memory, the PCE MUST send a PCErr message with a PCEP- request due to insufficient memory, the PCE MUST send a PCErr
ERROR object (Error-Type=16) and an Error-Value (Error-Value=1). The message with a PCEP-ERROR object (Error-Type=16) and an
corresponding P2MP path computation request MUST also be cancelled. Error-value of 1. The corresponding P2MP path computation request
MUST also be cancelled.
Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request Error-Type=16; Error-value=2: if a PCE receives a P2MP path
and the PCE is not capable of P2MP computation, the PCE MUST send a computation request and the PCE is not capable of P2MP
PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error- computation, the PCE MUST send a PCErr message with a PCEP-ERROR
Value (Error-Value=2). The corresponding P2MP path computation object (Error-Type=16) and an Error-value of 2. The corresponding
request MUST also be cancelled. P2MP path computation request MUST also be cancelled.
To indicate P2MP message fragmentation errors associated with a P2MP To indicate P2MP message fragmentation errors associated with a P2MP
path request, a new Error-Type (18) and subsequent error-values are path computation request, Error-Type (18) and subsequent Error-values
defined as follows for inclusion in the PCEP-ERROR object: are defined as follows for inclusion in the PCEP-ERROR object:
Error-Type=18; Error-Value=1: if a PCE has not received the last Error-Type=18; Error-value=1: if a PCE has not received the last
piece of the fragmented message, it should send an error message to piece of the fragmented message, it should send an error message
the sender to signal that it has received an incomplete message to the sender to signal that it has received an incomplete message
(i.e., "Fragmented request failure"). The PCE MUST send a PCErr (i.e., "Fragmented request failure"). The PCE MUST send a PCErr
message with a PCEP-ERROR object (Error-Type=18) and an Error-Value message with a PCEP-ERROR object (Error-Type=18) and an
(Error-Value=1). Error-value of 1.
3.16. PCEP NO-PATH Indicator 3.16. PCEP NO-PATH Indicator
To communicate the reasons for not being able to find P2MP path To communicate the reasons for not being able to find a P2MP path
computation, the NO-PATH object can be used in the PCRep message. computation, the NO-PATH object can be used in the PCRep message.
One new bit is defined in the NO-PATH-VECTOR TLV carried in the One bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH
NO-PATH Object: object:
bit 24: when set, the PCE indicates that there is a reachability bit 24: when set, the PCE indicates that there is a reachability
problem with all or a subset of the P2MP destinations. Optionally, problem with all or a subset of the P2MP destinations.
the PCE can specify the destination or list of destinations that are Optionally, the PCE can specify the destination or list of
not reachable using the new UNREACH-DESTINATION object defined in destinations that are not reachable using the UNREACH-DESTINATION
Section 3.14. object defined in Section 3.14.
4. Manageability Considerations 4. Manageability Considerations
[RFC5862] describes various manageability requirements in support of [RFC5862] describes various manageability requirements in support of
P2MP path computation when applying PCEP. This section describes how P2MP path computation when applying PCEP. This section describes how
manageability requirements mentioned in [RFC5862] are supported in manageability requirements mentioned in [RFC5862] are supported in
the context of PCEP extensions specified in this document. the context of PCEP extensions specified in this document.
Note that [RFC5440] describes various manageability considerations in Note that [RFC5440] describes various manageability considerations
PCEP, and most of the manageability requirements mentioned in for PCEP, and most of the manageability requirements mentioned in
[RFC5862] are already covered there. [RFC5862] are already covered there.
4.1. Control of Function and Policy 4.1. Control of Function and Policy
In addition to PCE configuration parameters listed in [RFC5440], the In addition to PCE configuration parameters listed in [RFC5440], the
following additional parameters might be required: following additional parameters might be required:
o The ability to enable or disable P2MP path computations on the o The PCE may be configured to enable or disable P2MP path
PCE. computations.
o The PCE may be configured to enable or disable the advertisement o The PCE may be configured to enable or disable the advertisement
of its P2MP path computation capability. A PCE can advertise its of its P2MP path computation capability. A PCE can advertise its
P2MP capability via the IGP discovery mechanism discussed in P2MP capability via the IGP discovery mechanism discussed in
Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement")
Protocol"), or during the Open Message Exchange discussed in or during the Open Message Exchange discussed in Section 3.1.2
Section 3.1.2 ("Open Message Extension"). ("Open Message Extension").
4.2. Information and Data Models 4.2. Information and Data Models
A number of MIB objects have been defined for general PCEP control A number of MIB objects have been defined in [RFC7420] for general
and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies PCEP control and monitoring of P2P computations. [RFC5862] specifies
that MIB objects will be required to support the control and that MIB objects will be required to support the control and
monitoring of the protocol extensions defined in this document. A new monitoring of the protocol extensions defined in this document. A
document will be required to define MIB objects for PCEP control and new document will be required to define MIB objects for PCEP control
monitoring of P2MP computations. and monitoring of P2MP computations.
The PCEP YANG model "ietf-pcep" is specified in [I-D.ietf-pce-pcep- The "ietf-pcep" PCEP YANG module is specified in [PCEP-YANG]. The
yang]. The P2MP capability of a PCEP entity or a configured peer, can P2MP capability of a PCEP entity or a configured peer can be set
be set using this YANG model. Also the support for P2MP path using this YANG module. Also, support for P2MP path computation can
computation can be learned using this model. The statistics are be learned using this module. The statistics are maintained in the
maintained in the model "ietf-pcep-stats" as specified in [I-D.ietf- "ietf-pcep-stats" YANG module as specified in [PCEP-YANG]. This YANG
pce-pcep-yang]. This YANG model will be required to be augmented to module will be required to be augmented to also include the
also include the P2MP related statistics. P2MP-related statistics.
4.3. Liveness Detection and Monitoring 4.3. Liveness Detection and Monitoring
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[RFC5440], since [RFC5862] does not address any additional [RFC5440], since [RFC5862] does not address any additional
requirements. requirements.
4.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional requirements beyond those expressed in There are no additional requirements beyond those expressed in
[RFC4657] for verifying the correct operation of the PCEP sessions. [RFC4657] for verifying the correct operation of the PCEP sessions.
It is expected that future MIB objects will facilitate verification It is expected that future MIB objects will facilitate verification
of correct operation and reporting of P2MP PCEP requests, responses, of correct operation and reporting of P2MP PCEP requests, responses,
and errors. and errors.
4.5. Requirements for Other Protocols and Functional Components 4.5. Requirements for Other Protocols and Functional Components
The method for the PCE to obtain information about a PCE capable of The method for the PCE to obtain information about a PCE capable of
P2MP path computations via OSPF and IS-IS is discussed in P2MP path computations via OSPF and IS-IS is discussed in
Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement") of
Protocol") of this document. this document.
The subsequent IANA assignments are documented in Section 6.9 ("OSPF The relevant IANA assignment is documented in Section 6.9 ("OSPF PCE
PCE Capability Flag") of this document. Capability Flag") of this document.
4.6. Impact on Network Operation 4.6. Impact on Network Operation
It is expected that the use of PCEP extensions specified in this It is expected that the use of PCEP extensions specified in this
document will not significantly increase the level of operational document will not significantly increase the level of operational
traffic. However, computing a P2MP tree may require more PCE state traffic. However, computing a P2MP tree may require more PCE state
compared to a P2P computation. In the event of a major network compared to a P2P computation. In the event of a major network
failure and multiple recovery P2MP tree computation requests being failure and multiple recovery P2MP tree computation requests being
sent to the PCE, the load on the PCE may also be significantly sent to the PCE, the load on the PCE may also be significantly
increased. increased.
5. Security Considerations 5. Security Considerations
As described in [RFC5862], P2MP path computation requests are more As described in [RFC5862], P2MP path computation requests are more
CPU-intensive and also utilize more link bandwidth. In the event of CPU-intensive and also utilize more link bandwidth. In the event of
an unauthorized P2MP path computation request, or a denial of service an unauthorized P2MP path computation request or a denial-of-service
attack, the subsequent PCEP requests and processing may be disruptive attack, the subsequent PCEP requests and processing may be disruptive
to the network. Consequently, it is important that implementations to the network. Consequently, it is important that implementations
conform to the relevant security requirements that specifically help conform to the relevant security requirements that specifically help
to minimize or negate unauthorized P2MP path computation requests and to minimize or negate unauthorized P2MP path computation requests and
denial of service attacks. These mechanisms include: denial-of-service attacks. These mechanisms include the following:
o Securing the PCEP session requests and responses is RECOMMENDED o Securing the PCEP session requests and responses is RECOMMENDED
using TCP security techniques such as TCP Authentication Option using TCP security techniques such as the TCP Authentication
(TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I- Option (TCP-AO) [RFC5925] or using Transport Layer Security (TLS)
D.ietf-pce-pceps], as per the recommendations and best current [RFC8253], as per the recommendations and best current practices
practices in [RFC7525]. in [RFC7525].
o Authenticating the PCEP requests and responses to ensure the o Authenticating the PCEP requests and responses to ensure that the
message is intact and sent from an authorized node using TCP-AO or message is intact and sent from an authorized node using the
TLS is RECOMMENDED. TCP-AO or TLS is RECOMMENDED.
o Providing policy control by explicitly defining which PCCs, via IP o Policy control could be provided by explicitly defining which PCCs
access-lists, are allowed to send P2MP path requests to the PCE. are allowed to send P2MP path computation requests to the PCE via
IP access lists.
PCEP operates over TCP, so it is also important to secure the PCE and PCEP operates over TCP, so it is also important to secure the PCE and
PCC against TCP denial of service attacks. PCC against TCP denial-of-service attacks.
As stated in [RFC6952], PCEP implementations SHOULD support TCP-AO
[RFC5925] and not use TCP-MD5 because of the known vulnerabilities As stated in [RFC6952], PCEP implementations SHOULD support the
and weakness. TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known
vulnerabilities and weakness.
6. IANA Considerations 6. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA IANA maintains a registry of PCEP parameters. A number of IANA
considerations have been highlighted in previous sections of this considerations have been highlighted in previous sections of this
document. IANA made the allocations as per [RFC6006]. document. IANA made the allocations as per [RFC6006].
6.1. PCEP TLV Type Indicators 6.1. PCEP TLV Type Indicators
As described in Section 3.1.2., the P2MP capability TLV allows the As described in Section 3.1.2, the P2MP capability TLV allows the PCE
PCE to advertise its P2MP path computation capability. to advertise its P2MP path computation capability.
IANA had made an allocation from the "PCEP TLV Type Indicators" IANA had previously made an allocation from the "PCEP TLV Type
subregistry, where RFC 6006 was the reference. IANA is requested to Indicators" subregistry, where RFC 6006 was the reference. IANA has
update the reference as follows to point to this document. updated the reference as follows to point to this document.
Value Description Reference Value Description Reference
6 P2MP capable [This I-D] 6 P2MP capable RFC 8306
6.2. Request Parameter Bit Flags 6.2. Request Parameter Bit Flags
As described in Section 3.3.1, three RP Object Flags have been As described in Section 3.3.1, three RP Object Flags have been
defined. defined.
IANA has made an allocations from the PCEP "RP Object Flag Field" IANA had previously made allocations from the PCEP "RP Object Flag
sub-registry, where RFC 6006 was the reference. IANA is requested to Field" subregistry, where RFC 6006 was the reference. IANA has
update the reference as follows to point to this document. updated the reference as follows to point to this document.
Bit Description Reference Bit Description Reference
18 Fragmentation (F-bit) [This I-D] 18 Fragmentation (F-bit) RFC 8306
19 P2MP (N-bit) [This I-D] 19 P2MP (N-bit) RFC 8306
20 ERO-compression (E-bit) [This I-D] 20 ERO-compression (E-bit) RFC 8306
6.3. Objective Functions 6.3. Objective Functions
As described in Section 3.6.1, two Objective Functions have been As described in Section 3.6.1, this document defines two objective
defined. functions.
IANA has made an allocations from the PCEP "Objective Function" sub- IANA had previously made allocations from the PCEP "Objective
registry, where RFC 6006 was the reference.IANA is requested to Function" subregistry, where RFC 6006 was the reference. IANA has
update the reference as follows to point to this document. updated the reference as follows to point to this document.
Code Point Name Reference Code Point Name Reference
7 SPT [This I-D] 7 SPT RFC 8306
8 MCT [This I-D] 8 MCT RFC 8306
6.4. Metric Object Types 6.4. METRIC Object-Type Values
As described in Section 3.6.2, three metric object T fields have been As described in Section 3.6.2, three METRIC object T fields have been
defined. defined.
IANA has made an allocations from the PCEP "METRIC Object T Field" IANA had previously made allocations from the PCEP "METRIC Object
sub-registry, where RFC 6006 was the reference. IANA is requested to T Field" subregistry, where RFC 6006 was the reference. IANA has
update the reference as follows to point to this document. updated the reference as follows to point to this document.
Value Description Reference Value Description Reference
8 P2MP IGP metric [This I-D] 8 P2MP IGP metric RFC 8306
9 P2MP TE metric [This I-D] 9 P2MP TE metric RFC 8306
10 P2MP hop count metric [This I-D] 10 P2MP hop count metric RFC 8306
6.5. PCEP Objects 6.5. PCEP Objects
As discussed in Section 3.3.2, two END-POINTS Object-Types are As discussed in Section 3.3.2, two END-POINTS Object-Type values are
defined. defined.
IANA has made the Object-Type allocations from the "PCEP Objects" IANA had previously made the Object-Type allocations from the "PCEP
sub-registry, where RFC 6006 was the reference. IANA is requested to Objects" subregistry, where RFC 6006 was the reference. IANA has
update the reference as follows to point to this document. updated the reference as follows to point to this document.
Object-Class Value 4 Object-Class Value 4
Name END-POINTS Name END-POINTS
Object-Type 3: IPv4 Object-Type 3: IPv4
4: IPv6 4: IPv6
5-15: Unassigned 5-15: Unassigned
Reference [This I-D] Reference RFC 8306
As described in Section 3.2, Section 3.11.1, and Section 3.14, four As described in Sections 3.2, 3.11.1, and 3.14, four PCEP
PCEP Object-Classes and six PCEP Object-Types have been defined. Object-Class values and six PCEP Object-Type values have been
defined.
IANA has made an allocations from the "PCEP Objects" sub-registry, IANA had previously made allocations from the "PCEP Objects"
where RFC 6006 was the reference. IANA is requested to update the subregistry, where RFC 6006 was the reference. IANA has updated the
reference as follows to point to this document. reference to point to this document.
Also, for the following four PCEP objects, the code-point 0 for the Also, for the following four PCEP objects, codepoint 0 for the
Object-Type field are marked "Reserved" with reference to Errata ID Object-Type field is marked "Reserved", as per Erratum ID 4956 for
4956. IANA is requested to update the reference to point to this RFC 5440. IANA has updated the reference to point to this document.
document.
Object-Class Value 28 Object-Class Value 28
Name UNREACH-DESTINATION Name UNREACH-DESTINATION
Object-Type 0: Reserved Object-Type 0: Reserved
1: IPv4 1: IPv4
2: IPv6 2: IPv6
3-15: Unassigned 3-15: Unassigned
Reference [This I-D] Reference RFC 8306
Object-Class Value 29 Object-Class Value 29
Name SERO Name SERO
Object-Type 0: Reserved Object-Type 0: Reserved
1: SERO 1: SERO
2-15: Unassigned 2-15: Unassigned
Reference [This I-D] Reference RFC 8306
Object-Class Value 30 Object-Class Value 30
Name SRRO Name SRRO
Object-Type 0: Reserved Object-Type 0: Reserved
1: SRRO 1: SRRO
2-15: Unassigned 2-15: Unassigned
Reference [This I-D] Reference RFC 8306
Object-Class Value 31 Object-Class Value 31
Name Branch Node Capability Object Name BNC
Object-Type 0: Reserved Object-Type 0: Reserved
1: Branch node list 1: Branch node list
2: Non-branch node list 2: Non-branch node list
3-15: Unassigned 3-15: Unassigned
Reference [This I-D] Reference RFC 8306
6.6. PCEP-ERROR Objects and Types 6.6. PCEP-ERROR Objects and Types
As described in Section 3.15, number of PCEP-ERROR Object Error Types As described in Section 3.15, a number of PCEP-ERROR Object
and Values have been defined. Error-Types and Error-values have been defined.
IANA has made an allocations from the PCEP "PCEP-ERROR Object Error IANA had previously made allocations from the PCEP "PCEP-ERROR Object
Types and Values" sub-registry, where RFC 6006 was the reference. Error Types and Values" subregistry, where RFC 6006 was the
IANA is requested to update the reference as follows to point to this reference. IANA has updated the reference as follows to point to
document. this document.
Error Error
Type Meaning Reference Type Meaning Reference
5 Policy violation 5 Policy violation
Error-value=7: [This I-D] Error-value=7: RFC 8306
P2MP Path computation is not allowed P2MP Path computation is not allowed
16 P2MP Capability Error 16 P2MP Capability Error
Error-Value=0: Unassigned [This I-D] Error-value=0: Unassigned RFC 8306
Error-Value=1: [This I-D] Error-value=1: RFC 8306
The PCE is not capable to satisfy the request The PCE cannot satisfy the request
due to insufficient memory due to insufficient memory
Error-Value=2: [This I-D] Error-value=2: RFC 8306
The PCE is not capable of P2MP computation The PCE is not capable of P2MP computation
17 P2MP END-POINTS Error 17 P2MP END-POINTS Error
Error-Value=0: Unassigned [This I-D] Error-value=0: Unassigned RFC 8306
Error-Value=1: [This I-D] Error-value=1: RFC 8306
The PCE is not capable to satisfy the request The PCE cannot satisfy the request
due to no END-POINTS with leaf type 2 due to no END-POINTS with leaf type 2
Error-Value=2: [This I-D] Error-value=2: RFC 8306
The PCE is not capable to satisfy the request The PCE cannot satisfy the request
due to no END-POINTS with leaf type 3 due to no END-POINTS with leaf type 3
Error-Value=3: [This I-D] Error-value=3: RFC 8306
The PCE is not capable to satisfy the request The PCE cannot satisfy the request
due to no END-POINTS with leaf type 4 due to no END-POINTS with leaf type 4
Error-Value=4: [This I-D] Error-value=4: RFC 8306
The PCE is not capable to satisfy the request The PCE cannot satisfy the request
due to inconsistent END-POINTS due to inconsistent END-POINTS
18 P2MP Fragmentation Error 18 P2MP Fragmentation Error
Error-Value=0: Unassigned [This I-D] Error-value=0: Unassigned RFC 8306
Error-Value=1: [This I-D] Error-value=1: RFC 8306
Fragmented request failure Fragmented request failure
6.7. PCEP NO-PATH Indicator 6.7. PCEP NO-PATH Indicator
As discussed in Section 3.16, NO-PATH-VECTOR TLV Flag Field has been As discussed in Section 3.16, the NO-PATH-VECTOR TLV Flag Field has
defined. been defined.
IANA has made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag IANA had previously made an allocation from the PCEP "NO-PATH-VECTOR
Field" sub-registry, where RFC 6006 was the reference. IANA is TLV Flag Field" subregistry, where RFC 6006 was the reference. IANA
requested to update the reference as follows to point to this has updated the reference as follows to point to this document.
document.
Bit Description Reference Bit Description Reference
24 P2MP Reachability Problem [This I-D] 24 P2MP Reachability Problem RFC 8306
6.8. SVEC Object Flag 6.8. SVEC Object Flag
As discussed in Section 3.12, two SVEC Object Flags are defined. As discussed in Section 3.12, two SVEC Object Flags are defined.
IANA has made an allocation from the PCEP "SVEC Object Flag Field" IANA had previously made allocations from the PCEP "SVEC Object Flag
sub-registry, where RFC 6006 was the reference. IANA is requested to Field" subregistry, where RFC 6006 was the reference. IANA has
update the reference as follows to point to this document. updated the reference as follows to point to this document.
Bit Description Reference Bit Description Reference
19 Partial Path Diverse [This I-D] 19 Partial Path Diverse RFC 8306
20 Link Direction Diverse [This I-D] 20 Link Direction Diverse RFC 8306
6.9. OSPF PCE Capability Flag 6.9. OSPF PCE Capability Flag
As discussed in Section 3.1.1, OSPF Capability Flag is defined to As discussed in Section 3.1.1, the OSPF Capability Flag is defined to
indicate P2MP path computation capability. indicate P2MP path computation capability.
IANA has made an assignment from the OSPF Parameters "Path IANA had previously made an assignment from the OSPF Parameters "Path
Computation Element (PCE) Capability Flags" registry, where RFC 6006 Computation Element (PCE) Capability Flags" registry, where RFC 6006
was the reference. IANA is requested to update the reference as was the reference. IANA has updated the reference as follows to
follows to point to this document. point to this document.
Bit Description Reference
10 P2MP path computation [This I-D]
7. Acknowledgements Bit Description Reference
The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, 10 P2MP path computation RFC 8306
Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv
Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan
Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean
Turner for their valuable comments and input on the RFC 6006.
Thanks to Deborah Brungard for handling of related errata on the RFC 7. References
6006.
Authors would like to thank Jonathan Hardwick and Adrian Farrel for 7.1. Normative References
providing review comments with suggested text for this document.
Thanks to Jonathan Hardwick for being the document shepherd and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
provide comments and guidance. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Thanks to Ben Niven-Jenkins for RTGDIR reviews. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
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>.
Thanks to Roni Even for GENART reviews. [RFC3473] Berger, L., Ed., "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>.
Thanks to Fred Baker for OPSDIR review. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>.
Thanks to Deborah Brungard for being the responsible AD and guiding [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
the authors. Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for
Point-to-Multipoint TE Label Switched Paths (LSPs)",
RFC 4875, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
Thanks to Mirja Kuhlewind, Alvaro Retana, Ben Campbell, Adam Roach, [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
Benoit Claise, Suresh Krishnan and Eric Rescorla for the IESG review Protocol Extensions for Discovery of Traffic Engineering
and comments. Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
December 2007, <https://www.rfc-editor.org/info/rfc5073>.
8. References [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., 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>.
8.1. Normative References [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., 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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Requirement Levels", BCP 14, RFC 2119, March 1997. Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Used to Form Encoding Rules in Various Routing Protocol
Tunnels", RFC 3209, December 2001. Specifications", RFC 5511, DOI 10.17487/RFC5511,
April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Switching (GMPLS) Signaling Resource ReserVation Objective Functions in the Path Computation Element
Protocol-Traffic Engineering (RSVP-TE) Extensions", Communication Protocol (PCEP)", RFC 5541,
RFC 3473, January 2003. DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
Yasukawa, Ed., "Extensions to Resource Reservation RFC 2119 Key Words", BCP 14, RFC 8174,
Protocol - Traffic Engineering (RSVP-TE) for Point-to- DOI 10.17487/RFC8174, May 2017,
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May <https://www.rfc-editor.org/info/rfc8174>.
2007.
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing 7.2. Informative References
Protocol Extensions for Discovery of Traffic Engineering
Node Capabilities", RFC 5073, December 2007.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [PCEP-YANG]
Zhang, "OSPF Protocol Extensions for Path Computation Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura,
Element (PCE) Discovery", RFC 5088, January 2008. "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
draft-ietf-pce-pcep-yang-05, July 2017.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Zhang, "IS-IS Protocol Extensions for Path Computation Computation Element (PCE)-Based Architecture", RFC 4655,
Element (PCE) Discovery", RFC 5089, January 2008. DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Used to Form Encoding Rules in Various Routing Protocol Element (PCE) Communication Protocol Generic
Specifications", RFC 5511, April 2009. Requirements", RFC 4657, DOI 10.17487/RFC4657,
September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Computation Element (PCE) Communication Protocol (PCEP)", Path Computation Element (PCE) to Point-to-Multipoint
RFC 5440, March 2009. (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009,
<https://www.rfc-editor.org/info/rfc5671>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients
Objective Functions in the Path Computation Element (PCC) - Path Computation Element (PCE) Requirements for
Communication Protocol (PCEP)", RFC 5541, June 2009. Point-to-Multipoint MPLS-TE", RFC 5862,
DOI 10.17487/RFC5862, June 2010,
<https://www.rfc-editor.org/info/rfc5862>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
S. Shaffer, "Extensions to OSPF for Advertising Optional Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
Router Capabilities", RFC 7770, February 2016. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
8.2. Informative References [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
<https://www.rfc-editor.org/info/rfc6006>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
Computation Element (PCE)-Based Architecture", RFC 4655, BGP, LDP, PCEP, and MSDP Issues According to the Keying
August 2006. and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Element (PCE) Communication Protocol Generic Hardwick, "Path Computation Element Communication Protocol
Requirements", RFC 4657, September 2006. (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
Path Computation Element (PCE) to Point-to-Multipoint "Recommendations for Secure Use of Transport Layer
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", Security (TLS) and Datagram Transport Layer Security
RFC 5671, October 2009. (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
(PCC) - Path Computation Element (PCE) Requirements for "PCEPS: Usage of TLS to Provide a Secure Transport for the
Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Appendix A. Summary of Changes from RFC 6006
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., o Updated the text to use the term "PCC" instead of "user" while
Ali, Z., and J. Meuric, "Extensions to the Path describing the encoding rules in Section 3.10.
Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, September 2010.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of o Updated the example in Figure 7 to explicitly include the
BGP, LDP, PCEP, and MSDP Issues According to the Keying RP object.
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
[RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J. o Corrected the description of the F-bit in the RP object in
Hardwick "PCE communication protocol (PCEP) Management Section 3.13, as per Erratum ID 3836.
Information Base (MIB) Module", RFC 7420, December 2014.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, o Corrected the description of the fragmentation procedure for the
"Recommendations for Secure Use of Transport Layer response in Section 3.13.2, as per Erratum ID 3819.
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525 May 2015.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC o Corrected the Error-Type for fragmentation in Section 3.15, as per
2119 Key Words", BCP 14, RFC 8174, May 2017. Erratum ID 3830.
[I-D.ietf-pce-pcep-yang] o Updated the references for the OSPF Router Information Link State
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Advertisement (LSA) [RFC7770] and the PCEP MIB [RFC7420].
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
(work in progress), June 2017.
[I-D.ietf-pce-pceps] o Added current information and references for PCEP YANG [PCEP-YANG]
Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure and PCEPS [RFC8253].
Transport for PCEP", draft-ietf-pce-pceps (work in
progress), August 2017.
Appendix A. Summary of the all Changes from RFC 6006 o Updated the Security Considerations section to include the TCP-AO
and TLS.
o Updated the text to use the term "PCC" instead of "user" while o Updated the IANA Considerations section (Section 6.5) to mark
describing the encoding rules in section 3.10. codepoint 0 as "Reserved" for the Object-Type defined in this
document, as per Erratum ID 4956 for [RFC5440]. IANA references
have also been updated to point to this document.
o Updated the example in figure 7 to explicitly include the RP Appendix A.1. RBNF Changes from RFC 6006
object.
o Corrected the description of F-bit in the RP object in section o Updates to the RBNF for the request message format, per
3.13, as per the errata ID 3836. Erratum ID 4867:
o Corrected the description of fragmentation procedure for the * Updated the request message to allow for the bundling of
response in section 3.13.2, as per the errata ID 3819. multiple path computation requests within a single PCReq
message.
o Corrected the Error-Type in section 3.15 for fragmentation, as per * Added <svec-list> in PCReq messages. This object was missed in
the errata ID 3830. [RFC6006].
o Updated the references for OSPF Router Information Link State * Added the BNC object in PCReq messages. This object is
Advertisement (LSA) [RFC7770] and PCEP-MIB [RFC7420]. required to support P2MP. The BNC object shares the same
format as the IRO, but it only supports IPv4 and IPv6 prefix
sub-objects.
o Add updated information and references for PCEP YANG [I-D.ietf-pce- * Updated the <RRO-List> format to also allow the SRRO. This
pcep-yang] and PCEPS [I-D.ietf-pce-pceps]. object was missed in [RFC6006].
o Updated security considerations to include TCP-AO and TLS. * Removed the BANDWIDTH object followed by the RRO from
<RRO-List>. The BANDWIDTH object was included twice in
RFC 6006 -- once as part of <end-point-path-pair-list> and also
as part of <RRO-List>. The latter has been removed, and the
RBNF is backward compatible with [RFC5440].
o Updated IANA considerations to mark code-point 0 as reserved for * Updated the <end-point-rro-pair-list> to allow an optional
the object type defined in this document, as per the errata ID 4956. BANDWIDTH object only if <RRO-List> is included.
IANA references are also updated to point to this document.
Appendix A.1 RBNF Changes from RFC 6006 o Updates to the RBNF for the reply message format, per
Erratum ID 4868:
o Update to RBNF for Request message format: * Updated the reply message to allow for bundling of multiple
path computation replies within a single PCRep message.
* Update to the request message to allow for the bundling of * Added the UNREACH-DESTINATION object in PCRep messages. This
multiple path computation requests within a single Path object was missed in [RFC6006].
Computation Request (PCReq) message.
* Addition of <svec-list> in PCReq message. This object was missed Acknowledgements
in [RFC6006].
* Addition of BNC object in PCReq message. This object is required The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan,
to support P2MP. It shares the same format as Include Route Object Autumn Liu, Huaimo Chen, Eiji Oki, Nic Neate, Suresh Babu K, Gaurav
(IRO) but it is a different object. Agrawal, Vishwas Manral, Dan Romascanu, Tim Polk, Stewart Bryant,
David Harrington, and Sean Turner for their valuable comments and
input on this document.
* Update to the <RRO-List> format, to also allow Secondary Record Thanks to Deborah Brungard for handling related errata for RFC 6006.
Route object (SRRO). This object was missed in [RFC6006].
* Removed the BANDWIDTH Object followed by Record Route Object The authors would like to thank Jonathan Hardwick and Adrian Farrel
(RRO) from <RRO-List>. As BANDWIDTH object doesn't need to follow for providing review comments with suggested text for this document.
for each RRO in the <RRO-List>, there already exist BANDWIDTH
object follow <RRO-List> and is backward compatible with
[RFC5440].
* Update to the <end-point-rro-pair-list>, to allow optional Thanks to Jonathan Hardwick for being the document shepherd and for
BANDWIDTH object only if <RRO-List> is included. providing comments and guidance.
* Errata ID: 4867 Thanks to Ben Niven-Jenkins for RTGDIR reviews.
o Update the RBNF for Reply message format: Thanks to Roni Even for GENART reviews.
* Update to the reply message to allow for bundling of multiple Thanks to Fred Baker for the OPSDIR review.
path computation replies within a single Path Computation Reply
(PCRep) message.
* Addition of the UNREACH-DESTINATION in PCRep message. This Thanks to Deborah Brungard for being the responsible AD and guiding
object was missed in [RFC6006]. the authors.
* Errata ID: 4868 Thanks to Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Adam Roach,
Benoit Claise, Suresh Krishnan, and Eric Rescorla for their IESG
review and comments.
Contributors Contributors
Fabien Verhaeghe Fabien Verhaeghe
Thales Communication France Thales Communication France
160 Bd Valmy 92700 Colombes 160 boulevard Valmy
92700 Colombes
France France
EMail: fabien.verhaeghe@gmail.com Email: fabien.verhaeghe@gmail.com
Tomonori Takeda Tomonori Takeda
NTT Corporation NTT Corporation
3-9-11, Midori-Cho 3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Musashino-Shi, Tokyo 180-8585
Japan Japan
EMail: tomonori.takeda@ntt.com Email: tomonori.takeda@ntt.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
EMail: zali@cisco.com Email: zali@cisco.com
Julien Meuric Julien Meuric
Orange Orange
2, Avenue Pierre-Marzin 2, Avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
EMail: julien.meuric@orange.com Email: julien.meuric@orange.com
Jean-Louis Le Roux Jean-Louis Le Roux
Orange Orange
2, Avenue Pierre-Marzin 2, Avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
EMail: jeanlouis.leroux@orange.com Email: jeanlouis.leroux@orange.com
Mohamad Chaitou Mohamad Chaitou
France France
EMail: mohamad.chaitou@gmail.com Email: mohamad.chaitou@gmail.com
Udayasree Palle Udayasree Palle
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: udayasreereddy@gmail.com Email: udayasreereddy@gmail.com
Authors' Addresses Authors' Addresses
Quintin Zhao Quintin Zhao
Huawei Technology Huawei Technologies
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US United States of America
EMail: quintin.zhao@huawei.com
Dhruv Dhody Email: quintin.zhao@huawei.com
Huawei Technology
Dhruv Dhody (editor)
Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Ramanjaneya Reddy Palleti Ramanjaneya Reddy Palleti
Huawei Technology Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: ramanjaneya.palleti@huawei.com
Email: ramanjaneya.palleti@huawei.com
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK United Kingdom
EMail: daniel@olddog.co.uk
Email: daniel@olddog.co.uk
 End of changes. 293 change blocks. 
836 lines changed or deleted 874 lines changed or added

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