RFC 6006
Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
RFC 6006: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths 🌸
Part 1 of 6. More parts are coming, so stay tuned 🎀
okay bestie, the title block is giving main character energy ✨. This is an IETF Standards Track doc from September 2010 with ISSN 2070-1721, so it's officially a real spec and not just an opinion piece 💅. The editors (the "Ed." ones) are Q. Zhao from Huawei Technology and D. King from Old Dog Consulting. The other authors are F. Verhaeghe (Thales Communication France), T. Takeda (NTT Corporation), Z. Ali (Cisco Systems, Inc.), and J. Meuric (France Telecom). The title block doesn't list anything this one obsoletes or updates, so it's standing on its own 🦋
Abstract
okay so the abstract says point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) can be set up with signaling techniques, but their paths might first need to be figured out 🗺️. The Path Computation Element (PCE) is the tech that's been picked for working out the paths of point-to-multipoint (P2MP) TE LSPs, and it's honestly iconic 👑
This document describes extensions to the PCE communication Protocol (PCEP) so it can handle requests and responses for computing paths for P2MP TE LSPs 💖
Status of This Memo
this is an Internet Standards Track document 🔥
It's a product of the Internet Engineering Task Force (IETF), which means it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 🧚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6006 🫶
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stand on the date this document was published. Please review those documents carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🙈
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Without getting an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 💀
Table of Contents 📚
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. PCC-PCE Communication Requirements ..............................5
3. Protocol Procedures and Extensions ..............................6
3.1. P2MP Capability Advertisement ..............................6
3.1.1. P2MP Computation TLV in the Existing PCE
Discovery Protocol ..................................6
3.1.2. Open Message Extension ..............................7
3.2. Efficient Presentation of P2MP LSPs ........................7
3.3. P2MP Path Computation Request/Reply Message Extensions .....8
3.3.1. The Extension of the RP Object ......................8
3.3.2. The New P2MP END-POINTS Object ......................9
3.4. Request Message Format ....................................12
3.5. Reply Message Format ......................................12
3.6. P2MP Objective Functions and Metric Types .................13
3.6.1. New Objective Functions ............................13
3.6.2. New Metric Object Types ............................14
3.7. Non-Support of P2MP Path Computation ......................14
3.8. Non-Support by Back-Level PCE Implementations .............15
3.9. P2MP TE Path Reoptimization Request .......................15
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16
3.11. Discovering Branch Nodes .................................19
3.11.1. Branch Node Object ................................19
3.12. Synchronization of P2MP TE Path Computation Requests .....19
3.13. Request and Response Fragmentation .......................20
3.13.1. Request Fragmentation Procedure ...................21
3.13.2. Response Fragmentation Procedure ..................21
3.13.3. Fragmentation Examples ............................21
3.14. UNREACH-DESTINATION Object ...............................22
3.15. P2MP PCEP-ERROR Objects and Types ........................23
3.16. PCEP NO-PATH Indicator ...................................24
4. Manageability Considerations ...................................25
4.1. Control of Function and Policy ............................25
4.2. Information and Data Models ...............................25
4.3. Liveness Detection and Monitoring .........................25
4.4. Verifying Correct Operation ...............................25
4.5. Requirements for Other Protocols and Functional
Components ................................................26
4.6. Impact on Network Operation ...............................26
5. Security Considerations ........................................26
6. IANA Considerations ............................................27
6.1. PCEP TLV Type Indicators ..................................27
6.2. Request Parameter Bit Flags ...............................27
6.3. Objective Functions .......................................27
6.4. Metric Object Types .......................................27
6.5. PCEP Objects ..............................................28
6.6. PCEP-ERROR Objects and Types ..............................29
6.7. PCEP NO-PATH Indicator ....................................30
6.8. SVEC Object Flag ..........................................30
6.9. OSPF PCE Capability Flag ..................................30
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................321. Introduction ✨
the Path Computation Element (PCE) defined in [RFC4655] is an entity that can work out a network path or route based on a network graph, while applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed 🦋
[RFC4875] explains how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks 🌸
The PCE has been picked as a suitable app for computing paths for P2MP TE LSPs [RFC5671] 💜
The PCE communication Protocol (PCEP) is built as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations, and it's defined in [RFC5440]. Honestly though, that spec doesn't give a way to request path computation of P2MP TE LSPs, which is the gap this doc fills 🍓
okay so a P2MP LSP is made up of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs get set up between ingress and egress Label Switching Routers (LSRs) and overlaid so they build a P2MP TE LSP. During path computation, the P2MP TE LSP may be determined as a set of S2L sub-LSPs that get computed separately and then combined to give the path of the P2MP LSP. Or the entire P2MP TE LSP may be determined as a P2MP tree in one single computation 🧚
This document relies on the mechanisms of PCEP to request path computation for P2MP TE LSPs. One path computation request message from a PCC may ask for 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 extreme case, the PCC may request that the S2L sub-LSPs be computed individually, and then it's the PCC's responsibility to decide whether to signal individual S2L sub-LSPs or combine the computation results to signal the entire P2MP TE LSP 🫶 Hence the PCC may use one path computation request message, or it may split the request across multiple path computation messages ✨
1.1. Terminology
here's the terminology used in this document 📚
- TE LSP: Traffic Engineering Label Switched Path.
- LSR: Label Switching Router.
- OF: Objective Function. This is a set of one or more optimization criteria used for computing a single path (e.g., path cost minimization), or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization). Basically, it's the goals the algorithm is chasing 🎯
- P2MP: Point-to-Multipoint.
- P2P: Point-to-Point.
this document also uses the terminology defined in [RFC4655], [RFC4875], and [RFC5440] 🌈
1.2. Requirements Language
okay, now the important bit 🔥 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those words are the ones that carry the requirement force, so treat them seriously, bestie 🫶
2. PCC-PCE Communication Requirements 💖
okay so this section is basically the checklist of everything a PCC (the client asking for a path) and a PCE (the path computer) need to be able to do with each other for P2MP MPLS-TE LSPs, which is the one-to-many tunnel thing from [RFC5862] 🫶 the numbers match up with the requirement numbers in [RFC5862], so you can cross-check like a detective 🔍
- The PCC MUST be able to specify that the request is a P2MP path computation request. 💅
- The PCC MUST be able to specify that objective functions are to be applied to the P2MP path computation request. 🎯
- The PCE MUST have the capability to reject a P2MP path request and indicate non-support of P2MP path computation. 🙅♀️
- The PCE MUST provide an indication of non-support of P2MP path computation by back-level PCE implementations. 🕰️
- A P2MP path computation request MUST be able to list multiple destinations. 🌸
- A P2MP path computation response MUST be able to carry the path of a P2MP LSP. 🦋
- By default, the path returned by the PCE SHOULD use the compressed format. 🗜️
- It MUST be possible for a single P2MP path computation request or response to be conveyed by a sequence of messages. 💌
- It MUST NOT be possible for a single P2MP path computation request to specify a set of different constraints, traffic parameters, or quality-of-service requirements for different destinations of a P2MP LSP. 🚫 this one is giving "no drama allowed," bestie 💀
- P2MP path modification and P2MP path diversity MUST be supported. 🔥
- It MUST be possible to reoptimize existing P2MP TE LSPs. ✨
- It MUST be possible to add and remove P2MP destinations from existing paths. 🧚
- It MUST be possible to specify a list of applicable branch nodes to use when computing the P2MP path. 🌳
- It MUST be possible for a PCC to discover P2MP path computation capability. 🔎
- The PCC MUST be able to request diverse paths when requesting a P2MP path. 🌈
3. Protocol Procedures and Extensions 🎀
okay this is the part where we actually build the stuff ✨ this section describes the protocol extensions that make all those requirements from Section 2 ("PCC-PCE Communication Requirements") of this document actually happen 💜
3.1. P2MP Capability Advertisement 📣
3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 🔍
so [RFC5088] defines a PCE Discovery (PCED) TLV that rides inside an OSPF Router Information Link State Advertisement (LSA) from [RFC4970], which is how PCEs get discovered over OSPF 🛰️ [RFC5088] says no new sub-TLVs may be added to the PCED TLV, so we can't just tack stuff on 🙅♀️ instead this document defines a new flag in the OSPF PCE Capability Flags to say "hey, I can do P2MP computation" 🎉
[RFC5089] does the same kind of thing for IS-IS with the PCED sub-TLV 🧠 this document is going to use the same flag requested for the OSPF PCE Capability Flags sub-TLV so IS-IS can show P2MP computation capability too, which is honestly so efficient 😭
the IANA assignment for the shared OSPF and IS-IS P2MP Capability Flag is documented in Section 6.9 ("OSPF PCE Capability Flag") of this document 📋
PCEs that want to advertise P2MP path computation support would set the bit (10) accordingly 🌟 PCCs that don't understand this bit will ignore it (per [RFC5088] and [RFC5089]) 🙈 and PCEs that don't support P2MP will leave the bit clear (per the default behavior defined in [RFC5088] and [RFC5089]) 🧼
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 Object") to further qualify the level of support. ⚠️
3.1.2. Open Message Extension 🚪
based on the Capabilities Exchange requirement described in [RFC5862], if a PCE doesn't advertise its P2MP capability during discovery, PCEP should be used to let a PCC find out, during the Open Message Exchange, which PCEs can handle P2MP path computation 🕵️♀️
to make that work, we extend the PCEP OPEN object by defining a new optional TLV that shows the PCE's capability to do P2MP path computations 💅
IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub-registry, as documented in Section 6.1 ("PCEP TLV Type Indicators") 🎀 the description is "P2MP capable", the length value is 2 bytes, and the value field is set to default value 0 🌸
including this TLV in an OPEN object tells the other side that the sender can do P2MP path computations 🦋
the capability TLV only really matters for a PCE, so it'll usually only show up in one of the two Open messages during PCE session establishment ✨ but in the case of PCE cooperation (e.g., inter-domain), when a PCE acting as a PCC starts a PCE session it SHOULD also indicate its path computation capabilities 🌐
3.2. Efficient Presentation of P2MP LSPs 🧚
when you're adding extra leaves, or optimizing existing P2MP TE LSPs as specified in [RFC5862], it may be necessary to pass the existing P2MP LSP route info between the PCC and PCE in the request and reply messages 🗺️ in each of these scenarios we need new path objects so the existing P2MP LSP can be passed efficiently between the PCE and PCC 🫶
we use the RSVP-TE extension Explicit Route Object (ERO) to encode the explicit route of a TE LSP through the network 🛤️ PCEP ERO sub-object types line up with RSVP-TE ERO sub-object types 💜 the format and content of the ERO object are defined in [RFC3209] and [RFC3473] 📖
the Secondary Explicit Route Object (SERO) is used to specify the 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 🎀 and the format of the SERO is the same as an ERO defined in [RFC3209] and [RFC3473] ✨
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 same as the SRRO defined in [RFC4873] 🙌
the SERO and SRRO are used to report the route of an existing TE LSP that you want to reoptimize 🔁 the format and content of the SERO and SRRO are defined in [RFC4875] 💖
a new PCEP object class and type are requested for SERO and SRRO 🙏
Object-Class Value 29
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference RFC 6006
Object-Class Value 30
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference RFC 6006the IANA assignment is documented in Section 6.5 ("PCEP Objects") 📋
since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to the ones defined for the ERO 🧠⚡
3.3. P2MP Path Computation Request/Reply Message Extensions 💌
this document extends the existing P2P RP (Request Parameters) object so a PCC can signal a P2MP path computation request to the PCE receiving the PCEP request 📨 the END-POINTS object is also extended so the message exchange between PCC and PCE is more efficient for P2MP path computation 🚀
3.3.1. The Extension of the RP Object 🎁
the PCE path computation request and reply messages need a few extra parameters so the receiving PCE knows that the message got fragmented across multiple messages, that it's asking for a P2MP path, and whether the route is in compressed or uncompressed format 🧩
this document adds the following flags to the RP Object 🏳️🌈
the F-bit is added to the flag bits of the RP object so the receiver can tell whether the request is part of a fragmented request or not 🧵
- F (RP fragmentation bit - 1 bit):
- 0: this means the RP is not fragmented, or it's the last piece of the fragmented RP 🏁
- 1: this means the RP is fragmented and this is not the last piece. the receiver has to wait for more fragments until it gets an RP with the same RP-ID and the F-bit set to 0 ⏳
the N-bit is added in the flag bits field of the RP object to tell the receiver whether the request/reply is for P2MP or not for P2MP 🎯
- N (P2MP bit - 1 bit):
- 0: this means this is not a PCReq or PCRep message for P2MP 🙅♀️
- 1: this means this is a PCReq or PCRep message for P2MP 🌟
the E-bit is added in the flag bits field of the RP object to tell the receiver whether the route is in the compressed format or not 🗜️ by default, the path returned by the PCE SHOULD use the compressed format 💅
- E (ERO-compression bit - 1 bit):
- 0: this means the route is not in the compressed format 🙃
- 1: this means the route is in the compressed format ✨
the IANA assignment is documented in Section 6.2 ("Request Parameter Bit Flags") of this document 📋🫶
3.3.2. The New P2MP END-POINTS Object ✨
okay so the END-POINTS object is what a PCReq message uses to say where a path starts (source IP) and where it ends (destination IP) 🧭 for the path we want computed. for P2MP paths we get two brand-new flavors of END-POINTS, and they're honestly so iconic:
- Old leaves whose path can be modified/reoptimized 🔄
- Old leaves whose path must be left unchanged 🔒
the new END-POINTS object lets one request message list a bunch of destinations at once, which is giving efficiency 💖
there are now 4 leaf types in a P2MP request, and I'm not gonna lie, the numbering is a whole vibe:
- New leaves to add (leaf type = 1) 🌱
- Old leaves to remove (leaf type = 2) 🗑️
- Old leaves whose path can be modified/reoptimized (leaf type = 3) ✨
- Old leaves whose path must be left unchanged (leaf type = 4) 🧊
each END-POINTS object only holds leaves of one type, and that type is saved in its END-POINTS leaf type field 🎀
the best part: when a single source has a huge pile of destinations, the END-POINTS part of the request can shrink by up to 50% 📉 literally so efficient 😭
also, a P2MP request can mix leaf types by putting several END-POINTS objects in one RP object, which you can see in the PCReq RBNF format in Section 3.4 ("Request Message Format") 🧩
the IPv4 version (Object-Type 3) looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1. The New P2MP END-POINTS Object Body Format for IPv4
the IPv6 version (Object-Type 4) is next, and it's a little bigger 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source 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
size check: the END-POINTS body is variable length 📏 it's in multiples of 4 bytes for IPv4, and multiples of 16 bytes plus 4 bytes for IPv6 🫶
3.4. Request Message Format
the PCReq message gets encoded with RBNF as defined in [RFC5511] 📝 here's the request message format:
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]Figure 3. The Message Format for the Request Message
compatibility is preserved with the [RFC5440] definition of <request> 🤝 and at least one instance of <endpoints> MUST be present in this message 🚨
we also wrote down the IANA assignment of the extra END-POINTS Object-Types in Section 6.5 ("PCEP Objects") of this document 📋
3.5. Reply Message Format
the PCRep message is encoded with RBNF as defined in [RFC5511] 💅 here's the reply message format:
<PCRep Message>::= <Common Header>
<response>
<response>::=<RP>
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
<end-point-path-pair-list>::=
[<END-POINTS>]<path>[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]Figure 4. The Message Format for the Reply Message
the optional END-POINTS object in a reply is how the PCE says which paths got removed, changed, left alone, or added for the request 🔍 the path only shows up for endpoints that were added or changed 🛤️
if the E-bit (ERO-Compress bit) was set to 1 in the request, then the path is an ERO followed by a list of SEROs 🪄
compatibility again: we keep [RFC5440]'s definition of <response>, plus the optional <end-point-path-pair-list> and <path> 💖
3.6. P2MP Objective Functions and Metric Types
3.6.1. New Objective Functions
six objective functions were already defined in [RFC5541] for P2P path computation 🎯 this document adds two more, SPT (Shortest Path Tree) and MCT (Minimum Cost Tree), that apply to P2MP path computation 🌳 so we need two new objective function codes ✨
here's the deal with each one:
Objective Function Code: 7
Name: Shortest Path Tree (SPT)
Description: Minimize the maximum source-to-leaf cost with respect 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).
Objective Function Code: 8
Name: Minimum Cost Tree (MCT)
Description: Minimize the total cost of the tree, that is the sum of the costs of tree links, with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified.
processing these two new objective functions follows the rules in [RFC5541] 🧠
3.6.2. New Metric Object Types
the <METRIC> object already has three types in [RFC5440]: the IGP metric, the TE metric, and the hop count metric 📏 this document adds three more P2MP versions: the P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric 🌈 each one encodes the sum of the metrics of all links in the tree 🌲 the values we propose for these new metric types are:
- P2MP IGP metric:
T=8🍓 - P2MP TE metric:
T=9🫧 - P2MP hop count metric:
T=10💜
3.7. Non-Support of P2MP Path Computation
- if a PCE gets a P2MP path request and understands the P2MP flag in the RP object, but isn't capable of P2MP computation 🙅♀️, the PCE MUST send a PCErr message with a PCEP-ERROR object and the matching Error-Value 💀 the request MUST then be cancelled at the PCC. new Error-Types and Error-Values are requested in Section 6 ("IANA Considerations") of this document 📝
- if the PCE doesn't understand the P2MP flag in the RP object, then the PCE MUST send a PCErr message with
Error-value=2(capability not supported) 🙈
3.8. Non-Support by Back-Level PCE Implementations
this one's a little bit of a plot twist 😤 if a PCE receives a P2MP request and doesn't understand the P2MP flag in the RP object (and therefore the PCEP P2MP extensions), then the PCE SHOULD reject the request 🛑
3.9. P2MP TE Path Reoptimization Request
a reoptimization request for a P2MP TE path uses the R-bit within the RP object, as defined in [RFC5440] 🔁 it's basically the same as reoptimizing a P2P TE path 💅 the only real difference is that the user MUST insert the list of RROs and SRROs after each type of END-POINTS in the PCReq message, as described in the "Request Message Format" section (Section 3.4) of this document 🫶
here's an example of a reoptimization request and the PCReq message that follows 👀
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 3
RRO list
OF (optional)Figure 5. PCReq Message Example 1 for Optimization
in this example, we ask for the path to every leaf to be reoptimized without adding or pruning any leaves ✨ the reoptimization request would use an END-POINT type 3 🎀 the RRO list would represent the P2MP LSP before the optimization, and the leaves whose paths can be modified would be marked in the END-POINTS object 🧩
it's also possible to name specific leaves whose path can't be modified 🙅♀️ an example of the PCReq message for that situation looks like this:
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)Figure 6. PCReq Message Example 2 for Optimization 🌸
3.10. Adding and Pruning Leaves to/from the P2MP Tree ✨
okay so, adding new leaves to or yeeting old leaves from an existing P2MP tree, by handing over a list of the existing leaves, SHOULD be possible to optimize that tree. 🌳 this section is the explainer for how to add and prune leaves, bestie 💖
to add new leaves, the user MUST build a P2MP request using END-POINTS with leaf type 1. 🎀
to remove old leaves, the user must build a P2MP request using END-POINTS with leaf type 2. ✂️ if there are no type-2 END-POINTS at all, then the PCE MUST send an error type 17, value=1: "The PCE is not capable of satisfying the request due to no END-POINTS with leaf type 2." 💀
when you're 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, including END-POINTS with leaf type 3, leaf type 4, or both. 🫶 there are brand new PCEP-ERROR objects and types for reporting when certain conditions aren't met (like when there are no END-POINTS with leaf type 3 or 4, or when you've got END-POINTS with leaf type 1 or 2 showing up in the wrong spot). 😭 a generic "Inconsistent END-POINT" error gets used if a PCC receives a request with an inconsistent END-POINT (aka a leaf marked as type 1 that already exists 🙈). all of these IANA assignments are documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this document. 🌸
for old leaves, the user MUST provide the old path as a list of RROs that immediately follows each END-POINTS object. 🧚 this document also spells out error values for when specific conditions aren't satisfied. 💅
here are the examples showing full and partial reoptimization of existing P2MP LSPs. 🦋
Case 1: Adding leaves with full reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 1
RRO list
END-POINTS for leaf type 3
RRO list
OF (optional)Case 2: Adding leaves with partial reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 1
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)Case 3: Adding leaves without reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 1
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)Case 4: Pruning Leaves with full reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
OF (optional)Case 5: Pruning leaves with partial reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)Case 6: Pruning leaves without reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)Case 7: Adding and pruning leaves with full reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 1
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
OF (optional)Case 8: Adding and pruning leaves with partial reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 1
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 3
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)Case 9: Adding and pruning leaves without reoptimization of existing paths
Common Header
RP with P2MP flag/R-bit set
END-POINTS for leaf type 1
END-POINTS for leaf type 2
RRO list
END-POINTS for leaf type 4
RRO list
OF (optional)3.11. Discovering Branch Nodes 🔍
before computing the P2MP path, a PCE may need to be given a way to know which nodes in the network are capable of acting as branch LSRs. 🧠 a PCE can discover those capabilities by using the mechanisms defined in [RFC5073]. ✨
3.11.1. Branch Node Object 🌿
the PCC can specify a list of nodes that CAN be used as branch nodes, or a list of nodes that CANNOT, by using the Branch Node Capability (BNC) Object. 🪄 the BNC Object has the same format as the Include Route Object (IRO) defined in [RFC5440], except that it only supports IPv4 and IPv6 prefix sub-objects. two Object-types are also defined:
- Branch node list: List of nodes that can be used as branch nodes.
- Non-branch node list: List of nodes that cannot be used as branch nodes.
the object can only be carried in a PCReq message. 📨 a Path Request may carry at most one Branch Node Object. 🫵
the Object-Class and Object-types have been allocated by IANA. 🎟️ the IANA assignment is documented in Section 6.5 ("PCEP Objects"). 🌸
3.12. Synchronization of P2MP TE Path Computation Requests 👯
there are cases where multiple P2MP LSPs' computations need to be synchronized. 🔗 for example, one P2MP LSP is the designated backup of another P2MP LSP. 🛟 in this case, path diversity for these dependent LSPs may need to be considered during the path computation. 🌈
the synchronization can be done by using the existing Synchronization VECtor (SVEC) functionality defined in [RFC5440]. 💕
here's an example of synchronizing two P2MP LSPs, each having two leaves, for Path Computation Request Messages:
Common Header
SVEC for sync of LSP1 and LSP2
OF (optional)
END-POINTS1 for P2MP
RRO1 list
END-POINTS2 for P2MP
RRO2 listFigure 7. PCReq Message Example for Synchronization 🎀
this specification also defines two new flags in the SVEC Object Flag Field for P2MP path dependent computation requests. 🦋 the first new flag lets the PCC request that the PCE compute a secondary P2MP path tree with partial path diversity for specific leaves, or for a specific S2L sub-path, relative to the primary P2MP path tree. 🔥 the second flag would let the PCC request that partial paths be link direction diverse. 🧭
the following flags are added to the SVEC object body in this document:
- P (Partial Path Diverse bit - 1 bit):
When set, this would indicate a request for path diversity for a specific leaf, a set of leaves, or all leaves. 💖
- D (Link Direction Diverse bit - 1 bit):
When set, this would indicate a request that a partial path or paths should be link direction diverse. ✨
the IANA assignment is referenced in Section 6.8 of this document. 📋
3.13. Request and Response Fragmentation 🧩
the total PCEP message length, including the common header, is 16 bytes. 🤏 in certain scenarios, the P2MP computation request may not fit into a single request or response message. 😩 for example, if a tree has many hundreds or thousands of leaves, then the request or response may need to be fragmented into multiple messages. 📦
the F-bit has been outlined in "The Extension of the RP Object" (Section 3.3.1) of this document. 🏷️ the F-bit is used in the RP object header to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. 🧵 to identify the single request or response, each message will use the same request ID. 🆔
3.13.1. Request Fragmentation Procedure ✂️
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 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 multiple messages. 🚩 to identify that a series of request messages represents a single request, each message will use the same request ID. 🆔
the assumption is that request messages are reliably delivered and in sequence, since PCEP relies on TCP. 🛤️
3.13.2. Response Fragmentation Procedure 📬
once the PCE computes a path based on the initial request, a response is sent back to the PCC. 🔙 if the response is too large to fit into a single response message, the PCE will split the response over multiple messages. 🪄 each message sent to the PCE, except the last one, will have the F-bit set in the RP object to signify that the response has been fragmented into multiple messages. 🏁 to identify that a series of response messages represents a single response, each message will use the same response ID. 🆔
again, the assumption is that response messages are reliably delivered and in sequence, since PCEP relies on TCP. 🫶
3.13.3. Fragmentation Examples 🎬
the following example shows the PCC sending a request message 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 request message can hold up to 800 leaves. 🧮 in this scenario, the original single message needs to be fragmented and sent using two smaller messages, which have Req-ID1 specified in the RP object, with the F-bit set on the first message and cleared on the second message. 🎯
Common Header
RP1 with Req-ID1 and P2MP=1 and F-bit=1
OF (optional)
END-POINTS1 for P2MP
RRO1 list
Common Header
RP2 with Req-ID1 and P2MP=1 and F-bit=0
OF (optional)
END-POINTS1 for P2MP
RRO1 listFigure 8. PCReq Message Fragmentation Example 🌸
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 receives the first piece of the fragmented message. ⏰ when the timer expires and it has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message. 🚨 the relevant error message is documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). 💜
3.14. UNREACH-DESTINATION Object ✨
okay so sometimes a PCE path computation request just fails bc all of the destinations, or some of them, are unreachable 😭. when that happens, the UNREACH-DESTINATION object lets the PCE optionally list which destinations are unreachable 🧚.
this object can show up in PCRep messages, and there can be up to one per RP 💅.
these are the UNREACH-DESTINATION objects that will be required:
UNREACH-DESTINATION Object-Class is 28.
UNREACH-DESTINATION Object-Type for IPv4 is 1.
UNREACH-DESTINATION Object-Type for IPv6 is 2.the IPv4 version (Object-Type=1) is laid out like this 🎀:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9. UNREACH-DESTINATION Object Body for IPv4
and the IPv6 one (Object-Type=2) looks like this 🦋:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10. UNREACH-DESTINATION Object Body for IPv6
3.15. P2MP PCEP-ERROR Objects and Types 🚨
for policy violations, a brand new error value, "P2MP Path computation not allowed", should be added to the existing policy violation error code (Error-Type=5) defined in [RFC5440] 💅:
Error-Type=5; Error-Value=7: if a PCE gets a P2MP path computation request that doesn't match the administrative privileges (aka "The PCE policy does not support P2MP path computation"), the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5) and an Error-Value (Error-Value=7). the matching P2MP path computation request MUST also be cancelled 🙈.
for capability errors on a P2MP path request, there's a new Error-Type (16) plus its own error values, to go inside the PCEP-ERROR object 🌈:
Error-Type=16; Error-Value=1: if a PCE gets a P2MP path request but doesn't have enough memory to satisfy it, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error-Value (Error-Value=1). the matching P2MP path computation request MUST also be cancelled 💀.
Error-Type=16; Error-Value=2: if a PCE gets a P2MP path request but it can't do P2MP computation at all, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error-Value (Error-Value=2). the matching P2MP path computation request MUST also be cancelled 🫶.
for P2MP message fragmentation problems on a P2MP path request, there's a new Error-Type (17) with its own error values, also for the PCEP-ERROR object ✨:
Error-Type=18; Error-Value=1: if a PCE hasn't received the last piece of a fragmented message, it should send an error message to the sender saying it got an incomplete message (aka "Fragmented request failure"). The PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=18) and an Error-Value (Error-Value=1) 😭.
3.16. PCEP NO-PATH Indicator 🦋
when a PCE can't find a P2MP path computation, the NO-PATH object can be used in the PCRep message to explain why 🍓.
one new bit is defined in the NO-PATH-VECTOR TLV that lives inside the NO-PATH Object:
bit 24: when it's set, the PCE is saying there's a reachability problem with all or some of the P2MP destinations. optionally, the PCE can also name the destination, or list of destinations, that can't be reached, using the brand new UNREACH-DESTINATION object from Section 3.14 🔥.
4. Manageability Considerations 🧚
[RFC5862] describes a bunch of manageability requirements for P2MP path computation when you're applying PCEP 💜. this section explains how those requirements from [RFC5862] are handled by the PCEP extensions in this document.
heads up: [RFC5440] already covers a lot of manageability stuff for PCEP, so most of what [RFC5862] asks for is already sorted there 💅.
4.1. Control of Function and Policy
on top of the PCE configuration parameters listed in [RFC5440], these extra parameters might be needed:
- the ability to turn P2MP path computations on or off on the PCE.
- the PCE can be configured to turn on or off the advertisement of its P2MP path computation capability. a PCE can advertise its P2MP capability through the IGP discovery mechanism in Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery Protocol"), or during the Open Message Exchange in Section 3.1.2 ("Open Message Extension") 🌸.
4.2. Information and Data Models
a bunch of MIB objects already exist for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] says MIB objects will be needed to control and monitor the protocol extensions in this document. a new document will be needed to define the MIB objects for PCEP control and monitoring of P2MP computations 📚.
4.3. Liveness Detection and Monitoring
nothing extra here beyond what [RFC5440] already says, because [RFC5862] doesn't bring up any additional requirements 🫶.
4.4. Verifying Correct Operation
there are no additional requirements beyond those in [RFC4657] for checking that PCEP sessions are working correctly 🔍. future MIB objects are expected to make it easier to verify correct operation and report P2MP PCEP requests, responses, and errors ✨.
4.5. Requirements for Other Protocols and Functional Components
the way a PCE finds out about a PCE that can do P2MP path computations, via OSPF and IS-IS, is covered in Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery Protocol") of this document 🛸.
the subsequent IANA assignments are documented in Section 6.9 ("OSPF PCE Capability Flag") of this document 🎀.
4.6. Impact on Network Operation
it's expected that using the PCEP extensions in this document won't noticeably increase the level of operational traffic. however, computing a P2MP tree may need more PCE state than a P2P computation does 🧠. if there's a major network failure and a bunch of recovery P2MP tree computation requests get sent to the PCE all at once, the load on the PCE can also spike a lot 😭.
5. Security Considerations 🔐
as [RFC5862] explains, P2MP path computation requests are more CPU-intensive and also use more link bandwidth 💻. if there's an unauthorized P2MP path computation request, or a denial of service attack, the PCEP requests and processing that follow can be disruptive to the network 🚨. so it's really important that implementations follow the relevant security requirements of [RFC5440] that help minimize or stop unauthorized P2MP path computation requests and denial of service attacks. those mechanisms include:
- securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]).
- authenticating the PCEP requests and responses so you know the message is intact and came from an authorized node (Section 10.3 of [RFC5440]).
- policy control, by explicitly defining which PCCs are allowed to send P2MP path requests to the PCE, using IP access-lists (Section 10.6 of [RFC5440]).
PCEP runs over TCP, so it's also important to protect the PCE and PCC against TCP denial of service attacks 🛡️. Section 10.7.1 of [RFC5440] lays out a bunch of ways to lower the risk of TCP-based denial of service attacks against PCEs and PCCs.
PCEP implementations SHOULD consider the extra security that the TCP Authentication Option (TCP-AO) [RFC5925] provides 🔑.
6. IANA Considerations 🌷
IANA keeps a registry of PCEP parameters. a bunch of IANA considerations were already flagged in earlier sections of this document, and IANA has made the following allocations 📋.
6.1. PCEP TLV Type Indicators
as Section 3.1.2. explains, the brand new P2MP capability TLV lets the PCE advertise its P2MP path computation capability. IANA has allocated the following from the "PCEP TLV Type Indicators" sub-registry 💖:
Value Description Reference
6 P2MP capable RFC 60066.2. Request Parameter Bit Flags
as Section 3.3.1 explains, three new RP Object Flags have been defined. IANA has made the following allocations from the PCEP "RP Object Flag Field" sub-registry 🏳️🌈:
Bit Description Reference
18 Fragmentation (F-bit) RFC 6006
19 P2MP (N-bit) RFC 6006
20 ERO-compression (E-bit) RFC 60066.3. Objective Functions
as Section 3.6.1 explains, two new Objective Functions have been defined. IANA has made the following allocations from the PCEP "Objective Function" sub-registry 🎯:
Code Point Name Reference
7 SPT RFC 6006
8 MCT RFC 60066.4. Metric Object Types
as Section 3.6.2 explains, three new metric object T fields have been defined. IANA has made the following allocations from the PCEP "METRIC Object T Field" sub-registry 📏:
Value Description Reference
8 P2MP IGP metric RFC 6006
9 P2MP TE metric RFC 6006
10 P2MP hop count metric RFC 60066.5. PCEP Objects
okay so, as we talked about in Section 3.3.2, there are two brand new END-POINTS Object-Types 🎀 IANA gave them spots in the "PCEP Objects" sub-registry like this:
Object-Class Value 4
Name END-POINTS
Object-Type 3: IPv4
4: IPv6
5-15: Unassigned
Reference RFC 6006As described in Section 3.2, Section 3.11.1, and Section 3.14, four PCEP Object-Classes and six PCEP Object-Types got defined 🧚 and IANA handed out these allocations from the "PCEP Objects" sub-registry:
Object-Class Value 28
Name UNREACH-DESTINATION
Object-Type 1: IPv4
2: IPv6
3-15: Unassigned
Reference RFC 6006
Object-Class Value 29
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference RFC 6006
Object-Class Value 30
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference RFC 6006
Object-Class Value 31
Name Branch Node Capability Object
Object-Type 1: Branch node list
2: Non-branch node list
3-15: Unassigned
Reference RFC 60066.6. PCEP-ERROR Objects and Types
As described in Section 3.15, a bunch of new PCEP-ERROR Object Error Types and Values showed up 😭 IANA then made these allocations in the PCEP "PCEP-ERROR Object Error Types and Values" sub-registry:
Error
Type Meaning Reference
5 Policy violation
Error-value=7: RFC 6006
P2MP Path computation is not allowed
16 P2MP Capability Error
Error-Value=0: Unassigned RFC 6006
Error-Value=1: RFC 6006
The PCE is not capable to satisfy the request
due to insufficient memory
Error-Value=2: RFC 6006
The PCE is not capable of P2MP computation
17 P2MP END-POINTS Error
Error-Value=0: Unassigned RFC 6006
Error-Value=1: RFC 6006
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 2
Error-Value=2: RFC 6006
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 3
Error-Value=3: RFC 6006
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 4
Error-Value=4: RFC 6006
The PCE is not capable to satisfy the request
due to inconsistent END-POINTS
18 P2MP Fragmentation Error
Error-Value=0: Unassigned RFC 6006
Error-Value=1: RFC 6006
Fragmented request failure6.7. PCEP NO-PATH Indicator
As discussed in Section 3.16, there's a new NO-PATH-VECTOR TLV Flag Field, and it's giving main character 💜 IANA assigned one bit from the PCEP "NO-PATH-VECTOR TLV Flag Field" sub-registry:
Bit Description Reference
24 P2MP Reachability Problem RFC 60066.8. SVEC Object Flag
As discussed in Section 3.12, two new SVEC Object Flags are defined 🦋 IANA gave out these from the PCEP "SVEC Object Flag Field" sub-registry:
Bit Description Reference
19 Partial Path Diverse RFC 6006
20 Link Direction Diverse RFC 60066.9. OSPF PCE Capability Flag
As discussed in Section 3.1.1, a new OSPF Capability Flag is defined to signal P2MP path computation capability 🌸 IANA made this one assignment in the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry:
Bit Description Reference
10 P2MP path computation RFC 60067. Acknowledgements
The authors wanted to thank a whole squad 🫶 Adrian Farrel, Young Lee, Dan Tappan, 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 this document. Iconic behaviour, honestly 👑
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R.,
and S. Shaffer, "Extensions to OSPF for Advertising
Optional Router Capabilities", RFC 4970, July 2007.
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
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.
Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, January 2008.
[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, January 2008.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation Element (PCE) Communication Protocol (PCEP)",
RFC 5440, March 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)",
RFC 5671, October 2009.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients
(PCC) - Path Computation Element (PCE) Requirements for
Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and D. King, "PCE
communication protocol (PCEP) Management Information
Base", Work in Progress, July 2010.Contributors
Jean-Louis Le Roux
France Telecom
2, Avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: jeanlouis.leroux@orange-ftgroup.com
Mohamad Chaitou
France
EMail: mohamad.chaitou@gmail.comAuthors' Addresses
Quintin Zhao (editor)
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
EMail: qzhao@huawei.com
Daniel King (editor)
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Fabien Verhaeghe
Thales Communication France
160 Bd Valmy 92700 Colombes
France
EMail: fabien.verhaeghe@gmail.com
Tomonori Takeda
NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585
Japan
EMail: takeda.tomonori@lab.ntt.co.jp
Zafar Ali
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: zali@cisco.com
Julien Meuric
France Telecom
2, Avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: julien.meuric@orange-ftgroup.com📦 where this page comes from
- ietf: rfc6006 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms