idnits 2.17.1 draft-boucadair-connectivity-provisioning-protocol-18.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 (December 10, 2019) is 1598 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 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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: June 12, 2020 D. Zhang 6 Huawei Technologies 7 P. Georgatsos 8 CERTH 9 December 10, 2019 11 Connectivity Provisioning Negotiation Protocol (CPNP) 12 draft-boucadair-connectivity-provisioning-protocol-18 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 June 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. CPNP Functional Elements . . . . . . . . . . . . . . . . . . 6 63 4. Order Processing Models . . . . . . . . . . . . . . . . . . . 7 64 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 65 6. CPNP Deployment Models . . . . . . . . . . . . . . . . . . . 11 66 7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 11 67 8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 68 8.1. Client/Server Communication . . . . . . . . . . . . . . . 14 69 8.2. Policy Configuration on the CPNP Server . . . . . . . . . 15 70 8.3. CPNP Session Entries . . . . . . . . . . . . . . . . . . 17 71 8.4. CPNP Transaction . . . . . . . . . . . . . . . . . . . . 17 72 8.5. CPNP Timers . . . . . . . . . . . . . . . . . . . . . . . 18 73 8.6. CPNP Operations . . . . . . . . . . . . . . . . . . . . . 18 74 8.7. Connectivity Provisioning Documents . . . . . . . . . . . 20 75 8.8. Child Provisioning Quotation Orders . . . . . . . . . . . 21 76 8.9. Negotiating with Multiple CPNP Servers . . . . . . . . . 22 77 8.10. State Management . . . . . . . . . . . . . . . . . . . . 22 78 8.10.1. On the Client Side . . . . . . . . . . . . . . . . . 23 79 8.10.2. On the Server Side . . . . . . . . . . . . . . . . . 25 80 9. CPNP Objects . . . . . . . . . . . . . . . . . . . . . . . . 27 81 9.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 27 82 9.1.1. CUSTOMER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 27 83 9.1.2. PROVIDER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 27 84 9.1.3. TRANSACTION_ID . . . . . . . . . . . . . . . . . . . 28 85 9.1.4. SEQUENCE_NUMBER . . . . . . . . . . . . . . . . . . . 28 86 9.1.5. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 28 87 9.1.6. EXPECTED_RESPONSE_TIME . . . . . . . . . . . . . . . 28 88 9.1.7. EXPECTED_OFFER_TIME . . . . . . . . . . . . . . . . . 28 89 9.1.8. VALIDITY_OFFER_TIME . . . . . . . . . . . . . . . . . 29 90 9.1.9. SERVICE_DESCRIPTION . . . . . . . . . . . . . . . . . 29 91 9.1.10. CPNP Information Elements . . . . . . . . . . . . . . 30 92 9.2. Operation Messages . . . . . . . . . . . . . . . . . . . 31 93 9.2.1. QUOTATION . . . . . . . . . . . . . . . . . . . . . . 31 94 9.2.2. PROCESSING . . . . . . . . . . . . . . . . . . . . . 32 95 9.2.3. OFFER . . . . . . . . . . . . . . . . . . . . . . . . 33 96 9.2.4. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . 34 97 9.2.5. DECLINE . . . . . . . . . . . . . . . . . . . . . . . 34 98 9.2.6. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 35 99 9.2.7. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 36 100 9.2.8. WITHDRAW . . . . . . . . . . . . . . . . . . . . . . 36 101 9.2.9. UPDATE . . . . . . . . . . . . . . . . . . . . . . . 37 102 9.2.10. FAIL . . . . . . . . . . . . . . . . . . . . . . . . 38 103 10. CPNP Message Validation . . . . . . . . . . . . . . . . . . . 39 104 10.1. On the Client Side . . . . . . . . . . . . . . . . . . . 39 105 10.2. On the Server Side . . . . . . . . . . . . . . . . . . . 41 106 11. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 41 107 11.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 41 108 11.1.1. Order Negotiation Cycle . . . . . . . . . . . . . . 41 109 11.1.2. Order Withdrawal Cycle . . . . . . . . . . . . . . . 43 110 11.1.3. Order Update Cycle . . . . . . . . . . . . . . . . . 43 111 11.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 44 112 11.2.1. Order Processing . . . . . . . . . . . . . . . . . . 44 113 11.2.2. Order Withdrawal . . . . . . . . . . . . . . . . . . 45 114 11.2.3. Order Update . . . . . . . . . . . . . . . . . . . . 45 115 11.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 45 116 11.4. Message Re-Transmission . . . . . . . . . . . . . . . . 46 117 12. Some Operational Guidelines . . . . . . . . . . . . . . . . . 46 118 12.1. Logging on the CPNP Server . . . . . . . . . . . . . . . 46 119 12.2. Business Guidelines & Objectives . . . . . . . . . . . . 46 120 13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 121 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 122 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 123 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 124 16.1. Normative References . . . . . . . . . . . . . . . . . . 48 125 16.2. Informative References . . . . . . . . . . . . . . . . . 49 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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). Sample negotiation uses cases are described in 145 Section 5. 147 [RFC7297] describes a Connectivity Provisioning Profile (CPP) 148 template to capture connectivity requirements to be met by a 149 transport infrastructure for the delivery of various services such as 150 Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) 151 services [RFC4026]. The CPP document defines the set of IP transfer 152 parameters that reflect the guarantees that can be provided by the 153 underlying transport network together with reachability scope and 154 capacity needs. CPNP uses the CPP template to encode connectivity 155 provisioning clauses under negotiation. The agreed CPP will be then 156 passed to other functional elements that are responsible for the 157 actual service activation and provisioning. For example, NETCONF 158 [RFC6241] or RESTCONF [RFC8040] can be used to activate adequate 159 network features that are required to deliver the agreed service. 160 How the outcome of CPNP negotiation is translated into service and 161 network provisioning actions is out of scope of this document. 163 As a reminder, several proposals have been made in the past by the 164 (research) community (e.g., COPS-SLS, Service Negotiation Protocol 165 (SrNP), Dynamic Service Negotiation Protocol (DSNP), Resource 166 Negotiation and Pricing Protocol (RNAP), Service Negotiation and 167 Acquisition Protocol (SNAP)). CPNP leverages the experience of the 168 authors with SrNP by separating the negotiation primitives from the 169 service under negotiation. Moreover, careful examination of the 170 other proposals revealed certain deficiencies that were easier to 171 address through the creation of a new protocol rather than modifying 172 existing protocols. For example: 174 o COPS-SLS relies upon COPS-PR [RFC3084], which is an Historic RFC. 176 o DSNP is tightly designed with one specific service in mind (QoS) 177 and does not make any distinction between a quotation phase and 178 the actual service ordering phase. 180 One of the primary motivations of this document is to provide a 181 permanent reference to exemplify how service negotiation can be 182 automated. 184 This document is organized as follows: 186 o Section 3 defines the functional elements involved in CPNP 187 exchanges. 188 o Section 4 introduces several order processing models and precises 189 those that are targeted by CPNP. 190 o Section 5 enumerates a non-exhaustive list of use cases that could 191 benefit from CPNP. 193 o Section 5 discusses CPNP deployment models. 194 o Section 7 presents the CPNP negotiation model. 195 o Section 8 provides an overview of the protocol. 196 o Section 9 specifies the CPNP objects. 197 o Section 10 describes the CPNP message validation procedure. 198 o Section 11 specifies the behavior of the involved CPNP functional 199 elements. 200 o Section 12 discusses relevant operational guidelines. 201 o Section 13 discusses protocol security aspects. 203 Implementation details are out of scope. An example of required 204 modules and interfaces to implement this specification is sketched in 205 Section 4 of [AGAVE]. This specification builds on that effort. 207 2. Terminology 209 This document makes use of the following terms: 211 Customer: Is a business role which denotes an entity that is 212 involved in the definition and the possible negotiation of a 213 contract, including a Connectivity Provisioning Agreement, with a 214 Provider. A connectivity provisioning contract is captured in a 215 dedicated CPP template-based document, which specifies (among 216 other information): the sites to be connected, border nodes, 217 outsourced operations (e.g., routing, force via points). 219 The right to invoke the subscribed service may be delegated by the 220 Customer to third-party End Users, or brokering services. 222 A Customer can be a Service Provider, an application owner, an 223 enterprise, a user, etc. 225 Network Provider (or Provider): Owns and administers one or many 226 transport domain(s) (typically Autonomous System (AS)) composed of 227 IP switching and transmission resources (e.g., routing, switching, 228 forwarding, etc.). Network Providers are responsible for ensuring 229 connectivity services (e.g., offering global or restricted 230 reachability at specific rates). Offered connectivity services 231 may not necessarily be restricted to IP. 233 The policies to be enforced by the connectivity service delivery 234 components can be derived from the technology-specific clauses 235 that might be included in contracts agreed with the Customers. If 236 no such clauses are included in the agreement, the mapping between 237 the connectivity requirements and the underlying technology- 238 specific policies to be enforced is deployment-specific. 240 Quotation Order: Denotes a request made by the Customer to the 241 Provider that includes a set of requirements. The Customer may 242 express its service-specific requirements by assigning (fixed or 243 loosely defined) values to the information items included in the 244 commonly understood template (e.g., CPP template) describing the 245 offered service. These requirements constitute the parameters to 246 be mutually agreed upon. 248 Offer: Refers to a response made by the Provider to a Customer 's 249 quotation order as to the extent at which the Provider may satisfy 250 the order at the time of its receipt. Offers reflect the 251 capability of the Provider in accommodating received Customer 252 orders beyond monolithic 'yes/no' answers. 254 An offer may fully or partially meet the requirements of the 255 corresponding order. In the latter case, it may include 256 alternative suggestions which the Customer may take into account 257 by issuing a new order. 259 Agreement: Refers to an order placed by the Customer and accepted by 260 the Provider. It signals the successful conclusion of a 261 negotiation cycle. 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 265 "OPTIONAL" in this document are to be interpreted as described in BCP 266 14 [RFC2119][RFC8174] when, and only when, they appear in all 267 capitals, as shown here. 269 3. CPNP Functional Elements 271 The following functional elements are defined: 273 CPNP client (or client): Denotes a software instance that sends 274 CPNP requests and receives CPNP responses. The current operations 275 that can be performed by a CPNP client are listed below: 277 1. Create a quotation order (Section 9.2.1). 279 2. Cancel an ongoing quotation order under negotiation 280 (Section 9.2.7). 282 3. Accept an offer made by a server (Section 9.2.4). 284 4. Withdraw an agreement (Section 9.2.8). 286 5. Update an agreement (Section 9.2.9). 288 CPNP server (or server): Denotes a software instance that receives 289 CPNP requests and sends back CPNP responses accordingly. The CPNP 290 server is responsible for the following operations: 292 1. Process a quotation order (Section 9.2.2). 294 2. Make an offer (Section 9.2.3). 296 3. Cancel an ongoing quotation order (Section 11.2.3). 298 4. Process an order withdrawal (Section 11.2.3). 300 4. Order Processing Models 302 For preparing their service orders, the Customers may need to be 303 aware of the offered services. The Providers therefore should first 304 proceed with the announcement of the services that they can provide. 305 The service announcement process may take place at designated global 306 or Provider-specific service markets, or through explicit 307 interactions with the Providers. The details of this process are 308 outside the scope of a negotiation protocol. 310 With or without such service announcement mechanisms in place, the 311 following order processing models can be distinguished: 313 Frozen model: 315 The Customer cannot actually negotiate the parameters of the 316 service(s) offered by a Provider. After consulting the Provider's 317 service portfolio, the Customer selects the service offer he/she 318 wants to subscribe and places an order to the Provider. Order 319 handling is quite simple on the Provider side because the service 320 is not customized as per Customer's requirements, but rather pre- 321 designed to target a group of customers having similar 322 requirements (i.e., these customers share the same Customer 323 Provisioning Profile). This mode can be implemented using 324 existing tools such as [RFC8309]. 326 Negotiation-based model: 328 Unlike the frozen model, the Customer documents his/her 329 requirements in a request for a quotation, which is then sent to 330 one or several Providers. Solicited Providers check whether they 331 can address these requirements or not, and get back to the 332 Customer accordingly, possibly with an offer that may not exactly 333 match customer's requirements (e.g., a 100 Mbps connection cannot 334 be provisioned given the amount of available resources, but an 80 335 Mbps connection can be provided). A negotiation between the 336 Customer and the Provider(s) then follows to the end of reaching 337 an agreement (or not). 339 Both frozen and negotiation-based models require the existence of 340 appropriate service templates like a CPP template and their 341 instantiation for expressing specific offerings from Providers and 342 service requirements from Customers, respectively. CPNP can be used 343 in either model for automating the required Customer-Provider 344 interactions. Since the frozen model can be seen as a special case 345 of the negotiation-based model, not only 'yes/no' answers but also 346 counter offers may be issued by the Provider in response to Customer 347 orders, this document focuses on the negotiation-based model. 349 Order processing management on the Network Provider's side is usually 350 connected with the following functional blocks: 352 o Network Provisioning (including Order Activation, Network 353 Planning, etc.) 354 o Authentication, Authorization and Accounting (AAA) 355 o Network and service management (performance verification, 356 complaint analysis, etc.) 357 o Sales-related functional blocks (e.g., billing, invoice 358 validation) 359 o Network Impact Analysis 361 CPNP does not assume any specific knowledge about these functional 362 blocks, drawing an explicit line between protocol operation and the 363 logic for handling connectivity provisioning requests. Evidently 364 order handling logic is subject to the information manipulated by 365 these blocks. For example, the resources that can be allocated to 366 accommodate Customer's requirements may depend on network 367 availability estimates as calculated by the planning functions and 368 related policies as well as on the number of orders to be processed 369 simultaneously over a given period of time. 371 This document does not elaborate on how Customers are identified and 372 subsequently managed by the Provider's Information System. 374 5. Sample Use Cases 376 A non-exhaustive list of CPNP use cases is provided below: 378 1. [RFC4176] introduces the L3VPN Service Order Management 379 functional block which is responsible for managing the requests 380 initiated by the Customers and tracks the status of the 381 completion of the related operations. CPNP can be used between 382 the Customer and the Provider to negotiate L3VPN service 383 parameters. 385 A CPNP server could therefore be part of the L3VPN Service Order 386 Management functional block discussed in [RFC4176]. A YANG data 387 model for L3VPN service delivery is defined in [RFC8299]. 389 2. CPNP can be used between two adjacent domains to deliver IP 390 interconnection services (e.g., enable, update, disconnect). 391 For example, two Autonomous Systems (ASes) can be connected via 392 several interconnection points. CPNP can be used between these 393 ASes to upgrade existing links, request additional resources, 394 provision a new interconnection point, etc. 396 See, for example, the framework documented in [ETICS]. 398 3. An integrated Provider can use CPNP to rationalize connectivity 399 provisioning needs related to its service portfolio. A CPNP 400 server function is used by network operations teams. A CPNP 401 interface to invoke CPNP negotiation cycles is exposed to 402 service management teams. 404 4. Service Providers can use CPNP to initiate connectivity 405 provisioning requests towards a number of Network Providers so 406 that to optimize the cost of delivering their services. 407 Although multiple CPNP ordering cycles can be initiated by a 408 Service Provider towards multiple Network Providers, a subset of 409 these orders may actually be put into effect. 411 For example, a cloud Service Provider can use CPNP to request 412 more resources from Network Providers. 414 5. CPNP can also be used in the context of network slicing 415 ([I-D.geng-netslices-architecture]) to request for network 416 resources together with a set of requirements that need to be 417 satisfied by the Provider. Such requirements are not restricted 418 to basic IP forwarding capabilities, but may also include a 419 characterization of a set of service functions that may be 420 invoked. 422 6. CPNP can be used in Machine-to-Machine (M2M) environments to 423 dynamically subscribe to M2M services (e.g., access to data 424 retrieved by a set of sensors, extend sensor coverage, etc.). 426 Also, Internet of Things (IoT, [RFC6574]) domains may rely on 427 CPNP to enable dynamic provisioning of data produced by involved 428 objects, according to their specific policies, to various 429 external stakeholders such as data analytics and business 430 intelligence companies. Direct CPNP-based interactions between 431 IoT domains and interested parties enable open access to diverse 432 sets of data across the Internet, e.g., from multiple types of 433 sensors, user groups and/or geographical areas. 435 7. CPNP can be used in the context of I2NSF ([RFC8329]) to capture 436 the customer-driven policies to be enforced by a set of Network 437 Security Functions. 439 8. A Provider offering cloud services can expose a CPNP interface 440 to allow Customers to dynamically negotiate related service 441 features such as additional storage, processing and networking 442 resources, enhanced security filters, etc. 444 9. In the inter-cloud context (also called cloud of clouds or cloud 445 federation), CPNP can be used to reserve external computing and 446 networking resources in other cloud environments. 448 10. CDN Providers can use CPNP to extend their footprint by 449 interconnecting their CDN infrastructure [RFC6770] (see 450 Figure 1). 452 ,--,--,--. ,--,--,--. 453 ,-' `-. ,-' `-. 454 (CDN Provider 'A')=====(CDN Provider 'B') 455 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 456 `--'--'--' `--'--'--' 458 Figure 1: CDN Interconnection 460 11. Mapping Service Providers (MSPs, [RFC7215]) can use CPNP to 461 enrich their mapping database by interconnecting their mapping 462 system (see Figure 2). This interconnection allows to relax the 463 constraints on PxTR in favour of native LISP forwarding 464 [RFC6830]. Also, it allows to prevent fragmented LISP mapping 465 database. A framework is described in 466 [I-D.boucadair-lisp-idr-ms-discovery]. 468 ,--,--,--. ,--,--,--. 469 ,-' `-. ,-' `-. 470 (Mapping System 'A')===(Mapping System 'B') 471 `-. ,-' `-. ,-' 472 `--'--'--' `--'--'--' 474 Figure 2: LISP Mapping System Interconnect 476 CPNP may also be used between SDN controllers in contexts where 477 Cooperating Layered Architecture for Software-Defined Networking 478 (CLAS) is enabled [RFC8597]. 480 6. CPNP Deployment Models 482 Several CPNP deployment models can be envisaged. Two examples are 483 listed below: 485 o The Customer deploys a CPNP client while one or several CPNP 486 servers are deployed by the Provider. 487 o The Customer does not enable any CPNP client. The Provider 488 maintains a Customer Order Management portal. The Customer can 489 initiate connectivity provisioning quotation orders via the 490 portal; appropriate CPNP messages are then generated and sent to 491 the relevant CPNP server. In this model, both the CPNP client and 492 CPNP server are under the responsibility of the same 493 administrative entity (i.e., Network Provider). 495 Once the negotiation of connectivity provisioning parameters is 496 successfully concluded that is, an order has been placed by the 497 Customer, the actual network provisioning operations are initiated. 498 The specification of related dynamic resource allocation and policy 499 enforcement schemes, as well as how CPNP servers interact with the 500 network provisioning functional blocks at Provider sides are out of 501 the scope of this document. 503 This document does not make any assumption about the CPNP deployment 504 model either. 506 7. CPNP Negotiation Model 508 CPNP runs between a Customer and a Provider carrying service orders 509 from the Customer and respective responses from the Provider to the 510 end of reaching a service provisioning agreement. As the services 511 offered by the Provider are well-described, by means of the CPP 512 template for connectivity matters, the negotiation process is 513 essentially a value-settlement process, where an agreement is pursued 514 on the values of the commonly understood information items (service 515 parameters) included in the service description template 516 (Section 9.1.9). 518 The protocol is transparent to the content that it carries and to the 519 negotiation logic, at Customer and Provider sides, that manipulates 520 the content. 522 The protocol aims at facilitating the execution of the negotiation 523 logic by providing the required generic communication primitives. 525 Since negotiations are initiated and primarily driven by the 526 Customer's negotiation logic, it is reasonable to assume that the 527 Customer can only call for an agreement. An implicit approach is 528 adopted for not overloading the protocol with additional messages. 529 In particular, the acceptance of an offer made by the Provider 530 signals a call for agreement from the Customer. Note that it is 531 almost certain the Provider to accept this call since it refers to an 532 offer that itself made. Of course, at any point the Provider or the 533 Customer may quit the negotiations, each on its own grounds. 535 Based on the above, CPNP adopts a Quotation Order/Offer/Answer model, 536 which proceeds through the following basic steps (Figure 3): 538 1. The client specifies its service requirements via a Provision 539 Quotation Order (PQO). The order may include fixed or loosely 540 defined values in the clauses describing service provisioning 541 characteristics. 543 2. The server declines the PQO, or makes an offer to address the 544 requirements of the PQO, or which may suggests a counter- 545 proposals that partially addresses the requirements of the PQO 546 for specific requirements that cannot be accommodated. 548 3. The client either accepts or declines the offer. Accepting the 549 offer implies a call for agreement. 551 +------+ +------+ 552 |Client| |Server| 553 +------+ +------+ 554 |=====Requested Service=====>| 555 |<=====Offered Service=======| 556 |======Agreed Service=======>| 558 Figure 3: Simplified Service Negotiation 560 Multiple instances of CPNP may run at Customer or Provider domains. 561 A CPNP client may be engaged simultaneously in multiple negotiations 562 with the same or different CPNP servers (parallel negotiations, see 563 Section 8.9) and a CPNP server may need to negotiate with other 564 Provider(s) as part of negotiations with a CPNP client (cascaded 565 negotiations, see Section 8.8). 567 CPNP relies on various timers to achieve its operations. Two types 568 of timers are defined: those that are specific to CPNP message 569 transmission and those that are specific to the negotiation logic. 570 The latter are used to guide the negotiation logic at both CPNP 571 client and CPNP server sides, particularly in cases where the CPNP 572 client is involved in parallel negotiations with several CPNP servers 573 or in cases where the CPNP server is, in its turn, involved in 574 negotiations with other Providers for processing a given quotation 575 order. Related to the above, CPNP allows the CPNP server to request 576 for more time. This request may be accepted or rejected by the CPNP 577 client. 579 Providers may need to publish available services to the Customers 580 (see Section 4). CPNP may optionally support this functionality. 581 Dedicated templates can be defined for the purpose of service 582 announcements, which will be used by the CPNP clients to initiate 583 their CPNP negotiation cycles. 585 For simplicity, a single Offer/Answer stage is assumed within one a 586 CPNP negotiation cycle. Nevertheless, as stated before, multiple 587 CPNP negotiation cycles can be undertaken by a CPNP client (see 588 Figure 4). 590 The model is flexible as it can accommodate changing conditions over 591 time (e.g., introduction of an additional VPN site). 593 +------+ +------+ +------+ +------+ 594 |Client| |Server| |Client| |Server| 595 +------+ +------+ +------+ +------+ 596 |=====Quotation Order=====>| |=====Quotation Order=====>| 597 |<==========Offer==========| |<==========Offer==========| 598 |===========Accept========>| |==========Decline========>| 600 1-Step Successful Negotiation 1-Step Failed Negotiation 601 Cycle Cycle 603 +------+ +------+ +------+ +------+ 604 |Client| |Server| |Client| |Server| 605 +------+ +------+ +------+ +------+ 606 |===Quotation Order(a)====>| |===Quotation Order(i)====>| 607 |<==========Offer==========| |<==========Offer==========| 608 |==========Decline========>| |==========Decline========>| 609 |===Quotation Order(b)====>| |===Quotation Order(j)====>| 610 |<==========Offer==========| |<==========Offer==========| 611 |===========Accept========>| |==========Decline========>| 612 |===Quotation Order(k)====>| 613 |<==========Offer==========| 614 |==========Decline========>| 615 |===Quotation Order(l)====>| 616 |<==Fail to make an offer==| 618 N-Step Negotiation Cycle: N-Step Negotiation Cycle: 619 Successful Negotiation Failed Negotiation 621 Figure 4: Overall Negotiation Process 623 This version of the protocol does not support means for a client to 624 retrieve a list of active/agreed offers. 626 8. Protocol Overview 628 8.1. Client/Server Communication 630 CPNP is a client/server protocol can run over any transport protocol 631 with UDP being the default transport mode secured with Datagram 632 Transport Layer Security (DTLS) [RFC6347]. No permanent CPNP 633 transport session needs to be maintained between the client and the 634 server. 636 The CPNP client can be configured with the CPNP server(s) (typically, 637 an IP address together with a port number) using manual or dynamic 638 configuration means. For example, a Provider advertises the port 639 number (CPNP_PORT) it uses to bind the CPNP service (e.g., using SRV 640 [RFC2782]). 642 The client sends CPNP messages to CPNP_PORT. The same port number 643 used as the source port number of a CPNP request sent to the server 644 MUST be used by the server to reply to that request. 646 CPNP is independent of the IP address family. 648 CPNP retransmission is discussed in Section 11.4 for unreliable 649 transports. 651 8.2. Policy Configuration on the CPNP Server 653 As an input to its decision-making process, the CPNP server may be 654 connected to various external modules such as: Customer Profiles, 655 Network Topology, Network Resource Management, Orders Repository, AAA 656 and Network Provisioning Manager (an example is shown in Figure 5). 658 These external modules provide inputs to the CPNP server, so that it 659 can: 661 o Check whether a customer is entitled to initiate a provisioning 662 quotation request. 664 o Check whether a customer is entitled to cancel an ongoing order. 666 o Check whether administrative data (e.g., billing-related 667 information) have been verified before starting handling the 668 request. 670 o Check whether network capacity is available or additional capacity 671 is required. 673 o Receive guidelines from network design and sales blocks (e.g., 674 pricing, network usage levels, threshold on number of CPP 675 templates that can be processed over a given period of time as a 676 function of the nature of the service to be delivered, etc.). 678 o Transfer completed orders to network provisioning blocks. For 679 example, the outcome of CPNP may be passed to modules such as 680 Application-Based Network Operations (ABNO) [RFC7491] or network 681 controllers. These controllers will use protocols such as NETCONF 682 [RFC6241] to interact with the appropriate network nodes and 683 functions for the sake of proper service activation and delivery. 685 The above list of CPNP server operations is not exhaustive. 687 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688 .Business & Administrative Management . 689 .+------------------------++---------------------------+. 690 .| Business Guidelines || Billing & Charging |. 691 .+-----------+------------++-----------+---------------+. 692 . | | . 693 . +-------------------+ | . 694 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 695 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 696 .Order Handling Management | | . 697 . +-------------------+ +-------+-----+--------------+ . 698 . |Network Topology DB+--+ CPNP Server | . 699 . +-------------------+ +-+---+---+---+---+-----+----+ . 700 . | | | | | | . 701 . +------------------------+-+ | | | | | . 702 . | Network Dimensioning | | | | | | . 703 . | & Planning | | | | | | . 704 . +--------------------------+ | | | | | . 705 . +----------------------------+-+ | | | +---+----+ . 706 . | | | | | | AAA | . 707 . | Network +------------+ | | | +--------+ . 708 . | Resource | +------------+-+ | +-+----------+ . 709 . | Management | | Customer | | | Orders | . 710 . | | | Profiles | | | Repository | . 711 . +-----------------+ +--------------+ | +------------+ . 712 . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . 713 +--------------------------------------+----------------+ 714 | Network Provisioning Manager | 715 +-------------------------------------------------------+ 717 Figure 5: Order Handling Management Functional Block 719 The following order handling modes can be also configured on the 720 server: 722 1. Fully automated mode: This mode does not require any action from 723 the administrator when receiving a request for a service. The 724 server can execute its decision-making process related to the 725 orders received and generate corresponding offers. 727 2. Administrative validation checking: Some or all of the server's 728 operations are subject to administrative validation procedures. 729 This mode requires an action from the administrator for every 730 request received. The CPNP methods which can be automatically 731 handled by the server or they are subject to one or several 732 validation administrative checks can be configured on the server. 734 8.3. CPNP Session Entries 736 A CPNP session entry is denoted by a 5-uplet defined as follows: 738 o Transport session (typically, IP address of the client, client's 739 port number, IP address of the server, and server's port number). 741 o Incremented Sequence Number (Section 11.3) 743 o Customer Agreement Identifier: This is a unique identifier 744 assigned to the order under negotiation by the client 745 (Section 9.1.1). This identifier is also used to identify the 746 agreement that will result from a successful negotiation. 748 o Provider Agreement Identifier: This is a unique identifier 749 assigned to the order under negotiation by the server 750 (Section 9.1.2). This identifier is also used to identify the 751 agreement that will result from a successful negotiation. 753 o Transaction-ID (Section 9.1.3). 755 8.4. CPNP Transaction 757 A CPNP transaction occurs between a client and a server for pursuing, 758 modifying, withdrawing a service agreement, and comprises all CPNP 759 messages exchanged between the client and the server, from the first 760 request sent by the client to the final response sent by the server. 761 A CPNP transaction is bound to a CPNP session (Section 8.3). 763 Because multiple CPNP transactions can be maintained by the CPNP 764 client, the client must assign an identifier to uniquely identify a 765 given transaction. This identifier is denoted as Transaction-ID. 767 The Transaction-ID must be randomly assigned by the CPNP client, 768 according to the best current practice for generating random numbers 769 [RFC4086] that cannot be guessed easily. Transaction-ID is used for 770 validating CPNP responses received by the client. 772 In the context of a transaction, the client needs to randomly select 773 a sequence number and assign it in the first CPNP message to send. 774 This number is then incremented for each request message is 775 subsequently sent within the ongoing CPNP transaction (see 776 Section 11.3). 778 8.5. CPNP Timers 780 CPNP adopts a simple retransmission procedure which relies on a 781 retransmission timer denoted as RETRANS_TIMER and maximum retry 782 threshold. The use of RETRANS_TIMER and a maximum retry threshold 783 are described in Section 11. 785 The response timer (RESPONSE_TIMER) is set by the client to denote 786 the time, in seconds, the client will wait for receiving a response 787 from the server to a provisioning quotation order request (see 788 Section 9.1.6). If the timer expires, the respective quotation order 789 is cancelled by the client and a CANCEL message is generated 790 accordingly. 792 An offer expiration timer (EXPIRE_TIMER) is set by the server to 793 represent the time, in minutes, after which an offer made by the 794 server will be invalid (see Section 9.1.8). 796 8.6. CPNP Operations 798 CPNP operations are listed below. They may be augmented, depending 799 on the nature of some transactions or because of security 800 considerations that may necessitate a distinct CPNP client/server 801 authentication phase before negotiation begins. 803 o QUOTATION (Section 9.2.1): 805 This operation is used by the client to initiate a provisioning 806 quotation order. Upon receipt of a QUOTATION request, the server 807 may respond with a PROCESSING, OFFER or a FAIL message. A 808 QUOTATION-initiated transaction can be terminated by a FAIL 809 message. 811 o PROCESSING (Section 9.2.2): 813 This operation is used to inform the remote party that the message 814 (the order quotation or the offer) sent was received and it is 815 processed. This message can also be issued by the server to 816 request more time, in which case the client may reply with an ACK 817 or FAIL message depending on whether more time can or cannot be 818 granted. 820 o OFFER (Section 9.2.3): 822 This operation is used by the server to inform the client about an 823 offer that can best accommodate the requirements indicated in the 824 previously received QUOTATION message. 826 o ACCEPT (Section 9.2.4): 828 This operation is used by the client to confirm the acceptance of 829 an offer made by the server. This message implies a call for 830 agreement. An agreement is reached when an ACK is subsequently 831 received from the server, which is likely to happen; it is rather 832 unlikely the server to reject an offer that it has already made. 834 o DECLINE (Section 9.2.5): 836 This operation is used by the client to reject an offer made by 837 the server. The ongoing transaction may not be terminated 838 immediately, e.g., the server/client may issue another offer/ 839 order. 841 o ACK (Section 9.2.6): 843 This operation is used by the server to acknowledge the receipt of 844 an ACCEPT or WITHDRAW message, or by the client to confirm the 845 time extension requested by the server for processing the last 846 received quotation order. 848 o CANCEL (Section 9.2.7): 850 This operation is used by the client to cancel (quit) the ongoing 851 transaction. 853 o WITHDRAW (Section 9.2.8): 855 This operation is used by the client to withdraw an agreement. 857 o UPDATE (Section 9.2.9): 859 This operation is used by the client to update an existing 860 agreement. For example, this method can be invoked to add a new 861 site. This method will trigger a new negotiation cycle. 863 o FAIL (Section 9.2.10): 865 This operation is used by the server to indicate that it cannot 866 accommodate the requirements documented in the PQO conveyed in the 867 QUOTATION message or to inform the client about an error 868 encountered when processing the received message. In either case, 869 the message implies that the server is unable to make offers and 870 as such it terminates the ongoing transaction. 872 This message is also used by the client to reject a time extension 873 request received from the server (in a PROCESSING message). The 874 message includes a status code for providing explanatory 875 information. 877 The above CPNP primitives are service-independent. CPNP messages may 878 transparently carry service-specific objects which are handled by the 879 negotiation logic at either side. 881 The document specifies the service objects that are required for 882 connectivity provisioning negotiation (see Section 8.7). Additional 883 service-specific objects to be carried in the CPNP messages can be 884 defined in the future for accommodating alternative deployment or 885 other service provisioning needs. 887 8.7. Connectivity Provisioning Documents 889 CPNP makes use of several flavors of Connectivity Provisioning 890 Documents (CPD). These documents follow the same CPP template 891 described in [RFC7297]. 893 Requested Connectivity Provisioning Document (Requested CPD): 894 Refers to the CPD included by a CPNP client in a QUOTATION 895 request. 897 Offered Connectivity Provisioning Document (Offered CPD): This 898 document is included by a CPNP server in an OFFER message. Its 899 information reflects the proposal of the server to accommodate all 900 or a subset of the clauses depicted in a Requested CPD. A 901 validity time is associated with the offer made. 903 Agreed Connectivity Provisioning Document (Agreed CPD): If the 904 client accepts an offer made by the server, the Offered CPD is 905 included in an ACCEPT message. This CPD is also included in an 906 ACK message. Thus, a 3-way hand-shaking procedure is followed for 907 successfully concluding the negotiation. 909 Figure 6 shows a typical CPNP negotiation cycle and the use of the 910 different types of Connectivity Provisioning Documents. 912 +------+ +------+ 913 |Client| |Server| 914 +------+ +------+ 915 |======QUOTATION (Requested CPD)=====>| 916 |<============PROCESSING==============| 917 |<========OFFER (Offered CPD)=========| 918 |=============PROCESSING=============>| 919 |=========ACCEPT (Agreed CPD)========>| 920 |<=========ACK (Agreed CPD)===========| 921 | | 923 Figure 6: Connectivity Provisioning Documents 925 A provisioning document can include parameters with fixed values, 926 loosely defined values, or a combination thereof. A provisioning 927 document is said to be concrete if all clauses have fixed values. 929 A typical evolution of a negotiation cycle would start with a 930 quotation order with loosely defined parameters, and then, as offers 931 are made, it would conclude with concrete provisioning document for 932 calling for the agreement. 934 8.8. Child Provisioning Quotation Orders 936 If the server detects that network resources from another Network 937 Provider need to be allocated in order to accommodate the 938 requirements described in a PQO (e.g., in the context of an inter- 939 domain VPN service, additional PE router resources need to be 940 allocated), the server may generate child PQOs to request the 941 appropriate network provisioning operations (see Figure 7). In such 942 situation, the server behaves also as a CPNP client. The server 943 associates the parent order with its child PQOs. This is typically 944 achieved by locally adding the reference of the child PQO to the 945 parent order. 947 +------+ +--------+ +--------+ 948 |Client| |Server A| |Server B| 949 +------+ +--------+ +--------+ 950 | | | 951 |=====QUOTATION=====>| | 952 |<====PROCESSING=====| | 953 | |=====QUOTATION=====>| 954 | |<====PROCESSING=====| 955 | |<=======OFFER=======| 956 | |=====PROCESSING====>| 957 | |=======ACCEPT======>| 958 | |<=======ACK=========| 959 |<=======OFFER=======| | 960 |=====PROCESSING====>| | 961 |=======ACCEPT======>| | 962 |<=======ACK=========| | 963 | | | 965 Figure 7: Example of Child Orders 967 8.9. Negotiating with Multiple CPNP Servers 969 A CPNP client may undertake multiple negotiations in parallel with 970 several servers for practical reasons such as cost optimization and 971 fail-safety. The multiple negotiations may lead to one or many 972 agreements. Multiple negotiations with the same Provider are not 973 precluded. 975 The salient point underlining the parallel negotiations scenario is 976 that although the negotiation protocol is strictly between two 977 parties, the negotiation logic may not necessarily be. The CPNP 978 client negotiation logic may need to collectively drive parallel 979 negotiations, as the negotiation with one server may affect the 980 negotiation with other servers; e.g., it may need to use the 981 responses from all servers as input for determining the messages (and 982 their content) to subsequently send in each individual negotiation. 983 Timing is therefore an important aspect at the client's. The CPNP 984 client needs to have the ability to synchronize the receipt of the 985 responses from the servers. CPNP takes into account this requirement 986 by allowing clients to specify in the QUOTATION message the time by 987 which the server needs to respond (see Section 9.1.6). 989 8.10. State Management 991 Both the client and the server maintain repositories to store ongoing 992 orders. How these repositories are maintained is deployment- 993 specific. It is out of scope of this document to elaborate on such 994 considerations. Timestamps are also logged to track state change. 996 Tracking may be needed for various reasons, including regulatory 997 ones. 999 In order to accommodate failures that may lead to the reboot of the 1000 client or the server, the use of permanent storage is recommended, 1001 thereby facilitating state recovery. 1003 8.10.1. On the Client Side 1005 The following lists the states which can be associated with a given 1006 order on the client's side: 1008 o Created: when the order has been created. It is not handled by 1009 the client until the administrator allows to process it. 1011 o AwaitingProcessing: when the administrator approved of processing 1012 a created order and the order has not been handled yet. 1014 o PQOSent: when the order has been sent to the server. 1016 o ServerProcessing: when the server has confirmed the receipt of the 1017 order. 1019 o OfferReceived: when an offer has been received from the server. 1021 o OfferProcessing: when a received offer is currently processed by 1022 the client. 1024 o AcceptSent: when the client confirmed the offer to the server. 1026 o AcceptAck: when the offer is acknowledged by the server. 1028 o Cancelled: when the order has failed or cancelled. 1030 +------------------+ 1031 | Created |-----------------+ 1032 +------------------+ | 1033 | | 1034 v | 1035 +------------------+ | 1036 |AwaitingProcessing|----------------+| 1037 +------------------+ || 1038 | || 1039 QUOTATION || 1040 v || 1041 +------------------+ || 1042 | PQOSent |---CANCEL------+|| 1043 +------------------+ vvv 1044 | +-----+ 1045 PROCESSING | | 1046 v | | 1047 +------------------+ CANCEL | C | 1048 | ServerProcessing |------------>| A | 1049 +------------------+ FAIL | N | 1050 | | C | 1051 | | E | 1052 OFFER | L | 1053 | | L | 1054 v | E | 1055 +------------------+ | D | 1056 | OfferReceived |---CANCEL--->| | 1057 +------------------+ | | 1058 | PROCESSING +-----+ 1059 v ^^^ 1060 +------------------+ ||| 1061 | OfferProcessing |---DECLINE-----+|| 1062 +------------------+ || 1063 | ACCEPT || 1064 v || 1065 +------------------+ || 1066 | AcceptSent |---CANCEL-------+| 1067 +------------------+ | 1068 | ACK | 1069 v | 1070 +------------------+ | 1071 | AcceptAck |---WITHDRAW------+ 1072 +------------------+ 1074 Figure 8: CPNP Finite State Machine (Client Side) 1076 8.10.2. On the Server Side 1078 The following lists the states which can be associated with a given 1079 order and a corresponding offer on the server's side: 1081 o PQOReceived: when the order has been received from the client. 1083 o AwaitingProcessing: when the order is being processed by the 1084 server. An action from the server administrator may be needed. 1086 o OfferProposed: when the request has been successfully handled and 1087 an offer has been sent to the client. 1089 o ProcessingReceived: when the server received a PROCESSING for an 1090 offer sent to the client. 1092 o AcceptReceived: when the server received a confirmation for the 1093 offer from the client. 1095 o AcceptAck: when the server acknowledged the offer (accepted by 1096 client) to the client. 1098 o Cancelled: when the order has failed to be met or it has been 1099 cancelled by the client. Associate resources must be released in 1100 the latter case, if prior reserved. 1102 o ChildCreated: when a child order has been created in cases where 1103 resources from another Network Provider are needed. 1105 o ChildPQOSent: when a child order has been sent to the remote 1106 server. 1108 o ChildServerProcessing: when a child order is currently processed 1109 by the remote server. 1111 o ChildOfferReceived: when an offer has been received to a child 1112 order from the remote server. 1114 o ChildOfferProcessing: when a received offer to a child order is 1115 currently processed. 1117 o ChildAcceptSent: when the child offer (offer received from the 1118 remote server in response to a child order) is confirmed to the 1119 remote server. 1121 o ChildAcceptAck: when an accepted child offer is acknowledged by 1122 the remote server. 1124 +------------------+ 1125 +---------------------| ChildCreated | 1126 | +------------------+ 1127 v | ^ 1128 +------------------+ | | 1129 | ChildPQOSent |----------------+| Q 1130 +------------------+ || U 1131 | || O 1132 QUOTATION || T 1133 v || A +--------------------+ 1134 +---------------------+ CANCEL || T | PQOReceived | 1135 |ChildServerProcessing|------------+|| I +--------------------+ 1136 +---------------------+ FAIL vvv O | | 1137 | +-----+ N CANCEL | 1138 PROCESSING | |<---|-------+ PROCESSING 1139 v | | | v 1140 +------------------+ | | +------------------------+ 1141 |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | 1142 +------------------+ | A | +------------------------+ 1143 | | N | ^ | OFFER 1144 OFFER | C | | +------------------+ 1145 | | E | ::= 1304 ... 1305 ::= 1306 ... 1307 ::= 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 ::= ... 1322 ::= 1323 1324 1326 Figure 10: The RBNF format of the Connectivity Provisioning Document 1327 (CPD) 1329 9.1.10. CPNP Information Elements 1331 An Information Element (IE) is an optional object which can be 1332 included in a CPNP message. 1334 9.1.10.1. Customer Description 1336 The client may include administrative information such as: 1338 o Name 1339 o Contact Information 1341 The format of this Information Element is as follows: 1343 ::= [] [] 1344 ::= [] [] 1345 [ ...] 1347 9.1.10.2. Provider Description 1349 The server may include administrative information in an offer such 1350 as: 1352 o Name 1353 o AS Number ([RFC6793]) 1354 o Contact Information 1356 The format of this Information Element is as follows: 1358 ::= [][][] 1360 9.1.10.3. Negotiation Options 1362 The client may include some negotiation options such as: 1364 o Setup purpose: A client may request to setup a connectivity only 1365 for testing purposes during a limited period. The order can be 1366 extended to become permanent if the client was satisfied during 1367 the test period. This operation is achieved using the UPDATE 1368 method. 1370 The format of this Information Element is as follows: 1372 ::= [] 1374 9.2. Operation Messages 1376 This section specifies the RBNF format of CPNP operation messages. 1377 The following operation codes are used: 1379 1: QUOTATION (Section 9.2.1) 1380 2: PROCESSING (Section 9.2.2) 1381 3: OFFER (Section 9.2.3) 1382 4: ACCEPT (Section 9.2.4) 1383 5: DECLINE (Section 9.2.5) 1384 6: ACK (Section 9.2.6) 1385 7: CANCEL (Section 9.2.7) 1386 8: WITHDRAW (Section 9.2.8) 1387 9: UPDATE (Section 9.2.9) 1388 10: FAIL (Section 9.2.10) 1390 9.2.1. QUOTATION 1392 The format of the QUOTATION message is shown below: 1394 ::= 1395 1396 1397 1398 1399 [] 1400 1401 [...] 1403 A QUOTATION message MUST include an order identifier which is 1404 generated by the client. Because several orders can be issued to 1405 several servers, the QUOTATION message MUST also include a 1406 Transaction-ID. 1408 The message MAY include an EXPECTED_RESPONSE_TIME which indicates by 1409 when the client is expecting to receive an offer from the server. 1410 QUOTATION message MUST also include a requested service description 1411 (that is, requested connectivity provisioning document for 1412 connectivity services). 1414 When the client sends the QUOTATION message to the server, the state 1415 of the order changes to "PQOSent". 1417 9.2.2. PROCESSING 1419 The format of the PROCESSING message is shown below: 1421 ::= 1422 1423 1424 1425 1426 1427 [] 1429 Upon receipt of a QUOTATION message, the server proceeds with parsing 1430 rules (see Section 10). If no error is encountered, the server 1431 generates a PROCESSING response to the client to indicate the PQO has 1432 been received and it is being processed. The server MUST generate an 1433 order identifier which identifies the order in its local order 1434 repository. The server MUST copy the content of 1435 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed 1436 in the QUOTATION message. The server MAY include an 1437 EXPECTED_OFFER_TIME by when it expects to make an offer to the 1438 client. 1440 Upon receipt of a PROCESSING message, the client verifies whether it 1441 has issued a PQO to that server and which contains the 1442 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is 1443 found, the PROCESSING message MUST be silently ignored. If a PQO is 1444 found, the client may check if it accepts the EXPECTED_OFFER_TIME and 1445 then, it changes to state of the order to "ServerProcessing". 1447 If more time is required by the server to process the quotation 1448 order, it MAY send a PROCESSING message that includes a new 1449 EXPECTED_OFFER_TIME. The client can answer with an ACK message if 1450 more time is granted (Figure 11) or with a FAIL message if the time 1451 extension is rejected (Figure 12). 1453 +------+ +------+ 1454 |Client| |Server| 1455 +------+ +------+ 1456 |=======QUOTATION(Requested CPD)=====>| 1457 |<========PROCESSING(time1)===========| 1458 ... 1459 |<========PROCESSING(MoreTime)========| 1460 |============ACK(TimeGranted)========>| 1461 ... 1462 |<=========OFFER(Offered CPD)=========| 1463 |=============PROCESSING=============>| 1464 |==========ACCEPT(Agreed CPD)========>| 1465 |<==========ACK(Agreed CPD)===========| 1466 | | 1468 Figure 11: Request More Negotiation Time: Granted 1470 +------+ +------+ 1471 |Client| |Server| 1472 +------+ +------+ 1473 |=======QUOTATION(Requested CPD)=====>| 1474 |<========PROCESSING(time1)===========| 1475 ... 1476 |<========PROCESSING(MoreTime)========| 1477 |===========FAIL(TimeRejected)=======>| 1479 Figure 12: Request More Negotiation Time: Rejected 1481 9.2.3. OFFER 1483 The format of the OFFER message is shown below: 1485 ::= 1486 1487 1488 1489 1490 1491 1492 1493 1494 [...] 1496 The server answers with an OFFER message to a QUOTATION request 1497 received from the client. The offer will be considered as rejected 1498 by the client if no confirmation (ACCEPT message sent by the client) 1499 is received by the server before the expiration of the validity time. 1501 9.2.4. ACCEPT 1503 The format of the ACCEPT message is shown below: 1505 ::= 1506 1507 1508 1509 1510 1511 1512 1513 [...] 1515 This message is used by a client to confirm the acceptance of an 1516 offer received from a server. The fields of this message MUST be 1517 copied from the received OFFER message. 1519 9.2.5. DECLINE 1521 The format of the DECLINE message is shown below: 1523 ::= 1524 1525 1526 1527 1528 1529 1531 The client may issue a DECLINE message to reject an offer. 1532 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, 1533 TRANSACTION_ID, and NONCE are used by the server as keys to find the 1534 corresponding order. If an order matches, the server changes the 1535 state of this order to "Cancelled" and then returns an ACK with a 1536 copy of the requested CPD to the requesting client. 1538 If no order is found, the server returns a FAIL message to the 1539 requesting client. 1541 A flow example is shown in Figure 13. 1543 +------+ +------+ 1544 |Client| |Server| 1545 +------+ +------+ 1546 |=======QUOTATION(Requested CPD)=====>| 1547 |<============PROCESSING==============| 1548 |<=========OFFER(Offered CPD)=========| 1549 |=============PROCESSING=============>| 1550 |===============DECLINE==============>| 1551 |<================ACK=================| 1552 | | 1554 Figure 13: DECLINE Flow Example 1556 9.2.6. ACK 1558 The format of the ACK message is shown below: 1560 ::= 1561 1562 1563 1564 1565 1566 [] 1567 [] 1568 [...] 1570 This message is issued by the server to close a CPNP transaction or 1571 by a client to grant more negotiation time to the server. 1573 This message is sent by the server as a response to an ACCEPT, 1574 WITHDRAW, DECLINE, or CANCEL message. In such case, the ACK message 1575 MUST include the copy of the service description document as stored 1576 by the server. In particular, the following considerations are taken 1577 into account for connectivity provisioning services: 1579 o A copy of the requested/offered CPD is included by the server if 1580 it successfully handled a CANCEL message. 1581 o A copy of the updated CPD is included by the server if it 1582 successfully handled an UPDATE message. 1583 o A copy of the offered CPD is included by the server if it 1584 successfully handled an ACCEPT message in the context of a 1585 QUOTATION transaction. 1587 o An empty CPD is included by the server if it successfully handled 1588 a DECLINE message. 1590 A client may issue an ACK message as a response to a more time 1591 request (conveyed in PROCESSING) received from the server. In such 1592 case, the ACK message MUST include an EXPECTED_RESPONSE_TIME that is 1593 likely to be set to the time extension requested by the server. 1595 9.2.7. CANCEL 1597 The format of the CANCEL message is shown below: 1599 ::= 1600 1601 1602 1603 1604 [] 1606 The client can issue a CANCEL message at any stage during the CPNP 1607 negotiation process before an agreement is reached. 1608 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID are used by the 1609 server as keys to find the corresponding order. If a quotation order 1610 matches, the server changes the state of this quotation order to 1611 "Cancelled" and then returns an ACK with a copy of the requested CPD 1612 to the requesting client. 1614 If no quotation order is found, the server returns a FAIL message to 1615 the requesting client. 1617 9.2.8. WITHDRAW 1619 The format of the WITHDRAW message is shown below: 1621 ::= 1622 1623 1624 1625 1626 1627 1628 [] 1629 [...] 1631 This message is used to withdraw an offer already subscribed by the 1632 Customer. Figure 14 shows a typical usage of this message. 1634 +------+ +------+ 1635 |Client| |Server| 1636 +------+ +------+ 1637 |============WITHDRAW(CPD)===========>| 1638 |<============PROCESSING==============| 1639 |<===========ACK(Empty CPD)===========| 1640 | | 1642 Figure 14: WITHDRAW Flow Example 1644 The CPNP MUST include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1645 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1646 the order. 1648 Upon receipt of a WITHDRAW message, the server checks whether an 1649 order matching the request is found. If an order is found, the state 1650 of the order is changed to "Cancelled" and an ACK message including 1651 an Empty CPD is returned to the requesting client. If no order is 1652 found, the server returns a FAIL message to the requesting client. 1654 9.2.9. UPDATE 1656 The format of the UPDATE message is shown below: 1658 ::= 1659 1660 1661 1662 1663 1664 1665 1666 1667 [...] 1669 This message is sent by the CPNP client to update an existing service 1670 agreement (e.g., connectivity provisioning agreement). The CPNP MUST 1671 include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1672 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1673 the order. The CPNP client includes a new service description (e.g., 1674 updated CPD) which integrates the requested modifications. A new 1675 Transaction_ID MUST be assigned by the client. 1677 Upon receipt of an UPDATE message, the server checks whether an 1678 order, having state "Completed", matches 1679 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1680 NONCE. 1682 o If no order is found, the CPNP server generates a FAIL error with 1683 the appropriate error code. 1684 o If an order is found, the server checks whether it can honor the 1685 request: 1687 * A FAIL message is sent to the client if the server cannot honor 1688 the request. The client may initiate a new PQO negotiation 1689 cycle. 1690 * An OFFER message including the updated connectivity 1691 provisioning document is sent to the client. For example, the 1692 server maintains an order for provisioning a VPN service that 1693 connects sites A, B and C. If the client sends an UPDATE 1694 message to remove site C, only sites A and B will be included 1695 in the OFFER sent by the server to the requesting client. 1697 A flow chart that illustrates the use of UPDATE operation is shown in 1698 Figure 15. 1700 +------+ +------+ 1701 |Client| |Server| 1702 +------+ +------+ 1703 |=========UPDATE(Requested CPD)======>| 1704 |<============PROCESSING==============| 1705 |<=========OFFER(Updated CPD)=========| 1706 |=============PROCESSING=============>| 1707 |==========ACCEPT(Updated CPD)=======>| 1708 |<==========ACK(Updated CPD)==========| 1709 | | 1711 Figure 15: UPDATE Flow Example 1713 9.2.10. FAIL 1715 The format of the FAIL message is shown below: 1717 ::= 1718 1719 1720 1721 1722 1723 1725 This message is sent in the following cases: 1727 o The server can not honor an order received from the client (i.e., 1728 received in a QUOTATION or UPDATE request). 1730 o The server encounters an error when processing a CPNP request 1731 received from the client. 1732 o The client can not grant more time to a the server. This is a 1733 response to a more time request conveyed in a PROCESSING message. 1735 The status code indicates the error code. The following codes are 1736 supported: 1738 1 (Message Validation Error): 1739 The message can not be validated (see Section 10). 1740 2 (Authentication Required): 1741 The request cannot be handled because authentication is 1742 required. 1743 3 (Authorization Failed): 1744 The request cannot be handled because authorization failed. 1745 4 (Administratively prohibited): 1746 The request can not be handled because of administrative 1747 policies. 1748 5 (Out of Resources): 1749 The request can not be honored because there is not enough 1750 capacity. 1751 6 (Network Presence Error): 1752 The request can not be honored because there is no network 1753 presence. 1754 7 (More Time Rejected): 1755 The request to extend the time negotiation is rejected by the 1756 client. 1758 10. CPNP Message Validation 1760 Both client and server proceed with CPNP message validation. The 1761 following tables summarize the validation checks to be followed. 1763 10.1. On the Client Side 1764 Operation Validation Checks 1765 ------------ -------------------------------------------------------- 1766 PROCESSING {Source IP address, source port number, destination IP 1767 address, destination port number, Transaction- 1768 ID, Customer Order Identifier} must match an 1769 existing PQO with a state set to "PQOSent". The 1770 sequence number carried in the packet must be larger 1771 than the sequence number maintained by the 1772 client. 1773 OFFER {Source IP address, source port number, destination IP 1774 address, destination port number, Transaction- 1775 ID, Customer Order Identifier} must match an 1776 existing order with state set to "PQOSent" or {Source 1777 IP address, source port number, destination IP address, 1778 destination port number, Transaction-ID, 1779 Customer Order Identifier, Provider Order 1780 Identifier} must match an existing order with a state 1781 set to "ServerProcessing". The sequence number 1782 carried in the packet must be larger than the 1783 sequence number maintained by the client. 1784 ACK {Source IP address, source port number, destination IP 1785 (QUOTATION address, destination port number, Transaction- 1786 Transaction) ID, Customer Order Identifier, Provider Order 1787 Identifier, Offered Connectivity Provisioning Order} 1788 must match an order with a state set to "AcceptSent". 1789 The sequence number carried in the packet must 1790 be larger than the sequence number maintained 1791 by the client. 1792 ACK (UPDATE {Source IP address, source port number, destination IP 1793 Transaction) address, destination port number, Transaction- 1794 ID, Customer Order Identifier, Provider Order 1795 Identifier, Updated Connectivity Provisioning Order} 1796 must match an order with a state set to "AcceptSent". 1797 The sequence number carried in the packet must 1798 be larger than the sequence number maintained 1799 by the client. 1800 ACK {Source IP address, source port number, destination IP 1801 (WITHDRAW address, destination port number, Transaction- 1802 Transaction) ID, Customer Order Identifier, Provider Order 1803 Identifier, Empty Connectivity Provisioning Order} 1804 must match an order with a state set to "Cancelled". The 1805 sequence number carried in the packet must be 1806 larger than the sequence number maintained by 1807 the client. 1809 10.2. On the Server Side 1811 Method Validation Checks 1812 ---------- ---------------------------------------------------------- 1813 QUOTATION The source IP address passes existing access filters (if 1814 any). The sequence number carried in the packet 1815 must not be less than the sequence number 1816 maintained by the server. 1817 PROCESSING The sequence number carried in the packet must be larger 1818 than the sequence number maintained by the 1819 server. 1820 ACCEPT {Source IP address, source port number, destination IP 1821 address, destination port number, Transaction- 1822 ID, Customer Order Identifier, Provider Order 1823 Identifier, Nonce, Offered Connectivity Provisioning 1824 Order} must match an order with state set to 1825 "OfferProposed" or "ProcessngReceived". The 1826 sequence number carried in the packet must be 1827 larger than the sequence number maintained by the server. 1828 DECLINE {Source IP address, source port number, destination IP 1829 address, destination port number, Transaction- 1830 ID, Customer Order Identifier, Provider Order 1831 Identifier, Nonce} must match an order with state set 1832 to "OfferProposed" or "ProcessngReceived". The sequence 1833 number carried in the packet must be larger than 1834 the sequence number maintained by the server. 1835 UPDATE The source IP address passes existing access filters (if 1836 any) and {Customer Order Identifier, Provider 1837 Order Identifier, Nonce} must match an existing 1838 order with state "Completed". 1839 WITHDRAW The source IP address passes existing access filters (if 1840 any) and {Customer Order Identifier, Provider 1841 Order Identifier, Nonce} must match an existing 1842 order with state "Completed". 1844 11. Theory of Operation 1846 Both CPNP client and server proceed to message validation checks as 1847 specified in Section 10. 1849 11.1. Client Behavior 1851 11.1.1. Order Negotiation Cycle 1853 To place a provisioning quotation order, the client initiates first a 1854 local quotation order object identified by a unique identifier 1855 assigned by the client. The state of the quotation order is set to 1856 "Created". The client then generates a QUOTATION request which 1857 includes the assigned identifier, possibly an expected response time, 1858 a Transaction-ID and a Requested Connectivity Provisioning Document. 1859 The client may include additional Information Elements such as 1860 Negotiation Options. 1862 The client may be configured to not enforce negotiation checks on 1863 EXPECTED_OFFER_TIME; if so no EXPECTED_RESPONSE_TIME attribute (or 1864 EXPECTED_RESPONSE_TIME set to infinite) should be included in the 1865 quotation order. 1867 Once the request is sent to the server, the state of the request is 1868 set to "PQOSent" and a timer, if a response time is included in the 1869 quotation order, is set to the expiration time as included in the 1870 QUOTATION request. The client also maintains a copy of the CPNP 1871 session entry details used to generate the QUOTATION request. The 1872 CPNP client must listen on the same port number that it used to send 1873 the QUOTATION request. 1875 If no answer is received from the server before the retransmission 1876 timer expires (i.e., RETRANS_TIMER, Section 8.5), the client proceeds 1877 to retransmission until maximum retry is reached (e.g., 3 times). 1878 The same sequence number is used for retransmitted packets. 1880 If a FAIL message is received, the client may decide to issue another 1881 (corrected) request towards the same server, cancel the local order, 1882 or contact another server. The behavior of the client depends on the 1883 error code returned by the server in the FAIL message. 1885 If a PROCESSING message matching the CPNP session entry (Section 8.3) 1886 is received, the client updates the CPNP session entry with the 1887 PROVIDER_AGREEMENT_IDENTIFIER information. If the client does not 1888 accept the expected offer time that may have been indicated in the 1889 PROCESSING message, the client may decide to cancel the quotation 1890 order. If the client accepts the EXPECTED_OFFER_TIME, it changes the 1891 state of the order to "ServerProcessing" and sets a timer to the 1892 value of EXPECTED_OFFER_TIME. If no offer is made before the timer 1893 expires, the client changes the state of the order to "Cancelled". 1895 As a response to a more time request (conveyed in a PROCESSING 1896 message that included a new EXPECTED_OFFER_TIME), the client may 1897 grant this extension by issuing an ACK message or reject the time 1898 extension with a FAIL message having a status code set to "More Time 1899 Rejected". 1901 If an OFFER message matching the CPNP session entry is received, the 1902 client checks if a PROCESSING message having the same 1903 PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If 1904 a PROCESSING message was already received for the same order but the 1905 PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included 1906 in the OFFER message, the client ignores silently the message. If a 1907 PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was 1908 already received and matches the CPNP transaction identifier, the 1909 client changes the state of the order to "OfferReceived" and sets a 1910 timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER 1911 message. 1913 If an offer is received from the server (i.e., as documented in an 1914 OFFER message), the client may accept or reject the offer. The 1915 client accepts the offer by generating an ACCEPT message which 1916 confirms that the client agrees to subscribe to the offer documented 1917 in the OFFER message; the state of the order is passed to 1918 "AcceptSent". The transaction is terminated if an ACK message is 1919 received from the server. If no ACK is received from the server, the 1920 client proceeds with the re-transmission of the ACCEPT message. 1922 The client may also decide to reject the offer by sending a DECLINE 1923 message. The state of the order is set by the client to "Cancelled". 1924 If an offer is not acceptable by the client, the client may decide to 1925 contact a new server or submit another order to the same server. 1926 Guidelines to issue an updated order or terminate the negotiation are 1927 specific to the client. 1929 11.1.2. Order Withdrawal Cycle 1931 A client may withdraw a completed order. This is achieved by issuing 1932 a WITHDRAW message. This message MUST include Customer Order 1933 Identifier, Provider Identifier, and Nonce returned during the order 1934 negotiation cycle specified in Section 11.1.1. 1936 If no ACK is received from the server, the client proceeds with the 1937 re-transmission of the message. 1939 11.1.3. Order Update Cycle 1941 A client may update a completed order. This is achieved by issuing 1942 an UPDATE message. This message MUST include Customer Order 1943 Identifier, Provider Order Identifier and Nonce returned during the 1944 order negotiation cycle specified in Section 11.1.1. The client MUST 1945 include in the UPDATE message an updated CPD with the requested 1946 changes. 1948 Subsequent messages exchange is similar to what is documented in 1949 Section 11.1.1. 1951 11.2. Server Behavior 1953 11.2.1. Order Processing 1955 Upon receipt of a QUOTATION message from a client, the server sets a 1956 CPNP session, stores Transaction-ID and generates a Provider Order 1957 Identifier. Once preliminary validation checks are completed ( 1958 Section 10), the server may return a PROCESSING message to notify the 1959 client the quotation order is received and it is under processing; 1960 the server may include an expected offer time to notify the client by 1961 when an offer will be proposed. An order with state 1962 "AwaitingProcessing" is created by the server. The server runs its 1963 decision-making process to decide which offer it can make to honor 1964 the received order. The offer should be made before the expected 1965 offer time expires. 1967 If the server cannot make an offer, it sends backs a FAIL message 1968 with the appropriate error code. 1970 If the server requires more negotiation time, it must send a 1971 PROCESSING message with a new EXPECTED_OFFER_TIME. The client may 1972 grant this extension by issuing an ACK message or reject the time 1973 extension with a FAIL message having a status code set to "More Time 1974 Rejected". If the client doesn't grant more time, the server must 1975 answer before the initial expected offer time; otherwise the client 1976 will ignore the quotation order. 1978 If the server can honor the request or it can make an offer that meet 1979 some of the requirements, it creates an OFFER message. The server 1980 must indicate the Transaction-ID, Customer Order Identifier as 1981 indicated in the QUOTATION message, and the Provider Order Identifier 1982 generated for this order. The server must also include Nonce and the 1983 offered Connectivity Provisioning Document. The server includes an 1984 offer validity time as well. Once sent to the client, the server 1985 changes the state of the order to "OfferSent" and a timer set to the 1986 validity time is initiated. 1988 If the server determines that additional network resources from 1989 another network provider are needed to accommodate a quotation order, 1990 it will create child PQO(s) and will behave as a CPNP client to 1991 negotiate child PQO(s) with possible partnering providers (see 1992 Figure 7). 1994 If no PROCESSING, ACCEPT or DECLINE message is received before the 1995 expiry of the RETRANS_TIMER, the server re-sends the same offer to 1996 the client. This procedure is repeated until maximum retry is 1997 reached. 1999 If an ACCEPT message is received before the offered validity time 2000 expires, the server proceeds with validation checks as specified in 2001 Section 10. The state of the corresponding order is passed to 2002 "AcceptReceived". The server sends back an ACK message to terminate 2003 the order processing cycle. 2005 If a CANCEL/DECLINE message is received, the server proceeds with the 2006 cancellation of the order. The state of the order is then passed to 2007 "Cancelled". 2009 11.2.2. Order Withdrawal 2011 A client may withdraw a completed order by issuing a WITHDRAW 2012 message. Upon receipt of a WITHDRAW message, the server proceeds 2013 with the validation checks, as specified in Section 10: 2015 o If the checks fail, a FAIL message is sent back to the client with 2016 the appropriate error code. 2018 o If the checks succeed, the server clears the clauses of the 2019 Connectivity Provisioning Document, changes the state of the order 2020 to "Cancelled", and sends back an ACK message with an Empty 2021 Connectivity Provisioning Document. 2023 11.2.3. Order Update 2025 A client may update an order by issuing an UPDATE message. Upon 2026 receipt of an UPDATE message, the server proceeds with the validation 2027 checks as specified in Section 10: 2029 o If the checks fail, a FAIL message is sent back to the client with 2030 the appropriate error code. 2031 o Subsequent messages exchange is similar to what is specified in 2032 Section 11.1.1. The server should generate a new Nonce value to 2033 be included in the offer made to the client. 2035 11.3. Sequence Numbers 2037 In each transaction, sequence numbers are used to protect the 2038 transaction against replay attacks. Each communicating partner of 2039 the transaction maintains two sequence numbers, one for incoming 2040 packets and one for outgoing packets. When a partner receives a 2041 message, it will check whether the sequence number in the message is 2042 larger than the incoming sequence number maintained locally. If not, 2043 the messages will be discarded. If the message is proved to be 2044 legal, the value of the incoming sequence number will be replaced by 2045 the value of the sequence number in the message. When a partner 2046 sends out a message, it will insert the value of outgoing sequence 2047 number into the message and increase the outgoing sequence number 2048 maintained locally by 1. 2050 11.4. Message Re-Transmission 2052 If a transaction partner sends out a message and does not receive any 2053 expected reply before the retransmission timer expires (i.e., 2054 RETRANS_TIMER), a transaction partner will try to re-transit the 2055 messages. An exception is the last message (e.g., ACK) sent from the 2056 server in a transaction. After sending this message, the 2057 retransmission timer will be disabled since no additional feedback is 2058 expected. 2060 In addition, if the partner receives a re-sent last incoming packet, 2061 the partner can also send out the answer to the incoming packet with 2062 a limited frequency. If no answer was generated at the moment, the 2063 partner needs to generate a PROCESSING message as the answer. 2065 To benefit message re-transmission, a partner could also store the 2066 last incoming packet and the associated answer. Note that the times 2067 of re-transmission could be decided by the local policy and re- 2068 transmission will not cause any change of sequence numbers. 2070 12. Some Operational Guidelines 2072 12.1. Logging on the CPNP Server 2074 The CPNP server should be configurable to log various events and 2075 associated information. Such information may include: 2077 o Client's IP address 2078 o Any event change (e.g., new quotation order, offer sent, order 2079 confirm, order cancellation, order withdraw, etc.) 2080 o Timestamp 2082 12.2. Business Guidelines & Objectives 2084 The CPNP server can operate in the following modes: 2086 1. Fully automated mode: 2088 The CPNP server is provisioned with a set of business guidelines 2089 and objectives that will be used as an input to the decision- 2090 making process. The CPNP server will service received orders 2091 that falls into these business guidelines; otherwise requests 2092 will be escalated to an administrator that will formally 2093 validate/invalidate an order request. The set of policies to be 2094 configured to the CPNP server are specific to each administrative 2095 entity managing a CPNP server. 2097 2. Administrative-based mode: 2099 This mode assumes some or all CPNP server' operations are subject 2100 to a formal administrative validation. CPNP events will trigger 2101 appropriate validation requests that will be forwarded to the 2102 contact person(s) or department which is responsible for 2103 validating the orders. Administrative validation messages are 2104 relayed using another protocol (e.g., SMTP) or a dedicated tool. 2106 Business guidelines are local to each administrative entity. How 2107 validation requests are presented to an administrator are out of 2108 scope of this document; each administrative entity may decide the 2109 appropriate mechanism to enable for that purpose. 2111 13. Security Considerations 2113 Means to defend the server against denial-of-service attacks must be 2114 enabled. For example, access control lists (ACLs) can be enforced on 2115 the client, the server or the network in between, to allow a trusted 2116 client to communicate with a trusted server. 2118 The client and the server MUST be mutually authenticated. 2119 Authenticated encryption MUST be used for data confidentiality and 2120 message integrity. 2122 The protocol does not provide security mechanisms to protect the 2123 confidentiality and integrity of the packets transported between the 2124 client and the server. An underlying security protocol such as 2125 (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport 2126 Layer Security (TLS) [RFC8446]) MUST be used to protect the integrity 2127 and confidentiality for the protocol. In this case, if it is 2128 possible to provide an Automated Key Management (AKM) and associate 2129 each transaction with a different key, inter-transaction replay 2130 attacks can naturally be addressed. If the client and the server use 2131 a single key, an additional mechanism should be provided to protect 2132 inter-transaction replay attacks between them. Clients MUST 2133 implement DTLS record replay detection (Section 3.3 of [RFC6347]) or 2134 an equivalent mechanism to protect against replay attacks. 2136 DTLS and TLS with a cipher suite offering confidentiality protection 2137 and the guidance given in [RFC7525] MUST be followed to avoid attacks 2138 on (D)TLS. 2140 The client MUST silently discard CPNP responses received from unknown 2141 CPNP servers. The use of a randomly generated Transaction-ID makes 2142 it hard to forge a response from a server with a spoofed IP address 2143 belonging to a legitimate CPNP server. Furthermore, CPNP demands 2144 that messages from the server must include correct identifiers of the 2145 orders. Two order identifiers are used: one generated by the client 2146 and a second one generated by the server. 2148 The Provider MUST enforce means to protect privacy-related 2149 information included the documents (see Section 8.7) exchanged using 2150 CPNP messages [RFC6462]. In particular, this information MUST NOT be 2151 revealed to external parties without the consent of Customers. 2152 Providers should enforce policies to make Customer fingerprinting 2153 difficult to achieve. For more discussion about privacy, refer to 2154 [RFC6462][RFC6973]. 2156 The Nonce and the Transaction ID attributes provide sufficient 2157 randomness and can effectively tolerate attacks raised by off-line 2158 adversaries, who do not have the capability of eavesdropping and 2159 intercepting the packets transported between the client and the 2160 server. Only authorized clients must be able to modify agreed CPNP 2161 orders. The use of a randomly generated Nonce by the server makes it 2162 hard to modify an agreement on behalf of a malicious third-party. 2164 14. IANA Considerations 2166 This document does not request any IANA action. 2168 15. Acknowledgements 2170 Thanks to Diego R. Lopez and Adrian Farrel for the comments. 2172 Thanks to the ISE reviewers. 2174 16. References 2176 16.1. Normative References 2178 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 2179 Application and Support", STD 3, RFC 1123, 2180 DOI 10.17487/RFC1123, October 1989, 2181 . 2183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2184 Requirement Levels", BCP 14, RFC 2119, 2185 DOI 10.17487/RFC2119, March 1997, 2186 . 2188 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2189 "Randomness Requirements for Security", BCP 106, RFC 4086, 2190 DOI 10.17487/RFC4086, June 2005, 2191 . 2193 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2194 Used to Form Encoding Rules in Various Routing Protocol 2195 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2196 2009, . 2198 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2199 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2200 January 2012, . 2202 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 2203 Connectivity Provisioning Profile (CPP)", RFC 7297, 2204 DOI 10.17487/RFC7297, July 2014, 2205 . 2207 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2208 "Recommendations for Secure Use of Transport Layer 2209 Security (TLS) and Datagram Transport Layer Security 2210 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2211 2015, . 2213 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2214 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2215 May 2017, . 2217 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2218 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2219 . 2221 16.2. Informative References 2223 [AGAVE] Boucadair, M., Georgatsos, P., Wang, N., Griffin, D., 2224 Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE 2225 Approach for Network Virtualization: Differentiated 2226 Services Delivery", April 2009, 2227 . 2230 [ETICS] EU FP7 ETICS Project, "Economics and Technologies of 2231 Inter-Carrier Services", January 2014, . 2235 [I-D.boucadair-lisp-idr-ms-discovery] 2236 Boucadair, M. and C. Jacquenet, "LISP Mapping Service 2237 Discovery at Large", draft-boucadair-lisp-idr-ms- 2238 discovery-01 (work in progress), March 2016. 2240 [I-D.geng-netslices-architecture] 2241 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 2242 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 2243 Architecture", draft-geng-netslices-architecture-02 (work 2244 in progress), July 2017. 2246 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2247 specifying the location of services (DNS SRV)", RFC 2782, 2248 DOI 10.17487/RFC2782, February 2000, 2249 . 2251 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 2252 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 2253 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 2254 RFC 3084, DOI 10.17487/RFC3084, March 2001, 2255 . 2257 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2258 Private Network (VPN) Terminology", RFC 4026, 2259 DOI 10.17487/RFC4026, March 2005, 2260 . 2262 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 2263 and A. Gonguet, "Framework for Layer 3 Virtual Private 2264 Networks (L3VPN) Operations and Management", RFC 4176, 2265 DOI 10.17487/RFC4176, October 2005, 2266 . 2268 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2269 and A. Bierman, Ed., "Network Configuration Protocol 2270 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2271 . 2273 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 2274 RFC 6462, DOI 10.17487/RFC6462, January 2012, 2275 . 2277 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 2278 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 2279 . 2281 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 2282 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 2283 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 2284 November 2012, . 2286 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 2287 Autonomous System (AS) Number Space", RFC 6793, 2288 DOI 10.17487/RFC6793, December 2012, 2289 . 2291 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2292 Locator/ID Separation Protocol (LISP)", RFC 6830, 2293 DOI 10.17487/RFC6830, January 2013, 2294 . 2296 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2297 Morris, J., Hansen, M., and R. Smith, "Privacy 2298 Considerations for Internet Protocols", RFC 6973, 2299 DOI 10.17487/RFC6973, July 2013, 2300 . 2302 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2303 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2304 October 2013, . 2306 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 2307 Networking: A Perspective from within a Service Provider 2308 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 2309 . 2311 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 2312 Pascual, J., and D. Lewis, "Locator/Identifier Separation 2313 Protocol (LISP) Network Element Deployment 2314 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2315 2014, . 2317 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 2318 Application-Based Network Operations", RFC 7491, 2319 DOI 10.17487/RFC7491, March 2015, 2320 . 2322 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2323 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2324 . 2326 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2327 Interchange Format", STD 90, RFC 8259, 2328 DOI 10.17487/RFC8259, December 2017, 2329 . 2331 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2332 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2333 DOI 10.17487/RFC8299, January 2018, 2334 . 2336 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2337 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2338 . 2340 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2341 Kumar, "Framework for Interface to Network Security 2342 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2343 . 2345 [RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., 2346 and P. Iovanna, "Cooperating Layered Architecture for 2347 Software-Defined Networking (CLAS)", RFC 8597, 2348 DOI 10.17487/RFC8597, May 2019, 2349 . 2351 Authors' Addresses 2353 Mohamed Boucadair 2354 Orange 2355 Rennes 35000 2356 France 2358 Email: mohamed.boucadair@orange.com 2360 Christian Jacquenet 2361 Orange 2362 Rennes 35000 2363 France 2365 Email: christian.jacquenet@orange.com 2367 Dacheng Zhang 2368 Huawei Technologies 2370 Email: dacheng.zhang@huawei.com 2371 Panos Georgatsos 2372 Centre for Research and Innovation 2373 Hellas 2374 78, Filikis Etairias str. 2375 Volos, Hellas 38334 2376 Greece 2378 Phone: +302421306070 2379 Email: pgeorgat@gmail.com