idnits 2.17.1 draft-boucadair-connectivity-provisioning-protocol-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2015) is 3321 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: September 24, 2015 D. Zhang 6 Huawei Technologies 7 P. Georgatsos 8 CERTH 9 March 23, 2015 11 Connectivity Provisioning Negotiation Protocol (CPNP) 12 draft-boucadair-connectivity-provisioning-protocol-09 14 Abstract 16 This document specifies the Connectivity Provisioning Negotiation 17 Protocol (CPNP) which is used to facilitate the dynamic negotiation 18 of service parameters. 20 CPNP is a generic protocol that can be used for various negotiation 21 purposes that include (but are not necessarily limited to) 22 connectivity provisioning services, storage facilities, Content 23 Delivery Networks (CDN) footprint, etc. CPNP can be extended with 24 new Information Elements. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 24, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. CPNP Functional Elements . . . . . . . . . . . . . . . . . . 6 69 4. Order Processing Models . . . . . . . . . . . . . . . . . . . 7 70 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 71 6. CPNP Deployment Models . . . . . . . . . . . . . . . . . . . 10 72 7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 10 73 8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Client/Server Communication . . . . . . . . . . . . . . . 12 75 8.2. Server Discovery . . . . . . . . . . . . . . . . . . . . 13 76 8.3. Policy Configuration on the CPNP Server . . . . . . . . . 13 77 8.4. CPNP Session . . . . . . . . . . . . . . . . . . . . . . 15 78 8.5. Extended CPNP Session . . . . . . . . . . . . . . . . . . 15 79 8.6. CPNP Transaction . . . . . . . . . . . . . . . . . . . . 15 80 8.7. CPNP Timers . . . . . . . . . . . . . . . . . . . . . . . 16 81 8.8. CPNP Operations . . . . . . . . . . . . . . . . . . . . . 16 82 8.9. Connectivity Provisioning Documents . . . . . . . . . . . 18 83 8.10. Child Provisioning Quotation Orders . . . . . . . . . . . 19 84 8.11. Negotiations with Multiple CPNP Servers . . . . . . . . . 20 85 8.12. State Management . . . . . . . . . . . . . . . . . . . . 20 86 8.12.1. On the Client Side . . . . . . . . . . . . . . . . . 21 87 8.12.2. On the Server Side . . . . . . . . . . . . . . . . . 23 88 9. CPNP Objects . . . . . . . . . . . . . . . . . . . . . . . . 26 89 9.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 26 90 9.1.1. CUSTOMER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 26 91 9.1.2. PROVIDER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 26 92 9.1.3. TRANSACTION_ID . . . . . . . . . . . . . . . . . . . 27 93 9.1.4. SEQUENCE_NUMBER . . . . . . . . . . . . . . . . . . . 27 94 9.1.5. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 27 95 9.1.6. EXPECTED_RESPONSE_TIME . . . . . . . . . . . . . . . 27 96 9.1.7. EXPECTED_OFFER_TIME . . . . . . . . . . . . . . . . . 27 97 9.1.8. VALIDITY_OFFER_TIME . . . . . . . . . . . . . . . . . 28 98 9.1.9. CONNECTIVITY_PROVISIONING_DOCUMENT . . . . . . . . . 28 99 9.1.10. Information Elements . . . . . . . . . . . . . . . . 28 100 9.2. Operation Messages . . . . . . . . . . . . . . . . . . . 30 101 9.2.1. QUOTATION . . . . . . . . . . . . . . . . . . . . . . 30 102 9.2.2. PROCESSING . . . . . . . . . . . . . . . . . . . . . 30 103 9.2.3. OFFER . . . . . . . . . . . . . . . . . . . . . . . . 32 104 9.2.4. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . 32 105 9.2.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 9.2.6. DECLINE . . . . . . . . . . . . . . . . . . . . . . . 33 107 9.2.7. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 34 108 9.2.8. WITHDRAW . . . . . . . . . . . . . . . . . . . . . . 34 109 9.2.9. UPDATE . . . . . . . . . . . . . . . . . . . . . . . 35 110 9.2.10. FAIL . . . . . . . . . . . . . . . . . . . . . . . . 36 111 10. Message Validation . . . . . . . . . . . . . . . . . . . . . 37 112 10.1. On the Client Side . . . . . . . . . . . . . . . . . . . 37 113 10.2. On the Server Side . . . . . . . . . . . . . . . . . . . 38 114 11. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 39 115 11.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 39 116 11.1.1. Order Negotiation Cycle . . . . . . . . . . . . . . 39 117 11.1.2. Order Withdrawal Cycle . . . . . . . . . . . . . . . 41 118 11.1.3. Order Update Cycle . . . . . . . . . . . . . . . . . 41 119 11.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 41 120 11.2.1. Order Processing . . . . . . . . . . . . . . . . . . 41 121 11.2.2. Order Withdrawal . . . . . . . . . . . . . . . . . . 43 122 11.2.3. Order Update . . . . . . . . . . . . . . . . . . . . 43 123 11.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 43 124 11.4. Message Re-Transmission . . . . . . . . . . . . . . . . 44 125 12. Operational Guidelines . . . . . . . . . . . . . . . . . . . 44 126 12.1. Logging on the CPNP Server . . . . . . . . . . . . . . . 44 127 12.2. Business Guidelines & Objectives . . . . . . . . . . . . 44 128 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 129 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 130 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 131 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 132 16.1. Normative References . . . . . . . . . . . . . . . . . . 47 133 16.2. Informative References . . . . . . . . . . . . . . . . . 47 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 136 1. Introduction 138 This document defines the Connectivity Provisioning Negotiation 139 Protocol (CPNP) that is meant to dynamically exchange and negotiate 140 connectivity provisioning parameters, and other service-specific 141 parameters, between a Customer and a Provider. CPNP is a tool that 142 introduces automation in the service negotiation and activation 143 procedures, thus fostering the overall service provisioning process. 145 CPNP can be seen as a component of the dynamic negotiation meta- 146 domain described in Section 3.4 of [RFC7149]. 148 CPNP is a generic protocol that can be used for other negotiation 149 purposes than connectivity provisioning. For example, CPNP can be 150 used to request extra storage resources, to extend the footprint of a 151 CDN (Content Delivery Networks), to enable additional features from a 152 cloud Provider, etc. CPNP can be extended with new Information 153 Elements (IEs). 155 [RFC7297] describes a Connectivity Provisioning Profile (CPP) 156 template to capture connectivity requirements to be met by a 157 transport infrastructure for the delivery of various services such as 158 Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) 159 services [RFC4026]. The CPP document defines the set of IP transfer 160 parameters that reflect the guarantees that can be provided by the 161 underlying transport network together with reachability scope and 162 capacity needs. CPNP uses the CPP template to encode connectivity 163 provisioning clauses. 165 As a reminder, several proposals have been made in the past by the 166 (research) community (e.g., COPS-SLS, Service Negotiation Protocol 167 (SrNP), Dynamic Service Negotiation Protocol (DSNP), Resource 168 Negotiation and Pricing Protocol (RNAP), Service Negotiation and 169 Acquisition Protocol (SNAP), etc.). It is out of the scope of this 170 document to elaborate on the differences between CPNP and the 171 aforementioned proposals. 173 This document is organized as follows: 175 o Section 3 defines the functional elements involved in CPNP 176 exchanges. 177 o Section 4 introduces several order processing models and precises 178 those that are targeted by CPNP. 179 o Section 5 enumerates a non-exhaustive list of use cases that could 180 benefit from CPNP. 181 o Section 5 discusses CPNP deployment models. 182 o Section 7 presents the CPNP negotiation model. 183 o Section 8 provides an overview of the protocol. 184 o Section 9 specifies the CPNP objects. 185 o Section 10 describes the CPNP message validation procedure. 186 o Section 11 specifies the behavior of the involved CPNP functional 187 elements. 188 o Section 12 discusses relevant operational guidelines. 189 o Section 13 discusses protocol security aspects. 191 2. Terminology 193 This document makes use of the following terms: 195 o Customer: 197 Is a business role which denotes an entity that is involved in the 198 definition and the possible negotiation of a contract, including a 199 Connectivity Provisioning Agreement, with a Provider. A 200 connectivity provisioning contract is captured in a dedicated CPP 201 template-based document, which specifies (among other 202 information): the sites to be connected, border nodes, outsourced 203 operations (e.g., routing, force via points). 205 The right to invoke the subscribed service may be delegated by the 206 Customer to third-party End Users, or brokering services. 208 A Customer can be a Service Provider, an application owner, an 209 enterprise, a user, etc. 211 o Network Provider (or Provider): 213 Owns and administers one or many transport domain(s) (typically 214 Autonomous System (AS)) composed of IP switching and transmission 215 resources (e.g., routing, switching, forwarding, etc.). Network 216 Providers are responsible for ensuring connectivity services 217 (e.g., offering global or restricted reachability at specific 218 rates). Offered connectivity services may not necessarily be 219 restricted to IP. 221 The policies to be enforced by the connectivity service delivery 222 components can be derived from the technology-specific clauses 223 that might be included in contracts agreed with the Customers. If 224 no such clauses are included in the agreement, the mapping between 225 the connectivity requirements and the underlying technology- 226 specific policies to be enforced is deployment-specific. 228 o Quotation Order: 230 Denotes a request made by the Customer to the Provider that 231 includes a set of requirements. The Customer may express its 232 service-specific requirements by assigning (fixed or loosely 233 defined) values to the information items included in the commonly 234 understood template (e.g. CPP template) describing the offered 235 service. These requirements constitute the parameters to be 236 mutually agreed upon. 238 o Offer: 240 Refers to a response made by the Provider to a Customer 's 241 quotation order as to the extent at which the Provider may satisfy 242 the order at the time of its receipt. Offers reflect the 243 capability of the Provider in accommodating received Customer 244 orders beyond monolithic 'yes/no' answers. 246 An offer may fully or partially meet the requirements of the 247 corresponding order. In the latter case, it may include 248 alternative suggestions which the Customer may take into account 249 by issuing a new order. 251 o Agreement: 253 Refers to an order placed by the Customer and accepted by the 254 Provider. It signals the successful conclusion of a negotiation 255 cycle. 257 3. CPNP Functional Elements 259 The following functional elements are defined: 261 o CPNP client (or client): 263 Denotes a software instance that sends CPNP requests and receives 264 CPNP responses. The current operations that can be performed by a 265 CPNP client are listed below: 267 1. Create a quotation order (Section 11.1.1). 269 2. Cancel an ongoing quotation order under negotiation 270 (Section 11.1.1). 272 3. Accept an offer made by a server (Section 11.1.1). 274 4. Withdraw an agreement (Section 11.1.2). 276 5. Update an agreement (Section 11.1.3). 278 o CPNP server (or server): 280 Denotes a software instance that receives CPNP requests and sends 281 back CPNP responses accordingly. The CPNP server is responsible 282 for the following operations: 284 1. Process a quotation order (Section 11.2.1). 286 2. Make an offer (Section 11.2.1). 288 3. Cancel an ongoing quotation order (Section 11.2.2). 290 4. Process an order withdrawal (Section 11.2.3). 292 4. Order Processing Models 294 For preparing their service orders, the Customers may need to be 295 aware of the offered services. The Providers therefore should first 296 proceed with the announcement of the services that they can provide. 297 The service announcement process may take place at designated global 298 or Provider-specific service markets, or through explicit 299 interactions with the Providers. The details of this process are 300 outside the scope of a negotiation protocol. 302 With or without such service announcement mechanisms in place, the 303 following order processing models can be distinguished: 305 The following order processing models can be distinguished: 307 1. Frozen model: 309 The Customer cannot actually negotiate the parameters of the 310 service(s) offered by a Provider. After consulting the 311 Provider's service portfolio, the Customer selects the service 312 offer he/she wants to subscribe and places an order to the 313 Provider. Order handling is quite simple on the Provider side 314 because the service is not customized as per Customer's 315 requirements, but rather pre-designed to target a group of 316 customers having similar requirements (i.e., these customers 317 share the same Customer Provisioning Profile). 319 2. Negotiation-based model: 321 Unlike the frozen model, the Customer documents his/her 322 requirements in a request for a quotation, which is then sent to 323 one or several Providers. Solicited Providers check whether they 324 can address these requirements or not, and get back to the 325 Customer accordingly, possibly with an offer that may not exactly 326 match customer's requirements (e.g., a 100 Mbps connection cannot 327 be provisioned given the amount of available resources, but an 80 328 Mbps connection can be provided). A negotiation between the 329 Customer and the Provider(s) then follows to the end of reaching 330 an agreement. 332 Both frozen and negotiation-based models require the existence of 333 appropriate service templates like a CPP template and their 334 instantiation for expressing specific offerings from Providers and 335 service requirements from Customers, respectively. CPNP can be used 336 in either model for automating the required Customer-Provider 337 interactions. Since the frozen model can be seen as a special case 338 of the negotiation-based model, not only 'yes/no' answers but also 339 counter offers may be issued by the Provider in response to Customer 340 orders, this document focuses on the negotiation-based model. 342 Order processing management on the Network Provider's side is usually 343 connected with the following functional blocks: 345 o Network Provisioning (including Order Activation, Network 346 Planning, etc.) 347 o Authentication, Authorization and Accounting (AAA) 348 o Network and service management (performance verification, 349 complaint analysis, etc.) 350 o Sales-related functional blocks (e.g., billing, invoice 351 validation, etc.) 352 o Network Impact Analysis 354 CPNP does not assume any specific knowledge about these functional 355 blocks, drawing an explicit line between protocol operation and the 356 logic for handling connectivity provisioning requests. Evidently 357 order handling logic is subject to the information manipulated by 358 these blocks. For example, the resources that can be allocated to 359 accommodate Customer's requirements may depend on network 360 availability estimates as calculated by the planning functions and 361 related policies as well as on the number of orders to be processed 362 simultaneously over a given period of time. 364 This document does not elaborate on how Customers are identified and 365 subsequently managed by the Provider's Information System. 367 5. Sample Use Cases 369 A non-exhaustive list of CPNP use cases is provided below: 371 1. [RFC4176] introduces the L3VPN Service Order Management 372 functional block which is responsible for managing the requests 373 initiated by the Customers and tracks the status of the 374 completion of the related operations. CPNP can be used between 375 the Customer and the Provider to negotiate L3VPN service 376 parameters. 378 A CPNP server could therefore be part of the L3VPN Service Order 379 Management functional block discussed in [RFC4176]. 381 2. CPNP can be used between two adjacent domains to deliver IP 382 interconnection services (e.g., enable, update, disconnect). For 383 example, two Autonomous Systems (ASes) can be connected via 384 several interconnection points. CPNP can be used between these 385 ASes to upgrade existing links, request additional resources, 386 provision a new interconnection point, etc. 388 See for example the framework documented in [ETICS]. 390 3. An integrated Provider can use CPNP to rationalize connectivity 391 provisioning needs related to its service portfolio. A CPNP 392 server function is used by network operations teams. A CPNP 393 interface to invoke CPNP negotiation cycles is exposed to service 394 management teams. 396 4. Service Providers can use CPNP to initiate connectivity 397 provisioning requests towards a number of Network Providers so 398 that to optimize the cost of delivering their services. Although 399 multiple CPNP ordering cycles can be initiated by a Service 400 Provider towards multiple Network Providers, a subset of these 401 orders may actually be put into effect. 403 For example, a cloud Service Provider can use CPNP to request 404 more resources from Network Providers. 406 5. CPNP can be used in Machine-to-Machine (M2M) environments to 407 dynamically subscribe to M2M services (e.g., access to data 408 retrieved by a set of sensors, extend sensor coverage, etc.). 410 Also, Internet of Things (IoT, [RFC6574]) domains may rely on 411 CPNP to enable dynamic provisioning of data produced by involved 412 objects, according to their specific policies, to various 413 external stakeholders such as data analytics and business 414 intelligence companies. Direct CPNP-based interactions between 415 IoT domains and interested parties enable open access to diverse 416 sets of data across the Internet, e.g., from multiple types of 417 sensors, user groups and/or geographical areas. 419 6. A Provider offering cloud services can expose a CPNP interface to 420 allow Customers to dynamically negotiate related service features 421 such as additional storage, processing and networking resources, 422 enhanced security filters, etc. 424 7. In the inter-cloud context (also called cloud of clouds or cloud 425 federation), CPNP can be used to reserve external computing and 426 networking resources in other cloud environments. 428 8. CDN Providers can use CPNP to extend their footprint by 429 interconnecting their CDN infrastructure [RFC6770] (see 430 Figure 1). 432 ,--,--,--. ,--,--,--. 433 ,-' `-. ,-' `-. 434 (CDN Provider 'A')=====(CDN Provider 'B') 435 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 436 `--'--'--' `--'--'--' 438 Figure 1: CDN Interconnection 440 6. CPNP Deployment Models 442 Several CPNP deployment models can be envisaged. Two examples are 443 listed below: 445 o The Customer deploys a CPNP client while one or several CPNP 446 servers are deployed by the Provider. 447 o The Customer does not enable any CPNP client. The Provider 448 maintains a Customer Order Management portal. The Customer can 449 initiate connectivity provisioning quotation orders via the 450 portal; appropriate CPNP messages are then generated and sent to 451 the relevant CPNP server. In this model, both the CPNP client and 452 CPNP server are under the responsibility of the same 453 administrative entity (i.e., Network Provider). 455 Once the negotiation of connectivity provisioning parameters is 456 successfully concluded that is, an order has been placed by the 457 Customer, the actual network provisioning operations are initiated. 458 The specification of related dynamic resource allocation and policy 459 enforcement schemes, as well as how CPNP servers interact with the 460 network provisioning functional blocks at Provider sides are out of 461 the scope of this document. 463 This document does not make any assumption about the CPNP deployment 464 model either. 466 7. CPNP Negotiation Model 468 CPNP runs between a Customer and a Provider carrying service orders 469 from the Customer and respective responses from the Provider to the 470 end of reaching a connectivity service provisioning agreement. As 471 the services offered by the Provider are well-described, by means of 472 the CPP template, the negotiation process is essentially a value- 473 settlement process, where an agreement is pursued on the values of 474 the commonly understood information items (service parameters) 475 included in the service description template. 477 The protocol is transparent to the content that it carries and to the 478 negotiation logic, at Customer and Provider sides, that manipulates 479 the content. 481 The protocol aims at facilitating the execution of the negotiation 482 logic by providing the required generic communication primitives. 484 Since negotiations are initiated and primarily driven by the 485 Customer's negotiation logic, it is reasonable to assume that the 486 Customer can only call for an agreement. An implicit approach is 487 adopted for not overloading the protocol with additional messages. 488 In particular, the acceptance of an offer made by the Provider 489 signals a call for agreement from the Customer. Note that it is 490 almost certain the Provider to accept this call since it refers to an 491 offer that itself made. Of course, at any point the Provider or the 492 Customer may quit the negotiations, each on its own grounds. 494 Based on the above, CPNP adopts a Quotation Order/Offer/Answer model, 495 which proceeds through the following basic steps: 497 1. The client specifies its service requirements via a Provision 498 Quotation Order (PQO). The order may include fixed or loosely 499 defined values in the clauses describing service provisioning 500 characteristics. 502 2. The server declines the PQO, or makes an offer to address the 503 requirements of the PQO, or which may suggests a counter- 504 proposals that partially addresses the requirements of the PQO 505 for specific requirements that cannot be accommodated. 507 3. The client either accepts or declines the offer. Accepting the 508 offer implies a call for agreement. 510 Multiple instances of CPNP may run at Customer or Provider domains. 511 A CPNP client may be engaged simultaneously in multiple negotiations 512 with the same or different CPNP servers (parallel negotiations, see 513 Section 8.11) and a CPNP server may need to negotiate with other 514 Provider(s) as part of negotiations with a CPNP client (cascaded 515 negotiations, see Section 8.10). 517 CPNP relies on various timers to achieve its operations. These 518 timers are used to guide the negotiation logic at both CPNP client 519 and CPNP server sides, particularly in cases where the CPNP client is 520 involved in parallel negotiations with several CPNP servers or in 521 cases where the CPNP server is, in its turn, involved in negotiations 522 with other Providers for processing a given quotation order. Related 523 to the above, CPNP allows the CPNP server to request for more time. 524 This request may be accepted or rejected by the CPNP client. 526 Providers may need to publish available services to the Customers 527 (see Section 4). CPNP may optionally support this functionality. 528 Dedicated templates can be defined for the purpose of service 529 announcements, which will be used by the CPNP clients to initiate 530 their CPNP negotiation cycles. 532 For simplicity, a single Offer/Answer stage is assumed within one a 533 CPNP negotiation cycle. Nevertheless, as stated before, multiple 534 CPNP negotiation cycles can be undertaken by a CPNP client (see 535 Figure 2). 537 The model is flexible as it can accommodate changing conditions over 538 time (e.g., introduction of an additional VPN site). 540 +------+ +------+ +------+ +------+ 541 |Client| |Server| |Client| |Server| 542 +------+ +------+ +------+ +------+ 543 |=====Quotation Order=====>| |=====Quotation Order=====>| 544 |<==========Offer==========| |<==========Offer==========| 545 |===========Accept========>| |==========Decline========>| 547 1-Step Successful Negotiation 1-Step Failed Negotiation 548 Cycle Cycle 550 +------+ +------+ +------+ +------+ 551 |Client| |Server| |Client| |Server| 552 +------+ +------+ +------+ +------+ 553 |===Quotation Order(a)====>| |===Quotation Order(i)====>| 554 |<==========Offer==========| |<==========Offer==========| 555 |==========Decline========>| |==========Decline========>| 556 |===Quotation Order(b)====>| |===Quotation Order(j)====>| 557 |<==========Offer==========| |<==========Offer==========| 558 |===========Accept========>| |==========Decline========>| 559 |===Quotation Order(k)====>| 560 |<==========Offer==========| 561 |==========Decline========>| 562 |===Quotation Order(l)====>| 563 |<==Fail to make an offer==| 565 N-Step Negotiation Cycle: N-Step Negotiation Cycle: 566 Successful Negotiation Failed Negotiation 568 Figure 2: Overall Negotiation Process 570 8. Protocol Overview 572 8.1. Client/Server Communication 574 CPNP is a client/server protocol which is designed to run over any 575 transport protocol with UDP being the default transport mode. No 576 permanent CPNP session needs to be maintained between the client and 577 the server. There is no need to run CPNP over a reliable transport 578 mode because CPNP messages are acknowledged. 580 The server uses CPNP_PORT (see Section 14) to bind the CPNP service. 581 The client sends CPNP messages to CPNP_PORT. The same port used as 582 the source port of the request sent to the server must be used by the 583 server to reply to that request. 585 CPNP is independent of the IP address family. 587 CPNP retransmission is discussed in Section 11.4. 589 8.2. Server Discovery 591 The CPNP client can be configured with the CPNP server(s) using 592 manual or dynamic configuration means. For example, Providers may 593 configure dedicated SRV records ([RFC2782]) or may use a well-known 594 name/address. 596 Discussions about how the client can discovers its the server(s) of 597 its interest are out of the scope of this document. The document 598 assumes that a the required CPNP server can be reached by the CPNP 599 client, thanks to some configuration means. 601 8.3. Policy Configuration on the CPNP Server 603 As an input to its decision-making process, the CPNP server may be 604 connected to various external modules such as: Customer Profiles, 605 Network Topology, Network Resource Management, Orders Repository, AAA 606 and Network Provisioning Manager (an example is shown in Figure 3). 608 These external modules provide inputs to the CPNP server, so that it 609 can: 611 o Check whether a customer is entitled to initiate a provisioning 612 quotation request. 614 o Check whether a customer is entitled to cancel an on-going order. 616 o Check whether administrative data (e.g., billing-related 617 information) have been verified before starting handling the 618 request. 620 o Check whether network capacity is available or additional capacity 621 is required. 623 o Receive guidelines from network design and sales blocks (e.g., 624 pricing, network usage levels, threshold on number of CPP 625 templates that can be processed over a given period of time as a 626 function of the nature of the service to be delivered, etc.). 628 o Transfer completed orders to network provisioning blocks. 630 The above list of CPNP server operations is not exhaustive. 632 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 .Business & Administrative Management . 634 .+------------------------++---------------------------+. 635 .| Business Guidelines || Billing & Charging |. 636 .+-----------+------------++-----------+---------------+. 637 . | | . 638 . +-------------------+ | . 639 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 640 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 641 .Order Handling Management | | . 642 . +-------------------+ +-------+-----+--------------+ . 643 . |Network Topology DB+--+ CPNP Server | . 644 . +-------------------+ +-+---+---+---+---+-----+----+ . 645 . | | | | | | . 646 . +------------------------+-+ | | | | | . 647 . | Network Dimensioning | | | | | | . 648 . | & Planning | | | | | | . 649 . +--------------------------+ | | | | | . 650 . +----------------------------+-+ | | | +---+----+ . 651 . | | | | | | AAA | . 652 . | Network +------------+ | | | +--------+ . 653 . | Resource | +------------+-+ | +-+----------+ . 654 . | Management | | Customer | | | Orders | . 655 . | | | Profiles | | | Repository | . 656 . +-----------------+ +--------------+ | +------------+ . 657 . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . 658 +--------------------------------------+----------------+ 659 | Network Provisioning Manager | 660 +-------------------------------------------------------+ 662 Figure 3: Order Handling Management Functional Block 664 The following order handling modes can be also configured on the 665 server: 667 1. Fully automated mode: 669 This mode does not require any action from the administrator when 670 receiving a request for a service. The server can execute its 671 decision-making process related to the orders received and 672 generate corresponding offers. 674 2. Administrative validation checking: 676 Some or all of the server's operations are subject to 677 administrative validation procedures. This mode requires an 678 action from the administrator for every request received. The 679 CPNP methods which can be automatically handled by the server or 680 they are subject to one or several validation administrative 681 checks can be configured on the server. 683 8.4. CPNP Session 685 Both the client and server maintain the following CPNP transport 686 session information: 688 A CPNP session is identified by the following items: 690 o IP address of the client 691 o Client's port number 692 o IP address of the server 693 o Server's port number 695 8.5. Extended CPNP Session 697 An extended PQO session is denoted by a 5-uplet defined as follows: 699 o CPNP session (Section 8.4) 701 o Incremented Sequence Number (Section 11.3) 703 o Customer Agreement Identifier: This is a unique identifier 704 assigned to the order under negotiation by the client 705 (Section 9.1.1). This identifier is also used to identify the 706 agreement that will result from a successful negotiation. 708 o Provider Agreement Identifier: This is a unique identifier 709 assigned to the order under negotiation by the server 710 (Section 9.1.2). This identifier is also used to identify the 711 agreement that will result from a successful negotiation. 713 o Transaction-ID (Section 9.1.3) 715 8.6. CPNP Transaction 717 A CPNP transaction occurs between a client and a server for pursuing, 718 modifying, withdrawing a service agreement and comprises all CPNP 719 messages exchanged between the client and the server, from the first 720 request sent by the client to the final response sent by the server. 721 A CPNP transaction is bound to a CPNP session. 723 Because multiple CPNP transactions can be maintained by the CPNP 724 client, the client must assign an identifier to uniquely identify a 725 given transaction. This identifier is denoted as Transaction-ID. 727 The Transaction-ID must be randomly assigned by the CPNP client, 728 according to the best current practice for generating random numbers 729 [RFC4086] that cannot be guessed easily. Transaction-ID is used for 730 validating CPNP responses received by the client. 732 In the context of a transaction, the client needs to randomly select 733 a sequence number and assign it in the first CPNP message to send. 734 This number is then incremented for each request message is 735 subsequently sent within the on-going CPNP transaction (see 736 Section 11.3). 738 8.7. CPNP Timers 740 CPNP adopts a simple retransmission procedure which relies on a 741 retransmission timer denoted as RETRANS_TIMER and maximum retry 742 threshold. The use of RETRANS_TIMER and a maximum retry threshold 743 are described in Section 11. 745 The response timer (RESPONSE_TIMER) is set by the client to denote 746 the time, in seconds, the client will wait for receiving a response 747 from the server to a provisioning quotation order request (see 748 Section 9.1.6). If the timer expires, the respective quotation order 749 is cancelled by the client and a CANCEL message is generated 750 accordingly. 752 An offer expiration timer (EXPIRE_TIMER) is set by the server to 753 represent the time, in minutes, after which an offer made by the 754 server will be invalid (see Section 9.1.8). 756 8.8. CPNP Operations 758 The current CPNP operations are listed below. They may be augmented, 759 depending on the nature of some transactions or because of security 760 considerations that may necessitate a distinct CPNP client/server 761 authentication phase before negotiation begins. 763 o QUOTATION: 765 This operation is used by the client to initiate a provisioning 766 quotation order. Upon receipt of a QUOTATION request, the server 767 may respond with a PROCESSING, OFFER or a FAIL message. A 768 QUOTATION-initiated transaction can be terminated by a FAIL 769 message. 771 o PROCESSING: 773 This operation is used to inform the remote party that the message 774 (the order quotation or the offer) sent was received and it is 775 processed. This message can also be issued by the server to 776 request more time, in which case the client may reply with an ACK 777 or FAIL message depending on whether more time can or cannot be 778 granted. 780 o OFFER: 782 This operation is used by the server to inform the client about an 783 offer that can best accommodate the requirements indicated in the 784 previously received QUOTATION message. 786 o ACCEPT: 788 This operation is used by the client to confirm the acceptance of 789 an offer made by the server. This message implies a call for 790 agreement. An agreement is reached when an ACK is subsequently 791 received from the server, which is likely to happen; it is rather 792 unlikely the server to reject an offer that it has already made. 794 o ACK: 796 This operation is used by the server to acknowledge the receipt of 797 an ACCEPT or WITHDRAW message, or by the client to confirm the 798 time extension requested by the server for processing the last 799 received quotation order. 801 o DECLINE: 803 This operation is used by the client to reject an offer made by 804 the server. The on-going transaction may not be terminated 805 immediately, e.g., the server/client may issue another offer/ 806 order. 808 o CANCEL: 810 This operation is used by the client to cancel (quit) the on-going 811 transaction. 813 o WITHDRAW: 815 This operation is used by the client to withdraw an agreement. 817 o UPDATE: 819 This operation is used by the client to update an existing 820 agreement. For example, this method can be invoked to add a new 821 site. This method will trigger a new negotiation cycle. 823 o FAIL: 825 This operation is used by the server to indicate that it cannot 826 accommodate the requirements documented in the PQO conveyed in the 827 QUOTATION message or to inform the client about an error 828 encountered when processing the received message. In either case, 829 the message implies that the server is unable to make offers and 830 as such it terminates the on-going transaction. 832 This message is also used by the client to reject a time extension 833 request received from the server (in a PROCESSING message). The 834 message includes a status code for providing explanatory 835 information. 837 Evidently, the above CPNP primitives are service-independent. CPNP 838 messages may transparently carry service-specific objects which are 839 handled by the negotiation logic at either side. The document 840 specifies the service objects that are required for connectivity 841 provisioning negotiation (see Section 8.9). Additional service- 842 specific objects to be carried in the CPNP messages can be defined in 843 the future for accommodating alternative deployment or other service 844 provisioning needs. 846 8.9. Connectivity Provisioning Documents 848 CPNP makes use of several flavors of Connectivity Provisioning 849 Documents (CPD). These documents follow the CPP template described 850 in [RFC7297]. 852 o Requested Connectivity Provisioning Document (Requested CPD): 854 refers to the CPD included by a CPNP client in a QUOTATION 855 request. 857 o Offered Connectivity Provisioning Document (Offered CPD): 859 This document is included by a CPNP server in an OFFER message. 860 Its information reflects the proposal of the server to accommodate 861 all or a subset of the clauses depicted in a Requested CPD. A 862 validity time is associated with the offer made. 864 o Agreed Connectivity Provisioning Document (Agreed CPD): 866 If the client accepts an offer made by the server, the Offered CPD 867 is included in an ACCEPT message. This CPD is also included in an 868 ACK message. Thus, a 3-way hand-shaking procedure is followed for 869 successfully concluding the negotiation. 871 Figure 4 shows a typical CPNP negotiation cycle and the use of the 872 different types of Connectivity Provisioning Documents. 874 +------+ +------+ 875 |Client| |Server| 876 +------+ +------+ 877 |======QUOTATION (Requested CPD)=====>| 878 |<============PROCESSING==============| 879 |<========OFFER (Offered CPD)=========| 880 |=============PROCESSING=============>| 881 |=========ACCEPT (Agreed CPD)========>| 882 |<=========ACK (Agreed CPD)===========| 884 Figure 4: Connectivity Provisioning Documents 886 A provisioning document can include parameters with fixed values, 887 loosely defined values, or a combination thereof. A provisioning 888 document is said to be concrete if all clauses have fixed values. 890 A typical evolution of a negotiation cycle would start with a 891 quotation order with loosely defined parameters, and then, as offers 892 are made, it would conclude with concrete provisioning document for 893 calling for the agreement. 895 8.10. Child Provisioning Quotation Orders 897 If the server detects that network resources from another Network 898 Provider need to be allocated in order to accommodate the 899 requirements described in a PQO (e.g., in the context of an inter- 900 domain VPN service, additional PE router resources need to be 901 allocated), the server may generate child PQOs to request the 902 appropriate network provisioning operations (see Figure 5). In such 903 situation, the server behaves also as a CPNP client. The server 904 associates the parent order with its child PQOs. This is typically 905 achieved by locally adding the reference of the child PQO to the 906 parent order. 908 +------+ +--------+ +--------+ 909 |Client| |Server A| |Server B| 910 +------+ +--------+ +--------+ 911 | | | 912 |=====QUOTATION=====>| | 913 |<====PROCESSING=====| | 914 | |=====QUOTATION=====>| 915 | |<====PROCESSING=====| 916 | |<=======OFFER=======| 917 | |=====PROCESSING====>| 918 | |=======ACCEPT======>| 919 | |<=======ACK=========| 920 |<=======OFFER=======| | 921 |=====PROCESSING====>| | 922 |=======ACCEPT======>| | 923 |<=======ACK=========| | 925 Figure 5: Example of Child Orders 927 8.11. Negotiations with Multiple CPNP Servers 929 A CPNP client may undertake multiple negotiations in parallel with 930 several servers for practical reasons such as cost optimization and 931 fail-safety. The multiple negotiations may lead to one or many 932 agreements. Multiple negotiations with the same Provider are not 933 precluded. 935 The salient point underlining the parallel negotiations scenario is 936 that although the negotiation protocol is strictly between two 937 parties, the negotiation logic may not necessarily be. The CPNP 938 client negotiation logic may need to collectively drive parallel 939 negotiations, as the negotiation with one server may affect the 940 negotiation with other servers; e.g., it may need to use the 941 responses from all servers as input for determining the messages (and 942 their content) to subsequently send in each individual negotiation. 943 Timing is therefore an important aspect at the client's. The CPNP 944 client needs to have the ability to synchronize the receipt of the 945 responses from the servers. CPNP takes into account this requirement 946 by allowing clients to specify in the QUOTATION message the time by 947 which the server needs to respond (see Section 9.1.6). 949 8.12. State Management 951 Both the client and the server maintain repositories to store on- 952 going orders. How these repositories are maintained is deployment- 953 specific. It is out of scope of this document to elaborate on such 954 considerations. Timestamps are also logged to track state change. 955 Tracking may be needed for various reasons,including regulatory ones. 957 8.12.1. On the Client Side 959 The following lists the states which can be associated with a given 960 order on the client's side: 962 o Created: 964 when the order has been created. It is not handled by the client 965 until the administrator allows to process it. 967 o AwaitingProcessing: 969 when the administrator approved of processing a created order and 970 the order has not been handled yet. 972 o PQOSent: 974 when the order has been sent to the server. 976 o ServerProcessing: 978 when the server has confirmed the receipt of the order. 980 o OfferReceived: 982 when an offer has been received from the server. 984 o OfferProcessing: 986 when a received offer is currently processed by the client. 988 o AcceptSent: 990 when the client confirmed the offer to the server. 992 o AcceptAck: 994 when the offer is acknowledged by the server. 996 o Cancelled: 998 when the order has failed or cancelled. 1000 +------------------+ 1001 | Created |-----------------+ 1002 +------------------+ | 1003 | | 1004 v | 1005 +------------------+ | 1006 |AwaitingProcessing|----------------+| 1007 +------------------+ || 1008 | || 1009 QUOTATION || 1010 v || 1011 +------------------+ || 1012 | PQOSent |---CANCEL------+|| 1013 +------------------+ vvv 1014 | +-----+ 1015 PROCESSING | | 1016 v | | 1017 +------------------+ CANCEL | C | 1018 | ServerProcessing |------------>| A | 1019 +------------------+ FAIL | N | 1020 | | C | 1021 | | E | 1022 OFFER | L | 1023 | | L | 1024 v | E | 1025 +------------------+ | D | 1026 | OfferReceived |---CANCEL--->| | 1027 +------------------+ | | 1028 | PROCESSING +-----+ 1029 v ^^^ 1030 +------------------+ ||| 1031 | OfferProcessing |---DECLINE-----+|| 1032 +------------------+ || 1033 | ACCEPT || 1034 v || 1035 +------------------+ || 1036 | AcceptSent |---CANCEL-------+| 1037 +------------------+ | 1038 | ACK | 1039 v | 1040 +------------------+ | 1041 | AcceptAck |---WITHDRAW------+ 1042 +------------------+ 1044 Figure 6: CPNP Finite State Machine (Client Side) 1046 8.12.2. On the Server Side 1048 The following lists the states which can be associated with a given 1049 order and a corresponding offer on the server's side: 1051 o PQOReceived: 1053 when the order has been received from the client. 1055 o AwaitingProcessing: 1057 when the order is being processed by the server. An action from 1058 the server administrator may be needed. 1060 o OfferProposed: 1062 when the request has been successfully handled and an offer has 1063 been sent to the client. 1065 o ProcessingReceived: 1067 when the server received a PROCESSING for an offer sent to the 1068 client. 1070 o AcceptReceived: 1072 when the server received a confirmation for the offer from the 1073 client. 1075 o AcceptAck: 1077 when the server acknowledged the offer (accepted by client) to the 1078 client. 1080 o Cancelled: 1082 when the order has failed to be met or it has been cancelled by 1083 the client. Associate resources must be released in the latter 1084 case, if prior reserved. 1086 o ChildCreated: 1088 when a child order has been created in cases where resources from 1089 another Network Provider are needed. 1091 o ChildPQOSent: 1093 when a child order has been sent to the remote server. 1095 o ChildServerProcessing: 1097 when a child order is currently processed by the remote server. 1099 o ChildOfferReceived: 1101 when an offer has been received to a child order from the remote 1102 server. 1104 o ChildOfferProcessing: 1106 when a received offer to a child order is currently processed. 1108 o ChildAcceptSent: 1110 when the child offer (offer received from the remote server in 1111 response to a child order) is confirmed to the remote server. 1113 o ChildAcceptAck: 1115 when an accepted child offer is acknowledged by the remote server. 1117 +------------------+ 1118 +---------------------| ChildCreated | 1119 | +------------------+ 1120 v | ^ 1121 +------------------+ | | 1122 | ChildPQOSent |----------------+| Q 1123 +------------------+ || U 1124 | || O 1125 QUOTATION || T 1126 v || A +--------------------+ 1127 +---------------------+ CANCEL || T | PQOReceived | 1128 |ChildServerProcessing|------------+|| I +--------------------+ 1129 +---------------------+ FAIL vvv O | | 1130 | +-----+ N CANCEL | 1131 PROCESSING | |<---|-------+ PROCESSING 1132 v | | | v 1133 +------------------+ | | +------------------------+ 1134 |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | 1135 +------------------+ | A | +------------------------+ 1136 | | N | ^ | OFFER 1137 OFFER | C | | +------------------+ 1138 | | E | ::= 1280 ... 1281 ::= 1282 ... 1283 ::= 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 ::= ... 1298 ::= 1299 1300 1302 9.1.10. Information Elements 1304 An Information Element (IE) is an optional object which can be 1305 included in a CPNP message. 1307 9.1.10.1. Customer Description 1309 The client may include administrative information such as: 1311 o Name 1312 o Contact Information 1314 The format of this Information Element is as follows: 1316 ::= 1317 ::= [] 1318 [ ...] 1320 9.1.10.2. Provider Description 1322 The server may include administrative information in an offer such 1323 as: 1325 o Name 1326 o AS Number ([RFC6793]) 1327 o Contact Information 1329 The format of this Information Element is as follows: 1331 ::= [] 1333 9.1.10.3. Negotiation Options 1335 The client may include some negotiation options such as: 1337 o Cost: the client may include an empty or a preferred COST 1338 attribute to request the cost from the server. The server will 1339 provide the cost information in the response. 1340 o Setup purpose: A client may request to setup a connectivity only 1341 for testing purposes during a limited period. The order can be 1342 extended to become permanent if the client was satisfied during 1343 the test period. This operation is achieved using UPDATE method. 1345 Other negotiation options may be defined in the future. 1347 The format of this Information Element is as follows: 1349 ::= [][] 1351 9.2. Operation Messages 1353 This section specifies the RBNF format of CPNP operation messages. 1355 9.2.1. QUOTATION 1357 The format of the QUOTATION message is shown below: 1359 ::= 1360 1361 1362 1363 1364 [] 1365 1366 [...] 1368 A QUOTATION message must include an order identifier which is 1369 generated by the client. Because several orders can be issued to 1370 several servers, the QUOTATION message must also include a 1371 Transaction-ID. 1373 The message may include an EXPECTED_RESPONSE_TIME which indicates by 1374 when the client is expecting to receive an offer from the server. 1375 QUOTATION message must also include a requested connectivity 1376 provisioning document. 1378 When the client sends the QUOTATION message to the server, the state 1379 of the order changes to "PQOSent". 1381 9.2.2. PROCESSING 1383 The format of the PROCESSING message is shown below: 1385 ::= 1386 1387 1388 1389 1390 1391 [] 1393 Upon receipt of a QUOTATION message, the server proceeds with parsing 1394 rules (see Section 10). If no error is encountered, the server 1395 generates a PROCESSING response to the client to indicate the PQO has 1396 been received and it is being processed. The server must generate an 1397 order identifier which identifies the order in its local order 1398 repository. The server MUST copy the content of 1399 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed 1400 in the QUOTATION message. The server may include an 1401 EXPECTED_OFFER_TIME by when it expects to make an offer to the 1402 client. 1404 Upon receipt of a PROCESSING message, the client verifies whether it 1405 has issued a PQO to that server and which contains the 1406 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is 1407 found, the PROCESSING message is silently ignored. If a PQO is 1408 found, the client may check if it accepts the EXPECTED_OFFER_TIME and 1409 then, it changes to state of the order to "ServerProcessing". 1411 If more time is required by the server to process the quotation 1412 order, it may send a PROCESSING message that includes a new 1413 EXPECTED_OFFER_TIME. The client can answer with an ACK message if 1414 more time is granted (Figure 8) or with a FAIL message if the time 1415 extension is rejected (Figure 9). 1417 +------+ +------+ 1418 |Client| |Server| 1419 +------+ +------+ 1420 |=======QUOTATION(Requested CPD)=====>| 1421 |<========PROCESSING(time1)===========| 1422 ... 1423 |<========PROCESSING(MoreTime)========| 1424 |============ACK(TimeGranted)========>| 1425 ... 1426 |<=========OFFER(Offered CPD)=========| 1427 |=============PROCESSING=============>| 1428 |==========ACCEPT(Agreed CPD)========>| 1429 |<==========ACK(Agreed CPD)===========| 1431 Figure 8: Request more negotiation time: Granted 1433 +------+ +------+ 1434 |Client| |Server| 1435 +------+ +------+ 1436 |=======QUOTATION(Requested CPD)=====>| 1437 |<========PROCESSING(time1)===========| 1438 ... 1439 |<========PROCESSING(MoreTime)========| 1440 |===========FAIL(TimeRejected)=======>| 1442 Figure 9: Request more negotiation time: Rejected 1444 9.2.3. OFFER 1446 The format of the OFFER message is shown below: 1448 ::= 1449 1450 1451 1452 1453 1454 1455 1456 1457 [...] 1459 The server answers with an OFFER message to a QUOTATION request 1460 received from the client. The offer will be considered as rejected 1461 by the client if no confirmation (ACCEPT message sent by the client) 1462 is received by the server before the expiration of the validity time. 1464 9.2.4. ACCEPT 1466 The format of the ACCEPT message is shown below: 1468 ::= 1469 1470 1471 1472 1473 1474 1475 1476 [...] 1478 This message is used by a client to confirm the acceptance of an 1479 offer received from a server. The fields of this message are copied 1480 from the received OFFER message. 1482 9.2.5. ACK 1484 The format of the ACK message is shown below: 1486 ::= 1487 1488 1489 1490 1491 1493 [] 1494 [] 1495 [...] 1497 This message is issued by the server to close a CPNP transaction or 1498 by a client to grant more negotiation time to the server. 1500 This message is sent by the server as a response to an ACCEPT, 1501 WITHDRAW, DECLINE, or CANCEL message. In such case, the ACK message 1502 must include the copy of the Connectivity Provisioning Document as 1503 stored by the server, in particular: 1505 o A copy of the requested/offered CPD is included by the server if 1506 it successfully handled a CANCEL message. 1507 o A copy of the updated CPD is included by the server if it 1508 successfully handled an UPDATE message. 1509 o A copy of the offered CPD is included by the server if it 1510 successfully handled an ACCEPT message in the context of a 1511 QUOTATION transaction. 1512 o An empty CPD is included by the server if it successfully handled 1513 a DECLINE message. 1515 A client may issue an ACK message as a response to a more time 1516 request (conveyed in PROCESSING) received from the server. In such 1517 case, the ACK message must include an EXPECTED_RESPONSE_TIME that is 1518 likely to be set to the time extension requested by the server. 1520 9.2.6. DECLINE 1522 The format of the DECLINE message is shown below: 1524 ::= 1525 1526 1527 1528 1529 1530 1532 The client can issue a DECLINE message to reject an offer. 1533 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, 1534 TRANSACTION_ID, and NONCE are used by the server as keys to find the 1535 corresponding order. If an order matches, the server changes the 1536 state of this order to "Cancelled" and then returns an ACK with a 1537 copy of the requested CPD to the requesting client. 1539 If no order is found, the server returns a FAIL message to the 1540 requesting client. 1542 A flow example is shown in Figure 10. 1544 +------+ +------+ 1545 |Client| |Server| 1546 +------+ +------+ 1547 |=======QUOTATION(Requested CPD)=====>| 1548 |<============PROCESSING==============| 1549 |<=========OFFER(Offered CPD)=========| 1550 |=============PROCESSING=============>| 1551 |===============DECLINE==============>| 1552 |<================ACK=================| 1554 Figure 10: DECLINE Flow Example 1556 9.2.7. CANCEL 1558 The format of the CANCEL message is shown below: 1560 ::= 1561 1562 1563 1564 1565 [] 1567 The client can issue a CANCEL message at any stage during the CPNP 1568 negotiation process before an agreement is reached. 1569 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID are used by the 1570 server as keys to find the corresponding order. If a quotation order 1571 matches, the server changes the state of this quotation order to 1572 "Cancelled" and then returns an ACK with a copy of the requested CPD 1573 to the requesting client. 1575 If no quotation order is found, the server returns a FAIL message to 1576 the requesting client. 1578 9.2.8. WITHDRAW 1580 The format of the WITHDRAW message is shown below: 1582 ::= 1583 1584 1585 1586 1587 1588 1589 [] 1591 [...] 1593 This message is used to withdraw an offer already subscribed by the 1594 Customer. Figure 11 shows a typical usage of this message. 1596 +------+ +------+ 1597 |Client| |Server| 1598 +------+ +------+ 1599 |============WITHDRAW(CPD)===========>| 1600 |<============PROCESSING==============| 1601 |<===========ACK(Empty CPD)===========| 1603 Figure 11: WITHDRAW Flow Example 1605 The CPNP must include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1606 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1607 the order. 1609 Upon receipt of a WITHDRAW message, the server checks whether an 1610 order matching the request is found. If an order is found, the state 1611 of the order is changed to "Cancelled" and an ACK message including 1612 an Empty CPD is returned to the requesting client. If no order is 1613 found, the server returns a FAIL message to the requesting client. 1615 9.2.9. UPDATE 1617 The format of the UPDATE message is shown below: 1619 ::= 1620 1621 1622 1623 1624 1625 1626 1627 1628 [...] 1630 This message is sent by the CPNP client to update an existing 1631 connectivity provisioning agreement. The CPNP must include the same 1632 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1633 NONCE as those used when creating the order. The CPNP client 1634 includes a new CPD which integrates the requested modifications. A 1635 new Transaction_ID must be assigned by the client. 1637 Upon receipt of an UPDATE message, the server checks whether an 1638 order, having state "Completed", matches 1639 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1640 NONCE. 1642 o If no order is found, the CPNP server generates a FAIL error with 1643 the appropriate error code. 1644 o If an order is found, the server checks whether it can honor the 1645 request: 1647 * A FAIL message is sent to the client if the server cannot honor 1648 the request. The client may initiate a new PQO negotiation 1649 cycle. 1650 * An OFFER message including the updated connectivity 1651 provisioning document is sent to the client. For example, the 1652 server maintains an order for provisioning a VPN service that 1653 connects sites A, B and C. If the client sends an UPDATE 1654 message to remove site C, only sites A and B will be included 1655 in the OFFER sent by the server to the requesting client. 1657 A flow chart that illustrates the use of UPDATE operation is shown in 1658 Figure 12. 1660 +------+ +------+ 1661 |Client| |Server| 1662 +------+ +------+ 1663 |=========UPDATE(Requested CPD)======>| 1664 |<============PROCESSING==============| 1665 |<=========OFFER(Updated CPD)=========| 1666 |=============PROCESSING=============>| 1667 |==========ACCEPT(Updated CPD)=======>| 1668 |<==========ACK(Updated CPD)==========| 1670 Figure 12: UPDATE Flow Example 1672 9.2.10. FAIL 1674 The format of the FAIL message is shown below: 1676 ::= 1677 1678 1679 1680 1681 1682 1684 This message is sent in the following cases: 1686 o The server can not honor an order received from the client (i.e., 1687 received in a QUOTATION or UPDATE request). 1688 o The server encounters an error when processing a CPNP request 1689 received from the client. 1690 o The client can not grant more time to a the server. This is a 1691 response to a more time request conveyed in a PROCESSING message. 1693 The status code indicates the error code. The following codes are 1694 currently supported; other codes will be defined in future versions 1695 of the document: 1697 1 (Validation Error): The message can not be validated (see 1698 Section 10). 1699 2 (Authentication Required): the request cannot be handled because 1700 authentication is required. 1701 3 (Authorization Required): the request cannot be handled because 1702 authorization failed. 1703 4 (Administratively prohibited): the request can not be handled 1704 because of administrative policies. 1705 5 (Out of Resources): the request can not be honored because there 1706 is not enough capacity. 1707 6 (Network Presence): the request can not be honored because there 1708 is no network presence. 1709 7 (More Time Rejected): the request to extend the time negotiation 1710 is rejected by the client. 1712 10. Message Validation 1714 Both client and server proceed with CPNP message validation. The 1715 following tables summarize the validation checks to be followed. 1717 10.1. On the Client Side 1718 Operation Validation Checks 1719 ------------ -------------------------------------------------------- 1720 PROCESSING {Source IP address, source port, destination IP address, 1721 destination port, Transaction-ID, Customer Order 1722 Identifier} must match an existing PQO with a state set 1723 to "PQOSent". The sequence number carried in the packet 1724 must be larger than the sequence number maintained by 1725 the client. 1726 OFFER {Source IP address, source port, destination IP address, 1727 destination port, Transaction-ID, Customer Order 1728 Identifier} must match an existing order with state set 1729 to "PQOSent" or {Source IP address, source port, 1730 destination IP address, destination port, Transaction- 1731 ID, Customer Order Identifier, Provider Order 1732 Identifier} must match an existing order with a state 1733 set to "ServerProcessing". The sequence number carried 1734 in the packet must be larger than the sequence number 1735 maintained by the client. 1736 ACK {Source IP address, source port, destination IP address, 1737 (QUOTATION destination port, Transaction-ID, Customer Order 1738 Transaction) Identifier, Provider Order Identifier, Offered 1739 Connectivity Provisioning Order} must match an order 1740 with a state set to "AcceptSent". The sequence number 1741 carried in the packet must be larger than the sequence 1742 number maintained by the client. 1743 ACK (UPDATE {Source IP address, source port, destination IP address, 1744 Transaction) destination port, Transaction-ID, Customer Order 1745 Identifier, Provider Order Identifier, Updated 1746 Connectivity Provisioning Order} must match an order 1747 with a state set to "AcceptSent". The sequence number 1748 carried in the packet must be larger than the sequence 1749 number maintained by the client. 1750 ACK {Source IP address, source port, destination IP address, 1751 (WITHDRAW destination port, Transaction-ID, Customer Order 1752 Transaction) Identifier, Provider Order Identifier, Empty 1753 Connectivity Provisioning Order} must match an order 1754 with a state set to "Cancelled". The sequence number 1755 carried in the packet must be larger than the sequence 1756 number maintained by the client. 1758 10.2. On the Server Side 1759 Method Validation Checks 1760 ---------- ---------------------------------------------------------- 1761 QUOTATION The source IP address passes existing access filters (if 1762 any). The sequence number carried in the packet must not 1763 be less than the sequence number maintained by the server. 1764 PROCESSING The sequence number carried in the packet must be larger 1765 than the sequence number maintained by the server. 1766 ACCEPT {Source IP address, source port, destination IP address, 1767 destination port, Transaction-ID, Customer Order 1768 Identifier, Provider Order Identifier, Nonce, Offered 1769 Connectivity Provisioning Order} must match an order with 1770 state set to "OfferProposed" or "ProcessngReceived". The 1771 sequence number carried in the packet must be larger than 1772 the sequence number maintained by the server. 1773 DECLINE {Source IP address, source port, destination IP address, 1774 destination port, Transaction-ID, Customer Order 1775 Identifier, Provider Order Identifier, Nonce} must match 1776 an order with state set to "OfferProposed" or 1777 "ProcessngReceived". The sequence number carried in the 1778 packet must be larger than the sequence number maintained 1779 by the server. 1780 UPDATE The source IP address passes existing access filters (if 1781 any) and {Customer Order Identifier, Provider Order 1782 Identifier, Nonce} must match an existing order with state 1783 "Completed". 1784 WITHDRAW The source IP address passes existing access filters (if 1785 any) and {Customer Order Identifier, Provider Order 1786 Identifier, Nonce} must match an existing order with state 1787 "Completed". 1789 11. Theory of Operation 1791 Both CPNP client and server proceeds to message validation checks as 1792 specified in Section 10. 1794 11.1. Client Behavior 1796 11.1.1. Order Negotiation Cycle 1798 To place a provisioning quotation order, the client initiates first a 1799 local quotation order object identified by a unique identifier 1800 assigned by the client. The state of the quotation order is set to 1801 "Created". The client then generates a QUOTATION request which 1802 includes the assigned identifier, possibly an expected response time, 1803 a Transaction-ID and a Requested Connectivity Provisioning Document. 1804 The client may include additional Information Elements such as 1805 Negotiation Options. 1807 The client may be configured to not enforce negotiation checks on 1808 EXPECTED_OFFER_TIME; if so no EXPECTED_RESPONSE_TIME attribute (or 1809 EXPECTED_RESPONSE_TIME set to infinite) should be included in the 1810 quotation order. 1812 Once the request is sent to the server, the state of the request is 1813 set to "PQOSent" and a timer, if a response time is included in the 1814 quotation order, is set to the expiration time as included in the 1815 QUOTATION request. The client also maintains a copy of the extended 1816 transport session details used to generate the QUOTATION request. 1817 The CPNP client must listen on the same port number that it used to 1818 send the QUOTATION request. 1820 If no answer is received from the server before the retransmission 1821 timer expires (i.e., RETRANS_TIMER, Section 8.7), the client proceeds 1822 to retransmission until maximum retry is reached (i.e., 3 times). 1823 The same sequence number is used for retransmitted packets. 1825 If a FAIL message is received, the client may decide to issue another 1826 (corrected) request towards the same server, cancel the local order, 1827 or contact another server. The behavior of the client depends on the 1828 error code returned by the server in the FAIL message. 1830 If a PROCESSING message matching the CPNP transport session is 1831 received, the client updates the CPNP session with the 1832 PROVIDER_AGREEMENT_IDENTIFIER information. If the client does not 1833 accept the expected offer time that may have been indicated in the 1834 PROCESSING message, the client may decide to cancel the quotation 1835 order. If the client accepts the EXPECTED_OFFER_TIME, it changes the 1836 state of the order to "ServerProcessing" and sets a timer to the 1837 value of EXPECTED_OFFER_TIME. If no offer is made before the timer 1838 expires, the client changes the state of the order to "Cancelled". 1840 As a response to a more time request (conveyed in a PROCESSING 1841 message that included a new EXPECTED_OFFER_TIME), the client may 1842 grant this extension by issuing an ACK message or reject the time 1843 extension with a FAIL message having a status code set to "More Time 1844 Rejected". 1846 If an OFFER message matching the extended CPNP session is received, 1847 the client checks if a PROCESSING message having the same 1848 PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If 1849 a PROCESSING message was already received for the same order but the 1850 PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included 1851 in the OFFER message, the client ignores silently the message. If a 1852 PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was 1853 already received and matches the CPNP transaction identifier, the 1854 client changes the state of the order to "OfferReceived" and sets a 1855 timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER 1856 message. 1858 If an offer is received from the server (i.e., as documented in an 1859 OFFER message), the client may accept or reject the offer. The 1860 client accepts the offer by generating an ACCEPT message which 1861 confirms that the client agrees to subscribe to the offer documented 1862 in the OFFER message; the state of the order is passed to 1863 "AcceptSent". The transaction is terminated if an ACK message is 1864 received from the server. If no ACK is received from the server, the 1865 client proceeds with the re-transmission of the ACCEPT message. 1867 The client may also decide to reject the offer by sending a DECLINE 1868 message. The state of the order is set by the client to "Cancelled". 1869 If an offer is not acceptable by the client, the client may decide to 1870 contact a new server or submit another order to the same server. 1871 Guidelines to issue an updated order or terminate the negotiation are 1872 specific to the client. 1874 11.1.2. Order Withdrawal Cycle 1876 A client may withdraw a completed order. This is achieved by issuing 1877 a WITHDRAW message. This message must include Customer Order 1878 Identifier, Provider Identifier and Nonce returned during the order 1879 negotiation cycle specified in Section 11.1.1. 1881 If no ACK is received from the server, the client proceeds with the 1882 re-transmission of the message. 1884 11.1.3. Order Update Cycle 1886 A client may update a completed order. This is achieved by issuing 1887 an UPDATE message. This message must include Customer Order 1888 Identifier, Provider Order Identifier and Nonce returned during the 1889 order negotiation cycle specified in Section 11.1.1. The client must 1890 include in the UPDATE message an updated CPD with the requested 1891 changes. 1893 Subsequent messages exchange is similar to what is documented in 1894 Section 11.1.1. 1896 11.2. Server Behavior 1898 11.2.1. Order Processing 1900 Upon receipt of a QUOTATION message from a client, the server sets a 1901 CPNP session, stores Transaction-ID and generates a Provider Order 1902 Identifier. Once preliminary validation checks are completed ( 1903 Section 10), the server may return a PROCESSING message to notify the 1904 client the quotation order is received and it is under processing; 1905 the server may include an expected offer time to notify the client by 1906 when an offer will be proposed. An order with state 1907 "AwaitingProcessing" is created by the server. The server runs its 1908 decision-making process to decide which offer it can make to honor 1909 the received order. The offer should be made before the expected 1910 offer time expires. 1912 If the server cannot make an offer, it sends backs a FAIL message 1913 with the appropriate error code. 1915 If the server requires more negotiation time, it must send a 1916 PROCESSING message with a new EXPECTED_OFFER_TIME. The client may 1917 grant this extension by issuing an ACK message or reject the time 1918 extension with a FAIL message having a status code set to "More Time 1919 Rejected". If the client doesn't grant more time, the server must 1920 answer before the initial expected offer time; otherwise the client 1921 will ignore the quotation order. 1923 If the server can honor the request or it can make an offer that meet 1924 some of the requirements, it creates an OFFER message. The server 1925 must indicate the Transaction-ID, Customer Order Identifier as 1926 indicated in the QUOTATION message, and the Provider Order Identifier 1927 generated for this order. The server must also include Nonce and the 1928 offered Connectivity Provisioning Document. The server includes an 1929 offer validity time as well. Once sent to the client, the server 1930 changes the state of the order to "OfferSent" and a timer set to the 1931 validity time is initiated. 1933 If the server determines that additional network resources from 1934 another network provider are needed to accommodate a quotation order, 1935 it will create child PQO(s) and will behave as a CPNP client to 1936 negotiate child PQO(s) with possible partnering providers (see 1937 Figure 5). 1939 If no PROCESSING, ACCEPT or DECLINE message is received before the 1940 expiry of the RETRANS_TIMER, the server re-sends the same offer to 1941 the client. This procedure is repeated until maximum retry is 1942 reached. 1944 If an ACCEPT message is received before the offered validity time 1945 expires, the server proceeds with validation checks as specified in 1946 Section 10. The state of the corresponding order is passed to 1947 "AcceptReceived". The server sends back an ACK message to terminate 1948 the order processing cycle. 1950 If a CANCEL/DECLINE message is received, the server proceeds with the 1951 cancellation of the order. The state of the order is then passed to 1952 "Cancelled". 1954 11.2.2. Order Withdrawal 1956 A client may withdraw a completed order by issuing a WITHDRAW 1957 message. Upon receipt of a WITHDRAW message, the server proceeds 1958 with the validation checks, as specified in Section 10. 1960 o If the checks fail, a FAIL message is sent back to the client with 1961 the appropriate error code. 1963 o If the checks succeed, the server clears the clauses of the 1964 Connectivity Provisioning Document, changes the state of the order 1965 to "Cancelled", and sends back an ACK message with an Empty 1966 Connectivity Provisioning Document. 1968 11.2.3. Order Update 1970 A client may update an order by issuing an UPDATE message. Upon 1971 receipt of an UPDATE message, the server proceeds with the validation 1972 checks as specified in Section 10. 1974 o If the checks fail, a FAIL message is sent back to the client with 1975 the appropriate error code. 1976 o Subsequent messages exchange is similar to what is specified in 1977 Section 11.1.1. The server should generate a new Nonce value to 1978 be included in the offer made to the client. 1980 11.3. Sequence Numbers 1982 In each transaction, sequence numbers are used to protect the 1983 transaction against replay attacks. Each communicating partner of 1984 the transaction maintains two sequence numbers, one for incoming 1985 packets and one for outgoing packets. When a partner receives a 1986 message, it will check whether the sequence number in the message is 1987 larger than the incoming sequence number maintained locally. If not, 1988 the messages will be discarded. If the message is proved to be 1989 legal, the value of the incoming sequence number will be replaced by 1990 the value of the sequence number in the message. When a partner 1991 sends out a message, it will insert the value of outgoing sequence 1992 number into the message and increase the outgoing sequence number 1993 maintained locally by 1. 1995 11.4. Message Re-Transmission 1997 If a transaction partner sends out a message and does not receive any 1998 expected reply before the retransmission timer expires (i.e., 1999 RETRANS_TIMER), a transaction partner will try to re-transit the 2000 messages. An exception is the last message (e.g., ACK) sent from the 2001 server in a transaction. After sending this message, the 2002 retransmission timer will be disabled since no additional feedback is 2003 expected. 2005 In addition, if the partner receives a re-sent last incoming packet, 2006 the partner can also send out the answer to the incoming packet with 2007 a limited frequency. If no answer was generated at the moment, the 2008 partner needs to generate a PROCESSING message as the answer. 2010 To benefit message re-transmission, a partner could also store the 2011 last incoming packet and the associated answer. Note that the times 2012 of re-transmission could be decided by the local policy and re- 2013 transmission will not cause any change of sequence numbers. 2015 12. Operational Guidelines 2017 12.1. Logging on the CPNP Server 2019 The CPNP server SHOULD be configurable to log various events and 2020 associated information. Such information includes: 2022 o Client's IP Address 2023 o Any event change (e.g., new quotation order, offer sent, order 2024 confirm, order cancellation, order withdraw, etc.) 2025 o Timestamp 2027 12.2. Business Guidelines & Objectives 2029 The CPNP server can operate in the following modes: 2031 1. Fully automated mode: The CPNP server is provisioned with a set 2032 of business guidelines and objectives that will be used as an 2033 input to the decision-making process. The CPNP server will 2034 service received orders that falls into these business 2035 guidelines; otherwise requests will be escalated to an 2036 administrator that will formally validate/invalidate an order 2037 request. The set of policies to be configured to the CPNP server 2038 are specific to each administrative entity managing a CPNP 2039 server. 2041 2. Administrative-based mode: This mode assumes some or all CPNP 2042 server' operations are subject to a formal administrative 2043 validation. CPNP events will trigger appropriate validation 2044 requests that will be forwarded to the contact person(s) or 2045 department which is responsible for validating the orders. 2046 Administrative validation messages are relayed using another 2047 protocol (e.g., SMTP) or a dedicated tool. 2049 Business guidelines are local to each administrative entity. How 2050 validation requests are presented to an administrator are out of 2051 scope of this document; each administrative entity may decide the 2052 appropriate mechanism to enable for that purpose. 2054 13. Security Considerations 2056 Means to defend the server against denial-of-service attacks must be 2057 enabled. For example, access control lists (ACLs) can be enforced on 2058 the client, the server or the network in between, to allow a trusted 2059 client to communicate with a trusted server. 2061 The client and the server should be mutually authenticated. Out of 2062 band mechanisms can be used instead of integrating them into CPNP. 2064 The client must silently discard CPNP responses received from unknown 2065 CPNP servers. The use of a randomly generated Transaction-ID makes 2066 it hard to forge a response from a server with a spoofed IP address 2067 belonging to a legitimate CPNP server. Furthermore, CPNP demands 2068 that messages from the server must include correct identifiers of the 2069 orders. Two order identifiers are used: one generated by the client 2070 and a second one generated by the server. 2072 The Provider must enforce means to protect privacy-related 2073 information included the documents (see Section 8.9) exchanged using 2074 CPNP messages [RFC6462]. In particular, this information must not be 2075 revealed to external parties without the consent of Customers. 2076 Providers should enforce policies to make Customer fingerprinting 2077 difficult to achieve. For more discussion about privacy, refer to 2078 [RFC6462][RFC6973]. 2080 The NONCE and the Transaction ID attributes provide sufficient 2081 randomness and can effectively tolerate attacks raised by off-line 2082 adversaries, who do not have the capability of eavesdropping and 2083 intercepting the packets transported between the client and the 2084 server. Only authorized clients must be able to modify agreed CPNP 2085 orders. The use of a randomly generated NONCE by the server makes it 2086 hard to modify an agreement on behalf of a malicious third-party. 2088 The sequence numbers included in the CPNP messages can be used to 2089 detect replay attacks and antique packets intercepted from on-going 2090 transactions may be re-sent. However, the protocol in its current 2091 version may be vulnerable to replay attacks where the replayed 2092 messages are intercepted from antique transactions. Although the 2093 Transaction ID provided by the client could protect inter-transaction 2094 replay attacks, no protection is provided for the server to deal with 2095 this type of attack. 2097 The protocol does not provide security mechanisms to protect the 2098 confidentiality and integrity of the packets transported between the 2099 client and the server. An underlying security protocol such as 2100 (e.g., DTLS [RFC6347], IPsec) could be used to protect the integrity 2101 and confidentiality for the protocol. In this case, if it is 2102 possible to provide an Automated Key Management (AKM) and associate 2103 each transaction with a different key, inter- transaction replay 2104 attacks can naturally be addressed. If the client and the server use 2105 a single key, an additional mechanism should be provided to protect 2106 inter-transaction replay attacks between them. 2108 The deployment option of a Customer Order Management portal operated 2109 by a trusted third-party (see Section 6) may facilitate the efficient 2110 resolution of the aforementioned security concerns. 2112 14. IANA Considerations 2114 Authors of the document request IANA to assign a UDP port for CPNP. 2116 A registry for CPNP methods should be created. The following codes 2117 are reserved: 2119 1: QUOTATION 2120 2: PROCESSING 2121 3: OFFER 2122 4: ACCEPT 2123 5: DECLINE 2124 6: ACK 2125 7: CANCEL 2126 8: WITHDRAW 2127 9: UPDATE 2128 10: FAIL 2130 A registry for CPNP errors should be created. The following codes 2131 are reserved: 2133 1: Message Validation Error 2134 2: Authentication Required 2135 3: Authorization Failed 2136 4: Administratively prohibited 2137 5: Out of Resources 2138 6: Network Presence Error 2139 7: More Time Rejected 2141 15. Acknowledgements 2143 Thanks to Diego R. Lopez for his comments. 2145 16. References 2147 16.1. Normative References 2149 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2150 and Support", STD 3, RFC 1123, October 1989. 2152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2153 Requirement Levels", BCP 14, RFC 2119, March 1997. 2155 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2156 Requirements for Security", BCP 106, RFC 4086, June 2005. 2158 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2159 Used to Form Encoding Rules in Various Routing Protocol 2160 Specifications", RFC 5511, April 2009. 2162 16.2. Informative References 2164 [ETICS] EU FP7 ETICS Project, "Economics and Technologies of 2165 Inter-Carrier Services", January 2014, . 2169 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2170 specifying the location of services (DNS SRV)", RFC 2782, 2171 February 2000. 2173 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2174 Private Network (VPN) Terminology", RFC 4026, March 2005. 2176 [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and 2177 A. Gonguet, "Framework for Layer 3 Virtual Private 2178 Networks (L3VPN) Operations and Management", RFC 4176, 2179 October 2005. 2181 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2182 Security Version 1.2", RFC 6347, January 2012. 2184 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 2185 RFC 6462, January 2012. 2187 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 2188 Workshop", RFC 6574, April 2012. 2190 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 2191 K., and G. Watson, "Use Cases for Content Delivery Network 2192 Interconnection", RFC 6770, November 2012. 2194 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 2195 Autonomous System (AS) Number Space", RFC 6793, December 2196 2012. 2198 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2199 Morris, J., Hansen, M., and R. Smith, "Privacy 2200 Considerations for Internet Protocols", RFC 6973, July 2201 2013. 2203 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 2204 Networking: A Perspective from within a Service Provider 2205 Environment", RFC 7149, March 2014. 2207 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 2208 Connectivity Provisioning Profile (CPP)", RFC 7297, July 2209 2014. 2211 Authors' Addresses 2213 Mohamed Boucadair 2214 France Telecom 2215 Rennes 35000 2216 France 2218 Email: mohamed.boucadair@orange.com 2220 Christian Jacquenet 2221 France Telecom 2222 Rennes 35000 2223 France 2225 Email: christian.jacquenet@orange.com 2227 Dacheng Zhang 2228 Huawei Technologies 2230 Email: zhangdacheng@huawei.com 2231 Panos Georgatsos 2232 Centre for Research and Innovation Hellas 2233 78, Filikis Etairias str. 2234 Volos, Hellas 38334 2235 Greece 2237 Phone: +302421306070 2238 Email: pgeorgat@iti.gr