• COPS-SLS relies upon the COPS usage for policy provisioning (COPS-PR) [RFC 3084], which is a Historic RFC.
• DSNP is tightly designed with one specific service in mind (QoS) and does not make any distinction between a quotation phase and the actual service-ordering phase.

Customer:

Is a business role that denotes an entity that is involved in the definition and the possible negotiation of an order, including a Connectivity Provisioning Agreement, with a Provider. A connectivity provisioning document is captured in a dedicated CPP template-based document, which may specify (among other information) the sites to be connected, border nodes, outsourced operations (e.g., routing, traffic steering).

The right to invoke the subscribed service may be delegated by the Customer to third-party end users or brokering services.

A Customer can be a Service Provider, an application owner, an enterprise, a user, etc.

Network Provider (or Provider):

Owns and administers one or many transport domain(s) (typically Autonomous Systems (ASes)) composed of (IP) switching and transmission resources (e.g., routing, switching, forwarding, etc.). Network Providers are responsible for delivering and operating connectivity services (e.g., offering global or restricted reachability at specific rates). Offered connectivity services may not necessarily be restricted to IP.

The policies to be enforced by the connectivity service delivery components can be derived from the technology-specific clauses that might be included in agreements with the Customers. If no such clauses are included in the agreement, the mapping between the connectivity requirements and the underlying technology-specific policies to be enforced is deployment specific.

Quotation Order:

Denotes a request made by the Customer to the Provider that includes a set of requirements. The Customer may express its service-specific requirements by assigning (strictly or loosely defined) values to the information items included in the commonly understood template (e.g., CPP template) describing the offered service. These requirements constitute the parameters to be mutually agreed upon.

Offer:

Refers to a response made by the Provider to a Customer's quotation order that describes the ability of the Provider to satisfy the order at the time of its receipt. Offers reflect the capability of the Provider in accommodating received Customer orders beyond monolithic 'yes/no' answers.

An offer may fully or partially meet the requirements of the corresponding order. In the latter case, it may include alternative suggestions that the Customer may take into account by issuing a new order.

Agreement:

Refers to an order placed by the Customer and accepted by the Provider. It signals the successful conclusion of a negotiation cycle.

CPNP client (or client):

Denotes a software instance that sends CPNP requests and receives CPNP responses. The current operations that can be performed by a CPNP client are listed below:

1. Create a quotation order (Section 9.2.1).
2. Cancel an ongoing quotation order under negotiation (Section 9.2.7).
3. Accept an offer made by a server (Section 9.2.4).
4. Withdraw an agreement (Section 9.2.8).
5. Update an agreement (Section 9.2.9).

CPNP server (or server):

Denotes a software instance that receives CPNP requests and sends back CPNP responses accordingly. The CPNP server is responsible for the following operations:

1. Process a quotation order (Section 9.2.2).
2. Make an offer (Section 9.2.3).
3. Cancel an ongoing quotation order (Section 11.2.3).
4. Process an order withdrawal (Section 11.2.3).

Frozen model:

The Customer cannot actually negotiate the parameters of the service(s) offered by a Provider. After consulting the Provider's service portfolio, the Customer selects the service offer to which he or she wants to subscribe and places an order to the Provider. Order handling is quite simple on the Provider side because the service is not customized per Customer's requirements, but rather designed to address a Customer base that shares the same requirements (i.e., these Customers share the same Connectivity Provisioning Profile). This mode can be implemented using existing tools such as [RFC 8309].

Negotiation-based model:

Unlike the frozen model, the Customer documents his/her requirements in a request for a quotation, which is then sent to one or several Providers. Solicited Providers check whether they can address these requirements or not, and get back to the Customer accordingly, possibly with an offer that may not exactly match the Customer's requirements (e.g., a 100 Mbps connection cannot be provisioned given the amount of available resources, but an 80 Mbps connection can be provided). A negotiation between the Customer and the Provider(s) then follows until both parties reach an agreement (or do not).

• Network provisioning (including order activation, Network Planning, etc.)
• Authentication, authorization, and accounting (AAA)
• Network and service management (performance measurement and assessment, fault detection, etc.)
• Sales-related functional blocks (e.g., billing, invoice validation)
• Network impact analysis

