idnits 2.17.1 draft-boucadair-connectivity-provisioning-protocol-22.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 (June 25, 2020) is 1399 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) == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-01 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-03 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- 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 (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft C. Jacquenet 4 Intended status: Informational Orange 5 Expires: December 27, 2020 D. Zhang 6 Huawei Technologies 7 P. Georgatsos 8 CERTH 9 June 25, 2020 11 Dynamic Service Negotiation 12 draft-boucadair-connectivity-provisioning-protocol-22 14 Abstract 16 This document defines the Connectivity Provisioning Negotiation 17 Protocol (CPNP) which is designed to facilitate the dynamic 18 negotiation of service parameters. 20 CPNP is a generic protocol that can be used for various negotiation 21 purposes that include (but are not necessarily limited to) 22 connectivity provisioning services, storage facilities, Content 23 Delivery Networks, etc. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 27, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. CPNP Functional Elements . . . . . . . . . . . . . . . . . . 6 62 4. Order Processing Models . . . . . . . . . . . . . . . . . . . 6 63 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 64 6. CPNP Deployment Models . . . . . . . . . . . . . . . . . . . 11 65 7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 11 66 8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 67 8.1. Client/Server Communication . . . . . . . . . . . . . . . 14 68 8.2. Policy Configuration on the CPNP Server . . . . . . . . . 15 69 8.3. CPNP Session Entries . . . . . . . . . . . . . . . . . . 18 70 8.4. CPNP Transaction . . . . . . . . . . . . . . . . . . . . 18 71 8.5. CPNP Timers . . . . . . . . . . . . . . . . . . . . . . . 19 72 8.6. CPNP Operations . . . . . . . . . . . . . . . . . . . . . 19 73 8.7. Connectivity Provisioning Documents . . . . . . . . . . . 21 74 8.8. Child Provisioning Quotation Orders . . . . . . . . . . . 22 75 8.9. Multi-Segment Service . . . . . . . . . . . . . . . . . . 23 76 8.10. Negotiating with Multiple CPNP Servers . . . . . . . . . 23 77 8.11. State Management . . . . . . . . . . . . . . . . . . . . 24 78 8.11.1. On the Client Side . . . . . . . . . . . . . . . . . 24 79 8.11.2. On the Server Side . . . . . . . . . . . . . . . . . 27 80 9. CPNP Objects . . . . . . . . . . . . . . . . . . . . . . . . 30 81 9.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 30 82 9.1.1. CUSTOMER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 30 83 9.1.2. PROVIDER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 30 84 9.1.3. TRANSACTION_ID . . . . . . . . . . . . . . . . . . . 31 85 9.1.4. SEQUENCE_NUMBER . . . . . . . . . . . . . . . . . . . 31 86 9.1.5. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 31 87 9.1.6. EXPECTED_RESPONSE_TIME . . . . . . . . . . . . . . . 31 88 9.1.7. EXPECTED_OFFER_TIME . . . . . . . . . . . . . . . . . 32 89 9.1.8. VALIDITY_OFFER_TIME . . . . . . . . . . . . . . . . . 32 90 9.1.9. SERVICE_DESCRIPTION . . . . . . . . . . . . . . . . . 32 91 9.1.10. CPNP Information Elements . . . . . . . . . . . . . . 33 92 9.2. Operation Messages . . . . . . . . . . . . . . . . . . . 34 93 9.2.1. QUOTATION . . . . . . . . . . . . . . . . . . . . . . 35 94 9.2.2. PROCESSING . . . . . . . . . . . . . . . . . . . . . 35 95 9.2.3. OFFER . . . . . . . . . . . . . . . . . . . . . . . . 37 96 9.2.4. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . 38 97 9.2.5. DECLINE . . . . . . . . . . . . . . . . . . . . . . . 38 98 9.2.6. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 39 99 9.2.7. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 40 100 9.2.8. WITHDRAW . . . . . . . . . . . . . . . . . . . . . . 40 101 9.2.9. UPDATE . . . . . . . . . . . . . . . . . . . . . . . 41 102 9.2.10. FAIL . . . . . . . . . . . . . . . . . . . . . . . . 43 103 9.2.11. ACTIVATE . . . . . . . . . . . . . . . . . . . . . . 44 104 10. CPNP Message Validation . . . . . . . . . . . . . . . . . . . 45 105 10.1. On the Client Side . . . . . . . . . . . . . . . . . . . 45 106 10.2. On the Server Side . . . . . . . . . . . . . . . . . . . 47 107 11. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 48 108 11.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 48 109 11.1.1. Order Negotiation Cycle . . . . . . . . . . . . . . 48 110 11.1.2. Order Withdrawal Cycle . . . . . . . . . . . . . . . 50 111 11.1.3. Order Update Cycle . . . . . . . . . . . . . . . . . 50 112 11.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 50 113 11.2.1. Order Processing . . . . . . . . . . . . . . . . . . 50 114 11.2.2. Order Withdrawal . . . . . . . . . . . . . . . . . . 52 115 11.2.3. Order Update . . . . . . . . . . . . . . . . . . . . 52 116 11.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 52 117 11.4. Message Re-Transmission . . . . . . . . . . . . . . . . 53 118 12. Some Operational Guidelines . . . . . . . . . . . . . . . . . 53 119 12.1. Logging on the CPNP Server . . . . . . . . . . . . . . . 53 120 12.2. Business Guidelines and Objectives . . . . . . . . . . . 53 121 13. Security Considerations . . . . . . . . . . . . . . . . . . . 54 122 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 123 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 124 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 125 16.1. Normative References . . . . . . . . . . . . . . . . . . 56 126 16.2. Informative References . . . . . . . . . . . . . . . . . 56 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 129 1. Introduction 131 This document defines the Connectivity Provisioning Negotiation 132 Protocol (CPNP) that is meant to dynamically exchange and negotiate 133 connectivity provisioning parameters and other service-specific 134 parameters between a Customer and a Provider. CPNP is a tool that 135 introduces automation in the service negotiation and activation 136 procedures, thus fostering the overall service provisioning process. 137 CPNP can be seen as a component of the dynamic negotiation meta- 138 domain described in Section 3.4 of [RFC7149]. 140 CPNP is a generic protocol that can be used for other negotiation 141 purposes than connectivity provisioning. For example, CPNP can be 142 used to request extra storage resources, to extend the footprint of a 143 CDN (Content Delivery Networks), to enable additional features from a 144 cloud Provider, etc. CPNP can be extended with new Information 145 Elements (IEs). Sample negotiation use cases are described in 146 Section 5. Section 4 introduces several order processing models and 147 precises those that are targeted by CPNP. The CPNP negotiation model 148 is then detailed in Section 7. 150 [RFC7297] describes a Connectivity Provisioning Profile (CPP) 151 template to capture connectivity requirements to be met by a 152 transport infrastructure for the delivery of various services such as 153 Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) 154 services [RFC4026]. The CPP document defines the set of IP transfer 155 parameters that reflect the guarantees that can be provided by the 156 underlying transport network together with reachability scope and 157 capacity needs. CPNP uses the CPP template to encode connectivity 158 provisioning clauses that are subject to negotiation. The agreed CPP 159 will be then passed to other functional elements that are responsible 160 for the actual service activation and provisioning. For example, 161 NETCONF [RFC6241] or RESTCONF [RFC8040] can be used to activate 162 adequate network features that are required to deliver the agreed 163 service. How the outcome of CPNP negotiation is translated into 164 service and network provisioning actions is out of scope of this 165 document. 167 As a reminder, several proposals have been made in the past by the 168 (research) community (e.g., COPS-SLS [I-D.nguyen-rap-cops-sls], 169 Service Negotiation Protocol (SrNP) [TEQUILA], Dynamic Service 170 Negotiation Protocol (DSNP) [I-D.itsumo-dsnp], Resource Negotiation 171 and Pricing Protocol (RNAP) [Xin], Service Negotiation and 172 Acquisition Protocol (SNAP) [Karl]). CPNP leverages the experience 173 of the authors with SrNP by separating the negotiation primitives 174 from the service under negotiation. Moreover, careful examination of 175 the other proposals revealed certain deficiencies that were easier to 176 address through the creation of a new protocol rather than modifying 177 existing protocols. For example: 179 o COPS-SLS relies upon COPS-PR [RFC3084], which is an Historic RFC. 181 o DSNP is tightly designed with one specific service in mind (QoS) 182 and does not make any distinction between a quotation phase and 183 the actual service ordering phase. 185 One of the primary motivations of this document is to provide a 186 permanent reference to exemplify how service negotiation can be 187 automated. 189 Implementation details are out of scope. An example of required 190 modules and interfaces to implement this specification is sketched in 191 Section 4 of [AGAVE]. This specification builds on that effort. 193 2. Terminology 195 This document makes use of the following terms: 197 Customer: Is a business role which denotes an entity that is 198 involved in the definition and the possible negotiation of an 199 order, including a Connectivity Provisioning Agreement, with a 200 Provider. A connectivity provisioning order is captured in a 201 dedicated CPP template-based document, which may specify (among 202 other information): the sites to be connected, border nodes, 203 outsourced operations (e.g., routing, force via points). 205 The right to invoke the subscribed service may be delegated by the 206 Customer to third-party End Users, or brokering services. 208 A Customer can be a Service Provider, an application owner, an 209 enterprise, a user, etc. 211 Network Provider (or Provider): Owns and administers one or many 212 transport domain(s) (typically Autonomous System (AS)) composed of 213 (IP) switching and transmission resources (e.g., routing, 214 switching, forwarding, etc.). Network Providers are responsible 215 for delivering and operating connectivity services (e.g., offering 216 global or restricted reachability at specific rates). Offered 217 connectivity services may not necessarily be restricted to IP. 219 The policies to be enforced by the connectivity service delivery 220 components can be derived from the technology-specific clauses 221 that might be included in agreements with the Customers. If no 222 such clauses are included in the agreement, the mapping between 223 the connectivity requirements and the underlying technology- 224 specific policies to be enforced is deployment-specific. 226 Quotation Order: Denotes a request made by the Customer to the 227 Provider that includes a set of requirements. The Customer may 228 express its service-specific requirements by assigning (strictly 229 or loosely defined) values to the information items included in 230 the commonly understood template (e.g., CPP template) describing 231 the offered service. These requirements constitute the parameters 232 to be mutually agreed upon. 234 Offer: Refers to a response made by the Provider to a Customer's 235 quotation order that describes the ability of the Provider to 236 satisfy the order at the time of its receipt. Offers reflect the 237 capability of the Provider in accommodating received Customer 238 orders beyond monolithic 'yes/no' answers. 240 An offer may fully or partially meet the requirements of the 241 corresponding order. In the latter case, it may include 242 alternative suggestions which the Customer may take into account 243 by issuing a new order. 245 Agreement: Refers to an order placed by the Customer and accepted by 246 the Provider. It signals the successful conclusion of a 247 negotiation cycle. 249 3. CPNP Functional Elements 251 The following functional elements are defined: 253 CPNP client (or client): Denotes a software instance that sends 254 CPNP requests and receives CPNP responses. The current operations 255 that can be performed by a CPNP client are listed below: 257 1. Create a quotation order (Section 9.2.1). 259 2. Cancel an ongoing quotation order under negotiation 260 (Section 9.2.7). 262 3. Accept an offer made by a server (Section 9.2.4). 264 4. Withdraw an agreement (Section 9.2.8). 266 5. Update an agreement (Section 9.2.9). 268 CPNP server (or server): Denotes a software instance that receives 269 CPNP requests and sends back CPNP responses accordingly. The CPNP 270 server is responsible for the following operations: 272 1. Process a quotation order (Section 9.2.2). 274 2. Make an offer (Section 9.2.3). 276 3. Cancel an ongoing quotation order (Section 11.2.3). 278 4. Process an order withdrawal (Section 11.2.3). 280 4. Order Processing Models 282 For preparing their service orders, Customers may need to be aware of 283 the offered services. Therefore, Providers should first proceed with 284 the announcement (or the exposure) of the services they can provide. 285 The service announcement process may take place at designated global 286 or Provider-specific service markets, or through explicit 287 interactions with the Providers. The details of this process are 288 outside the scope of this document. 290 With or without such service announcement/exposure mechanisms in 291 place, the following order processing models can be distinguished: 293 Frozen model: 295 The Customer cannot actually negotiate the parameters of the 296 service(s) offered by a Provider. After consulting the Provider's 297 service portfolio, the Customer selects the service offer he/she 298 wants to subscribe and places an order to the Provider. Order 299 handling is quite simple on the Provider side because the service 300 is not customized as per Customer's requirements, but rather pre- 301 designed to address a Customer base that shares the same 302 requirements (i.e., these customers share the same Customer 303 Provisioning Profile). This mode can be implemented using 304 existing tools such as [RFC8309]. 306 Negotiation-based model: 308 Unlike the frozen model, the Customer documents his/her 309 requirements in a request for a quotation, which is then sent to 310 one or several Providers. Solicited Providers check whether they 311 can address these requirements or not, and get back to the 312 Customer accordingly, possibly with an offer that may not exactly 313 match customer's requirements (e.g., a 100 Mbps connection cannot 314 be provisioned given the amount of available resources, but an 80 315 Mbps connection can be provided). A negotiation between the 316 Customer and the Provider(s) then follows until both parties reach 317 an agreement (or do not). 319 Both frozen and negotiation-based models require the existence of 320 appropriate service templates like a CPP template and their 321 instantiation for expressing specific offerings from Providers and 322 service requirements from Customers, respectively. CPNP can be used 323 in either model for automating the required Customer-Provider 324 interactions. The frozen model can be seen as a special case of the 325 negotiation-based model. This document focuses on the negotiation- 326 based model. Not only 'yes/no' answers but also counter-proposals 327 may be offered by the Provider in response to Customer orders. 329 Order processing management on the Network Provider's side usually 330 solicits features supported by the following functional blocks: 332 o Network Provisioning (including Order Activation, Network 333 Planning, etc.) 334 o Authentication, Authorization and Accounting (AAA) 335 o Network and service management (performance measurement and 336 assessment, fault detection, etc.) 337 o Sales-related functional blocks (e.g., billing, invoice 338 validation) 339 o Network Impact Analysis 341 CPNP does not assume any specific knowledge about these functional 342 blocks, drawing an explicit line between protocol operation and the 343 logic for handling connectivity provisioning requests. An order 344 processing logic is typically fed with the information manipulated by 345 the aforementioned functional blocks. For example, the resources 346 that can be allocated to accommodate Customer's requirements may 347 depend on network availability estimates as calculated by the 348 planning functions and related policies, as well as the number of 349 orders to be processed simultaneously over a given period of time. 351 This document does not elaborate on how Customers are identified and 352 subsequently managed by the Provider's Information System. 354 5. Sample Use Cases 356 A non-exhaustive list of CPNP use cases is provided below: 358 1. [RFC4176] introduces the Layer 3 VPN (L3VPN) Service Order 359 Management functional block which is responsible for managing 360 the requests initiated by the Customers and tracks the status of 361 the completion of the related operations. CPNP can be used 362 between the Customer and the Provider to negotiate L3VPN service 363 parameters. 365 A CPNP server could therefore be part of the L3VPN Service Order 366 Management functional block discussed in [RFC4176]. A L3VPN 367 Service YANG data Model (L3SM) is defined in [RFC8299]. Once an 368 agreement is reached, the service can be provisioned using, 369 e.g., the L3VPN Network YANG Model specified in 370 [I-D.ietf-opsawg-l3sm-l3nm]. 372 Likewise, A CPNP server could be part of the Layer 2 VPN (L2VPN) 373 Service Order Management functional block. A YANG data model 374 for L2VPN service delivery is defined in [RFC8466]. Once an 375 agreement is reached, the L2VPN service can be provisioned 376 using, e.g., the L2VPN Network YANG Model specified in 377 [I-D.barguil-opsawg-l2sm-l2nm]. 379 2. CPNP can be used between two adjacent domains to deliver IP 380 interconnection services (e.g., enable, update, disconnect). 381 For example, two Autonomous Systems (ASes) can be connected via 382 several interconnection points. CPNP can be used between these 383 ASes to upgrade existing links, request additional resources, 384 provision a new interconnection point, etc. 386 See, for example, the framework documented in [ETICS]. 388 3. An integrated Provider can use CPNP to rationalize connectivity 389 provisioning needs related to its service portfolio. A CPNP 390 server function is used by network operations teams. A CPNP 391 interface to trigger CPNP negotiation cycles is exposed to 392 service management teams. 394 4. Service Providers can use CPNP to initiate connectivity 395 provisioning requests towards a number of Network Providers so 396 as to optimize the cost of delivering their services. Although 397 multiple CPNP ordering cycles can be initiated by a Service 398 Provider towards multiple Network Providers, a subset of these 399 orders may actually be put into effect. 401 For example, a cloud Service Provider can use CPNP to request 402 more resources from Network Providers. 404 5. CPNP can also be used in the context of network slicing 405 ([I-D.geng-netslices-architecture]) to request network resources 406 together with a set of requirements that need to be satisfied by 407 the Provider. Such requirements are not restricted to basic IP 408 forwarding capabilities, but may also include a characterization 409 of a set of service functions that may be invoked. For the 410 network slicing case, the instances of a CPP template could be 411 derived from the network slice templates inputs as documented in 412 [I-D.contreras-teas-slice-nbi]. 414 6. CPNP can be used in Machine-to-Machine (M2M) environments to 415 dynamically subscribe to M2M services (e.g., access to data 416 retrieved by a set of sensors, extend sensor coverage, etc.). 418 Also, Internet of Things (IoT, [RFC6574]) domains may rely on 419 CPNP to enable dynamic access to data produced by involved 420 objects, according to their specific policies, to various 421 external stakeholders such as data analytics and business 422 intelligence companies. Direct CPNP-based interactions between 423 IoT domains and interested parties enable open access to diverse 424 sets of data across the Internet, e.g., from multiple types of 425 sensors, user groups and/or geographical areas. 427 7. CPNP can be used in the context of I2NSF ([RFC8329]) to capture 428 the customer-driven policies to be enforced by a set of Network 429 Security Functions. 431 8. A Provider offering cloud services can expose a CPNP interface 432 to allow Customers to dynamically negotiate typical data center 433 resources, such as additional storage, processing and networking 434 resources, enhanced security filters, etc. 436 Cloud computing providers typically structure their computation 437 service offerings by bundling CPU, RAM, and storage units as 438 quotas, instances, or flavors that can be consumed in an 439 ephemeral or temporal fashion during the lifetime of the 440 required function. A similar approach is followed by CPNP (see 441 for example, Section 9.2.11). 443 9. In the inter-cloud context (also called cloud of clouds or cloud 444 federation), CPNP can be used to reserve computing and 445 networking resources hosted by various cloud infrastructures. 447 10. CDN Providers can use CPNP to extend their footprint by 448 interconnecting their respective CDN infrastructures [RFC6770] 449 (see Figure 1). 451 ,--,--,--. ,--,--,--. 452 ,-' `-. ,-' `-. 453 (CDN Provider 'A')=====(CDN Provider 'B') 454 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 455 `--'--'--' `--'--'--' 457 Figure 1: CDN Interconnection 459 11. Mapping Service Providers (MSPs, [RFC7215]) can use CPNP to 460 enrich their mapping database by interconnecting their mapping 461 system (see Figure 2). This interconnection allows to relax the 462 constraints on PxTR (Proxy Ingress/Egress Tunnel Router) in 463 favour of native LISP (Locator/ID Separation Protocol) 464 forwarding [RFC6830]. Also, it prevents the fragmentation of 465 the LISP mapping 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 12. CPNP may also be used between SDN (Software-Defined Networking) 477 controllers in contexts where Cooperating Layered Architecture 478 for Software-Defined Networking (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. A CPNP client can discover 487 its CPNP servers using a variety of means (static, dynamic, etc.). 488 o The Customer does not enable any CPNP client. The Provider 489 maintains a Customer Order Management portal. The Customer can 490 initiate connectivity provisioning quotation orders via the 491 portal; appropriate CPNP messages are then generated and sent to 492 the relevant CPNP server. In this model, both the CPNP client and 493 CPNP server are under the responsibility of the same 494 administrative entity (i.e., Network Provider). 496 Once the negotiation of connectivity provisioning parameters is 497 successfully concluded, that is, an order has been placed by the 498 Customer, the actual network provisioning operations are initiated. 499 The specification of related dynamic resource allocation and policy 500 enforcement schemes, as well as how CPNP servers interact with the 501 network provisioning functional blocks at Provider sides are out of 502 the scope of this document. 504 This document does not make any assumption about the CPNP deployment 505 model either. 507 7. CPNP Negotiation Model 509 CPNP runs between a Customer and a Provider carrying service orders 510 from the Customer and corresponding responses from the Provider to 511 the end of reaching a service provisioning agreement. As the 512 services offered by the Provider are well-described, by means of the 513 CPP template for connectivity matters, the negotiation process is 514 essentially a value-settlement process, where an agreement is pursued 515 on the values of the commonly understood information items (service 516 parameters) included in the service description template 517 (Section 9.1.9). 519 The protocol is transparent to the content that it carries and to the 520 negotiation logic invoked at Customer and Provider sides, and which 521 manipulates the content (i.e., the information carried in CPNP 522 messages to proceed with the negotiation). 524 The protocol aims at facilitating the execution of the negotiation 525 logic by providing the required generic communication primitives. 527 Since negotiations are initiated and primarily driven by the 528 Customer's negotiation logic, it is reasonable to assume that the 529 Customer is the only party that can call for an agreement. An 530 implicit approach is adopted for not overloading the protocol with 531 additional messages. In particular, the acceptance of an offer made 532 by the Provider signals a call for agreement from the Customer. Note 533 that it is almost certain the Provider will accept this call since it 534 refers to an offer that itself made. Of course, at any point the 535 Provider or the Customer may quit the negotiations, each on its own 536 grounds. 538 Based on the above, CPNP adopts a Quotation Order/Offer/Answer model, 539 which proceeds through the following basic steps (Figure 3): 541 1. The CPNP client specifies its service requirements via a 542 Provision Quotation Order (PQO). The order may include strictly 543 or loosely defined values in the clauses describing service 544 provisioning characteristics. 546 2. The CPNP server declines the PQO, or makes an offer to address 547 the requirements of the PQO, or suggests a counter-proposal that 548 partially addresses the requirements of the PQO in case specific 549 requirements cannot be accommodated. 551 3. The CPNP client either accepts or declines the offer. Accepting 552 the offer by the CPNP client implies a call for agreement; thus 553 the agreement between both parties and the conclusion of the 554 negotiation. 556 +------+ +------+ 557 |Client| |Server| 558 +------+ +------+ 559 |=====Requested Service=====>| 560 |<=====Offered Service=======| 561 |======Agreed Service=======>| 563 Figure 3: Simplified Service Negotiation 565 Multiple instances of CPNP may run at Customer's or Provider's 566 domains. A CPNP client may be engaged in multiple, simultaneous 567 negotiations with the same or different CPNP servers (parallel 568 negotiations, see Section 8.10) and a CPNP server may need to 569 negotiate with other Provider(s) as part of negotiations that are 570 ongoing with a CPNP client (cascaded negotiations, see Section 8.8). 572 CPNP relies on various timers to run its operations. Two types of 573 timers are defined: those that are specific to CPNP message 574 transmission and those that are specific to the negotiation logic. 575 The latter are used to guide the negotiation logic at both CPNP 576 client and CPNP server sides, particularly in cases where the CPNP 577 client is involved in parallel negotiations with several CPNP servers 578 or in cases where the CPNP server is in turn involved in negotiations 579 with other Providers for processing a given customer-originated 580 quotation order. CPNP allows a CPNP server to request an extra time 581 to proceed with the negotiation. This request may be accepted or 582 rejected by the CPNP client. 584 Providers may need to publish available services to the Customers 585 (see Section 4). CPNP may optionally support this functionality. 586 Dedicated templates can be defined for the purpose of service 587 announcement, which will be used by the CPNP clients to initiate 588 their CPNP negotiation cycles. 590 For the sake of simplicity, a single Offer/Answer stage is assumed 591 within one CPNP negotiation cycle. Nevertheless, as already stated, 592 multiple CPNP negotiation cycles can be undertaken by a CPNP client 593 (see Figure 4). 595 The model is flexible enough to accommodate changing conditions 596 during the lifetime of a service (e.g., introduction of an additional 597 VPN site). 599 +------+ +------+ +------+ +------+ 600 |Client| |Server| |Client| |Server| 601 +------+ +------+ +------+ +------+ 602 |=====Quotation Order=====>| |=====Quotation Order=====>| 603 |<==========Offer==========| |<==========Offer==========| 604 |===========Accept========>| |==========Decline========>| 606 1-Step Successful Negotiation 1-Step Failed Negotiation 607 Cycle Cycle 609 +------+ +------+ +------+ +------+ 610 |Client| |Server| |Client| |Server| 611 +------+ +------+ +------+ +------+ 612 |===Quotation Order(a)====>| |===Quotation Order(i)====>| 613 |<==========Offer==========| |<==========Offer==========| 614 |==========Decline========>| |==========Decline========>| 615 |===Quotation Order(b)====>| |===Quotation Order(j)====>| 616 |<==========Offer==========| |<==========Offer==========| 617 |===========Accept========>| |==========Decline========>| 618 |===Quotation Order(k)====>| 619 |<==========Offer==========| 620 |==========Decline========>| 621 |===Quotation Order(l)====>| 622 |<==Fail to make an offer==| 624 N-Step Negotiation Cycle: N-Step Negotiation Cycle: 625 Successful Negotiation Failed Negotiation 627 Figure 4: Overall Negotiation Process 629 Means used by a CPNP client to retrieve a list of active/agreed 630 offers are not defined in this document. 632 An order can be implicitly or explicitly activated. Section 3.11 of 633 [RFC7297] specifies a dedicated clause called Activation Means. Such 634 clause indicates the required action(s) to be undertaken to activate 635 access to the (IP connectivity) service. This document defines a 636 dedicated CPNP message that can be used for explicit activation 637 (Section 9.2.11)). 639 8. Protocol Overview 641 8.1. Client/Server Communication 643 CPNP is a client/server protocol that can run over any transport 644 protocol. Yet, UDP is the default transport mode secured with 645 Datagram Transport Layer Security (DTLS) [RFC6347]. No permanent 646 CPNP transport session needs to be maintained between the client and 647 the server. 649 The CPNP client can be configured with the CPNP server(s). 650 Typically, an IP address together with a port number are configured 651 to the CPNP client, based upon manual or dynamic configuration means 652 (e.g., DHCP). Alternatively, a Provider may advertise the port 653 number (CPNP_PORT) it uses to bind the CPNP service using SRV 654 [RFC2782]. 656 The CPNP client may be provided with a domain name of the CPNP server 657 for PKIX-based authentication purposes. CPNP servers should prefer 658 the use of DNS-ID and SRV-ID over CN-ID identifier types in 659 certificate requests (Section 2.3 of [RFC6125]). URI-IDs should not 660 be used for CPNP server identity verification. 662 The client sends CPNP requests using CPNP_PORT as the destination 663 port number. The same port number used as the source port number of 664 a CPNP request sent to a CPNP server is used by the server to reply 665 to that request. 667 CPNP is independent of the IP address family. 669 CPNP retransmission is discussed in Section 11.4 for unreliable 670 transports. 672 Considerations related to mutual authentication are discussed in 673 Section 13. 675 8.2. Policy Configuration on the CPNP Server 677 As an input to its decision-making process, the CPNP server may be 678 connected to various external modules such as: Customer Profiles, 679 Network Topology, Network Resource Management, Order Repositories, 680 AAA, and Network Provisioning Manager (an example is shown in 681 Figure 5). 683 These external modules provide inputs to the CPNP server, so that it 684 can: 686 o Check whether a customer is entitled to initiate a provisioning 687 quotation request. 689 o Check whether a customer is entitled to cancel an ongoing order. 691 o Check whether administrative data (e.g., billing-related 692 information) have been verified before the processing of the 693 request starts. 695 o Check whether network capacity is available or additional capacity 696 is required. 698 o Receive guidelines from network design and sales blocks (e.g., 699 pricing, network usage levels, thresholds associated with the 700 number of CPP templates that can be processed over a given period 701 of time as a function of the nature of the service to be 702 delivered, etc.). 704 o Transfer completed orders to network provisioning blocks (referred 705 to as "Network Provisioning Manager" in Figure 5). For example, 706 the outcome of CPNP may be passed to modules such as Application- 707 Based Network Operations (ABNO) [RFC7491] or network controllers. 708 These controllers will use protocols such as NETCONF [RFC6241] to 709 interact with the appropriate network nodes and functions for the 710 sake of proper service activation and delivery. 712 The above list of CPNP server operations is not exhaustive. 714 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715 .Business & Administrative Management . 716 .+------------------------++---------------------------+. 717 .| Business Guidelines || Billing & Charging |. 718 .+-----------+------------++-----------+---------------+. 719 . | | . 720 . +-------------------+ | . 721 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 722 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 723 .Order Handling Management | | . 724 . +-------------------+ +-------+-----+--------------+ . 725 . |Network Topology DB+--+ CPNP Server | . 726 . +-------------------+ +-+---+---+---+---+-----+----+ . 727 . | | | | | | . 728 . +------------------------+-+ | | | | | . 729 . | Network Dimensioning | | | | | | . 730 . | & Planning | | | | | | . 731 . +--------------------------+ | | | | | . 732 . +----------------------------+-+ | | | +---+----+ . 733 . | | | | | | AAA | . 734 . | Network +------------+ | | | +--------+ . 735 . | Resource | +------------+-+ | +-+----------+ . 736 . | Management | | Customer | | | Orders | . 737 . | | | Profiles | | | Repository | . 738 . +-----------------+ +--------------+ | +------------+ . 739 . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . 740 +--------------------------------------+----------------+ 741 | Network Provisioning Manager | 742 +-------------------------------------------------------+ 744 Figure 5: Order Handling Management Functional Block (Focus on 745 Internal Interfaces) 747 The following order handling modes can also be configured on the 748 server: 750 1. Fully automated mode: This mode does not require any action from 751 the administrator when receiving a request for a service. The 752 server can execute its decision-making process related to the 753 orders received and generate corresponding offers. 755 2. Administrative validation checking: Some or all of the server's 756 operations are subject to administrative validation procedures. 757 This mode requires an action from the administrator for every 758 request received. To that aim, the CPNP methods which can be 759 automatically handled by the server (or are subject to one or 760 several validation administrative checks) can be configured on 761 the server. 763 8.3. CPNP Session Entries 765 A CPNP session entry is denoted by a tuple defined as follows: 767 o Transport session (typically, IP address of the CPNP client, 768 client's port number, IP address of the CPNP server, and CPNP 769 server's port number). 771 o Incremented Sequence Number (Section 11.3) 773 o Customer Agreement Identifier: This is a unique identifier 774 assigned to the order under negotiation by the CPNP client 775 (Section 9.1.1). This identifier is also used by the client to 776 identify the agreement that will result from a successful 777 negotiation. 779 o Provider Agreement Identifier: This is a unique identifier 780 assigned to the order under negotiation by the CPNP server 781 (Section 9.1.2). This identifier is also used by the server to 782 identify the agreement that will result from a successful 783 negotiation. 785 o Transaction-ID (Section 8.4). 787 8.4. CPNP Transaction 789 A CPNP transaction occurs between a client and a server for 790 completing, modifying, withdrawing a service agreement, and comprises 791 all CPNP messages exchanged between the client and the server, from 792 the first request sent by the client to the final response sent by 793 the server. A CPNP transaction is bound to a CPNP session 794 (Section 8.3). 796 Because multiple CPNP transactions can be maintained by the CPNP 797 client, the client must assign an identifier to uniquely identify a 798 given transaction. This identifier is denoted as Transaction-ID. 800 The Transaction-ID must be randomly assigned by the CPNP client, 801 according to the best current practice for generating random numbers 802 [RFC4086] that cannot be guessed easily. Transaction-ID is used for 803 validating CPNP responses received by the client. 805 In the context of a transaction, the client needs to randomly select 806 a sequence number and assign it to the first CPNP message to send. 807 This number is then incremented for each request message that is 808 subsequently sent within the ongoing CPNP transaction (see 809 Section 11.3). 811 8.5. CPNP Timers 813 CPNP adopts a simple retransmission procedure which relies on a 814 retransmission timer denoted as RETRANS_TIMER and a maximum retry 815 threshold. The use of RETRANS_TIMER and a maximum retry threshold 816 are described in Section 11. 818 The response timer (EXPECTED_RESPONSE_TIME) is set by the client to 819 denote the time, in seconds, the client will wait for receiving a 820 response from the server to a provisioning quotation order request 821 (see Section 9.1.6). If the timer expires, the respective quotation 822 order is cancelled by the client and a CANCEL message is generated 823 accordingly. 825 The expected offer timer (EXPECTED_OFFER_TIME) is set by the server 826 to indicate the time by when the CPNP server is expecting to make an 827 offer to the CPNP client (see Section 9.1.7). If no offer is 828 received by then, the CPNP client will consider the order as 829 rejected. 831 An offer expiration timer (VALIDITY_OFFER_TIME) is set by the server 832 to represent the time, in minutes, after which an offer made by the 833 server becomes invalid (see Section 9.1.8). 835 8.6. CPNP Operations 837 CPNP operations are listed below. They may be augmented, depending 838 on the nature of some transactions or because of security 839 considerations that may necessitate a distinct CPNP client/server 840 authentication phase before negotiation begins. 842 o QUOTATION (Section 9.2.1): 844 This operation is used by the client to initiate a provisioning 845 quotation order. Upon receipt of a QUOTATION request, the server 846 may respond with a PROCESSING, OFFER or a FAIL message. A 847 QUOTATION-initiated transaction can be terminated by a FAIL 848 message. 850 o PROCESSING (Section 9.2.2): 852 This operation is used to inform the remote party that the message 853 (the order quotation or the offer) sent was received and it is 854 processed. This message can also be issued by the server to 855 request more time, in which case the client may reply with an ACK 856 or FAIL message depending on whether extra time can or cannot be 857 granted. 859 o OFFER (Section 9.2.3): 861 This operation is used by the server to inform the client about an 862 offer that can best accommodate the requirements indicated in the 863 previously received QUOTATION message. 865 o ACCEPT (Section 9.2.4): 867 This operation is used by the client to confirm the acceptance of 868 an offer made by the server. This message implies a call for 869 agreement. An agreement is reached when an ACK is subsequently 870 received from the server, which is likely to happen if the message 871 is sent before the offer validity time expires; the server is 872 unlikely to reject an offer that it has already made. 874 o DECLINE (Section 9.2.5): 876 This operation is used by the client to reject an offer made by 877 the server. The ongoing transaction may not be terminated 878 immediately, e.g., the server/client may issue another offer/ 879 order. 881 o ACK (Section 9.2.6): 883 This operation is used by the server to acknowledge the receipt of 884 an ACCEPT or WITHDRAW message, or by the client to confirm the 885 time extension requested (conveyed in a PROCESSING message) by the 886 server for processing the last received quotation order. 888 o CANCEL (Section 9.2.7): 890 This operation is used by the client to cancel (quit) the ongoing 891 transaction. 893 o WITHDRAW (Section 9.2.8): 895 This operation is used by the client to withdraw a completed order 896 (i.e., an agreement). 898 o UPDATE (Section 9.2.9): 900 This operation is used by the client to update an existing 901 agreement. For example, this method can be invoked to add a new 902 VPN site. This method will trigger a new negotiation cycle. 904 o FAIL (Section 9.2.10): 906 This operation is used by the server to indicate that it cannot 907 accommodate the requirements documented in the PQO conveyed in the 908 QUOTATION message or to inform the client about an error 909 encountered when processing the received message. In either case, 910 the message implies that the server is unable to make offers and 911 as a consequence, it terminates the ongoing transaction. 913 This message is also used by the client to reject a time extension 914 request received from the server (in a PROCESSING message). The 915 message includes a status code for providing explanatory 916 information. 918 The above CPNP primitives are service-independent. CPNP messages may 919 transparently carry service-specific objects which are handled by the 920 negotiation logic at either side. 922 The document defines the service objects that are required for 923 connectivity provisioning negotiation (see Section 8.7) purposes. 924 Additional service-specific objects to be carried in CPNP messages 925 can be defined in the future for accommodating alternative deployment 926 schemes or other service provisioning needs. 928 8.7. Connectivity Provisioning Documents 930 CPNP makes use of several flavors of Connectivity Provisioning 931 Documents (CPD). These documents follow the same CPP template 932 described in [RFC7297]. 934 Requested Connectivity Provisioning Document (Requested CPD): 935 Refers to the CPD included by a CPNP client in a QUOTATION 936 request. 938 Offered Connectivity Provisioning Document (Offered CPD): This 939 document is included by a CPNP server in an OFFER message. Its 940 information reflects the proposal of the server to accommodate all 941 or a subset of the clauses depicted in a Requested CPD. A 942 validity time is associated with the offer made. 944 Agreed Connectivity Provisioning Document (Agreed CPD): If the 945 client accepts an offer made by the server, the Offered CPD is 946 included in an ACCEPT message. This CPD is also included in an 947 ACK message. Thus, a 3-way handshake procedure is followed for 948 successfully completing the negotiation. 950 Figure 6 shows a typical CPNP negotiation cycle and the use of the 951 different types of Connectivity Provisioning Documents. 953 +------+ +------+ 954 |Client| |Server| 955 +------+ +------+ 956 |======QUOTATION (Requested CPD)=====>| 957 |<============PROCESSING==============| 958 |<========OFFER (Offered CPD)=========| 959 |=============PROCESSING=============>| 960 |=========ACCEPT (Agreed CPD)========>| 961 |<=========ACK (Agreed CPD)===========| 962 | | 964 Figure 6: Connectivity Provisioning Documents 966 A provisioning document can include parameters with fixed values, 967 loosely-defined values, or any combination thereof. A provisioning 968 document is said to be concrete if all clauses have fixed values. 970 A typical evolution of a negotiation cycle would start with a 971 quotation order with loosely-defined parameters, and then, as offers 972 are made, it would conclude with concrete provisioning document for 973 calling for the agreement. 975 8.8. Child Provisioning Quotation Orders 977 If the server detects that network resources from another Network 978 Provider need to be allocated in order to accommodate the 979 requirements described in a PQO (e.g., in the context of an inter- 980 domain VPN service, additional PE router resources need to be 981 allocated), the server may generate child PQOs to request the 982 appropriate network provisioning operations (see Figure 7). In such 983 situation, the server behaves also as a CPNP client. The server 984 associates the parent order with its child PQOs. How this is 985 achieved is implementation-specific (e.g., this can be typically 986 achieved by locally adding the reference of the child PQO to the 987 parent order). 989 +------+ +--------+ +--------+ 990 |Client| |Server A| |Server B| 991 +------+ +--------+ +--------+ 992 | | | 993 |=====QUOTATION=====>| | 994 |<====PROCESSING=====| | 995 | |=====QUOTATION=====>| 996 | |<====PROCESSING=====| 997 | |<=======OFFER=======| 998 | |=====PROCESSING====>| 999 | |=======ACCEPT======>| 1000 | |<=======ACK=========| 1001 |<=======OFFER=======| | 1002 |=====PROCESSING====>| | 1003 |=======ACCEPT======>| | 1004 |<=======ACK=========| | 1005 | | | 1007 Figure 7: Example of Child Orders 1009 Note that recursion must not be activated by the server for an order 1010 if the client includes a negotiation option to restrict the 1011 negotiation scope to the resources of the server's domain 1012 (Section 9.1.10.3). 1014 If recursion is not explicitly disabled, the server may notify the 1015 client when appropriate (Section 9.2.2). Such notification may also 1016 depend on the nature of the service but also regulatory 1017 considerations. 1019 8.9. Multi-Segment Service 1021 A composite service (e.g., connectivity) requested by a customer 1022 could imply multi-segment services (e.g., multi-segment connectivity 1023 spanning an end-to-end scope), in the sense that one single CPNP 1024 request is decomposed into N connectivity requests at the provider's 1025 side (thereby leading to child orders). The Provider is in charge of 1026 handling the complexity of splitting the generic provisioning order 1027 in a multi-segment context. Such complexity is local to the 1028 Provider. 1030 8.10. Negotiating with Multiple CPNP Servers 1032 A CPNP client may undertake multiple negotiations in parallel with 1033 several servers for various reasons, such as cost optimization and 1034 fail-safety. These multiple negotiations may lead to one or many 1035 agreements. 1037 The salient point underlining the parallel negotiation scenarios is 1038 that, although the negotiation protocol is strictly between two 1039 parties, this may not be the case of the negotiation logic. The CPNP 1040 client negotiation logic may need to collectively drive parallel 1041 negotiations, as the negotiation with one server may affect the 1042 negotiation with other servers; for example, it may need to use the 1043 responses from all servers as an input for determining the messages 1044 (and their content) to subsequently send within the course of each 1045 individual negotiation. Timing is therefore an important aspect at 1046 the client's side. The CPNP client needs to have the ability to 1047 synchronize the receipt of the responses from the servers. CPNP 1048 takes into account this requirement by allowing clients to specify in 1049 the QUOTATION message the time by which the server needs to respond 1050 (see Section 9.1.6). 1052 8.11. State Management 1054 Both the client and the server maintain repositories to store ongoing 1055 orders. How these repositories are maintained is deployment- 1056 specific. It is out of scope of this document to elaborate on such 1057 considerations. Timestamps are also logged to track state change. 1058 Tracking may be needed for various reasons, including regulatory or 1059 billing ones. 1061 In order to accommodate failures that may lead to the reboot of the 1062 client or the server, the use of permanent storage is recommended, 1063 thereby facilitating state recovery. 1065 8.11.1. On the Client Side 1067 This is the list of the typical states that can be associated with a 1068 given order on the client's side: 1070 o Created: when the order has been created. It is not handled by 1071 the client until the administrator allows to process it. 1073 o AwaitingProcessing: when the administrator approved the processing 1074 of a created order and the order has not been handled yet. 1076 o PQOSent: when the order has been sent to the server. 1078 o ServerProcessing: when the server has confirmed the receipt of the 1079 order. 1081 o OfferReceived: when an offer has been received from the server. 1083 o OfferProcessing: when a received offer is currently processed by 1084 the client. 1086 o AcceptSent: when the client confirmed the offer to the server. 1088 o Completed: when the offer is acknowledged by the server. 1090 o Cancelled: when the order has failed or cancelled. 1092 Sub-states may be defined (e.g., to track failed vs. cancelled 1093 orders) but those are not shown in Figure 8. 1095 +------------------+ 1096 | Created |-----------------+ 1097 +------------------+ | 1098 | | 1099 v | 1100 +------------------+ | 1101 |AwaitingProcessing|----------------+| 1102 +------------------+ || 1103 | || 1104 QUOTATION/UPDATE || 1105 v || 1106 +------------------+ || 1107 | PQOSent |---CANCEL------+|| 1108 +------------------+ vvv 1109 | +-----+ 1110 PROCESSING | | 1111 v | | 1112 +------------------+ CANCEL | C | 1113 | ServerProcessing |------------>| A | 1114 +------------------+ FAIL | N | 1115 | | C | 1116 | | E | 1117 OFFER | L | 1118 | | L | 1119 v | E | 1120 +------------------+ | D | 1121 | OfferReceived |---CANCEL--->| | 1122 +------------------+ | | 1123 | PROCESSING +-----+ 1124 v ^^^ 1125 +------------------+ ||| 1126 | OfferProcessing |---DECLINE-----+|| 1127 +------------------+ || 1128 | ACCEPT || 1129 v || 1130 +------------------+ || 1131 | AcceptSent |---CANCEL-------+| 1132 +------------------+ | 1133 | ACK | 1134 v | 1135 +------------------+ | 1136 | Completed |---WITHDRAW------+ 1137 +------------------+ 1139 Figure 8: Example of a CPNP Finite State Machine (Client Side) 1141 8.11.2. On the Server Side 1143 The following lists the states which can be associated with a given 1144 order and a corresponding offer on the server's side: 1146 o PQOReceived: when the order has been received from the client. 1148 o AwaitingProcessing: when the order is being processed by the 1149 server. An action from the server administrator may be needed. 1151 o OfferProposed: when the request has been successfully handled and 1152 an offer has been sent to the client. 1154 o ProcessingReceived: when the server received a PROCESSING for an 1155 offer sent to the client. 1157 o AcceptReceived: when the server received a confirmation for the 1158 offer from the client. 1160 o Completed: when the server acknowledged the offer (accepted by 1161 client) to the client. Transitioning to this state assumes that 1162 the ACK was received by the client (this can be detected by the 1163 server if it receives retransmitted ACCEPT from the client). 1165 o Cancelled: when the order cannot be accommodated or it has been 1166 cancelled by the client. Associate resources must be released in 1167 the latter case, if previously reserved. 1169 o ChildCreated: when a child order has been created in cases where 1170 resources from another Network Provider are needed. 1172 o ChildPQOSent: when a child order has been sent to the remote 1173 server. 1175 o ChildServerProcessing: when a child order is currently processed 1176 by the remote server. 1178 o ChildOfferReceived: when an offer has been received to a child 1179 order from the remote server. 1181 o ChildOfferProcessing: when a received offer to a child order is 1182 currently processed. 1184 o ChildAcceptSent: when the child offer (offer received from the 1185 remote server in response to a child order) is confirmed to the 1186 remote server. 1188 o ChildCompleted: when an accepted child offer is acknowledged by 1189 the remote server. 1191 +------------------+ +------------------+ 1192 |AwaitingProcessing|<----------| ChildCreated | 1193 +------------------+ +------------------+ 1194 | | ^ 1195 v | | 1196 +------------------+ | | 1197 | ChildPQOSent |----------------+| Q 1198 +------------------+ || U 1199 | || O 1200 QUOTATION/UPDATE || T 1201 v || A +--------------------+ 1202 +---------------------+ CANCEL || T | PQOReceived | 1203 |ChildServerProcessing|------------+|| I +--------------------+ 1204 +---------------------+ FAIL vvv O | | 1205 | +-----+ N CANCEL | 1206 PROCESSING | |<---|-------+ PROCESSING 1207 v | | | v 1208 +------------------+ | | +------------------------+ 1209 |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | 1210 +------------------+ | A | +------------------------+ 1211 | | N | ^ | OFFER 1212 OFFER | C | | +------------------+ 1213 | | E | ::= 1373 ... 1374 ::= 1375 ... 1376 ::= 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 ::= ... 1391 ::= 1392 1393 1395 Figure 10: The RBNF format of the Connectivity Provisioning Document 1396 (CPD) 1398 9.1.10. CPNP Information Elements 1400 An Information Element (IE) is an optional object which can be 1401 included in a CPNP message. 1403 9.1.10.1. Customer Description 1405 The client may include administrative information such as: 1407 o Name 1408 o Contact Information 1410 The format of this Information Element is as follows: 1412 ::= [] [] 1413 ::= [] [] 1414 [ ...] 1416 9.1.10.2. Provider Description 1418 The server may include administrative information in an offer such 1419 as: 1421 o Name 1422 o AS Number ([RFC6793]) 1423 o Contact Information 1425 The format of this Information Element is as follows: 1427 ::= [][][] 1429 9.1.10.3. Negotiation Options 1431 The client may include some negotiation options such as: 1433 o Setup purpose: A client may request the setup of a service (e.g., 1434 connectivity) only for testing purposes during a limited period. 1435 The order can be extended to become permanent if the client was 1436 satisfied during the test period. This operation is achieved 1437 using the UPDATE method. 1438 o Activation type: A client may request a permanent or scheduled 1439 activation type. If no activation type clause is included during 1440 the negotiation, this means that the order will be immediately 1441 activated right after the negotiation ends. 1443 The format of this Information Element is as follows: 1445 ::= [] 1447 9.2. Operation Messages 1449 This section defines the RBNF format of CPNP operation messages. The 1450 following operation codes are used: 1452 1: QUOTATION (Section 9.2.1) 1453 2: PROCESSING (Section 9.2.2) 1454 3: OFFER (Section 9.2.3) 1455 4: ACCEPT (Section 9.2.4) 1456 5: DECLINE (Section 9.2.5) 1457 6: ACK (Section 9.2.6) 1458 7: CANCEL (Section 9.2.7) 1459 8: WITHDRAW (Section 9.2.8) 1460 9: UPDATE (Section 9.2.9) 1461 10: FAIL (Section 9.2.10) 1462 11: ACTIVATE (Section 9.2.11) 1463 These codes are used to unambiguously identify a CPNP operation; the 1464 operation code is conveyed in the "METHOD_CODE" attribute mentioned 1465 in the following sub-sections. 1467 In the following, "VERSION" refers to the CPNP version number. This 1468 attribute must be set to 1. 1470 9.2.1. QUOTATION 1472 The format of the QUOTATION message is shown below: 1474 ::= 1475 1476 1477 1478 1479 [] 1480 1481 [...] 1483 A QUOTATION message must include an order identifier which is 1484 generated by the client (CUSTOMER_AGREEMENT_IDENTIFIER). Because 1485 several orders can be issued to several servers, the QUOTATION 1486 message must also include a Transaction-ID. 1488 The message may include an EXPECTED_RESPONSE_TIME which indicates by 1489 when the client is expecting to receive an offer from the server. 1490 QUOTATION message must also include a requested service description 1491 (that is, requested connectivity provisioning document for 1492 connectivity services). 1494 The message may include ACTIVATION_TYPE to request a permanent or 1495 scheduled activation type (e.g., using the ACTIVATE method defined in 1496 Section 9.2.11). If no such clause is included, the default mode is 1497 to assume that the order will be active once the agreed activation 1498 means are successfully invoked (e.g., Section 3.11 of [RFC7297]). 1500 When the client sends the QUOTATION message to the server, the state 1501 of the order changes to "PQOSent" at the client side. 1503 9.2.2. PROCESSING 1505 The format of the PROCESSING message is shown below: 1507 ::= 1508 1509 1510 1511 1512 1513 [] 1514 [] 1516 Upon receipt of a QUOTATION message, the server proceeds with parsing 1517 rules (see Section 10). If no error is encountered, the server 1518 generates a PROCESSING response to the client to indicate the PQO has 1519 been received and it is being processed. The server must generate an 1520 order identifier which identifies the order in its local order 1521 repository. The server must copy the content of 1522 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed 1523 in the QUOTATION message. The server may include an 1524 EXPECTED_OFFER_TIME by when it expects to make an offer to the 1525 client. 1527 Upon receipt of a PROCESSING message, the client verifies whether it 1528 has issued a PQO to that server and which contains the 1529 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is 1530 found, the PROCESSING message must be silently ignored. If a PQO is 1531 found, the client may check whether it accepts the 1532 EXPECTED_OFFER_TIME and then, it changes to state of the order to 1533 "ServerProcessing". 1535 If more time is required by the server to process the quotation 1536 order, it may send a PROCESSING message that includes a new 1537 EXPECTED_OFFER_TIME. The client can answer with an ACK message if 1538 more time is granted (Figure 11) or with a FAIL message if the time 1539 extension request is rejected (Figure 12). 1541 The server may provide more details in the PROCESSING_SUBCODE 1542 attribute about the reason for requesting more time to process the 1543 request. The following codes are defined: 1545 (1) Upgrade of local resources 1547 (2) Request external resources 1548 +------+ +------+ 1549 |Client| |Server| 1550 +------+ +------+ 1551 |=======QUOTATION(Requested CPD)=====>| 1552 |<========PROCESSING(time1)===========| 1553 ... 1554 |<========PROCESSING(MoreTime)========| 1555 |============ACK(TimeGranted)========>| 1556 ... 1557 |<=========OFFER(Offered CPD)=========| 1558 |=============PROCESSING=============>| 1559 |==========ACCEPT(Agreed CPD)========>| 1560 |<==========ACK(Agreed CPD)===========| 1561 | | 1563 Figure 11: Request More Negotiation Time: Granted 1565 +------+ +------+ 1566 |Client| |Server| 1567 +------+ +------+ 1568 |=======QUOTATION(Requested CPD)=====>| 1569 |<========PROCESSING(time1)===========| 1570 ... 1571 |<========PROCESSING(MoreTime)========| 1572 |=====FAIL(More Time Rejected)=======>| 1574 Figure 12: Request More Negotiation Time: Rejected 1576 9.2.3. OFFER 1578 The format of the OFFER message is shown below: 1580 ::= 1581 1582 1583 1584 1585 1586 1587 1588 1589 [...] 1591 The server answers with an OFFER message to a QUOTATION request 1592 received from the client. The offer will be considered as rejected 1593 by the client if no confirmation (ACCEPT message sent by the client) 1594 is received by the server before the expiration of the validity time. 1596 The server may include ACTIVATION_TYPE to indicate whether the offer 1597 is about a permanent or scheduled activation type. The message may 1598 include ACTIVATION_SCHEDULE to indicate when the order is to be 1599 activated. If no such clause is included, the default mode is to 1600 assume that the order will be active once the agreed activation means 1601 are successfully invoked (e.g., Section 3.11 of [RFC7297] or 1602 Section 9.2.11). 1604 9.2.4. ACCEPT 1606 The format of the ACCEPT message is shown below: 1608 ::= 1609 1610 1611 1612 1613 1614 1615 1616 [...] 1618 This message is used by a client to confirm the acceptance of an 1619 offer received from a server. The fields of this message must be 1620 copied from the received OFFER message. This message should not be 1621 sent after the validity time of the offer expires, as indicated by 1622 the server (Section 9.2.3). 1624 9.2.5. DECLINE 1626 The format of the DECLINE message is shown below: 1628 ::= 1629 1630 1631 1632 1633 1634 1635 [...] 1637 The client may issue a DECLINE message to reject an offer. 1638 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, 1639 TRANSACTION_ID, and NONCE are used by the server as keys to find the 1640 corresponding order. If an order matches, the server changes the 1641 state of this order to "Cancelled" and then returns an ACK with a 1642 copy of the requested CPD to the requesting client. 1644 A DECLINE message may include an information element to indicate the 1645 reason for declining an offer. The following codes are defined: 1647 1 (Unacceptable gap between the request and the offer) 1649 2 (Conflict with another offer from another server) 1651 3 (Activation type mismatch) 1653 If no order is found, the server returns a FAIL message to the 1654 requesting client. In order to prevent DDoS (Distributed Denial of 1655 Service) attacks, the server should restrict the number of FAIL 1656 messages sent to a requesting client. It may also rate-limit FAIL 1657 messages. 1659 A flow example is shown in Figure 13. 1661 +------+ +------+ 1662 |Client| |Server| 1663 +------+ +------+ 1664 |=======QUOTATION(Requested CPD)=====>| 1665 |<============PROCESSING==============| 1666 |<=========OFFER(Offered CPD)=========| 1667 |=============PROCESSING=============>| 1668 |===============DECLINE==============>| 1669 |<================ACK=================| 1670 | | 1672 Figure 13: DECLINE Flow Example 1674 9.2.6. ACK 1676 The format of the ACK message is shown below: 1678 ::= 1679 1680 1681 1682 1683 1684 [] 1685 [] 1686 [...] 1688 This message is issued by the server to close a CPNP transaction or 1689 by a client to grant more negotiation time to the server. 1691 This message is sent by the server as a response to an ACCEPT, 1692 WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message 1693 must include the copy of the service description document as stored 1694 by the server. In particular, the following considerations are taken 1695 into account for connectivity provisioning services: 1697 o A copy of the requested/offered CPD is included by the server if 1698 it successfully handled a CANCEL message. 1699 o A copy of the updated CPD is included by the server if it 1700 successfully handled an UPDATE message. 1701 o A copy of the offered CPD is included by the server if it 1702 successfully handled an ACCEPT message in the context of a 1703 QUOTATION transaction (refer to "Agreed CPD" in Section 8.7). 1704 o An empty CPD is included by the server if it successfully handled 1705 a DECLINE or WITHDRAW message. 1707 A client may issue an ACK message as a response to a time extension 1708 request (conveyed in PROCESSING) received from the server. In such 1709 case, the ACK message must include an EXPECTED_RESPONSE_TIME that is 1710 likely to be set to the time extension requested by the server. 1712 9.2.7. CANCEL 1714 The format of the CANCEL message is shown below: 1716 ::= 1717 1718 1719 1720 1721 [] 1723 The client can issue a CANCEL message at any stage during the CPNP 1724 negotiation process before an agreement is reached. 1725 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID are used by the 1726 server as keys to find the corresponding order. If a quotation order 1727 matches, the server changes the state of this quotation order to 1728 "Cancelled" and then returns an ACK with a copy of the requested CPD 1729 to the requesting client. 1731 If no quotation order is found, the server returns a FAIL message to 1732 the requesting client. 1734 9.2.8. WITHDRAW 1736 The format of the WITHDRAW message is shown below: 1738 ::= 1739 1740 1741 1742 1743 1744 1745 [] 1746 [...] 1748 This message is used to withdraw an offer already accepted by the 1749 Customer. Figure 14 shows a typical usage of this message. 1751 +------+ +------+ 1752 |Client| |Server| 1753 +------+ +------+ 1754 |============WITHDRAW(CPD)===========>| 1755 |<============PROCESSING==============| 1756 |<===========ACK(Empty CPD)===========| 1757 | | 1759 Figure 14: WITHDRAW Flow Example 1761 The WITHDRAW message must include the same 1762 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1763 NONCE as those used when creating the order. 1765 Upon receipt of a WITHDRAW message, the server checks whether an 1766 order matching the request is found. If an order is found, the state 1767 of the order is changed to "Cancelled" and an ACK message including 1768 an Empty CPD is returned to the requesting client. If no order is 1769 found, the server returns a FAIL message to the requesting client. 1771 9.2.9. UPDATE 1773 The format of the UPDATE message is shown below: 1775 ::= 1776 1777 1778 1779 1780 1781 1782 1783 1784 [...] 1786 This message is sent by the CPNP client to update an existing service 1787 agreement (e.g., connectivity provisioning agreement). The UPDATE 1788 message must include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1789 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1790 the order. The CPNP client includes a new service description (e.g., 1791 updated CPD) which integrates the requested modifications. A new 1792 Transaction_ID must be assigned by the client. 1794 Upon receipt of an UPDATE message, the server checks whether an 1795 order, having state "Completed", matches 1796 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1797 NONCE. 1799 o If no order is found, the CPNP server generates a FAIL error with 1800 the appropriate error code (Section 9.2.10). 1801 o If an order is found, the server checks whether it can honor the 1802 request: 1804 * A FAIL message is sent to the client if the server cannot honor 1805 the request. The client may initiate a new PQO negotiation 1806 cycle (that is, a new UPDATE). 1807 * An OFFER message including the updated clauses (e.g., updated 1808 connectivity provisioning document) is sent to the client. For 1809 example, the server maintains an order for provisioning a VPN 1810 service that connects sites A, B, and C. If the client sends 1811 an UPDATE message to remove site C, only sites A and B will be 1812 included in the OFFER sent by the server to the requesting 1813 client. 1815 Note that the cycle that is triggered by an UPDATE message is 1816 also considered as a negotiation cycle. 1818 A flow chart that illustrates the use of UPDATE operation is shown in 1819 Figure 15. 1821 +------+ +------+ 1822 |Client| |Server| 1823 +------+ +------+ 1824 |=========UPDATE(Requested CPD)======>| 1825 |<============PROCESSING==============| 1826 |<=========OFFER(Updated CPD)=========| 1827 |=============PROCESSING=============>| 1828 |==========ACCEPT(Updated CPD)=======>| 1829 |<==========ACK(Updated CPD)==========| 1830 | | 1832 Figure 15: UPDATE Flow Example 1834 9.2.10. FAIL 1836 The format of the FAIL message is shown below: 1838 ::= 1839 1840 1841 1842 1843 1844 1846 This message is sent in the following cases: 1848 o The server cannot honor an order received from the client (i.e., 1849 received in a QUOTATION or UPDATE request). 1850 o The server encounters an error when processing a CPNP request 1851 received from the client. 1852 o The client cannot grant more time to the server. This is a 1853 response to a time extension request carried in a PROCESSING 1854 message. 1856 The status code indicates the error code. The following codes are 1857 supported: 1859 1 (Message Validation Error): 1860 The message cannot be validated (see Section 10). 1861 2 (Authentication Required): 1862 The request cannot be handled because authentication is 1863 required. 1864 3 (Authorization Failed): 1865 The request cannot be handled because authorization failed. 1866 4 (Administratively prohibited): 1867 The request cannot be handled because of administrative 1868 policies. 1869 5 (Out of Resources): 1870 The request cannot be honored because resources (e.g., capacity) 1871 are insufficient. 1872 6 (Network Presence Error): 1873 The request cannot be honored because there is no network 1874 presence. 1875 7 (More Time Rejected): 1876 The request to extend the time for negotiation is rejected by 1877 the client. 1878 8 (Unsupported Activation Type): 1879 The request cannot be handled because the requested activation 1880 type is not supported. 1882 9.2.11. ACTIVATE 1884 The format of the ACTIVATE message is shown below: 1886 ::= 1887 1888 1889 1890 1891 1892 1893 1894 [...] 1896 This message is sent by the CPNP client to request the activation of 1897 an existing service agreement. The message must include the same 1898 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1899 NONCE as those used when creating the order. The CPNP client may 1900 includes a schedule target for activating this order. A new 1901 Transaction_ID must be assigned by the client. 1903 Upon receipt of an ACTIVATE message, the server checks whether an 1904 order, having state "Completed", matches 1905 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1906 NONCE. 1908 o If no completed order is found, the CPNP server generates a FAIL 1909 error with the appropriate error code (Section 9.2.10). 1910 o If an order is found, the server checks whether it can honor the 1911 request: 1913 * A FAIL message is sent to the client if the server cannot honor 1914 the request (e.g., out of resources or explicit activation 1915 wasn't negotiated with this client). 1916 * An ACK is sent to the client to confirm that the immediate 1917 activation (or de-activation) of the order or its successful 1918 scheduling if a non-null ACTIVATION_SCHEDULE was included in 1919 the request. Note that setting ACTIVATION_SCHEDULE to 0 in an 1920 ACTIVATE request has a special meaning: it is used to request a 1921 de-activation of an agreed order. 1923 Figure 16 illustrates the use of ACTIVATE operation. 1925 +------+ +------+ 1926 |Client| |Server| 1927 +------+ +------+ 1928 |================ACTIVATE()==========>| 1929 |<==============ACK()=================| 1930 | | 1932 Figure 16: ACTIVATE Flow Example 1934 10. CPNP Message Validation 1936 Both client and server proceed with CPNP message validation. The 1937 following tables summarize the validation checks to be followed. 1939 10.1. On the Client Side 1940 Operation Validation Checks 1941 ------------ -------------------------------------------------------- 1942 PROCESSING {Source IP address, source port number, destination IP 1943 address, destination port number, Transaction- 1944 ID, Customer Order Identifier} must match an 1945 existing PQO with a state set to "PQOSent". The 1946 sequence number carried in the packet must be larger 1947 than the sequence number maintained by the 1948 client. 1949 OFFER {Source IP address, source port number, destination IP 1950 address, destination port number, Transaction- 1951 ID, Customer Order Identifier} must match an 1952 existing order with state set to "PQOSent" or {Source 1953 IP address, source port number, destination IP address, 1954 destination port number, Transaction-ID, 1955 Customer Order Identifier, Provider Order 1956 Identifier} must match an existing order with a state 1957 set to "ServerProcessing". The sequence number 1958 carried in the packet must be larger than the 1959 sequence number maintained by the client. 1960 ACK {Source IP address, source port number, destination IP 1961 (QUOTATION address, destination port number, Transaction- 1962 Transaction) ID, Customer Order Identifier, Provider Order 1963 Identifier, Offered Connectivity Provisioning Order} 1964 must match an order with a state set to "AcceptSent". 1965 The sequence number carried in the packet must 1966 be larger than the sequence number maintained 1967 by the client. 1968 ACK (UPDATE {Source IP address, source port number, destination IP 1969 Transaction) address, destination port number, Transaction- 1970 ID, Customer Order Identifier, Provider Order 1971 Identifier, Updated Connectivity Provisioning Order} 1972 must match an order with a state set to "AcceptSent". 1973 The sequence number carried in the packet must 1974 be larger than the sequence number maintained 1975 by the client. 1976 ACK {Source IP address, source port number, destination IP 1977 (WITHDRAW address, destination port number, Transaction- 1978 Transaction) ID, Customer Order Identifier, Provider Order 1979 Identifier, Empty Connectivity Provisioning Order} 1980 must match an order with a state set to "Cancelled". The 1981 sequence number carried in the packet must be 1982 larger than the sequence number maintained by 1983 the client. 1985 10.2. On the Server Side 1987 Method Validation Checks 1988 ---------- ---------------------------------------------------------- 1989 QUOTATION The source IP address passes existing access filters (if 1990 any). The sequence number carried in the packet 1991 must not be lower than the sequence number 1992 maintained by the server. 1993 PROCESSING The sequence number carried in the packet must be greater 1994 than the sequence number maintained by the 1995 server. 1996 CANCEL {Source IP address, source port number, destination IP 1997 address, destination port number, Transaction- 1998 ID, Customer Order Identifier} must match an 1999 order with state set to "PQOReceived" or 2000 "OfferProposed" or "ProcessingReceived" or "AcceptReceived 2001 ". The sequence number carried in the packet 2002 must be greater than the sequence number 2003 maintained by the server. 2004 ACCEPT {Source IP address, source port number, destination IP 2005 address, destination port number, Transaction- 2006 ID, Customer Order Identifier, Provider Order 2007 Identifier, Nonce, Offered Connectivity Provisioning 2008 Order} must match an order with state set to 2009 "OfferProposed" or "ProcessingReceived". The 2010 sequence number carried in the packet must be 2011 greater than the sequence number maintained by the server. 2012 FAIL {Source IP address, source port number, destination IP 2013 address, destination port number, Transaction- 2014 ID, Customer Order Identifier, Provider Order 2015 Identifier} must match an order with state set to 2016 "AwaitingProcessing" and for which a request to grant more 2017 time to process an offer was requested. The 2018 sequence number carried in the packet must be 2019 greater than the sequence number maintained by the 2020 server. 2021 DECLINE {Source IP address, source port number, destination IP 2022 address, destination port number, Transaction- 2023 ID, Customer Order Identifier, Provider Order 2024 Identifier, Nonce} must match an order with state set 2025 to "OfferProposed" or "ProcessingReceived". The sequence 2026 number carried in the packet must be greater 2027 than the sequence number maintained by the 2028 server. 2029 UPDATE The source IP address passes existing access filters (if 2030 any) and {Customer Order Identifier, Provider 2031 Order Identifier, Nonce} must match an existing 2032 order with state "Completed". 2034 WITHDRAW The source IP address passes existing access filters (if 2035 any) and {Customer Order Identifier, Provider 2036 Order Identifier, Nonce} must match an existing 2037 order with state "Completed". 2038 ACTIVATE The source IP address passes existing access filters (if 2039 any) and {Customer Order Identifier, Provider 2040 Order Identifier, Nonce} must match an existing 2041 order with state "Completed" for which the 2042 activation procedure is tagged to be explicit. 2044 11. Theory of Operation 2046 Both CPNP client and server proceed with message validation checks as 2047 specified in Section 10. 2049 11.1. Client Behavior 2051 11.1.1. Order Negotiation Cycle 2053 To place a provisioning quotation order, the client first initiates a 2054 local quotation order object identified by a unique identifier 2055 assigned by the client (Client Order Identifier). The state of the 2056 quotation order is set to "Created". The client then generates a 2057 QUOTATION request which includes the assigned identifier, possibly an 2058 expected response time, a Transaction-ID, and a Requested Service 2059 (e.g., Requested Connectivity Provisioning Document). The client may 2060 include additional Information Elements such as Negotiation Options 2061 or Activation Type. 2063 The client may be configured to not enforce negotiation checks on 2064 EXPECTED_OFFER_TIME; if so, no EXPECTED_RESPONSE_TIME attribute (or 2065 EXPECTED_RESPONSE_TIME set to infinite) should be included in the 2066 quotation order. 2068 Once the request is sent to the server, the state of the request is 2069 set to "PQOSent" and a timer, if a response time is included in the 2070 quotation order, is set to the expiration time as included in the 2071 QUOTATION request. The client also maintains a copy of the CPNP 2072 session entry details used to generate the QUOTATION request. The 2073 CPNP client must listen on the same port number that it used to send 2074 the QUOTATION request. 2076 If no answer is received from the server before the retransmission 2077 timer expires (i.e., RETRANS_TIMER, Section 8.5), the client 2078 retransmits the message until maximum retry is reached (e.g., 3 2079 times). The same sequence number is used for retransmitted packets. 2081 If a FAIL message is received, the client may decide to issue another 2082 (corrected) request towards the same server, cancel the local order, 2083 or contact another server. The behavior of the client depends on the 2084 error code returned by the server in the FAIL message. 2086 If a PROCESSING message matching the CPNP session entry (Section 8.3) 2087 is received, the client updates the CPNP session entry with the 2088 PROVIDER_AGREEMENT_IDENTIFIER information. If the client does not 2089 accept the expected offer time that may have been indicated in the 2090 PROCESSING message, the client may decide to cancel the quotation 2091 order. If the client accepts the EXPECTED_OFFER_TIME, it changes the 2092 state of the order to "ServerProcessing" and sets a timer to the 2093 value of EXPECTED_OFFER_TIME. If no offer is made before the timer 2094 expires, the client changes the state of the order to "Cancelled". 2096 As a response to a time extension request (conveyed in a PROCESSING 2097 message that included a new EXPECTED_OFFER_TIME), the client may 2098 grant this extension by issuing an ACK message or reject the time 2099 extension with a FAIL message having a status code set to "More Time 2100 Rejected". 2102 If an OFFER message matching the CPNP session entry is received, the 2103 client checks if a PROCESSING message having the same 2104 PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If 2105 a PROCESSING message was already received for the same order but the 2106 PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included 2107 in the OFFER message, the client silently ignores the message. If a 2108 PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was 2109 already received and matches the CPNP transaction identifier, the 2110 client changes the state of the order to "OfferReceived" and sets a 2111 timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER 2112 message. 2114 If an offer is received from the server (i.e., as documented in an 2115 OFFER message), the client may accept or reject the offer. The 2116 client accepts the offer by generating an ACCEPT message which 2117 confirms that the client agrees to subscribe to the offer documented 2118 in the OFFER message; the state of the order is passed to 2119 "AcceptSent". The transaction is terminated if an ACK message is 2120 received from the server. If no ACK is received from the server, the 2121 client proceeds with the retransmission of the ACCEPT message until 2122 the maximum retry is reached (Section 11.4). 2124 The client may also decide to reject the offer by sending a DECLINE 2125 message. The state of the order is set by the client to "Cancelled". 2126 If an offer is not acceptable by the client, the client may decide to 2127 contact a new server or submit another order to the same server. 2129 Guidelines to issue an updated order or terminate the negotiation are 2130 specific to the client. 2132 An order can be activated (or de-activated) using the ACTIVATE 2133 message or other agreed activation means (Section 3.11 of [RFC7297]). 2135 11.1.2. Order Withdrawal Cycle 2137 A client may withdraw a completed order. This is achieved by issuing 2138 a WITHDRAW message. This message must include Customer Order 2139 Identifier, Provider Identifier, and Nonce returned during the order 2140 negotiation cycle, as specified in Section 11.1.1. 2142 If no ACK is received from the server, the client proceeds with the 2143 retransmission of the message. If no ACK is received after the 2144 maximum retry is exhausted, the client should log the information and 2145 must send an alarm to the administrator. If there is no specific 2146 instruction from the administrator, the client should schedule 2147 another Withdrawal cycle. The client must not retry this Withdrawal 2148 cycle more frequently than every 300 seconds and must not retry more 2149 frequently than every 60 seconds. 2151 11.1.3. Order Update Cycle 2153 A client may update a completed order. This is achieved by issuing 2154 an UPDATE message. This message must include Customer Order 2155 Identifier, Provider Order Identifier and Nonce returned during the 2156 order negotiation cycle specified in Section 11.1.1. The client must 2157 include in the UPDATE message an updated CPD with the requested 2158 changes. 2160 Subsequent messages exchange is similar to what is documented in 2161 Section 11.1.1. 2163 11.2. Server Behavior 2165 11.2.1. Order Processing 2167 Upon receipt of a QUOTATION message from a client, the server sets a 2168 CPNP session, stores Transaction-ID and generates a Provider Order 2169 Identifier. Once preliminary validation checks are completed ( 2170 Section 10), the server may return a PROCESSING message to inform the 2171 client that the quotation order is received and it is under 2172 processing; the server may include an expected offer time to notify 2173 the client by when an offer will be proposed. An order with state 2174 "AwaitingProcessing" is created by the server. The server runs its 2175 decision-making process to decide which offer it can make to honor 2176 the received order. The offer should be made before the expected 2177 offer time expires. 2179 If the server cannot make an offer, it sends backs a FAIL message 2180 with the appropriate error code. 2182 If the server requires more negotiation time, it must send a 2183 PROCESSING message with a new EXPECTED_OFFER_TIME. The client may 2184 grant this extension by issuing an ACK message or reject the time 2185 extension with a FAIL message having a status code set to "More Time 2186 Rejected". If the client doesn't grant more time, the server must 2187 answer before the initial expected offer time; otherwise the client 2188 will decline the quotation order. 2190 If the server can honor the request or it can make an offer that 2191 meets only some of the requirements, it creates an OFFER message. 2192 The server must indicate the Transaction-ID, Customer Order 2193 Identifier as indicated in the QUOTATION message, and the Provider 2194 Order Identifier generated for this order. The server must also 2195 include Nonce and the offered service document (e.g., offered 2196 Connectivity Provisioning Document). The server includes an offer 2197 validity time as well. Once sent to the client, the server changes 2198 the state of the order to "OfferProposed" and a timer set to the 2199 validity time is initiated. 2201 If the server determines that additional network resources from 2202 another network provider are needed to accommodate a quotation order, 2203 it will create child PQO(s) and will behave as a CPNP client to 2204 negotiate child PQO(s) with possible partnering providers (see 2205 Figure 7). 2207 If no PROCESSING, ACCEPT, or DECLINE message is received before the 2208 expiry of the RETRANS_TIMER, the server re-sends the same offer to 2209 the client. This procedure is repeated until maximum retry is 2210 reached. 2212 If an ACCEPT message is received before the offered validity time 2213 expires, the server proceeds with validation checks as specified in 2214 Section 10. The state of the corresponding order is passed to 2215 "AcceptReceived". The server sends back an ACK message to terminate 2216 the order processing cycle. 2218 If a CANCEL/DECLINE message is received, the server proceeds with the 2219 cancellation of the order. The state of the order is then passed to 2220 "Cancelled". 2222 11.2.2. Order Withdrawal 2224 A client may withdraw a completed order by issuing a WITHDRAW 2225 message. Upon receipt of a WITHDRAW message, the server proceeds 2226 with the validation checks, as specified in Section 10: 2228 o If the checks fail, a FAIL message is sent back to the client with 2229 the appropriate error code (e.g., 1 (Message Validation Error), 2 2230 (Authentication Required), or 3 (Authorization Failed)). 2232 o If the checks succeed, the server clears the clauses of the 2233 Connectivity Provisioning Document, changes the state of the order 2234 to "Cancelled", and sends back an ACK message with an Empty 2235 Connectivity Provisioning Document. 2237 11.2.3. Order Update 2239 A client may update an order by issuing an UPDATE message. Upon 2240 receipt of an UPDATE message, the server proceeds with the validation 2241 checks as specified in Section 10: 2243 o If the checks fail, a FAIL message is sent back to the client with 2244 the appropriate error code (e.g., 1 (Message Validation Error), 2 2245 (Authentication Required), 3 (Authorization Failed), or 6 (Network 2246 Presence Error)). 2247 o The exchange of subsequent messages is similar to what is 2248 specified in Section 11.1.1. The server should generate a new 2249 Nonce value to be included in the offer made to the client. 2251 11.3. Sequence Numbers 2253 In each transaction, sequence numbers are used to protect the 2254 transaction against replay attacks. Each communicating partner of 2255 the transaction maintains two sequence numbers, one for incoming 2256 packets and one for outgoing packets. When a partner receives a 2257 message, it will check whether the sequence number in the message is 2258 larger than the incoming sequence number maintained locally. If not, 2259 the message will be discarded. If the message is proved to be 2260 legitimate, the value of the incoming sequence number maintained 2261 locally will be replaced by the value of the sequence number in the 2262 message. When a partner sends out a message, it will insert the 2263 value of the outgoing sequence number into the message and increase 2264 the outgoing sequence number maintained locally by 1. 2266 11.4. Message Re-Transmission 2268 If a transaction partner sends out a message and does not receive any 2269 expected reply before the retransmission timer expires (i.e., 2270 RETRANS_TIMER), a transaction partner will try to re-transmit the 2271 message. The procedure is reiterated until a maximum retry is 2272 reached (e.g., 3 times). An exception is the last message (e.g., 2273 ACK) sent from the server in a transaction. After sending this 2274 message, the retransmission timer will be disabled since no 2275 additional feedback is expected. 2277 In addition, if the partner receives a retransmission of a last 2278 incoming packet it handled, the partner can re-send the same answer 2279 to the incoming packet with a limited frequency. If no answer was 2280 generated at the moment, the partner needs to generate a PROCESSING 2281 message as the answer. 2283 To optimize message retransmission, a partner could also store the 2284 last incoming packet and the associated answer. Note that the times 2285 of retransmission could be decided by the local policy and 2286 retransmission will not cause any change of sequence numbers. 2288 12. Some Operational Guidelines 2290 12.1. Logging on the CPNP Server 2292 The CPNP server should be configurable to log various events and 2293 associated information. Such information may include: 2295 o Client's IP address 2296 o Any event change (e.g., new quotation order, offer sent, order 2297 confirm, order cancellation, order withdraw, etc.) 2298 o Timestamp 2300 The exact logging details are deployment-specific. 2302 12.2. Business Guidelines and Objectives 2304 The CPNP server can operate in the following modes: 2306 1. Fully automated mode: 2308 The CPNP server is provisioned with a set of business guidelines 2309 and objectives that will be used as an input to the decision- 2310 making process. The CPNP server will service received orders 2311 that fall into these business guidelines; otherwise, requests 2312 will be escalated to an administrator that will formally 2313 validate/invalidate an order request. The set of policies to be 2314 configured to the CPNP server are specific to each administrative 2315 entity managing a CPNP server. 2317 2. Administrative-based mode: 2319 This mode assumes some or all CPNP server' operations are subject 2320 to a formal administrative validation. CPNP events will trigger 2321 appropriate validation requests that will be forwarded to the 2322 contact person(s) or department which is responsible for 2323 validating the orders. Administrative validation messages are 2324 relayed using another protocol (e.g., SMTP) or a dedicated tool. 2326 Business guidelines are local to each administrative entity. How 2327 validation requests are presented to an administrator are out of 2328 scope of this document; each administrative entity may decide the 2329 appropriate mechanism to enable for that purpose. 2331 13. Security Considerations 2333 Means to defend the server against denial-of-service attacks must be 2334 enabled. For example, access control lists can be enforced on the 2335 client, the server or the network in between, to allow a trusted 2336 client to communicate with a trusted server. 2338 The client and the server must be mutually authenticated. 2339 Authenticated encryption must be used for data confidentiality and 2340 message integrity. 2342 The protocol does not provide security mechanisms to protect the 2343 confidentiality and integrity of the packets transported between the 2344 client and the server. An underlying security protocol such as 2345 (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport 2346 Layer Security (TLS) [RFC8446]) must be used to protect the integrity 2347 and confidentiality of protocol messages. In this case, if it is 2348 possible to provide an Automated Key Management and associate each 2349 transaction with a different key, inter-transaction replay attacks 2350 can naturally be addressed. If the client and the server use a 2351 single key, an additional mechanism should be provided to protect 2352 inter-transaction replay attacks between them. Clients must 2353 implement DTLS record replay detection (Section 3.3 of [RFC6347]) or 2354 an equivalent mechanism to protect against replay attacks. 2356 DTLS and TLS with a cipher suite offering confidentiality protection 2357 and the guidance given in [RFC7525] must be followed to avoid attacks 2358 on (D)TLS. 2360 The client must silently discard CPNP responses received from unknown 2361 CPNP servers. The use of a randomly generated Transaction-ID makes 2362 it hard to forge a response from a server with a spoofed IP address 2363 belonging to a legitimate CPNP server. Furthermore, CPNP demands 2364 that messages from the server must include the correct identifiers of 2365 the orders. Two order identifiers are used: one generated by the 2366 client and a second one generated by the server. Both the CPNP 2367 client and server maintain the local identifier they assigned and the 2368 one assigned by the peer for a given order. Means to detect swapping 2369 of these identifiers (even when such swapping occurs by inadvertence 2370 at the client or the server) should be enabled by CPNP clients/ 2371 servers. For example, the CPNP server should not assign a provider 2372 agreement identifier that is equal to a customer agreement identifier 2373 used by the CPNP client. 2375 The Provider must enforce means to protect privacy-related 2376 information included the documents (see Section 8.7) exchanged in 2377 CPNP messages [RFC6462]. In particular, this information must not be 2378 revealed to external parties without the consent of Customers. 2379 Providers should enforce policies to make Customer fingerprinting 2380 difficult to achieve (e.g., in a recursion request). For more 2381 discussion about privacy, refer to [RFC6462][RFC6973]. 2383 The Nonce and the Transaction ID attributes provide sufficient 2384 randomness and can effectively tolerate attacks raised by off-path 2385 adversaries, who do not have the capability of eavesdropping and 2386 intercepting the packets transported between the client and the 2387 server. Only authorized clients must be able to modify agreed CPNP 2388 orders. The use of a randomly generated Nonce by the server makes it 2389 hard to modify an agreement on behalf of a malicious third-party. 2391 14. IANA Considerations 2393 This document does not request any IANA action. 2395 15. Acknowledgements 2397 Thanks to Diego R. Lopez, Adrian Farrel, Eric Vyncke, Eric Kline, 2398 and Benjamin Kaduk for the comments. 2400 Thanks to the ISE reviewers. 2402 Special thanks to Luis Miguel Contreras Murillo for the detailed 2403 review. 2405 16. References 2406 16.1. Normative References 2408 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2409 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2410 . 2412 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2413 "Randomness Requirements for Security", BCP 106, RFC 4086, 2414 DOI 10.17487/RFC4086, June 2005, 2415 . 2417 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2418 Used to Form Encoding Rules in Various Routing Protocol 2419 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2420 2009, . 2422 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2423 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2424 January 2012, . 2426 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 2427 Connectivity Provisioning Profile (CPP)", RFC 7297, 2428 DOI 10.17487/RFC7297, July 2014, 2429 . 2431 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2432 "Recommendations for Secure Use of Transport Layer 2433 Security (TLS) and Datagram Transport Layer Security 2434 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2435 2015, . 2437 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2438 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2439 . 2441 16.2. Informative References 2443 [AGAVE] Boucadair, M., Georgatsos, P., Wang, N., Griffin, D., 2444 Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE 2445 Approach for Network Virtualization: Differentiated 2446 Services Delivery", April 2009, 2447 . 2450 [ETICS] EU FP7 ETICS Project, "Economics and Technologies of 2451 Inter-Carrier Services", January 2014, . 2455 [I-D.barguil-opsawg-l2sm-l2nm] 2456 Barguil, S., Dios, O., Boucadair, M., Munoz, L., Jalil, 2457 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 2458 barguil-opsawg-l2sm-l2nm-02 (work in progress), May 2020. 2460 [I-D.boucadair-lisp-idr-ms-discovery] 2461 Boucadair, M. and C. Jacquenet, "LISP Mapping Service 2462 Discovery at Large", draft-boucadair-lisp-idr-ms- 2463 discovery-01 (work in progress), March 2016. 2465 [I-D.contreras-teas-slice-nbi] 2466 Contreras, L., Homma, S., and J. Ordonez-Lucena, 2467 "Considerations for defining a Transport Slice NBI", 2468 draft-contreras-teas-slice-nbi-01 (work in progress), 2469 March 2020. 2471 [I-D.geng-netslices-architecture] 2472 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 2473 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 2474 Architecture", draft-geng-netslices-architecture-02 (work 2475 in progress), July 2017. 2477 [I-D.ietf-opsawg-l3sm-l3nm] 2478 Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A. 2479 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 2480 opsawg-l3sm-l3nm-03 (work in progress), April 2020. 2482 [I-D.itsumo-dsnp] 2483 Chen, J., "Dynamic Service Negotiation Protocol (DSNP)", 2484 draft-itsumo-dsnp-03 (work in progress), March 2006. 2486 [I-D.nguyen-rap-cops-sls] 2487 Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)", 2488 draft-nguyen-rap-cops-sls-03 (work in progress), July 2489 2002. 2491 [Karl] Czajkowski, K., Foster, I., Kesselman, C., Sander, V., and 2492 S. Tuecke, "SNAP: A Protocol for Negotiating Service Level 2493 Agreements and Coordinating Resource Management in 2494 Distributed Systems", 2495 . 2498 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2499 specifying the location of services (DNS SRV)", RFC 2782, 2500 DOI 10.17487/RFC2782, February 2000, 2501 . 2503 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 2504 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 2505 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 2506 RFC 3084, DOI 10.17487/RFC3084, March 2001, 2507 . 2509 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2510 Private Network (VPN) Terminology", RFC 4026, 2511 DOI 10.17487/RFC4026, March 2005, 2512 . 2514 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 2515 and A. Gonguet, "Framework for Layer 3 Virtual Private 2516 Networks (L3VPN) Operations and Management", RFC 4176, 2517 DOI 10.17487/RFC4176, October 2005, 2518 . 2520 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2521 Verification of Domain-Based Application Service Identity 2522 within Internet Public Key Infrastructure Using X.509 2523 (PKIX) Certificates in the Context of Transport Layer 2524 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2525 2011, . 2527 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2528 and A. Bierman, Ed., "Network Configuration Protocol 2529 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2530 . 2532 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 2533 RFC 6462, DOI 10.17487/RFC6462, January 2012, 2534 . 2536 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 2537 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 2538 . 2540 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 2541 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 2542 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 2543 November 2012, . 2545 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 2546 Autonomous System (AS) Number Space", RFC 6793, 2547 DOI 10.17487/RFC6793, December 2012, 2548 . 2550 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2551 Locator/ID Separation Protocol (LISP)", RFC 6830, 2552 DOI 10.17487/RFC6830, January 2013, 2553 . 2555 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2556 Morris, J., Hansen, M., and R. Smith, "Privacy 2557 Considerations for Internet Protocols", RFC 6973, 2558 DOI 10.17487/RFC6973, July 2013, 2559 . 2561 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2562 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2563 October 2013, . 2565 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 2566 Networking: A Perspective from within a Service Provider 2567 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 2568 . 2570 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 2571 Pascual, J., and D. Lewis, "Locator/Identifier Separation 2572 Protocol (LISP) Network Element Deployment 2573 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2574 2014, . 2576 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 2577 Application-Based Network Operations", RFC 7491, 2578 DOI 10.17487/RFC7491, March 2015, 2579 . 2581 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2582 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2583 . 2585 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2586 Interchange Format", STD 90, RFC 8259, 2587 DOI 10.17487/RFC8259, December 2017, 2588 . 2590 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2591 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2592 DOI 10.17487/RFC8299, January 2018, 2593 . 2595 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2596 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2597 . 2599 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2600 Kumar, "Framework for Interface to Network Security 2601 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2602 . 2604 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2605 Data Model for Layer 2 Virtual Private Network (L2VPN) 2606 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2607 2018, . 2609 [RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., 2610 and P. Iovanna, "Cooperating Layered Architecture for 2611 Software-Defined Networking (CLAS)", RFC 8597, 2612 DOI 10.17487/RFC8597, May 2019, 2613 . 2615 [TEQUILA] Georgatsos, P. and G. Giannakopoulos, "Service Negotiation 2616 Protocol (SrNP)", . 2619 [Xin] Wang, X., "Resource Negotiation and Pricing Protocol 2620 (RNAP)", 2621 . 2624 Authors' Addresses 2626 Mohamed Boucadair (editor) 2627 Orange 2628 Rennes 35000 2629 France 2631 Email: mohamed.boucadair@orange.com 2633 Christian Jacquenet 2634 Orange 2635 Rennes 35000 2636 France 2638 Email: christian.jacquenet@orange.com 2640 Dacheng Zhang 2641 Huawei Technologies 2643 Email: dacheng.zhang@huawei.com 2644 Panos Georgatsos 2645 Centre for Research and Innovation 2646 Hellas 2647 78, Filikis Etairias str. 2648 Volos, Hellas 38334 2649 Greece 2651 Phone: +302421306070 2652 Email: pgeorgat@gmail.com