idnits 2.17.1 draft-boucadair-connectivity-provisioning-protocol-01.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 (October 08, 2013) is 3852 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-boucadair-connectivity-provisioning-profile-02 == Outdated reference: A later version (-09) exists of draft-sin-sdnrg-sdn-approach-04 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track France Telecom 5 Expires: April 11, 2014 October 08, 2013 7 Connectivity Provisioning Negotiation Protocol (CPNP) 8 draft-boucadair-connectivity-provisioning-protocol-01 10 Abstract 12 This document specifies the Connectivity Provisioning Negotiation 13 Protocol (CPNP) which is used to facilitate the dynamic negotiation 14 of service parameters between a Customer and a Provider. As such, 15 CPNP is a generic protocol that can be used for various negotiation 16 purposes that include (but are not necessarily limited to) 17 connectivity provisioning services, storage facilities, CDN (Content 18 Delivery Networks) footprint, etc. 20 CPNP can be extended with new Information Elements. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 11, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Order Processing Models . . . . . . . . . . . . . . . . . . . 5 65 4. Functional Elements . . . . . . . . . . . . . . . . . . . . . 6 66 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 8 68 7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 8 69 8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Client/Server Communication . . . . . . . . . . . . . . . 9 71 8.2. Server Discovery . . . . . . . . . . . . . . . . . . . . 10 72 8.3. Policy Configuration on the CPNP Server . . . . . . . . . 10 73 8.4. CPNP Session . . . . . . . . . . . . . . . . . . . . . . 12 74 8.5. Extended CPNP Session . . . . . . . . . . . . . . . . . . 12 75 8.6. CPNP Transaction . . . . . . . . . . . . . . . . . . . . 13 76 8.7. CPNP Operations . . . . . . . . . . . . . . . . . . . . . 13 77 8.8. Connectivity Provisioning Documents . . . . . . . . . . . 14 78 8.9. Child Connectivity Provisioning Quotation Orders . . . . 15 79 8.10. State Management . . . . . . . . . . . . . . . . . . . . 16 80 8.10.1. On The Client Side . . . . . . . . . . . . . . . . . 16 81 8.10.2. On The Server Side . . . . . . . . . . . . . . . . . 17 82 8.11. CPNP Timers . . . . . . . . . . . . . . . . . . . . . . . 19 83 9. CPNP Objects . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.1.1. CUSTOMER_ORDER_IDENTIFIER . . . . . . . . . . . . . . 19 86 9.1.2. PROVIDER_ORDER_IDENTIFIER . . . . . . . . . . . . . . 20 87 9.1.3. TRANSACTION_ID . . . . . . . . . . . . . . . . . . . 20 88 9.1.4. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9.1.5. EXPECTED_RESPONSE_DATE . . . . . . . . . . . . . . . 20 90 9.1.6. EXPECTED_OFFER_DATE . . . . . . . . . . . . . . . . . 20 91 9.1.7. VALIDITY_DATE . . . . . . . . . . . . . . . . . . . . 20 92 9.1.8. CONNECTIVITY_PROVISIONING_DOCUMENT . . . . . . . . . 21 93 9.1.9. Information Elements . . . . . . . . . . . . . . . . 21 94 9.2. Operation Messages . . . . . . . . . . . . . . . . . . . 22 95 9.2.1. PROVISION . . . . . . . . . . . . . . . . . . . . . . 22 96 9.2.2. PROCESSING . . . . . . . . . . . . . . . . . . . . . 23 97 9.2.3. OFFER . . . . . . . . . . . . . . . . . . . . . . . . 23 98 9.2.4. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . 24 99 9.2.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 9.2.6. DECLINE . . . . . . . . . . . . . . . . . . . . . . . 25 101 9.2.7. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 26 102 9.2.8. WITHDRAW . . . . . . . . . . . . . . . . . . . . . . 26 103 9.2.9. UPDATE . . . . . . . . . . . . . . . . . . . . . . . 27 104 9.2.10. FAIL . . . . . . . . . . . . . . . . . . . . . . . . 28 105 10. Message Validation . . . . . . . . . . . . . . . . . . . . . 29 106 10.1. On The Client Side . . . . . . . . . . . . . . . . . . . 29 107 10.2. On The Server Side . . . . . . . . . . . . . . . . . . . 30 108 11. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 30 109 11.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 30 110 11.1.1. Order Negotiation Cycle . . . . . . . . . . . . . . 30 111 11.1.2. Order Withdrawal Cycle . . . . . . . . . . . . . . . 32 112 11.1.3. Order Update Cycle . . . . . . . . . . . . . . . . . 32 113 11.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 32 114 11.2.1. Order Processing . . . . . . . . . . . . . . . . . . 32 115 11.2.2. Order Withdrawal . . . . . . . . . . . . . . . . . . 33 116 11.2.3. Order Update . . . . . . . . . . . . . . . . . . . . 34 117 12. Operational Guidelines . . . . . . . . . . . . . . . . . . . 34 118 12.1. Logging On The CPNP Server . . . . . . . . . . . . . . . 34 119 12.2. Business Guidelines & Objectives . . . . . . . . . . . . 34 120 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 121 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 122 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 123 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 124 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 125 16.2. Informative References . . . . . . . . . . . . . . . . . 36 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 128 1. Introduction 130 [I-D.boucadair-connectivity-provisioning-profile] describes a 131 Connectivity Provisioning Profile (CPP) template to capture 132 connectivity requirements to be met by a transport infrastructure for 133 the delivery of various services such as Voice over IP, IPTV, and VPN 134 services. The CPP profile defines the set of IP transfer parameters 135 that reflect the guarantees that can be provided by the underlying 136 transport network together with a reachability scope and capacity 137 needs. 139 This document defines the Connectivity Provisioning Negotiation 140 Protocol (CPNP) that is meant to dynamically exchange and negotiate 141 the connectivity provisioning parameters between a Customer and a 142 Provider. CPNP is a tool that introduces automation in the service 143 negotiation and activation procedures, thus fostering the overall 144 service delivery process. CPNP can be seen as a component of the 145 dynamic negotiation meta-domain described in Section 3.4 of 146 [I-D.sin-sdnrg-sdn-approach]. 148 CPNP is a generic protocol that can be used for other negotiation 149 purposes than connectivity provisioning. For example, CPNP can be 150 used to request extra storage resources, to extend the footprint of a 151 CDN, to enable additional features from a cloud provider, etc. CPNP 152 can be extended with new Information Elements. 154 As a reminder, several proposals have been made in the past by the 155 community (e.g., COPS-SLS, SrNP (Service Negotiation Protocol), DSNP 156 (Dynamic Service Negotiation Protocol, RNAP (Resource Negotiation and 157 Pricing Protocol), SNAP (Service Negotiation and Acquisition 158 Protocol), etc.). None of these proposals has been standardized by 159 IETF. It is out of the scope of this document to elaborate on the 160 differences between CPNP and the aforementioned proposals. 162 2. Terminology 164 This document makes use of the following terms: 166 o Customer: is a business role which denotes an entity that is 167 involved in the definition and the possible negotiation of a 168 Connectivity Provisioning Agreement with a Network Provider. This 169 contract is captured in a dedicated CPP (Connectivity Provisioning 170 Profile, [I-D.boucadair-connectivity-provisioning-profile]) 171 template, which specifies (among other information): the sites to 172 be connected, border nodes, outsourced operations (e.g., routing). 173 The right to invoke the connectivity service may be delegated by 174 the Customer to third-party End Users, or brokering services. 176 o Network Provider (or Provider): owns and administers one or many 177 transport domain(s) (typically Autonomous System (AS)) composed of 178 IP switching and transmission resources (e.g., routing, switching, 179 forwarding, etc.). Network Providers are responsible for ensuring 180 connectivity services (e.g., offering global or restricted 181 reachability). Connectivity services offered to Customers are 182 captured in contracts from which are derived the technology- 183 specific clauses and policies to be enforced by the components 184 involved in the connectivity service delivery. Offered 185 connectivity services are not restricted to IP. 187 3. Order Processing Models 189 There are basically two models for customer's order processing 190 purposes: 192 1. Frozen model: The Customer cannot negotiate the parameters of the 193 connectivity service delivered by a Provider. After consulting a 194 service portfolio, the Customer selects the offer he/she wants to 195 subscribe and places an order to the Provider. Order handling is 196 quite simple on the Provider side because the service is not 197 customized as per customer's requirements, but rather pre- 198 designed to target a group of customers having similar 199 requirements (and who therefore share the same Customer 200 Provisioning Profile). 202 2. Announcement model: The Provider proceeds to the announcement of 203 a set of services templates. The Customer can then initiate a 204 negotiation cycle using these templates to prepare its request 205 order. 207 3. Negotiation-based model: Unlike the frozen model, the Customer 208 documents his/her requirements in some kind of request for 209 quotation which is then sent to one or several Providers. 210 Solicited Providers then check whether they can address these 211 requirements or not, and get back to the Customer accordingly, 212 possibly with an offer that may not exactly match customer's 213 requirements (e.g., a 100 Mbps connection cannot be provisioned 214 given the amount of available resources, but an 80 Mbps 215 connection can be provided). A negotiation between the Customer 216 and the Provider then follows, and an order is placed by the 217 Customer eventually, upon completion of the negotiation phase. 219 Even if the frozen model could also yield the instantiation of a CPP 220 template and CPNP could be used to display the said CPP to the 221 customer and confirm the order is being processed/delivered, etc., 222 this document focuses on the negotiation-based model. 224 Order processing management on the Network Provider's side is usually 225 connected with the following functional blocks: 227 o Network Provisioning (including Order Activation, Network 228 Planning, etc.) 230 o AAA 232 o Sales-related functional blocks (e.g., billing, Customers credit 233 checks validation, etc.) 235 o Network Impact Analysis 237 CPNP does not assume any specific knowledge about these functional 238 blocks, but the instantiation of the connectivity provisioning 239 requests may be conditioned by the information manipulated by some of 240 these blocks. For example, the resources that can be allocated to 241 accommodate the customer's requirements may depend on the network 242 planning policy as well as the number of orders to be processed 243 simultaneously over a given period of time. 245 This document does not elaborate on how Customers are identified and 246 managed by the Provider's Information System. 248 4. Functional Elements 250 The following functional elements are defined in the context of CPNP: 252 o Client: denotes a software instance that sends CPNP requests and 253 receives CPNP responses. The current operations that can be 254 performed by a CPNP client are listed below: 256 1. Create a quotation order (Section 11.1.1). 258 2. Cancel an ongoing quotation order under negotiation 259 (Section 11.1.1). 261 3. Withdraw a pre-negotiated order (Section 11.1.2). 263 4. Update a pre-negotiated order (Section 11.1.3). 265 o Server: denotes a software instance that receives CPNP requests 266 and sends back CPNP responses accordingly. The CPNP server is 267 responsible for the following operations: 269 1. Quotation order handling (Section 11.2.1). 271 2. Cancel an ongoing quotation order (Section 11.2.2). 273 3. Handling of an order withdrawal (Section 11.2.3). 275 5. Sample Use Cases 277 A list of CPNP use cases is provided below: 279 o [RFC4176] introduces the L3VPN Service Order Management functional 280 block which is responsible for managing the requests initiated by 281 the Customers and tracks the status of the completion of the 282 related operations. CPNP can be used between the Customer and the 283 Provider to negotiate L3VPN service parameters. A CPNP server 284 could therefore be part of the L3VPN Service Order Management 285 functional block discussed in [RFC4176]. 287 o CPNP can be used between two adjacent domains to deliver IP 288 interconnect services (e.g., enable, update, disconnect). For 289 example, two ASes can be connected via several interconnection 290 points. CPNP can be used between these ASes to upgrade existing 291 links, request additional resources, provision a new 292 interconnection point, etc. 294 o An integrated Provider can use CPNP to rationalize connectivity 295 provisioning needs related to its service portfolio. A CPNP 296 server function is used by network operations teams. A CPNP 297 interface to invoke CPNP negotiation cycles is exposed to service 298 management teams. 300 o Service Providers can initiate connectivity provisioning requests 301 towards Network Providers using CPNP. Multiple CPNP ordering 302 cycles can be initiated by a Service Provider towards multiple 303 Network Providers. Only a subset of these orders may be put into 304 effect. 306 o CPNP can be used in M2M environments to dynamically subscribe to 307 M2M services (e.g., access to data retrieved by a set of sensors, 308 extend sensor coverage, etc.). 310 o A provider offering cloud services can expose a CPNP interface to 311 allow customers to dynamically negotiate the features they want to 312 subscribe to. These features can be for instance: request 313 additional storage resources, enable security filters, etc. 315 o CDN Providers can use CPNP to extend their footprint by 316 interconnecting their CDN infrastructure [RFC6770] (see Figure 1). 318 ,--,--,--. ,--,--,--. 319 ,-' `-. ,-' `-. 320 (CDN Provider 'A')=====(CDN Provider 'B') 321 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 322 `--'--'--' `--'--'--' 324 Figure 1: CDN Interconnection 326 6. Deployment Models 328 Several CPNP deployment models can be envisaged. Two examples are 329 listed below: 331 o The Customer deploys a CPNP client while one or several CPNP 332 servers are deployed by the Provider. 334 o The Customer does not enable any CPNP client. The Provider 335 maintains a Customer Order Management portal. The Customer can 336 initiate connectivity provisioning quotation orders via the 337 portal; appropriate CPNP messages are then generated and sent to 338 the relevant CPNP server. In this model, both the CPNP client and 339 CPNP server are under the responsibility of the same 340 administrative entity (i.e., Network Provider). 342 Once the negotiation of connectivity provisioning parameters is 343 completed and an order has been placed by the Customer accordingly, 344 the actual network provisioning operations are initiated. The 345 specification of corresponding dynamic resource allocation and policy 346 enforcement schemes, as well as how CPNP servers interact with 347 network provisioning functional blocks are out of the scope of this 348 document. 350 This document does not make any assumption about the CPNP deployment 351 model either. 353 7. CPNP Negotiation Model 355 CPNP adopts a Quotation Order/Offer/Answer model where: 357 1. The client specifies its requirements via a Provision Quotation 358 Order (PQO). 360 2. The server makes an offer to either address the requirements of 361 the PQO or suggests a counter-proposal that partially addresses 362 the requirements of the PQO or declines the PQO. 364 3. The client either accepts or declines the offer. 366 The server may support the optional functionality to publish 367 available services to the clients. Dedicated templates can be 368 defined for the purpose of service announcements. The client will 369 use these templates to initiate its CPNP negotiation cycle. 371 Only one Offer/Answer stage is assumed within one single CPNP 372 transaction (Section 8.6). Nevertheless, multiple CPNP transactions 373 can be undertaken by the CPNP client (see Figure 2). 375 +------+ +------+ +------+ +------+ 376 |Client| |Server| |Client| |Server| 377 +------+ +------+ +------+ +------+ 378 |==== Quotation Order=====>| |==== Quotation Order======>| 379 |<====Make an offer========| |<=====Make an offer========| 380 |=========Accept==========>| |=========Decline==========>| 382 1-Step Successful Negotiation 1-Step Failed Negotiation 383 Cycle Cycle 385 +------+ +------+ +------+ +------+ 386 |Client| |Server| |Client| |Server| 387 +------+ +------+ +------+ +------+ 388 |==Quotation Order(CPDa)==>| |==Quotation Order(CPD1)==>| 389 |<====Make an offer========| |<=====Make an offer=======| 390 |========Decline==========>| |=========Decline=========>| 391 |==Quotation Order(CPDb)==>| |==Quotation Order(CPD2)==>| 392 |<====Make an offer========| |<=====Make an offer=======| 393 |=========Accept==========>| |=========Decline=========>| 394 |==Quotation Order(CPD3)==>| 395 |<=====Make an offer=======| 396 |=========Decline=========>| 397 |==Quotation Order(CPD4)==>| 398 |<==Fail to make an offer==| 400 N-Step Negotiation Cycle: N-Step Negotiation Cycle: 401 Successful Negotiation Failed Negotiation 403 Figure 2: Overall Negotiation Process 405 8. Protocol Overview 407 8.1. Client/Server Communication 409 CPNP is a client/server protocol which runs over UDP. No permanent 410 CPNP session needs to be maintained between the client and the 411 server. There is no need to run CPNP over a reliable transport mode 412 because CPNP messages are acknowledged. 414 The server uses CPNP_PORT (see Section 14) to bind the CPNP service. 415 CPNP client sends messages to CPNP_PORT. The same port is used as 416 the source port of the request sent to the server to document service 417 requirements, and must be used by the client to listen to messages 418 sent by the server. 420 CPNP messages can also be transported over DTLS [RFC6347]. 422 8.2. Server Discovery 424 The CPNP client can be configured with the CPNP server using manual 425 or dynamic configuration means. For example, Providers may configure 426 dedicated SRV records ([RFC2782]). 428 Discussions about how the client discovers its server(s) are out of 429 the scope of this document. The document assumes a CPNP server can 430 be reached by the CPNP client, thanks to some configuration means. 432 8.3. Policy Configuration on the CPNP Server 434 As an input to the CPNP server's decision-making process, the CPNP 435 server is connected to various external modules such as: Customer 436 Profiles, Network Topology, Network Resource Management, Orders 437 Repository, AAA or Network Provisioning Manager (an example is shown 438 in Figure 3). 440 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 .Business & Administrative Management . 442 .+------------------------++---------------------------+. 443 .| Business Guidelines || Billing & Charging |. 444 .+-----------+------------++-----------+---------------+. 445 . | | . 446 . +-------------------+ | . 447 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 448 . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . 449 .Order Handling Management | | . 450 . +-------------------+ +-------+-----+--------------+ . 451 . |Network Topology DB+--+ CPNP Server | . 452 . +-------------------+ +-+---+---+---+---+-----+----+ . 453 . | | | | | | . 454 . +------------------------+-+ | | | | | . 455 . | Network Dimensioning | | | | | | . 456 . | & Planning | | | | | | . 457 . +--------------------------+ | | | | | . 458 . +----------------------------+-+ | | | +---+----+ . 459 . | | | | | | AAA | . 460 . | Network +------------+ | | | +--------+ . 461 . | Resource | +------------+-+ | +-+----------+ . 462 . | Management | | Customer | | | Orders | . 463 . | | | Profiles | | | Repository | . 464 . +-----------------+ +--------------+ | +------------+ . 465 . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . 466 +--------------------------------------+----------------+ 467 | Network Provisioning Manager | 468 +-------------------------------------------------------+ 470 Figure 3: Order Handling Management Functional Block 472 These external modules provide inputs to the CPNP server, so that it 473 can: 475 o Check whether a customer is entitled to initiate the connectivity 476 provisioning quotation request. 478 o Check whether a customer is entitled to cancel the order 480 o Check whether administrative data (e.g., billing-related 481 information) have been verified before starting handling the 482 request 484 o Check whether network capacity is available or additional capacity 485 is required 487 o Receive guidelines from network design and sales blocks (e.g., 488 cost, increase network usage, threshold of how many CPP templates 489 can be processed over a given period of time as a function of the 490 nature of the service to be delivered, etc.) 492 o Transfer completed orders to network provisioning blocks 494 o Etc. 496 The above list of CPNP server operations is not exhaustive. 498 The following order handling modes can be also configured on the 499 server: 501 1. Fully automated mode: This mode does not require any action from 502 the administrator when receiving a request for a service. The 503 server can execute its decision-making process related to the 504 orders received and generate corresponding offers. 506 2. Administrative validation checking: Some or all server's 507 operations are subject to administrative validation procedures. 508 This mode requires an action from the administrator for every 509 request received by the CPNP server. CPNP methods which can be 510 automatically handled or subject to one or several validation 511 administrative checks can be configured on the server. 513 8.4. CPNP Session 515 Both the client and server maintain the following CPNP transport 516 session information: 518 A CPNP session is identified by the following items: 520 o IP address of the client 522 o Client's port number 524 o IP address of the server 526 o Server's port number 528 8.5. Extended CPNP Session 530 An extended PQO session denotes a 4-uplet defined as follows: 532 o CPNP session 534 o Customer Order Identifier 535 o Provider Order Identifier 537 o Transaction-ID 539 8.6. CPNP Transaction 541 A CPNP transaction occurs between a client and a server and comprises 542 all CPNP messages, from the first request sent by the client to the 543 server until a final response sent by the server to the client and 544 which completes the transaction. The CPNP transaction is bound to a 545 CPNP session. 547 Because multiple CPNP transactions can be maintained by the CPNP 548 client, the client must assign an identifier to uniquely identify a 549 given transaction. This identifier is denoted as Transaction-ID. 551 The Transaction-ID must be randomly assigned, according to the best 552 current practice for generating random numbers [RFC4086] that cannot 553 be guessed easily. Transaction-ID is used as part of the validation 554 of CPNP responses received by the client. 556 Using cryptographically random Transaction-IDs provides some 557 protection against session hijacking. 559 8.7. CPNP Operations 561 The current CPNP operations are listed below. They may be augmented, 562 depending on the nature of some transactions or because of security 563 considerations that may suggest a CPNP client/server authentication 564 phase before negotiation begins. 566 o PROVISION: This operation is used to initiate a connectivity 567 provisioning quotation order. Upon receipt of a PROVISION 568 request, the server may response with a PROCESSING, OFFER or a 569 FAIL message. 571 o PROCESSING: This operation is used to inform the remote party the 572 message was received and that the order quotation or the offer is 573 being processed. 575 o OFFER: This operation is used by the server to inform the client 576 about an Offer that is supposed to best accommodate the 577 requirements indicated in the PROVISION message. 579 o ACCEPT: This operation is used to confirm the acceptance of an 580 offer made by the server. 582 o ACK: This operation is used by the server to acknowledge the 583 receipt of an ACCEPT or WITHDRAW message. 585 o DECLINE: This operation is used by a client to reject an offer 586 made by the server. 588 o CANCEL: This operation is used by the client to cancel an ongoing 589 connectivity provisioning quotation order. 591 o WITHDRAW: This operation is used by the client to withdraw a pre- 592 negotiated connectivity provisioning order. 594 o UPDATE: This operation is used by the client to update an existing 595 connectivity provisioning order. For example, this method can be 596 invoked to add a new site. This method will trigger a new 597 negotiation cycle. 599 o FAIL: This operation is used by the server when it cannot 600 accommodate the requirements documented in the PQO conveyed in the 601 PROVISION message. This operation can also be used by a server to 602 inform the client about an error encountered when processing the 603 received message. The message includes the status code which 604 provides more information about the error. 606 8.8. Connectivity Provisioning Documents 608 CPNP makes use of several flavors of Connectivity Provisioning 609 Documents (CPD). All these documents follow the CPP template 610 described in [I-D.boucadair-connectivity-provisioning-profile]. 612 o Requested Connectivity Provisioning Document: refers to the CPD 613 included by a CPNP client in a PROVISION request. 615 o Offered Connectivity Provisioning Document: This document is 616 included by a CPNP server in an OFFER message. This information 617 reflects the proposal of the server to accommodate all or a subset 618 of the clauses depicted in a CPD. A validity date is associated 619 with the offer. 621 o Agreed Connectivity Provisioning Document: If the client accepts 622 the offer, the offered CPD is included in an ACCEPT message. This 623 CPD is also included in an ACK message. 625 Figure 4 shows a typical CPNP transaction and the use of Connectivity 626 Provisioning Documents: 628 +------+ +------+ 629 |Client| |Server| 630 +------+ +------+ 631 |======PROVISION (Requested CPD)=====>| 632 |<============PROCESSING==============| 633 |<========OFFER (Offered CPD)=========| 634 |=============PROCESSING=============>| 635 |=========ACCEPT (Agreed CPD)========>| 636 |<=========ACK (Agreed CPD)===========| 638 Figure 4: Connectivity Provisioning Documents 640 8.9. Child Connectivity Provisioning Quotation Orders 642 If the server detects network resources from another network provider 643 need to be allocated in order to accommodate the requirements 644 described in a PQO (e.g., context of an inter-domain VPN service 645 where additional PE router resources need to be allocated), the 646 server may generate child PQOs to request the appropriate network 647 provisioning operations (see Figure 5). In such situation, the 648 server behaves as a CPNP client. The server must also associate the 649 parent order with its child PQOs. This is typically achieved by 650 locally adding the reference of the child PQO to the parent order. 652 +------+ +--------+ +--------+ 653 |Client| |Server A| |Server B| 654 +------+ +--------+ +--------+ 655 | | | 656 |=====PROVISION=====>| | 657 |<====PROCESSING=====| | 658 | |=====PROVISION=====>| 659 | |<====PROCESSING=====| 660 | |<=======OFFER=======| 661 | |=====PROCESSING====>| 662 | |=======ACCEPT======>| 663 | |<=======ACK=========| 664 |<=======OFFER=======| | 665 |=====PROCESSING====>| | 666 |=======ACCEPT======>| | 667 |<=======ACK=========| | 669 Figure 5: Example of Child Orders 671 8.10. State Management 673 Both the client and the server maintain repositories to store ongoing 674 orders. Contracted orders can be stored in the same repositories or 675 be stored in a dedicated one (e.g., Connectivity Provisioning 676 Agreements). Timestamps are also logged for any state change. 678 8.10.1. On The Client Side 680 The following lists the states which can be associated with a given 681 order on the client's side: 683 o Created: when the order has been created. It is not handled by 684 the client until the administrator allows to process it. 685 o AwaitingProcessing: when the administrator ordered to process an 686 order and this order is not handled yet. 687 o PQOSent: when the PQO has been sent to the server. 688 o ServerProcessing: when the server has confirmed the receipt of the 689 order. 690 o OfferReceived: when an offer has been received from the server. 691 o OfferProcessing: when a received offer is currently processed by 692 the client. 693 o AcceptSent: when the client confirmed the offer to the server. 694 o AcceptAck: when the offer is acknowledged by the server. 695 o Cancelled: when the order has failed or has been cancelled. 697 +------------------+ 698 | Created |-----------------+ 699 +------------------+ | 700 | | 701 v | 702 +------------------+ | 703 |AwaitingProcessing|----------------+| 704 +------------------+ || 705 | || 706 PROVISION || 707 v || 708 +------------------+ || 709 | PQOSent |---CANCEL------+|| 710 +------------------+ vvv 711 | +-----+ 712 PROCESSING | | 713 v | | 714 +------------------+ CANCEL | C | 715 | ServerProcessing |------------>| A | 716 +------------------+ FAIL | N | 717 | | C | 718 | | E | 720 OFFER | L | 721 | | L | 722 v | E | 723 +------------------+ | D | 724 | OfferReceived |---CANCEL--->| | 725 +------------------+ | | 726 | PROCESSING +-----+ 727 v ^^^ 728 +------------------+ ||| 729 | OfferProcessing |---DECLINE-----+|| 730 +------------------+ || 731 | ACCEPT || 732 v || 733 +------------------+ || 734 | AcceptSent |---CANCEL-------+| 735 +------------------+ | 736 | ACK | 737 v | 738 +------------------+ | 739 | AcceptAck |---WITHDRAW------+ 740 +------------------+ 742 Figure 6: CPNP Finite State Machine (Client Side) 744 8.10.2. On The Server Side 746 The following lists the states which can be associated with a given 747 order on the server's side: 749 o PQOReceived: when the connectivity provisioning quotation order 750 request has been received from the client. 751 o AwaitingProcessing: when the order request is being processed by 752 the server. An action from the server administrator may be 753 needed. 754 o OfferProposed: when the request has been successfully handled and 755 an offer has been sent to the requesting client. 756 o ProcessingReceived: when the server received a PROCESSING for an 757 offer sent to the client. 758 o AcceptReceived: when the server received a confirm for the offer 759 from the client. 760 o AcceptAck: when the server acknowledged the offer to the client. 761 o Cancelled: when the order request has failed or has been 762 cancelled. Associate resources must be released in the latter 763 case. 764 o ChildCreated: when a child PQO has been created because resources 765 from another network provider are needed. 766 o ChildPQOSent: when a child PQO has been sent to another server. 768 o ChildServerProcessing: when a child PQO is currently processed by 769 another server. 770 o ChildOfferReceived: when an offer has been received to a child 771 PQO. 772 o ChildOfferProcessing: when a received offer is currently 773 processed. 774 o ChildAcceptSent: when the child offer is confirmed to another 775 server. 776 o ChildAcceptAck: when the child offer is acknowledged by another 777 server. 779 +------------------+ 780 +---------------------| ChildCreated | 781 | +------------------+ 782 v | ^ 783 +------------------+ | | 784 | ChildPQOSent |----------------+| P 785 +------------------+ || R 786 | || O 787 PROVISION || V 788 v || I +--------------------+ 789 +---------------------+ CANCEL || S | PQOReceived | 790 |ChildServerProcessing|------------+|| I +--------------------+ 791 +---------------------+ FAIL vvv O | | 792 | +-----+ N CANCEL | 793 PROCESSING | |<---|-------+ PROCESSING 794 v | | | v 795 +------------------+ | | +------------------------+ 796 |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | 797 +------------------+ | A | +------------------------+ 798 | | N | ^ | OFFER 799 OFFER | C | | +------------------+ 800 | | E | ::= 921 ... 922 ::= 923 ... 924 ::= 925 926 927 928 929 930 931 932 933 934 935 936 937 938 ::= ... 939 ::= 940 941 943 9.1.9. Information Elements 945 An Information Element is an optional object which can be included in 946 a CPNP message. 948 9.1.9.1. Customer Description 950 The client may include administrative information such as: 952 o Name 953 o Contact Information 955 The format of this Information Element is as follows: 957 ::= 958 ::= [] 959 [ ...] 961 9.1.9.2. Provider Description 963 The server may include administrative information in an offer such 964 as: 966 o Name 967 o AS Number 968 o Contact Information 970 The format of this Information Element is as follows: 972 ::= [] 974 9.1.9.3. Negotiation Options 976 The client may include some negotiation options such as: 978 o Cost: the client may include an empty or a preferred COST 979 attribute to request the cost from the server. The server will 980 provide the cost information in the response. 981 o Setup purpose: A client may request to setup a connectivity only 982 for testing purposes during a limited period. The order can be 983 extended to become permanent if the client was satisfied during 984 the test period. This operation is achieved using UPDATE method. 986 Other negotiation options may be defined in the future. 988 The format of this Information Element is as follows: 990 ::= [][] 992 9.2. Operation Messages 994 This section specifies the RBNF format of CPNP operation messages. 996 9.2.1. PROVISION 998 The format of PROVISION message is shown below: 1000 ::= 1001 1002 1003 1004 [] 1005 1006 [...] 1008 A PROVISION message must include an order identifier which is 1009 generated by the client. Because several orders can be issued to 1010 several servers, the PROVISION message must also include a 1011 Transaction-ID. The message may include an EXPECTED_RESPONSE_DATE 1012 which indicates by when the client is expecting to receive an offer 1013 from the server. PROVISION message must also include a requested 1014 connectivity provisioning document. 1016 When the client sends the PROVISION message to the server, the state 1017 of the order changes to "PQOSent". 1019 9.2.2. PROCESSING 1021 The format of PROCESSING Message is shown below: 1023 ::= 1024 1025 1026 1027 1028 [] 1030 Upon receipt of a PROVISION message, the server proceeds with parsing 1031 rules (see Section 10). If no error is encountered, the server 1032 generates a PROCESSING response to the client to indicate the PQO has 1033 been received and it is being processed. The server must generate an 1034 order identifier which identifies the order in its local order 1035 repository. The server MUST copy the content of 1036 CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed in 1037 the PROVISION message. The server may include an EXPECTED_OFFER_DATE 1038 by when it expects to make an offer to the client. 1040 Upon receipt of a PROCESSING message, the client verifies whether it 1041 has issued a PQO to that server and which contains the 1042 CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID. If no such PQO is 1043 found, the PROCESSING message is silently ignored. If a PQO is 1044 found, the client may check if it accepts the EXPECTED_OFFER_DATE and 1045 then, it changes to state of the order to "ServerProcessing". 1047 9.2.3. OFFER 1049 The format of OFFER message is shown below: 1051 ::= 1052 1053 1054 1055 1056 1057 1058 1059 [...] 1061 The server answers with an OFFER message to a PROVISION request 1062 received from the client. The offer will be considered as rejected 1063 by the client if no confirmation (ACCEPT message sent by the client) 1064 is received by the server before the expiration of the validity date. 1066 9.2.4. ACCEPT 1068 The format of ACCEPT message is shown below: 1070 ::= 1071 1072 1073 1074 1075 1076 1077 [...] 1079 This message is used by a client to confirm the acceptance of an 1080 offer received from a server. The fields of this message are copied 1081 from the received OFFER message. 1083 9.2.5. ACK 1085 The format of ACK message is shown below: 1087 ::= 1088 1089 1090 1091 1092 1093 [...] 1095 This message is issued by the server to close a CPNP transaction. In 1096 particular, this message is sent as a response to an ACCEPT, 1097 WITHDRAW, DECLINE, or CANCEL message. The ACK message must include 1098 the copy of the Connectivity Provisioning Document as stored by the 1099 server, in particular: 1101 o A copy of the requested/offered CPD is included by the server if 1102 it successfully handled a CANCEL message. 1103 o A copy of the updated CPD is included by the server if it 1104 successfully handled an UPDATE message. 1105 o A copy of the offered CPD is included by the server if it 1106 successfully handled an ACCEPT message in the context of a 1107 PROVISION transaction. 1108 o An empty CPD is included by the server if it successfully handled 1109 a DECLINE message. 1111 9.2.6. DECLINE 1113 The format of DECLINE message is shown below: 1115 ::= 1116 1117 1118 1119 1121 The client can issue a DECLINE message to reject an offer. 1122 CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER and 1123 TRANSACTION_ID are used by the server as keys to find the 1124 corresponding order. If an order matches, the server changes the 1125 state of this order to "Cancelled" and then returns an ACK with a 1126 copy of the requested CPD to the requesting client. 1128 If no order is found, the server returns a FAIL message to the 1129 requesting client. 1131 A flow example is shown in Figure 8. 1133 +------+ +------+ 1134 |Client| |Server| 1135 +------+ +------+ 1136 |======PROVISION (Requested CPD)=====>| 1137 |<============PROCESSING==============| 1138 |<========OFFER (Offered CPD)=========| 1139 |=============PROCESSING=============>| 1140 |===============DECLINE==============>| 1141 |<================ACK=================| 1142 Figure 8: DECLINE Flow Example 1144 9.2.7. CANCEL 1146 The format of CANCEL message is shown below: 1148 ::= 1149 1150 1151 1152 [] 1154 The client can issue a CANCEL message at any stage during the CPNP 1155 negotiation process. CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID 1156 are used by the server as keys to find the corresponding order. If 1157 an order matches, the server changes the state of this order to 1158 "Cancelled" and then returns an ACK with a copy of the requested CPD 1159 to the requesting client. 1161 If no order is found, the server returns a FAIL message to the 1162 requesting client. 1164 9.2.8. WITHDRAW 1166 The format of WITHDRAW message is shown below: 1168 ::= 1169 1170 1171 1172 1173 1174 [] 1175 [...] 1177 This message is used to withdraw an offer already subscribed by the 1178 Customer. Figure 9 shows a typical usage of this message. 1180 +------+ +------+ 1181 |Client| |Server| 1182 +------+ +------+ 1183 |===========WITHDRAW (CPD)===========>| 1184 |<============PROCESSING==============| 1185 |<==========ACK (Empty CPD)===========| 1187 Figure 9: WITHDRAW Flow Example 1189 The CPNP must include the same CUSTOMER_ORDER_IDENTIFIER, 1190 PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the 1191 order. 1193 Upon receipt of a WITHDRAW message, the server checks whether an 1194 order matching the request is found. If an order is found, the state 1195 of the order is changed to "Cancelled" and an ACK message including 1196 an Empty CPD is returned to the requesting client. If no order is 1197 found, the server returns a FAIL message to the requesting client. 1199 9.2.9. UPDATE 1201 The format of UPDATE message is shown below: 1203 ::= 1204 1205 1206 1207 1208 1209 1210 1211 [...] 1213 This message is sent by the CPNP client to update an existing 1214 connectivity provisioning agreement. The CPNP must include the same 1215 CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE as 1216 those used when creating the order. The CPNP client includes a new 1217 CPD which integrates the requested modifications. A new 1218 Transaction_ID must be assigned by the client. 1220 Upon receipt of an UPDATE message, the server checks whether an 1221 order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER, 1222 PROVIDER_ORDER_IDENTIFIER, and NONCE. 1224 o If no order is found, the CPNP server generates a FAIL error with 1225 the appropriate error code. 1226 o If an order is found, the server checks whether it can honor the 1227 request: 1229 * A FAIL message is sent to the client if the server cannot honor 1230 the request. The client may initiate a new PQO negotiation 1231 cycle. 1233 * An OFFER message including the updated connectivity 1234 provisioning document is sent to the client. For example, the 1235 server maintains an order for provisioning a VPN service that 1236 connects sites A, B and C. If the client sends an UPDATE 1237 message to remove site C, only sites A and B will be included 1238 in the OFFER sent by the server to the requesting client. 1240 A flow chart that illustrates the use of UPDATE operation is shown in 1241 Figure 10. 1243 +------+ +------+ 1244 |Client| |Server| 1245 +------+ +------+ 1246 |=========UPDATE (Diff CPD)==========>| 1247 |<============PROCESSING==============| 1248 |<========OFFER (Updated CPD)=========| 1249 |=============PROCESSING=============>| 1250 |=========ACCEPT (Updated CPD)=======>| 1251 |<=========ACK (Updated CPD)==========| 1253 Figure 10: UPDATE Flow Example 1255 9.2.10. FAIL 1257 The format of FAIL message is shown below: 1259 ::= 1260 1261 1262 1263 1264 1266 This message is sent in the following cases: 1268 o The server can not honor an order received from the client (i.e., 1269 received in a PROVISION or UPDATE request). 1270 o The server encounters an error when processing a CPNP request 1271 received from the client. 1273 The status code indicates the error code. The following codes are 1274 currently supported; other codes will be defined in future versions 1275 of the document: 1277 o 1 (Validation Error): The message can not be validated (see 1278 Section 10). 1280 o 2 (Authentication Required): the request cannot be handled because 1281 authentication is required. 1282 o 3 (Administratively prohibited): the request can not be handled 1283 because of administrative policies. 1284 o 4 (Out of Resources): the request can not be honored because there 1285 is not enough capacity. 1286 o 5 (Network Presence): the request can not be honored because there 1287 is no network presence. 1289 10. Message Validation 1291 Both client and server proceed with CPNP message validation. The 1292 following tables summarize the validation checks to be followed. 1294 10.1. On The Client Side 1296 Operation Validation Checks 1297 --------------- ----------------------------------------------------- 1298 PROCESSING {Source IP address, source port, destination IP 1299 address, destination port, Transaction-ID, Customer 1300 Order Identifier} must match an existing PQO with a 1301 state set to "PQOSent". 1302 OFFER {Source IP address, source port, destination IP 1303 address, destination port, Transaction-ID, Customer 1304 Order Identifier} must match an existing order with 1305 state set to "PQOSent" or {Source IP address, source 1306 port, destination IP address, destination port, 1307 Transaction-ID, Customer Order Identifier, Provider 1308 Order Identifier} must match an existing order with a 1309 state set to "ServerProcessing". 1310 ACK (PROVISION {Source IP address, source port, destination IP 1311 Transaction) address, destination port, Transaction-ID, Customer 1312 Order Identifier, Provider Order Identifier, Offered 1313 Connectivity Provisioning Order} must match an order 1314 with a state set to "AcceptSent". 1315 ACK (UPDATE {Source IP address, source port, destination IP 1316 Transaction) address, destination port, Transaction-ID, Customer 1317 Order Identifier, Provider Order Identifier, Updated 1318 Connectivity Provisioning Order} must match an order 1319 with a state set to "AcceptSent". 1320 ACK (WITHDRAW {Source IP address, source port, destination IP 1321 Transaction) address, destination port, Transaction-ID, Customer 1322 Order Identifier, Provider Order Identifier, Empty 1323 Connectivity Provisioning Order} must match an order 1324 with a state set to "Cancelled". 1326 10.2. On The Server Side 1328 Method Validation Checks 1329 ----------- --------------------------------------------------------- 1330 PROVISION The source IP address passes existing access filters (if 1331 any). 1332 ACCEPT {Source IP address, source port, destination IP address, 1333 destination port, Transaction-ID, Customer Order 1334 Identifier, Provider Order Identifier, Nonce, Offered 1335 Connectivity Provisioning Order} must match an order with 1336 state set to "OfferProposed" or "ProcessngReceived". 1337 DECLINE {Source IP address, source port, destination IP address, 1338 destination port, Transaction-ID, Customer Order 1339 Identifier, Provider Order Identifier, Nonce} must match 1340 an order with state set to "OfferProposed" or 1341 "ProcessngReceived". 1342 UPDATE The source IP address passes existing access filters (if 1343 any) and {Customer Order Identifier, Provider Order 1344 Identifier, Nonce} must match an existing order with 1345 state "Completed". 1346 WITHDRAW The source IP address passes existing access filters (if 1347 any) and {Customer Order Identifier, Provider Order 1348 Identifier, Nonce} must match an existing order with 1349 state "Completed". 1351 11. Theory of Operation 1353 Both CPNP client and server proceeds to message validation checks as 1354 specified in Section 10. 1356 11.1. Client Behavior 1358 11.1.1. Order Negotiation Cycle 1360 To place a connectivity provisioning quotation order, the client 1361 initiates first a local order object identified by a unique 1362 identifier assigned by the client. The state of the quotation order 1363 is set to "Created". The client then generates a PROVISION request 1364 which includes the assigned identifier, possibly an Expected Response 1365 Date, a Transaction-ID and a Requested Connectivity Provisioning 1366 Document. The client may include additional Information Elements 1367 such as Negotiation Options. 1369 The client may be configured to not enforce negotiation checks on 1370 EXPECTED_OFFER_DATE; if so no EXPECTED_RESP_TIMER attribute (or 1371 EXPECTED_RESP_TIMER set to infinite) should be included in the 1372 quotation order. 1374 Once the request is sent to the server, the state of the request is 1375 set to "PQOSent" and a timer, if a response time is included in the 1376 quotation order, is set to the expiration date as included in the 1377 PROVISION request. The client also maintains a copy of the extended 1378 transport session details used to generate the PROVISION request. 1379 The CPNP client must listen on the same port number that it used to 1380 send the PROVISION request. 1382 If no answer is received from the server before the retransmission 1383 timer expires (i.e., RETRANS_TIMER), the client proceeds to 1384 retransmission until maximum retry is reached (i.e., 3 times). 1386 If a FAIL message is received, the client may decide to issue another 1387 (corrected) request towards the same server, cancel the local order, 1388 or contact another server. The behavior of the client depends on the 1389 error code returned by the server in the FAIL message. 1391 If a PROCESSING message matching the CPNP transport session is 1392 received, the client updates the CPNP session with the 1393 PROVIDER_ORDER_IDENTIFIER information. If the client does not accept 1394 the expected offer date that may have been indicated in the 1395 PROCESSING message, the client may decide to cancel the quotation 1396 order. If the client accepts the EXPECTED_OFFER_DATE, it changes the 1397 state of the order to "ServerProcessing" and sets a timer to the 1398 value of EXPECTED_OFFER_DATE. If no offer is made before the timer 1399 expires, the client changes the state of the order to "Cancelled". 1401 If an OFFER message matching the extended CPNP session is received, 1402 the client checks if a PROCESSING message having the same 1403 PROVIDER_ORDER_IDENTIFIER has been received from the server. If a 1404 PROCESSING message was already received for the same order but the 1405 PROVIDER_ORDER_IDENTIFIER does not match the identifier included in 1406 the OFFER message, the client ignores silently the message. If a 1407 PROCESSING message having the same PROVIDER_ORDER_IDENTIFIER was 1408 already received and matches the CPNP transaction identifier, the 1409 client changes the state of the order to "OfferReceived" and sets a 1410 timer to the value of VALIDITY_DATE indicated in the OFFER message. 1412 If an offer is received from the server (i.e., as documented in an 1413 OFFER message), the client may accept or reject the offer. The 1414 client accepts the offer by generating an ACCEPT message which 1415 confirms that the client agrees to subscribe to the offer documented 1416 in the OFFER message; the state of the order is passed to 1417 "AcceptSent". The transaction is terminated if an ACK message is 1418 received from the server. If no ACK is received from the server, the 1419 client proceeds with the re-transmission of the ACCEPT message. 1421 The client may also decide to reject the offer by sending a DECLINE 1422 message. The state of the order is set by the client to "Cancelled". 1423 If an offer is not acceptable by the client, the client may decide to 1424 contact a new server or submit another order to the same server. 1425 Guidelines to issue an updated order or terminate the negotiation are 1426 specific to the client. 1428 11.1.2. Order Withdrawal Cycle 1430 A client may withdraw a completed order. This is achieved by issuing 1431 a WITHDRAW message. This message must include Customer Order 1432 Identifier, Provider Identifier and Nonce returned during the order 1433 negotiation cycle specified in Section 11.1.1. 1435 If no ACK is received from the server, the client proceeds with the 1436 re-transmission of the message. 1438 11.1.3. Order Update Cycle 1440 A client may update a completed order. This is achieved by issuing 1441 an UPDATE message. This message must include Customer Order 1442 Identifier, Provider Order Identifier and Nonce returned during the 1443 order negotiation cycle specified in Section 11.1.1. The client must 1444 include in the UPDATE message an updated CPD with the requested 1445 changes. 1447 Subsequent messages exchange is similar to what is documented in 1448 Section 11.1.1. 1450 11.2. Server Behavior 1452 11.2.1. Order Processing 1454 Upon receipt of a PROVISION message from a client, the server sets a 1455 CPNP session, stores Transaction-ID and generates a Provider Order 1456 Identifier. Once preliminary validation checks are completed ( 1457 Section 10), the server may return a PROCESSING message to notify the 1458 client the quotation order is received and it is under processing; 1459 the server may include an expected offer date to notify the client by 1460 when an offer will be proposed. An order with state 1461 "AwaitingProcessing" is created by the server. The server runs its 1462 decision-making process to decide which offer it can make to honor 1463 the received order. The offer should be made before the expected 1464 offer date expires. 1466 If the server cannot honor the request, it sends backs a FAIL message 1467 with the appropriate error code. 1469 If the server can honor the request, it creates an OFFER message. 1470 The server must indicate the Transaction-ID, Customer Order 1471 Identifier as indicated in the PROVISION message, and the Provider 1472 Order Identifier generated for this order. The server must also 1473 include Nonce and the offered Connectivity Provisioning Document. 1474 The server includes an offer validity date as well. Once sent to the 1475 client, the server changes the state of the order to "OfferSent" and 1476 a timer set to the validity date is initiated. 1478 If the server determines that additional network resources from 1479 another network provider are needed to accommodate a quotation order, 1480 it will create child PQO(s) and will behave as a CPNP client to 1481 negotiate child PQO(s) with possible partnering providers (see Figure 1482 5). 1484 If no PROCESSING, ACCEPT or DECLINE message is received before the 1485 expiry of the RETRANS_TIMER, the server re-sends the same offer to 1486 the client. This procedure is repeated until maximum retry is 1487 reached. 1489 If an ACCEPT message is received before the offered validity date 1490 expires, the server proceeds with validation checks as specified in 1491 Section 10. The state of the corresponding order is passed to 1492 "AcceptReceived". The server sends back an ACK message to terminate 1493 the order processing cycle. 1495 If a CANCEL/DECLINE message is received, the server proceeds with the 1496 cancellation of the order. The state of the order is then passed to 1497 "Cancelled". 1499 11.2.2. Order Withdrawal 1501 A client may withdraw a completed order by issuing a WITHDRAW 1502 message. Upon receipt of a WITHDRAW message, the server proceeds 1503 with the validation checks, as specified in Section 10. 1505 o If the checks fail, a FAIL message is sent back to the client with 1506 the appropriate error code. 1507 o If the checks succeed, the server clears the clauses of the 1508 Connectivity Provisioning Document, changes the state of the order 1509 to "Cancelled", and sends back an ACK message with an Empty 1510 Connectivity Provisioning Document. 1512 11.2.3. Order Update 1514 A client may update an order by issuing an UPDATE message. Upon 1515 receipt of an UPDATE message, the server proceeds with the validation 1516 checks as specified in Section 10. 1518 o If the checks fail, a FAIL message is sent back to the client with 1519 the appropriate error code. 1520 o Subsequent messages exchange is similar to what is specified in 1521 Section 11.1.1. The server should generate a new Nonce value to 1522 be included in the offer made to the client. 1524 12. Operational Guidelines 1526 12.1. Logging On The CPNP Server 1528 The CPNP server SHOULD be configurable to log various events and 1529 associated information. Such information includes: 1531 o Client's IP Address 1532 o Any event change (e.g., new quotation order, offer sent, order 1533 confirm, order cancellation, order withdraw, etc.) 1534 o Timestamp 1536 12.2. Business Guidelines & Objectives 1538 The CPNP server can operate in the following modes: 1540 1. Fully automated mode: The CPNP server is provisioned with a set 1541 of business guidelines and objectives that will be used as an 1542 input to the decision-making process. The CPNP server will 1543 service received orders that falls into these business 1544 guidelines; otherwise requests will be escalated to an 1545 administrator that will formally validate/invalidate an order 1546 request. The set of policies to be configured to the CPNP server 1547 are specific to each administrative entity managing a CPNP 1548 server. 1549 2. Administrative-based mode: This mode assumes some or all CPNP 1550 server' operations are subject to a formal administrative 1551 validation. CPNP events will trigger appropriate validation 1552 requests that will be forwarded to the contact person(s) or 1553 department which is responsible for validating the orders. 1554 Administrative validation messages are relayed using another 1555 protocol (e.g., SMTP) or a dedicated tool. 1557 Business guidelines are local to each administrative entity. How 1558 validation requests are presented to an administrator are out of 1559 scope of this document; each administrative entity may decide the 1560 appropriate mechanism to enable for that purpose. 1562 13. Security Considerations 1564 Means to defend the server against denial-of-service attacks MUST be 1565 enabled. For example, access control lists (ACLs) can be enforced on 1566 the client, the server or the network in between, to allow a trusted 1567 client to communicate with a trusted server. 1569 The client and the server SHOULD be mutually authenticated. Out of 1570 band mechanisms can be used instead of integrating them into CPNP. 1572 The client MUST silently discard CPNP responses received from unknown 1573 CPNP servers. The use of a randomly generated Transaction-ID makes 1574 it hard to forge a response from a server with a spoofed IP address 1575 belonging the legitimate CPNP server. Furthermore, CPNP messages 1576 from the server must also include correct identifiers of the orders. 1577 Two order identifiers are used: one generated by the client and the 1578 second one is generated by the server. 1580 Only authorized clients MUST be able to modify existing CPNP orders. 1581 The use of a randomly generated Nonce by the server makes it hard to 1582 modify an order on behalf of a third-party. 1584 14. IANA Considerations 1586 Authors of the document request IANA to assign a UDP port for CPNP. 1588 A registry for CPNP methods should be created. The following codes 1589 are reserved: 1591 1: PROVISION 1592 2: PROCESSING 1593 3: OFFER 1594 4: ACCEPT 1595 5: DECLINE 1596 6: ACK 1597 7: CANCEL 1598 8: WITHDRAW 1599 9: UPDATE 1600 10: FAIL 1602 A register for CPNP errors should be created. The following codes 1603 are reserved: 1605 1: Message Validation Error 1606 2: Authentication Required 1607 3: Administratively prohibited 1608 4: Out of Resources 1609 5: Network Presence Error 1611 15. Acknowledgements 1613 Thanks to Diego R. Lopez for his comments. 1615 16. References 1617 16.1. Normative References 1619 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1620 and Support", STD 3, RFC 1123, October 1989. 1622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1623 Requirement Levels", BCP 14, RFC 2119, March 1997. 1625 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1626 Requirements for Security", BCP 106, RFC 4086, June 2005. 1628 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1629 Used to Form Encoding Rules in Various Routing Protocol 1630 Specifications", RFC 5511, April 2009. 1632 16.2. Informative References 1634 [I-D.boucadair-connectivity-provisioning-profile] 1635 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 1636 Connectivity Provisioning Profile", draft-boucadair- 1637 connectivity-provisioning-profile-02 (work in progress), 1638 September 2012. 1640 [I-D.sin-sdnrg-sdn-approach] 1641 Boucadair, M. and C. Jacquenet, "Software-Defined 1642 Networking: A Perspective From Within A Service Provider", 1643 draft-sin-sdnrg-sdn-approach-04 (work in progress), 1644 October 2013. 1646 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1647 specifying the location of services (DNS SRV)", RFC 2782, 1648 February 2000. 1650 [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and 1651 A. Gonguet, "Framework for Layer 3 Virtual Private 1652 Networks (L3VPN) Operations and Management", RFC 4176, 1653 October 2005. 1655 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1656 Security Version 1.2", RFC 6347, January 2012. 1658 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1659 K., and G. Watson, "Use Cases for Content Delivery Network 1660 Interconnection", RFC 6770, November 2012. 1662 Authors' Addresses 1664 Mohamed Boucadair 1665 France Telecom 1666 Rennes 35000 1667 France 1669 Email: mohamed.boucadair@orange.com 1671 Christian Jacquenet 1672 France Telecom 1673 Rennes 35000 1674 France 1676 Email: christian.jacquenet@orange.com