1. [RFC 4176] introduces the Layer 3 VPN (L3VPN) Service Order Management functional block, which is responsible for managing the requests initiated by the Customers and tracks the status of the completion of the related operations. CPNP can be used between the Customer and the Provider to negotiate L3VPN service parameters. A CPNP server could therefore be part of the L3VPN Service Order Management functional block discussed in [RFC 4176]. A L3VPN Service YANG data model (L3SM) is defined in [RFC 8299]. Once an agreement is reached, the service can be provisioned using, e.g., the L3VPN Network YANG data model specified in [L3VPN-NETWORK-YANG]. Likewise, a CPNP server could be part of the Layer 2 VPN (L2VPN) Service Order Management functional block. A YANG data model for L2VPN service delivery is defined in [RFC 8466]. Once an agreement is reached, the L2VPN service can be provisioned using, e.g., the L2VPN Network YANG data model specified in [L2VPN-NETWORK-YANG].
2. CPNP can be used between two adjacent domains to deliver IP interconnection services (e.g., enable, update, disconnect). For example, two Autonomous Systems (ASes) can be connected via several interconnection points. CPNP can be used between these ASes to upgrade existing links, request additional resources, provision a new interconnection point, etc. See, for example, the framework documented in [ETICS].
3. An integrated Provider can use CPNP to rationalize connectivity provisioning needs related to its service portfolio. A CPNP server function is used by network operations teams. A CPNP interface to trigger CPNP negotiation cycles is exposed to service management teams.
4. Service Providers can use CPNP to initiate connectivity provisioning requests towards a number of Network Providers so as to optimize the cost of delivering their services. Although multiple CPNP ordering cycles can be initiated by a Service Provider towards multiple Network Providers, a subset of these orders may actually be put into effect. For example, a cloud Service Provider can use CPNP to request more resources from Network Providers.
5. CPNP can also be used in the context of network slicing [NETSLICES-ARCH] to request network resources together with a set of requirements that need to be satisfied by the Provider. Such requirements are not restricted to basic IP forwarding capabilities, but may also include a characterization of a set of service functions that may be invoked. For the network slicing case, the instances of a CPP template could be derived from the network slice template documented in [TEAS-SLICE-NBI].
6. CPNP can be used in Machine-to-Machine (M2M) environments to dynamically subscribe to M2M services (e.g., access data retrieved by a set of sensors, extend sensor coverage, etc.). Also, Internet of Things (IoT) [RFC 6574] domains may rely on CPNP to enable dynamic access to data produced by involved objects, according to their specific policies, to various external stakeholders such as data analytics and business intelligence companies. Direct CPNP-based interactions between IoT domains and interested parties enable open access to diverse sets of data across the Internet, e.g., from multiple types of sensors, user groups, and/or geographical areas.
7. CPNP can be used in the context of Interface to Network Security Functions (I2NSF) [RFC 8329] to capture the Customer-driven policies to be enforced by a set of Network Security Functions.
8. A Provider offering cloud services can expose a CPNP interface to allow Customers to dynamically negotiate typical data center resources, such as additional storage, processing and networking resources, enhanced security filters, etc. Cloud computing Providers typically structure their computation service offerings by bundling CPU, RAM, and storage units as quotas, instances, or flavors that can be consumed in an ephemeral or temporal fashion during the lifetime of the required function. A similar approach is followed by CPNP (see for example, Section 9.2.11).
9. In the inter-cloud context (also called cloud of clouds or cloud federation), CPNP can be used to reserve computing and networking resources hosted by various cloud infrastructures.
10. CDN Providers can use CPNP to extend their footprint by interconnecting their respective CDN infrastructures [RFC 6770] (see Figure 1).

           ,--,--,--.             ,--,--,--.
        ,-'          `-.       ,-'          `-.
       (CDN Provider 'A')=====(CDN Provider 'B')
        `-.  (CDN-A) ,-'       `-. (CDN-B)  ,-'
          `--'--'--'             `--'--'--'
    

    Figure 1: CDN Interconnection
11. Mapping Service Providers (MSPs) [RFC 7215] can use CPNP to enrich their mapping database by interconnecting their mapping system (see Figure 2). This interconnection allows the relaxation of the constraints on PxTR (Proxy Ingress/Egress Tunnel Router) in favour of native LISP (Locator/ID Separation Protocol) forwarding [RFC 6830]. Also, it prevents the fragmentation of the LISP mapping database. A framework is described in [LISP-MS-DISCOVERY].

           ,--,--,--.             ,--,--,--.
        ,-'          `-.       ,-'          `-.
       (Mapping System 'A')===(Mapping System 'B')
        `-.          ,-'       `-.           ,-'
           `--'--'--'             `--'--'--'
    

    Figure 2: LISP Mapping System Interconnect
