diff options
Diffstat (limited to 'doc/rfc/rfc5521.txt')
| -rw-r--r-- | doc/rfc/rfc5521.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc5521.txt b/doc/rfc/rfc5521.txt new file mode 100644 index 0000000..58081bb --- /dev/null +++ b/doc/rfc/rfc5521.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group E. Oki +Request for Comments: 5521 University of Electro-Communications +Category: Standards Track T. Takeda + NTT + A. Farrel + Old Dog Consulting + April 2009 + + + Extensions to the Path Computation Element Communication Protocol + (PCEP) for Route Exclusions + +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. + + + + + + + + + +Oki, et al. Standards Track [Page 1] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +Abstract + + The Path Computation Element (PCE) provides functions of path + computation in support of traffic engineering (TE) in Multi-Protocol + Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. + + When a Path Computation Client (PCC) requests a PCE for a route, it + may be useful for the PCC to specify, as constraints to the path + computation, abstract nodes, resources, and Shared Risk Link Groups + (SRLGs) that are to be explicitly excluded from the computed route. + Such constraints are termed "route exclusions". + + The PCE Communication Protocol (PCEP) is designed as a communication + protocol between PCCs and PCEs. This document presents PCEP + extensions for route exclusions. + +Table of Contents + + 1. Introduction ................................................. 3 + 1.1. Conventions Used in This Document .......................3 + 2. Protocol Procedures and Extensions ........................... 4 + 2.1. Exclude Route Object (XRO) ............................. 4 + 2.1.1. Definition ..................................... 4 + 2.1.2. Processing Rules ............................... 8 + 2.2. Explicit Route Exclusion ............................... 9 + 2.2.1. Definition ..................................... 9 + 2.2.2. Processing Rules .............................. 10 + 3. Exclude Route with Confidentiality .......................... 11 + 3.1. Exclude Route Object (XRO) Carrying Path-Key .......... 11 + 3.1.1. Definition .................................... 11 + 3.1.2. Processing Rules .............................. 12 + 4. IANA Considerations ......................................... 13 + 4.1. PCEP Objects .......................................... 13 + 4.2. New Subobject for the Include Route Object ............ 13 + 4.3. Error Object Field Values ............................. 13 + 4.4. Exclude Route Flags ................................... 14 + 5. Manageability Considerations ................................ 14 + 6. Security Considerations ..................................... 14 + 7. References .................................................. 15 + 7.1. Normative References .................................. 15 + 7.2. Informative References ................................ 15 + Acknowledgements ................................................ 16 + + + + + + + + + +Oki, et al. Standards Track [Page 2] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +1. Introduction + + The Path Computation Element (PCE) defined in [RFC4655] is an entity + that is capable of computing a network path or route based on a + network graph, and applying computational constraints. A Path + Computation Client (PCC) may make requests to a PCE for paths to be + computed. + + When a PCC requests a PCE for a route, it may be useful for the PCC + to specify abstract nodes, resources, and Shared Risk Link Groups + (SRLGs) that are to be explicitly excluded from the route. + + For example, disjoint paths for inter-domain Label Switched Paths + (LSPs) may be computed by cooperation between PCEs, each of which + computes segments of the paths across one domain. In order to + achieve path computation for a secondary (backup) path, a PCE may act + as a PCC to request another PCE for a route that must be + node/link/SRLG disjoint from the primary (working) path. Another + example is where a network operator wants a path to avoid specified + nodes for administrative reasons, perhaps because the specified nodes + will be out-of-service in the near future. + + [RFC4657] specifies generic requirements for a communication protocol + between PCCs and PCEs. Generic constraints described in [RFC4657] + include route exclusions for links, nodes, and SRLGs. That is, the + requirement for support of route exclusions within the PCC-PCE + communication protocol is already established. + + The PCE communication protocol (PCEP) is designed as a communication + protocol between PCCs and PCEs and is defined in [RFC5440]. This + document presents PCEP extensions to satisfy the requirements for + route exclusions as described in Sections 5.1.4 and 5.1.16 of + [RFC4657]. + + Note that MPLS-TE and GMPLS signaling extensions for communicating + route exclusions between network nodes for specific Label Switched + Paths (LSPs) are described in [RFC4874]. Route exclusions may be + specified during provisioning requests for specific LSPs by setting + the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in + [RFC3812] to false (2). + +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 RFC 2119 [RFC2119]. + + + + + +Oki, et al. Standards Track [Page 3] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +2. Protocol Procedures and Extensions + + This section describes the procedures adopted by a PCE handling a + request for path computation with route exclusions received from a + PCC, and defines how those exclusions are encoded. + + There are two types of route exclusion described in [RFC4874]. + + 1. Exclusion of certain abstract nodes or resources from the whole + path. This set of abstract nodes is referred to as the Exclude + Route List. + + 2. Exclusion of certain abstract nodes or resources between a + specific pair of abstract nodes present in an explicit path. Such + specific exclusions are referred to as an Explicit Route + Exclusion. + + This document defines protocol extensions to allow a PCC to specify + both types of route exclusions to a PCE on a path computation + request. + + A new PCEP object, the Exclude Route Object (XRO), is defined to + convey the Exclude Route List. The existing Include Route Object + (IRO) in PCEP [RFC5440] is modified by introducing a new IRO + subobject, the Explicit Exclusion Route subobject (EXRS), to convey + Explicit Route Exclusions. + +2.1. Exclude Route Object (XRO) + +2.1.1. Definition + + The XRO is OPTIONAL and MAY be carried within Path Computation + Request (PCReq) and Path Computation Reply (PCRep) messages. + + When present in a PCReq message, the XRO provides a list of network + resources that the PCE is requested to exclude from the path that it + computes. Flags associated with each list member instruct the PCE as + to whether the network resources must be excluded from the computed + path, or whether the PCE should make best efforts to exclude the + resources from the computed path. + + The XRO MAY be used on a PCRep message that carries the NO-PATH + object (i.e., one that reports a path computation failure) to + indicate the set of elements of the original XRO that prevented the + PCE from finding a path. + + The XRO MAY also be used on a PCRep message for a successful path + computation when the PCE wishes to provide a set of exclusions to be + + + +Oki, et al. Standards Track [Page 4] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + signaled during LSP setup using the extensions to Resource + Reservation Protocol (RSVP)-TE [RFC4874]. + + The XRO Object-Class is 17. + + The XRO Object-Type is 1. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Flags |F| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + // (Subobjects) // + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: XRO Body Format + + Reserved: 16 bits - MUST be set to zero on transmission and SHOULD be + ignored on receipt. + + Flags: 16 bits - The following flags are currently defined: + + F (Fail - 1 bit): when set, the requesting PCC requires the + computation of a new path for an existing TE LSP that has failed. + If the F bit is set, the path of the existing TE LSP MUST be + provided in the PCReq message by means of a Record Route Object + (RRO) defined in [RFC5440]. This allows the path computation to + take into account the previous path and reserved resources to + avoid double bandwidth booking should the Traffic Engineering + Database (TED) have not yet been updated or the corresponding + resources not be yet been released. This will usually be used in + conjunction with the exclusion from the path computation of the + failed resource that caused the LSP to fail. + + Subobjects: The XRO is made up of one or more subobject(s). An XRO + with no subobjects MUST NOT be sent and SHOULD be ignored on receipt. + + In the following subobject definitions, a set of fields have + consistent meaning as follows: + + X + The X-bit indicates whether the exclusion is mandatory or desired. + 0 indicates that the resource specified MUST be excluded from the + path computed by the PCE. 1 indicates that the resource specified + SHOULD be excluded from the path computed by the PCE, but MAY be + + + + +Oki, et al. Standards Track [Page 5] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + included subject to PCE policy and the absence of a viable path + that meets the other constraints and excludes the resource. + + Type + The type of the subobject. The following subobject types are + defined. + + Type Subobject + -------------+------------------------------- + 1 IPv4 prefix + 2 IPv6 prefix + 4 Unnumbered Interface ID + 32 Autonomous system number + 34 SRLG + + Length + The length of the subobject including the Type and Length fields. + + Prefix Length + Where present, this field can be used to indicate a set of + addresses matching a prefix. If the subobject indicates a single + address, the prefix length MUST be set to the full length of the + address. + + Attribute + The Attribute field indicates how the exclusion subobject is to be + interpreted. + + 0 Interface + The subobject is to be interpreted as an interface or set of + interfaces. All interfaces identified by the subobject are to be + excluded from the computed path according to the setting of the + X-bit. This value is valid only for subobject types 1, 2, and 3. + + 1 Node + The subobject is to be interpreted as a node or set of nodes. All + nodes identified by the subobject are to be excluded from the + computed path according to the setting of the X-bit. This value + is valid only for subobject types 1, 2, 3, and 4. + + 2 SRLG + The subobject identifies an SRLG explicitly or indicates all of + the SRLGs associated with the resource or resources identified by + the subobject. Resources that share any SRLG with those + identified are to be excluded from the computed path according to + the setting of the X-bit. This value is valid for all subobjects. + + + + + +Oki, et al. Standards Track [Page 6] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + Reserved + Reserved fields within subobjects MUST be transmitted as zero and + SHOULD be ignored on receipt. + + The subobjects are encoded as follows: + + IPv4 prefix Subobject + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |X| Type = 1 | Length | IPv4 address (4 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 address (continued) | Prefix Length | Attribute | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IPv6 prefix Subobject + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |X| Type = 2 | Length | IPv6 address (16 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 address (continued) | Prefix Length | Attribute | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Unnumbered Interface ID Subobject + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |X| Type = 3 | Length | Reserved | Attribute | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TE Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The TE Router ID and Interface ID fields are as defined in [RFC3477]. + + + + + + +Oki, et al. Standards Track [Page 7] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + Autonomous System Number Subobject + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |X| Type = 4 | Length | 2-Octet AS Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note that as in other PCEP objects [RFC5440] and RSVP-TE objects + [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is + provided. It is anticipated that, as 4-octet AS Numbers become more + common, both PCEP and RSVP-TE will be updated in a consistent way to + add this support. + + SRLG Subobject + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |X| Type = 5 | Length | SRLG Id (4 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SRLG Id (continued) | Reserved | Attribute | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Attribute SHOULD be set to two (2) and SHOULD be ignored on + receipt. + +2.1.2. Processing Rules + + A PCC builds an XRO to encode all of the resources that it wishes the + PCE to exclude from the path that it is requested to compute. For + each exclusion, the PCC clears the X-bit to indicate that the PCE is + required to exclude the resources, or sets the X-bit to indicate that + the PCC simply desires that the resources are excluded. For each + exclusion, the PCC also sets the Attribute field to indicate how the + PCE should interpret the contents of the exclusion subobject. + + When a PCE receives a PCReq message it looks for an XRO to see if + exclusions are required. If the PCE finds more than one XRO, it MUST + use the first one in the message and MUST ignore subsequent + instances. + + If the PCE does not recognize the XRO, it MUST return a PCErr message + with Error-Type "Unknown Object" as described in [RFC5440]. + + If the PCE is unwilling or unable to process the XRO, it MUST return + a PCErr message with the Error-Type "Not supported object" and follow + the relevant procedures described in [RFC5440]. + + + +Oki, et al. Standards Track [Page 8] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + If the PCE processes the XRO and attempts to compute a path, it MUST + adhere to the requested exclusions as expressed in the XRO. That is, + the returned path MUST NOT include any resources encoded with the + X-bit clear, and SHOULD NOT include any with the X-bit set unless + alternate paths that match the other constraints expressed in the + PCReq are unavailable. + + When a PCE returns a path in a PCRep, it MAY also supply an XRO. An + XRO in a PCRep message with the NO-PATH object indicates that the set + of elements of the original XRO prevented the PCE from finding a + path. On the other hand, if an XRO is present in a PCRep message + without a NO-PATH object, the PCC SHOULD apply the contents using the + same rules as in [RFC4874] and the PCC or a corresponding LSR SHOULD + signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs + should apply. This may be particularly useful in per-domain path + computation scenarios [RFC5152]. + +2.2. Explicit Route Exclusion + +2.2.1. Definition + + Explicit Route Exclusion defines network elements that must not or + should not be used on the path between two abstract nodes or + resources explicitly indicated in the Include Route Object (IRO) + [RFC5440]. This information is encoded by defining a new subobject + for the IRO. + + The new IRO subobject, the Explicit Exclusion Route subobject (EXRS), + has type 33 (see Section 4). The EXRS contains one or more + subobjects in its own right. An EXRS MUST NOT be sent with no + subobjects, and if received with no subobjects, MUST be ignored. + + The format of the EXRS is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |L| Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + // One or more EXRS subobjects // + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + L + MUST be set to zero on transmission and MUST be ignored on + receipt. + + + + +Oki, et al. Standards Track [Page 9] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + Reserved + MUST be set to zero on transmission and SHOULD be ignored on + receipt. + + The EXRS subobject may carry any of the subobjects defined for + inclusion in the XRO by this document or by future documents. The + meanings of the fields of the XRO subobjects are unchanged when the + subobjects are included in an EXRS, except that scope of the + exclusion is limited to the single hop between the previous and + subsequent elements in the IRO. + +2.2.2. Processing Rules + + A PCC that supplies a partial explicit route to a PCE in an IRO MAY + also specify explicit exclusions by including one or more EXRSs in + the IRO. + + If a PCE that does not support the use of EXRS receives an IRO in a + PCReq message that contains an EXRS, it will respond according to the + rules for a malformed object as described in [RFC5440]. The PCE MAY + also include the IRO in the PCErr to indicate in which case the IRO + SHOULD be terminated immediately after the unrecognized EXRS. + + If a PCE that supports the EXRS in an IRO parses an IRO and + encounters an EXRS that contains a subobject that it does not support + or recognize, it MUST act according to the setting of the X-bit in + the subobject. If the X-bit is clear, the PCE MUST respond with a + PCErr with Error-Type "Unrecognized EXRS subobject" and set the + Error-Value to the EXRS subobject type code (see Section 4). If the + X-bit is set, the PCE MAY respond with a PCErr as already stated or + MAY ignore the EXRS subobject: this choice is a local policy + decision. + + If a PCE parses an IRO and encounters an EXRS subobject that it + recognizes, it MUST act according to the requirements expressed in + the subobject. That is, if the X-bit is clear, the PCE MUST NOT + produce a path that includes any resource identified by the EXRS + subobject in the path between the previous abstract node in the IRO + and the next abstract node in the IRO. If the X-bit is set, the PCE + SHOULD NOT produce a path that includes any resource identified by + the EXRS subobject in the path between the previous abstract node in + the IRO and the next abstract node in the IRO unless it is not + possible to construct a path that avoids that resource while still + complying with the other constraints expressed in the PCReq message. + + + + + + + +Oki, et al. Standards Track [Page 10] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + A successful path computation reported in a PCRep message MUST + include an ERO to specify the path that has been computed as + specified in [RFC5440]. That ERO MAY contain specific route + exclusions using the EXRS as specified in [RFC4874]. + + If the path computation fails and a PCErr is returned with a NO-PATH + object, the PCE MAY include an IRO to report the hops that could not + be complied with as described in [RFC5440], and that IRO MAY include + EXRSs. + +3. Exclude Route with Confidentiality + +3.1. Exclude Route Object (XRO) Carrying Path-Key + +3.1.1. Definition + + In PCE-based inter-domain diverse path computation, an XRO may be + used to find a backup (secondary) path. A sequential path + computation approach may be applied for this purpose, where a working + (primary) path route is computed first and a backup path route that + must be a node/link/SRLG disjoint route from the working path is then + computed [RFC5298]. Backward Recursive Path Computation (BRPC) may + be used for inter-domain path computation [RFC5441]. + + In some cases of inter-domain computation (e.g., where domains are + administered by different service providers), confidentiality must be + kept. For primary path computation, to preserve confidentiality, + instead of explicitly expressing the computed route, Path-Key + Subobjects (PKSs) [RFC5520] are carried in the Explicit Route Object + (ERO) in the PCRep Message. + + Therefore, during inter-domain diverse path computation, it may be + necessary to request diversity from a path that is not fully known + and where a segment of the path is represented by a PKS. This means + that a PKS may be present as a subobject of the XRO on a PCReq + message. + + The format and definition of PKS when it appears as an XRO subobject + are as defined in [RFC5520], except for the definition of the L bit. + The L bit of the PKS subobject in the XRO MUST be ignored. + + + + + + + + + + + +Oki, et al. Standards Track [Page 11] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +3.1.2. Processing Rules + + Consider that BRPC is applied for both working and backup path + computation in a sequential manner. First, PCC requests PCE for the + computation of a working path. After BRPC processing has completed, + the PCC receives the results of the working-path computation + expressed in an ERO in a PCRep message. The ERO may include PKSs if + certain segments of the path are to be kept confidential. + + For backup path computation, when the PCC constructs a PCReq Message, + it includes the entire working-path in the XRO so that the computed + path is node/link disjoint from the working path. The XRO may also + include SRLGs to ensure SRLG diversity from the working path. If the + working path ERO includes PKS subobjects, these are also included in + the XRO to allow the PCE to ensure diversity. + + A set of PCEs for backup path computation may be the same as ones for + working path computation, or they may be different. + + - Identical PCEs + + In the case where the same PCEs are used for both path + computations, the processing is as follows. During the process of + BRPC for backup path computation, a PCE may encounter a PKS as it + processes the XRO when it creates a virtual path tree (VPT) in its + own domain. The PCE retrieves the PCE-ID from the PKS, recognizes + itself, and converts the PKS into a set of XRO subobjects that it + uses for the local calculation to create the VPT. The XRO + subobjects created in this way MUST NOT be shared with other PCEs. + Other operations are the same as BRPC. + + - Different PCEs + + In the case where a set of PCEs for backup path computation is + different from the ones used for working path computation, the + processing is as follows. If a PCE encounters a PKS in an XRO + when it is creating a virtual path tree in its own domain, the PCE + retrieves the PCE-ID from the PKS and sends a PCReq message to the + identified PCE to expand the PKS. The PCE computing the VPT + treats the path segment in the response as a set of XRO subobjects + in performing its path computation. The XRO subobjects determined + in this way MUST NOT be shared with other PCEs. + + + + + + + + + +Oki, et al. Standards Track [Page 12] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +4. IANA Considerations + +4.1. PCEP Objects + + The "PCEP Parameters" registry contains a subregistry "PCEP Objects". + IANA has made the following allocations from this registry. + + Object Name Reference + Class + 17 XRO [RFC5521] + Object-Type + 1: Route exclusion + + This object should be registered as being allowed to carry the + following subobjects: + + Subobject Type Reference + 1 IPv4 prefix [RFC3209] + 2 IPv6 prefix [RFC3209] + 4 Unnumbered Interface ID [RFC3477] + 32 Autonomous system number [RFC3209] + 34 SRLG [RFC4874] + 64 Path-Key with 32-bit PCE ID [RFC5520] + 65 Path-Key with 128-bit PCE ID [RFC5520] + +4.2. New Subobject for the Include Route Object + + The "PCEP Parameters" registry contains a subregistry "PCEP Objects" + with an entry for the Include Route Object (IRO). + + IANA added a further subobject that can be carried in the IRO as + follows: + + Subobject Type Reference + + 33 Explicit Exclusion Route subobject (EXRS) [RFC4874] + +4.3. Error Object Field Values + + The "PCEP Parameters" registry contains a subregistry "Error Types + and Values". IANA made the following allocations from this + subregistry. + + Error + Type Meaning Reference + + 11 Unrecognized EXRS subobject [RFC5521] + + + + +Oki, et al. Standards Track [Page 13] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +4.4. Exclude Route Flags + + IANA created a subregistry of the "PCEP Parameters" for the bits + carried in the Flags field of the Exclude Route Object (XRO). The + subregistry is called "XRO Flag Field". + + New bits may be allocated only by an IETF Consensus action. + + The field contains 16 bits numbered from bit 0 as the most + significant bit. + + Bit Name Description Reference + + 15 F-bit Fail [RFC5221] + +5. Manageability Considerations + + A MIB module for management of the PCEP is being specified in a + separate document [PCEP-MIB]. That MIB module allows examination of + individual PCEP messages, in particular requests, responses and + errors. + + The MIB module MUST be extended to include the ability to view the + route exclusion extensions defined in this document. + + Several local policy decisions should be made at the PCE. Firstly, + the exact behavior with regard to desired exclusions must be + available for examination by an operator and may be configurable. + Second, the behavior on receipt of an unrecognized XRO or EXRS + subobject with the X-bit set should be configurable and must be + available for inspection. The inspection and control of these local + policy choices may be part of the PCEP MIB module. + +6. Security Considerations + + The new exclude route mechanisms defined in this document allow finer + and more specific control of the path computed by a PCE. Such + control increases the risk if a PCEP message is intercepted, + modified, or spoofed because it allows the attacker to exert control + over the path that the PCE will compute or to make the path + computation impossible. Therefore, the security techniques described + in [RFC5440] are considered more important. + + Note, however, that the route exclusion mechanisms also provide the + operator with the ability to route around vulnerable parts of the + network and may be used to increase overall network security. + + + + + +Oki, et al. Standards Track [Page 14] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + +7. References + +7.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. + + [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A + Per-Domain Path Computation Method for Establishing + Inter-Domain Traffic Engineering (TE) Label Switched Paths + (LSPs)", RFC 5152, February 2008. + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + March 2009. + + [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, + "A Backward-Recursive PCE-Based Computation (BRPC) + Procedure to Compute Shortest Constrained Inter-Domain + Traffic Engineering Label Switched Paths", RFC 5441, April + 2009. + + [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, + "Preserving Topology Confidentiality in Inter-Domain Path + Computation Using a Path-Key-Based Mechanism", RFC 5520, + April 2009. + +7.2. Informative References + + [PCEP-MIB] Koushik, A. S. K., and E. Stephan, "PCE Communication + Protocol(PCEP) Management Information Base", Work in + Progress, November 2008. + + [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links + in Resource ReSerVation Protocol - Traffic Engineering + (RSVP-TE)", RFC 3477, January 2003. + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, June + 2004. + + + + + + +Oki, et al. Standards Track [Page 15] + +RFC 5521 Extensions to PCEP for Route Exclusions April 2009 + + + [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. + + [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - + Extension to Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE)", RFC 4874, April 2007. + + [RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. + Vasseur, "Analysis of Inter-Domain Label Switched Path + (LSP) Recovery", RFC 5298, August 2008. + +Acknowledgements + + The authors would like to thank Fabien Verhaeghe for valuable + comments on subobject formats. Thanks to Magnus Westerlund, Dan + Romascanu, Tim Polk, and Dave Ward for comments during IESG review. + +Authors' Addresses + + Eiji Oki + University of Electro-Communications + 1-5-1 Chofugaoka + Chofu, Tokyo 182-8585 + JAPAN + + EMail: oki@ice.uec.ac.jp + + Tomonori Takeda + NTT + 3-9-11 Midori-cho, + Musashino-shi, Tokyo 180-8585, Japan + EMail: takeda.tomonori@lab.ntt.co.jp + + Adrian Farrel + Old Dog Consulting + EMail: adrian@olddog.co.uk + + + + + + + + + + +Oki, et al. Standards Track [Page 16] + |