Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status:
InformationalStandards Track R. Zhang Expires: July 19,September 3, 2007 BT Infonet N. Bitar Verizon JL. Le Roux France Telecom January 15,March 2, 2007 A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths draft-ietf-pce-brpc-03.txtdraft-ietf-pce-brpc-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19,September 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The ability to compute constrainedshortest constrained Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraintconstrained paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. Requirements Language 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]. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Domain path selection . . . . . . . . . . . . . . . . . . 6 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 67 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 89 6. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9 7. Usage in conjunction with per-domain path computation . . . . 9 8. BRPC procedure completion failure . . . . . . . . . . . . . . 910 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Diverse end-to-end path computation . . . . . . . . . . . 10 9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 1011 10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 11. Path Computation failure . . . . . . . . . . . . . . . . . . . 11 12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 1112 13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 13.1. Control of Function and Policy . . . . . . . . . . . . . . 12 13.2. Information and Data Models . . . . . . . . . . . . . . . 12 13.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 13.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13 13.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 13 13.6. Impact on Network Operation . . . . . . . . . . . . . . . 13 13.7. Path computation chain monitoring . . . . . . . . . . . . 13 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1213 14.1. New flag of the RP object . . . . . . . . . . . . . . . . 1213 14.2. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 1214 15. Security Considerations . . . . . . . . . . . . . . . . . . . 1214 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1314 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1314 17.1. Normative References . . . . . . . . . . . . . . . . . . . 1314 17.2. Informative References . . . . . . . . . . . . . . . . . . 1315 Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] . . . . . . . . . . . . . . . . . . 1416 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1416 Intellectual Property and Copyright Statements . . . . . . . . . . 1618 1. Terminology ABR: routers used to connect two IGP areas (areas in OSPF or levels in IS-IS). ASBR: routers used to connect together ASsASes of a different orthe same or different Service ProviderProvider(s) via one or more Inter-AS links. Boundary Node (BN): a boundary node is either an ABR in the context of inter- area TEinter-area Traffic Engineering or an ASBR in the context of inter-AS TE.Traffic Engineering. Entry BN of domain(n): a BN connecting domain(n-1) to domain(n).domain(n) along a determined sequence of domains. Exit BN of domain(n): a BN connecting domain(n) to domain(n+1).domain(n+1) along a determined sequence of domains. Inter-AS TE LSP: A TE LSP that crosses an AS boundary. Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. LSR: Label Switching Router. LSP: Label Switched Path. PCC: Path Computation Client. Any client application requesting a path computation to be performed by the 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. PCE(i) is a PCE with the scope of domain(i). TED: Traffic Engineering Database. VSPT: Virtual Shortest Path Tree. The notion of contiguous, stitched and nested TE LSPs is defined in [I-D.ietf-ccamp-inter-domain-framework][RFC4726] and will not be repeated here. 2. Introduction The requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively. The framework for inter-domain MPLS Traffic Engineering has been provided in [I-D.ietf-ccamp-inter-domain-framework].[RFC4726]. [I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for establishing inter-domain (G)MPLS TE LSP whereby the path is computed during the signalling process on a per-domain basis by the entry boundary node of each domain (each node in charge of computing a section of an inter-domain TE LSP path is always along the path of such TE LSP). Such path computation technique fulfills some of the requirements stated in [RFC4105] and [RFC4216] but not all of them. In particular, it cannot guarantee to find an optimal (shortest) inter-domain constrained path. Furthermore, it cannot be efficiently used to compute a set of inter-domain diversely routed TE LSPs. The PCE architecture is defined in [RFC4655]. The aim of this document is to describe a PCE-based TE LSP computation procedure to compute optimal inter-domain constrained (G)MPLS TE LSPs. Qualifying a path as optimal requires some clarification. Indeed, a globally optimal TE LSP placement usually refers to a set of TE LSPs whose placements optimize the network resources with regards to a specified objective function (e.g. a placement that reduces the maximum or average network load while satisfying the TE LSP constraints). In this document, an optimal inter-domain constrained TE LSP is defined as the shortest path satisfying the set of required constraints that would be obtained in the absence of multiple domains (in other words, in a totally flat IGP network between the source and destination of the TE LSP). 3. General assumptions In the rest of this document, we make the following set of assumptions common to inter-area and inter-AS MPLS TE: - Each IGP area or AS is assumed to be Traffic Engineering enabled (i.e. running OSPF-TE or ISIS-TE and RSVP-TE). - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality. - While certain constraints like bandwidth can be used across different domains, other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary nodes, there will exist some sort of local mapping based on policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. - The various ASBRs are BGP peers, without any IGP running on the inter-ASBR links. -Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a single AS made of multiple IGP areas, multiples ASsASes made of a single IGP area or any combination of the above. For the sake of simplicity, each AS will be considered to be comprisedmade of a single area in this document. The case of an Inter-AS TE LSP spanning multiple ASsASes where some of those ASsASes are themselves made of multiple IGP areas can be easily derived from this case by applying the BRPC procedure described in this document, recursively. - The domain path (set of domains traversed to reach the destination domain) is either administratively pre-determined or discovered by some means (outsidethat are outside of the scope of this document).document. 4. BRPC Procedure The BRPC procedure is a Multiple-PCE path computation technique as described in [RFC4655]. A possible model consists of hosting the PCE function on boundary nodes (e.g., ABR or ASBR) but this is not mandated by the BRPC procedure. The BRPC procedure does not make any assumptions with regards to the nature of the inter-domain TE LSP that could be contiguous, nested or stitched. Furthermore, no assumption is made on the actual path computation algorithm in use by a PCE (it can be any variant of CSPF, algorithm based on linear-programming to solve multi-constraints optimization problems and so on). 4.1. Domain path selection The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific setsequence of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get tothe optimal constrained path between the source and the destination of the TE LSP. The BRPC procedure can also be used across a subset of all domain sequences, and the best path among these sequences is then selected. 4.2. Mode of Operation Definition of VSPT(i) In each domain i: * There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- en(k,i) is the kth entry BN of domain(i). * There is a set of X-ex(i) exit BNBNs noted BN-ex(k,i) where BN-ex(k,i)BN- ex(k,i) is the kth exit BN of domain(i). VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to PCE(i-1): Root (TE LSP destination) / I \ BN-en(1,i) BN-en(2,i) ... BN-en((j), i). Where j<=[X-en(i)] is the number of entry BN in domain i and j<= [X-en(i)] Each link of tree VSPT(i) represents the shortest path between BN- en(j,i) (identified by its TE Router-ID) and the destination that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, ...). These are path segments to reach the destination from BN-en(j,i). Note that PCE(i) only considers the entry BNs that provide connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only made of those BNs that provide connectivity from domain (i-1) to domain(i). Furthermore, some BNs may be excluded according to policy constraints (either due to local policy or policies signaled in the path computation request). Step 1: the PCC needs to first determine the PCE capable of serving its path computation request.request (this can be done thanks to local configuration or via IGP discovery (see [I-D.ietf-pce-disco-proto-ospf] and [I-D.ietf-pce-disco-proto-isis])). The path computation request is then relayed until reaching a PCE(n) such that the TE LSP destination resides in the domain(n). At each step of the process, the next PCE can either be statically configured or dynamically discovered via IGP/BGP extensions. If no next PCE can be found or the next hop PCE of choice is unavailable, the procedure stops and a path computation error is returned (see sectionSection 8). If multiple PCEs are discovered, the PCE may select a subset of these PCEs based on some local policies or heuristics. Note also that a sequence of PCEs might be enforced by policy on the PCC and this constraint can be eithercarried in the PCEP path computation request (defined(as defined in [I-D.ietf-pce-pcep].[I-D.vasseur-pce-monitoring]). Step 2: PCE(n) computes VSPT(n) made of the list of shortest constrained path(s) between every BN-en(j,n) and the TE LSP destination using a suitable path computation algorithm (e.g. CSPF) and returns the computed VSPT(n) to PCE(n-1). Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i)domain(i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i)domain(i) to the domain (i+1).domain(i+1). Then PCE(i) computes VSPT(i) (P2MP(MP2P (Multi-Point to Point) tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). End Finally PCE(1) computes the end-to-end shortest constrained path from the source to the destination and returns the corresponding path to the requesting PCC.PCC in the form of a PCRep message as defined in [I-D.ietf-pce-pcep]. Each branch of the VSPT tree (path) may be returned in the form of an explicit path (in which case all the hops along the path segment are listed) or a loose path (in which case only the BR is specified) so as to preserve confidentiality along with the respective cost. In the later case, various techniques can used in order to retrieve the computed explicit paths on a per domain basis during the signaling process thanks to the use of path keys as described in [I-D.bradford-pce-path-key]. BRPC guarantees to find the optimal (shortest) constrained inter- domain TE LSP according to a set of defined domains to be traversed. Note that other variants of the BRPC procedure relying on the same principles are also possible. Note also that in case of ECMP paths, more than one path could be returned to the requesting LSR. 5. PCEP Protocol Extensions The BRPC procedure requires the specification of a new flag of the RP object carried within the PCReq message (defined in [I-D.ietf-pce-pcep]), the aim of which is to specify that the shortest path(s) satisfying the constraints from the destination to the set of entry boundary nodes are requested (such set of path(s) forms the downstream VSPT as specified in Section 4.2). The following new flag of the RP object is defined: VSPT (V) flag: 0x60. When set, this indicates that the PCC requests the computation of an inter-domain TE LSP using the BRPC procedure. Because path segment(s) computed by a downstream PCE in the context of the BRPC procedure must be provided along with their respective path cost(s), the C flag of the METRIC object carried within the PCReq message MUST be set. It is the choice of the requester to appropriately set the O bit of the RP object. 6. Inter-AS TE Links In the case of Inter-AS TE LSP path computation, the BRPC procedure requires the knowledge of the traffic engineering attributes of the Inter-AS TE links: the process by which the PCE acquires this information is out of the scope of the BRPC procedure (which is compliant with the PCE architecture defined in [RFC4655]). That said, a straitghforward solution consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (there is no IGP adjacency over the inter-ASBR links). This allows the PCE of a domain to get entire TE visibility up to the set of entry ASBRs in the downstream domain. 7. Usage in conjunction with per-domain path computation The BRPC procedure may be used to compute path segments and could be usedin conjunction with other path computation techniques (such as the per-domainper- domain path computation technique defined in [I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end path. In this case end-to-end path optimality can no longer be guaranteed. 8. BRPC procedure completion failure If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message isMUST be returned to the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type which specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-Value are managed by IANA. A new Error-Type is defined that relates to the BRPC procedure. Error-type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or more PCEs along the domain path 9. Applicability As discussed in section Section 3, the requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively. Among the set of requirements, both documents indicate the need for some solution providing the ability to compute an optimal (shortest) constrained inter-domain TE LSP and to compute a set of diverse inter-domain TE LSPs. 9.1. Diverse end-to-end path computation PCEP allows a PCC to request the computation of a set of diverse TE LSPs thanks to the SVEC object by setting the flags L, N or S to request link, node or SRLG diversity respectively. Such request MUST be taken into account by each PCE along the path computation chain during the VSPT computation. In the context of the BRPC procedure, a set of diversely routed TE LSP between two LSRs can be computed since the paths segment(s) of the VSPT are simultaneously computed by a given PCE. The BRPC pathprocedure allows for the computation of diverse paths under various objective functions (such as minimizing the sum of the costs of the N diverse paths, etc) thus avoiding the well-knownwell- known "trapping" problem. Indeed, with a 2-step approach consisting of computing the first path followed by the computation of the second path after having removed the set of network elements traversed by the first path (if that does not violate confidentiality preservation), one cannot guarantee that a solution will be found even if such solution exists. Furthermore, even if a solution is found, it may not be the most optimal one with respect to an objective function such as minimizing the sum of the paths costs, bounding the path delays of both paths and so on. Finally, it must be noted that such a 2-step path computation approach is usually less efficient in term of signalling delays since it requires two serialized TE LSP set up. 9.2. Path optimality BRPC guarantees that the optimal (shortest) constrained inter-domain path will always be found subject to policy constraints. When combined with other local path computation techniques (e.g. in the case of stitched/nested TE LSP) and in the case where a domain has more than one BR-en or more than one BR-ex, optimality after some network change within the domain can only be guaranteed by re- executing the BRPC procedure. 10. Reoptimization of an inter-domain TE LSP The ability to reoptimize an existing inter-domain TE LSP path has been explicitly listed as a requirement in [RFC4105] and [RFC4216]. In the case of a TE LSP reoptimization request, regularthe reoptimization procedures apply asdefined in PCEP[I-D.ietf-pce-pcep] apply where the path in use (if available on the head-end) is provided withinas part of the path computation request in order for the PCEs involved in the reoptimization request to avoid double bandwidth accounting. 11. Path Computation failure If a PCE requires to relay a path computation request acccording to the BRPC procedure defined in this document to a downstream PCE thatand no such PCE is available, the PCE MUST send a negative path computation reply to the requester using a PCReq message as specified in [I-D.ietf-pce-pcep]that[I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case, the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (also defined(defined in [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path Computation chain unvailable" set. 0x04: BRPC Path computation chain unavailable 12. Metric normalization In the case of inter-area TE, the same IGP/TE metric scheme is usually adopted for all the IGP areas (e.g. based on the link-speed, propagation delay or some other combination of link attributes). Hence, the proposed set of mechanisms always computes the shortest path across multiple areas obeying the required set of constraints with respect to a well-specified objective function. Conversely, in the case of Inter-AS TE, in order for this path computation to be meaningful, a metric normalization between ASsASes may be required. One solution to avoid IGP metric modification would be for the SPs to agree on a TE metric normalization scheme and use the TE metric for TE LSP path computation (in that case, this must be requested in the PCEP Path computation request) thanks to the COST object.METRIC object (defined in [I-D.ietf-pce-pcep]). 13. Manageability Considerations To be added in a further revision of this document. 14. IANA Considerations 14.1. New flag of the RP object A new flagThis section is compliant with [I-D.ietf-pce-manageability-requirements]. 13.1. Control of the RP object (specified in [I-D.ietf-pce-pcep])Function and Policy The only configurable item is defined in this document. Name: VSPT (V) Bit Number: 10 Value: 0x60 When set, this indicates that the PCC requeststhe computationsupport of an inter-domain TE LSP usingthe BRPC procedure. A new Error-Type is defined in this document (Error-Type and Error- value to be assigned by IANA). Error-type Meaning 13 BRPCprocedure completion failure Error-value 1:on a PCE. The support of the BRPC procedure not supportedby one or PCEs alongthe domain path 14.2. New flagPCE MAY be controlled by a policy module governing the conditions under which a PCE should participate to the BRPC procedure (origin of the NO-PATH-VECTOR TLV A new flagrequests, number of requests per second, ...). If the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep])BRPC is not supported/allowed on a PCE, it MUST send a PCErr message as specified in this document. Defining RFC: draft-ietf-pce-pcep (toSection 8. 13.2. Information and Data Models A BRPC MIB module will be replaced by RFC number when pusblished) Name of bit:specified in a separate document. 13.3. Liveness Detection and Monitoring The BRPC Path computation chainprocedure is a Multiple-PCE path computation technique and as such a set of PCEs are involved in the path computation chain. If the path computation chain is not operational either because at least one PCE does not support the BRPC procedure or because one of the PCEs that must be involved in the path computation chain is not available, procedures are defined to report such failures in Section 8 and Section 11 respectively. Furthermore, a built in diagnostic tool to check the availability and performances of a PCE chain is defined in [I-D.vasseur-pce-monitoring]. 13.4. Verifying Correct Operation Verifying the correct operation of BRPC can be done by looking at the TEDs related to the various domains traversed by a TE LSP at the time the BRPC procedure was invoked and verify that the path computed by the BRPC procedure is the expected optimal path (the path that would be obtained in the absence of multiple domains). 13.5. Requirements on Other Protocols and Functional Components The BRPC procedure does not put any new requirements on other protocol. That said, since the BRPC procedure relies on the PCEP protocol, there is a dependency between BRPC and PCEP; consequently the BRPC procedure inherently makes use of the management functions developped for PCEP. 13.6. Impact on Network Operation The BRPC procudure does not have any significant impact on network operation: indeed, BRPC is a Multiple-PCE path computation scheme as defined in [RFC4655] and does not differ from any other path computation request. 13.7. Path computation chain monitoring [I-D.vasseur-pce-monitoring] specifies a set of mechanisms that can be used to gather PCE state metrics. Because BRPC is a Multiple-PCE path computation techniques, such mechanims could be advantageously used in the context of the BRPC procedure to check the liveness of the path computation chain, locate a faulty component, monitor the overall performance and so on. 14. IANA Considerations 14.1. New flag of the RP object A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is defined in this document. Name: VSPT (V) Bit Number: 10 Value: 0x60 When set, this indicates that the PCC requests the computation of an inter-domain TE LSP using the BRPC procedure. A new Error-Type is defined in this document (Error-Type and Error- value to be assigned by IANA). Error-type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or PCEs along the domain path 14.2. New flag of the NO-PATH-VECTOR TLV A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) is specified in this document. Defining RFC: draft-ietf-pce-pcep (to be replaced by RFC number when pusblished) Name of bit: BRPC Path computation chain unavailable Bit number (suggested value): 0x04 15. Security Considerations The BRPC procedure does not introduce any additionalrelies on the use of the PCEP protocol and as such is subjected to the potential attacks listed in section 11 of [I-D.ietf-pce-pcep]. In addition to the security issues beyondmechanisms described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, falsification and Denial of Service, an implementation MAY support a policy module governing the ones relatedcondditions under which a PCE should participate to inter-PCE communication.the BRPC procedure. The BRPC procedure does not increase the information exchanged between ASes and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216]. 16. Acknowledgements The authors would like to thank Arthi Ayyangar, Dimitri Papadimitriou and Siva Sivabalan for their useful comments. A special thank to Adrian Farrel for his useful comments and suggestions. 17. References 17.1. Normative References [I-D.ietf-pce-pcep] Roux, J. and J. Vasseur, "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-05(PCEP)", draft-ietf-pce-pcep-06 (work in progress), JanuaryFebruary 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. 17.2. Informative References [I-D.bradford-pce-path-key] Bradford, R., "Preserving Topology Confidentiality in Inter-Domain Path Computation using a key based mechanism", draft-bradford-pce-path-key-02 (work in progress), January 2007. [I-D.ietf-ccamp-inter-domain-framework] Farrel, A., "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", draft-ietf-ccamp-inter-domain-framework-06 (work in progress), August 2006.[I-D.ietf-ccamp-inter-domain-pd-path-comp] Vasseur, J., "A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-comp-03draft-ietf-ccamp-inter-domain-pd-path-comp-04 (work in progress), August 2006.February 2007. [I-D.ietf-ccamp-inter-domain-rsvp-te] Ayyangar, A. and J. Vasseur,A., "Inter domain MPLSMultiprotocol Label Switching (MPLS) and GMPLSGeneralized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-rsvp-te-04draft-ietf-ccamp-inter-domain-rsvp-te-05 (work in progress), JanuaryMarch 2007. [I-D.ietf-pce-disco-proto-isis] Roux, J., "IS-IS protocol extensions for Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-proto-isis-02 (work in progress), February 2007. [I-D.ietf-pce-disco-proto-ospf] Roux, J., "OSPF protocol extensions for Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-proto-ospf-02 (work in progress), February 2007. [I-D.ietf-pce-manageability-requirements] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", draft-ietf-pce-manageability-requirements-01 (work in progress), March 2007. [I-D.vasseur-pce-monitoring] Roux, J. and J. Vasseur, "A set of monitoring tools for Path Computation Element based Architecture", draft-vasseur-pce-monitoring-02 (work in progress), March 2007. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005. [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] This Internet-Draft is being submitted for eventual publication as an RFC with a proposed status of Informational.Standard. Discussion of this proposal should take place on the following mailing list: firstname.lastname@example.org. Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: email@example.com Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: firstname.lastname@example.org Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA Email: email@example.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion, 22307 FRANCE Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).