12. CPNP may also be used between SDN (Software-Defined Networking) controllers in contexts where Cooperating Layered Architecture for Software-Defined Networking (CLAS) is enabled [RFC 8597].

• The Customer deploys a CPNP client while one or several CPNP servers are deployed by the Provider. A CPNP client can discover its CPNP servers using a variety of means (static, dynamic, etc.).
• The Customer does not enable any CPNP client. The Provider maintains a Customer Order Management portal. The Customer can initiate connectivity provisioning quotation orders via the portal; appropriate CPNP messages are then generated and sent to the relevant CPNP server. In this model, both the CPNP client and CPNP server are under the responsibility of the same administrative entity (i.e., Network Provider).

1. The CPNP client specifies its service requirements in a Provisioning Quotation Order (PQO). The order may include strictly or loosely defined values in the clauses describing service provisioning characteristics.
2. The CPNP server declines the PQO, or makes an offer to address the requirements of the PQO, or suggests a counterproposal that partially addresses the requirements of the PQO in case specific requirements cannot be accommodated.
3. The CPNP client either accepts or declines the offer. The acceptance of the offer by the CPNP client implies a call for agreement and, thus, the agreement between both parties and the conclusion of the negotiation.

+------+                     +------+ 
|Client|                     |Server| 
+------+                     +------+ 
   |=====Requested Service=====>|  
   |<=====Offered Service=======|  
   |=====Accepted Service======>| 

+------+                  +------+ +------+                  +------+
|Client|                  |Server| |Client|                  |Server|
+------+                  +------+ +------+                  +------+
   |=====Quotation Order=====>|       |=====Quotation Order=====>|
   |<==========Offer==========|       |<==========Offer==========|
   |===========Accept========>|       |==========Decline========>|

  1-Step Successful Negotiation         1-Step Failed Negotiation
            Cycle                               Cycle

+------+                  +------+ +------+                  +------+
|Client|                  |Server| |Client|                  |Server|
+------+                  +------+ +------+                  +------+
   |===Quotation Order(a)====>|       |===Quotation Order(i)====>|
   |<==========Offer==========|       |<==========Offer==========|   
   |==========Decline========>|       |==========Decline========>|
   |===Quotation Order(b)====>|       |===Quotation Order(j)====>|
   |<==========Offer==========|       |<==========Offer==========|   
   |===========Accept========>|       |==========Decline========>|
                                      |===Quotation Order(k)====>|
                                      |<==========Offer==========| 
                                      |==========Decline========>|
                                      |===Quotation Order(l)====>|
                                      |<==Fail to make an offer==| 

    N-Step Negotiation Cycle:         N-Step Negotiation Cycle:
      Successful Negotiation              Failed Negotiation

• Check whether a Customer is entitled to initiate a provisioning quotation request.
• Check whether a Customer is entitled to cancel an ongoing order.
• Check whether administrative data (e.g., billing-related information) have been verified before the processing of the request starts.
• Check whether network capacity is available or additional capacity is required.
• Receive guidelines from network design and sales blocks (e.g., pricing, network usage levels, thresholds associated with the number of CPP templates that can be processed over a given period of time as a function of the nature of the service to be delivered, etc.).
• Transfer completed orders to network provisioning blocks (referred to as "Network Provisioning Manager" in Figure 5). For example, the outcome of CPNP may be passed to modules such as Application-Based Network Operations (ABNO) [RFC 7491] or network controllers. These controllers will use protocols such as NETCONF [RFC 6241] to interact with the appropriate network nodes and functions for the sake of proper service activation and delivery.

       . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
       .Business & Administrative Management                   .      
       .+------------------------++---------------------------+.  
       .| Business Guidelines    ||    Billing & Charging     |.
       .+-----------+------------++-----------+---------------+.
       .            |                         |                .
       .            +-------------------+     |                .
       . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
       . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
       .Order Handling Management       |     |                .
       . +-------------------+  +-------+-----+--------------+ .
       . |Network Topology DB+--+        CPNP Server         | .
       . +-------------------+  +-+---+---+---+---+-----+----+ . 
       .                          |   |   |   |   |     |      .
       . +------------------------+-+ |   |   |   |     |      .
       . |   Network Dimensioning   | |   |   |   |     |      .
       . |        & Planning        | |   |   |   |     |      .
       . +--------------------------+ |   |   |   |     |      .
       . +----------------------------+-+ |   |   | +---+----+ .
       . |                              | |   |   | |   AAA  | .
       . |   Network       +------------+ |   |   | +--------+ .
       . |  Resource       | +------------+-+ | +-+----------+ .
       . |  Management     | |   Customer   | | |   Orders   | .
       . |                 | |   Profiles   | | | Repository | .
       . +-----------------+ +--------------+ | +------------+ .
       . . . . . . . . . . . . . . . . . . . .|. . . . . . . . .
       +--------------------------------------+----------------+
       |             Network Provisioning Manager              |   
       +-------------------------------------------------------+   

