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