diff options
Diffstat (limited to 'doc/rfc/rfc5541.txt')
| -rw-r--r-- | doc/rfc/rfc5541.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc5541.txt b/doc/rfc/rfc5541.txt new file mode 100644 index 0000000..fa52645 --- /dev/null +++ b/doc/rfc/rfc5541.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group JL. Le Roux +Request for Comments: 5541 France Telecom +Category: Standards Track JP. Vasseur + Cisco System Inc. + Y. Lee + Huawei + June 2009 + + + Encoding of Objective Functions in the + Path Computation Element Communication Protocol (PCEP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, 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, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + +Le Roux, et al. Standards Track [Page 1] + +RFC 5541 Objective Functions in PCEP June 2009 + + +Abstract + + 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 is subject to a set of one or more + specific optimization criteria, referred to as objective functions + (e.g., minimum cost path, widest path, etc.). + + In the Path Computation Element (PCE) architecture, a Path + Computation Client (PCC) may want a path to be computed for one or + more TE LSPs according to a specific objective function. Thus, the + PCC needs to instruct the PCE to use the correct objective function. + Furthermore, it is possible that not all PCEs support the same set of + objective functions; therefore, it is useful for the PCC to be able + to automatically discover the set of objective functions supported by + each PCE. + + This document defines extensions to the PCE communication Protocol + (PCEP) to allow a PCE to indicate the set of objective functions it + supports. Extensions are also defined so that a PCC can indicate in + a path computation request the required objective function, and a PCE + can report in a path computation reply the objective function that + was used for path computation. + + This document defines objective function code types for six objective + functions previously listed in the PCE requirements work, and + provides the definition of four new metric types that apply to a set + of synchronized requests. + + + + + + + + + + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 2] + +RFC 5541 Objective Functions in PCEP June 2009 + + +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 ...................................21 + +1. Introduction + + The Path Computation Element-based network architecture [RFC4655] + defines a Path Computation Element (PCE) as an entity capable of + computing the paths of Traffic Engineered Label Switched Paths (TE + LSPs) based on a network graph and of applying computational + constraints. A PCE services path computation requests that are sent + by Path Computation Clients (PCC). + + + +Le Roux, et al. Standards Track [Page 3] + +RFC 5541 Objective Functions in PCEP June 2009 + + + The PCE communication Protocol (PCEP), defined in [RFC5440], allows + for communication between a PCC and a PCE or between two PCEs, in + compliance with requirements and guidelines set forth in [RFC4657]. + Such interactions include path computation requests and path + computation replies. + + The computation of one or a set of TE LSPs is subject to a set of one + or more optimization criteria, called an objective function. An + objective function is used by the PCE when it computes a path or a + set of paths in order to select the "best" candidate paths. There is + a variety of objective functions: an objective function could apply + either to a set of non-synchronized path computation requests, or to + a set of synchronized path computation requests. In the former case, + the objective function refers to an individual path computation + request (e.g., computation of the shortest constrained path where the + metric is the IGP metric, computation of the least loaded constrained + path, etc.). Conversely, in the latter case, the objective function + refers to a set of path computation requests the computation of which + is synchronized (e.g., minimize the aggregate bandwidth consumption + of all LSPs, minimize the sum of the delays for two diverse paths or + of the delta between those delays, etc.). Moreover, some objective + functions relate to the optimization of a single metric and others to + the optimization of a set of metrics (organized in a hierarchical + manner, using a weighted function, etc.). + + As spelled out in [RFC4674], it may be useful for a PCC to discover + the set of objective functions supported by a PCE. Furthermore, + [RFC4657] requires the ability for a PCC to indicate in a path + computation request a required/desired objective function, as well as + optional function parameters. + + For these purposes, this document extends the PCE communication + Protocol (PCEP). It defines PCEP extensions that allow a PCE to + advertise a list of supported objective functions, as well as + extensions to carry the objective function in PCEP request and reply + messages. It complements the PCEP base specification [RFC5440]. + + Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined + in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the + discovery of a few generic parameters, while more detailed PCE + parameters should be discovered using the PCE communication Protocol. + Objective functions are in this second category; thus, the objective + function discovery procedure is handled by PCEP. + + A new PCEP TLV, named the OF-List TLV, is defined in Section 2. The + OF-List TLV is carried in the PCEP OPEN object and allows a PCE to + list, during PCEP session-setup phase, the objective functions that + it supports. + + + +Le Roux, et al. Standards Track [Page 4] + +RFC 5541 Objective Functions in PCEP June 2009 + + + A new PCEP object, the OF object, is defined in Section 3. The OF + object is carried within a PCReq (Path Computation Request) message + to indicate the required/desired objective function to be applied by + a PCE, or in a PCRep (Path Computation Reply) message to indicate the + objective function that was used for path computation. + + Six mandatory objective functions that must be supported by PCEP are + listed in [RFC4657]. This document provides a definition of these + six mandatory objective functions. Additional objective functions + may be defined in other documents. Note that additional objective + functions are defined for the PCE Global Concurrent Optimization + (GCO) application, in [PCE-GCO]. + + This document also provides the definition of four new metric types + that apply to a set of synchronized requests. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Terminology + + LSR: Label Switching Router. + + OF: Objective Function. A set of one or more optimization + criteria used for the computation of a single path (e.g., + path cost minimization) or for the synchronized computation + of a set of paths (e.g., aggregate bandwidth consumption + minimization, etc.). + + PCC: Path Computation Client. Any client application requesting a + path computation to be performed by a Path Computation + Element. + + PCE: Path Computation Element. An entity (component, application, + or network node) that is capable of computing a network path + or route based on a network graph and of applying + computational constraints. + + PCEP: Path Computation Element communication Protocol. + + TE LSP: Traffic Engineered Label Switched Path. + + + + + + + +Le Roux, et al. Standards Track [Page 5] + +RFC 5541 Objective Functions in PCEP June 2009 + + +1.3. Message Formats + + Message formats in this document are expressed using Reduced BNF as + used in [RFC5440] and defined in [RFC5511]. + +2. Discovery of PCE Objective Functions + + This section defines PCEP extensions (see [RFC5440]) so as to support + the advertisement of the objective functions supported by a PCE. + + A new PCEP OF-List (Objective Function list) TLV is defined. The + PCEP OF-List TLV is carried within an OPEN object. This way, during + PCEP session-setup phase, a PCE can advertise to a PCEP peer the list + of 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 as to + indicate the list of supported objective functions. + + The OF-List TLV format is compliant with the PCEP TLV format defined + in [RFC5440]. That is, the TLV is composed of 2 octets for the type, + 2 octets specifying the TLV length, and a Value field. The Length + field defines the length of the value portion in octets. The TLV is + padded to 4-octet alignment, and padding is not included in the + Length field (e.g., a 3-octet value would have a length of three, but + the total size of the TLV would be eight octets). + + The PCEP OF-List TLV has the following format: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Le Roux, et al. Standards Track [Page 6] + +RFC 5541 Objective Functions in PCEP June 2009 + + + OF Code (2 bytes): 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 in order to advertise a set of one or + more objective functions. The OF-List TLV MUST NOT appear more than + once in an OPEN object. If it appears more than once, the PCEP + session MUST be rejected with error type 1 and error value 1 (PCEP + session establishment failure / Reception of an invalid Open + message). The absence of the OF-List TLV in an OPEN object MUST be + interpreted as an absence of information on the list of supported + objective functions by the PCE. + + As specified in [RFC5440], a PCEP peer that does not recognize the + OF-List TLV will silently ignore it. + +3. Objective Function in PCEP Path Computation Request and Reply + Messages + + This section defines PCEP extensions [RFC5440] so as to support the + communication of objective functions in PCEP path computation request + and reply messages. A new PCEP OF (Objective Function) object is + defined, to be carried within a PCReq message in order for the PCC to + indicate the required/desired objective function. + + The PCEP OF object may also be carried within a PCRep message in + order for the PCE to indicate the objective function that was used by + the PCE. + + A new flag is defined in the RP (Request Parameters) object. The + flag is used in a PCReq message to indicate that the PCE MUST include + an OF object in the PCRep message to indicate the objective function + that was used during path computation. + + Also, new PCEP error types and values are defined. + +3.1. OF Object + + The PCEP OF (Objective Function) object is optional. It MAY be + carried within a PCReq message so as to indicate the desired/required + objective function to be applied by the PCE during path computation + or within a PCRep message so as to indicate the objective function + that was used by the PCE during path computation. + + + + + +Le Roux, et al. Standards Track [Page 7] + +RFC 5541 Objective Functions in PCEP June 2009 + + + The OF object format is compliant with the PCEP object format defined + in [RFC5440]. + + The OF Object-Class is 21. + The OF Object-Type is 1. + + The format of the OF object body is: + + 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): The identifier of the objective function. IANA + manages the "PCE Objective Function" code point registry (see Section + 6). + + Reserved (2 bytes): This field MUST be set to zero on transmission + and MUST be ignored on receipt. + + Optional TLVs may be defined in the future so as to encode objective + function parameters. + +3.1.1. Elements of Procedure + + To request the use of a specific objective function by the PCE, a PCC + includes an OF object in the PCReq message. + + [RFC5440] specifies a bit flag, referred to as the P bit, carried in + the common PCEP object header. The P bit is set by a PCC to mandate + that a PCE must take the information carried in the object into + account during the path computation. + + If the P bit is set in the OF object, the objective function is + mandatory (required objective function) and the PCE MUST use the + objective function during path computation. If the P bit is clear in + the OF object, the objective function is optional (desired objective + function) and the PCE SHOULD apply the function if it is supported + but MAY choose to apply a different objective function, according to + local capabilities and policies. + + + + + + +Le Roux, et al. Standards Track [Page 8] + +RFC 5541 Objective Functions in PCEP June 2009 + + + On receipt of a PCReq message with an OF object, a PCE MUST proceed + as follows: + + - If the OF object is unknown/unsupported, the PCE MUST follow + procedures defined in [RFC5440]. That is, 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 if 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 if 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 if 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 to be applied to a set of synchronized path computation + requests, the OF object MUST be carried just after the corresponding + SVEC (Synchronization VECtor) object and MUST NOT be repeated for + each elementary request. + + + + + + + +Le Roux, et al. Standards Track [Page 9] + +RFC 5541 Objective Functions in PCEP June 2009 + + + Similarly, if a metric is to be applied to a set of synchronized + requests, the METRIC object MUST follow the SVEC object and MUST NOT + be repeated for each elementary request. Note that metrics applied + to a set of synchronized requests are defined in Section 5. + + An OF object specifying an objective function that applies to an + individual path computation request (non-synchronized case) MUST + follow the RP object for which it applies. + + The format of the PCReq message is updated as follows. Please see + Appendix A for a 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 used by the PCE during path computation. + + When the PCE wants to indicate to the PCC the objective function that + 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 is applicable to the set of paths, + the METRIC object MUST directly follow the SVEC object and MUST NOT + be repeated for each elementary request. + + + +Le Roux, et al. Standards Track [Page 10] + +RFC 5541 Objective Functions in PCEP June 2009 + + + An OF object specifying an objective function used for an individual + path computation (non-synchronized case) MUST follow the RP object + for which it applies. + + The format of the PCRep message is updated as follows. Please see + Appendix A for a full set of RBNF fragments defined in this document + and the necessary 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 to a negative reply, i.e., a + reply with a NO-PATH object. + + + + + + + + +Le Roux, et al. Standards Track [Page 11] + +RFC 5541 Objective Functions in PCEP June 2009 + + +3.3. New RP Object Flag + + In some cases, where no objective function is specified in the + request or an optional objective function is desired (P flag cleared + in the OF object common header) but the PCE does not follow the + request, the PCC may desire to know the objective function that was + used by the PCE during path computation. To that end, a new flag is + defined in the RP object, named the OF flag, allowing a PCC to + request for the inclusion in the path computation reply of the + objective function that was used by the PCE during path computation. + + The following new bit flag of the RP object is defined: + + The Supply OF on response flag (bit number 24). When set in a PCReq + message, this indicates that the PCE MUST provide the applied + objective function (should a path satisfying the constraints be + found) in the PCRep message. When set in a PCRep message, this + indicates that the objective function that was used during path + computation is included. + +3.3.1. Elements Of Procedure + + If the PCC wants to know the objective function used by the PCE + during path computation for a given request, it sets the OF flag in + the RP object. + + On receipt of a PCReq message with the OF flag in the RP object set, + the PCE proceeds as follows: + + - 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, resulting in it sending a PCRep that does not contain + an OF object. In this case, the PCC's behavior is an implementation + choice. The PCC might: + + - Discard the PCRep because it really wanted the OF object returned. + + - Accept the PCRep without the knowledge of the OF that was applied. + + + +Le Roux, et al. Standards Track [Page 12] + +RFC 5541 Objective Functions in PCEP June 2009 + + + Note also that these procedures can give rise to the situation where + a PCC receives a PCRep that contains an OF object with an objective + function identifier that the PCC does not recognize. In this + situation, the PCC behavior is dependent on implementation and + configuration. The PCC 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]. Objective function codes have been assigned by IANA and + are described below. + + Objective functions are formulated using the following 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), where C(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. + + + + +Le Roux, et al. Standards Track [Page 13] + +RFC 5541 Objective Functions in PCEP June 2009 + + + 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 the computation of which 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. These metric types 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. + + + + + + + +Le Roux, et al. Standards Track [Page 14] + +RFC 5541 Objective Functions in PCEP June 2009 + + + 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 + for which it applies. + +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, as + follows: + + - Objective Function code point value + - Objective Function name + - Defining RFC + + The same registry is applicable to the OF object and the OF-List TLV + that are defined in this document. + + The guidelines (using terms defined in [RFC5226]) for the assignment + of objective function code point values are as follows: + + - Function code value 0 is reserved. + + - Function code values in the range 1-32767 are assigned as follows: + + o Function code values 1 through 1023 are assigned by IANA using + the "IETF Review" policy. + + o Function code values 1024 through 32767 are assigned by IANA, + using the "First Come First Served" policy. + + o Function code values in the range 32768-65535 are for "Private + Use". + + + + + + + + + +Le Roux, et al. Standards Track [Page 15] + +RFC 5541 Objective Functions in PCEP June 2009 + + + 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 5541 + +6.2. PCEP Code Points + +6.2.1. OF Object + + IANA manages the PCEP Objects code point registry (see [RFC5440]). + This is 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 5541 + +6.2.2. OF-List TLV + + IANA manages the PCEP TLV code point registry (see [RFC5440]). This + is 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 5541 + +6.2.3. PCEP Error Values + + IANA maintains a registry of Error-types and Error-values for use in + PCEP messages. This is maintained as the "PCEP-ERROR Object Error + Types and Values" sub-registry of the "Path Computation Element + Protocol (PCEP) Numbers" registry. + + + + +Le Roux, et al. Standards Track [Page 16] + +RFC 5541 Objective Functions in PCEP June 2009 + + + 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 5541 + +6.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] continue to be applicable. + + + + + +Le Roux, et al. Standards Track [Page 17] + +RFC 5541 Objective Functions in PCEP June 2009 + + + This document introduces a single new object that may optionally be + carried on PCEP messages and 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 + + It MUST be possible to configure the activation/deactivation of + objective function discovery in PCEP. + + 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 may apply to any + session the PCEP speaker participates in, to a specific session with + a given PCEP peer, or to a specific group of sessions with a specific + group of PCEP peers. + + Note that it is not mandatory for an implementation to support all + objective functions defined in Section 4. + + It MUST be possible to configure a default objective function used + for path computation when a path request is received that requests to + use 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 defined in this document do not imply any new liveness + detection and monitoring requirements in addition to those already + listed in [RFC5440]. + +8.4. Verify Correct Operations + + Mechanisms defined in this document do not imply any new operation + verification requirements in addition to those already listed in + [RFC5440]. + + + + +Le Roux, et al. Standards Track [Page 18] + +RFC 5541 Objective Functions in PCEP June 2009 + + +8.5. Requirements On Other Protocols + + Mechanisms defined in this document do not imply any requirements on + other protocols in addition to those already listed in [RFC5440]. + +8.6. Impact On Network Operations + + Mechanisms defined in this document do not have any impact on network + operations in addition to those already listed in [RFC5440]. + +9. Acknowledgments + + The authors would like to thank Jerry Ash, Fabien Verhaeghe, Robert + Sparks, and Adrian Farrel for their useful comments. + +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. + + + + + +Le Roux, et al. Standards Track [Page 19] + +RFC 5541 Objective Functions in PCEP June 2009 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 20] + +RFC 5541 Objective Functions in PCEP June 2009 + + +Appendix A. RBNF Code Fragments + + This appendix contains the full set of code fragments defined in this + document. + + 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: + + o Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + + o 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. + + o 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. + + <PCReq Message> ::= <Common Header> + [<svec-list>] + <request-list> + + <PCRep Message> ::= <Common Header> + [<svec-list>] + <response-list> + + + + + + + +Le Roux, et al. Standards Track [Page 21] + +RFC 5541 Objective Functions in PCEP June 2009 + + + <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>] + + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 22] + +RFC 5541 Objective Functions in PCEP June 2009 + + +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.com + + + + + + + + + + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 23] + |