idnits 2.17.1 draft-boucadair-connectivity-provisioning-protocol-16.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2019) is 1680 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 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: Informational Orange 5 Expires: March 22, 2020 D. Zhang 6 Huawei Technologies 7 P. Georgatsos 8 CERTH 9 September 19, 2019 11 Connectivity Provisioning Negotiation Protocol (CPNP) 12 draft-boucadair-connectivity-provisioning-protocol-16 14 Abstract 16 This document specifies the Connectivity Provisioning Negotiation 17 Protocol (CPNP) which is designed for dynamic negotiation of service 18 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 footprint, etc. The protocol can be extended with 24 new Information Elements. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 22, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. CPNP Functional Elements . . . . . . . . . . . . . . . . . . 6 63 4. Order Processing Models . . . . . . . . . . . . . . . . . . . 6 64 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 65 6. CPNP Deployment Models . . . . . . . . . . . . . . . . . . . 10 66 7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 11 67 8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 68 8.1. Client/Server Communication . . . . . . . . . . . . . . . 13 69 8.2. Policy Configuration on the CPNP Server . . . . . . . . . 14 70 8.3. CPNP Session Entries . . . . . . . . . . . . . . . . . . 16 71 8.4. CPNP Transaction . . . . . . . . . . . . . . . . . . . . 16 72 8.5. CPNP Timers . . . . . . . . . . . . . . . . . . . . . . . 17 73 8.6. CPNP Operations . . . . . . . . . . . . . . . . . . . . . 17 74 8.7. Connectivity Provisioning Documents . . . . . . . . . . . 19 75 8.8. Child Provisioning Quotation Orders . . . . . . . . . . . 20 76 8.9. Negotiating with Multiple CPNP Servers . . . . . . . . . 21 77 8.10. State Management . . . . . . . . . . . . . . . . . . . . 21 78 8.10.1. On the Client Side . . . . . . . . . . . . . . . . . 22 79 8.10.2. On the Server Side . . . . . . . . . . . . . . . . . 24 80 9. CPNP Objects . . . . . . . . . . . . . . . . . . . . . . . . 26 81 9.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 26 82 9.1.1. CUSTOMER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 26 83 9.1.2. PROVIDER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 26 84 9.1.3. TRANSACTION_ID . . . . . . . . . . . . . . . . . . . 27 85 9.1.4. SEQUENCE_NUMBER . . . . . . . . . . . . . . . . . . . 27 86 9.1.5. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 27 87 9.1.6. EXPECTED_RESPONSE_TIME . . . . . . . . . . . . . . . 27 88 9.1.7. EXPECTED_OFFER_TIME . . . . . . . . . . . . . . . . . 27 89 9.1.8. VALIDITY_OFFER_TIME . . . . . . . . . . . . . . . . . 28 90 9.1.9. CONNECTIVITY_PROVISIONING_DOCUMENT . . . . . . . . . 28 91 9.1.10. CPNP Information Elements . . . . . . . . . . . . . . 28 92 9.2. Operation Messages . . . . . . . . . . . . . . . . . . . 30 93 9.2.1. QUOTATION . . . . . . . . . . . . . . . . . . . . . . 30 94 9.2.2. PROCESSING . . . . . . . . . . . . . . . . . . . . . 30 95 9.2.3. OFFER . . . . . . . . . . . . . . . . . . . . . . . . 32 96 9.2.4. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . 32 97 9.2.5. DECLINE . . . . . . . . . . . . . . . . . . . . . . . 33 98 9.2.6. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 9.2.7. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 34 100 9.2.8. WITHDRAW . . . . . . . . . . . . . . . . . . . . . . 35 101 9.2.9. UPDATE . . . . . . . . . . . . . . . . . . . . . . . 35 102 9.2.10. FAIL . . . . . . . . . . . . . . . . . . . . . . . . 37 103 10. CPNP Message Validation . . . . . . . . . . . . . . . . . . . 38 104 10.1. On the Client Side . . . . . . . . . . . . . . . . . . . 38 105 10.2. On the Server Side . . . . . . . . . . . . . . . . . . . 39 106 11. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 39 107 11.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 39 108 11.1.1. Order Negotiation Cycle . . . . . . . . . . . . . . 39 109 11.1.2. Order Withdrawal Cycle . . . . . . . . . . . . . . . 41 110 11.1.3. Order Update Cycle . . . . . . . . . . . . . . . . . 41 111 11.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 42 112 11.2.1. Order Processing . . . . . . . . . . . . . . . . . . 42 113 11.2.2. Order Withdrawal . . . . . . . . . . . . . . . . . . 43 114 11.2.3. Order Update . . . . . . . . . . . . . . . . . . . . 43 115 11.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 43 116 11.4. Message Re-Transmission . . . . . . . . . . . . . . . . 44 117 12. Some Operational Guidelines . . . . . . . . . . . . . . . . . 44 118 12.1. Logging on the CPNP Server . . . . . . . . . . . . . . . 44 119 12.2. Business Guidelines & Objectives . . . . . . . . . . . . 44 120 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 121 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 122 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 123 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 124 16.1. Normative References . . . . . . . . . . . . . . . . . . 46 125 16.2. Informative References . . . . . . . . . . . . . . . . . 47 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 128 1. Introduction 130 This document defines the Connectivity Provisioning Negotiation 131 Protocol (CPNP) that is meant to dynamically exchange and negotiate 132 connectivity provisioning parameters, and other service-specific 133 parameters, between a Customer and a Provider. CPNP is a tool that 134 introduces automation in the service negotiation and activation 135 procedures, thus fostering the overall service provisioning process. 136 CPNP can be seen as a component of the dynamic negotiation meta- 137 domain described in Section 3.4 of [RFC7149]. 139 CPNP is a generic protocol that can be used for other negotiation 140 purposes than connectivity provisioning. For example, CPNP can be 141 used to request extra storage resources, to extend the footprint of a 142 CDN (Content Delivery Networks), to enable additional features from a 143 cloud Provider, etc. CPNP can be extended with new Information 144 Elements (IEs). 146 [RFC7297] describes a Connectivity Provisioning Profile (CPP) 147 template to capture connectivity requirements to be met by a 148 transport infrastructure for the delivery of various services such as 149 Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) 150 services [RFC4026]. The CPP document defines the set of IP transfer 151 parameters that reflect the guarantees that can be provided by the 152 underlying transport network together with reachability scope and 153 capacity needs. CPNP uses the CPP template to encode connectivity 154 provisioning clauses. 156 As a reminder, several proposals have been made in the past by the 157 (research) community (e.g., COPS-SLS, Service Negotiation Protocol 158 (SrNP), Dynamic Service Negotiation Protocol (DSNP), Resource 159 Negotiation and Pricing Protocol (RNAP), Service Negotiation and 160 Acquisition Protocol (SNAP), etc.). It is out of the scope of this 161 document to elaborate on the differences between CPNP and the 162 aforementioned proposals. 164 This document is organized as follows: 166 o Section 3 defines the functional elements involved in CPNP 167 exchanges. 168 o Section 4 introduces several order processing models and precises 169 those that are targeted by CPNP. 170 o Section 5 enumerates a non-exhaustive list of use cases that could 171 benefit from CPNP. 172 o Section 5 discusses CPNP deployment models. 173 o Section 7 presents the CPNP negotiation model. 174 o Section 8 provides an overview of the protocol. 175 o Section 9 specifies the CPNP objects. 176 o Section 10 describes the CPNP message validation procedure. 177 o Section 11 specifies the behavior of the involved CPNP functional 178 elements. 179 o Section 12 discusses relevant operational guidelines. 180 o Section 13 discusses protocol security aspects. 182 2. Terminology 184 This document makes use of the following terms: 186 Customer: Is a business role which denotes an entity that is 187 involved in the definition and the possible negotiation of a 188 contract, including a Connectivity Provisioning Agreement, with a 189 Provider. A connectivity provisioning contract is captured in a 190 dedicated CPP template-based document, which specifies (among 191 other information): the sites to be connected, border nodes, 192 outsourced operations (e.g., routing, force via points). 194 The right to invoke the subscribed service may be delegated by the 195 Customer to third-party End Users, or brokering services. 197 A Customer can be a Service Provider, an application owner, an 198 enterprise, a user, etc. 200 Network Provider (or Provider): Owns and administers one or many 201 transport domain(s) (typically Autonomous System (AS)) composed of 202 IP switching and transmission resources (e.g., routing, switching, 203 forwarding, etc.). Network Providers are responsible for ensuring 204 connectivity services (e.g., offering global or restricted 205 reachability at specific rates). Offered connectivity services 206 may not necessarily be restricted to IP. 208 The policies to be enforced by the connectivity service delivery 209 components can be derived from the technology-specific clauses 210 that might be included in contracts agreed with the Customers. If 211 no such clauses are included in the agreement, the mapping between 212 the connectivity requirements and the underlying technology- 213 specific policies to be enforced is deployment-specific. 215 Quotation Order: Denotes a request made by the Customer to the 216 Provider that includes a set of requirements. The Customer may 217 express its service-specific requirements by assigning (fixed or 218 loosely defined) values to the information items included in the 219 commonly understood template (e.g., CPP template) describing the 220 offered service. These requirements constitute the parameters to 221 be mutually agreed upon. 223 Offer: Refers to a response made by the Provider to a Customer 's 224 quotation order as to the extent at which the Provider may satisfy 225 the order at the time of its receipt. Offers reflect the 226 capability of the Provider in accommodating received Customer 227 orders beyond monolithic 'yes/no' answers. 229 An offer may fully or partially meet the requirements of the 230 corresponding order. In the latter case, it may include 231 alternative suggestions which the Customer may take into account 232 by issuing a new order. 234 Agreement: Refers to an order placed by the Customer and accepted by 235 the Provider. It signals the successful conclusion of a 236 negotiation cycle. 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 240 "OPTIONAL" in this document are to be interpreted as described in BCP 241 14 [RFC2119][RFC8174] when, and only when, they appear in all 242 capitals, as shown here. 244 3. CPNP Functional Elements 246 The following functional elements are defined: 248 CPNP client (or client): Denotes a software instance that sends 249 CPNP requests and receives CPNP responses. The current operations 250 that can be performed by a CPNP client are listed below: 252 1. Create a quotation order (Section 9.2.1). 254 2. Cancel an ongoing quotation order under negotiation 255 (Section 9.2.7). 257 3. Accept an offer made by a server (Section 9.2.4). 259 4. Withdraw an agreement (Section 9.2.8). 261 5. Update an agreement (Section 9.2.9). 263 CPNP server (or server): Denotes a software instance that receives 264 CPNP requests and sends back CPNP responses accordingly. The CPNP 265 server is responsible for the following operations: 267 1. Process a quotation order (Section 9.2.2). 269 2. Make an offer (Section 9.2.3). 271 3. Cancel an ongoing quotation order (Section 11.2.3). 273 4. Process an order withdrawal (Section 11.2.3). 275 4. Order Processing Models 277 For preparing their service orders, the Customers may need to be 278 aware of the offered services. The Providers therefore should first 279 proceed with the announcement of the services that they can provide. 280 The service announcement process may take place at designated global 281 or Provider-specific service markets, or through explicit 282 interactions with the Providers. The details of this process are 283 outside the scope of a negotiation protocol. 285 With or without such service announcement mechanisms in place, the 286 following order processing models can be distinguished: 288 Frozen model: 290 The Customer cannot actually negotiate the parameters of the 291 service(s) offered by a Provider. After consulting the Provider's 292 service portfolio, the Customer selects the service offer he/she 293 wants to subscribe and places an order to the Provider. Order 294 handling is quite simple on the Provider side because the service 295 is not customized as per Customer's requirements, but rather pre- 296 designed to target a group of customers having similar 297 requirements (i.e., these customers share the same Customer 298 Provisioning Profile). 300 Negotiation-based model: 302 Unlike the frozen model, the Customer documents his/her 303 requirements in a request for a quotation, which is then sent to 304 one or several Providers. Solicited Providers check whether they 305 can address these requirements or not, and get back to the 306 Customer accordingly, possibly with an offer that may not exactly 307 match customer's requirements (e.g., a 100 Mbps connection cannot 308 be provisioned given the amount of available resources, but an 80 309 Mbps connection can be provided). A negotiation between the 310 Customer and the Provider(s) then follows to the end of reaching 311 an agreement. 313 Both frozen and negotiation-based models require the existence of 314 appropriate service templates like a CPP template and their 315 instantiation for expressing specific offerings from Providers and 316 service requirements from Customers, respectively. CPNP can be used 317 in either model for automating the required Customer-Provider 318 interactions. Since the frozen model can be seen as a special case 319 of the negotiation-based model, not only 'yes/no' answers but also 320 counter offers may be issued by the Provider in response to Customer 321 orders, this document focuses on the negotiation-based model. 323 Order processing management on the Network Provider's side is usually 324 connected with the following functional blocks: 326 o Network Provisioning (including Order Activation, Network 327 Planning, etc.) 328 o Authentication, Authorization and Accounting (AAA) 329 o Network and service management (performance verification, 330 complaint analysis, etc.) 331 o Sales-related functional blocks (e.g., billing, invoice 332 validation) 334 o Network Impact Analysis 336 CPNP does not assume any specific knowledge about these functional 337 blocks, drawing an explicit line between protocol operation and the 338 logic for handling connectivity provisioning requests. Evidently 339 order handling logic is subject to the information manipulated by 340 these blocks. For example, the resources that can be allocated to 341 accommodate Customer's requirements may depend on network 342 availability estimates as calculated by the planning functions and 343 related policies as well as on the number of orders to be processed 344 simultaneously over a given period of time. 346 This document does not elaborate on how Customers are identified and 347 subsequently managed by the Provider's Information System. 349 5. Sample Use Cases 351 A non-exhaustive list of CPNP use cases is provided below: 353 1. [RFC4176] introduces the L3VPN Service Order Management 354 functional block which is responsible for managing the requests 355 initiated by the Customers and tracks the status of the 356 completion of the related operations. CPNP can be used between 357 the Customer and the Provider to negotiate L3VPN service 358 parameters. 360 A CPNP server could therefore be part of the L3VPN Service Order 361 Management functional block discussed in [RFC4176]. A YANG data 362 model for L3VPN service delivery is defined in [RFC8049]. 364 2. CPNP can be used between two adjacent domains to deliver IP 365 interconnection services (e.g., enable, update, disconnect). 366 For example, two Autonomous Systems (ASes) can be connected via 367 several interconnection points. CPNP can be used between these 368 ASes to upgrade existing links, request additional resources, 369 provision a new interconnection point, etc. 371 See, for example, the framework documented in [ETICS]. 373 3. An integrated Provider can use CPNP to rationalize connectivity 374 provisioning needs related to its service portfolio. A CPNP 375 server function is used by network operations teams. A CPNP 376 interface to invoke CPNP negotiation cycles is exposed to 377 service management teams. 379 4. Service Providers can use CPNP to initiate connectivity 380 provisioning requests towards a number of Network Providers so 381 that to optimize the cost of delivering their services. 383 Although multiple CPNP ordering cycles can be initiated by a 384 Service Provider towards multiple Network Providers, a subset of 385 these orders may actually be put into effect. 387 For example, a cloud Service Provider can use CPNP to request 388 more resources from Network Providers. 390 5. CPNP can also be used in the context of network slicing 391 ([I-D.geng-netslices-architecture]) to request for network 392 resources together with a set of requirements that need to be 393 satisfied by the Provider. Such requirements are not restricted 394 to basic IP forwarding capabilities, but may also include a 395 characterization of a set of service functions that may be 396 invoked. 398 6. CPNP can be used in Machine-to-Machine (M2M) environments to 399 dynamically subscribe to M2M services (e.g., access to data 400 retrieved by a set of sensors, extend sensor coverage, etc.). 402 Also, Internet of Things (IoT, [RFC6574]) domains may rely on 403 CPNP to enable dynamic provisioning of data produced by involved 404 objects, according to their specific policies, to various 405 external stakeholders such as data analytics and business 406 intelligence companies. Direct CPNP-based interactions between 407 IoT domains and interested parties enable open access to diverse 408 sets of data across the Internet, e.g., from multiple types of 409 sensors, user groups and/or geographical areas. 411 7. CPNP can be used in the context of I2NSF ([RFC8329]) to capture 412 the customer-driven policies to be enforced by a set of Network 413 Security Functions. 415 8. A Provider offering cloud services can expose a CPNP interface 416 to allow Customers to dynamically negotiate related service 417 features such as additional storage, processing and networking 418 resources, enhanced security filters, etc. 420 9. In the inter-cloud context (also called cloud of clouds or cloud 421 federation), CPNP can be used to reserve external computing and 422 networking resources in other cloud environments. 424 10. CDN Providers can use CPNP to extend their footprint by 425 interconnecting their CDN infrastructure [RFC6770] (see 426 Figure 1). 428 ,--,--,--. ,--,--,--. 429 ,-' `-. ,-' `-. 430 (CDN Provider 'A')=====(CDN Provider 'B') 431 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 432 `--'--'--' `--'--'--' 434 Figure 1: CDN Interconnection 436 11. Mapping Service Providers (MSPs, [RFC7215]) can use CPNP to 437 enrich their mapping database by interconnecting their mapping 438 system (see Figure 2). This interconnection allows to relax the 439 constraints on PxTR in favour of native LISP forwarding 440 [RFC6830]. Also, it allows to prevent fragmented LISP mapping 441 database. A framework is described in 442 [I-D.boucadair-lisp-idr-ms-discovery]. 444 ,--,--,--. ,--,--,--. 445 ,-' `-. ,-' `-. 446 (Mapping System 'A')===(Mapping System 'B') 447 `-. ,-' `-. ,-' 448 `--'--'--' `--'--'--' 450 Figure 2: LISP Mapping System Interconnect 452 CPNP may also be used between SDN controllers in contexts where 453 Cooperating Layered Architecture for Software-Defined Networking 454 (CLAS) is enabled [RFC8597]. 456 6. CPNP Deployment Models 458 Several CPNP deployment models can be envisaged. Two examples are 459 listed below: 461 o The Customer deploys a CPNP client while one or several CPNP 462 servers are deployed by the Provider. 463 o The Customer does not enable any CPNP client. The Provider 464 maintains a Customer Order Management portal. The Customer can 465 initiate connectivity provisioning quotation orders via the 466 portal; appropriate CPNP messages are then generated and sent to 467 the relevant CPNP server. In this model, both the CPNP client and 468 CPNP server are under the responsibility of the same 469 administrative entity (i.e., Network Provider). 471 Once the negotiation of connectivity provisioning parameters is 472 successfully concluded that is, an order has been placed by the 473 Customer, the actual network provisioning operations are initiated. 475 The specification of related dynamic resource allocation and policy 476 enforcement schemes, as well as how CPNP servers interact with the 477 network provisioning functional blocks at Provider sides are out of 478 the scope of this document. 480 This document does not make any assumption about the CPNP deployment 481 model either. 483 7. CPNP Negotiation Model 485 CPNP runs between a Customer and a Provider carrying service orders 486 from the Customer and respective responses from the Provider to the 487 end of reaching a connectivity service provisioning agreement. As 488 the services offered by the Provider are well-described, by means of 489 the CPP template, the negotiation process is essentially a value- 490 settlement process, where an agreement is pursued on the values of 491 the commonly understood information items (service parameters) 492 included in the service description template. 494 The protocol is transparent to the content that it carries and to the 495 negotiation logic, at Customer and Provider sides, that manipulates 496 the content. 498 The protocol aims at facilitating the execution of the negotiation 499 logic by providing the required generic communication primitives. 501 Since negotiations are initiated and primarily driven by the 502 Customer's negotiation logic, it is reasonable to assume that the 503 Customer can only call for an agreement. An implicit approach is 504 adopted for not overloading the protocol with additional messages. 505 In particular, the acceptance of an offer made by the Provider 506 signals a call for agreement from the Customer. Note that it is 507 almost certain the Provider to accept this call since it refers to an 508 offer that itself made. Of course, at any point the Provider or the 509 Customer may quit the negotiations, each on its own grounds. 511 Based on the above, CPNP adopts a Quotation Order/Offer/Answer model, 512 which proceeds through the following basic steps: 514 1. The client specifies its service requirements via a Provision 515 Quotation Order (PQO). The order may include fixed or loosely 516 defined values in the clauses describing service provisioning 517 characteristics. 519 2. The server declines the PQO, or makes an offer to address the 520 requirements of the PQO, or which may suggests a counter- 521 proposals that partially addresses the requirements of the PQO 522 for specific requirements that cannot be accommodated. 524 3. The client either accepts or declines the offer. Accepting the 525 offer implies a call for agreement. 527 Multiple instances of CPNP may run at Customer or Provider domains. 528 A CPNP client may be engaged simultaneously in multiple negotiations 529 with the same or different CPNP servers (parallel negotiations, see 530 Section 8.9) and a CPNP server may need to negotiate with other 531 Provider(s) as part of negotiations with a CPNP client (cascaded 532 negotiations, see Section 8.8). 534 CPNP relies on various timers to achieve its operations. These 535 timers are used to guide the negotiation logic at both CPNP client 536 and CPNP server sides, particularly in cases where the CPNP client is 537 involved in parallel negotiations with several CPNP servers or in 538 cases where the CPNP server is, in its turn, involved in negotiations 539 with other Providers for processing a given quotation order. Related 540 to the above, CPNP allows the CPNP server to request for more time. 541 This request may be accepted or rejected by the CPNP client. 543 Providers may need to publish available services to the Customers 544 (see Section 4). CPNP may optionally support this functionality. 545 Dedicated templates can be defined for the purpose of service 546 announcements, which will be used by the CPNP clients to initiate 547 their CPNP negotiation cycles. 549 For simplicity, a single Offer/Answer stage is assumed within one a 550 CPNP negotiation cycle. Nevertheless, as stated before, multiple 551 CPNP negotiation cycles can be undertaken by a CPNP client (see 552 Figure 3). 554 The model is flexible as it can accommodate changing conditions over 555 time (e.g., introduction of an additional VPN site). 557 +------+ +------+ +------+ +------+ 558 |Client| |Server| |Client| |Server| 559 +------+ +------+ +------+ +------+ 560 |=====Quotation Order=====>| |=====Quotation Order=====>| 561 |<==========Offer==========| |<==========Offer==========| 562 |===========Accept========>| |==========Decline========>| 564 1-Step Successful Negotiation 1-Step Failed Negotiation 565 Cycle Cycle 567 +------+ +------+ +------+ +------+ 568 |Client| |Server| |Client| |Server| 569 +------+ +------+ +------+ +------+ 570 |===Quotation Order(a)====>| |===Quotation Order(i)====>| 571 |<==========Offer==========| |<==========Offer==========| 572 |==========Decline========>| |==========Decline========>| 573 |===Quotation Order(b)====>| |===Quotation Order(j)====>| 574 |<==========Offer==========| |<==========Offer==========| 575 |===========Accept========>| |==========Decline========>| 576 |===Quotation Order(k)====>| 577 |<==========Offer==========| 578 |==========Decline========>| 579 |===Quotation Order(l)====>| 580 |<==Fail to make an offer==| 582 N-Step Negotiation Cycle: N-Step Negotiation Cycle: 583 Successful Negotiation Failed Negotiation 585 Figure 3: Overall Negotiation Process 587 This version of the protocol does not support means for a client to 588 retrieve a list of active/agreed offers. 590 8. Protocol Overview 592 8.1. Client/Server Communication 594 CPNP is a client/server protocol can run over any transport protocol 595 with UDP being the default transport mode secured with Datagram 596 Transport Layer Security (DTLS) [RFC6347]. No permanent CPNP 597 transport session needs to be maintained between the client and the 598 server. 600 The CPNP client can be configured with the CPNP server(s) (typically, 601 an IP address together with a port number) using manual or dynamic 602 configuration means. For example, a Provider advertises the port 603 number (CPNP_PORT) it uses to bind the CPNP service (e.g., using SRV 604 [RFC2782]). 606 The client sends CPNP messages to CPNP_PORT. The same port number 607 used as the source port number of a CPNP request sent to the server 608 MUST be used by the server to reply to that request. 610 CPNP is independent of the IP address family. 612 CPNP retransmission is discussed in Section 11.4. 614 8.2. Policy Configuration on the CPNP Server 616 As an input to its decision-making process, the CPNP server may be 617 connected to various external modules such as: Customer Profiles, 618 Network Topology, Network Resource Management, Orders Repository, AAA 619 and Network Provisioning Manager (an example is shown in Figure 4). 621 These external modules provide inputs to the CPNP server, so that it 622 can: 624 o Check whether a customer is entitled to initiate a provisioning 625 quotation request. 627 o Check whether a customer is entitled to cancel an on-going order. 629 o Check whether administrative data (e.g., billing-related 630 information) have been verified before starting handling the 631 request. 633 o Check whether network capacity is available or additional capacity 634 is required. 636 o Receive guidelines from network design and sales blocks (e.g., 637 pricing, network usage levels, threshold on number of CPP 638 templates that can be processed over a given period of time as a 639 function of the nature of the service to be delivered, etc.). 641 o Transfer completed orders to network provisioning blocks. For 642 example, the outcome of CPNP may be passed to modules such as 643 Application-Based Network Operations (ABNO) [RFC7491] or network 644 controllers. 646 The above list of CPNP server operations is not exhaustive. 648 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 .Business & Administrative Management . 650 .+------------------------++---------------------------+. 651 .| Business Guidelines || Billing & Charging |. 652 .+-----------+------------++-----------+---------------+. 653 . | | . 654 . +-------------------+ | . 655 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 656 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 657 .Order Handling Management | | . 658 . +-------------------+ +-------+-----+--------------+ . 659 . |Network Topology DB+--+ CPNP Server | . 660 . +-------------------+ +-+---+---+---+---+-----+----+ . 661 . | | | | | | . 662 . +------------------------+-+ | | | | | . 663 . | Network Dimensioning | | | | | | . 664 . | & Planning | | | | | | . 665 . +--------------------------+ | | | | | . 666 . +----------------------------+-+ | | | +---+----+ . 667 . | | | | | | AAA | . 668 . | Network +------------+ | | | +--------+ . 669 . | Resource | +------------+-+ | +-+----------+ . 670 . | Management | | Customer | | | Orders | . 671 . | | | Profiles | | | Repository | . 672 . +-----------------+ +--------------+ | +------------+ . 673 . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . 674 +--------------------------------------+----------------+ 675 | Network Provisioning Manager | 676 +-------------------------------------------------------+ 678 Figure 4: Order Handling Management Functional Block 680 The following order handling modes can be also configured on the 681 server: 683 1. Fully automated mode: This mode does not require any action from 684 the administrator when receiving a request for a service. The 685 server can execute its decision-making process related to the 686 orders received and generate corresponding offers. 688 2. Administrative validation checking: Some or all of the server's 689 operations are subject to administrative validation procedures. 690 This mode requires an action from the administrator for every 691 request received. The CPNP methods which can be automatically 692 handled by the server or they are subject to one or several 693 validation administrative checks can be configured on the server. 695 8.3. CPNP Session Entries 697 A CPNP session entry is denoted by a 5-uplet defined as follows: 699 o Transport session (typically, IP address of the client, client's 700 port number, IP address of the server, and server's port number). 702 o Incremented Sequence Number (Section 11.3) 704 o Customer Agreement Identifier: This is a unique identifier 705 assigned to the order under negotiation by the client 706 (Section 9.1.1). This identifier is also used to identify the 707 agreement that will result from a successful negotiation. 709 o Provider Agreement Identifier: This is a unique identifier 710 assigned to the order under negotiation by the server 711 (Section 9.1.2). This identifier is also used to identify the 712 agreement that will result from a successful negotiation. 714 o Transaction-ID (Section 9.1.3). 716 8.4. CPNP Transaction 718 A CPNP transaction occurs between a client and a server for pursuing, 719 modifying, withdrawing a service agreement, and comprises all CPNP 720 messages exchanged between the client and the server, from the first 721 request sent by the client to the final response sent by the server. 722 A CPNP transaction is bound to a CPNP session (Section 8.3). 724 Because multiple CPNP transactions can be maintained by the CPNP 725 client, the client must assign an identifier to uniquely identify a 726 given transaction. This identifier is denoted as Transaction-ID. 728 The Transaction-ID must be randomly assigned by the CPNP client, 729 according to the best current practice for generating random numbers 730 [RFC4086] that cannot be guessed easily. Transaction-ID is used for 731 validating CPNP responses received by the client. 733 In the context of a transaction, the client needs to randomly select 734 a sequence number and assign it in the first CPNP message to send. 735 This number is then incremented for each request message is 736 subsequently sent within the on-going CPNP transaction (see 737 Section 11.3). 739 8.5. CPNP Timers 741 CPNP adopts a simple retransmission procedure which relies on a 742 retransmission timer denoted as RETRANS_TIMER and maximum retry 743 threshold. The use of RETRANS_TIMER and a maximum retry threshold 744 are described in Section 11. 746 The response timer (RESPONSE_TIMER) is set by the client to denote 747 the time, in seconds, the client will wait for receiving a response 748 from the server to a provisioning quotation order request (see 749 Section 9.1.6). If the timer expires, the respective quotation order 750 is cancelled by the client and a CANCEL message is generated 751 accordingly. 753 An offer expiration timer (EXPIRE_TIMER) is set by the server to 754 represent the time, in minutes, after which an offer made by the 755 server will be invalid (see Section 9.1.8). 757 8.6. CPNP Operations 759 CPNP operations are listed below. They may be augmented, depending 760 on the nature of some transactions or because of security 761 considerations that may necessitate a distinct CPNP client/server 762 authentication phase before negotiation begins. 764 o QUOTATION (Section 9.2.1): 766 This operation is used by the client to initiate a provisioning 767 quotation order. Upon receipt of a QUOTATION request, the server 768 may respond with a PROCESSING, OFFER or a FAIL message. A 769 QUOTATION-initiated transaction can be terminated by a FAIL 770 message. 772 o PROCESSING (Section 9.2.2): 774 This operation is used to inform the remote party that the message 775 (the order quotation or the offer) sent was received and it is 776 processed. This message can also be issued by the server to 777 request more time, in which case the client may reply with an ACK 778 or FAIL message depending on whether more time can or cannot be 779 granted. 781 o OFFER (Section 9.2.3): 783 This operation is used by the server to inform the client about an 784 offer that can best accommodate the requirements indicated in the 785 previously received QUOTATION message. 787 o ACCEPT (Section 9.2.4): 789 This operation is used by the client to confirm the acceptance of 790 an offer made by the server. This message implies a call for 791 agreement. An agreement is reached when an ACK is subsequently 792 received from the server, which is likely to happen; it is rather 793 unlikely the server to reject an offer that it has already made. 795 o DECLINE (Section 9.2.5): 797 This operation is used by the client to reject an offer made by 798 the server. The on-going transaction may not be terminated 799 immediately, e.g., the server/client may issue another offer/ 800 order. 802 o ACK (Section 9.2.6): 804 This operation is used by the server to acknowledge the receipt of 805 an ACCEPT or WITHDRAW message, or by the client to confirm the 806 time extension requested by the server for processing the last 807 received quotation order. 809 o CANCEL (Section 9.2.7): 811 This operation is used by the client to cancel (quit) the on-going 812 transaction. 814 o WITHDRAW (Section 9.2.8): 816 This operation is used by the client to withdraw an agreement. 818 o UPDATE (Section 9.2.9): 820 This operation is used by the client to update an existing 821 agreement. For example, this method can be invoked to add a new 822 site. This method will trigger a new negotiation cycle. 824 o FAIL (Section 9.2.10): 826 This operation is used by the server to indicate that it cannot 827 accommodate the requirements documented in the PQO conveyed in the 828 QUOTATION message or to inform the client about an error 829 encountered when processing the received message. In either case, 830 the message implies that the server is unable to make offers and 831 as such it terminates the on-going transaction. 833 This message is also used by the client to reject a time extension 834 request received from the server (in a PROCESSING message). The 835 message includes a status code for providing explanatory 836 information. 838 The above CPNP primitives are service-independent. CPNP messages may 839 transparently carry service-specific objects which are handled by the 840 negotiation logic at either side. 842 The document specifies the service objects that are required for 843 connectivity provisioning negotiation (see Section 8.7). Additional 844 service-specific objects to be carried in the CPNP messages can be 845 defined in the future for accommodating alternative deployment or 846 other service provisioning needs. 848 8.7. Connectivity Provisioning Documents 850 CPNP makes use of several flavors of Connectivity Provisioning 851 Documents (CPD). These documents follow the CPP template described 852 in [RFC7297]. 854 Requested Connectivity Provisioning Document (Requested CPD): 855 Refers to the CPD included by a CPNP client in a QUOTATION 856 request. 858 Offered Connectivity Provisioning Document (Offered CPD): This 859 document is included by a CPNP server in an OFFER message. Its 860 information reflects the proposal of the server to accommodate all 861 or a subset of the clauses depicted in a Requested CPD. A 862 validity time is associated with the offer made. 864 Agreed Connectivity Provisioning Document (Agreed CPD): If the 865 client accepts an offer made by the server, the Offered CPD is 866 included in an ACCEPT message. This CPD is also included in an 867 ACK message. Thus, a 3-way hand-shaking procedure is followed for 868 successfully concluding the negotiation. 870 Figure 5 shows a typical CPNP negotiation cycle and the use of the 871 different types of Connectivity Provisioning Documents. 873 +------+ +------+ 874 |Client| |Server| 875 +------+ +------+ 876 |======QUOTATION (Requested CPD)=====>| 877 |<============PROCESSING==============| 878 |<========OFFER (Offered CPD)=========| 879 |=============PROCESSING=============>| 880 |=========ACCEPT (Agreed CPD)========>| 881 |<=========ACK (Agreed CPD)===========| 882 | | 884 Figure 5: 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.8. 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 6). 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=========| | 924 | | | 926 Figure 6: Example of Child Orders 928 8.9. Negotiating with Multiple CPNP Servers 930 A CPNP client may undertake multiple negotiations in parallel with 931 several servers for practical reasons such as cost optimization and 932 fail-safety. The multiple negotiations may lead to one or many 933 agreements. Multiple negotiations with the same Provider are not 934 precluded. 936 The salient point underlining the parallel negotiations scenario is 937 that although the negotiation protocol is strictly between two 938 parties, the negotiation logic may not necessarily be. The CPNP 939 client negotiation logic may need to collectively drive parallel 940 negotiations, as the negotiation with one server may affect the 941 negotiation with other servers; e.g., it may need to use the 942 responses from all servers as input for determining the messages (and 943 their content) to subsequently send in each individual negotiation. 944 Timing is therefore an important aspect at the client's. The CPNP 945 client needs to have the ability to synchronize the receipt of the 946 responses from the servers. CPNP takes into account this requirement 947 by allowing clients to specify in the QUOTATION message the time by 948 which the server needs to respond (see Section 9.1.6). 950 8.10. State Management 952 Both the client and the server maintain repositories to store on- 953 going orders. How these repositories are maintained is deployment- 954 specific. It is out of scope of this document to elaborate on such 955 considerations. Timestamps are also logged to track state change. 956 Tracking may be needed for various reasons,including regulatory ones. 958 8.10.1. On the Client Side 960 The following lists the states which can be associated with a given 961 order on the client's side: 963 o Created: when the order has been created. It is not handled by 964 the client until the administrator allows to process it. 966 o AwaitingProcessing: when the administrator approved of processing 967 a created order and the order has not been handled yet. 969 o PQOSent: when the order has been sent to the server. 971 o ServerProcessing: when the server has confirmed the receipt of the 972 order. 974 o OfferReceived: when an offer has been received from the server. 976 o OfferProcessing: when a received offer is currently processed by 977 the client. 979 o AcceptSent: when the client confirmed the offer to the server. 981 o AcceptAck: when the offer is acknowledged by the server. 983 o Cancelled: when the order has failed or cancelled. 985 +------------------+ 986 | Created |-----------------+ 987 +------------------+ | 988 | | 989 v | 990 +------------------+ | 991 |AwaitingProcessing|----------------+| 992 +------------------+ || 993 | || 994 QUOTATION || 995 v || 996 +------------------+ || 997 | PQOSent |---CANCEL------+|| 998 +------------------+ vvv 999 | +-----+ 1000 PROCESSING | | 1001 v | | 1002 +------------------+ CANCEL | C | 1003 | ServerProcessing |------------>| A | 1004 +------------------+ FAIL | N | 1005 | | C | 1006 | | E | 1007 OFFER | L | 1008 | | L | 1009 v | E | 1010 +------------------+ | D | 1011 | OfferReceived |---CANCEL--->| | 1012 +------------------+ | | 1013 | PROCESSING +-----+ 1014 v ^^^ 1015 +------------------+ ||| 1016 | OfferProcessing |---DECLINE-----+|| 1017 +------------------+ || 1018 | ACCEPT || 1019 v || 1020 +------------------+ || 1021 | AcceptSent |---CANCEL-------+| 1022 +------------------+ | 1023 | ACK | 1024 v | 1025 +------------------+ | 1026 | AcceptAck |---WITHDRAW------+ 1027 +------------------+ 1029 Figure 7: CPNP Finite State Machine (Client Side) 1031 8.10.2. On the Server Side 1033 The following lists the states which can be associated with a given 1034 order and a corresponding offer on the server's side: 1036 o PQOReceived: when the order has been received from the client. 1038 o AwaitingProcessing: when the order is being processed by the 1039 server. An action from the server administrator may be needed. 1041 o OfferProposed: when the request has been successfully handled and 1042 an offer has been sent to the client. 1044 o ProcessingReceived: when the server received a PROCESSING for an 1045 offer sent to the client. 1047 o AcceptReceived: when the server received a confirmation for the 1048 offer from the client. 1050 o AcceptAck: when the server acknowledged the offer (accepted by 1051 client) to the client. 1053 o Cancelled: when the order has failed to be met or it has been 1054 cancelled by the client. Associate resources must be released in 1055 the latter case, if prior reserved. 1057 o ChildCreated: when a child order has been created in cases where 1058 resources from another Network Provider are needed. 1060 o ChildPQOSent: when a child order has been sent to the remote 1061 server. 1063 o ChildServerProcessing: when a child order is currently processed 1064 by the remote server. 1066 o ChildOfferReceived: when an offer has been received to a child 1067 order from the remote server. 1069 o ChildOfferProcessing: when a received offer to a child order is 1070 currently processed. 1072 o ChildAcceptSent: when the child offer (offer received from the 1073 remote server in response to a child order) is confirmed to the 1074 remote server. 1076 o ChildAcceptAck: when an accepted child offer is acknowledged by 1077 the remote server. 1079 +------------------+ 1080 +---------------------| ChildCreated | 1081 | +------------------+ 1082 v | ^ 1083 +------------------+ | | 1084 | ChildPQOSent |----------------+| Q 1085 +------------------+ || U 1086 | || O 1087 QUOTATION || T 1088 v || A +--------------------+ 1089 +---------------------+ CANCEL || T | PQOReceived | 1090 |ChildServerProcessing|------------+|| I +--------------------+ 1091 +---------------------+ FAIL vvv O | | 1092 | +-----+ N CANCEL | 1093 PROCESSING | |<---|-------+ PROCESSING 1094 v | | | v 1095 +------------------+ | | +------------------------+ 1096 |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | 1097 +------------------+ | A | +------------------------+ 1098 | | N | ^ | OFFER 1099 OFFER | C | | +------------------+ 1100 | | E | ::= 1240 ... 1241 ::= 1242 ... 1243 ::= 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 ::= ... 1258 ::= 1259 1260 1262 Figure 9: The RBNF format of the Connectivity Provisioning Document 1263 (CPD) 1265 9.1.10. CPNP Information Elements 1267 An Information Element (IE) is an optional object which can be 1268 included in a CPNP message. 1270 9.1.10.1. Customer Description 1272 The client may include administrative information such as: 1274 o Name 1275 o Contact Information 1277 The format of this Information Element is as follows: 1279 ::= [] [] 1280 ::= [] [] 1281 [ ...] 1283 9.1.10.2. Provider Description 1285 The server may include administrative information in an offer such 1286 as: 1288 o Name 1289 o AS Number ([RFC6793]) 1290 o Contact Information 1292 The format of this Information Element is as follows: 1294 ::= [] [] [] 1296 9.1.10.3. Negotiation Options 1298 The client may include some negotiation options such as: 1300 o Cost: the client may include an empty or a preferred COST 1301 attribute to request the cost from the server. The server will 1302 provide the cost information in the response. 1303 o Setup purpose: A client may request to setup a connectivity only 1304 for testing purposes during a limited period. The order can be 1305 extended to become permanent if the client was satisfied during 1306 the test period. This operation is achieved using UPDATE method. 1308 Other negotiation options may be defined in the future. 1310 The format of this Information Element is as follows: 1312 ::= [] [] 1314 9.2. Operation Messages 1316 This section specifies the RBNF format of CPNP operation messages. 1317 The following operation codes are used: 1319 1: QUOTATION (Section 9.2.1) 1320 2: PROCESSING (Section 9.2.2) 1321 3: OFFER (Section 9.2.3) 1322 4: ACCEPT (Section 9.2.4) 1323 5: DECLINE (Section 9.2.5) 1324 6: ACK (Section 9.2.6) 1325 7: CANCEL (Section 9.2.7) 1326 8: WITHDRAW (Section 9.2.8) 1327 9: UPDATE (Section 9.2.9) 1328 10: FAIL (Section 9.2.10) 1330 9.2.1. QUOTATION 1332 The format of the QUOTATION message is shown below: 1334 ::= 1335 1336 1337 1338 1339 [] 1340 1341 [...] 1343 A QUOTATION message MUST include an order identifier which is 1344 generated by the client. Because several orders can be issued to 1345 several servers, the QUOTATION message MUST also include a 1346 Transaction-ID. 1348 The message MAY include an EXPECTED_RESPONSE_TIME which indicates by 1349 when the client is expecting to receive an offer from the server. 1350 QUOTATION message MUST also include a requested connectivity 1351 provisioning document. 1353 When the client sends the QUOTATION message to the server, the state 1354 of the order changes to "PQOSent". 1356 9.2.2. PROCESSING 1358 The format of the PROCESSING message is shown below: 1360 ::= 1361 1362 1363 1364 1365 1366 [] 1368 Upon receipt of a QUOTATION message, the server proceeds with parsing 1369 rules (see Section 10). If no error is encountered, the server 1370 generates a PROCESSING response to the client to indicate the PQO has 1371 been received and it is being processed. The server MUST generate an 1372 order identifier which identifies the order in its local order 1373 repository. The server MUST copy the content of 1374 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed 1375 in the QUOTATION message. The server MAY include an 1376 EXPECTED_OFFER_TIME by when it expects to make an offer to the 1377 client. 1379 Upon receipt of a PROCESSING message, the client verifies whether it 1380 has issued a PQO to that server and which contains the 1381 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is 1382 found, the PROCESSING message MUST be silently ignored. If a PQO is 1383 found, the client may check if it accepts the EXPECTED_OFFER_TIME and 1384 then, it changes to state of the order to "ServerProcessing". 1386 If more time is required by the server to process the quotation 1387 order, it MAY send a PROCESSING message that includes a new 1388 EXPECTED_OFFER_TIME. The client can answer with an ACK message if 1389 more time is granted (Figure 10) or with a FAIL message if the time 1390 extension is rejected (Figure 11). 1392 +------+ +------+ 1393 |Client| |Server| 1394 +------+ +------+ 1395 |=======QUOTATION(Requested CPD)=====>| 1396 |<========PROCESSING(time1)===========| 1397 ... 1398 |<========PROCESSING(MoreTime)========| 1399 |============ACK(TimeGranted)========>| 1400 ... 1401 |<=========OFFER(Offered CPD)=========| 1402 |=============PROCESSING=============>| 1403 |==========ACCEPT(Agreed CPD)========>| 1404 |<==========ACK(Agreed CPD)===========| 1405 | | 1407 Figure 10: Request More Negotiation Time: Granted 1408 +------+ +------+ 1409 |Client| |Server| 1410 +------+ +------+ 1411 |=======QUOTATION(Requested CPD)=====>| 1412 |<========PROCESSING(time1)===========| 1413 ... 1414 |<========PROCESSING(MoreTime)========| 1415 |===========FAIL(TimeRejected)=======>| 1417 Figure 11: Request More Negotiation Time: Rejected 1419 9.2.3. OFFER 1421 The format of the OFFER message is shown below: 1423 ::= 1424 1425 1426 1427 1428 1429 1430 1431 1432 [...] 1434 The server answers with an OFFER message to a QUOTATION request 1435 received from the client. The offer will be considered as rejected 1436 by the client if no confirmation (ACCEPT message sent by the client) 1437 is received by the server before the expiration of the validity time. 1439 9.2.4. ACCEPT 1441 The format of the ACCEPT message is shown below: 1443 ::= 1444 1445 1446 1447 1448 1449 1450 1451 [...] 1453 This message is used by a client to confirm the acceptance of an 1454 offer received from a server. The fields of this message MUST be 1455 copied from the received OFFER message. 1457 9.2.5. DECLINE 1459 The format of the DECLINE message is shown below: 1461 ::= 1462 1463 1464 1465 1466 1467 1469 The client may issue a DECLINE message to reject an offer. 1470 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, 1471 TRANSACTION_ID, and NONCE are used by the server as keys to find the 1472 corresponding order. If an order matches, the server changes the 1473 state of this order to "Cancelled" and then returns an ACK with a 1474 copy of the requested CPD to the requesting client. 1476 If no order is found, the server returns a FAIL message to the 1477 requesting client. 1479 A flow example is shown in Figure 12. 1481 +------+ +------+ 1482 |Client| |Server| 1483 +------+ +------+ 1484 |=======QUOTATION(Requested CPD)=====>| 1485 |<============PROCESSING==============| 1486 |<=========OFFER(Offered CPD)=========| 1487 |=============PROCESSING=============>| 1488 |===============DECLINE==============>| 1489 |<================ACK=================| 1490 | | 1492 Figure 12: DECLINE Flow Example 1494 9.2.6. ACK 1496 The format of the ACK message is shown below: 1498 ::= 1499 1500 1501 1502 1503 1504 [] 1506 [] 1507 [...] 1509 This message is issued by the server to close a CPNP transaction or 1510 by a client to grant more negotiation time to the server. 1512 This message is sent by the server as a response to an ACCEPT, 1513 WITHDRAW, DECLINE, or CANCEL message. In such case, the ACK message 1514 MUST include the copy of the Connectivity Provisioning Document as 1515 stored by the server, in particular: 1517 o A copy of the requested/offered CPD is included by the server if 1518 it successfully handled a CANCEL message. 1519 o A copy of the updated CPD is included by the server if it 1520 successfully handled an UPDATE message. 1521 o A copy of the offered CPD is included by the server if it 1522 successfully handled an ACCEPT message in the context of a 1523 QUOTATION transaction. 1524 o An empty CPD is included by the server if it successfully handled 1525 a DECLINE message. 1527 A client may issue an ACK message as a response to a more time 1528 request (conveyed in PROCESSING) received from the server. In such 1529 case, the ACK message MUST include an EXPECTED_RESPONSE_TIME that is 1530 likely to be set to the time extension requested by the server. 1532 9.2.7. CANCEL 1534 The format of the CANCEL message is shown below: 1536 ::= 1537 1538 1539 1540 1541 [] 1543 The client can issue a CANCEL message at any stage during the CPNP 1544 negotiation process before an agreement is reached. 1545 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID are used by the 1546 server as keys to find the corresponding order. If a quotation order 1547 matches, the server changes the state of this quotation order to 1548 "Cancelled" and then returns an ACK with a copy of the requested CPD 1549 to the requesting client. 1551 If no quotation order is found, the server returns a FAIL message to 1552 the requesting client. 1554 9.2.8. WITHDRAW 1556 The format of the WITHDRAW message is shown below: 1558 ::= 1559 1560 1561 1562 1563 1564 1565 [] 1566 [...] 1568 This message is used to withdraw an offer already subscribed by the 1569 Customer. Figure 13 shows a typical usage of this message. 1571 +------+ +------+ 1572 |Client| |Server| 1573 +------+ +------+ 1574 |============WITHDRAW(CPD)===========>| 1575 |<============PROCESSING==============| 1576 |<===========ACK(Empty CPD)===========| 1577 | | 1579 Figure 13: WITHDRAW Flow Example 1581 The CPNP MUST include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1582 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1583 the order. 1585 Upon receipt of a WITHDRAW message, the server checks whether an 1586 order matching the request is found. If an order is found, the state 1587 of the order is changed to "Cancelled" and an ACK message including 1588 an Empty CPD is returned to the requesting client. If no order is 1589 found, the server returns a FAIL message to the requesting client. 1591 9.2.9. UPDATE 1593 The format of the UPDATE message is shown below: 1595 ::= 1596 1597 1598 1599 1600 1601 1602 1603 1604 [...] 1606 This message is sent by the CPNP client to update an existing 1607 connectivity provisioning agreement. The CPNP MUST include the same 1608 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1609 NONCE as those used when creating the order. The CPNP client 1610 includes a new CPD which integrates the requested modifications. A 1611 new Transaction_ID MUST be assigned by the client. 1613 Upon receipt of an UPDATE message, the server checks whether an 1614 order, having state "Completed", matches 1615 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1616 NONCE. 1618 o If no order is found, the CPNP server generates a FAIL error with 1619 the appropriate error code. 1620 o If an order is found, the server checks whether it can honor the 1621 request: 1623 * A FAIL message is sent to the client if the server cannot honor 1624 the request. The client may initiate a new PQO negotiation 1625 cycle. 1626 * An OFFER message including the updated connectivity 1627 provisioning document is sent to the client. For example, the 1628 server maintains an order for provisioning a VPN service that 1629 connects sites A, B and C. If the client sends an UPDATE 1630 message to remove site C, only sites A and B will be included 1631 in the OFFER sent by the server to the requesting client. 1633 A flow chart that illustrates the use of UPDATE operation is shown in 1634 Figure 14. 1636 +------+ +------+ 1637 |Client| |Server| 1638 +------+ +------+ 1639 |=========UPDATE(Requested CPD)======>| 1640 |<============PROCESSING==============| 1641 |<=========OFFER(Updated CPD)=========| 1642 |=============PROCESSING=============>| 1643 |==========ACCEPT(Updated CPD)=======>| 1644 |<==========ACK(Updated CPD)==========| 1645 | | 1647 Figure 14: UPDATE Flow Example 1649 9.2.10. FAIL 1651 The format of the FAIL message is shown below: 1653 ::= 1654 1655 1656 1657 1658 1659 1661 This message is sent in the following cases: 1663 o The server can not honor an order received from the client (i.e., 1664 received in a QUOTATION or UPDATE request). 1665 o The server encounters an error when processing a CPNP request 1666 received from the client. 1667 o The client can not grant more time to a the server. This is a 1668 response to a more time request conveyed in a PROCESSING message. 1670 The status code indicates the error code. The following codes are 1671 supported: 1673 1 (Message Validation Error): 1674 The message can not be validated (see Section 10). 1675 2 (Authentication Required): 1676 The request cannot be handled because authentication is 1677 required. 1678 3 (Authorization Failed): 1679 The request cannot be handled because authorization failed. 1680 4 (Administratively prohibited): 1681 The request can not be handled because of administrative 1682 policies. 1683 5 (Out of Resources): 1684 The request can not be honored because there is not enough 1685 capacity. 1686 6 (Network Presence Error): 1687 The request can not be honored because there is no network 1688 presence. 1689 7 (More Time Rejected): 1690 The request to extend the time negotiation is rejected by the 1691 client. 1693 10. CPNP Message Validation 1695 Both client and server proceed with CPNP message validation. The 1696 following tables summarize the validation checks to be followed. 1698 10.1. On the Client Side 1700 Operation Validation Checks 1701 ------------ -------------------------------------------------------- 1702 PROCESSING {Source IP address, source port number, destination IP 1703 address, destination port number, Transaction-ID, 1704 Customer Order Identifier} must match an existing PQO 1705 with a state set to "PQOSent". The sequence number 1706 carried in the packet must be larger than the sequence 1707 number maintained by the client. 1708 OFFER {Source IP address, source port number, destination IP 1709 address, destination port number, Transaction-ID, 1710 Customer Order Identifier} must match an existing order 1711 with state set to "PQOSent" or {Source IP address, 1712 source port number, destination IP address, destination 1713 port number, Transaction-ID, Customer Order Identifier, 1714 Provider Order Identifier} must match an existing order 1715 with a state set to "ServerProcessing". The sequence 1716 number carried in the packet must be larger than the 1717 sequence number maintained by the client. 1718 ACK {Source IP address, source port number, destination IP 1719 (QUOTATION address, destination port number, Transaction-ID, 1720 Transaction) Customer Order Identifier, Provider Order Identifier, 1721 Offered Connectivity Provisioning Order} must match an 1722 order with a state set to "AcceptSent". The sequence 1723 number carried in the packet must be larger than the 1724 sequence number maintained by the client. 1725 ACK (UPDATE {Source IP address, source port number, destination IP 1726 Transaction) address, destination port number, Transaction-ID, 1727 Customer Order Identifier, Provider Order Identifier, 1728 Updated Connectivity Provisioning Order} must match an 1729 order with a state set to "AcceptSent". The sequence 1730 number carried in the packet must be larger than the 1731 sequence number maintained by the client. 1732 ACK {Source IP address, source port number, destination IP 1733 (WITHDRAW address, destination port number, Transaction-ID, 1734 Transaction) Customer Order Identifier, Provider Order Identifier, 1735 Empty Connectivity Provisioning Order} must match an 1736 order with a state set to "Cancelled". The sequence 1737 number carried in the packet must be larger than the 1738 sequence number maintained by the client. 1740 10.2. On the Server Side 1742 Method Validation Checks 1743 ---------- ---------------------------------------------------------- 1744 QUOTATION The source IP address passes existing access filters (if 1745 any). The sequence number carried in the packet must not 1746 be less than the sequence number maintained by the server. 1747 PROCESSING The sequence number carried in the packet must be larger 1748 than the sequence number maintained by the server. 1749 ACCEPT {Source IP address, source port number, destination IP 1750 address, destination port number, Transaction-ID, Customer 1751 Order Identifier, Provider Order Identifier, Nonce, 1752 Offered Connectivity Provisioning Order} must match an 1753 order with state set to "OfferProposed" or 1754 "ProcessngReceived". The sequence number carried in the 1755 packet must be larger than the sequence number maintained 1756 by the server. 1757 DECLINE {Source IP address, source port number, destination IP 1758 address, destination port number, Transaction-ID, Customer 1759 Order Identifier, Provider Order Identifier, Nonce} must 1760 match an order with state set to "OfferProposed" or 1761 "ProcessngReceived". The sequence number carried in the 1762 packet must be larger than the sequence number maintained 1763 by the server. 1764 UPDATE The source IP address passes existing access filters (if 1765 any) and {Customer Order Identifier, Provider Order 1766 Identifier, Nonce} must match an existing order with state 1767 "Completed". 1768 WITHDRAW The source IP address passes existing access filters (if 1769 any) and {Customer Order Identifier, Provider Order 1770 Identifier, Nonce} must match an existing order with state 1771 "Completed". 1773 11. Theory of Operation 1775 Both CPNP client and server proceed to message validation checks as 1776 specified in Section 10. 1778 11.1. Client Behavior 1780 11.1.1. Order Negotiation Cycle 1782 To place a provisioning quotation order, the client initiates first a 1783 local quotation order object identified by a unique identifier 1784 assigned by the client. The state of the quotation order is set to 1785 "Created". The client then generates a QUOTATION request which 1786 includes the assigned identifier, possibly an expected response time, 1787 a Transaction-ID and a Requested Connectivity Provisioning Document. 1789 The client may include additional Information Elements such as 1790 Negotiation Options. 1792 The client may be configured to not enforce negotiation checks on 1793 EXPECTED_OFFER_TIME; if so no EXPECTED_RESPONSE_TIME attribute (or 1794 EXPECTED_RESPONSE_TIME set to infinite) should be included in the 1795 quotation order. 1797 Once the request is sent to the server, the state of the request is 1798 set to "PQOSent" and a timer, if a response time is included in the 1799 quotation order, is set to the expiration time as included in the 1800 QUOTATION request. The client also maintains a copy of the CPNP 1801 session entry details used to generate the QUOTATION request. The 1802 CPNP client must listen on the same port number that it used to send 1803 the QUOTATION request. 1805 If no answer is received from the server before the retransmission 1806 timer expires (i.e., RETRANS_TIMER, Section 8.5), the client proceeds 1807 to retransmission until maximum retry is reached (i.e., 3 times). 1808 The same sequence number is used for retransmitted packets. 1810 If a FAIL message is received, the client may decide to issue another 1811 (corrected) request towards the same server, cancel the local order, 1812 or contact another server. The behavior of the client depends on the 1813 error code returned by the server in the FAIL message. 1815 If a PROCESSING message matching the CPNP session entry (Section 8.3) 1816 is received, the client updates the CPNP session entry with the 1817 PROVIDER_AGREEMENT_IDENTIFIER information. If the client does not 1818 accept the expected offer time that may have been indicated in the 1819 PROCESSING message, the client may decide to cancel the quotation 1820 order. If the client accepts the EXPECTED_OFFER_TIME, it changes the 1821 state of the order to "ServerProcessing" and sets a timer to the 1822 value of EXPECTED_OFFER_TIME. If no offer is made before the timer 1823 expires, the client changes the state of the order to "Cancelled". 1825 As a response to a more time request (conveyed in a PROCESSING 1826 message that included a new EXPECTED_OFFER_TIME), the client may 1827 grant this extension by issuing an ACK message or reject the time 1828 extension with a FAIL message having a status code set to "More Time 1829 Rejected". 1831 If an OFFER message matching the CPNP session entry is received, the 1832 client checks if a PROCESSING message having the same 1833 PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If 1834 a PROCESSING message was already received for the same order but the 1835 PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included 1836 in the OFFER message, the client ignores silently the message. If a 1837 PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was 1838 already received and matches the CPNP transaction identifier, the 1839 client changes the state of the order to "OfferReceived" and sets a 1840 timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER 1841 message. 1843 If an offer is received from the server (i.e., as documented in an 1844 OFFER message), the client may accept or reject the offer. The 1845 client accepts the offer by generating an ACCEPT message which 1846 confirms that the client agrees to subscribe to the offer documented 1847 in the OFFER message; the state of the order is passed to 1848 "AcceptSent". The transaction is terminated if an ACK message is 1849 received from the server. If no ACK is received from the server, the 1850 client proceeds with the re-transmission of the ACCEPT message. 1852 The client may also decide to reject the offer by sending a DECLINE 1853 message. The state of the order is set by the client to "Cancelled". 1854 If an offer is not acceptable by the client, the client may decide to 1855 contact a new server or submit another order to the same server. 1856 Guidelines to issue an updated order or terminate the negotiation are 1857 specific to the client. 1859 11.1.2. Order Withdrawal Cycle 1861 A client may withdraw a completed order. This is achieved by issuing 1862 a WITHDRAW message. This message MUST include Customer Order 1863 Identifier, Provider Identifier, and Nonce returned during the order 1864 negotiation cycle specified in Section 11.1.1. 1866 If no ACK is received from the server, the client proceeds with the 1867 re-transmission of the message. 1869 11.1.3. Order Update Cycle 1871 A client may update a completed order. This is achieved by issuing 1872 an UPDATE message. This message MUST include Customer Order 1873 Identifier, Provider Order Identifier and Nonce returned during the 1874 order negotiation cycle specified in Section 11.1.1. The client MUST 1875 include in the UPDATE message an updated CPD with the requested 1876 changes. 1878 Subsequent messages exchange is similar to what is documented in 1879 Section 11.1.1. 1881 11.2. Server Behavior 1883 11.2.1. Order Processing 1885 Upon receipt of a QUOTATION message from a client, the server sets a 1886 CPNP session, stores Transaction-ID and generates a Provider Order 1887 Identifier. Once preliminary validation checks are completed ( 1888 Section 10), the server may return a PROCESSING message to notify the 1889 client the quotation order is received and it is under processing; 1890 the server may include an expected offer time to notify the client by 1891 when an offer will be proposed. An order with state 1892 "AwaitingProcessing" is created by the server. The server runs its 1893 decision-making process to decide which offer it can make to honor 1894 the received order. The offer should be made before the expected 1895 offer time expires. 1897 If the server cannot make an offer, it sends backs a FAIL message 1898 with the appropriate error code. 1900 If the server requires more negotiation time, it must send a 1901 PROCESSING message with a new EXPECTED_OFFER_TIME. The client may 1902 grant this extension by issuing an ACK message or reject the time 1903 extension with a FAIL message having a status code set to "More Time 1904 Rejected". If the client doesn't grant more time, the server must 1905 answer before the initial expected offer time; otherwise the client 1906 will ignore the quotation order. 1908 If the server can honor the request or it can make an offer that meet 1909 some of the requirements, it creates an OFFER message. The server 1910 must indicate the Transaction-ID, Customer Order Identifier as 1911 indicated in the QUOTATION message, and the Provider Order Identifier 1912 generated for this order. The server must also include Nonce and the 1913 offered Connectivity Provisioning Document. The server includes an 1914 offer validity time as well. Once sent to the client, the server 1915 changes the state of the order to "OfferSent" and a timer set to the 1916 validity time is initiated. 1918 If the server determines that additional network resources from 1919 another network provider are needed to accommodate a quotation order, 1920 it will create child PQO(s) and will behave as a CPNP client to 1921 negotiate child PQO(s) with possible partnering providers (see 1922 Figure 6). 1924 If no PROCESSING, ACCEPT or DECLINE message is received before the 1925 expiry of the RETRANS_TIMER, the server re-sends the same offer to 1926 the client. This procedure is repeated until maximum retry is 1927 reached. 1929 If an ACCEPT message is received before the offered validity time 1930 expires, the server proceeds with validation checks as specified in 1931 Section 10. The state of the corresponding order is passed to 1932 "AcceptReceived". The server sends back an ACK message to terminate 1933 the order processing cycle. 1935 If a CANCEL/DECLINE message is received, the server proceeds with the 1936 cancellation of the order. The state of the order is then passed to 1937 "Cancelled". 1939 11.2.2. Order Withdrawal 1941 A client may withdraw a completed order by issuing a WITHDRAW 1942 message. Upon receipt of a WITHDRAW message, the server proceeds 1943 with the validation checks, as specified in Section 10: 1945 o If the checks fail, a FAIL message is sent back to the client with 1946 the appropriate error code. 1948 o If the checks succeed, the server clears the clauses of the 1949 Connectivity Provisioning Document, changes the state of the order 1950 to "Cancelled", and sends back an ACK message with an Empty 1951 Connectivity Provisioning Document. 1953 11.2.3. Order Update 1955 A client may update an order by issuing an UPDATE message. Upon 1956 receipt of an UPDATE message, the server proceeds with the validation 1957 checks as specified in Section 10: 1959 o If the checks fail, a FAIL message is sent back to the client with 1960 the appropriate error code. 1961 o Subsequent messages exchange is similar to what is specified in 1962 Section 11.1.1. The server should generate a new Nonce value to 1963 be included in the offer made to the client. 1965 11.3. Sequence Numbers 1967 In each transaction, sequence numbers are used to protect the 1968 transaction against replay attacks. Each communicating partner of 1969 the transaction maintains two sequence numbers, one for incoming 1970 packets and one for outgoing packets. When a partner receives a 1971 message, it will check whether the sequence number in the message is 1972 larger than the incoming sequence number maintained locally. If not, 1973 the messages will be discarded. If the message is proved to be 1974 legal, the value of the incoming sequence number will be replaced by 1975 the value of the sequence number in the message. When a partner 1976 sends out a message, it will insert the value of outgoing sequence 1977 number into the message and increase the outgoing sequence number 1978 maintained locally by 1. 1980 11.4. Message Re-Transmission 1982 If a transaction partner sends out a message and does not receive any 1983 expected reply before the retransmission timer expires (i.e., 1984 RETRANS_TIMER), a transaction partner will try to re-transit the 1985 messages. An exception is the last message (e.g., ACK) sent from the 1986 server in a transaction. After sending this message, the 1987 retransmission timer will be disabled since no additional feedback is 1988 expected. 1990 In addition, if the partner receives a re-sent last incoming packet, 1991 the partner can also send out the answer to the incoming packet with 1992 a limited frequency. If no answer was generated at the moment, the 1993 partner needs to generate a PROCESSING message as the answer. 1995 To benefit message re-transmission, a partner could also store the 1996 last incoming packet and the associated answer. Note that the times 1997 of re-transmission could be decided by the local policy and re- 1998 transmission will not cause any change of sequence numbers. 2000 12. Some Operational Guidelines 2002 12.1. Logging on the CPNP Server 2004 The CPNP server should be configurable to log various events and 2005 associated information. Such information may include: 2007 o Client's IP address 2008 o Any event change (e.g., new quotation order, offer sent, order 2009 confirm, order cancellation, order withdraw, etc.) 2010 o Timestamp 2012 12.2. Business Guidelines & Objectives 2014 The CPNP server can operate in the following modes: 2016 1. Fully automated mode: 2018 The CPNP server is provisioned with a set of business guidelines 2019 and objectives that will be used as an input to the decision- 2020 making process. The CPNP server will service received orders 2021 that falls into these business guidelines; otherwise requests 2022 will be escalated to an administrator that will formally 2023 validate/invalidate an order request. The set of policies to be 2024 configured to the CPNP server are specific to each administrative 2025 entity managing a CPNP server. 2027 2. Administrative-based mode: 2029 This mode assumes some or all CPNP server' operations are subject 2030 to a formal administrative validation. CPNP events will trigger 2031 appropriate validation requests that will be forwarded to the 2032 contact person(s) or department which is responsible for 2033 validating the orders. Administrative validation messages are 2034 relayed using another protocol (e.g., SMTP) or a dedicated tool. 2036 Business guidelines are local to each administrative entity. How 2037 validation requests are presented to an administrator are out of 2038 scope of this document; each administrative entity may decide the 2039 appropriate mechanism to enable for that purpose. 2041 13. Security Considerations 2043 Means to defend the server against denial-of-service attacks must be 2044 enabled. For example, access control lists (ACLs) can be enforced on 2045 the client, the server or the network in between, to allow a trusted 2046 client to communicate with a trusted server. 2048 The client and the server MUST be mutually authenticated. 2049 Authenticated encryption MUST be used for data confidentiality and 2050 message integrity. 2052 The protocol does not provide security mechanisms to protect the 2053 confidentiality and integrity of the packets transported between the 2054 client and the server. An underlying security protocol such as 2055 (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport 2056 Layer Security (TLS) [RFC8446]) MUST be used to protect the integrity 2057 and confidentiality for the protocol. In this case, if it is 2058 possible to provide an Automated Key Management (AKM) and associate 2059 each transaction with a different key, inter-transaction replay 2060 attacks can naturally be addressed. If the client and the server use 2061 a single key, an additional mechanism should be provided to protect 2062 inter-transaction replay attacks between them. Clients MUST 2063 implement DTLS record replay detection (Section 3.3 of [RFC6347]) or 2064 an equivalent mechanism to protect against replay attacks. 2066 DTLS and TLS with a cipher suite offering confidentiality protection 2067 and the guidance given in [RFC7525] MUST be followed to avoid attacks 2068 on (D)TLS. 2070 The client MUST silently discard CPNP responses received from unknown 2071 CPNP servers. The use of a randomly generated Transaction-ID makes 2072 it hard to forge a response from a server with a spoofed IP address 2073 belonging to a legitimate CPNP server. Furthermore, CPNP demands 2074 that messages from the server must include correct identifiers of the 2075 orders. Two order identifiers are used: one generated by the client 2076 and a second one generated by the server. 2078 The Provider MUST enforce means to protect privacy-related 2079 information included the documents (see Section 8.7) exchanged using 2080 CPNP messages [RFC6462]. In particular, this information MUST NOT be 2081 revealed to external parties without the consent of Customers. 2082 Providers should enforce policies to make Customer fingerprinting 2083 difficult to achieve. For more discussion about privacy, refer to 2084 [RFC6462][RFC6973]. 2086 The Nonce and the Transaction ID attributes provide sufficient 2087 randomness and can effectively tolerate attacks raised by off-line 2088 adversaries, who do not have the capability of eavesdropping and 2089 intercepting the packets transported between the client and the 2090 server. Only authorized clients must be able to modify agreed CPNP 2091 orders. The use of a randomly generated Nonce by the server makes it 2092 hard to modify an agreement on behalf of a malicious third-party. 2094 14. IANA Considerations 2096 This document does not request any IANA action. 2098 15. Acknowledgements 2100 Thanks to Diego R. Lopez for his comments. 2102 16. References 2104 16.1. Normative References 2106 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 2107 Application and Support", STD 3, RFC 1123, 2108 DOI 10.17487/RFC1123, October 1989, 2109 . 2111 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2112 Requirement Levels", BCP 14, RFC 2119, 2113 DOI 10.17487/RFC2119, March 1997, 2114 . 2116 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2117 "Randomness Requirements for Security", BCP 106, RFC 4086, 2118 DOI 10.17487/RFC4086, June 2005, 2119 . 2121 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2122 Used to Form Encoding Rules in Various Routing Protocol 2123 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2124 2009, . 2126 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2127 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2128 January 2012, . 2130 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2131 "Recommendations for Secure Use of Transport Layer 2132 Security (TLS) and Datagram Transport Layer Security 2133 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2134 2015, . 2136 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2137 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2138 May 2017, . 2140 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2141 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2142 . 2144 16.2. Informative References 2146 [ETICS] EU FP7 ETICS Project, "Economics and Technologies of 2147 Inter-Carrier Services", January 2014, . 2151 [I-D.boucadair-lisp-idr-ms-discovery] 2152 Boucadair, M. and C. Jacquenet, "LISP Mapping Service 2153 Discovery at Large", draft-boucadair-lisp-idr-ms- 2154 discovery-01 (work in progress), March 2016. 2156 [I-D.geng-netslices-architecture] 2157 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 2158 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 2159 Architecture", draft-geng-netslices-architecture-02 (work 2160 in progress), July 2017. 2162 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2163 specifying the location of services (DNS SRV)", RFC 2782, 2164 DOI 10.17487/RFC2782, February 2000, 2165 . 2167 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2168 Private Network (VPN) Terminology", RFC 4026, 2169 DOI 10.17487/RFC4026, March 2005, 2170 . 2172 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 2173 and A. Gonguet, "Framework for Layer 3 Virtual Private 2174 Networks (L3VPN) Operations and Management", RFC 4176, 2175 DOI 10.17487/RFC4176, October 2005, 2176 . 2178 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 2179 RFC 6462, DOI 10.17487/RFC6462, January 2012, 2180 . 2182 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 2183 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 2184 . 2186 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 2187 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 2188 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 2189 November 2012, . 2191 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 2192 Autonomous System (AS) Number Space", RFC 6793, 2193 DOI 10.17487/RFC6793, December 2012, 2194 . 2196 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2197 Locator/ID Separation Protocol (LISP)", RFC 6830, 2198 DOI 10.17487/RFC6830, January 2013, 2199 . 2201 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2202 Morris, J., Hansen, M., and R. Smith, "Privacy 2203 Considerations for Internet Protocols", RFC 6973, 2204 DOI 10.17487/RFC6973, July 2013, 2205 . 2207 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 2208 Networking: A Perspective from within a Service Provider 2209 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 2210 . 2212 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2213 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2214 2014, . 2216 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 2217 Pascual, J., and D. Lewis, "Locator/Identifier Separation 2218 Protocol (LISP) Network Element Deployment 2219 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2220 2014, . 2222 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 2223 Connectivity Provisioning Profile (CPP)", RFC 7297, 2224 DOI 10.17487/RFC7297, July 2014, 2225 . 2227 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 2228 Application-Based Network Operations", RFC 7491, 2229 DOI 10.17487/RFC7491, March 2015, 2230 . 2232 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 2233 Model for L3VPN Service Delivery", RFC 8049, 2234 DOI 10.17487/RFC8049, February 2017, 2235 . 2237 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2238 Kumar, "Framework for Interface to Network Security 2239 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2240 . 2242 [RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., 2243 and P. Iovanna, "Cooperating Layered Architecture for 2244 Software-Defined Networking (CLAS)", RFC 8597, 2245 DOI 10.17487/RFC8597, May 2019, 2246 . 2248 Authors' Addresses 2250 Mohamed Boucadair 2251 Orange 2252 Rennes 35000 2253 France 2255 Email: mohamed.boucadair@orange.com 2257 Christian Jacquenet 2258 Orange 2259 Rennes 35000 2260 France 2262 Email: christian.jacquenet@orange.com 2263 Dacheng Zhang 2264 Huawei Technologies 2266 Email: zhangdacheng@huawei.com 2268 Panos Georgatsos 2269 Centre for Research and Innovation Hellas 2270 78, Filikis Etairias str. 2271 Volos, Hellas 38334 2272 Greece 2274 Phone: +302421306070 2275 Email: pgeorgat@iti.gr