Fully automated mode:

This mode does not require any action from the administrator when receiving a request for a service. The server can execute its decision-making process related to the orders received and can generate corresponding offers.

Administrative validation checking:

Some or all of the server's operations are subject to administrative validation procedures. This mode requires an action from the administrator for every request received. To that aim, the CPNP methods that can be automatically handled by the server (or are subject to one or several validation administrative checks) can be configured on the server.

• Transport session (typically, the IP address of the CPNP client, the client's port number, the IP address of the CPNP server, and the CPNP server's port number).
• Incremented sequence number (Section 11.3).
• Customer agreement identifier: This is a unique identifier assigned to the order under negotiation by the CPNP client (Section 9.1.1). This identifier is also used by the client to identify the agreement that will result from a successful negotiation.
• Provider agreement identifier: This is a unique identifier assigned to the order under negotiation by the CPNP server (Section 9.1.2). This identifier is also used by the server to identify the agreement that will result from a successful negotiation.
• Transaction-ID (Section 8.4).

This operation is used by the client to initiate a PQO. Upon receipt of a QUOTATION request, the server may respond with a PROCESSING, OFFER, or a FAIL message. A QUOTATION-initiated transaction can be terminated by a FAIL message.

This operation is used to inform the remote party that its message (the order quotation or the offer) was received and it is being processed. This message can also be issued by the server to request more time, in which case, the client may reply with an ACK or FAIL message depending on whether extra time can or cannot be granted.

This operation is used by the server to inform the client about an offer that can best accommodate the requirements indicated in the previously received QUOTATION message.

This operation is used by the client to confirm the acceptance of an offer made by the server. This message implies a call for agreement. An agreement is reached when an ACK is subsequently received from the server, which is likely to happen if the message is sent before the offer validity time expires; the server is unlikely to reject an offer that it has already made.

This operation is used by the client to reject an offer made by the server. The ongoing transaction may not be terminated immediately, e.g., the client may issue another order or the server may issue another offer.

This operation is used by the server to acknowledge the receipt of an ACCEPT or WITHDRAW message or by the client to confirm the server's request for a time extension (conveyed in a PROCESSING message) in order to process the last received quotation order.

This operation is used by the client to cancel (quit) the ongoing transaction.

This operation is used by the client to withdraw a completed order (i.e., an agreement).

This operation is used by the client to update an existing agreement. For example, this method can be invoked to add a new VPN site. This method will trigger a new negotiation cycle.

This operation is used by the server to indicate that it cannot accommodate the requirements documented in the PQO conveyed in the QUOTATION message or to inform the client about an error encountered when processing the received message. In either case, the message implies that the server is unable to make offers, and, as a consequence, it terminates the ongoing transaction.

This message is also used by the client to reject a time extension request in a PROCESSING message received from the server. The message includes a status code that provides explanatory information.

Requested CPD:

Refers to the CPD included by a CPNP client in a QUOTATION request.

Offered CPD:

This document is included by a CPNP server in an OFFER message. Its information reflects the proposal of the server to accommodate all or a subset of the clauses depicted in a Requested CPD. A validity time is associated with the offer made.

Accepted CPD:

If the client accepts an offer made by the server, the Offered CPD is included in an ACCEPT message. This CPD is also included in an ACK message. Thus, a three-way handshake procedure is followed for successfully completing the negotiation.

