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