diff options
Diffstat (limited to 'doc/rfc/rfc5088.txt')
| -rw-r--r-- | doc/rfc/rfc5088.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc5088.txt b/doc/rfc/rfc5088.txt new file mode 100644 index 0000000..c80f520 --- /dev/null +++ b/doc/rfc/rfc5088.txt @@ -0,0 +1,1123 @@ + + + + + + + +Network Working Group JL. Le Roux, Ed. +Request for Comments: 5088 France Telecom +Category: Standards Track JP. Vasseur, Ed. + Cisco System Inc. + Y. Ikejiri + NTT Communications + R. Zhang + BT + January 2008 + + + OSPF Protocol Extensions for Path Computation Element (PCE) Discovery + +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. + +Abstract + + There are various circumstances where it is highly desirable for a + Path Computation Client (PCC) to be able to dynamically and + automatically discover a set of Path Computation Elements (PCEs), + along with information that can be used by the PCC for PCE selection. + When the PCE is a Label Switching Router (LSR) participating in the + Interior Gateway Protocol (IGP), or even a server participating + passively in the IGP, a simple and efficient way to announce PCEs + consists of using IGP flooding. For that purpose, this document + defines extensions to the Open Shortest Path First (OSPF) routing + protocol for the advertisement of PCE Discovery information within an + OSPF area or within the entire OSPF routing domain. + + + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 1] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................4 + 3. Overview ........................................................5 + 3.1. PCE Discovery Information ..................................5 + 3.2. Flooding Scope .............................................5 + 4. The OSPF PCED TLV ...............................................6 + 4.1. PCE-ADDRESS Sub-TLV ........................................7 + 4.2. PATH-SCOPE Sub-TLV .........................................8 + 4.3. PCE-DOMAIN Sub-TLV ........................................10 + 4.4. NEIG-PCE-DOMAIN Sub-TLV ...................................11 + 4.5. PCE-CAP-FLAGS Sub-TLV .....................................12 + 5. Elements of Procedure ..........................................13 + 6. Backward Compatibility .........................................14 + 7. IANA Considerations ............................................14 + 7.1. OSPF TLV ..................................................14 + 7.2. PCE Capability Flags Registry .............................14 + 8. Security Considerations ........................................15 + 9. Manageability Considerations ...................................16 + 9.1. Control of Policy and Functions ...........................16 + 9.2. Information and Data Model ................................16 + 9.3. Liveness Detection and Monitoring .........................16 + 9.4. Verify Correct Operations .................................16 + 9.5. Requirements on Other Protocols and Functional + Components ................................................16 + 9.6. Impact on Network Operations ..............................17 + 10. Acknowledgments ...............................................17 + 11. References ....................................................17 + 11.1. Normative References .....................................17 + 11.2. Informative References ...................................18 + +1. Introduction + + [RFC4655] describes the motivations and architecture for a Path + Computation Element (PCE)-based path computation model for + Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) + Traffic Engineered Label Switched Paths (TE LSPs). The model allows + for the separation of the PCE from a Path Computation Client (PCC) + (also referred to as a non co-located PCE) and allows for cooperation + between PCEs (where one PCE acts as a PCC to make requests of the + other PCE). This relies on a communication protocol between a PCC + and PCE, and also between PCEs. The requirements for such a + communication protocol can be found in [RFC4657], and the + communication protocol is defined in [PCEP]. + + + + + + +Le Roux, et al. Standards Track [Page 2] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + The PCE architecture requires that a PCC be aware of the location of + one or more PCEs in its domain, and, potentially, of PCEs in other + domains, e.g., in the case of inter-domain TE LSP computation. + + A network may contain a large number of PCEs, each with potentially + distinct capabilities. In such a context, it is highly desirable to + have a mechanism for automatic and dynamic PCE discovery that allows + PCCs to automatically discover a set of PCEs, along with additional + information about each PCE that may be used by a PCC to perform PCE + selection. Additionally, it is valuable for a PCC to dynamically + detect new PCEs, failed PCEs, or any modification to the PCE + information. Detailed requirements for such a PCE discovery + mechanism are provided in [RFC4674]. + + Note that the PCE selection algorithm applied by a PCC is out of the + scope of this document. + + When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs + are either LSRs or servers also participating in the IGP, an + effective mechanism for PCE discovery within an IGP routing domain + consists of utilizing IGP advertisements. + + This document defines extensions to OSPFv2 [RFC2328] and OSPFv3 + [RFC2740] to allow a PCE in an OSPF routing domain to advertise its + location, along with some information useful to a PCC for PCE + selection, so as to satisfy dynamic PCE discovery requirements set + forth in [RFC4674]. + + Generic capability advertisement mechanisms for OSPF are defined in + [RFC4970]. These allow a router to advertise its capabilities within + an OSPF area or an entire OSPF routing domain. This document + leverages this generic capability advertisement mechanism to fully + satisfy the dynamic PCE discovery requirements. + + This document defines a new TLV (named the PCE Discovery TLV (PCED + TLV)) to be carried within the OSPF Router Information LSA + ([RFC4970]). + + The PCE information advertised is detailed in Section 3. Protocol + extensions and procedures are defined in Sections 4 and 5. + + The OSPF extensions defined in this document allow for PCE discovery + within an OSPF routing domain. Solutions for PCE discovery across + Autonomous System boundaries are beyond the scope of this document, + and are for further study. + + + + + + +Le Roux, et al. Standards Track [Page 3] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +2. Terminology + + ABR: OSPF Area Border Router. + + AS: Autonomous System. + + IGP: Interior Gateway Protocol. Either of the two routing protocols, + Open Shortest Path First (OSPF) or Intermediate System to + Intermediate System (IS-IS). + + Intra-area TE LSP: A TE LSP whose path does not cross an IGP area + boundary. + + Intra-AS TE LSP: A TE LSP whose path does not cross an AS boundary. + + Inter-area TE LSP: A TE LSP whose path transits two or more IGP + areas. That is, a TE LSP that crosses at least one IGP area + boundary. + + Inter-AS TE LSP: A TE LSP whose path transits two or more ASes or + sub-ASes (BGP confederations). That is, a TE LSP that crosses at + least one AS boundary. + + LSA: Link State Advertisement. + + LSR: Label Switching Router. + + 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 applying computational constraints. + + PCED: PCE Discovery. + + PCE-Domain: In a PCE context, this refers to any collection of + network elements within a common sphere of address management or path + computational responsibility (referred to as a "domain" in + [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. + This should be distinguished from an OSPF routing domain. + + PCEP: Path Computation Element communication Protocol. + + TE LSP: Traffic Engineered Label Switched Path. + + TLV: Type-Length-Variable data encoding. + + + + +Le Roux, et al. Standards Track [Page 4] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + 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]. + + IS-IS extensions for PCE discovery are defined in [RFC5089]. + +3. Overview + +3.1. PCE Discovery Information + + The PCE discovery information is composed of: + + - The PCE location: an IPv4 and/or IPv6 address that is used to + reach the PCE. It is RECOMMENDED to use an address that is always + reachable if there is any connectivity to the PCE; + + - The PCE path computation scope (i.e., intra-area, inter-area, + inter-AS, or inter-layer); + + - The set of one or more PCE-Domain(s) into which the PCE has + visibility and for which the PCE can compute paths; + + - The set of zero, one, or more neighbor PCE-Domain(s) toward which + the PCE can compute paths; + + - A set of communication capabilities (e.g., support for request + prioritization) and path computation-specific capabilities (e.g., + supported constraints). + + PCE discovery information is, by nature, fairly static and does not + change with PCE activity. Changes in PCE discovery information may + occur as a result of PCE configuration updates, PCE + deployment/activation, PCE deactivation/suppression, or PCE failure. + Hence, this information is not expected to change frequently. + +3.2. Flooding Scope + + The flooding scope for PCE information advertised through OSPF can be + limited to one or more OSPF areas the PCE belongs to, or can be + extended across the entire OSPF routing domain. + + Note that some PCEs may belong to multiple areas, in which case the + flooding scope may comprise these areas. This could be the case for + an ABR, for instance, advertising its PCE information within the + backbone area and/or a subset of its attached IGP area(s). + + + + + + +Le Roux, et al. Standards Track [Page 5] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +4. The OSPF PCED TLV + + The OSPF PCE Discovery TLV (PCED TLV) contains a non-ordered set of + sub-TLVs. + + The format of the OSPF PCED TLV and its sub-TLVs is identical to the + TLV format used by the Traffic Engineering Extensions to OSPF + [RFC3630]. 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; padding is not included in + the Length field (so a 3-octet value would have a length of 3, but + the total size of the TLV would be 8 octets). Nested TLVs are also + 4-octet aligned. Unrecognized types are ignored. + + The OSPF PCED TLV has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + // sub-TLVs // + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 6 + Length: Variable + Value: This comprises one or more sub-TLVs + + Five sub-TLVs are defined: + Sub-TLV type Length Name + 1 variable PCE-ADDRESS sub-TLV + 2 4 PATH-SCOPE sub-TLV + 3 4 PCE-DOMAIN sub-TLV + 4 4 NEIG-PCE-DOMAIN sub-TLV + 5 variable PCE-CAP-FLAGS sub-TLV + + The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within + the PCED TLV. + + The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They MAY + be present in the PCED TLV to facilitate selection of inter-domain + PCEs. + + + + + +Le Roux, et al. Standards Track [Page 6] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED + TLV to facilitate the PCE selection process. + + Malformed PCED TLVs or sub-TLVs not explicitly described in this + document MUST cause the LSA to be treated as malformed according to + the normal procedures of OSPF. + + Any unrecognized sub-TLV MUST be silently ignored. + + The PCED TLV is carried within an OSPF Router Information LSA defined + in [RFC4970]. + + No additional sub-TLVs will be added to the PCED TLV in the future. + If a future application requires the advertisement of additional PCE + information in OSPF, this will not be carried in the Router + Information LSA. + + The following sub-sections describe the sub-TLVs that may be carried + within the PCED TLV. + +4.1. PCE-ADDRESS Sub-TLV + + The PCE-ADDRESS sub-TLV specifies an IP address that can be used to + reach the PCE. It is RECOMMENDED to make use of an address that is + always reachable, provided that the PCE is alive and reachable. + + The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the + PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and + IPv6 address. It MUST NOT appear more than once for the same address + type. If it appears more than once for the same address type, only + the first occurrence is processed and any others MUST be ignored. + + The format of the PCE-ADDRESS sub-TLV is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 1 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | address-type | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + // PCE IP Address // + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PCE-ADDRESS sub-TLV format + + + + +Le Roux, et al. Standards Track [Page 7] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + Type: 1 + Length: 8 (IPv4) or 20 (IPv6) + + Address-type: + 1 IPv4 + 2 IPv6 + + Reserved: SHOULD be set to zero on transmission and MUST be ignored + on receipt. + + PCE IP Address: The IP address to be used to reach the PCE. + +4.2. PATH-SCOPE Sub-TLV + + The PATH-SCOPE sub-TLV indicates the PCE path computation scope, + which refers to the PCE's ability to compute or take part in the + computation of paths for intra-area, inter-area, inter-AS, or inter- + layer TE LSPs. + + The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the + PCED TLV. There MUST be exactly one instance of the PATH-SCOPE + sub-TLV within each PCED TLV. If it appears more than once, only the + first occurrence is processed and any others MUST be ignored. + + The PATH-SCOPE sub-TLV contains a set of bit-flags indicating the + supported path scopes, and four fields indicating PCE preferences. + + The PATH-SCOPE sub-TLV has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 2 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 2 + Length: 4 + Value: This comprises a 2-octet flags field where each bit + represents a supported path scope, as well as four + preference fields used to specify PCE preferences. + + + + + + + + + +Le Roux, et al. Standards Track [Page 8] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + The following bits are defined: + + Bit Path Scope + + 0 L bit: Can compute intra-area paths. + 1 R bit: Can act as PCE for inter-area TE LSP + computation. + 2 Rd bit: Can act as a default PCE for inter-area TE LSP + computation. + 3 S bit: Can act as PCE for inter-AS TE LSP computation. + 4 Sd bit: Can act as a default PCE for inter-AS TE LSP + computation. + 5 Y bit: Can act as PCE for inter-layer TE LSP + computation. + + PrefL field: PCE's preference for intra-area TE LSP computation. + + PrefR field: PCE's preference for inter-area TE LSP computation. + + PrefS field: PCE's preference for inter-AS TE LSP computation. + + PrefY field: PCE's preference for inter-layer TE LSP computation. + + Res: Reserved for future use. + + The L, R, S, and Y bits are set when the PCE can act as a PCE for + intra-area, inter-area, inter-AS, or inter-layer TE LSP computation, + respectively. These bits are non-exclusive. + + When set, the Rd bit indicates that the PCE can act as a default PCE + for inter-area TE LSP computation (that is, the PCE can compute a + path toward any neighbor area). Similarly, when set, the Sd bit + indicates that the PCE can act as a default PCE for inter-AS TE LSP + computation (the PCE can compute a path toward any neighbor AS). + + When the Rd and Sd bit are set, the PCED TLV MUST NOT contain a + NEIG-PCE-DOMAIN sub-TLV (see Section 4.4). + + When the R bit is clear, the Rd bit SHOULD be clear on transmission + and MUST be ignored on receipt. When the S bit is clear, the Sd bit + SHOULD be clear on transmission and MUST be ignored on receipt. + + The PrefL, PrefR, PrefS, and PrefY fields are each three bits long + and allow the PCE to specify a preference for each computation scope, + where 7 reflects the highest preference. Such preferences can be + used for weighted load balancing of path computation requests. An + operator may decide to configure a preference for each computation + scope at each PCE so as to balance the path computation load among + + + +Le Roux, et al. Standards Track [Page 9] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + them. The algorithms used by a PCC to load balance its path + computation requests according to such PCE preferences is out of the + scope of this document and is a matter for local or network-wide + policy. The same or different preferences may be used for each + scope. For instance, an operator that wants a PCE capable of both + inter-area and inter-AS computation to be preferred for use for + inter-AS computations may configure PrefS higher than PrefR. + + When the L, R, S, or Y bits are cleared, the PrefL, PrefR, PrefS, and + PrefY fields SHOULD respectively be set to 0 on transmission and MUST + be ignored on receipt. + + Both reserved fields SHOULD be set to zero on transmission and MUST + be ignored on receipt. + +4.3. PCE-DOMAIN Sub-TLV + + The PCE-DOMAIN sub-TLV specifies a PCE-Domain (area or AS) where the + PCE has topology visibility and through which the PCE can compute + paths. + + The PCE-DOMAIN sub-TLV SHOULD be present when PCE-Domains for which + the PCE can operate cannot be inferred by other IGP information: for + instance, when the PCE is inter-domain capable (i.e., when the R bit + or S bit is set) and the flooding scope is the entire routing domain + (see Section 5 for a discussion of how the flooding scope is set and + interpreted). + + A PCED TLV may include multiple PCE-DOMAIN sub-TLVs when the PCE has + visibility into multiple PCE-Domains. + + The PCE-DOMAIN sub-TLV has the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 3 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Domain-type | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Domain ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PCE-DOMAIN sub-TLV format + + Type: 3 + Length: 8 + + + + +Le Roux, et al. Standards Track [Page 10] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + Two domain-type values are defined: + 1 OSPF Area ID + 2 AS Number + + Domain ID: With the domain-type set to 1, this indicates the + 32-bit Area ID of an area where the PCE has visibility and can + compute paths. With domain-type set to 2, this indicates an AS + number of an AS where the PCE has visibility and can compute + paths. When the AS number is coded in two octets, the AS Number + field MUST have its first two octets set to 0. + +4.4. NEIG-PCE-DOMAIN Sub-TLV + + The NEIG-PCE-DOMAIN sub-TLV specifies a neighbor PCE-Domain (area or + AS) toward which a PCE can compute paths. It means that the PCE can + take part in the computation of inter-domain TE LSPs with paths that + transit this neighbor PCE-Domain. + + A PCED sub-TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the + PCE can compute paths towards several neighbor PCE-Domains. + + The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN + sub-TLV: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 4 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Domain-type | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Domain ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + NEIG-PCE-DOMAIN sub-TLV format + + Type: 4 + Length: 8 + + Two domain-type values are defined: + 1 OSPF Area ID + 2 AS Number + + Domain ID: With the domain-type set to 1, this indicates the + 32-bit Area ID of a neighbor area toward which the PCE can compute + paths. With domain-type set to 2, this indicates the AS number of + + + + + +Le Roux, et al. Standards Track [Page 11] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + a neighbor AS toward which the PCE can compute paths. When the AS + number is coded in two octets, the AS Number field MUST have its + first two octets set to 0. + + The NEIG-PCE-DOMAIN sub-TLV MUST be present at least once with + domain-type set to 1 if the R bit is set and the Rd bit is cleared, + and MUST be present at least once with domain-type set to 2 if the S + bit is set and the Sd bit is cleared. + +4.5. PCE-CAP-FLAGS Sub-TLV + + The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to indicate PCE + capabilities. It MAY be present within the PCED TLV. It MUST NOT be + present more than once. If it appears more than once, only the first + occurrence is processed and any others MUST be ignored. + + The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array + of units of 32-bit flags numbered from the most significant bit as + bit zero, where each bit represents one PCE capability. + + The format of the PCE-CAP-FLAGS sub-TLV 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 5 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + // PCE Capability Flags // + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 5 + Length: Multiple of 4 octets + Value: This contains an array of units of 32-bit flags + numbered from the most significant as bit zero, where + each bit represents one PCE capability. + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 12] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + IANA will manage the space of the PCE Capability Flags. + + The following bits have been assigned by IANA: + + Bit Capabilities + + 0 Path computation with GMPLS link constraints + 1 Bidirectional path computation + 2 Diverse path computation + 3 Load-balanced path computation + 4 Synchronized path computation + 5 Support for multiple objective functions + 6 Support for additive path constraints + (max hop count, etc.) + 7 Support for request prioritization + 8 Support for multiple requests per message + + 9-31 Reserved for future assignments by IANA. + + These capabilities are defined in [RFC4657]. + + Reserved bits SHOULD be set to zero on transmission and MUST be + ignored on receipt. + +5. Elements of Procedure + + The PCED TLV is advertised within OSPFv2 Router Information LSAs + (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router Information + LSAs (function code of 12), which are defined in [RFC4970]. As such, + elements of procedure are inherited from those defined in [RFC4970]. + + In OSPFv2, the flooding scope is controlled by the opaque LSA type + (as defined in [RFC2370]) and in OSPFv3, by the S1/S2 bits (as + defined in [RFC2740]). If the flooding scope is area local, then the + PCED TLV MUST be carried within an OSPFv2 type 10 router information + LSA or an OSPFV3 Router Information LSA with the S1 bit set and the + S2 bit clear. If the flooding scope is the entire IGP domain, then + the PCED TLV MUST be carried within an OSPFv2 type 11 Router + Information LSA or OSPFv3 Router Information LSA with the S1 bit + clear and the S2 bit set. When only the L bit of the PATH-SCOPE + sub-TLV is set, the flooding scope MUST be area local. + + When the PCE function is deactivated, the OSPF speaker advertising + this PCE MUST originate a new Router Information LSA that no longer + includes the corresponding PCED TLV, provided there are other TLVs in + the LSA. If there are no other TLVs in the LSA, it MUST either send + an empty Router Information LSA or purge it by prematurely aging it. + + + + +Le Roux, et al. Standards Track [Page 13] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + The PCE address (i.e., the address indicated within the PCE-ADDRESS + sub-TLV) SHOULD be reachable via some prefixes advertised by OSPF. + + The PCED TLV information regarding a specific PCE is only considered + current and useable when the router advertising this information is + itself reachable via OSPF calculated paths in the same area of the + LSA in which the PCED TLV appears. + + A change in the state of a PCE (activate, deactivate, parameter + change) MUST result in a corresponding change in the PCED TLV + information advertised by an OSPF router (inserted, removed, updated) + in its LSA. The way PCEs determine the information they advertise, + and how that information is made available to OSPF, is out of the + scope of this document. Some information may be configured (e.g., + address, preferences, scope) and other information may be + automatically determined by the PCE (e.g., areas of visibility). + + A change in information in the PCED TLV MUST NOT trigger any SPF + computation at a receiving router. + +6. Backward Compatibility + + The PCED TLV defined in this document does not introduce any + interoperability issues. + + A router not supporting the PCED TLV will just silently ignore the + TLV as specified in [RFC4970]. + +7. IANA Considerations + +7.1. OSPF TLV + + IANA has defined a registry for TLVs carried in the Router + Information LSA defined in [RFC4970]. IANA has assigned a new TLV + codepoint for the PCED TLV carried within the Router Information LSA. + + Value TLV Name Reference + ----- -------- ---------- + 6 PCED (this document) + +7.2. PCE Capability Flags Registry + + This document provides new capability bit flags, which are present in + the PCE-CAP-FLAGS TLV referenced in Section 4.1.5. + + + + + + + +Le Roux, et al. Standards Track [Page 14] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + The IANA has created a new top-level OSPF registry, the "PCE + Capability Flags" registry, and will manage the space of PCE + capability bit flags numbering them in the usual IETF notation + starting at zero and continuing at least through 31, with the most + significant bit as bit zero. + + New bit numbers may be allocated only by an IETF Consensus action. + + Each bit should be tracked with the following qualities: + + - Bit number + - Capability Description + - Defining RFC + + Several bits are defined in this document. The following values have + been assigned: + + Bit Capability Description + + 0 Path computation with GMPLS link constraints + 1 Bidirectional path computation + 2 Diverse path computation + 3 Load-balanced path computation + 4 Synchronized paths computation + 5 Support for multiple objective functions + 6 Support for additive path constraints + (max hop count, etc.) + 7 Support for request prioritization + 8 Support for multiple requests per message + +8. Security Considerations + + This document defines OSPF extensions for PCE discovery within an + administrative domain. Hence the security of the PCE discovery + relies on the security of OSPF. + + Mechanisms defined to ensure authenticity and integrity of OSPF LSAs + [RFC2154], and their TLVs, can be used to secure the PCE Discovery + information as well. + + OSPF provides no encryption mechanism for protecting the privacy of + LSAs and, in particular, the privacy of the PCE discovery + information. + + + + + + + + +Le Roux, et al. Standards Track [Page 15] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +9. Manageability Considerations + + Manageability considerations for PCE Discovery are addressed in + Section 4.10 of [RFC4674]. + +9.1. Control of Policy and Functions + + Requirements for the configuration of PCE discovery parameters on + PCCs and PCEs are discussed in Section 4.10.1 of [RFC4674]. + + In particular, a PCE implementation SHOULD allow the following + parameters to be configured on the PCE: + + - The PCE IPv4/IPv6 address(es) (see Section 4.1). + + - The PCE Scope, including the inter-domain functions + (inter-area, inter-AS, inter-layer), the preferences, + and whether the PCE can act as default PCE (see Section 4.2). + + - The PCE-Domains (see Section 4.3). + + - The neighbor PCE-Domains (see Section 4.4). + + - The PCE capabilities (see Section 4.5). + +9.2. Information and Data Model + + A MIB module for PCE Discovery is defined in [PCED-MIB]. + +9.3. Liveness Detection and Monitoring + + This document specifies the use of OSPF as a PCE Discovery Protocol. + The requirements specified in [RFC4674] include the ability to + determine liveness of the PCE Discovery protocol. Normal operation + of the OSPF protocol meets these requirements. + +9.4. Verify Correct Operations + + The correlation of information advertised against information + received can be achieved by comparing the information in the PCED TLV + received by the PCC with that stored at the PCE using the PCED MIB + [PCED-MIB]. The number of dropped, corrupt, and rejected information + elements are available through the PCED MIB. + +9.5. Requirements on Other Protocols and Functional Components + + The OSPF extensions defined in this document do not imply any + requirement on other protocols. + + + +Le Roux, et al. Standards Track [Page 16] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +9.6. Impact on Network Operations + + Frequent changes in PCE information advertised in the PCED TLV, may + have a significant impact on OSPF and might destabilize the operation + of the network by causing the PCCs to swap between PCEs. + + As discussed in Section 4.10.4 of [RFC4674], it MUST be possible to + apply at least the following controls: + + - Configurable limit on the rate of announcement of changed + parameters at a PCE. + + - Control of the impact on PCCs, such as through rate-limiting + the processing of PCED TLVs. + + - Configurable control of triggers that cause a PCC to swap to + another PCE. + +10. Acknowledgments + + We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike + Shand, and Lou Berger for their useful comments and suggestions. + + We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, Tim + Polk, and Lisa Dusseault for their comments during the final stages + of publication. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with + Digital Signatures", RFC 2154, June 1997. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July + 1998. + + [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", + RFC 2740, December 1999. + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic + Engineering (TE) Extensions to OSPF Version 2", RFC 3630, + September 2003. + + + +Le Roux, et al. Standards Track [Page 17] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + + [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., + and S. Shaffer, "Extensions to OSPF for Advertising + Optional Router Capabilities", RFC 4970, July 2007. + +11.2. Informative References + + [PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path + Computation Element Discovery", Work in Progress, March + 2007. + + [PCEP] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path + Computation Element (PCE) communication Protocol (PCEP) + ", Work in Progress, November 2007. + + [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. + + [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation + Element (PCE) Discovery", RFC 4674, October 2006. + + [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 18] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +Authors' Addresses + + Jean-Louis Le Roux (Editor) + France Telecom + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + FRANCE + EMail: jeanlouis.leroux@orange-ftgroup.com + + + Jean-Philippe Vasseur (Editor) + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA 01719 + USA + EMail: jpv@cisco.com + + + Yuichi Ikejiri + NTT Communications Corporation + 1-1-6, Uchisaiwai-cho, Chiyoda-ku + Tokyo 100-8019 + JAPAN + EMail: y.ikejiri@ntt.com + + + Raymond Zhang + BT + 2160 E. Grand Ave. + El Segundo, CA 90025 + USA + EMail: raymond.zhang@bt.com + + + + + + + + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 19] + +RFC 5088 OSPF Protocol Extensions for PCE Discovery January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Le Roux, et al. Standards Track [Page 20] + |