+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |======QUOTATION (Requested CPD)=====>|
   |<============PROCESSING==============|
   |<========OFFER (Offered CPD)=========|
   |=============PROCESSING=============>|
   |=======ACCEPT (Accepted CPD)========>|
   |<=======ACK (Accepted CPD)===========|
   |                                     |

Created:

The order has been created. It is not handled by the client until the administrator allows it to be processed.

AwaitingProcessing:

The administrator has approved the processing of a created order, but the order has not been handled yet.

PQOSent:

The order has been sent to the server.

ServerProcessing:

The server has confirmed the receipt of the order.

OfferReceived:

An offer has been received from the server.

OfferProcessing:

A received offer is being processed by the client.

AcceptSent:

The client has confirmed the offer to the server.

Completed:

The offer has been acknowledged by the server.

Cancelled:

The order has failed or was cancelled.

+------------------+
|     Created      |-----------------+
+------------------+                 |
        |                            |
        v                            |
+------------------+                 |
|AwaitingProcessing|----------------+|
+------------------+                || 
        |                           ||
   QUOTATION/UPDATE                 ||
        v                           ||
+------------------+                ||
|     PQOSent      |---CANCEL------+||
+------------------+               vvv
        |                        +-----+
    PROCESSING                   |     |
        v                        |     |
+------------------+   CANCEL    |  C  |
| ServerProcessing |------------>|  A  |
+------------------+    FAIL     |  N  |
        |                        |  C  |
        |                        |  E  | 
      OFFER                      |  L  |
        |                        |  L  |
        v                        |  E  |
+------------------+             |  D  |
|  OfferReceived   |---CANCEL--->|     |
+------------------+             |     |
        | PROCESSING             +-----+
        v                          ^^^
+------------------+               |||
|  OfferProcessing |---DECLINE-----+||
+------------------+                ||
        | ACCEPT                    ||
        v                           ||
+------------------+                ||
|    AcceptSent    |---CANCEL-------+|
+------------------+                 |
        | ACK                        |
        v                            |
+------------------+                 |
|   Completed      |---WITHDRAW------+
+------------------+

PQOReceived:

The order has been received from the client.

AwaitingProcessing:

The order is being processed by the server. An action from the server administrator may be needed.

OfferProposed:

The request has been successfully handled, and an offer has been sent to the client.

ProcessingReceived:

The server has received a PROCESSING message for an offer sent to the client.

AcceptReceived:

The server has received a confirmation for the offer from the client.

Completed:

The server has acknowledged the offer (accepted by client) to the client. Transitioning to this state assumes that the ACK was received by the client (this can be detected by the server if it receives a retransmitted ACCEPT message from the client).

Cancelled:

The order cannot be accommodated, or it has been cancelled by the client. Associated resources must be released in the latter case, if previously reserved.

ChildCreated:

A child order has been created in cases where resources from another Network Provider are needed.

ChildPQOSent:

A child order has been sent to the remote server.

ChildServerProcessing:

A child order is being processed by the remote server.

ChildOfferReceived:

The remote server has received an offer to a child order.

ChildOfferProcessing:

A received offer to a child order is being processed.

ChildAcceptSent:

The child offer (the offer received from the remote server in response to a child order) is confirmed to the remote server.

ChildCompleted:

The accepted child offer has been acknowledged by the remote server.

+------------------+           +------------------+    
|AwaitingProcessing|<----------|    ChildCreated  |                        
+------------------+           +------------------+                   
        |                            |      ^ 
        v                            |      |                                                
+------------------+                 |      |           
|   ChildPQOSent   |----------------+|      Q     
+------------------+                ||      U              
        |                           ||      O                 
     QUOTATION/UPDATE               ||      T                  
        v                           ||      A  +--------------------+ 
+---------------------+   CANCEL    ||      T  |     PQOReceived    |      
|ChildServerProcessing|------------+||      I  +--------------------+ 
+---------------------+    FAIL    vvv      O       |      |  
        |                        +-----+    N    CANCEL    |
    PROCESSING                   |     |<---|-------+  PROCESSING
        v                        |     |    |              v
+------------------+             |     |   +------------------------+            
|ChildOfferReceived|----CANCEL---|  C  |<--|   AwaitingProcessing   |  
+------------------+             |  A  |   +------------------------+ 
        |                        |  N  |       ^          | OFFER
      OFFER                      |  C  |       | +------------------+ 
        |                        |  E  |<DECLINE-|   OfferProposed  |
        |                        |  L  |       | +------------------+     
        v                        |  L  |       |          |
