RFC 5541
Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
RFC 5541 🦋 Part 1 of 4 💅
okay bestie, so this is RFC 5541, Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) 🎀. It's dated June 2009 and it's a Standards Track doc, so it's a real spec, not just vibes. The authors are JL. Le Roux (France Telecom), JP. Vasseur (Cisco System Inc.), and Y. Lee (Huawei) 👑. It doesn't list anything it obsoletes or updates, so it stands on its own ✨.
Status of This Memo
okay so this doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send ideas for making it better 💬. If you want to know where this protocol is in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And yes, distribution is totally unlimited 🌈.
Copyright Notice
this part is giving legal realness 🧾. It's Copyright (c) 2009 IETF Trust and the persons identified as the document authors, and all rights are reserved 🔒. It's subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the publication date. You can find those at http://trustee.ietf.org/license-info, and honestly you should read them, because they explain your rights and restrictions 📜.
ngl the tea here is about older material. This doc might include stuff from IETF Documents or IETF Contributions published before November 10, 2008 🫖. Some of that copyright might belong to people who never gave the IETF Trust permission to allow changes outside the IETF Standards Process 😭. So unless you get a proper license from whoever controls that copyright, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.
Abstract
okay so the big picture: the computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks follows one or more specific optimization criteria 🎯. Those are called objective functions, like minimum cost path or widest path 💸.
In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) might want a path computed for one or more TE LSPs using a specific objective function ✨. So the PCC has to tell the PCE which objective function to use 🫶. Here's the plot twist: not every PCE supports the same objective functions 😳. That's why it's useful for the PCC to automatically discover which objective functions each PCE supports 🔍.
This document extends the PCE communication Protocol (PCEP) so a PCE can say which objective functions it supports 📢. It also covers how a PCC can request a specific objective function in a path computation request, and how a PCE can report the objective function it actually used in the path computation reply 💅.
It defines objective function code types for six objective functions from the PCE requirements work, and it defines four new metric types that apply to a set of synchronized requests 🔥.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
1.2. Terminology ................................................5
1.3. Message Formats ............................................6
2. Discovery of PCE Objective Functions ............................6
2.1. OF-List TLV ................................................6
2.2. Elements of Procedure ......................................7
3. Objective Function in PCEP Path Computation Request and Reply
Messages ........................................................7
3.1. OF Object ..................................................7
3.1.1. Elements of Procedure ...............................8
3.2. Carrying The OF Object In a PCEP Message ...................9
3.3. New RP Object Flag ........................................12
3.3.1. Elements Of Procedure ..............................12
4. Objective Functions Definition .................................13
5. New Metric Types ...............................................14
6. IANA Considerations ............................................15
6.1. PCE Objective Function Sub-Registry .......................15
6.2. PCEP Code Points ..........................................16
6.2.1. OF Object ..........................................16
6.2.2. OF-List TLV ........................................16
6.2.3. PCEP Error Values ..................................16
6.2.4. RP Object Flag .....................................17
6.2.5. Metric Types .......................................17
7. Security Considerations ........................................17
8. Manageability Considerations ...................................18
8.1. Control of Function and Policy ............................18
8.2. Information and Data Models ...............................18
8.3. Liveness Detection and Monitoring .........................18
8.4. Verify Correct Operations .................................18
8.5. Requirements On Other Protocols ...........................19
8.6. Impact On Network Operations ..............................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. RBNF Code Fragments ...................................211. Introduction ✨
okay so the Path Computation Element-based architecture [RFC4655] defines a PCE as an entity that can compute the paths of TE LSPs based on a network graph and apply computational constraints 🧠. A PCE handles path computation requests sent by PCCs 💌.
The PCE communication Protocol (PCEP), defined in [RFC5440], lets a PCC talk to a PCE, or two PCEs talk to each other 🗣️. This follows the requirements and guidelines in [RFC4657] 📋. The conversations include path computation requests and path computation replies 💬.
Computing one or a set of TE LSPs comes with one or more optimization criteria, called an objective function 🎯. The PCE uses it when it computes a path or a set of paths so it can pick the "best" candidates 🏆. There are lots of objective functions 🌈. One could apply to a set of non-synchronized path computation requests, or to a set of synchronized path computation requests 🔀.
In the non-synchronized case, the objective function looks at one individual path computation request. Examples are computing the shortest constrained path where the metric is the IGP metric, or the least loaded constrained path 🛤️. In the synchronized case, the objective function covers a set of requests that get computed together. Examples are minimizing the aggregate bandwidth consumption of all LSPs, or minimizing the sum of the delays for two diverse paths, or the delta between those delays 🫠. Some objective functions optimize a single metric, and others optimize a set of metrics, organized hierarchically or with a weighted function 🧁.
As [RFC4674] spells out, it can be useful for a PCC to discover which objective functions a PCE supports 🔎. [RFC4657] also requires that a PCC can indicate a required or desired objective function in a path computation request, along with any optional function parameters 🎀.
So this document extends PCEP for those purposes 💖. It defines PCEP extensions that let a PCE advertise its supported objective functions, plus extensions that carry the objective function in PCEP request and reply messages 🫶. It complements the PCEP base spec [RFC5440] 🧩.
Quick side note: the OSPF- and IS-IS-based PCE discovery mechanisms are in [RFC5088] and [RFC5089] 🛰️. Those are for discovering a few generic parameters. More detailed PCE parameters should be discovered through the PCE communication Protocol 🕵️. Objective functions are in that second category, so PCEP handles objective function discovery 🙌.
A new PCEP TLV, the OF-List TLV, is defined in Section 2 📝. It rides inside the PCEP OPEN object and lets a PCE list, during the PCEP session-setup phase, the objective functions it supports 🌸.
A new PCEP object, the OF object, is defined in Section 3 🧚. It goes inside a PCReq (Path Computation Request) message to say which objective function the PCE should apply. It can also go inside a PCRep (Path Computation Reply) message to say which objective function was used for the computation 💫.
Six mandatory objective functions that PCEP must support are listed in [RFC4657]. This document defines all six 🍓. More objective functions can show up in other documents. Also, additional objective functions are defined for the PCE Global Concurrent Optimization (GCO) application in [PCE-GCO] 🌍.
Last thing: this document also defines four new metric types for sets of synchronized requests 🔥.
1.1. Conventions Used in This Document
these are the key words we use for requirement levels. In this document, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in [RFC2119] 📖. Read them carefully, bestie, they carry real weight 🙈.
1.2. Terminology
here's the glossary so we're all on the same page 🫶:
LSR: Label Switching Router.OF: Objective Function. A set of one or more optimization criteria used either for computing a single path (for example, path cost minimization), or for the synchronized computation of a set of paths (for example, aggregate bandwidth consumption minimization, and so on) 💅.PCC: Path Computation Client. Any client application that asks for a path computation to be performed by a Path Computation Element 📞.PCE: Path Computation Element. An entity (a component, an application, or a network node) that can compute a network path or route based on a network graph and apply computational constraints 🧠.PCEP: Path Computation Element communication Protocol 🗨️.TE LSP: Traffic Engineered Label Switched Path 🛣️.
1.3. Message Formats
the message formats in this document are written in Reduced BNF, the same way [RFC5440] uses it, and as defined in [RFC5511] 🧾.
(Part 1 of 4 💜)
2. Discovery of PCE Objective Functions ✨
okay so this section is all about how a PCE gets to show off the objective functions it can handle 💅 it does this by extending PCEP (see [RFC5440]) so the PCE can advertise them 🦋
we're defining a brand new PCEP OF-List (Objective Function list) TLV 🎀 it lives inside an OPEN object, so during the PCEP session-setup phase a PCE can tell its PCEP peer exactly which objective functions it supports 🫶
2.1. OF-List TLV
the PCEP OF-List TLV is optional 🌸 it MAY be carried within an OPEN object sent by a PCE in an Open message to a PCEP peer so it can say which objective functions it supports 💜
the OF-List TLV follows the PCEP TLV format from [RFC5440] ✨ so it's 2 octets for the type, 2 octets for the TLV length, and then a Value field 🧚 the Length field counts only the value portion in octets, and the TLV gets padded to 4-octet alignment. the padding does NOT get counted in the Length field 🙈 for example, a 3-octet value has a length of three, but the whole TLV ends up being eight octets, which is so specific and I love it 😭
the PCEP OF-List TLV looks like this 🍓
TYPE: 4
LENGTH: N * 2 (where N is the number of objective functions)
VALUE: list of 2-byte objective function code points, identifying
the objective functions supported by the sender of the Open
message. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+each OF Code is 2 bytes and it's the Objective Function code point identifier 🔥 IANA manages the "PCE Objective Function" code point registry (see Section 6) 👑
2.2. Elements of Procedure
a PCE MAY include an OF-List TLV within an OPEN object in an Open message sent to a PCEP peer so it can advertise one or more objective functions 🌈 the OF-List TLV MUST NOT appear more than once in an OPEN object 🚫 and if it does show up more than once, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message) 💀
if there's no OF-List TLV in an OPEN object, that MUST be interpreted as "no info on the supported objective functions from this PCE" 🥲 it's an absence of information, not a list of nothing
as specified in [RFC5440], a PCEP peer that doesn't recognize the OF-List TLV will silently ignore it 🫠 no drama, no crash, just vibes 🌸
3. Objective Function in PCEP Path Computation Request and Reply Messages
this section extends PCEP ([RFC5440]) so the objective functions can be communicated in path computation requests and replies 🦋 we're defining a new PCEP OF (Objective Function) object that gets carried within a PCReq message, so the PCC can say which objective function it wants or requires 🎀
the PCEP OF object can also show up in a PCRep message, where the PCE uses it to indicate which objective function it actually used 💜
there's also a new flag in the RP (Request Parameters) object 🧚 the PCC sets it in a PCReq message to tell the PCE that it MUST include an OF object in the PCRep message, showing which objective function got used during path computation ✨
and yep, new PCEP error types and values are defined too 💅
3.1. OF Object
the PCEP OF (Objective Function) object is optional 🌷 it MAY be carried within a PCReq message to indicate the desired or required objective function the PCE should apply during path computation, or within a PCRep message to indicate the objective function the PCE actually used 🫶
the OF object format follows the PCEP object format from [RFC5440] 🍓
the OF Object-Class is 21. the OF Object-Type is 1.
here's the format of the OF object body 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OF Code (2 bytes) is the identifier of the objective function 🔥 once again, IANA manages the "PCE Objective Function" code point registry (see Section 6) 👑
Reserved (2 bytes) MUST be set to zero on transmission and MUST be ignored on receipt 🙈 very strict, very iconic
optional TLVs may be defined in the future to encode objective function parameters 🌈
3.1.1. Elements of Procedure
to request a specific objective function from the PCE, a PCC includes an OF object in the PCReq message 🦋
[RFC5440] specifies a bit flag called the P bit, which is carried in the common PCEP object header 💜 the PCC sets the P bit to mandate that the PCE takes the information in the object into account during path computation 🫶
so here's the deal with the P bit 😭
- if the P bit is set in the OF object, the objective function is mandatory (a required objective function) and the PCE MUST use it during path computation 🔥
- if the P bit is clear in the OF object, the objective function is optional (a desired objective function) and the PCE SHOULD apply it if it's supported, but MAY choose a different objective function based on local capabilities and policies 🌸
when a PCE gets a PCReq message with an OF object, it MUST proceed as follows 🎀
- if the OF object is unknown/unsupported, the PCE MUST follow the procedures defined in [RFC5440] 📜 that means if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request MUST be discarded 💀 if the P bit is cleared, the PCE is free to ignore the object 🫠
- if the objective function is unknown/unsupported and the P bit is set, the PCE MUST send a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded 🙅♀️
- if the objective function is unknown/unsupported and the P bit is cleared, the PCE SHOULD apply another (default) objective function 🧚
- if the objective function is supported but policy does not permit applying it and the P bit is set, the PCE MUST send a PCErr message with the PCEP error type "policy-violation" (type 5) and a new error value, "objective function not allowed", which is defined in this document 🥺
- if the objective function is supported but policy does not allow applying it and the P bit is cleared, the PCE SHOULD apply another (default) objective function 🌷
- if the objective function is supported and policy allows applying it and the P bit is set, the PCE MUST apply the requested objective function 👑 otherwise, if the P bit is cleared, the PCE is free to apply any other objective function ✨
the default objective function may be locally configured 🏡
3.2. Carrying The OF Object In a PCEP Message
the OF object MAY be carried within a PCReq message 💖 if an objective function is meant to apply to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC (Synchronization VECtor) object, and it MUST NOT be repeated for each elementary request 🫶
the same goes for metrics: if a metric applies to a set of synchronized requests, the METRIC object MUST follow the SVEC object and MUST NOT be repeated for each elementary request 📏 metrics applied to a set of synchronized requests are defined in Section 5 🦋
an OF object for an individual path computation request (the non-synchronized case) MUST follow the RP object it applies to 🎀
the format of the PCReq message is updated as follows 💅 check out Appendix A for the full set of RBNF fragments defined in this document and the necessary code license 📜
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<metric-list> ::= <METRIC>[<metric-list>]the OF object MAY be carried within a PCRep message to indicate the objective function the PCE used during path computation 🧚
when the PCE wants to tell the PCC which objective function was used for the synchronized computation of a set of paths, the PCRep message MUST include the corresponding SVEC object, directly followed by the OF object, which MUST NOT be repeated for each elementary request 💜 if a metric applies to the set of paths, the METRIC object MUST directly follow the SVEC object and MUST NOT be repeated for each elementary request 📏
an OF object for an objective function used in an individual path computation (the non-synchronized case) MUST follow the RP object it applies to 🌸
the format of the PCRep message is updated as follows 💖 again, see Appendix A for the full RBNF fragments and the code license 📜
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC> [<metric-list>]Note: the OF object MAY be associated with a negative reply, i.e., a reply with a NO-PATH object 🙈
3.3. New RP Object Flag ✨
okay so sometimes the PCC doesn't specify any objective function in its request, or it asks for an optional one (P flag cleared in the OF object common header) 🎀, and then the PCE just... doesn't follow the request 💀. in that case the PCC might be curious which objective function the PCE actually used during path computation. so we define a new flag in the RP object, called the OF flag, that lets the PCC ask for the objective function to be included in the path computation reply 🦋
here's the new bit flag of the RP object:
- Supply OF on response flag (bit number 24). when it's set in a PCReq message, the PCE MUST provide the applied objective function (should a path satisfying the constraints be found) in the PCRep message. when it's set in a PCRep message, it means the objective function that was used during path computation is included 💖
3.3.1. Elements Of Procedure
if the PCC wants to know which objective function the PCE used for a given request, it sets the OF flag in the RP object 💅
when a PCE gets a PCReq message with the OF flag in the RP object set, here's what it does:
- if policy permits, it MUST include in the PCRep message an OF object indicating the objective function it used during path computation.
- if policy does not permit, it MUST send a PCErr message with the PCEP error code "policy-violation" (type 5) and a new error value, "objective function indication not allowed", which is defined in this document. 🚫
note that a legacy PCE might not recognize the OF flag in the RP object 🙈. according to the definition of the Flags field for the RP object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the unknown flag, so it ends up sending a PCRep that doesn't contain an OF object. in that case, what the PCC does is an implementation choice. the PCC might:
- discard the PCRep because it really wanted the OF object returned.
- accept the PCRep without knowing which OF was applied.
also, these procedures can lead to a PCC receiving a PCRep that contains an OF object with an objective function identifier the PCC doesn't recognize 😭. in that situation the PCC's behavior depends on implementation and configuration. it could choose any of the following (or some other action):
- ignore the OF object and use the computed path.
- add the objective function to its view of the PCE's repertoire for inclusion in future computation requests.
- discard the PCRep (i.e., the computed path) and send a PCReq to another PCE.
- discard the PCRep (i.e., the computed path) and send another PCReq to the same PCE explicitly requiring the use of some other objective function (i.e., by setting the P bit in the OF object).
4. Objective Functions Definition ✨
six objective functions that must be supported by PCEP are listed in [RFC4657]. IANA has assigned the objective function codes, and they're described below 🌸
objective functions are built from this terminology:
- a network comprises a set of N links
{Li, (i=1...N)}. - a path P is a list of K links
{Lpi,(i=1...K)}. - metric of link L is denoted
M(L). this can be the IGP metric, the TE metric, or any other metric. - the cost of a path P is denoted
C(P), whereC(P) = sum {M(Lpi), (i=1...K)}. - residual bandwidth on link L is denoted
r(L). - maximum reservable bandwidth on link L is denoted
R(L).
there are three objective functions that apply to the computation of a single path 🧚
Objective Function Code: 1
Name: Minimum Cost Path (MCP)
Description: Find a path P such that C(P) is minimized.Objective Function Code: 2
Name: Minimum Load Path (MLP)
Description: Find a path P such that
( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.Objective Function Code: 3
Name: Maximum residual Bandwidth Path (MBP)
Description: Find a path P such that
( Min { r(Lpi), i=1...K } ) is maximized.there are three objective functions that apply to a set of path computation requests whose computation is synchronized 👑
Objective Function Code: 4
Name: Minimize aggregate Bandwidth Consumption (MBC)
Description: Find a set of paths such that
( Sum {R(Li) - r(Li), i=1...N} ) is minimized.Objective Function Code: 5
Name: Minimize the Load of the most loaded Link (MLL)
Description: Find a set of paths such that
( Max { (R(Li) - r(Li)) / R(Li), i=1...N}) is minimized.Objective Function Code: 6
Name: Minimize the Cumulative Cost of a set of paths (MCC)
Description: Find a set of paths {P1...Pm} such that
(Sum { C(Pi), i=1...m}) is minimized.other objective functions may be defined in separate documents. 🦋
5. New Metric Types 💜
three metric types are defined in PCEP for the METRIC object: TE metric, IGP metric, and hop count. those apply to an individual request. here we define four new metric types that apply to a set of synchronized requests 🌈
- Type 4: Aggregate bandwidth consumption.
- Type 5: Load of the most loaded link.
- Type 6: Cumulative IGP cost.
- Type 7: Cumulative TE cost.
these metrics may be used in a PCReq to indicate a bound (B bit set in the METRIC object) or to request the computation of a metric (C bit set in the METRIC object), or in a PCRep to indicate a computed metric 💅
a METRIC object with one of these four types follows the SVEC object it applies to. 🎀
6. IANA Considerations 🌷
6.1. PCE Objective Function Sub-Registry
this document defines a 16-bit PCE objective function identifier to be carried within the PCEP OF object, and also defines the PCEP OF-List TLV 🫶
IANA created and now manages the 16-bit "PCE Objective Function" code point registry, starting from 1 and continuing through 32767, with these columns:
- Objective Function code point value
- Objective Function name
- Defining RFC
the same registry applies to the OF object and the OF-List TLV defined in this document.
the guidelines (using terms defined in [RFC5226]) for assigning objective function code point values are:
- Function code value 0 is reserved.
- Function code values in the range 1-32767 are assigned as follows:
- Function code values 1 through 1023 are assigned by IANA using the "IETF Review" policy.
- Function code values 1024 through 32767 are assigned by IANA, using the "First Come First Served" policy.
- Function code values in the range 32768-65535 are for "Private Use".
six objective functions are defined in Section 4 of this document and have been assigned by IANA ✨
Code Point Name Reference
-------------------------------------------------------
1 MCP RFC 5541
2 MLP RFC 5541
3 MBP RFC 5541
4 MBC RFC 5541
5 MLL RFC 5541
6 MCC RFC 55416.2. PCEP Code Points 🍓
6.2.1. OF Object
IANA manages the PCEP Objects code point registry (see [RFC5440]). it's maintained as the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
this document defines a new PCEP object, the OF object, to be carried in PCReq and PCRep messages. IANA has made the following allocation:
Object Name Object Name Reference
Class Type
------------------------------------------------------------
21 OF 1 Objective Function RFC 55416.2.2. OF-List TLV
IANA manages the PCEP TLV code point registry (see [RFC5440]). it's maintained as the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
this document defines a new PCEP TLV, the OF-List TLV, to be carried in the OPEN object. IANA has made the following allocation:
Type TLV name References
-----------------------------------------------
4 OF-List RFC 55416.2.3. PCEP Error Values
IANA maintains a registry of Error-types and Error-values for use in PCEP messages. it's maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry 💖
two new Error-values are defined for the Error-type "policy violation" (type 5):
Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation
Error-value=3: objective function not RFC 5541
allowed (request rejected)
Error-value=4: OF bit of the RP object RFC 5541
set (request rejected)6.2.4. RP Object Flag
a new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following allocation:
Bit Description Reference
-------------------------------------------
24 Supply OF on response RFC 55416.2.5. Metric Types
four new metric types are defined in this document for the METRIC object (specified in [RFC5440]). IANA maintains a registry of metric types in the "METRIC Object T Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following allocations:
- Type 4: Aggregate bandwidth consumption
- Type 5: Load of the most loaded link
- Type 6: Cumulative IGP cost
- Type 7: Cumulative TE cost
7. Security Considerations 🔐
PCEP security mechanisms are described in [RFC5440] and are used to secure entire PCEP messages. nothing in this document changes the message flows or introduces any new messages, so the security mechanisms set out in [RFC5440] still apply 🛡️
this document introduces a single new object that may optionally be carried on PCEP messages, and it will be automatically secured using the mechanisms described in [RFC5440] 🫶
⚠️ if a PCEP message is vulnerable to attack (for example, because the security mechanisms are not used), then the OF object could be used as part of an attack. however, it is likely that other objects will provide far more significant ways of attacking a PCE or PCC in this case. 💀
8. Manageability Considerations 🌸
8.1. Control of Function and Policy 🎀
okay so first up, it MUST be possible to turn objective function discovery on and off in PCEP. bestie, that's non-negotiable 💅
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring a list of authorized objective functions on a PCE. this can apply to any session the PCEP speaker is part of, to one specific session with a given PCEP peer, or to a specific group of sessions with a specific group of PCEP peers. so much control, it's giving main character energy 👑
not gonna lie, it's not mandatory for an implementation to support every objective function from Section 4 🫶
and last but not least, it MUST be possible to configure a default objective function for path computation. this matters when a path request comes in asking for an optional objective function 🦋
8.2. Information and Data Models 🧚
the PCEP MIB Module defined in [PCEP-MIB] could be extended to include objective functions ✨
8.3. Liveness Detection and Monitoring 💜
mechanisms in this document don't add any new liveness detection and monitoring requirements on top of the ones already listed in [RFC5440]. no notes, no extra homework 🌸
8.4. Verify Correct Operations 🍓
same energy here: mechanisms in this document don't add any new operation verification requirements beyond what [RFC5440] already lists 💅
8.5. Requirements On Other Protocols 🌈
and again, the mechanisms here don't imply any requirements on other protocols beyond the ones already listed in [RFC5440] 🦋
8.6. Impact On Network Operations ⭐
last one in this batch: the mechanisms in this document have no impact on network operations beyond what [RFC5440] already covers 🫶
9. Acknowledgments 💖
the authors wanted to thank Jerry Ash, Fabien Verhaeghe, Robert Sparks, and Adrian Farrel for their useful comments. the squad really showed up 🙌
10. References 📚
10.1. Normative References 🔥
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.10.2. Informative References 🧠
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
Element (PCE) Discovery", RFC 4674, October 2006.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[PCE-GCO] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", Work in Progress, March 2009.
[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol
(PCEP) Management Information Base", Work in Progress,
January 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.Appendix A. RBNF Code Fragments 🧩
this appendix has the full set of code fragments defined in this document, so here they are in all their glory ✨
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The RBNF grammar fragments themselves:
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<metric-list> ::= <METRIC>[<metric-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]Authors' Addresses 💌
JL Le Roux
France Telecom
2, Avenue Pierre-Marzin
Lannion 22307
France
EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
L'Atlantis
92782 Issy Les Moulineaux
France
EMail: jpv@cisco.com
Young Lee
Huawei Technologies, LTD.
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
EMail: ylee@huawei.comThat's the whole spec, bestie! 🌈💖 You made it through every single section, and honestly you're obsessed-level smart now 👑✨
📦 where this page comes from
- ietf: rfc5541 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms