idnits 2.17.00 (12 Aug 2021) /tmp/idnits17090/draft-boucadair-pce-comm-proto-00.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 3978, Section 5.5 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1050. ** 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. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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: '... order to c...' == Line 124 has weird spacing: '...cluding pSLS ...' == Line 138 has weird spacing: '... rely for ...' == Line 199 has weird spacing: '... The path ...' == Line 252 has weird spacing: '...ntities to c...' == (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) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: draft-ietf-tewg-interarea-mpls-te-req has been published as RFC 4105 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interarea-mpls-te-req (ref. 'INTERAREA-REQ') == Outdated reference: draft-ietf-tewg-interas-mpls-te-req has been published as RFC 4216 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interas-mpls-te-req (ref. 'INTERAS-REQ') == Outdated reference: draft-ietf-pce-architecture has been published as RFC 4655 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-architecture (ref. 'PCE-ARCH') == Outdated reference: draft-ietf-ccamp-inter-domain-framework has been published as RFC 4726 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-inter-domain-framework (ref. 'PCE-FWK') -- Possible downref: Normative reference to a draft: ref. 'INTERAS-PCE' -- 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: 15 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair (Ed.) 3 P. Morand (Ed.) 4 Internet Draft France Telecom R&D 5 Document: draft-boucadair-pce-comm-proto-00.txt May 2005 6 Category: Standards Track 8 Inter PCE Communication protocol 9 draft-boucadair-pce-comm-proto-00.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 Internet- 23 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 draft describes a new protocol allowing communication between 41 two Path Computation Elements (PCEs) located in different domains in 42 order to compute inter-domain paths satisfying a set of QoS 43 constraints. This protocol could also be used for intra-domain 44 purposes. 46 Table of Contents 47 1. Contributors................................................2 48 2. Changes since last version:.................................2 49 3. Terminology.................................................3 50 4. Introduction................................................3 51 5. Conventions used in this document...........................4 52 6. Overview of overall service approach........................4 53 7. PCE to PCE communication....................................5 54 8. PCP messages................................................6 55 8.1. Common header...............................................6 56 8.2. OPEN message................................................7 57 8.3. ACCEPT message..............................................7 58 8.4. CLOSE message...............................................8 59 8.5. REQUEST message.............................................8 60 8.6. RESPONSE-PATH message......................................11 61 8.7. PATH-ERROR message.........................................12 62 8.8. CANCEL message.............................................13 63 8.9. ACKNOWLEDGE message........................................14 64 8.10. KEEPALIVE message (KA)......................................14 65 9. Exchange of PCP messages...................................14 66 9.1. Communication..............................................14 67 9.2. OPEN (OPN).................................................15 68 9.3. ACCEPT (ACP)...............................................15 69 9.4. CLOSE (CLO)................................................15 70 9.5. REQUEST (REQ)..............................................15 71 9.6. RESPONSE (RSP).............................................18 72 9.7. ACKNOWLEDGE (ACK)..........................................19 73 9.8. CANCEL (CCL)...............................................19 74 10. Security Considerations....................................20 75 11. References.................................................20 76 12. Acknowledgments............................................21 77 13. Author's Addresses.........................................21 79 1. Contributors 81 o Hamid Asgari (Thales Research and Technology) 82 o Panagiotis Georgatsos (Algonet) 83 o David Griffin (University College London) 84 o Micheal Howarth (University of Surrey) 85 o Thibaut Coadic (France Telecom) 87 2. Changes since last version: 89 The main changes occurred in this version are: 90 o Add new contributor; 91 o Rewording of several sections of the draft; 92 o Correction of some typos. 94 3. Terminology 96 This memo makes use of the following terms: 98 o Path Computation Element (PCE): an entity that is responsible 99 for computing/finding inter/intra domain paths for establishing 100 LSPs. This entity can simultaneously act as client and a server. 101 Several PCEs could be deployed in a given AS. 103 o Path Computation Client (PCC): a PCE acting as a client. This 104 entity is responsible for issuing path computation requests that 105 fulfill the Service Management constraints for the establishment 106 of inter/intra domain LSPs. 108 o Path Computation Server (PCS): a PCE acting as a server. This 109 entity is responsible for handling path computation requests in 110 order to satisfy PCC constraints. 112 o High-level service: is the service using a PCE-based system as 113 an underlying infrastructure (an inter-domain QoS VPNs service 114 for instance) 116 o High-level service customer: is a customer that subscribes to a 117 High-level service. 119 o pSLS: A provider SLS is an SLS established between two Internet 120 Network Providers (INP) with the purpose of extending the 121 geographical span of their service offers. 123 o SLS Management: This management entity is responsible for SLS- 124 related activities, including pSLS ordering (i.e establishing 125 contracts between peers) and SLS invocation (i.e committing 126 resources before traffic can be admitted) 128 o q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into 129 account QoS information as input to for its route selection 130 process. 132 o Domain: within this draft it denotes an Autonomous system. 134 4. Introduction 136 Nowadays, services are deployed on the same infrastructure (best- 137 effort shared IP network) on which more elaborate functionalities 138 rely for providing enhanced network services. Especially those 139 intended for specific corporate customers or providers needs. These 140 extra functionalities were introduced because the basic IP approach 141 failed to support those added-value services or was not considered to 142 be efficient enough. 144 MPLS is a technical solution that has been successfully deployed by a 145 large number of providers for supporting connection-oriented services 146 such as IP VPN services for which traffic isolation is an important 147 criterion. Then, the solution evolved to encompass QoS issues, and 148 Traffic engineering functions were then progressively introduced. Up 149 to now, some providers have deployed MPLS TE but only within their 150 own domains. 152 Extending the scope of offered intra-domain services (like QoS-based 153 services), using MPLS as infrastructure, to the Internet scale is 154 conditioned by the cooperation between service providers. Several 155 proposals have been proposed within the IETF in order to deal with 156 this issue but only from inter-AS point of view (see for example 157 [INTERAREA-REQ], [INTERAS-REQ], [PCE-ARCH] and [PCE-FWK]). 159 Inter-provider issues need to be studied further in order to build a 160 complete end-to-end solution. 162 Draft [INTERAS-PCE] describes a solution that could be implemented in 163 order to offer end-to-end services. This solution requires a close 164 cooperation between distinct Path Computation Elements (PCE) that are 165 located in distinct domains. 167 This draft describes a protocol to use for communication between two 168 Path computation Elements. 170 The structure of this draft is as follows: 171 o Section 5 presents an overview of the overall service approach; 172 o Section 6 lists characteristics of the PCP protocol; 173 o Sections 7 and 8 detail the PCP messages and operations. 175 5. Conventions used in this document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC-2119 [RFC2119]. 181 6. Overview of overall service approach 183 Neighboring domains establish pSLSs between themselves. An inter- 184 domain routing protocol runs between the domains. This inter-domain 185 routing protocol is used to announce PCE unique identifiers [PCE- 186 DISCOVERY] across the Internet in order for other PCEs to be able to 187 discover possible paths towards every AS having a PCE. Therefore, 188 when an AS wants to establish an LSP between 2 addresses, its PCE 189 forms a path computation request containing the HEAD-END-ADDRESS and 190 the TAIL-END-ADDRESS defining the future LSP. In addition to the IP 191 address of the head and the tail of the LSP, each X-END-ADRESS 192 contains also the PCE unique identifier of the AS these IP addresses 193 belong to. Using information reported by BGP the PCE identifies 194 possible paths that reach the target AS identified by its PCE unique 195 identifier. It then selects one of these paths and forms a new 196 request, which is sent to the neighboring PCE it selected along that 197 path. 199 The path computation request is propagated downstream to the 200 appropriate PCEs and is repeated until the request reaches the 201 destination PCE. Each PCE along the path ensures that the constraints 202 expressed by the request are satisfied. Each PCE is responsible for 203 computing both the intra- and inter-domain sub-path and to ensure 204 that resources are available and will remain available until the LSP 205 is effectively created. If for some reasons the path computation 206 aborts, all resources must be relaxed. 208 After authenticating the identity of LSP requester (originating) PCE, 209 the destination PCE sends a reply message back to the upstream 210 domain's PCE accepting the request. The LSP sub-path (from the 211 ingress ASBR and the final destination) is inserted in the message. 212 The next upstream domain's PCE does the same adding its own relevant 213 sub-path to the overall loose or strict path. At the end of the 214 chain, the originating PCE does also the same. An end-to-end path has 215 thus been computed. The originating PCE is now in a position to 216 provide the service request handler with appropriate information 217 (end-to-end inter-domain path) allowing an RSVP reservation to be 218 issued for the establishment of the LSP. 220 At the service/application level, when an originating AS wants to 221 establish an LSP towards a destination ASs, there MUST exist a 222 preliminary agreement between the two ASs (Service providers owning 223 these PCEs). This agreement specifies both the tail-end and head-end 224 address of the LSP, together with the PCE unique identifier of the 225 originating and destination AS. This allows only agreed LSP to be 226 established. 228 7. PCE to PCE communication 230 A PCE can act as a client (PCC) or a server (PCS). A PCC is 231 responsible for issuing requests. PCS is responsible for handling 232 requests received from PCCs. 234 +------------+ +------------+ 235 | PCE | | PCE | 236 | | | | 237 | +------+ | | +------+ | 238 | | PCC | | | | PCC | | 239 | | |<-|-------\ | | | | 240 | +--/\--+ | | | +--/\--+ | 241 | || | |PCP | || | 242 | || | | | || | 243 | +--\/--+ | | | +--\/--+ | 244 | | PCS | | \---------------|->| PCS | | 245 | | | | | | | | 246 | +------+ | | +------+ | 247 +------------+ +------------+ 249 PCP protocol is used for communication between a PCC and a PCS. 251 PCP is a simple query and response protocol that can be used between 252 PCE entities to collaborate for computing an inter-domain QoS 253 constrained path. 255 The main characteristics of the PCP protocol include: 257 o The protocol employs a client/server model in which a PCE can 258 both act as a client and/or a server at the same time. A PCE 259 Client (PCC) sends requests, cancellation and receives 260 responses. 262 o The protocol uses TCP as its transport protocol for reliable 263 exchange of messages between PCE. Therefore, no additional 264 mechanisms are necessary for reliable communication between two 265 PCEs. 267 o In its first version, PCP does not provide any message level 268 security for authentication, message replay protection, and 269 integrity. However, PCP can reuse existing protocols for 270 security such as IPSEC [RFC2401] or TLS [RFC2246] to 271 authenticate and secure the channel between two PCEs. 273 o The current PCP protocol provides the service for supporting 274 only a basic path computation function. In particular it does 275 not support additional path computation constraints, or provide 276 enhanced reporting features in the case of path computation 277 failure. 279 8. PCP messages 281 This section discusses the PCP message formats and objects exchanged 282 between PCE entities. 284 8.1. Common header 286 Each PCP message consists of the PCP header followed by a number of 287 arguments depending on the nature of the operation. 289 0 1 2 3 290 +--------------+--------------+--------------+--------------+ 291 | Version | Op Code | Message Length | 292 +--------------+--------------+--------------+--------------+ 294 Global note: //// implies field is reserved, set to 0. 296 The fields in the header are: 298 Version: 8 bits. PCP version. Current version is 1. 300 Op Code: 8 bits. The current defined PCP operations are: 302 1 = OPEN (OPN) 303 2 = ACCEPT (ACP) 304 3 = CLOSE (CLO) 305 4 = REQUEST (REQ) 306 5 = RESPONSE (RSP) 307 6 = PATH-ERROR (ERR) 308 7 = CANCEL (CCL) 309 8 = ACKNOWLEDGE (ACK) 310 9 = KEEP-ALIVE (KA) 312 Message Length: 16 bits 314 This is the size of the message in octets, which includes the 315 standard PCP header and all encapsulated objects. Messages MUST be 316 aligned on 4 octet intervals. 318 8.2. OPEN message 320 0 1 2 3 321 +-------------+-------------+-------------+-------------+ 322 | | 323 | PCSID | 324 | | 325 | | 326 +-------------+-------------+-------------+-------------+ 328 The message contains only one argument. This PCSID is propagated by 329 BGP between the domains. This is a routable IPv4 or IPv6 address 330 identifying a PCS of a domain. This PCSID must be inserted by the PCE 331 opening a PCP session. The size of the PCSID is 4 or 16 bytes. 333 8.3. ACCEPT message 335 0 1 2 3 336 +-------------+-------------+-------------+-------------+ 337 | KA-Timer |///////////////////////////| 338 +-------------+-------------+-------------+-------------+ 340 o KA-Timer (Keep-Alive Timer): The argument of the accept message 341 is a 2 octets integer value which represents a timer value 342 expressed in units of seconds. This timer value is treated as a 343 delta. KA-Timer is used to specify the maximum time interval 344 over which a PCP message MUST be sent by the two communication 345 entities. The range of finite timeouts is 1 to 65535 seconds 346 represented as an unsigned two-octet integer. The value of zero 347 implies infinity. 349 8.4. CLOSE message 351 The close message contains an error code indicating the reason of the 352 close of the session. 354 0 1 2 3 355 +--------------+--------------+--------------+--------------+ 356 | Error-Code | ////////////////////////////| 357 +--------------+--------------+--------------+--------------+ 359 Error-Code: 360 1 = Shutting Down 361 2 = Bad Message Format 362 3 = Incorrect identifier 363 4 = Unable to process 364 5 = Protocol error 366 8.5. REQUEST message 368 The Request message is sent by the PCC for computing and inter-domain 369 path. 371 +-------------+ 372 1 byte | TTL | 373 +-------------+ 374 1 byte | L0 | 375 +-------------+-------------+-------------+-------------+ 376 2 bytes| AS-NUMBER | 377 +-------------+-------------+-------------+-------------+ 378 // // 379 +-------------+-------------+-------------+-------------+ 380 2 bytes| AS-NUMBER | 381 +-------------+-------------+-------------+-------------+ 382 2 bytes| L1 | 383 +-------------+-------------+-------//----+-------------+ 384 | PATH-COMPUTATION-ID | 385 |-----------------------------------//------------------| 386 2 bytes| L2 | 387 +-------------+-------------+-------//----+-------------+ 388 | PATH-REFERENCE-ID | 389 +-------------+-------------+-------//----+-------------+ 390 2 bytes| REQ-REFERENCE-ID | 391 +-------------+-------------+-------------+-------------+ 392 1 byte | ADD-TYPE | 393 +-------------+-------------+-------//----+-------------+ 394 | HEAD-END-ADDRESS | 395 +-------------+-------------+-------//----+-------------+ 396 | TAIL-END-ADDRESS | 397 +-------------+-------------+-------//----+-------------+ 398 1 byte | NUMBER-OF-QC-CONSTRAINT + 399 +-------------+-------------+ 400 2 bytes| QC-CONSTRAINT-LENGTH + 401 +-------------+-------------+ 402 1 byte | QOS-CLASS-IDENTIFIER + 403 +-------------+-------------+---------------------------+ 404 1 byte | QOS-INFO-CODE + QOS-INFO-SUB-CODE | 405 +-------------+-------------+-------------+-------------+ 406 2 bytes| QOS-INFO-VALUE | 407 +-------------+-------------+-------------+-------------+ 408 | QOS-INFO-CODE + QOS-INFO-SUB-CODE | 409 +-------------+-------------+-------------+-------------+ 410 | QOS-INFO-VALUE | 411 +-------------+-------------+-------------+-------------+ 412 | QOS-INFO-CODE + QOS-INFO-SUB-CODE | 413 +-------------+-------------+-------------+-------------+ 414 | QOS-INFO-VALUE | 415 +-------------+-------------+-------------+-------------+ 417 o TTL: is the maximum number of ASs that can be crossed by the 418 path. This field is decremented by one each time a PCS issues a 419 request. 421 o L0: is a 1-byte length field. It represents the number of ASs 422 that have already been crossed. 424 o AS-NUMBER: is a 2 bytes length field representing an AS number. 425 The first AS-NUMBER value of the list is the AS-NUMBER of the 426 PCC that initialized a path computation. 428 o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of 429 this field is 2 bytes. 431 o PATH-COMPUTATION-ID: is a globally unique value that identifies 432 a path computation occurrence. It is a variable-length field. It 433 is suggested, at least in this first specification, that this 434 identifier is computed using the PCSID of the domain, 435 concatenated with the date and an identifier that will be 436 computed by the first requesting PCC each time a request will 437 have to be issued. Across PCC reboots, this identifier must be 438 unique. This PATH-COMPUTATION-ID will be replicated in all 439 subsequent request initiated by the PCEs along the path. 441 o L2: is the length in bytes of the PATH-REFERENCE-ID. Size of 442 this field is 2 bytes. 444 o PATH-REFERENCE-ID: is a variable-length field. It is an 445 identifier that represents a pre-agreement between the head and 446 the tail-end domain that allows the PCS from the terminating 447 domain to accept or reject the path computation request. 449 o REQ-REFERENCE-ID: is a 2 bytes length field representing an 450 unsigned integer. This field is used to identify the REQUEST. It 451 allows making the difference between several REQ issued for 452 different path computation (but same PATH-COMPUTATION-ID) 453 between two neighbor ASs interconnected via multiple links. 455 o ADD-TYPE: indicates the nature of the IP addresses of the tail- 456 end and head-end termination: 457 o 1 = IPv4 458 o 2 = IPv6 460 o HEAD-END-ADDRESS: is the head-end address of the future LSP 461 represented in the form HEAD-END@PCSID. This is a couple of 462 IPv4 or IPv6 address. The first address of the couple 463 identifies a loopback or an interface address of a network 464 element, the second element is the PCSID of the domain owning 465 the previous address. 467 o TAIL-END-ADDRESS: is the tail-end address of the LSP 468 represented in the form TAIL-END@PCSID. This is a couple of 469 IPv4 or IPv6 address. The first address of the couple 470 identifies a loopback or an interface address of a network 471 element, the second element is the PCSID of the domain owning 472 the previous address. 474 These above parameters MUST be present in each REQUEST and in the 475 same order. 477 o NUMBER-OF-QC-CONSTRAINT: represents the number of QoS class 478 constraints the PCS must take into account when computing a 479 path. A QoS class constraint contains a QoS-Class-Identifier 480 (like a DSCP value) followed by additional constraints. The size 481 of this filed is 1 byte. This field in not really necessary in 482 this first version of the specification but it could become 483 useful if additional path constraints were included in the 484 request. 486 o QC-CONSTRAINT-LENGTH: is the length in bytes of the QoS-Class- 487 Constraint that follows. The size of this field is 2 bytes. 489 o QOS-CLASS-IDENTIFIER: identifies a particular QoS-class. The 490 size of the field is 1 byte. 492 o QOS-INFO-CODE: this field identifies the type of QoS 493 information. The size of this field is 4 bits. This code could 494 be: 495 o (0) Reserved 496 o (1) Packet rate 497 o (2) One-way delay metric 498 o (3) Inter-packet delay variation 500 o QOS-INFO-SUB-CODE: this field carries the sub-type of the QoS 501 information. The following sub-types have been identified. The 502 size of this field is 4 bits. 503 o (0) None 504 o (1) Reserved rate 505 o (2) Available rate 506 o (3) Loss rate 507 o (4) Minimum one-way delay 508 o (5) Maximum one-way delay 509 o (6) Average one-way delay 511 o QOS-INFO-VALUE: this field indicates the value of the QoS 512 information. These are the constraints that the PCE should 513 respect. The corresponding units depend on the instantiation of 514 the QoS information code. 516 8.6. RESPONSE-PATH message 518 This message is sent back when a path has been successfully computed. 520 +-------------+-------------+ 521 2 bytes| L1 | 522 +-------------+-------------+-------//----+-------------+ 523 | PATH-COMPUTATION-ID | 524 |-----------------------------------//------------------| 525 2 bytes| REQ-REFERENCE-ID | 526 |-----------------------------------//------------------| 527 1 bytes| PATH-LENGTH | 528 +-------------+ 529 1 byte | ADD-TYPE | 530 +-------------+-------------+-------//----+-------------+ 531 | NEXT-HOP | 532 +-------------+-------------+-------//----+-------------+ 533 // // 534 +-------------+-------------+-------//----+-------------+ 535 | NEXT-HOP | 536 +-------------+-------------+-------//----+-------------+ 537 8 bytes| VALIDITY-DATE + 538 +-------------+-------------+ 539 1 byte | NUMBER-OF-QC-CONSTRAINT + 540 +-------------+-------------+ 541 2 bytes| QC-CONSTRAINT-LENGTH + 542 +-------------+-------------+ 543 1 byte | QOS-CLASS-IDENTIFIER + 544 +-------------+-------------+---------------------------+ 545 1 byte | QOS-INFO-CODE + QOS-INFO-SUB-CODE | 546 +-------------+-------------+-------------+-------------+ 547 2 bytes| QOS-INFO-VALUE | 548 +-------------+-------------+-------------+-------------+ 549 | QOS-INFO-CODE + QOS-INFO-SUB-CODE | 550 +-------------+-------------+-------------+-------------+ 551 | QOS-INFO-VALUE | 552 +-------------+-------------+-------------+-------------+ 553 | QOS-INFO-CODE + QOS-INFO-SUB-CODE | 554 +-------------+-------------+-------------+-------------+ 555 | QOS-INFO-VALUE | 556 +-------------+-------------+-------------+-------------+ 558 o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of 559 this field is 2 bytes. 561 o PATH-COMPUTATION-ID: is a globally unique value that identifies 562 a path computation occurrence. It is a variable-length field. 563 This value of this identifier MUST be the same as the one 564 provided by the REQUEST. 566 o REQ-REFERENCE-ID: is a 2 bytes length field representing an 567 unsigned integer. This field is used to reference the initial 568 REQUEST. 570 o PATH-LENGTH: indicates the number of next hops that form the 571 path. The size of this filed is 1 byte. 573 o ADD-TYPE: indicates the nature of the IP addresses in the PATH. 574 The size of this filed is 1 byte. 575 o 1 = IPv4 576 o 2 = IPv6 578 o NEXT-HOP: IP address of a next hop that is part of the computed 579 path. Size of this field depends on the nature of the IP 580 address. 582 o VALIDITY-DATE: represents the GMT date after which the computed 583 path returned will not be valid. The size of this field is 8 584 bytes. 586 These above parameters MUST be present in each RESPONSE and in the 587 same order. 589 The other parameters have the same meaning than for the REQUEST 590 except: 592 o QOS-INFO-VALUE: represents the QoS guarantees of the path, for 593 this particular QoS-INFO-CODE parameter (delay, jitter,à) 594 between the ingress ASBR of the responding PCE domain and the 595 tail-end of the path. 597 8.7. PATH-ERROR message 598 This message is sent back when a path could not be computed. 600 +-------------+-------------+ 601 2 bytes| L1 | 602 +-------------+-------------+-------//----+-------------+ 603 | PATH-COMPUTATION-ID | 604 |-----------------------------------//------------------| 605 2 bytes| REQ-REFERENCE-ID | 606 |-----------------------------------//------------------| 607 1 bytes| REASON-CODE | 608 +-------------+-------------+ 610 o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of 611 this field is 2 bytes. 613 o PATH-COMPUTATION-ID: is a globally unique value that identifies 614 a path computation occurrence. It is a variable-length field. 615 This identifier MUST be the same as the one provided by the 616 REQUEST. 618 o REQ-REFERENCE-ID: is a 2 bytes length field representing an 619 unsigned integer. This field is used to reference the initial 620 REQUEST. 622 o REASON-CODE: indicate the reason of the failure. Identified 623 failure are: 625 1 = No resource available 626 2 = Path reference error 627 3 = Abnormal termination 628 4 = PATH-COMPUTATION-ID already used 629 5 = TTL expired 630 6 = Loop detected 631 7 = Request already handled 633 8.8. CANCEL message 635 This message is sent by a PCC or a PCS when a path computation must 636 be cancelled. 638 +-------------+-------------+ 639 2 bytes| L1 | 640 +-------------+-------------+-------//----+-------------+ 641 | PATH-COMPUTATION-ID | 642 |-----------------------------------//------------------| 643 2 bytes| REQ-REFERENCE-ID | 644 |-------------------------------------------------------| 646 o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of 647 this field is 2 bytes. 649 o PATH-COMPUTATION-ID: is a globally unique value that identifies 650 a path computation occurrence. It is a variable-length field. 651 This identifier MUST be the same as the one provided by the 652 REQUEST. 654 o REQ-REFERENCE-ID: is a 2 bytes length field representing an 655 unsigned integer. This field is used to reference the initial 656 REQUEST. 658 8.9. ACKNOWLEDGE message 660 This message is sent by a PCC to a PCS to confirm the reservation of 661 the path. This feature is particularly used when a PCC launches 662 multiple REQUEST messages during its path computation phase. 664 +-------------+-------------+ 665 2 bytes| L1 | 666 +-------------+-------------+-------//----+-------------+ 667 | PATH-COMPUTATION-ID | 668 |-----------------------------------//------------------| 669 2 bytes| REQ-REFERENCE-ID | 670 |-------------------------------------------------------| 672 o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of 673 this field is 2 bytes. 675 o PATH-COMPUTATION-ID: is globally unique value that identifies a 676 path computation occurrence. It is a variable-length field. This 677 identifier MUST be the same as the one provided by the REQUEST. 679 o REQ-REFERENCE-ID: is a 2 bytes length field representing an 680 unsigned integer. This field is used to reference the initial 681 REQUEST. 683 8.10. KEEPALIVE message (KA) 685 Message exchanged between two PCEs to maintain TCP session when no 686 other messages are exchanged. 688 This message has no argument. 690 9. Exchange of PCP messages 692 9.1. Communication 694 The PCP protocol uses a single persistent TCP connection between a 695 PCC and a remote PCS. One PCE server implementation per server MUST 696 listen on a well-known TCP port number (to be defined). The PCC is 697 responsible for initiating the TCP connection to the PCS. The 698 location of the remote PCS is deduced and retrieved from the 699 management plane blocks during the path computation process or at PCS 700 boot via the SLS management block. PCE can have crossed 701 communication; some are acting as a client role, others as a server 702 role. 704 9.2. OPEN (OPN) 706 An OPN message MUST be sent before any other message exchange. As 707 part of the open message, the PCC provide its PCSID, which allows the 708 server to identify the client. It can also use this information to 709 retrieve the client context near its management plane. Only one OPN 710 message can be issued at a time. 712 If the PCS receives malformed message it MUST close the session using 713 the appropriate error code. 715 9.3. ACCEPT (ACP) 717 The ACP message is used to positively respond to the OPN message from 718 the PCC. This message will return to the PCC a KA-timer value object 719 indicating the maximum acceptable intermediate time between the 720 generation of messages by the PCEs. The KA-timer value is determined 721 by the PCS and is specified in seconds. 723 If the PCS refuses the PCC open message, it will instead issue a 724 CLOSE message. 726 9.4. CLOSE (CLO) 728 The CLOSE message can be issued by either the PCC or the PCS to 729 notify the other that it is no longer available. 731 The Error code is included to describe the reason for the close. 733 When issuing a CLOSE both the PCC and the PCS MUST delete all the 734 internal states related to this PCP session. Additionally, all 735 pending requests MUST be cancelled in order to free as much as 736 possible all pending resources reservations that could have been 737 established. PATH-ERROR or CANCEL message must be sent depending on 738 requests' state. 740 9.5. REQUEST (REQ) 742 A request is issued by a PCC when it has found a potential path 743 toward the target final destination. This request can be issued as a 744 consequence of a request received from another domain it has 745 agreement with or from its own service management plane. 747 When the service request comes from a remote PCC, the server achieves 748 the following tasks: 750 (0) If the receiving TTL is zero the PCS MUST discard the request. 751 The receiving PCS, decrements by one the received TTL value. If 752 the TTL is equal to zero, the request is rejected if the PCS is 753 not the last PCS in the chain. In addition the PCS examines the 754 AS-PATH included in the received REQ and reject it if it finds 755 its own AS number in the list. This mechanism allows avoiding 756 possible loops when a limited set of QoS constraints are 757 provided in the request. 759 (1) It checks if the PATH-COMPUTATION-ID of the received REQ is 760 already associated to a pre-contract or contract for the same 761 requester. If this is the case, it returns a PATH-ERROR message 762 with a reason-code = 4. It checks if the PATH-COMPUTATION-ID and 763 the REQ-REFERENCE-ID of the received REQ are already associated 764 to a pre-reservation record concerning the same requester. If a 765 pre-reservation is found, it returns a PATH-ERROR message with a 766 reason-code = 4. 768 (2) It considers the HEAD-END-ADDRESS and the TAIL-END-ADDRESS 769 parameters present in the request. The HEAD-END-ADDRESS MUST 770 indicate a valid entry point in its domain. If not, the PCS 771 returns a PATH-ERROR with an appropriate reason value. 773 (3) Then it extracts the PCSID from the TAIL-END-ADDRESS and parses 774 the QoS constraints provided at part of the request message. It 775 has thus identified all QoS-class required together with their 776 associated QoS constraints. 778 (4) The PCS achieves some policing and verifies that the request 779 constraints will not exceed the resources negotiated in the 780 pSLS. If resources are exceeded, the PCS returns a PATH-ERROR 781 message. If resources are available, the PCS pre-reserves the 782 corresponding resources near the management plane. 784 (5) If the PCS recognizes its own PCSID in the TAIL-END-ADDRESS, it 785 considers the PATH-REFERENCE-ID otherwise it jumps to step (6). 786 If this identifier is known from its management plane, the 787 request is accepted and processing continues on (51). Otherwise 788 the PCS returns a PATH-ERROR message with a reason-code = 2. 790 (51) The PCS computes an intra-domain path and verifies the 791 availability of the resources along this internal path. If 792 available, the PCS interacts with its management plane and 793 creates a context, which triggers the administrative reservation 794 of the resources. When interacting with the management blocks, 795 the PCS MUST provide all information necessary to identify the 796 sub-path it selected. In particular it MUST provide the PATH- 797 COMPUTATION-ID, the REQ-REFERENCE-ID, the ingress point ASBR 798 address used in its domain and the termination point in its 799 domain. The PCS sends a RESPONSE-PATH message back to the 800 requesting PCC. If resources are not available a PATH-ERROR 801 message is generated. 803 (6) It then queries the dynamic inter-domain traffic-engineering 804 block with the retrieved PCSID and the list of requested QoS- 805 classes. The dynamic inter-domain TE block returns the available 806 BGP announcements. The PCS then verifies whether it can find a 807 next-hop ASBR, which announces the PCSID within the requested 808 QoS-class. If cannot find it the procedure stops and a PATH- 809 ERROR message is returned back to the requesting entity with an 810 appropriate reason-code value. 812 (7) If one or several next-hops are found, the PCS examines the QoS 813 performance guarantees of the announcements and compare the 814 values with those requested in the request. If it doesn't 815 understand one of the requested QoS constraints, PATH-ERROR 816 message is sent back. Otherwise, QoS constraints are 817 successively compared to those received from q-BGP. All next- 818 hops propagating the set of announcements satisfying the 819 required QoS constraints are kept. The others are left on side. 821 (8) For each possible next hop ASBR the PCS checks if there are 822 enough available resources available at the domain boundaries. 823 In particular if some bandwidth guarantees are required the PCS 824 checks if the administrative maximum bandwidth agreed during the 825 pSLS negotiation phase will not be exceeded. If resources are 826 not available the ASBR is left on side and the next ASBR in the 827 list is considered. If resources are available, the PCS pre- 828 reserves the corresponding resources near the management plane. 829 At this stage, the management plane doesn't create any contract 830 since we are not sure that an end-to-end path exists. This pre- 831 reservation can be taken into account by the PCS for subsequent 832 requests. It can use it as a lock and delay the incoming 833 requests or introduce the pre-reservations in its resource 834 availability computation according to the local policy enforced. 835 When interacting with the management blocks, the PCS must 836 provide all information necessary to identify the sub-path it 837 selected. In particular it must provide the PATH-COMPUTATION-ID, 838 the REQ-REFERENCE-ID, the ingress point address of its domain 839 and the ingress point address of the next domain. This latter 840 information can be used by the management plane to identify the 841 upstream and downstream involved domains. 843 o (81) The PCS computes an intra-domain path and verifies the 844 availability of the resources along this internal path. If 845 resources are available, the sub-path is valid and the PCE 846 forms a new REQUEST message which is sent to the PCS of the 847 remote domain owning the next-hop ASBR. It adds its own AS 848 number to the existing list. If internal resources are not 849 available, the PCS discard the pre-reservation and considers 850 the next next hop ASBR in the list. When building the request 851 the PCC keeps the PATH-COMPUTATION-ID, the PATH-REFERENCE-ID, 852 the TAIL-END-ADDRESS unchanged. The initial HEAD-END-ADDRESS 853 is replaced by the address of the ingress next-hop ASBR 854 identified during the path computation. The QoS constraints 855 characteristics are modified in order to take into account 856 the QoS performance guarantees provided by the domain. 858 (9) If QoS constraints cannot be satisfied for any of the ASBR, the 859 PCS returns a PATH-ERROR message. 861 Note that it is quite possible that several next hops ASBR can 862 satisfy the requested constraints. In such a case the PCS can process 863 one next-hop ASBR at a time or several in parallel. For one incoming 864 request, there can be multiple simultaneous outgoing requests towards 865 different PCS. If several requests are sent toward the same neighbor, 866 for a same PATH-COMPUTATION-ID, the REQ-REFERENCE-ID must be 867 different. Nevertheless, this feature can lead to scalability issues 868 and needs further investigations. 870 9.6. RESPONSE (RSP) 872 A RESPONSE message is sent by a PCS in response to a request issued 873 by a PCC. RSP messages are sent back when a valid end-to-end path has 874 been computed. The RSP message MUST be initiated by the tail-end 875 domain. 877 When a valid end-to-end path has been computed, the PCS of the last 878 domain on the path, forms a RSP message. It first inserts the 879 original PATH-COMPUTATION-ID. Then its forms a path argument that 880 MUST contains the IP address of the tail-end LSP and the IP address 881 interface of the ingress ASBR supporting that path. It MAY insert 882 between these two extremities, the IP address of additional hops. It 883 MAY also indicates the date after which the path will not be valid 884 anymore because administratively reserved resources will have been 885 relaxed. Then, it MUST indicate QoS guarantees it provides between 886 the ingress ASBR and the tail-end address of the LSP. The RSP message 887 is then sent to the requesting PCC. 889 On receipt, the PCC adds its own intra-domain sub-path to the list. 890 It does not indicate the next-hop ASBR since this latter has already 891 been inserted by the downstream PCS. This sub-path can be a strict or 892 loose description. It also modifies the QoS guarantee parameters so 893 that they reflect the QoS guarantees it can provide for its part of 894 the path. This is achieved in the same way as for the request, but it 895 is an "addition" operation if we consider the delay, for example. The 896 VALIDITY-DATE MUST modified so that the value indicates now the 897 smaller date between the date received in the RSP message and the 898 date reported by the management plane. 900 If the PCC sent multiple REQUEST messages in parallel, it MAY wait 901 for a RSP or ERR message for all the requests it sent. If the PCC got 902 multiple RSP messages it MUST select only one and inform the un- 903 selected PCS that they can cancel their reservation. It forms CANCEL 904 messages, sends them to the appropriate PCS and cancels its own pre- 905 reservation for the corresponding requests. If the PCC doesn't whish 906 to wait for a reply, it can send a CANCEL message at any time. 908 The PCS can send the consolidated RES message to the requesting PCC 909 after sending ACK message to the PCS it decided to keep in the path. 911 9.7. ACKNOWLEDGE (ACK) 913 The ACK message is used by PCS to confirm to its management plane 914 that the resources needed for the path referenced by PATH- 915 COMPUTATION-ID and REQ-REFERENCE-ID present in the message need to be 916 reserved. It allows the management plane to create a contract based 917 on information previously stores by the PCS during the computation 918 phase. If no ACK is received, no contract is created and the 919 negotiation at the management level will fail. If for some reasons, 920 no ACK were received, the VALIDITY-DATE would be used and the 921 administrative pre-reservation automatically removed for that path. 922 ACK messages are only accepted if they arrive after the server has 923 issued a RSP otherwise they are ignored. 925 9.8. CANCEL (CCL) 927 A CANCEL message can be sent by PCC and PCS. CCL messages can be 928 generated during the normal path computation cycle but also in case 929 of an abnormal termination of a PCE to PCE communication. 931 If a PCE, acting as a server for the PCP session, received a CCL 932 message from the PCC, it MUST form new CCL messages and forward a CCL 933 message to each PCS to which it sent a REQ for which it did not 934 received any positive or negative reply. Once this has been achieved 935 it MUST delete all its internal states referencing the request 936 identified by the PATH-COMPUTATION-ID and REQ-REFERENCE-ID indicated 937 in the message. If the PCE has no pending request concerning this 938 PATH-COMPUTATION-ID and REQ-REFERENCE-ID, it can optionally query its 939 management plane to retrieve a possible existing contract referenced 940 by this PATH-COMPUTATION-ID and delete it. Just before deleting this 941 contract, it can form a new CCL message and forward it to the next 942 PCS in the path. If it does not, the VALIDITY-DATE will be applied. 944 The same procedure applies if the PCE server detects a communication 945 problem with one of its PCC. In that case, the PCS issues CCL 946 messages for all pending request received from this PCC. 948 When a PCE, acting as a client for the PCP session, received a CCL 949 message from a PCE server, this indicates that a PCS along the path 950 towards the target destination has experienced communication problems 951 leading to close a PCP communication. In such a case, each PCC 952 cancels all the internal states referencing this PATH-COMPUTATION-ID 953 and forward this indication to the upstream client PCS up to the 954 initial requestor. 956 10. Security Considerations 958 PCP is a communication protocol that is used between two PCEs. No 959 security mechanisms are defined in this PCP specification. It is 960 recommended that a security protocol like IPSec or TLS MUST be 961 activated in order to protect PCP sessions. 963 11. References 965 [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, 966 February 2004 968 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 969 Technology", RFC 3668, February 2004 971 [INTERAREA-REQ] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements 972 for Inter-Area MPLS Traffic Engineering ", 973 draft-ietf-tewg-interarea-mpls-te-req-03.txt, November 2004 975 [INTERAS-REQ] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS 976 Traffic Engineering requirements ", draft-ietf-tewg-interas-mpls- 977 te-req-09.txt, September 2004 979 [PCE-ARCH] Ash, J., Farrel, A., Vasseur, JP., "Path Computation 980 Element (PCE) Architecture", draft-ietf-pce-architecture-00.txt, 981 March 2005 983 [PCE-FWK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for 984 Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- 985 domain-framework-01.txt, February 2005 987 [INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing 988 inter-AS QoS tunnels", draft-boucadair-pce-interas-01.txt, May 989 2005 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, March 1997 994 [PCE-DISCOVERY] Boucadair, M., Morand, P., "PCE Discovery via Border 995 Gateway Protocol", draft-boucadair-pce-discovery-01.txt, May 2005 997 [RFC2401] Atkinson R., "Security Architecture for the Internet 998 Protocol", RFC 2401, August 1998. 1000 [RFC2246] Dierks T., Allen C., "The TLS Protocol", RFC 2246, January 1001 1999 1003 12. Acknowledgments 1005 The authors would also like to thank all the partners of the MESCAL 1006 (Management of End-to-End Quality of Service Across the Internet At 1007 Large, http://www.mescal.org) project for the fruitful discussions. 1009 13. Author's Addresses 1011 Mohamed Boucadair 1012 France Telecom R & D 1013 42, rue des Coutures 1014 BP 6243 1015 14066 Caen Cedex 4 1016 France 1017 Phone: +33 2 31 75 92 31 1018 Email: mohamed.boucadair@francetelecom.com 1020 Pierrick Morand 1021 France Telecom R & D 1022 42, rue des Coutures 1023 BP 6243 1024 14066 Caen Cedex 4 1025 France 1026 Email: pierick.morand@francetelecom.com 1028 Intellectual Property Statement 1030 The IETF takes no position regarding the validity or scope of any 1031 Intellectual Property Rights or other rights that might be claimed to 1032 pertain to the implementation or use of the technology described in 1033 this document or the extent to which any license under such rights 1034 might or might not be available; nor does it represent that it has 1035 made any independent effort to identify any such rights. Information 1036 on the procedures with respect to rights in RFC documents can be 1037 found in BCP 78 and BCP 79. 1039 Copies of IPR disclosures made to the IETF Secretariat and any 1040 assurances of licenses to be made available, or the result of an 1041 attempt made to obtain a general license or permission for the use of 1042 such proprietary rights by implementers or users of this 1043 specification can be obtained from the IETF on-line IPR repository at 1044 http://www.ietf.org/ipr. 1046 The IETF invites any interested party to bring to its attention any 1047 copyrights, patents or patent applications, or other proprietary 1048 rights that may cover technology that may be required to implement 1049 this standard. Please address the information to the IETF at 1050 ietf-ipr@ietf.org. 1052 Disclaimer of Validity 1054 This document and the information contained herein are provided on an 1055 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1056 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1057 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1058 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1059 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1060 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1062 Copyright Statement 1064 Copyright (C) The Internet Society (2005). This document is subject 1065 to the rights, licenses and restrictions contained in BCP 78, and 1066 except as set forth therein, the authors retain all their rights.