+------------------+             |  E  |       |      PROCESSING
|ChildOfferReceived|---CANCEL----|  D  |       |          v
+------------------+             |     |       | +------------------+      
        |                        |     |<DECLINE-| Proc'ingReceived |     
   PROCESSING                    |     |       |+------------------+       
        |                        +-----+       |          | ACCEPT
        v                         ^^^^^        |          v  
+------------------+              |||||        | +------------------+
|ChildOfferProc'ing|---DECLINE----+|||+-CANCEL-|-|  AcceptReceived  |       
+------------------+               |||         | +------------------+ 
        |ACCEPT                    |||         |          |ACK
        v                          |||         |          v   
+------------------+               |||         | +------------------+
|  ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-|    Completed     |       
+------------------+                |          | +------------------+                  
        | ACK                       |          |
        v                           |          |
+------------------+                |          |
|  ChildCompleted  |---WITHDRAW-----+          |
|                  +---------------------------+
+------------------+

• Name
• Contact Information

<Customer Description> ::= [<NAME>] [<Contact Information>]
<Contact Information> ::=  [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
                           [<TELEPHONE_NUMBER> ...]

• Name
• AS Number [RFC 6793]
• Contact Information

<Provider Description> ::= [<NAME>][<Contact Information>]
                           [<AS_NUMBER>]

Setup purpose:

A client may request the setup of a service (e.g., connectivity) only for testing purposes during a limited period. The order can be extended to become permanent if the client was satisfied during the test period. This operation is achieved using the UPDATE method.

Activation type:

A client may request a permanent or scheduled activation type. If no activation type clause is included during the negotiation, this means that the order will be immediately activated right after the negotiation ends.

<Negotiation Options> ::= [<PURPOSE>]

<ACK Message> ::= <VERSION>
                  <METHOD_CODE>
                  <SEQUENCE_NUMBER>
                  <TRANSACTION_ID>
                  <CUSTOMER_ORDER_IDENTIFIER>
                  <PROVIDER_ORDER_IDENTIFIER>
                  [<EXPECTED_RESPONSE_TIME>]
                  [<CPD>]
                  [<INFORMATION_ELEMENT>...]

• A copy of the Requested/Offered CPD is included by the server if it successfully handled a CANCEL message.
• A copy of the Updated CPD is included by the server if it successfully handled an UPDATE message.
• A copy of the Offered CPD is included by the server if it successfully handled an ACCEPT message in the context of a QUOTATION transaction (refer to "Accepted CPD" in Section 8.7).
• An Empty CPD is included by the server if it successfully handled a DECLINE or WITHDRAW message.

<UPDATE Message> ::= <VERSION>
                     <METHOD_CODE>
                     <SEQUENCE_NUMBER>
                     <TRANSACTION_ID>
                     <CUSTOMER_ORDER_IDENTIFIER>
                     <PROVIDER_ORDER_IDENTIFIER>
                     <NONCE>
                     <EXPECTED_RESPONSE_TIME>
                     <REQUESTED_CPD>
                     [<INFORMATION_ELEMENT>...]

• If no order is found, the CPNP server generates a FAIL error with the appropriate error code (Section 9.2.10).
• If an order is found, the server checks whether it can honor the request:
  • A FAIL message is sent to the client if the server cannot honor the request. The client may initiate a new PQO negotiation cycle (that is, send a new UPDATE message).
  • An OFFER message including the updated clauses (e.g., Updated CPD) is sent to the client. For example, the server maintains an order for provisioning a VPN service that connects sites A, B, and C. If the client sends an UPDATE message to remove site C, only sites A and B will be included in the OFFER sent by the server to the requesting client. Note that the cycle that is triggered by an UPDATE message is also considered to be a negotiation cycle.

+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |=========UPDATE(Requested CPD)======>|
   |<============PROCESSING==============|
   |<=========OFFER(Updated CPD)=========|
   |=============PROCESSING=============>|
   |==========ACCEPT(Updated CPD)=======>|
   |<==========ACK(Updated CPD)==========|
   |                                     |

<FAIL Message> ::=  <VERSION>
                    <METHOD_CODE>
                    <SEQUENCE_NUMBER>
                    <TRANSACTION_ID>
                    <CUSTOMER_ORDER_IDENTIFIER>
                    <PROVIDER_ORDER_IDENTIFIER>
                    <STATUS_CODE>

• The server cannot honor an order received from the client (i.e., received in a QUOTATION or UPDATE request).
• The server encounters an error when processing a CPNP request received from the client.
• The client cannot grant more time to the server. This is a response to a time extension request carried in a PROCESSING message.

<ACTIVATE Message> ::= <VERSION>
                       <METHOD_CODE>
                       <SEQUENCE_NUMBER>
                       <TRANSACTION_ID>
                       <CUSTOMER_ORDER_IDENTIFIER>
                       <PROVIDER_ORDER_IDENTIFIER>
                       <NONCE>
                       <ACTIVATION_SCHEDULE>
                       [<INFORMATION_ELEMENT>...]

• If no completed order is found, the CPNP server generates a FAIL error with the appropriate error code (Section 9.2.10).
• If an order is found, the server checks whether it can honor the request:
  • A FAIL message is sent to the client if the server cannot honor the request (e.g., out of resources or explicit activation wasn't negotiated with this client).
  • An ACK is sent to the client to confirm that the immediate activation (or deactivation) of the order or its successful scheduling if a non-null ACTIVATION_SCHEDULE was included in the request. Note that setting ACTIVATION_SCHEDULE to 0 in an ACTIVATE request has a special meaning: it is used to request a deactivation of an accepted order.

+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |================ACTIVATE()==========>|
   |<==============ACK()=================|
   |                                     |

• If the checks fail, a FAIL message is sent back to the client with the appropriate error code (e.g., 1 (Message Validation Error), 2 (Authentication Required), or 3 (Authorization Failed)).
• If the checks succeed, the server clears the clauses of the CPD, changes the state of the order to "Cancelled", and sends back an ACK message with an Empty CPD.

• If the checks fail, a FAIL message is sent back to the client with the appropriate error code (e.g., 1 (Message Validation Error), 2 (Authentication Required), 3 (Authorization Failed), or 6 (Network Presence Error)).
• The exchange of subsequent messages is similar to what is specified in Section 11.1.1. The server should generate a new Nonce value to be included in the offer made to the client.

• Client's IP address
• Any event change (e.g., new quotation order, offer sent, order confirmation, order cancellation, order withdrawal, etc.)
• Timestamp

Fully automated mode:

The CPNP server is provisioned with a set of business guidelines and objectives that will be used as an input to the decision-making process. The CPNP server will service received orders that fall into these business guidelines; otherwise, requests will be escalated to an administrator that will formally validate or invalidate an order request. The set of policies to be configured to the CPNP server are specific to each administrative entity managing a CPNP server.

Administrative-based mode:

This mode assumes some or all of the CPNP server's operations are subject to a formal administrative validation. CPNP events will trigger appropriate validation requests that will be forwarded to the contact person(s) or department that is responsible for validating the orders. Administrative validation messages are relayed using another protocol (e.g., SMTP) or a dedicated tool.

[RFC3339]

G. Klyne, and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC5511]

A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009,
<https://www.rfc-editor.org/info/rfc5511>.

[RFC6347]

E. Rescorla, and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012,
<https://www.rfc-editor.org/info/rfc6347>.

[RFC7297]

M. Boucadair, C. Jacquenet, and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014,
<https://www.rfc-editor.org/info/rfc7297>.

[RFC7525]

Y. Sheffer, R. Holz, and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[AGAVE]

EU FP7 ETICS Project, M. Boucadair, P. Georgatsos, N. Wang, D. Griffin, G. Pavlou, M. Howarth, and A. Elizondo, "The AGAVE Approach for Network Virtualization: Differentiated Services Delivery", DOI 10.1007/s12243-009-0103-4, April 2009,
<https://rd.springer.com/article/10.1007/s12243-009-0103-4>.

[COPS-SLS]

T Nguyen, "COPS Usage for SLS negotiation (COPS-SLS)", Internet-Draft draft-nguyen-rap-cops-sls-03, July 2002,
<https://tools.ietf.org/html/draft-nguyen-rap-cops-sls-03>.

[DSNP]

National Tsing Hua University, J. Chen, "Dynamic Service Negotiation Protocol (DSNP)", Internet-Draft draft-itsumo-dsnp-03, March 2006,
<https://tools.ietf.org/html/draft-itsumo-dsnp-03>.

[ETICS]

EU FP7 ETICS Project, , "Economics and Technologies of Inter-Carrier Services", January 2014,
<https://cordis.europa.eu/project/id/248567>.

[L2VPN-NETWORK-YANG]

China Unicom, , , , , , and , "A Layer 2 VPN Network YANG Model", Internet-Draft draft-ietf-opsawg-l2nm-00, July 2020,
<https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00>.

[L3VPN-NETWORK-YANG]

Nokia, , , , , and , "A Layer 3 VPN Network YANG Model", Internet-Draft draft-ietf-opsawg-l3sm-l3nm-05, October 2020,
<https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05>.

[LISP-MS-DISCOVERY]

, and , "LISP Mapping Service Discovery at Large", Internet-Draft draft-boucadair-lisp-idr-ms-discovery-01, March 2016,
<https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms-discovery-01>.

[NETSLICES-ARCH]

Orange, , , , , , , and , "Network Slicing Architecture", Internet-Draft draft-geng-netslices-architecture-02, July 2017,
<https://tools.ietf.org/html/draft-geng-netslices-architecture-02>.

[RFC2782]

A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.

[RFC3084]

K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, DOI 10.17487/RFC3084, March 2001,
<https://www.rfc-editor.org/info/rfc3084>.

[RFC4026]

L. Andersson, and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.

[RFC4107]

S. Bellovin, and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005,
<https://www.rfc-editor.org/info/rfc4107>.

[RFC4176]

Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005,
<https://www.rfc-editor.org/info/rfc4176>.

[RFC6125]

P. Saint-Andre, and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011,
<https://www.rfc-editor.org/info/rfc6125>.

[RFC6241]

R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.

[RFC6462]

A. Cooper, "Report from the Internet Privacy Workshop", RFC 6462, DOI 10.17487/RFC6462, January 2012,
<https://www.rfc-editor.org/info/rfc6462>.

[RFC6574]

H. Tschofenig, and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012,
<https://www.rfc-editor.org/info/rfc6574>.

[RFC6770]

G. Bertrand, E. Stephan, T. Burbridge, P. Eardley, K. Ma, and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012,
<https://www.rfc-editor.org/info/rfc6770>.

[RFC6793]

Q. Vohra, and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.

[RFC6830]

D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.

[RFC6973]

A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.

[RFC7049]

C. Bormann, and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013,
<https://www.rfc-editor.org/info/rfc7049>.

[RFC7149]

M. Boucadair, and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.

[RFC7215]

L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014,
<https://www.rfc-editor.org/info/rfc7215>.

[RFC7491]

D. King, and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>.

[RFC8040]

A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.

[RFC8259]

T. Bray, "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.

[RFC8299]

Q. Wu, S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.

[RFC8309]

Q. Wu, W. Liu, and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.

[RFC8329]

D. Lopez, E. Lopez, L. Dunbar, J. Strassner, and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.

[RFC8466]

B. Wen, G. Fioccola, C. Xie, and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018,
<https://www.rfc-editor.org/info/rfc8466>.

[RFC8597]

LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, and P. Iovanna, "Cooperating Layered Architecture for Software-Defined Networking (CLAS)", RFC 8597, DOI 10.17487/RFC8597, May 2019,
<https://www.rfc-editor.org/info/rfc8597>.

[RNAP]

X. Wang, "A Resource Negotiation and Pricing Protocol (RNAP)",
<http://www.cs.columbia.edu/~xinwang/public/projects/protocol.html>.

[SNAP]

, , , , and , "SNAP: A Protocol for Negotiating Service Level Agreements and Coordinating Resource Management in Distributed Systems", DOI 10.1.1.19.5907, 2002,
<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5907>.

[SrNP]

P. Georgatsos, and G. Giannakopoulos, "Service Negotiation Protocol (SrNP)",
<https://www.ist-tequila.org/presentations/srnp-pipcm.pdf>.

[TEAS-SLICE-NBI]

Telefonica, , , and , "Considerations for defining a Transport Slice NBI", Internet-Draft draft-contreras-teas-slice-nbi-02, July 2020,
<https://tools.ietf.org/html/draft-contreras-teas-slice-nbi-02>.

Mohamed Boucadair

Christian Jacquenet

Dacheng Zhang

Panos Georgatsos