idnits 2.17.1 draft-boucadair-connectivity-provisioning-protocol-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2020) is 1486 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 (-02) exists of draft-barguil-opsawg-l2sm-l2nm-01 == 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-02 -- 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 (~~), 4 warnings (==), 3 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: September 25, 2020 D. Zhang 6 Huawei Technologies 7 P. Georgatsos 8 CERTH 9 March 24, 2020 11 Dynamic Service Negotiation 12 draft-boucadair-connectivity-provisioning-protocol-20 14 Abstract 16 This document specifies 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 September 25, 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 . . . . . . . . . . . . . . . . . . . 7 63 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 64 6. CPNP Deployment Models . . . . . . . . . . . . . . . . . . . 11 65 7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 12 66 8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 15 67 8.1. Client/Server Communication . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . 55 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 uses cases are described in 146 Section 5. 148 [RFC7297] describes a Connectivity Provisioning Profile (CPP) 149 template to capture connectivity requirements to be met by a 150 transport infrastructure for the delivery of various services such as 151 Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) 152 services [RFC4026]. The CPP document defines the set of IP transfer 153 parameters that reflect the guarantees that can be provided by the 154 underlying transport network together with reachability scope and 155 capacity needs. CPNP uses the CPP template to encode connectivity 156 provisioning clauses that are subject to negotiation. The agreed CPP 157 will be then passed to other functional elements that are responsible 158 for the actual service activation and provisioning. For example, 159 NETCONF [RFC6241] or RESTCONF [RFC8040] can be used to activate 160 adequate network features that are required to deliver the agreed 161 service. How the outcome of CPNP negotiation is translated into 162 service and network provisioning actions is out of scope of this 163 document. 165 As a reminder, several proposals have been made in the past by the 166 (research) community (e.g., COPS-SLS [I-D.nguyen-rap-cops-sls], 167 Service Negotiation Protocol (SrNP) [TEQUILA], Dynamic Service 168 Negotiation Protocol (DSNP) [I-D.itsumo-dsnp], Resource Negotiation 169 and Pricing Protocol (RNAP) [Xin], Service Negotiation and 170 Acquisition Protocol (SNAP) [Karl]). CPNP leverages the experience 171 of the authors with SrNP by separating the negotiation primitives 172 from the service under negotiation. Moreover, careful examination of 173 the other proposals revealed certain deficiencies that were easier to 174 address through the creation of a new protocol rather than modifying 175 existing protocols. For example: 177 o COPS-SLS relies upon COPS-PR [RFC3084], which is an Historic RFC. 179 o DSNP is tightly designed with one specific service in mind (QoS) 180 and does not make any distinction between a quotation phase and 181 the actual service ordering phase. 183 One of the primary motivations of this document is to provide a 184 permanent reference to exemplify how service negotiation can be 185 automated. 187 This document is organized as follows: 189 o Section 3 defines the functional elements involved in CPNP 190 exchanges. 191 o Section 4 introduces several order processing models and precises 192 those that are targeted by CPNP. 194 o Section 5 enumerates a non-exhaustive list of use cases that could 195 benefit from CPNP. 196 o Section 5 discusses CPNP deployment models. 197 o Section 7 presents the CPNP negotiation model. 198 o Section 8 provides an overview of the protocol. 199 o Section 9 specifies the CPNP objects. 200 o Section 10 describes the CPNP message validation procedure. 201 o Section 11 specifies the behavior of the involved CPNP functional 202 elements. 203 o Section 12 discusses relevant operational guidelines. 204 o Section 13 discusses protocol security aspects. 206 Implementation details are out of scope. An example of required 207 modules and interfaces to implement this specification is sketched in 208 Section 4 of [AGAVE]. This specification builds on that effort. 210 2. Terminology 212 This document makes use of the following terms: 214 Customer: Is a business role which denotes an entity that is 215 involved in the definition and the possible negotiation of an 216 order, including a Connectivity Provisioning Agreement, with a 217 Provider. A connectivity provisioning order is captured in a 218 dedicated CPP template-based document, which may specify (among 219 other information): the sites to be connected, border nodes, 220 outsourced operations (e.g., routing, force via points). 222 The right to invoke the subscribed service may be delegated by the 223 Customer to third-party End Users, or brokering services. 225 A Customer can be a Service Provider, an application owner, an 226 enterprise, a user, etc. 228 Network Provider (or Provider): Owns and administers one or many 229 transport domain(s) (typically Autonomous System (AS)) composed of 230 (IP) switching and transmission resources (e.g., routing, 231 switching, forwarding, etc.). Network Providers are responsible 232 for delivering and operating connectivity services (e.g., offering 233 global or restricted reachability at specific rates). Offered 234 connectivity services may not necessarily be restricted to IP. 236 The policies to be enforced by the connectivity service delivery 237 components can be derived from the technology-specific clauses 238 that might be included in agreements with the Customers. If no 239 such clauses are included in the agreement, the mapping between 240 the connectivity requirements and the underlying technology- 241 specific policies to be enforced is deployment-specific. 243 Quotation Order: Denotes a request made by the Customer to the 244 Provider that includes a set of requirements. The Customer may 245 express its service-specific requirements by assigning (strictly 246 or loosely defined) values to the information items included in 247 the commonly understood template (e.g., CPP template) describing 248 the offered service. These requirements constitute the parameters 249 to be mutually agreed upon. 251 Offer: Refers to a response made by the Provider to a Customer's 252 quotation order that describes the ability of the Provider to 253 satisfy the order at the time of its receipt. Offers reflect the 254 capability of the Provider in accommodating received Customer 255 orders beyond monolithic 'yes/no' answers. 257 An offer may fully or partially meet the requirements of the 258 corresponding order. In the latter case, it may include 259 alternative suggestions which the Customer may take into account 260 by issuing a new order. 262 Agreement: Refers to an order placed by the Customer and accepted by 263 the Provider. It signals the successful conclusion of a 264 negotiation cycle. 266 Note that this document is not on the IETF standards track. However, 267 a conformant implementation is supposed to adhere to the specified 268 behavior for security and interoperability reasons. This document 269 uses BCP 14 to describe that necessary behavior. 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 273 "OPTIONAL" in this document are to be interpreted as described in BCP 274 14 [RFC2119][RFC8174] when, and only when, they appear in all 275 capitals, as shown here. 277 3. CPNP Functional Elements 279 The following functional elements are defined: 281 CPNP client (or client): Denotes a software instance that sends 282 CPNP requests and receives CPNP responses. The current operations 283 that can be performed by a CPNP client are listed below: 285 1. Create a quotation order (Section 9.2.1). 287 2. Cancel an ongoing quotation order under negotiation 288 (Section 9.2.7). 290 3. Accept an offer made by a server (Section 9.2.4). 292 4. Withdraw an agreement (Section 9.2.8). 294 5. Update an agreement (Section 9.2.9). 296 CPNP server (or server): Denotes a software instance that receives 297 CPNP requests and sends back CPNP responses accordingly. The CPNP 298 server is responsible for the following operations: 300 1. Process a quotation order (Section 9.2.2). 302 2. Make an offer (Section 9.2.3). 304 3. Cancel an ongoing quotation order (Section 11.2.3). 306 4. Process an order withdrawal (Section 11.2.3). 308 4. Order Processing Models 310 For preparing their service orders, Customers may need to be aware of 311 the offered services. Therefore, Providers should first proceed with 312 the announcement (or the exposure) of the services they can provide. 313 The service announcement process may take place at designated global 314 or Provider-specific service markets, or through explicit 315 interactions with the Providers. The details of this process are 316 outside the scope of this document. 318 With or without such service announcement/exposure mechanisms in 319 place, the following order processing models can be distinguished: 321 Frozen model: 323 The Customer cannot actually negotiate the parameters of the 324 service(s) offered by a Provider. After consulting the Provider's 325 service portfolio, the Customer selects the service offer he/she 326 wants to subscribe and places an order to the Provider. Order 327 handling is quite simple on the Provider side because the service 328 is not customized as per Customer's requirements, but rather pre- 329 designed to address a Customer base that shares the same 330 requirements (i.e., these customers share the same Customer 331 Provisioning Profile). This mode can be implemented using 332 existing tools such as [RFC8309]. 334 Negotiation-based model: 336 Unlike the frozen model, the Customer documents his/her 337 requirements in a request for a quotation, which is then sent to 338 one or several Providers. Solicited Providers check whether they 339 can address these requirements or not, and get back to the 340 Customer accordingly, possibly with an offer that may not exactly 341 match customer's requirements (e.g., a 100 Mbps connection cannot 342 be provisioned given the amount of available resources, but an 80 343 Mbps connection can be provided). A negotiation between the 344 Customer and the Provider(s) then follows until both parties reach 345 an agreement (or do not). 347 Both frozen and negotiation-based models require the existence of 348 appropriate service templates like a CPP template and their 349 instantiation for expressing specific offerings from Providers and 350 service requirements from Customers, respectively. CPNP can be used 351 in either model for automating the required Customer-Provider 352 interactions. Since the frozen model can be seen as a special case 353 of the negotiation-based model, not only 'yes/no' answers but also 354 counter-proposals may be offered by the Provider in response to 355 Customer orders. This document focuses on the negotiation-based 356 model. 358 Order processing management on the Network Provider's side usually 359 solicits features supported by the following functional blocks: 361 o Network Provisioning (including Order Activation, Network 362 Planning, etc.) 363 o Authentication, Authorization and Accounting (AAA) 364 o Network and service management (performance measurement and 365 assessment, fault detection, etc.) 366 o Sales-related functional blocks (e.g., billing, invoice 367 validation) 368 o Network Impact Analysis 370 CPNP does not assume any specific knowledge about these functional 371 blocks, drawing an explicit line between protocol operation and the 372 logic for handling connectivity provisioning requests. An order 373 processing logic is typically fed with the information manipulated by 374 the aforementioned functional blocks. For example, the resources 375 that can be allocated to accommodate Customer's requirements may 376 depend on network availability estimates as calculated by the 377 planning functions and related policies, as well as the number of 378 orders to be processed simultaneously over a given period of time. 380 This document does not elaborate on how Customers are identified and 381 subsequently managed by the Provider's Information System. 383 5. Sample Use Cases 385 A non-exhaustive list of CPNP use cases is provided below: 387 1. [RFC4176] introduces the Layer 3 VPN (L3VPN) Service Order 388 Management functional block which is responsible for managing 389 the requests initiated by the Customers and tracks the status of 390 the completion of the related operations. CPNP can be used 391 between the Customer and the Provider to negotiate L3VPN service 392 parameters. 394 A CPNP server could therefore be part of the L3VPN Service Order 395 Management functional block discussed in [RFC4176]. A L3VPN 396 Service YANG data Model (L3SM) is defined in [RFC8299]. Once an 397 agreement is reached, the service can be provisioned using, 398 e.g., the L3VPN Network YANG Model specified in 399 [I-D.ietf-opsawg-l3sm-l3nm]. 401 Likewise, A CPNP server could be part of the Layer 2 VPN (L2VPN) 402 Service Order Management functional block. A YANG data model 403 for L2VPN service delivery is defined in [RFC8466]. Once an 404 agreement is reached, the L2VPN service can be provisioned 405 using, e.g., the L2VPN Network YANG Model specified in 406 [I-D.barguil-opsawg-l2sm-l2nm]. 408 2. CPNP can be used between two adjacent domains to deliver IP 409 interconnection services (e.g., enable, update, disconnect). 410 For example, two Autonomous Systems (ASes) can be connected via 411 several interconnection points. CPNP can be used between these 412 ASes to upgrade existing links, request additional resources, 413 provision a new interconnection point, etc. 415 See, for example, the framework documented in [ETICS]. 417 3. An integrated Provider can use CPNP to rationalize connectivity 418 provisioning needs related to its service portfolio. A CPNP 419 server function is used by network operations teams. A CPNP 420 interface to trigger CPNP negotiation cycles is exposed to 421 service management teams. 423 4. Service Providers can use CPNP to initiate connectivity 424 provisioning requests towards a number of Network Providers so 425 as to optimize the cost of delivering their services. Although 426 multiple CPNP ordering cycles can be initiated by a Service 427 Provider towards multiple Network Providers, a subset of these 428 orders may actually be put into effect. 430 For example, a cloud Service Provider can use CPNP to request 431 more resources from Network Providers. 433 5. CPNP can also be used in the context of network slicing 434 ([I-D.geng-netslices-architecture]) to request network resources 435 together with a set of requirements that need to be satisfied by 436 the Provider. Such requirements are not restricted to basic IP 437 forwarding capabilities, but may also include a characterization 438 of a set of service functions that may be invoked. For the 439 network slicing case, the instances of a CPP template could be 440 derived from the network slice templates inputs as documented in 441 [I-D.contreras-teas-slice-nbi]. 443 6. CPNP can be used in Machine-to-Machine (M2M) environments to 444 dynamically subscribe to M2M services (e.g., access to data 445 retrieved by a set of sensors, extend sensor coverage, etc.). 447 Also, Internet of Things (IoT, [RFC6574]) domains may rely on 448 CPNP to enable dynamic access to data produced by involved 449 objects, according to their specific policies, to various 450 external stakeholders such as data analytics and business 451 intelligence companies. Direct CPNP-based interactions between 452 IoT domains and interested parties enable open access to diverse 453 sets of data across the Internet, e.g., from multiple types of 454 sensors, user groups and/or geographical areas. 456 7. CPNP can be used in the context of I2NSF ([RFC8329]) to capture 457 the customer-driven policies to be enforced by a set of Network 458 Security Functions. 460 8. A Provider offering cloud services can expose a CPNP interface 461 to allow Customers to dynamically negotiate typical data center 462 resources, such as additional storage, processing and networking 463 resources, enhanced security filters, etc. 465 Cloud computing providers typically structure their computation 466 service offerings by bundling CPU, RAM, and storage units as 467 quotas, instances, or flavors that can be consumed in an 468 ephemeral or temporal fashion during the lifetime of the 469 required function. A similar approach is followed by CPNP (see 470 for example, Section 9.2.11). 472 9. In the inter-cloud context (also called cloud of clouds or cloud 473 federation), CPNP can be used to reserve computing and 474 networking resources hosted by various cloud infrastructures. 476 10. CDN Providers can use CPNP to extend their footprint by 477 interconnecting their respective CDN infrastructures [RFC6770] 478 (see Figure 1). 480 ,--,--,--. ,--,--,--. 481 ,-' `-. ,-' `-. 482 (CDN Provider 'A')=====(CDN Provider 'B') 483 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 484 `--'--'--' `--'--'--' 486 Figure 1: CDN Interconnection 488 11. Mapping Service Providers (MSPs, [RFC7215]) can use CPNP to 489 enrich their mapping database by interconnecting their mapping 490 system (see Figure 2). This interconnection allows to relax the 491 constraints on PxTR (Proxy Ingress/Egress Tunnel Router) in 492 favour of native LISP (Locator/ID Separation Protocol) 493 forwarding [RFC6830]. Also, it prevents the fragmentation of 494 the LISP mapping database. A framework is described in 495 [I-D.boucadair-lisp-idr-ms-discovery]. 497 ,--,--,--. ,--,--,--. 498 ,-' `-. ,-' `-. 499 (Mapping System 'A')===(Mapping System 'B') 500 `-. ,-' `-. ,-' 501 `--'--'--' `--'--'--' 503 Figure 2: LISP Mapping System Interconnect 505 12. CPNP may also be used between SDN (Software-Defined Networking) 506 controllers in contexts where Cooperating Layered Architecture 507 for Software-Defined Networking (CLAS) is enabled [RFC8597]. 509 6. CPNP Deployment Models 511 Several CPNP deployment models can be envisaged. Two examples are 512 listed below: 514 o The Customer deploys a CPNP client while one or several CPNP 515 servers are deployed by the Provider. A CPNP client can discover 516 its CPNP servers using a variety of means (static, dynamic, etc.). 517 o The Customer does not enable any CPNP client. The Provider 518 maintains a Customer Order Management portal. The Customer can 519 initiate connectivity provisioning quotation orders via the 520 portal; appropriate CPNP messages are then generated and sent to 521 the relevant CPNP server. In this model, both the CPNP client and 522 CPNP server are under the responsibility of the same 523 administrative entity (i.e., Network Provider). 525 Once the negotiation of connectivity provisioning parameters is 526 successfully concluded, that is, an order has been placed by the 527 Customer, the actual network provisioning operations are initiated. 528 The specification of related dynamic resource allocation and policy 529 enforcement schemes, as well as how CPNP servers interact with the 530 network provisioning functional blocks at Provider sides are out of 531 the scope of this document. 533 This document does not make any assumption about the CPNP deployment 534 model either. 536 7. CPNP Negotiation Model 538 CPNP runs between a Customer and a Provider carrying service orders 539 from the Customer and corresponding responses from the Provider to 540 the end of reaching a service provisioning agreement. As the 541 services offered by the Provider are well-described, by means of the 542 CPP template for connectivity matters, the negotiation process is 543 essentially a value-settlement process, where an agreement is pursued 544 on the values of the commonly understood information items (service 545 parameters) included in the service description template 546 (Section 9.1.9). 548 The protocol is transparent to the content that it carries and to the 549 negotiation logic invoked at Customer and Provider sides, and which 550 manipulates the content (i.e., the information carried in CPNP 551 messages to proceed with the negotiation). 553 The protocol aims at facilitating the execution of the negotiation 554 logic by providing the required generic communication primitives. 556 Since negotiations are initiated and primarily driven by the 557 Customer's negotiation logic, it is reasonable to assume that the 558 Customer is the only party that can call for an agreement. An 559 implicit approach is adopted for not overloading the protocol with 560 additional messages. In particular, the acceptance of an offer made 561 by the Provider signals a call for agreement from the Customer. Note 562 that it is almost certain the Provider to accept this call since it 563 refers to an offer that itself made. Of course, at any point the 564 Provider or the Customer may quit the negotiations, each on its own 565 grounds. 567 Based on the above, CPNP adopts a Quotation Order/Offer/Answer model, 568 which proceeds through the following basic steps (Figure 3): 570 1. The CPNP client specifies its service requirements via a 571 Provision Quotation Order (PQO). The order may include strictly 572 or loosely defined values in the clauses describing service 573 provisioning characteristics. 575 2. The CPNP server declines the PQO, or makes an offer to address 576 the requirements of the PQO, or suggests a counter-proposal that 577 partially addresses the requirements of the PQO in case specific 578 requirements cannot be accommodated. 580 3. The CPNP client either accepts or declines the offer. Accepting 581 the offer by the CPNP client implies a call for agreement; thus 582 the agreement between both parties and the conclusion of the 583 negotiation. 585 +------+ +------+ 586 |Client| |Server| 587 +------+ +------+ 588 |=====Requested Service=====>| 589 |<=====Offered Service=======| 590 |======Agreed Service=======>| 592 Figure 3: Simplified Service Negotiation 594 Multiple instances of CPNP may run at Customer's or Provider's 595 domains. A CPNP client may be engaged in multiple, simultaneous 596 negotiations with the same or different CPNP servers (parallel 597 negotiations, see Section 8.10) and a CPNP server may need to 598 negotiate with other Provider(s) as part of negotiations that are 599 ongoing with a CPNP client (cascaded negotiations, see Section 8.8). 601 CPNP relies on various timers to run its operations. Two types of 602 timers are defined: those that are specific to CPNP message 603 transmission and those that are specific to the negotiation logic. 604 The latter are used to guide the negotiation logic at both CPNP 605 client and CPNP server sides, particularly in cases where the CPNP 606 client is involved in parallel negotiations with several CPNP servers 607 or in cases where the CPNP server is in turn involved in negotiations 608 with other Providers for processing a given customer-originated 609 quotation order. CPNP allows a CPNP server to request an extra time 610 to proceed with the negotiation. This request may be accepted or 611 rejected by the CPNP client. 613 Providers may need to publish available services to the Customers 614 (see Section 4). CPNP may optionally support this functionality. 615 Dedicated templates can be defined for the purpose of service 616 announcement, which will be used by the CPNP clients to initiate 617 their CPNP negotiation cycles. 619 For the sake of simplicity, a single Offer/Answer stage is assumed 620 within one CPNP negotiation cycle. Nevertheless, as already stated, 621 multiple CPNP negotiation cycles can be undertaken by a CPNP client 622 (see Figure 4). 624 The model is flexible enough to accommodate changing conditions 625 during the lifetime of a service (e.g., introduction of an additional 626 VPN site). 628 +------+ +------+ +------+ +------+ 629 |Client| |Server| |Client| |Server| 630 +------+ +------+ +------+ +------+ 631 |=====Quotation Order=====>| |=====Quotation Order=====>| 632 |<==========Offer==========| |<==========Offer==========| 633 |===========Accept========>| |==========Decline========>| 635 1-Step Successful Negotiation 1-Step Failed Negotiation 636 Cycle Cycle 638 +------+ +------+ +------+ +------+ 639 |Client| |Server| |Client| |Server| 640 +------+ +------+ +------+ +------+ 641 |===Quotation Order(a)====>| |===Quotation Order(i)====>| 642 |<==========Offer==========| |<==========Offer==========| 643 |==========Decline========>| |==========Decline========>| 644 |===Quotation Order(b)====>| |===Quotation Order(j)====>| 645 |<==========Offer==========| |<==========Offer==========| 646 |===========Accept========>| |==========Decline========>| 647 |===Quotation Order(k)====>| 648 |<==========Offer==========| 649 |==========Decline========>| 650 |===Quotation Order(l)====>| 651 |<==Fail to make an offer==| 653 N-Step Negotiation Cycle: N-Step Negotiation Cycle: 654 Successful Negotiation Failed Negotiation 656 Figure 4: Overall Negotiation Process 658 Means used by a CPNP client to retrieve a list of active/agreed 659 offers are not defined in this document. 661 An order can be implicitly or explicitly activated. Section 3.1 of 662 [RFC7297] specifies a dedicated clause called activation Means. Such 663 clause indicates the required action(s) to be undertaken to activate 664 access to the (IP connectivity) service. This document defines a 665 dedicated CPNP message that can be used for explicit activation 666 (Section 9.2.11)). 668 8. Protocol Overview 670 8.1. Client/Server Communication 672 CPNP is a client/server protocol that can run over any transport 673 protocol. Yet, UDP is the default transport mode secured with 674 Datagram Transport Layer Security (DTLS) [RFC6347]. No permanent 675 CPNP transport session needs to be maintained between the client and 676 the server. 678 The CPNP client can be configured with the CPNP server(s). 679 Typically, an IP address together with a port number are configured 680 to the CPNP client, based upon manual or dynamic configuration means 681 (e.g., DHCP). Alternatively, a Provider may advertise the port 682 number (CPNP_PORT) it uses to bind the CPNP service using SRV 683 [RFC2782]. 685 The client sends CPNP requests using CPNP_PORT as the destination 686 port number. The same port number used as the source port number of 687 a CPNP request sent to a CPNP server is used by the server to reply 688 to that request. 690 CPNP is independent of the IP address family. 692 CPNP retransmission is discussed in Section 11.4 for unreliable 693 transports. 695 Considerations related to mutual authentication are discussed in 696 Section 13. 698 8.2. Policy Configuration on the CPNP Server 700 As an input to its decision-making process, the CPNP server may be 701 connected to various external modules such as: Customer Profiles, 702 Network Topology, Network Resource Management, Order Repositories, 703 AAA, and Network Provisioning Manager (an example is shown in 704 Figure 5). 706 These external modules provide inputs to the CPNP server, so that it 707 can: 709 o Check whether a customer is entitled to initiate a provisioning 710 quotation request. 712 o Check whether a customer is entitled to cancel an ongoing order. 714 o Check whether administrative data (e.g., billing-related 715 information) have been verified before the processing of the 716 request starts. 718 o Check whether network capacity is available or additional capacity 719 is required. 721 o Receive guidelines from network design and sales blocks (e.g., 722 pricing, network usage levels, thresholds associated with the 723 number of CPP templates that can be processed over a given period 724 of time as a function of the nature of the service to be 725 delivered, etc.). 727 o Transfer completed orders to network provisioning blocks (referred 728 to as "Network Provisioning Manager" in Figure 5). For example, 729 the outcome of CPNP may be passed to modules such as Application- 730 Based Network Operations (ABNO) [RFC7491] or network controllers. 731 These controllers will use protocols such as NETCONF [RFC6241] to 732 interact with the appropriate network nodes and functions for the 733 sake of proper service activation and delivery. 735 The above list of CPNP server operations is not exhaustive. 737 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738 .Business & Administrative Management . 739 .+------------------------++---------------------------+. 740 .| Business Guidelines || Billing & Charging |. 741 .+-----------+------------++-----------+---------------+. 742 . | | . 743 . +-------------------+ | . 744 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 745 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 746 .Order Handling Management | | . 747 . +-------------------+ +-------+-----+--------------+ . 748 . |Network Topology DB+--+ CPNP Server | . 749 . +-------------------+ +-+---+---+---+---+-----+----+ . 750 . | | | | | | . 751 . +------------------------+-+ | | | | | . 752 . | Network Dimensioning | | | | | | . 753 . | & Planning | | | | | | . 754 . +--------------------------+ | | | | | . 755 . +----------------------------+-+ | | | +---+----+ . 756 . | | | | | | AAA | . 757 . | Network +------------+ | | | +--------+ . 758 . | Resource | +------------+-+ | +-+----------+ . 759 . | Management | | Customer | | | Orders | . 760 . | | | Profiles | | | Repository | . 761 . +-----------------+ +--------------+ | +------------+ . 762 . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . 763 +--------------------------------------+----------------+ 764 | Network Provisioning Manager | 765 +-------------------------------------------------------+ 767 Figure 5: Order Handling Management Functional Block (Focus on 768 Internal Interfaces) 770 The following order handling modes can also be configured on the 771 server: 773 1. Fully automated mode: This mode does not require any action from 774 the administrator when receiving a request for a service. The 775 server can execute its decision-making process related to the 776 orders received and generate corresponding offers. 778 2. Administrative validation checking: Some or all of the server's 779 operations are subject to administrative validation procedures. 780 This mode requires an action from the administrator for every 781 request received. To that aim, the CPNP methods which can be 782 automatically handled by the server (or are subject to one or 783 several validation administrative checks) can be configured on 784 the server. 786 8.3. CPNP Session Entries 788 A CPNP session entry is denoted by a tuplet defined as follows: 790 o Transport session (typically, IP address of the CPNP client, 791 client's port number, IP address of the CPNP server, and CPNP 792 server's port number). 794 o Incremented Sequence Number (Section 11.3) 796 o Customer Agreement Identifier: This is a unique identifier 797 assigned to the order under negotiation by the CPNP client 798 (Section 9.1.1). This identifier is also used to identify the 799 agreement that will result from a successful negotiation. 801 o Provider Agreement Identifier: This is a unique identifier 802 assigned to the order under negotiation by the CPNP server 803 (Section 9.1.2). This identifier is also used to identify the 804 agreement that will result from a successful negotiation. 806 o Transaction-ID (Section 8.4). 808 8.4. CPNP Transaction 810 A CPNP transaction occurs between a client and a server for 811 completing, modifying, withdrawing a service agreement, and comprises 812 all CPNP messages exchanged between the client and the server, from 813 the first request sent by the client to the final response sent by 814 the server. A CPNP transaction is bound to a CPNP session 815 (Section 8.3). 817 Because multiple CPNP transactions can be maintained by the CPNP 818 client, the client must assign an identifier to uniquely identify a 819 given transaction. This identifier is denoted as Transaction-ID. 821 The Transaction-ID must be randomly assigned by the CPNP client, 822 according to the best current practice for generating random numbers 823 [RFC4086] that cannot be guessed easily. Transaction-ID is used for 824 validating CPNP responses received by the client. 826 In the context of a transaction, the client needs to randomly select 827 a sequence number and assign it to the first CPNP message to send. 828 This number is then incremented for each request message that is 829 subsequently sent within the ongoing CPNP transaction (see 830 Section 11.3). 832 8.5. CPNP Timers 834 CPNP adopts a simple retransmission procedure which relies on a 835 retransmission timer denoted as RETRANS_TIMER and a maximum retry 836 threshold. The use of RETRANS_TIMER and a maximum retry threshold 837 are described in Section 11. 839 The response timer (EXPECTED_RESPONSE_TIME) is set by the client to 840 denote the time, in seconds, the client will wait for receiving a 841 response from the server to a provisioning quotation order request 842 (see Section 9.1.6). If the timer expires, the respective quotation 843 order is cancelled by the client and a CANCEL message is generated 844 accordingly. 846 The expected offer timer (EXPECTED_OFFER_TIME) is set by the server 847 to indicate the time by when the CPNP server is expecting to make an 848 offer to the CPNP client (see Section 9.1.7). If no offer is 849 received by then, the CPNP client will consider the order as 850 rejected. 852 An offer expiration timer (VALIDITY_OFFER_TIME) is set by the server 853 to represent the time, in minutes, after which an offer made by the 854 server becomes invalid (see Section 9.1.8). 856 8.6. CPNP Operations 858 CPNP operations are listed below. They may be augmented, depending 859 on the nature of some transactions or because of security 860 considerations that may necessitate a distinct CPNP client/server 861 authentication phase before negotiation begins. 863 o QUOTATION (Section 9.2.1): 865 This operation is used by the client to initiate a provisioning 866 quotation order. Upon receipt of a QUOTATION request, the server 867 may respond with a PROCESSING, OFFER or a FAIL message. A 868 QUOTATION-initiated transaction can be terminated by a FAIL 869 message. 871 o PROCESSING (Section 9.2.2): 873 This operation is used to inform the remote party that the message 874 (the order quotation or the offer) sent was received and it is 875 processed. This message can also be issued by the server to 876 request more time, in which case the client may reply with an ACK 877 or FAIL message depending on whether extra time can or cannot be 878 granted. 880 o OFFER (Section 9.2.3): 882 This operation is used by the server to inform the client about an 883 offer that can best accommodate the requirements indicated in the 884 previously received QUOTATION message. 886 o ACCEPT (Section 9.2.4): 888 This operation is used by the client to confirm the acceptance of 889 an offer made by the server. This message implies a call for 890 agreement. An agreement is reached when an ACK is subsequently 891 received from the server, which is likely to happen if the message 892 is sent before the offer validity time expires; the server is 893 unlikely to reject an offer that it has already made. 895 o DECLINE (Section 9.2.5): 897 This operation is used by the client to reject an offer made by 898 the server. The ongoing transaction may not be terminated 899 immediately, e.g., the server/client may issue another offer/ 900 order. 902 o ACK (Section 9.2.6): 904 This operation is used by the server to acknowledge the receipt of 905 an ACCEPT or WITHDRAW message, or by the client to confirm the 906 time extension requested (conveyed in a PROCESSING message) by the 907 server for processing the last received quotation order. 909 o CANCEL (Section 9.2.7): 911 This operation is used by the client to cancel (quit) the ongoing 912 transaction. 914 o WITHDRAW (Section 9.2.8): 916 This operation is used by the client to withdraw an agreement. 918 o UPDATE (Section 9.2.9): 920 This operation is used by the client to update an existing 921 agreement. For example, this method can be invoked to add a new 922 VPN site. This method will trigger a new negotiation cycle. 924 o FAIL (Section 9.2.10): 926 This operation is used by the server to indicate that it cannot 927 accommodate the requirements documented in the PQO conveyed in the 928 QUOTATION message or to inform the client about an error 929 encountered when processing the received message. In either case, 930 the message implies that the server is unable to make offers and 931 as a consequence, it terminates the ongoing transaction. 933 This message is also used by the client to reject a time extension 934 request received from the server (in a PROCESSING message). The 935 message includes a status code for providing explanatory 936 information. 938 The above CPNP primitives are service-independent. CPNP messages may 939 transparently carry service-specific objects which are handled by the 940 negotiation logic at either side. 942 The document specifies the service objects that are required for 943 connectivity provisioning negotiation (see Section 8.7) purposes. 944 Additional service-specific objects to be carried in CPNP messages 945 can be defined in the future for accommodating alternative deployment 946 schemes or other service provisioning needs. 948 8.7. Connectivity Provisioning Documents 950 CPNP makes use of several flavors of Connectivity Provisioning 951 Documents (CPD). These documents follow the same CPP template 952 described in [RFC7297]. 954 Requested Connectivity Provisioning Document (Requested CPD): 955 Refers to the CPD included by a CPNP client in a QUOTATION 956 request. 958 Offered Connectivity Provisioning Document (Offered CPD): This 959 document is included by a CPNP server in an OFFER message. Its 960 information reflects the proposal of the server to accommodate all 961 or a subset of the clauses depicted in a Requested CPD. A 962 validity time is associated with the offer made. 964 Agreed Connectivity Provisioning Document (Agreed CPD): If the 965 client accepts an offer made by the server, the Offered CPD is 966 included in an ACCEPT message. This CPD is also included in an 967 ACK message. Thus, a 3-way handshake procedure is followed for 968 successfully completing the negotiation. 970 Figure 6 shows a typical CPNP negotiation cycle and the use of the 971 different types of Connectivity Provisioning Documents. 973 +------+ +------+ 974 |Client| |Server| 975 +------+ +------+ 976 |======QUOTATION (Requested CPD)=====>| 977 |<============PROCESSING==============| 978 |<========OFFER (Offered CPD)=========| 979 |=============PROCESSING=============>| 980 |=========ACCEPT (Agreed CPD)========>| 981 |<=========ACK (Agreed CPD)===========| 982 | | 984 Figure 6: Connectivity Provisioning Documents 986 A provisioning document can include parameters with fixed values, 987 loosely-defined values, or any combination thereof. A provisioning 988 document is said to be concrete if all clauses have fixed values. 990 A typical evolution of a negotiation cycle would start with a 991 quotation order with loosely-defined parameters, and then, as offers 992 are made, it would conclude with concrete provisioning document for 993 calling for the agreement. 995 8.8. Child Provisioning Quotation Orders 997 If the server detects that network resources from another Network 998 Provider need to be allocated in order to accommodate the 999 requirements described in a PQO (e.g., in the context of an inter- 1000 domain VPN service, additional PE router resources need to be 1001 allocated), the server may generate child PQOs to request the 1002 appropriate network provisioning operations (see Figure 7). In such 1003 situation, the server behaves also as a CPNP client. The server 1004 associates the parent order with its child PQOs. How this is 1005 achieved is implementation-specific (e.g., this can be typically 1006 achieved by locally adding the reference of the child PQO to the 1007 parent order). 1009 +------+ +--------+ +--------+ 1010 |Client| |Server A| |Server B| 1011 +------+ +--------+ +--------+ 1012 | | | 1013 |=====QUOTATION=====>| | 1014 |<====PROCESSING=====| | 1015 | |=====QUOTATION=====>| 1016 | |<====PROCESSING=====| 1017 | |<=======OFFER=======| 1018 | |=====PROCESSING====>| 1019 | |=======ACCEPT======>| 1020 | |<=======ACK=========| 1021 |<=======OFFER=======| | 1022 |=====PROCESSING====>| | 1023 |=======ACCEPT======>| | 1024 |<=======ACK=========| | 1025 | | | 1027 Figure 7: Example of Child Orders 1029 Note that recursion MUST NOT be activated by the server for an order 1030 if the client includes a negotiation option to restrict the 1031 negotiation scope to the resources of the server's domain 1032 (Section 9.1.10.3). 1034 If recursion is not explicitly disabled, the server may notify the 1035 client when appropriate (Section 9.2.2). Such notification may also 1036 depend on the nature of the service but also regulatory 1037 considerations. 1039 8.9. Multi-Segment Service 1041 A composite service (e.g., connectivity) requested by a customer 1042 could imply multi-segment services (e.g., multi-segment connectivity 1043 spanning an end-to-end scope), in the sense that one single CPNP 1044 request is decomposed into N connectivity requests at the provider's 1045 side (thereby leading to child orders). The Provider is in charge of 1046 handling the complexity of splitting the generic provisioning order 1047 in a multi-segment context. Such complexity is local to the 1048 Provider. 1050 8.10. Negotiating with Multiple CPNP Servers 1052 A CPNP client may undertake multiple negotiations in parallel with 1053 several servers for various reasons, such as cost optimization and 1054 fail-safety. These multiple negotiations may lead to one or many 1055 agreements. 1057 The salient point underlining the parallel negotiation scenarios is 1058 that, although the negotiation protocol is strictly between two 1059 parties, this may not be the case of the negotiation logic. The CPNP 1060 client negotiation logic may need to collectively drive parallel 1061 negotiations, as the negotiation with one server may affect the 1062 negotiation with other servers; for example, it may need to use the 1063 responses from all servers as an input for determining the messages 1064 (and their content) to subsequently send within the course of each 1065 individual negotiation. Timing is therefore an important aspect at 1066 the client's side. The CPNP client needs to have the ability to 1067 synchronize the receipt of the responses from the servers. CPNP 1068 takes into account this requirement by allowing clients to specify in 1069 the QUOTATION message the time by which the server needs to respond 1070 (see Section 9.1.6). 1072 8.11. State Management 1074 Both the client and the server maintain repositories to store ongoing 1075 orders. How these repositories are maintained is deployment- 1076 specific. It is out of scope of this document to elaborate on such 1077 considerations. Timestamps are also logged to track state change. 1078 Tracking may be needed for various reasons, including regulatory or 1079 billing ones. 1081 In order to accommodate failures that may lead to the reboot of the 1082 client or the server, the use of permanent storage is recommended, 1083 thereby facilitating state recovery. 1085 8.11.1. On the Client Side 1087 This is the list of the typical states that can be associated with a 1088 given order on the client's side: 1090 o Created: when the order has been created. It is not handled by 1091 the client until the administrator allows to process it. 1093 o AwaitingProcessing: when the administrator approved the processing 1094 of a created order and the order has not been handled yet. 1096 o PQOSent: when the order has been sent to the server. 1098 o ServerProcessing: when the server has confirmed the receipt of the 1099 order. 1101 o OfferReceived: when an offer has been received from the server. 1103 o OfferProcessing: when a received offer is currently processed by 1104 the client. 1106 o AcceptSent: when the client confirmed the offer to the server. 1108 o Completed: when the offer is acknowledged by the server. 1110 o Cancelled: when the order has failed or cancelled. 1112 Sub-states may be defined (e.g., to track failed vs. cancelled 1113 orders) but those are not shown in Figure 8. 1115 +------------------+ 1116 | Created |-----------------+ 1117 +------------------+ | 1118 | | 1119 v | 1120 +------------------+ | 1121 |AwaitingProcessing|----------------+| 1122 +------------------+ || 1123 | || 1124 QUOTATION/UPDATE || 1125 v || 1126 +------------------+ || 1127 | PQOSent |---CANCEL------+|| 1128 +------------------+ vvv 1129 | +-----+ 1130 PROCESSING | | 1131 v | | 1132 +------------------+ CANCEL | C | 1133 | ServerProcessing |------------>| A | 1134 +------------------+ FAIL | N | 1135 | | C | 1136 | | E | 1137 OFFER | L | 1138 | | L | 1139 v | E | 1140 +------------------+ | D | 1141 | OfferReceived |---CANCEL--->| | 1142 +------------------+ | | 1143 | PROCESSING +-----+ 1144 v ^^^ 1145 +------------------+ ||| 1146 | OfferProcessing |---DECLINE-----+|| 1147 +------------------+ || 1148 | ACCEPT || 1149 v || 1150 +------------------+ || 1151 | AcceptSent |---CANCEL-------+| 1152 +------------------+ | 1153 | ACK | 1154 v | 1155 +------------------+ | 1156 | Completed |---WITHDRAW------+ 1157 +------------------+ 1159 Figure 8: Example of a CPNP Finite State Machine (Client Side) 1161 8.11.2. On the Server Side 1163 The following lists the states which can be associated with a given 1164 order and a corresponding offer on the server's side: 1166 o PQOReceived: when the order has been received from the client. 1168 o AwaitingProcessing: when the order is being processed by the 1169 server. An action from the server administrator may be needed. 1171 o OfferProposed: when the request has been successfully handled and 1172 an offer has been sent to the client. 1174 o ProcessingReceived: when the server received a PROCESSING for an 1175 offer sent to the client. 1177 o AcceptReceived: when the server received a confirmation for the 1178 offer from the client. 1180 o Completed: when the server acknowledged the offer (accepted by 1181 client) to the client. Transitioning to this state assumes that 1182 the ACK was received by the client (this can be detected by the 1183 server if it receives retransmitted ACCEPT from the client). 1185 o Cancelled: when the order cannot be accommodated or it has been 1186 cancelled by the client. Associate resources must be released in 1187 the latter case, if previously reserved. 1189 o ChildCreated: when a child order has been created in cases where 1190 resources from another Network Provider are needed. 1192 o ChildPQOSent: when a child order has been sent to the remote 1193 server. 1195 o ChildServerProcessing: when a child order is currently processed 1196 by the remote server. 1198 o ChildOfferReceived: when an offer has been received to a child 1199 order from the remote server. 1201 o ChildOfferProcessing: when a received offer to a child order is 1202 currently processed. 1204 o ChildAcceptSent: when the child offer (offer received from the 1205 remote server in response to a child order) is confirmed to the 1206 remote server. 1208 o ChildCompleted: when an accepted child offer is acknowledged by 1209 the remote server. 1211 +------------------+ +------------------+ 1212 |AwaitingProcessing|<----------| ChildCreated | 1213 +------------------+ +------------------+ 1214 | | ^ 1215 v | | 1216 +------------------+ | | 1217 | ChildPQOSent |----------------+| Q 1218 +------------------+ || U 1219 | || O 1220 QUOTATION/UPDATE || T 1221 v || A +--------------------+ 1222 +---------------------+ CANCEL || T | PQOReceived | 1223 |ChildServerProcessing|------------+|| I +--------------------+ 1224 +---------------------+ FAIL vvv O | | 1225 | +-----+ N CANCEL | 1226 PROCESSING | |<---|-------+ PROCESSING 1227 v | | | v 1228 +------------------+ | | +------------------------+ 1229 |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | 1230 +------------------+ | A | +------------------------+ 1231 | | N | ^ | OFFER 1232 OFFER | C | | +------------------+ 1233 | | E | ::= 1392 ... 1393 ::= 1394 ... 1395 ::= 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 ::= ... 1410 ::= 1411 1412 1414 Figure 10: The RBNF format of the Connectivity Provisioning Document 1415 (CPD) 1417 9.1.10. CPNP Information Elements 1419 An Information Element (IE) is an optional object which can be 1420 included in a CPNP message. 1422 9.1.10.1. Customer Description 1424 The client may include administrative information such as: 1426 o Name 1427 o Contact Information 1429 The format of this Information Element is as follows: 1431 ::= [] [] 1432 ::= [] [] 1433 [ ...] 1435 9.1.10.2. Provider Description 1437 The server may include administrative information in an offer such 1438 as: 1440 o Name 1441 o AS Number ([RFC6793]) 1442 o Contact Information 1444 The format of this Information Element is as follows: 1446 ::= [][][] 1448 9.1.10.3. Negotiation Options 1450 The client may include some negotiation options such as: 1452 o Setup purpose: A client may request the setup of a service (e.g., 1453 connectivity) only for testing purposes during a limited period. 1454 The order can be extended to become permanent if the client was 1455 satisfied during the test period. This operation is achieved 1456 using the UPDATE method. 1457 o Activation type: A client may request a permanent or scheduled 1458 activation type. If no activation type clause is included during 1459 the negotiation, this means that the order will be immediately 1460 activated right after the negotiation ends. 1462 The format of this Information Element is as follows: 1464 ::= [] 1466 9.2. Operation Messages 1468 This section specifies the RBNF format of CPNP operation messages. 1469 The following operation codes are used: 1471 1: QUOTATION (Section 9.2.1) 1472 2: PROCESSING (Section 9.2.2) 1473 3: OFFER (Section 9.2.3) 1474 4: ACCEPT (Section 9.2.4) 1475 5: DECLINE (Section 9.2.5) 1476 6: ACK (Section 9.2.6) 1477 7: CANCEL (Section 9.2.7) 1478 8: WITHDRAW (Section 9.2.8) 1479 9: UPDATE (Section 9.2.9) 1480 10: FAIL (Section 9.2.10) 1481 11: ACTIVATE (Section 9.2.11) 1482 These codes are used to unambiguously identify a CPNP operation; the 1483 operation code is conveyed in the "METHOD_CODE" attribute mentioned 1484 in the following sub-sections. 1486 In the following, "VERSION" refers to the CPNP version number. This 1487 attribute MUST be set to 1. 1489 9.2.1. QUOTATION 1491 The format of the QUOTATION message is shown below: 1493 ::= 1494 1495 1496 1497 1498 [] 1499 1500 [...] 1502 A QUOTATION message MUST include an order identifier which is 1503 generated by the client (CUSTOMER_AGREEMENT_IDENTIFIER). Because 1504 several orders can be issued to several servers, the QUOTATION 1505 message MUST also include a Transaction-ID. 1507 The message MAY include an EXPECTED_RESPONSE_TIME which indicates by 1508 when the client is expecting to receive an offer from the server. 1509 QUOTATION message MUST also include a requested service description 1510 (that is, requested connectivity provisioning document for 1511 connectivity services). 1513 The message MAY include ACTIVATION_TYPE to request a permanent or 1514 scheduled activation type (e.g., using the ACTIVATE method defined in 1515 Section 9.2.11). If no such clause is included, the default mode is 1516 to assume that the order will be active once the agreed activation 1517 means are successfully invoked (e.g., Section 3.11 of [RFC7297]). 1519 When the client sends the QUOTATION message to the server, the state 1520 of the order changes to "PQOSent" at the client side. 1522 9.2.2. PROCESSING 1524 The format of the PROCESSING message is shown below: 1526 ::= 1527 1528 1529 1530 1531 1532 [] 1533 [] 1535 Upon receipt of a QUOTATION message, the server proceeds with parsing 1536 rules (see Section 10). If no error is encountered, the server 1537 generates a PROCESSING response to the client to indicate the PQO has 1538 been received and it is being processed. The server MUST generate an 1539 order identifier which identifies the order in its local order 1540 repository. The server MUST copy the content of 1541 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed 1542 in the QUOTATION message. The server MAY include an 1543 EXPECTED_OFFER_TIME by when it expects to make an offer to the 1544 client. 1546 Upon receipt of a PROCESSING message, the client verifies whether it 1547 has issued a PQO to that server and which contains the 1548 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is 1549 found, the PROCESSING message MUST be silently ignored. If a PQO is 1550 found, the client may check whether it accepts the 1551 EXPECTED_OFFER_TIME and then, it changes to state of the order to 1552 "ServerProcessing". 1554 If more time is required by the server to process the quotation 1555 order, it MAY send a PROCESSING message that includes a new 1556 EXPECTED_OFFER_TIME. The client can answer with an ACK message if 1557 more time is granted (Figure 11) or with a FAIL message if the time 1558 extension request is rejected (Figure 12). 1560 The server may provide more details in the PROCESSING_SUBCODE 1561 attribute about the reason for requesting more time to process the 1562 request. The following codes are defined: 1564 (1) Upgrade of local resources 1566 (2) Request external resources 1567 +------+ +------+ 1568 |Client| |Server| 1569 +------+ +------+ 1570 |=======QUOTATION(Requested CPD)=====>| 1571 |<========PROCESSING(time1)===========| 1572 ... 1573 |<========PROCESSING(MoreTime)========| 1574 |============ACK(TimeGranted)========>| 1575 ... 1576 |<=========OFFER(Offered CPD)=========| 1577 |=============PROCESSING=============>| 1578 |==========ACCEPT(Agreed CPD)========>| 1579 |<==========ACK(Agreed CPD)===========| 1580 | | 1582 Figure 11: Request More Negotiation Time: Granted 1584 +------+ +------+ 1585 |Client| |Server| 1586 +------+ +------+ 1587 |=======QUOTATION(Requested CPD)=====>| 1588 |<========PROCESSING(time1)===========| 1589 ... 1590 |<========PROCESSING(MoreTime)========| 1591 |=====FAIL(More Time Rejected)=======>| 1593 Figure 12: Request More Negotiation Time: Rejected 1595 9.2.3. OFFER 1597 The format of the OFFER message is shown below: 1599 ::= 1600 1601 1602 1603 1604 1605 1606 1607 1608 [...] 1610 The server answers with an OFFER message to a QUOTATION request 1611 received from the client. The offer will be considered as rejected 1612 by the client if no confirmation (ACCEPT message sent by the client) 1613 is received by the server before the expiration of the validity time. 1615 The server MAY include ACTIVATION_TYPE to indicate whether the offer 1616 is about a permanent or scheduled activation type. The message MAY 1617 include ACTIVATION_SCHEDULE to indicate when the order is to be 1618 activated. If no such clause is included, the default mode is to 1619 assume that the order will be active once the agreed activation means 1620 are successfully invoked (e.g., Section 3.11 of [RFC7297] or 1621 Section 9.2.11). 1623 9.2.4. ACCEPT 1625 The format of the ACCEPT message is shown below: 1627 ::= 1628 1629 1630 1631 1632 1633 1634 1635 [...] 1637 This message is used by a client to confirm the acceptance of an 1638 offer received from a server. The fields of this message MUST be 1639 copied from the received OFFER message. This message SHOULD NOT be 1640 sent after the validity time of the offer expires, as indicated by 1641 the server (Section 9.2.3). 1643 9.2.5. DECLINE 1645 The format of the DECLINE message is shown below: 1647 ::= 1648 1649 1650 1651 1652 1653 1654 [...] 1656 The client may issue a DECLINE message to reject an offer. 1657 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, 1658 TRANSACTION_ID, and NONCE are used by the server as keys to find the 1659 corresponding order. If an order matches, the server changes the 1660 state of this order to "Cancelled" and then returns an ACK with a 1661 copy of the requested CPD to the requesting client. 1663 A DECLINE message MAY include an information to indicate the reason 1664 for declining an offer. The following codes are defined: 1666 1 (Unacceptable gap between the request and the offer) 1668 2 (Conflict with another offer from another server) 1670 3 (Activation type mismatch) 1672 If no order is found, the server returns a FAIL message to the 1673 requesting client. In order to prevent DDoS (Distributed Denial of 1674 Service) attacks, the server SHOULD restrict the number of FAIL 1675 messages sent to a requesting client. It MAY also rate-limit FAIL 1676 messages. 1678 A flow example is shown in Figure 13. 1680 +------+ +------+ 1681 |Client| |Server| 1682 +------+ +------+ 1683 |=======QUOTATION(Requested CPD)=====>| 1684 |<============PROCESSING==============| 1685 |<=========OFFER(Offered CPD)=========| 1686 |=============PROCESSING=============>| 1687 |===============DECLINE==============>| 1688 |<================ACK=================| 1689 | | 1691 Figure 13: DECLINE Flow Example 1693 9.2.6. ACK 1695 The format of the ACK message is shown below: 1697 ::= 1698 1699 1700 1701 1702 1703 [] 1704 [] 1705 [...] 1707 This message is issued by the server to close a CPNP transaction or 1708 by a client to grant more negotiation time to the server. 1710 This message is sent by the server as a response to an ACCEPT, 1711 WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message 1712 MUST include the copy of the service description document as stored 1713 by the server. In particular, the following considerations are taken 1714 into account for connectivity provisioning services: 1716 o A copy of the requested/offered CPD is included by the server if 1717 it successfully handled a CANCEL message. 1718 o A copy of the updated CPD is included by the server if it 1719 successfully handled an UPDATE message. 1720 o A copy of the offered CPD is included by the server if it 1721 successfully handled an ACCEPT message in the context of a 1722 QUOTATION transaction (refer to "Agreed CPD" in Section 8.7). 1723 o An empty CPD is included by the server if it successfully handled 1724 a DECLINE or WITHDRAW message. 1726 A client may issue an ACK message as a response to a time extension 1727 request (conveyed in PROCESSING) received from the server. In such 1728 case, the ACK message MUST include an EXPECTED_RESPONSE_TIME that is 1729 likely to be set to the time extension requested by the server. 1731 9.2.7. CANCEL 1733 The format of the CANCEL message is shown below: 1735 ::= 1736 1737 1738 1739 1740 [] 1742 The client can issue a CANCEL message at any stage during the CPNP 1743 negotiation process before an agreement is reached. 1744 CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID are used by the 1745 server as keys to find the corresponding order. If a quotation order 1746 matches, the server changes the state of this quotation order to 1747 "Cancelled" and then returns an ACK with a copy of the requested CPD 1748 to the requesting client. 1750 If no quotation order is found, the server returns a FAIL message to 1751 the requesting client. 1753 9.2.8. WITHDRAW 1755 The format of the WITHDRAW message is shown below: 1757 ::= 1758 1759 1760 1761 1762 1763 1764 [] 1765 [...] 1767 This message is used to withdraw an offer already accepted by the 1768 Customer. Figure 14 shows a typical usage of this message. 1770 +------+ +------+ 1771 |Client| |Server| 1772 +------+ +------+ 1773 |============WITHDRAW(CPD)===========>| 1774 |<============PROCESSING==============| 1775 |<===========ACK(Empty CPD)===========| 1776 | | 1778 Figure 14: WITHDRAW Flow Example 1780 The CPNP MUST include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1781 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1782 the order. 1784 Upon receipt of a WITHDRAW message, the server checks whether an 1785 order matching the request is found. If an order is found, the state 1786 of the order is changed to "Cancelled" and an ACK message including 1787 an Empty CPD is returned to the requesting client. If no order is 1788 found, the server returns a FAIL message to the requesting client. 1790 9.2.9. UPDATE 1792 The format of the UPDATE message is shown below: 1794 ::= 1795 1796 1797 1798 1799 1800 1801 1802 1803 [...] 1805 This message is sent by the CPNP client to update an existing service 1806 agreement (e.g., connectivity provisioning agreement). The CPNP MUST 1807 include the same CUSTOMER_AGREEMENT_IDENTIFIER, 1808 PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating 1809 the order. The CPNP client includes a new service description (e.g., 1810 updated CPD) which integrates the requested modifications. A new 1811 Transaction_ID MUST be assigned by the client. 1813 Upon receipt of an UPDATE message, the server checks whether an 1814 order, having state "Completed", matches 1815 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1816 NONCE. 1818 o If no order is found, the CPNP server generates a FAIL error with 1819 the appropriate error code (Section 9.2.10). 1820 o If an order is found, the server checks whether it can honor the 1821 request: 1823 * A FAIL message is sent to the client if the server cannot honor 1824 the request. The client may initiate a new PQO negotiation 1825 cycle (that is, a new UPDATE). 1826 * An OFFER message including the updated clauses (e.g., updated 1827 connectivity provisioning document) is sent to the client. For 1828 example, the server maintains an order for provisioning a VPN 1829 service that connects sites A, B, and C. If the client sends 1830 an UPDATE message to remove site C, only sites A and B will be 1831 included in the OFFER sent by the server to the requesting 1832 client. 1834 Note that the cycle that is triggered by an UPDATE message is 1835 also considered as a negotiation cycle. 1837 A flow chart that illustrates the use of UPDATE operation is shown in 1838 Figure 15. 1840 +------+ +------+ 1841 |Client| |Server| 1842 +------+ +------+ 1843 |=========UPDATE(Requested CPD)======>| 1844 |<============PROCESSING==============| 1845 |<=========OFFER(Updated CPD)=========| 1846 |=============PROCESSING=============>| 1847 |==========ACCEPT(Updated CPD)=======>| 1848 |<==========ACK(Updated CPD)==========| 1849 | | 1851 Figure 15: UPDATE Flow Example 1853 9.2.10. FAIL 1855 The format of the FAIL message is shown below: 1857 ::= 1858 1859 1860 1861 1862 1863 1865 This message is sent in the following cases: 1867 o The server cannot honor an order received from the client (i.e., 1868 received in a QUOTATION or UPDATE request). 1869 o The server encounters an error when processing a CPNP request 1870 received from the client. 1871 o The client cannot grant more time to the server. This is a 1872 response to a time extension request carried in a PROCESSING 1873 message. 1875 The status code indicates the error code. The following codes are 1876 supported: 1878 1 (Message Validation Error): 1879 The message cannot be validated (see Section 10). 1880 2 (Authentication Required): 1881 The request cannot be handled because authentication is 1882 required. 1883 3 (Authorization Failed): 1884 The request cannot be handled because authorization failed. 1885 4 (Administratively prohibited): 1886 The request cannot be handled because of administrative 1887 policies. 1888 5 (Out of Resources): 1889 The request cannot be honored because resources (e.g., capacity) 1890 are insufficient. 1891 6 (Network Presence Error): 1892 The request cannot be honored because there is no network 1893 presence. 1894 7 (More Time Rejected): 1895 The request to extend the time for negotiation is rejected by 1896 the client. 1897 8 (Unsupported Activation Type): 1898 The request cannot be handled because the requested activation 1899 type is not supported. 1901 9.2.11. ACTIVATE 1903 The format of the ACTIVATE message is shown below: 1905 ::= 1906 1907 1908 1909 1910 1911 1912 1913 [...] 1915 This message is sent by the CPNP client to request the activation of 1916 an existing service agreement. The message MUST include the same 1917 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1918 NONCE as those used when creating the order. The CPNP client may 1919 includes a schedule target for activating this order. A new 1920 Transaction_ID MUST be assigned by the client. 1922 Upon receipt of an UPDATE message, the server checks whether an 1923 order, having state "Completed", matches 1924 CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and 1925 NONCE. 1927 o If no completed order is found, the CPNP server generates a FAIL 1928 error with the appropriate error code (Section 9.2.10). 1929 o If an order is found, the server checks whether it can honor the 1930 request: 1932 * A FAIL message is sent to the client if the server cannot honor 1933 the request (e.g., out of resources or explicit activation 1934 wasn't negotiated with this client). 1935 * An ACK is sent to the client to confirm that the immediate 1936 activation (or de-activation) of the order or its successful 1937 scheduling if a non-null ACTIVATION_SCHEDULE was included in 1938 the request. Note that setting ACTIVATION_SCHEDULE to 0 in an 1939 ACTIVATE request has a special meaning: it is used to request a 1940 de-activation of an agreed order. 1942 Figure 16 illustrates the use of ACTIVATE operation. 1944 +------+ +------+ 1945 |Client| |Server| 1946 +------+ +------+ 1947 |================ACTIVATE()==========>| 1948 |<==============ACK()=================| 1949 | | 1951 Figure 16: ACTIVATE Flow Example 1953 10. CPNP Message Validation 1955 Both client and server proceed with CPNP message validation. The 1956 following tables summarize the validation checks to be followed. 1958 10.1. On the Client Side 1959 Operation Validation Checks 1960 ------------ -------------------------------------------------------- 1961 PROCESSING {Source IP address, source port number, destination IP 1962 address, destination port number, Transaction- 1963 ID, Customer Order Identifier} must match an 1964 existing PQO with a state set to "PQOSent". The 1965 sequence number carried in the packet must be larger 1966 than the sequence number maintained by the 1967 client. 1968 OFFER {Source IP address, source port number, destination IP 1969 address, destination port number, Transaction- 1970 ID, Customer Order Identifier} must match an 1971 existing order with state set to "PQOSent" or {Source 1972 IP address, source port number, destination IP address, 1973 destination port number, Transaction-ID, 1974 Customer Order Identifier, Provider Order 1975 Identifier} must match an existing order with a state 1976 set to "ServerProcessing". The sequence number 1977 carried in the packet must be larger than the 1978 sequence number maintained by the client. 1979 ACK {Source IP address, source port number, destination IP 1980 (QUOTATION address, destination port number, Transaction- 1981 Transaction) ID, Customer Order Identifier, Provider Order 1982 Identifier, Offered Connectivity Provisioning Order} 1983 must match an order with a state set to "AcceptSent". 1984 The sequence number carried in the packet must 1985 be larger than the sequence number maintained 1986 by the client. 1987 ACK (UPDATE {Source IP address, source port number, destination IP 1988 Transaction) address, destination port number, Transaction- 1989 ID, Customer Order Identifier, Provider Order 1990 Identifier, Updated Connectivity Provisioning Order} 1991 must match an order with a state set to "AcceptSent". 1992 The sequence number carried in the packet must 1993 be larger than the sequence number maintained 1994 by the client. 1995 ACK {Source IP address, source port number, destination IP 1996 (WITHDRAW address, destination port number, Transaction- 1997 Transaction) ID, Customer Order Identifier, Provider Order 1998 Identifier, Empty Connectivity Provisioning Order} 1999 must match an order with a state set to "Cancelled". The 2000 sequence number carried in the packet must be 2001 larger than the sequence number maintained by 2002 the client. 2004 10.2. On the Server Side 2006 Method Validation Checks 2007 ---------- ---------------------------------------------------------- 2008 QUOTATION The source IP address passes existing access filters (if 2009 any). The sequence number carried in the packet 2010 must not be lower than the sequence number 2011 maintained by the server. 2012 PROCESSING The sequence number carried in the packet must be greater 2013 than the sequence number maintained by the 2014 server. 2015 CANCEL {Source IP address, source port number, destination IP 2016 address, destination port number, Transaction- 2017 ID, Customer Order Identifier} must match an 2018 order with state set to "PQOReceived" or 2019 "OfferProposed" or "ProcessingReceived" or "AcceptReceived 2020 ". The sequence number carried in the packet 2021 must be greater than the sequence number 2022 maintained by the server. 2023 ACCEPT {Source IP address, source port number, destination IP 2024 address, destination port number, Transaction- 2025 ID, Customer Order Identifier, Provider Order 2026 Identifier, Nonce, Offered Connectivity Provisioning 2027 Order} must match an order with state set to 2028 "OfferProposed" or "ProcessingReceived". The 2029 sequence number carried in the packet must be 2030 greater than the sequence number maintained by the server. 2031 FAIL {Source IP address, source port number, destination IP 2032 address, destination port number, Transaction- 2033 ID, Customer Order Identifier, Provider Order 2034 Identifier} must match an order with state set to 2035 "AwaitingProcessing" and for which a request to grant more 2036 time to process an offer was requested. The 2037 sequence number carried in the packet must be 2038 greater than the sequence number maintained by the 2039 server. 2040 DECLINE {Source IP address, source port number, destination IP 2041 address, destination port number, Transaction- 2042 ID, Customer Order Identifier, Provider Order 2043 Identifier, Nonce} must match an order with state set 2044 to "OfferProposed" or "ProcessingReceived". The sequence 2045 number carried in the packet must be greater 2046 than the sequence number maintained by the 2047 server. 2048 UPDATE The source IP address passes existing access filters (if 2049 any) and {Customer Order Identifier, Provider 2050 Order Identifier, Nonce} must match an existing 2051 order with state "Completed". 2053 WITHDRAW The source IP address passes existing access filters (if 2054 any) and {Customer Order Identifier, Provider 2055 Order Identifier, Nonce} must match an existing 2056 order with state "Completed". 2057 ACTIVATE The source IP address passes existing access filters (if 2058 any) and {Customer Order Identifier, Provider 2059 Order Identifier, Nonce} must match an existing 2060 order with state "Completed" for which the 2061 activation procedure is tagged to be explicit. 2063 11. Theory of Operation 2065 Both CPNP client and server proceed with message validation checks as 2066 specified in Section 10. 2068 11.1. Client Behavior 2070 11.1.1. Order Negotiation Cycle 2072 To place a provisioning quotation order, the client first initiates a 2073 local quotation order object identified by a unique identifier 2074 assigned by the client (Client Order Identifier). The state of the 2075 quotation order is set to "Created". The client then generates a 2076 QUOTATION request which includes the assigned identifier, possibly an 2077 expected response time, a Transaction-ID, and a Requested Service 2078 (e.g., Requested Connectivity Provisioning Document). The client may 2079 include additional Information Elements such as Negotiation Options 2080 or Activation Type. 2082 The client may be configured to not enforce negotiation checks on 2083 EXPECTED_OFFER_TIME; if so, no EXPECTED_RESPONSE_TIME attribute (or 2084 EXPECTED_RESPONSE_TIME set to infinite) should be included in the 2085 quotation order. 2087 Once the request is sent to the server, the state of the request is 2088 set to "PQOSent" and a timer, if a response time is included in the 2089 quotation order, is set to the expiration time as included in the 2090 QUOTATION request. The client also maintains a copy of the CPNP 2091 session entry details used to generate the QUOTATION request. The 2092 CPNP client must listen on the same port number that it used to send 2093 the QUOTATION request. 2095 If no answer is received from the server before the retransmission 2096 timer expires (i.e., RETRANS_TIMER, Section 8.5), the client 2097 retransmits the message until maximum retry is reached (e.g., 3 2098 times). The same sequence number is used for retransmitted packets. 2100 If a FAIL message is received, the client may decide to issue another 2101 (corrected) request towards the same server, cancel the local order, 2102 or contact another server. The behavior of the client depends on the 2103 error code returned by the server in the FAIL message. 2105 If a PROCESSING message matching the CPNP session entry (Section 8.3) 2106 is received, the client updates the CPNP session entry with the 2107 PROVIDER_AGREEMENT_IDENTIFIER information. If the client does not 2108 accept the expected offer time that may have been indicated in the 2109 PROCESSING message, the client may decide to cancel the quotation 2110 order. If the client accepts the EXPECTED_OFFER_TIME, it changes the 2111 state of the order to "ServerProcessing" and sets a timer to the 2112 value of EXPECTED_OFFER_TIME. If no offer is made before the timer 2113 expires, the client changes the state of the order to "Cancelled". 2115 As a response to a time extension request (conveyed in a PROCESSING 2116 message that included a new EXPECTED_OFFER_TIME), the client may 2117 grant this extension by issuing an ACK message or reject the time 2118 extension with a FAIL message having a status code set to "More Time 2119 Rejected". 2121 If an OFFER message matching the CPNP session entry is received, the 2122 client checks if a PROCESSING message having the same 2123 PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If 2124 a PROCESSING message was already received for the same order but the 2125 PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included 2126 in the OFFER message, the client silently ignores the message. If a 2127 PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was 2128 already received and matches the CPNP transaction identifier, the 2129 client changes the state of the order to "OfferReceived" and sets a 2130 timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER 2131 message. 2133 If an offer is received from the server (i.e., as documented in an 2134 OFFER message), the client may accept or reject the offer. The 2135 client accepts the offer by generating an ACCEPT message which 2136 confirms that the client agrees to subscribe to the offer documented 2137 in the OFFER message; the state of the order is passed to 2138 "AcceptSent". The transaction is terminated if an ACK message is 2139 received from the server. If no ACK is received from the server, the 2140 client proceeds with the retransmission of the ACCEPT message until 2141 the maximum retry is reached (Section 11.4). 2143 The client may also decide to reject the offer by sending a DECLINE 2144 message. The state of the order is set by the client to "Cancelled". 2145 If an offer is not acceptable by the client, the client may decide to 2146 contact a new server or submit another order to the same server. 2148 Guidelines to issue an updated order or terminate the negotiation are 2149 specific to the client. 2151 An order can be activated (or de-activated) using the ACTIVATE 2152 message or other agreed activation means (Section 3.11 of [RFC7297]). 2154 11.1.2. Order Withdrawal Cycle 2156 A client may withdraw a completed order. This is achieved by issuing 2157 a WITHDRAW message. This message MUST include Customer Order 2158 Identifier, Provider Identifier, and Nonce returned during the order 2159 negotiation cycle, as specified in Section 11.1.1. 2161 If no ACK is received from the server, the client proceeds with the 2162 retransmission of the message. If no ACK is received after the 2163 maximum retry is exhausted, the client should log the information and 2164 must send an alarm to the administrator. If there is no specific 2165 instruction from the administrator, the client SHOULD schedule 2166 another Withdrawal cycle. The client MUST NOT retry this Withdrawal 2167 cycle more frequently than every 300 seconds and MUST NOT retry more 2168 frequently than every 60 seconds. 2170 11.1.3. Order Update Cycle 2172 A client may update a completed order. This is achieved by issuing 2173 an UPDATE message. This message MUST include Customer Order 2174 Identifier, Provider Order Identifier and Nonce returned during the 2175 order negotiation cycle specified in Section 11.1.1. The client MUST 2176 include in the UPDATE message an updated CPD with the requested 2177 changes. 2179 Subsequent messages exchange is similar to what is documented in 2180 Section 11.1.1. 2182 11.2. Server Behavior 2184 11.2.1. Order Processing 2186 Upon receipt of a QUOTATION message from a client, the server sets a 2187 CPNP session, stores Transaction-ID and generates a Provider Order 2188 Identifier. Once preliminary validation checks are completed ( 2189 Section 10), the server may return a PROCESSING message to inform the 2190 client that the quotation order is received and it is under 2191 processing; the server may include an expected offer time to notify 2192 the client by when an offer will be proposed. An order with state 2193 "AwaitingProcessing" is created by the server. The server runs its 2194 decision-making process to decide which offer it can make to honor 2195 the received order. The offer should be made before the expected 2196 offer time expires. 2198 If the server cannot make an offer, it sends backs a FAIL message 2199 with the appropriate error code. 2201 If the server requires more negotiation time, it must send a 2202 PROCESSING message with a new EXPECTED_OFFER_TIME. The client may 2203 grant this extension by issuing an ACK message or reject the time 2204 extension with a FAIL message having a status code set to "More Time 2205 Rejected". If the client doesn't grant more time, the server must 2206 answer before the initial expected offer time; otherwise the client 2207 will decline the quotation order. 2209 If the server can honor the request or it can make an offer that 2210 meets only some of the requirements, it creates an OFFER message. 2211 The server must indicate the Transaction-ID, Customer Order 2212 Identifier as indicated in the QUOTATION message, and the Provider 2213 Order Identifier generated for this order. The server must also 2214 include Nonce and the offered service document (e.g., offered 2215 Connectivity Provisioning Document). The server includes an offer 2216 validity time as well. Once sent to the client, the server changes 2217 the state of the order to "OfferProposed" and a timer set to the 2218 validity time is initiated. 2220 If the server determines that additional network resources from 2221 another network provider are needed to accommodate a quotation order, 2222 it will create child PQO(s) and will behave as a CPNP client to 2223 negotiate child PQO(s) with possible partnering providers (see 2224 Figure 7). 2226 If no PROCESSING, ACCEPT, or DECLINE message is received before the 2227 expiry of the RETRANS_TIMER, the server re-sends the same offer to 2228 the client. This procedure is repeated until maximum retry is 2229 reached. 2231 If an ACCEPT message is received before the offered validity time 2232 expires, the server proceeds with validation checks as specified in 2233 Section 10. The state of the corresponding order is passed to 2234 "AcceptReceived". The server sends back an ACK message to terminate 2235 the order processing cycle. 2237 If a CANCEL/DECLINE message is received, the server proceeds with the 2238 cancellation of the order. The state of the order is then passed to 2239 "Cancelled". 2241 11.2.2. Order Withdrawal 2243 A client may withdraw a completed order by issuing a WITHDRAW 2244 message. Upon receipt of a WITHDRAW message, the server proceeds 2245 with the validation checks, as specified in Section 10: 2247 o If the checks fail, a FAIL message is sent back to the client with 2248 the appropriate error code (e.g., 1 (Message Validation Error), 2 2249 (Authentication Required), or 3 (Authorization Failed)). 2251 o If the checks succeed, the server clears the clauses of the 2252 Connectivity Provisioning Document, changes the state of the order 2253 to "Cancelled", and sends back an ACK message with an Empty 2254 Connectivity Provisioning Document. 2256 11.2.3. Order Update 2258 A client may update an order by issuing an UPDATE message. Upon 2259 receipt of an UPDATE message, the server proceeds with the validation 2260 checks as specified in Section 10: 2262 o If the checks fail, a FAIL message is sent back to the client with 2263 the appropriate error code (e.g., 1 (Message Validation Error), 2 2264 (Authentication Required), 3 (Authorization Failed), or 6 (Network 2265 Presence Error)). 2266 o The exchange of subsequent messages is similar to what is 2267 specified in Section 11.1.1. The server should generate a new 2268 Nonce value to be included in the offer made to the client. 2270 11.3. Sequence Numbers 2272 In each transaction, sequence numbers are used to protect the 2273 transaction against replay attacks. Each communicating partner of 2274 the transaction maintains two sequence numbers, one for incoming 2275 packets and one for outgoing packets. When a partner receives a 2276 message, it will check whether the sequence number in the message is 2277 larger than the incoming sequence number maintained locally. If not, 2278 the message will be discarded. If the message is proved to be 2279 legitimate, the value of the incoming sequence number maintained 2280 locally will be replaced by the value of the sequence number in the 2281 message. When a partner sends out a message, it will insert the 2282 value of the outgoing sequence number into the message and increase 2283 the outgoing sequence number maintained locally by 1. 2285 11.4. Message Re-Transmission 2287 If a transaction partner sends out a message and does not receive any 2288 expected reply before the retransmission timer expires (i.e., 2289 RETRANS_TIMER), a transaction partner will try to re-transmit the 2290 message. The procedure is reiterated until a maximum retry is 2291 reached (e.g., 3 times). An exception is the last message (e.g., 2292 ACK) sent from the server in a transaction. After sending this 2293 message, the retransmission timer will be disabled since no 2294 additional feedback is expected. 2296 In addition, if the partner receives a retransmission of a last 2297 incoming packet it handled, the partner can re-send the same answer 2298 to the incoming packet with a limited frequency. If no answer was 2299 generated at the moment, the partner needs to generate a PROCESSING 2300 message as the answer. 2302 To optimize message retransmission, a partner could also store the 2303 last incoming packet and the associated answer. Note that the times 2304 of retransmission could be decided by the local policy and 2305 retransmission will not cause any change of sequence numbers. 2307 12. Some Operational Guidelines 2309 12.1. Logging on the CPNP Server 2311 The CPNP server should be configurable to log various events and 2312 associated information. Such information may include: 2314 o Client's IP address 2315 o Any event change (e.g., new quotation order, offer sent, order 2316 confirm, order cancellation, order withdraw, etc.) 2317 o Timestamp 2319 The exact logging details are deployment-specific. 2321 12.2. Business Guidelines and Objectives 2323 The CPNP server can operate in the following modes: 2325 1. Fully automated mode: 2327 The CPNP server is provisioned with a set of business guidelines 2328 and objectives that will be used as an input to the decision- 2329 making process. The CPNP server will service received orders 2330 that fall into these business guidelines; otherwise, requests 2331 will be escalated to an administrator that will formally 2332 validate/invalidate an order request. The set of policies to be 2333 configured to the CPNP server are specific to each administrative 2334 entity managing a CPNP server. 2336 2. Administrative-based mode: 2338 This mode assumes some or all CPNP server' operations are subject 2339 to a formal administrative validation. CPNP events will trigger 2340 appropriate validation requests that will be forwarded to the 2341 contact person(s) or department which is responsible for 2342 validating the orders. Administrative validation messages are 2343 relayed using another protocol (e.g., SMTP) or a dedicated tool. 2345 Business guidelines are local to each administrative entity. How 2346 validation requests are presented to an administrator are out of 2347 scope of this document; each administrative entity may decide the 2348 appropriate mechanism to enable for that purpose. 2350 13. Security Considerations 2352 Means to defend the server against denial-of-service attacks must be 2353 enabled. For example, access control lists (ACLs) can be enforced on 2354 the client, the server or the network in between, to allow a trusted 2355 client to communicate with a trusted server. 2357 The client and the server MUST be mutually authenticated. 2358 Authenticated encryption MUST be used for data confidentiality and 2359 message integrity. 2361 The protocol does not provide security mechanisms to protect the 2362 confidentiality and integrity of the packets transported between the 2363 client and the server. An underlying security protocol such as 2364 (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport 2365 Layer Security (TLS) [RFC8446]) MUST be used to protect the integrity 2366 and confidentiality of protocol messages. In this case, if it is 2367 possible to provide an Automated Key Management (AKM) and associate 2368 each transaction with a different key, inter-transaction replay 2369 attacks can naturally be addressed. If the client and the server use 2370 a single key, an additional mechanism should be provided to protect 2371 inter-transaction replay attacks between them. Clients MUST 2372 implement DTLS record replay detection (Section 3.3 of [RFC6347]) or 2373 an equivalent mechanism to protect against replay attacks. 2375 DTLS and TLS with a cipher suite offering confidentiality protection 2376 and the guidance given in [RFC7525] MUST be followed to avoid attacks 2377 on (D)TLS. 2379 The client MUST silently discard CPNP responses received from unknown 2380 CPNP servers. The use of a randomly generated Transaction-ID makes 2381 it hard to forge a response from a server with a spoofed IP address 2382 belonging to a legitimate CPNP server. Furthermore, CPNP demands 2383 that messages from the server must include the correct identifiers of 2384 the orders. Two order identifiers are used: one generated by the 2385 client and a second one generated by the server. 2387 The Provider MUST enforce means to protect privacy-related 2388 information included the documents (see Section 8.7) exchanged in 2389 CPNP messages [RFC6462]. In particular, this information MUST NOT be 2390 revealed to external parties without the consent of Customers. 2391 Providers should enforce policies to make Customer fingerprinting 2392 difficult to achieve (e.g., in a recursion request). For more 2393 discussion about privacy, refer to [RFC6462][RFC6973]. 2395 The Nonce and the Transaction ID attributes provide sufficient 2396 randomness and can effectively tolerate attacks raised by off-line 2397 adversaries, who do not have the capability of eavesdropping and 2398 intercepting the packets transported between the client and the 2399 server. Only authorized clients must be able to modify agreed CPNP 2400 orders. The use of a randomly generated Nonce by the server makes it 2401 hard to modify an agreement on behalf of a malicious third-party. 2403 14. IANA Considerations 2405 This document does not request any IANA action. 2407 15. Acknowledgements 2409 Thanks to Diego R. Lopez and Adrian Farrel for the comments. 2411 Thanks to the ISE reviewers. 2413 Special thanks to Luis Miguel Contreras Murillo for the detailed 2414 review. 2416 16. References 2418 16.1. Normative References 2420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2421 Requirement Levels", BCP 14, RFC 2119, 2422 DOI 10.17487/RFC2119, March 1997, 2423 . 2425 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2426 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2427 . 2429 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2430 "Randomness Requirements for Security", BCP 106, RFC 4086, 2431 DOI 10.17487/RFC4086, June 2005, 2432 . 2434 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2435 Used to Form Encoding Rules in Various Routing Protocol 2436 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2437 2009, . 2439 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2440 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2441 January 2012, . 2443 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 2444 Connectivity Provisioning Profile (CPP)", RFC 7297, 2445 DOI 10.17487/RFC7297, July 2014, 2446 . 2448 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2449 "Recommendations for Secure Use of Transport Layer 2450 Security (TLS) and Datagram Transport Layer Security 2451 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2452 2015, . 2454 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2455 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2456 May 2017, . 2458 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2459 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2460 . 2462 16.2. Informative References 2464 [AGAVE] Boucadair, M., Georgatsos, P., Wang, N., Griffin, D., 2465 Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE 2466 Approach for Network Virtualization: Differentiated 2467 Services Delivery", April 2009, 2468 . 2471 [ETICS] EU FP7 ETICS Project, "Economics and Technologies of 2472 Inter-Carrier Services", January 2014, . 2476 [I-D.barguil-opsawg-l2sm-l2nm] 2477 Barguil, S., Dios, O., Lopezalvarez, V., Munoz, L., and L. 2478 Jalil, "A Layer 2 VPN Network Yang Model", draft-barguil- 2479 opsawg-l2sm-l2nm-01 (work in progress), March 2020. 2481 [I-D.boucadair-lisp-idr-ms-discovery] 2482 Boucadair, M. and C. Jacquenet, "LISP Mapping Service 2483 Discovery at Large", draft-boucadair-lisp-idr-ms- 2484 discovery-01 (work in progress), March 2016. 2486 [I-D.contreras-teas-slice-nbi] 2487 Contreras, L., Homma, S., and J. Ordonez-Lucena, 2488 "Considerations for defining a Transport Slice NBI", 2489 draft-contreras-teas-slice-nbi-01 (work in progress), 2490 March 2020. 2492 [I-D.geng-netslices-architecture] 2493 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 2494 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 2495 Architecture", draft-geng-netslices-architecture-02 (work 2496 in progress), July 2017. 2498 [I-D.ietf-opsawg-l3sm-l3nm] 2499 Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A. 2500 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 2501 opsawg-l3sm-l3nm-02 (work in progress), March 2020. 2503 [I-D.itsumo-dsnp] 2504 Chen, J., "Dynamic Service Negotiation Protocol (DSNP)", 2505 draft-itsumo-dsnp-03 (work in progress), March 2006. 2507 [I-D.nguyen-rap-cops-sls] 2508 Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)", 2509 draft-nguyen-rap-cops-sls-03 (work in progress), July 2510 2002. 2512 [Karl] Czajkowski, K., Foster, I., Kesselman, C., Sander, V., and 2513 S. Tuecke, "SNAP: A Protocol for Negotiating Service Level 2514 Agreements and Coordinating Resource Management in 2515 Distributed Systems", 2516 . 2519 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2520 specifying the location of services (DNS SRV)", RFC 2782, 2521 DOI 10.17487/RFC2782, February 2000, 2522 . 2524 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 2525 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 2526 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 2527 RFC 3084, DOI 10.17487/RFC3084, March 2001, 2528 . 2530 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2531 Private Network (VPN) Terminology", RFC 4026, 2532 DOI 10.17487/RFC4026, March 2005, 2533 . 2535 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 2536 and A. Gonguet, "Framework for Layer 3 Virtual Private 2537 Networks (L3VPN) Operations and Management", RFC 4176, 2538 DOI 10.17487/RFC4176, October 2005, 2539 . 2541 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2542 and A. Bierman, Ed., "Network Configuration Protocol 2543 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2544 . 2546 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 2547 RFC 6462, DOI 10.17487/RFC6462, January 2012, 2548 . 2550 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 2551 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 2552 . 2554 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 2555 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 2556 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 2557 November 2012, . 2559 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 2560 Autonomous System (AS) Number Space", RFC 6793, 2561 DOI 10.17487/RFC6793, December 2012, 2562 . 2564 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2565 Locator/ID Separation Protocol (LISP)", RFC 6830, 2566 DOI 10.17487/RFC6830, January 2013, 2567 . 2569 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2570 Morris, J., Hansen, M., and R. Smith, "Privacy 2571 Considerations for Internet Protocols", RFC 6973, 2572 DOI 10.17487/RFC6973, July 2013, 2573 . 2575 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2576 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2577 October 2013, . 2579 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 2580 Networking: A Perspective from within a Service Provider 2581 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 2582 . 2584 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 2585 Pascual, J., and D. Lewis, "Locator/Identifier Separation 2586 Protocol (LISP) Network Element Deployment 2587 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2588 2014, . 2590 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 2591 Application-Based Network Operations", RFC 7491, 2592 DOI 10.17487/RFC7491, March 2015, 2593 . 2595 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2596 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2597 . 2599 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2600 Interchange Format", STD 90, RFC 8259, 2601 DOI 10.17487/RFC8259, December 2017, 2602 . 2604 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2605 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2606 DOI 10.17487/RFC8299, January 2018, 2607 . 2609 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2610 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2611 . 2613 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 2614 Kumar, "Framework for Interface to Network Security 2615 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 2616 . 2618 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2619 Data Model for Layer 2 Virtual Private Network (L2VPN) 2620 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2621 2018, . 2623 [RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., 2624 and P. Iovanna, "Cooperating Layered Architecture for 2625 Software-Defined Networking (CLAS)", RFC 8597, 2626 DOI 10.17487/RFC8597, May 2019, 2627 . 2629 [TEQUILA] Georgatsos, P. and G. Giannakopoulos, "Service Negotiation 2630 Protocol (SrNP)", . 2633 [Xin] Wang, X., "Resource Negotiation and Pricing Protocol 2634 (RNAP)", 2635 . 2638 Authors' Addresses 2640 Mohamed Boucadair (editor) 2641 Orange 2642 Rennes 35000 2643 France 2645 Email: mohamed.boucadair@orange.com 2647 Christian Jacquenet 2648 Orange 2649 Rennes 35000 2650 France 2652 Email: christian.jacquenet@orange.com 2654 Dacheng Zhang 2655 Huawei Technologies 2657 Email: dacheng.zhang@huawei.com 2658 Panos Georgatsos 2659 Centre for Research and Innovation 2660 Hellas 2661 78, Filikis Etairias str. 2662 Volos, Hellas 38334 2663 Greece 2665 Phone: +302421306070 2666 Email: pgeorgat@gmail.com