idnits 2.17.00 (12 Aug 2021) /tmp/idnits2485/draft-boucadair-pce-interas-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 42 has weird spacing: '...CE) as a me...' == Line 128 has weird spacing: '...service level...' == Line 129 has weird spacing: '...ncludes servi...' == Line 130 has weird spacing: '...between peer ...' == Line 134 has weird spacing: '...rmation as i...' == (18 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6208 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2385' is defined on line 683, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Unexpected draft version: The latest known version of draft-boucadair-pcp-interas is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'INTERAS-PCP' -- Possible downref: Normative reference to a draft: ref. 'PCE-DISCOVERY' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Boucadair (Ed.) 3 IETF Internet Draft P. Morand (Ed.) 4 Document: draft-boucadair-pce-interas-01.txt France Telecom R&D 5 Proposed Status: Informational May 2005 6 Expires: November 2005 8 A Solution for providing inter-AS MPLS-based QoS tunnels 9 < draft-boucadair-pce-interas-01.txt > 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667 [RFC3667]. By submitting this Internet- 15 Draft, each author represents that any applicable patent or other IPR 16 claims of which he or she is aware have been or will be disclosed, 17 and any of which he or she become aware will be disclosed, in 18 accordance with RFC 3668 [RFC3668]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 2005. 38 Abstract 40 This document describes a solution for providing inter-AS MPLS-based 41 Quality of Service (QoS) tunnels. This solution makes use of Path 42 Computation Elements (PCE) as a means to compute inter-domain 43 constraint-based paths. Service considerations and agreements between 44 two IP Network Providers (INP) implementing this solution are also 45 described. 47 Copyright Notice 48 providing inter-AS MPLS-based QoS tunnels 50 Copyright (C) The Internet Society. (2005) 52 Table of Contents 54 1. Contributors................................................2 55 2. Changes since last version:.................................2 56 3. Terminology.................................................2 57 4. Introduction................................................3 58 4.1. General.....................................................3 59 4.2. Assumptions.................................................4 60 4.3. Draft structure.............................................5 61 5. Conventions used in this document...........................5 62 6. Inter-AS PCE model..........................................5 63 7. Inter-provider Service Considerations.......................7 64 8. Path Computation Element functions..........................8 65 9. PCE discovery..............................................10 66 10. PCE to PCE Communication...................................10 67 11. Routing considerations.....................................11 68 11.1. Assumptions.................................................11 69 11.2. Finding inter-domain LSP paths..............................11 70 12. Communication between PCE and LSR/LER for initiating 71 LSP set-up...............................................13 72 13. Advanced features..........................................13 73 13.1. Exclusion of specific ASs from the path.....................13 74 13.2. Feedback....................................................13 75 14. Security Considerations....................................14 76 15. References.................................................14 77 16. Acknowledgments............................................14 78 17. Author's Addresses.........................................15 80 1. Contributors 82 o Hamid Asgari (Thales Research and Technology) 83 o Noel Butler (Thales Research and Technology) 84 o Panagiotis Georgatsos (Algonet) 85 o David Griffin (University College London) 86 o Micheal Howarth (University of Surrey) 88 2. Changes since last version: 90 The main changes occurred in this version are: 91 o Add new contributor to the draft 92 o Rewording of several sections of the draft 94 3. Terminology 96 This memo makes use of the following terms: 98 providing inter-AS MPLS-based QoS tunnels 100 o Path Computation Element (PCE): an entity that is responsible 101 for computing/finding inter/intra domain MPLS tunnels (LSPs). 102 This entity can simultaneously act as client and a server. 103 Several PCEs can be deployed in a given AS. 105 o Path Computation Client (PCC): a PCE acting as a client. This 106 entity is responsible for issuing path computation requests that 107 fulfill the Service Management constraints for the establishment 108 of inter/intra domain LSPs. 110 o Path Computation Server (PCS): a PCE acting as a server. This 111 entity is responsible for handling path computation requests 112 including neighboring PCC constraints. 114 o High-level service: the service employing a PCE-based system as 115 the underlying infrastructure for creating e.g., inter-domain 116 QoS VPNs. 118 o High-level service customer: the customer that subscribes to a 119 High-level service. 121 o pSLS(provider SLS): A provider level SLS, which is established 122 for specific QoS class between two Internet Network Providers 123 (INP) for exchanging traffic in the Internet with the purpose to 124 expand the geographical span of their offered services. pSLSs 125 are meant to support aggregate traffic and they are assumed to 126 exist prior to any agreements with end customers. 128 o SLS Management: a service level management system, which 129 includes service ordering (i.e for establishing contracts 130 between peer providers) and service invocation (i.e for 131 committing resources before traffic can be admitted) 133 o q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into 134 account QoS information as input for its route selection 135 process. 137 o Domain: within this document it denotes an Autonomous System. 139 4. Introduction 141 4.1. General 143 The level of Quality of Service (QoS) guarantees offered by INPs 144 using a pure IP-based traffic engineering (TE) solution, other than 145 overbooking, is not yet satisfactory for all corporate business 146 services, for which strong guarantees must be provided. For this type 147 of customers, hard QoS performance and bandwidth guarantees are 148 considered as the major requirements. 150 providing inter-AS MPLS-based QoS tunnels 152 Currently, these requirements can be satisfied within a single domain 153 or across several interconnected domains managed only by a single 154 INP. However, it becomes very challenging when these domains are 155 managed by different INPs. Each INP defines and deploys its own QoS 156 policy within the scope of its domain(s), utilizes its proprietary TE 157 functions, etc. 159 Providing QoS-based services within the scope of the Internet 160 requires the collaboration among INPs in order to offer this type of 161 services. This document aims at proposing a solution that will 162 facilitate the introduction of such services in an Inter-provider 163 environment. Service considerations are also taken into account. 165 4.2. Assumptions 167 In this document, we assume the following: 169 o An AS can announce a given prefix in several QoS planes; each of 170 these QoS planes being identified across inter-domain links by a 171 unique DiffServ Code Point (DSCP); 173 o Each announcement, except best effort ones, contains values of a 174 set of QoS parameters that characterizes the likely end-to-end 175 QoS to be experienced for reaching a given prefix (we call this 176 end-to-end QoS as aggregated QoS); 178 o The way aggregated QoS values are computed is out of the scope 179 of this document; 181 o Adjacent ASs agree on the DSCP values to use in order to signal 182 a given QoS class at inter-domain links (we call these DSCP 183 values inter-domain DSCPs); 185 o Every AS has the freedom to bind an inter-domain DSCP to a local 186 DSCP within its domain, which identifies its local QoS class for 187 signalling a QoS planes in its domain; 189 o An AS supporting the inter-domain MPLS-based QoS tunnels 190 service, owns a Path Computation Service Identifier(s) (PCSID), 191 which is a routable IP address. This IP address is not 192 necessarily the IP address(es) of the PCE(s) of the domain. 193 These PCSIDs are announced per QoS plane basis, by an inter- 194 domain routing protocol, together with the planeÆs aggregated 195 QoS values; 197 o ASs can discover other ASs supporting the inter-domain MPLS- 198 based QoS tunnels service by receiving inter-domain routing 199 protocol announcements. These announcements provide an AS with 200 providing inter-AS MPLS-based QoS tunnels 202 the end-to-end QoS characteristics of the path towards any 203 prefix of the remote AS owning the PCSID. 205 4.3. Draft structure 207 The structure of this document is as follows: 209 o Section 5 describes the inter-AS PCE model. 211 o Section 6 discusses the service considerations. 213 o Section 7 highlights PCE functions. 215 o Section 8 explains the PCE discovery function. 217 o Section 9 gives an overview of the PCP protocol that is used for 218 communication between PCEs. 220 o Section 10 and 11 describe routing issues. 222 o Finally, section 12 presents some advance features in order to 223 enhance PCE service. 225 5. Conventions used in this document 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC-2119 [RFC2119]. 231 6. Inter-AS PCE model 233 A Path Computation Element (PCE) is responsible for finding an inter- 234 domain path satisfying a set of constraints (e.g. specific QoS 235 performance guarantees requested by a customer), in order to 236 establish inter-domain constraint-based LSPs. 238 In an inter-provider environment, the computation of this path is 239 necessarily distributed and required communication between PCEs of 240 different domains. Communication between PCE entities is achieved via 241 the PCE Communication Protocol (PCP, [INTERAS-PCP]). Once computed, 242 the path is provided to the RSVP-TE/MPLS machinery of the head-end 243 Label Switching Router (LSR), which can request/establish an inter- 244 domain Label Switching Path (LSP) that will follow the inter-domain 245 path provided by the PCE. 247 +----------------+ 248 | | 249 +----+ AS1 +----+ 251 providing inter-AS MPLS-based QoS tunnels 253 ..........|ASBR| |ASBR|.......... BGP Session 254 . +----+ +----+ . 255 . | | . 256 . | +----+ | . 257 . +-----|PCE |-----+ . 258 . +----+ . 259 . ^ ^ . 260 . | | . 261 . | | . 262 +----+ | | +----+ 263 +-----|ASBR|-----+ | | +-----|ASBR|-----+ 264 | +----+ | | | | +----+ | 265 | AS2 +----+ | | +----+ AS3 | 266 | | P | | | | P | | 267 | | C |<---------/ \-------->| C | | 268 | | E |<--------------------->| E | | 269 | +----+ +----+ | 270 | | | | 271 | +----+ | | +----+ | 272 +-----|ASBR|-----+ +-----|ASBR|-----+ 273 +----+ +----+ 274 |. . . . . . . . . . . . . . . . . . . . . . . | 276 ...: Peering links 277 ---: inter-PCE session 279 Figure 1: Inter-AS PCE scenario 281 In the above figure, we assume that each domain operates a set of 282 QoS-classes. Each INP deploys its own local QoS-classes with specific 283 QoS characteristics. QoS-classes in a domain have not necessarily the 284 same QoS characteristics with QoS-classes in the other domains. We 285 also assume that service level QoS-based contracts (pSLSs) have been 286 established between adjacent domains. BGP is running between these 287 adjacent ASs. Each AS learns, the set of destinations its peer 288 domains can reach, together with end-to-end QoS performance 289 characteristics. 291 When a pSLS is established, the domains exchange their respective PCE 292 information (name, IP address, identifiers, authentication 293 information, etc.). 295 In order to create an inter-domain constraint-based LSP, the domain 296 which requests the establishment of the LSP asks its PCE to compute 297 an inter-domain path satisfying a set of constraints, (for example 298 bandwidth guarantee per QoS-Class, maximum end-to-end delay, etc.) 300 The first PCE selects one possible path among the set of alternatives 301 and identifies the next-hop domain. It then verifies that appropriate 302 resources are available in its own domain and sets up administrative 303 pre-reservations in the management system of its domain. Then it 304 providing inter-AS MPLS-based QoS tunnels 306 contacts the next hop PCE, requesting a path computation between the 307 next hop AS Border Router (ASBR) and the termination address of the 308 inter-domain LSP. This second PCE performs the same computation as 309 the first one did and the procedure is iteratively repeated up to the 310 last PCE. If a path satisfying all requirements is found, each PCE 311 returns the path received from the responding PCE concatenated with 312 the sub-path it computed. Finally, the originating PCE receives the 313 whole computed path. 315 7. Inter-provider Service Considerations 317 A pSLS MUST be established between two neighbors in order to grant to 318 the requestor the appropriate rights for requesting and/or 319 establishing inter-domain LSPs (see figure below). Nevertheless, 320 information like destination and number of future LSPs to be 321 established is not known in advance. The pSLS indicates only the 322 upper-boundaries that the upstream AS is allowed to use, in terms of 323 QoS-class identifiers that can be used at the inter-domain for 324 establishing inter-domain LSP and in terms of maximum bandwidth 325 associated to each QoS-class. 327 The pSLS agreement does not reserve any network resources in advance. 328 Resources are only allocated when an inter-domain LSP is set up. The 329 management plane of each downstream domain along the path SHOULD be 330 aware of the existence of those LSPs together with their associated 331 QoS guarantees. 333 +--------High Level Service Agreement--------+ 334 | | 335 v v 336 <----AS1-----> <----AS2-----> <----AS3-----> 337 ' ' ' ' ' ' 338 ' '<-pSLS->' '<- pSLS->' ' 339 ' ' ' ' ' ' 340 +------------+ +------------+ +------------+ 341 | PCE | | PCE | | PCE | 342 | | | | | | 343 | +------+ | | +------+ | | +------+ | 344 | | PCC | | | | PCC | | | | PCC | | 345 | | |<-|--\ | | |<-|--\ | | | | 346 | +--/\--+ | | | +--/\--+ | | | +--/\--+ | 347 | || | |PCP | || | |PCP | || | 348 | || | | | || | | | || | 349 | +--\/--+ | | | +--\/--+ | | | +--\/--+ | 350 | | PCS | | \-----|->| PCS | | \------|->| PCS | | 351 | | | | | | | | | | | | 352 | +------+ | | +------+ | | +------+ | 353 +------------+ +------------+ +------------+ 355 Figure 2: Service Overview 357 providing inter-AS MPLS-based QoS tunnels 359 However, it is difficult to establish such a contract in advance 360 especially when the LSP path is not known in advance. Thus, the 361 sequence of operation for establishing an LSP should be: 363 o Compute inter-domain path candidate(s); 364 o Select and request an inter-domain path for this particular LSP 365 using information returned by the PCE, 366 o Establish the LSP once final negotiation terms have been agreed 367 end-to-end between PCEs of adjacent domains. 369 The establishment of this cascade of negotiations can be difficult to 370 achieve and can take some time. In particular, the risk is not 371 negligible that the resources that were available when the PCE 372 performed the path computation are no longer available along the path 373 when the cascaded negotiation terms are agreed, because others LSPs 374 have used the corresponding resources. 376 In order to solve this issue it is necessary that the PCE of each 377 domain makes an administrative reservation of the corresponding 378 resources and indicates the characteristics of the path. This 379 information is registered by the management plane, which triggers in 380 parallel the creation of a provisional contract referencing the 381 technical characteristics of the future LSP. Subsequent path 382 computation requests may be impacted because the management plane 383 removes these resources from the available overall network resources. 384 This provisional contract is valid for a limited time period, which 385 is the minimum of time periods each specified and reported by a 386 domain along the path. If time period expires, the provisional 387 contract can be removed from the management systems, and related 388 administrative network resources have to be informed. 390 It is the responsibility of the management plane of each domain to 391 cooperate in agreeing the exact financial terms and additional 392 clauses of this contract, including its duration. Each domain knows 393 the entry and the exit point of the LSP within its own domain and 394 consequently knows both the upstream and downstream ASs to deal with. 395 This validation procedure SHOULD ideally be automated to speed up the 396 process and could integrate pricing negotiation. The way that the 397 other blocks of the management plane deal with this automation is out 398 the scope of this document. 400 Thus, once the pre-contract is validated, the path computed by the 401 PCE can be provided to the head-end LSP, which effectively sets up 402 the LSP. Note that every ingress point of each domain SHOULD activate 403 some outsourced policy functions that would allow RSVP TE to get an 404 agreement from the management system. 406 8. Path Computation Element functions 407 providing inter-AS MPLS-based QoS tunnels 409 The main function provided by a PCE is to contribute to the overall 410 path computation by computing part of the end-to-end inter-domain 411 path satisfying a set of constraints. The management plane could call 412 other elementary services such as requesting a path computation for 413 informational purposes or canceling a request in progress for 414 instance. 416 The deployment and the maintenance of the LSP connectivity require 417 cooperation of several functional entities from different planes. 418 Within this document, the PCE is only responsible for computing an 419 inter-domain constraint-based path. The implementation of the service 420 (whether it is automated or not) and the creation of inter-domain LSP 421 results from the cooperation of functional blocks, control plane 422 blocks and data plane blocks arenÆt described in this document. 424 The PCE does not itself trigger the establishment of any inter-domain 425 LSP, but provides inter-domain paths, if they are available. Unlike 426 the management plane, it is not aware of business considerations A 427 PCE entity provides an interface used by the service management block 428 to request a path computation. It communicates with other remote PCE 429 thanks to the PCP protocol and requests additional services from 430 other functional blocks as illustrated in the figure below: 432 +---------------------+ 433 | Service Management | 434 +----------o----------+ 435 | 436 | 437 v 438 +----------+ +----------+ +----------+ 439 | PCE |<---------->| PCE |<---------->| PCE | 440 +----------+ +----------+ +----------+ 441 | 442 /----------------+-----------------+----------------\ 443 | | | | 444 +---v---+ +---v---+ +---v---+ +---v---+ 445 | | | | | | | | 446 |BW Mgt | | SLS | |Access | | Intra | 447 | | | Mgt | | & | | & | 448 | | | | |Author | | Inter | 449 | | | | | | | TE | 450 | | | | | | | | 451 +-------+ +-------+ +-------+ +-------+ 452 Figure 3: PCE Interactions 454 The PCE interacts with the dynamic routing processes to retrieve 455 routing information that is used to compute an inter-domain path 456 satisfying the expressed constraints. An interface MUST be made 457 available to the PCE so that it can access routing information. Note 458 that both intra and inter-domain routes MUST be made available to the 459 PCE. 461 providing inter-AS MPLS-based QoS tunnels 463 In addition, for access control and authorization purposes, the PCE 464 MUST be provided with access to the list of other PCEs from which it 465 will accept requests. This list is updated each time new pSLSs are 466 negotiated by the INP. 468 9. PCE discovery 470 Within this document, we assume that during the service negotiation 471 phase the peers exchange the IP addresses of their respective PCE(s). 472 This information is stored in the SLS Management Systems of each INP. 474 As described in [PCE-DISCOVERY], instead of announcing all potential 475 tail-end addresses in BGP, only an identifier is announced via BGP. 476 It is called the Path Computation Service Identifier (PCSID). This 477 particular BGP announcement is identified by a well-known community 478 value (to be defined by IANA) and is represented by a routable IP 479 address, which can be different from the real IP address of the PCE. 481 As a consequence, this particular route SHOULD NOT be installed in 482 the Forwarding Information Base (FIB) since this PCSID is not 483 necessarily the IP address of the PCE. 485 BGP announcements of PCSID will ease to discover the set of remote 486 ASs supporting the inter-AS MPLS-based QoS tunnels service and 487 associated end-to-end QoS-related information for reaching them. In 488 order to compute a path towards a specific domain supporting this 489 inter-AS MPLS-based QoS tunnels service, the local PCE chooses a 490 route that serves the PCSID of that domain and extracts from the 491 AS_PATH attribute the AS number of the next hop ASBR. Then, the local 492 PCE queries its SLS Management system and gets back the PCE's IP 493 address of the next neighboring PCE to contact. Finally, the local 494 PCE forms and forwards a path computation request to the next PCE. 495 The process is iteratively repeated until the request reaches the PCE 496 of the target AS identified by its PCSID. 498 10. PCE to PCE Communication 500 A PCE can act as a client (Path Computation Client, PCC) or a server 501 (Path Computation Server, PCS). The PCC is responsible for issuing 502 Path Computation requests. The PCS is responsible for handling 503 requests received from PCCs. 505 The PCP (Path Computation Protocol) is a simple query and response 506 protocol that is used for communication between PCE entities, i.e., 507 PCC and PCS. 509 +------------+ +------------+ 510 | PCE | | PCE | 511 providing inter-AS MPLS-based QoS tunnels 513 | | | | 514 | +------+ | | +------+ | 515 | | PCC | | | | PCC | | 516 | | |<-|-------\ | | | | 517 | +--/\--+ | | | +--/\--+ | 518 | || | |PCP | || | 519 | || | | | || | 520 | +--\/--+ | | | +--\/--+ | 521 | | PCS | | \---------------|->| PCS | | 522 | | | | | | | | 523 | +------+ | | +------+ | 524 +------------+ +------------+ 525 Figure 4: PCC to PCS communication 527 The main characteristics of the PCP protocol are: 529 o The protocol employs a client/server model in which a PCE can 530 both act as a client and/or a server at the same time. A PCE 531 Client (PCC) sends requests, cancellation and receives 532 responses. 534 o The protocol uses TCP as its transport protocol, providing the 535 reliable exchange of messages between PCEs. 537 o In its first version, PCP does not provide any message level 538 security for authentication, message replay protection, and 539 integrity. However, PCP can reuse existing protocols for 540 security such as IPSEC [RFC2401] or TLS [RFC2246] to 541 authenticate and secure the channel between two PCE. 543 o The current PCP protocol provides the service for supporting 544 only a basic path computation function. In particular it does 545 not support the service for additional path computation 546 constraints, or provide enhanced reporting features in the case 547 of path computation failure. 549 11. Routing considerations 551 11.1. Assumptions 553 We assume in this document that PCE addresses are only announced in a 554 few QoS-Class planes. Addresses of LSR/LER interfaces could be 555 announced in the best effort plane. This reduces the number of BGP 556 announcements to one announcement per PCE per AS. By setting a well- 557 known community value, we specify announcements that serve PCEs. 558 These are not regarded as routes and are not stored in the FIBs. 560 11.2. Finding inter-domain LSP paths 561 providing inter-AS MPLS-based QoS tunnels 563 In order to find an inter-domain path, the PCE MUST be provided with 564 a set of attributes including the information describing head-end and 565 tail-end of the LSP and the performance requirements for the LSP. The 566 aforementioned information MUST include the loopback IP address of 567 its LSR, and the IP Address of the PCE of its domain (notation is 568 IPADDRESS@PCSID). This information MUST also include the performance 569 guarantees required for the inter-domain constraint-based LSP. This 570 information MAY encompasses the requested QoS-class(es) so that the 571 set of collaborating PCE can compute a path that will cross a set of 572 domain satisfying the expressed constraints. 574 It can also contain, per QoS-class, additional QoS performance 575 guarantees that the PCE must take into account. These performance 576 guarantees include guaranteed end-to-end delay, jitter, loss rate 577 and/or bandwidth. Note that these parameters can differ depending on 578 the type of requested QoS-class, and they MAY not all be present in 579 the LSP set-up request. If included in the path computation request 580 they MUST be taken into account by the PCE. If the PCE doesn't 581 recognize a given QoS parameter, the PCE MUST stop its computation 582 and MUST return an error (PCP Error Message). 584 When computing a path, a PCE interacts with other blocks of the 585 management plane. In particular, it checks the availability of the 586 resources within the boundaries of its domain. If the resources are 587 available, and the sub-path (path between the ingress point of its 588 domain and a potential ingress point of a given domain) conforms to 589 the path constraints requested, it MUST inform the management plane 590 of a pre-reservation concerning this path. This information can then 591 be taken into account when processing other path computation 592 requests. Once this operation succeeds, the request is propagated to 593 the next domain PCE, which has been selected by the PCE of this 594 domain. 596 Note that the performance guarantees requested MUST be updated before 597 forwarding it to the next domain by taking into account the 598 performance figures already observed along the computed sub-path plus 599 the performance figures within its own domain. Therefore, PCE MUST be 600 aware of the above performance figures of the QoS-classes. 602 The requesting PCE MUST use the QoS-class identifier they agreed 603 during the pSLS negotiation phase in order to signal a given QoS- 604 class. 606 If an end-to-end LSP has to be re-engineered because the associated 607 constraints have changed in terms of QoS-class requested, bandwidth, 608 delay, etc., a new end-to-end path needs to be computed. In order to 609 improve its chances of finding a valid path, the requestor can 610 specify that the path for which the request is issued will replace a 611 previously established LSP. For doing so, the requestor can indicate 612 the reference of the path corresponding to this LSP. A PCE can 613 release, during the path computation process, the resources 614 providing inter-AS MPLS-based QoS tunnels 616 corresponding to the former LSP, if the new path follows part of the 617 former path. This reference is stored in the management plane of each 618 domain and is generated by the initial requestor. This reference is 619 globally unique. 621 The ability to address such additional constraints can be interesting 622 in the case of backup LSPs, so that the PCE can compute a path along 623 a different route. These considerations are out of scope of this 624 document. 626 12. Communication between PCE and LSR/LER for initiating LSP set-up 628 Communication between PCE and an LER/LSR could be achieved thanks to 629 the use of Common Open Policy Service protocol (COPS, [RFC2748]). An 630 RSVP client-type could be used in order to convey configuration data 631 resulting from the computation operation executed by a PCE. 632 Specification of RSVP configuration data is out of scope of this 633 document. 635 13. Advanced features 637 13.1. Exclusion of specific ASs from the path 639 If a PCE in the chain wants to exclude particular AS(s) from the 640 path, additional constraints (that can be expressed using the AS 641 number of the excluded domain/s) MUST be added to the request message 642 body and MUST be propagated downstream. 644 13.2. Feedback 646 When computing a path, the PCEs can fail to find a path for a number 647 of reasons. These failures, in normal operations, will be mainly due 648 to the lack of resources, or not meeting the requested QoS 649 requirements. In such a situation, a path, which would have been the 650 optimal path, would not be established. Identifying the domain/s 651 where the path computation failed, together with the reasons, would 652 be of a real added value for providers in order to improve their 653 efficiency. 655 A proposal for achieving this is to rely on the Path Computation 656 Protocol, which could be improved to return all the path alternatives 657 which were tried but have failed. In doing so, the requesting 658 provider would be aware of the reasons of the failure and possibly 659 interact with that AS where the path computation failed and aborted. 661 The AS (where the path computation failed), faces with multiple 662 requests, from external domains, could consider a possible 663 providing inter-AS MPLS-based QoS tunnels 665 modification of some of its peering agreements based on business 666 objectives. 668 14. Security Considerations 670 This document does not change the underlying security issues in the 671 PCP and BGP protocols specifications. It is recommended that a 672 security protocol like IPSec or TLS to be activated in order to 673 protect PCP sessions. 675 15. References 677 [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, 678 February 2004 680 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 681 Technology", RFC 3668, February 2004 683 [RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP 684 MD5 Signature Option", RFC 2385, August 1998 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997 689 [INTERAS-PCP] Boucadair M., Morand P., "Inter PCE Communication 690 Protocol", draft-boucadair-pcp-interas-01.txt, May 2005 692 [PCE-DISCOVERY] Boucadair M., Morand P., "PCE discovery via Border 693 Gateway Protocol", draft-boucadair-pce-discovery-01.txt, Work in 694 progress, May 2005 696 [RFC2401] Atkinson R., "Security Architecture for the Internet 697 Protocol", RFC 2401, August 1998 699 [RFC2246] Dierks T., Allen C., "The TLS Protocol", RFC 2246, January 700 1999 702 [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and 703 A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 704 2748, January 2000. 706 16. Acknowledgments 708 The authors would also like to thank all the partners of the MESCAL 709 (Management of End-to-End Quality of Service Across the Internet At 710 Large, http://www.mescal.org) project for the fruitful discussions. 712 providing inter-AS MPLS-based QoS tunnels 714 17. Author's Addresses 716 Mohamed Boucadair 717 France Telecom R & D 718 42, rue des Coutures 719 BP 6243 720 14066 Caen Cedex 4 721 France 722 Phone: +33 2 31 75 92 31 723 Email: mohamed.boucadair@francetelecom.com 725 Pierrick Morand 726 France Telecom R & D 727 42, rue des Coutures 728 BP 6243 729 14066 Caen Cedex 4 730 France 731 Email: pierick.morand@francetelecom.com 733 Intellectual Property Statement 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed to 737 pertain to the implementation or use of the technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; nor does it represent that it has 740 made any independent effort to identify any such rights. Information 741 on the procedures with respect to rights in RFC documents can be 742 found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use of 747 such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository at 749 http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at 755 ietf-ipr@ietf.org. 757 Disclaimer of Validity 759 This document and the information contained herein are provided on an 760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 762 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 763 providing inter-AS MPLS-based QoS tunnels 765 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 766 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 767 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 769 Copyright Statement 771 Copyright (C) The Internet Society (2005). This document is subject 772 to the rights, licenses and restrictions contained in BCP 78, and 773 except as set forth therein, the authors retain all their rights.