doc: Add RFC documents

1 files changed, 2733 insertions, 0 deletions

diff --git a/doc/rfc/rfc8921.txt b/doc/rfc/rfc8921.txt
new file mode 100644
index 0000000..e4b1e76
--- /dev/null
+++ b/doc/rfc/rfc8921.txt
@@ -0,0 +1,2733 @@
+
+
+
+
+Independent Submission                                 M. Boucadair, Ed.
+Request for Comments: 8921                                  C. Jacquenet
+Category: Informational                                           Orange
+ISSN: 2070-1721                                                 D. Zhang
+                                                     Huawei Technologies
+                                                           P. Georgatsos
+                                                                   CERTH
+                                                            October 2020
+
+
+ Dynamic Service Negotiation: The Connectivity Provisioning Negotiation
+                            Protocol (CPNP)
+
+Abstract
+
+   This document defines the Connectivity Provisioning Negotiation
+   Protocol (CPNP), which is designed to facilitate the dynamic
+   negotiation of service parameters.
+
+   CPNP is a generic protocol that can be used for various negotiation
+   purposes that include (but are not necessarily limited to)
+   connectivity provisioning services, storage facilities, Content
+   Delivery Networks, etc.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8921.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  CPNP Functional Elements
+   4.  Order Processing Models
+   5.  Sample Use Cases
+   6.  CPNP Deployment Models
+   7.  CPNP Negotiation Model
+   8.  Protocol Overview
+     8.1.  Client/Server Communication
+     8.2.  Policy Configuration on the CPNP Server
+     8.3.  CPNP Session Entries
+     8.4.  CPNP Transactions
+     8.5.  CPNP Timers
+     8.6.  CPNP Operations
+     8.7.  Connectivity Provisioning Documents
+     8.8.  Child PQOs
+     8.9.  Multi-Segment Service
+     8.10. Negotiating with Multiple CPNP Servers
+     8.11. State Management
+       8.11.1.  On the Client Side
+       8.11.2.  On the Server Side
+   9.  CPNP Objects
+     9.1.  Attributes
+       9.1.1.  CUSTOMER_ORDER_IDENTIFIER
+       9.1.2.  PROVIDER_ORDER_IDENTIFIER
+       9.1.3.  TRANSACTION_ID
+       9.1.4.  SEQUENCE_NUMBER
+       9.1.5.  NONCE
+       9.1.6.  EXPECTED_RESPONSE_TIME
+       9.1.7.  EXPECTED_OFFER_TIME
+       9.1.8.  VALIDITY_OFFER_TIME
+       9.1.9.  SERVICE_DESCRIPTION
+       9.1.10. CPNP Information Elements
+     9.2.  Operation Messages
+       9.2.1.  QUOTATION
+       9.2.2.  PROCESSING
+       9.2.3.  OFFER
+       9.2.4.  ACCEPT
+       9.2.5.  DECLINE
+       9.2.6.  ACK
+       9.2.7.  CANCEL
+       9.2.8.  WITHDRAW
+       9.2.9.  UPDATE
+       9.2.10. FAIL
+       9.2.11. ACTIVATE
+   10. CPNP Message Validation
+     10.1.  On the Client Side
+     10.2.  On the Server Side
+   11. Theory of Operation
+     11.1.  Client Behavior
+       11.1.1.  Order Negotiation Cycle
+       11.1.2.  Order Withdrawal Cycle
+       11.1.3.  Order Update Cycle
+     11.2.  Server Behavior
+       11.2.1.  Order Processing
+       11.2.2.  Order Withdrawal
+       11.2.3.  Order Update
+     11.3.  Sequence Numbers
+     11.4.  Message Retransmission
+   12. Some Operational Guidelines
+     12.1.  CPNP Server Logging
+     12.2.  Business Guidelines and Objectives
+   13. Security Considerations
+   14. IANA Considerations
+   15. References
+     15.1.  Normative References
+     15.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document defines the Connectivity Provisioning Negotiation
+   Protocol (CPNP) that is meant to dynamically exchange and negotiate
+   connectivity provisioning parameters and other service-specific
+   parameters between a Customer and a Provider.  CPNP is a tool that
+   introduces automation to the service negotiation and activation
+   procedures, thus fostering the overall service provisioning process.
+   CPNP can be seen as a component of the dynamic negotiation metadomain
+   described in Section 2.4 of [RFC7149].
+
+   CPNP is a generic protocol that can be used for negotiation purposes
+   other than connectivity provisioning.  For example, CPNP can be used
+   to request extra storage resources, to extend the footprint of a
+   Content Delivery Network (CDN), to enable additional features from a
+   cloud Provider, etc.  CPNP can be extended with new Information
+   Elements (IEs).  Sample negotiation use cases are described in
+   Section 5.  Section 4 introduces several order processing models and
+   defines those that are targeted by CPNP.  The CPNP negotiation model
+   is then detailed in Section 7.
+
+   [RFC7297] describes a Connectivity Provisioning Profile (CPP)
+   template to capture connectivity requirements to be met by a
+   transport infrastructure for the delivery of various services such as
+   Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN)
+   services [RFC4026].  The CPP document defines the set of IP transfer
+   parameters that reflect the guarantees that can be provided by the
+   underlying transport network together with reachability scope and
+   capacity needs.  CPNP uses the CPP template to encode connectivity
+   provisioning clauses that are subject to negotiation.  The accepted
+   CPP will then be passed to other functional elements that are
+   responsible for the actual service activation and provisioning.  For
+   example, Network Configuration Protocol (NETCONF) [RFC6241] or
+   RESTCONF [RFC8040] can be used to activate adequate network features
+   that are required to deliver the accepted service.  How the outcome
+   of CPNP negotiation is translated into service and network
+   provisioning actions is out of scope of this document.
+
+   As a reminder, several proposals have been made in the past by the
+   (research) community (e.g., Common Open Policy Service protocol for
+   supporting Service Level Specification [COPS-SLS], Service
+   Negotiation Protocol [SrNP], Dynamic Service Negotiation Protocol
+   [DSNP], Resource Negotiation and Pricing Protocol [RNAP], Service
+   Negotiation and Acquisition Protocol [SNAP]).  CPNP leverages the
+   authors' experience with SrNP by separating the negotiation
+   primitives from the service under negotiation.  Moreover, careful
+   examination of the other proposals revealed certain deficiencies that
+   were easier to address through the creation of a new protocol rather
+   than the modification of existing protocols.  For example:
+
+   *  COPS-SLS relies upon the COPS usage for policy provisioning (COPS-
+      PR) [RFC3084], 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.
+
+   One of the primary motivations of this document is to provide a
+   permanent reference to exemplify how service negotiation can be
+   automated.
+
+   Implementation details are out of scope.  An example of required
+   modules and interfaces to implement this specification is sketched in
+   Section 4 of [AGAVE].  This specification builds on that effort.
+
+2.  Terminology
+
+   This document makes use of the following terms:
+
+   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.
+
+3.  CPNP Functional Elements
+
+   The following functional elements are defined:
+
+   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).
+
+4.  Order Processing Models
+
+   For preparing their service orders, Customers may need to be aware of
+   the offered services.  Therefore, Providers should first proceed with
+   the announcement (or the exposure) of the services they can provide.
+   The service announcement process may take place at designated global
+   or Provider-specific service markets or through explicit interactions
+   with the Providers.  The details of this process are outside the
+   scope of this document.
+
+   With or without such service announcement/exposure mechanisms in
+   place, the following order processing models can be distinguished:
+
+   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 [RFC8309].
+
+   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).
+
+   Both frozen and negotiation-based models require the existence of
+   appropriate service templates like a CPP template and their
+   instantiation for expressing specific offerings from Providers and
+   service requirements from Customers, respectively.  CPNP can be used
+   in either model for automating the required Customer-Provider
+   interactions.  The frozen model can be seen as a special case of the
+   negotiation-based model.  This document focuses on the negotiation-
+   based model.  Not only 'yes/no' answers but also counterproposals may
+   be offered by the Provider in response to Customer orders.
+
+   Order processing management on the Network Provider's side usually
+   solicits features supported by the following functional blocks:
+
+   *  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
+
+   CPNP does not assume any specific knowledge about these functional
+   blocks, drawing an explicit line between protocol operation and the
+   logic for handling connectivity provisioning requests.  An order
+   processing logic is typically fed with the information manipulated by
+   the aforementioned functional blocks.  For example, the resources
+   that can be allocated to accommodate the Customer's requirements may
+   depend on network availability estimates as calculated by the
+   planning functions and related policies, as well as the number of
+   orders to be processed simultaneously over a given period of time.
+
+   This document does not elaborate on how Customers are identified and
+   subsequently managed by the Provider's information system.
+
+5.  Sample Use Cases
+
+   A non-exhaustive list of CPNP use cases is provided below:
+
+   1.   [RFC4176] 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 [RFC4176].  A L3VPN
+        Service YANG data model (L3SM) is defined in [RFC8299].  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 [RFC8466].  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) [RFC6574] 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) [RFC8329] 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 [RFC6770]
+        (see Figure 1).
+
+                         ,--,--,--.             ,--,--,--.
+                      ,-'          `-.       ,-'          `-.
+                     (CDN Provider 'A')=====(CDN Provider 'B')
+                      `-.  (CDN-A) ,-'       `-. (CDN-B)  ,-'
+                        `--'--'--'             `--'--'--'
+
+                         Figure 1: CDN Interconnection
+
+   11.  Mapping Service Providers (MSPs) [RFC7215] 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 [RFC6830].  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 [RFC8597].
+
+6.  CPNP Deployment Models
+
+   Several CPNP deployment models can be envisaged.  Two examples are
+   listed below:
+
+   *  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).
+
+   Once the negotiation of connectivity provisioning parameters is
+   successfully concluded, that is, an order has been placed by the
+   Customer, the actual network provisioning operations are initiated.
+   The specification of related dynamic resource allocation and policy
+   enforcement schemes, as well as how CPNP servers interact with the
+   network provisioning functional blocks on the Provider side, are out
+   of the scope of this document.
+
+   This document does not make any assumptions about the CPNP deployment
+   model either.
+
+7.  CPNP Negotiation Model
+
+   CPNP runs between a Customer and a Provider, carrying service orders
+   from the Customer and corresponding responses from the Provider in
+   order to reach a service provisioning agreement.  As the services
+   offered by the Provider are well described, by means of the CPP
+   template for connectivity matters, the negotiation process is
+   essentially a value-settlement process, where an agreement is pursued
+   on the values of the commonly understood information items (service
+   parameters) included in the service description template
+   (Section 9.1.9).
+
+   The content that CPNP carries and the negotiation logic invoked at
+   Customer and Provider sides to manipulate the content (i.e., the
+   information carried in CPNP messages to proceed with the negotiation)
+   is transparent to the protocol.
+
+   The protocol aims to facilitate the execution of the negotiation
+   logic by providing the required generic communication primitives.
+
+   Since negotiations are initiated and primarily driven by the
+   Customer's negotiation logic, it is reasonable to assume that the
+   Customer is the only party that can call for an agreement.  An
+   implicit approach is adopted for not overloading the protocol with
+   additional messages.  In particular, the acceptance of an offer made
+   by the Provider signals a call for agreement from the Customer.  Note
+   that it is almost certain the Provider will accept this call since it
+   refers to an offer that the Provider made.  Of course, at any point
+   the Provider or the Customer may quit the negotiations, each on its
+   own grounds.
+
+   Based on the above, CPNP adopts a quotation order/offer/answer model,
+   which proceeds through the following basic steps (Figure 3):
+
+   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======>|
+
+                  Figure 3: Simplified Service Negotiation
+
+   Multiple instances of CPNP may run at a Customer's or a Provider's
+   domains.  A CPNP client may be engaged in multiple, simultaneous
+   negotiations with the same or different CPNP servers (parallel
+   negotiations, see Section 8.10), and a CPNP server may need to
+   negotiate with other Provider(s) as part of negotiations that are
+   ongoing with a CPNP client (cascaded negotiations, see Section 8.8).
+
+   CPNP relies on various timers to run its operations.  Two types of
+   timers are defined: those that are specific to CPNP message
+   transmission and those that are specific to the negotiation logic.
+   The latter are used to guide the negotiation logic at both CPNP
+   client and CPNP server sides, particularly in cases where the CPNP
+   client is involved in parallel negotiations with several CPNP servers
+   or in cases where the CPNP server is, in turn, involved in
+   negotiations with other Providers for processing a given Customer-
+   originated quotation order.  CPNP allows a CPNP server to request
+   extra time to proceed with the negotiation.  This request may be
+   accepted or rejected by the CPNP client.
+
+   Providers may need to publish available services to the Customers
+   (see Section 4).  CPNP may optionally support this functionality.
+   Dedicated templates can be defined for the purpose of service
+   announcement, which will be used by the CPNP clients to initiate
+   their CPNP negotiation cycles.
+
+   For the sake of simplicity, a single offer/answer stage is assumed
+   within one CPNP negotiation cycle.  Nevertheless, as already stated,
+   multiple CPNP negotiation cycles can be undertaken by a CPNP client
+   (see Figure 4).
+
+   The model is flexible enough to accommodate changing conditions
+   during the lifetime of a service (e.g., the introduction of an
+   additional VPN site).
+
+   +------+                  +------+ +------+                  +------+
+   |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
+
+                   Figure 4: Overall Negotiation Process
+
+   The means used by a CPNP client to retrieve a list of active/accepted
+   offers are not defined in this document.
+
+   An order can be implicitly or explicitly activated.  Section 3.11 of
+   [RFC7297] specifies a dedicated clause called Activation Means.  Such
+   a clause indicates the required action(s) to be undertaken to
+   activate access to the (IP connectivity) service.  This document
+   defines a dedicated CPNP message that can be used for explicit
+   activation (Section 9.2.11).
+
+8.  Protocol Overview
+
+8.1.  Client/Server Communication
+
+   CPNP is a client/server protocol that can run over any transport
+   protocol.  The default transport mode is UDP secured with Datagram
+   Transport Layer Security (DTLS) [RFC6347].  No permanent CPNP
+   transport session needs to be maintained between the client and the
+   server.
+
+   The CPNP client can be configured with the CPNP server(s).
+   Typically, the CPNP client is configured with an IP address together
+   with a port number using manual or dynamic configuration means (e.g.,
+   DHCP).  Alternatively, a Provider may advertise the port number
+   (CPNP_PORT) it uses to bind the CPNP service using SRV [RFC2782].
+
+   The CPNP client may be provided with a domain name of the CPNP server
+   for PKIX-based authentication purposes.  CPNP servers should prefer
+   the use of DNS-ID and SRV-ID over CN-ID identifier types in
+   certificate requests (Section 2.3 of [RFC6125]).  URI-IDs should not
+   be used for CPNP server identity verification.
+
+   The client sends CPNP requests using CPNP_PORT as the destination
+   port number.  The same port number used as the source port number of
+   a CPNP request sent to a CPNP server is used by the server to reply
+   to that request.
+
+   CPNP is independent of the IP address family.
+
+   CPNP retransmission for unreliable transports is discussed in
+   Section 11.4.
+
+   Considerations related to mutual authentication are discussed in
+   Section 13.
+
+8.2.  Policy Configuration on the CPNP Server
+
+   As an input to its decision-making process, the CPNP server may be
+   connected to various external modules such as Customer Profiles,
+   Network Topology, Network Resource Management, Order Repositories,
+   AAA, and Network Provisioning Manager (an example is shown in
+   Figure 5).
+
+   These external modules provide inputs to the CPNP server so that it
+   can do the following:
+
+   *  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) [RFC7491] or network controllers.
+      These controllers will use protocols such as NETCONF [RFC6241] to
+      interact with the appropriate network nodes and functions for the
+      sake of proper service activation and delivery.
+
+   The above list of CPNP server operations is not exhaustive.
+
+            . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+            .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              |
+            +-------------------------------------------------------+
+
+       Figure 5: Order Handling Management Functional Block (Focus on
+                            Internal Interfaces)
+
+   The following order-handling modes can also be configured on the
+   server:
+
+   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.
+
+8.3.  CPNP Session Entries
+
+   A CPNP session entry is represented by a tuple defined as follows:
+
+   *  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).
+
+8.4.  CPNP Transactions
+
+   A CPNP transaction occurs between a client and a server for
+   completing, modifying, or withdrawing a service agreement, and
+   comprises all CPNP messages exchanged between the client and the
+   server, from the first request sent by the client to the final
+   response sent by the server.  A CPNP transaction is bound to a CPNP
+   session (Section 8.3).
+
+   Because multiple CPNP transactions can be maintained by the CPNP
+   client, the client must assign an identifier to uniquely identify a
+   given transaction.  This identifier is the Transaction-ID.
+
+   The Transaction-ID must be randomly assigned by the CPNP client,
+   according to the best current practice for generating random numbers
+   [RFC4086] that cannot be guessed easily.  The Transaction-ID is used
+   for validating CPNP responses received by the client.
+
+   In the context of a transaction, the client needs to select a
+   sequence number randomly and then needs to assign it to the first
+   CPNP message to send.  This number is then incremented for each
+   request message that is subsequently sent within the ongoing CPNP
+   transaction (see Section 11.3).
+
+8.5.  CPNP Timers
+
+   CPNP adopts a simple retransmission procedure that relies on a
+   retransmission timer represented by RETRANS_TIMER and a maximum retry
+   threshold.  The use of RETRANS_TIMER and a maximum retry threshold
+   are described in Section 11.
+
+   The response timer (EXPECTED_RESPONSE_TIME) is set by the client to
+   denote the time, in seconds, the client will wait to receive a
+   response from the server to a PQO request (see Section 9.1.6).  If
+   the timer expires, the respective PQO is cancelled by the client, and
+   a CANCEL message is generated accordingly.
+
+   The expected offer timer (EXPECTED_OFFER_TIME) is set by the server
+   to indicate the time by when the CPNP server is expected to make an
+   offer to the CPNP client (see Section 9.1.7).  If no offer is
+   received by then, the CPNP client will consider the order as
+   rejected.
+
+   An offer expiration timer (VALIDITY_OFFER_TIME) is set by the server
+   to represent the time, in minutes, after which an offer made by the
+   server becomes invalid (see Section 9.1.8).
+
+8.6.  CPNP Operations
+
+   CPNP operations are listed below.  They may be augmented depending on
+   the nature of some transactions or because of security considerations
+   that may necessitate a distinct CPNP client/server authentication
+   phase before negotiation begins.
+
+   QUOTATION (Section 9.2.1):
+      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.
+
+   PROCESSING (Section 9.2.2):
+      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.
+
+   OFFER (Section 9.2.3):
+      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.
+
+   ACCEPT (Section 9.2.4):
+      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.
+
+   DECLINE (Section 9.2.5):
+      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.
+
+   ACK (Section 9.2.6):
+      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.
+
+   CANCEL (Section 9.2.7):
+      This operation is used by the client to cancel (quit) the ongoing
+      transaction.
+
+   WITHDRAW (Section 9.2.8):
+      This operation is used by the client to withdraw a completed order
+      (i.e., an agreement).
+
+   UPDATE (Section 9.2.9):
+      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.
+
+   FAIL (Section 9.2.10):
+      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.
+
+   The above CPNP primitives are service independent.  CPNP messages may
+   transparently carry service-specific objects that are handled by the
+   negotiation logic at either side.
+
+   The document defines the service objects that are required for
+   connectivity provisioning negotiation purposes (see Section 8.7).
+   Additional service-specific objects for CPNP messages to accommodate
+   alternative deployment schemes or other service provisioning needs
+   can be defined in the future.
+
+8.7.  Connectivity Provisioning Documents
+
+   CPNP makes use of several flavors of Connectivity Provisioning
+   Documents (CPD).  These documents follow the same CPP template
+   described in [RFC7297].
+
+   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.
+
+   Figure 6 shows a typical CPNP negotiation cycle and the use of the
+   different types of CPDs.
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |======QUOTATION (Requested CPD)=====>|
+                 |<============PROCESSING==============|
+                 |<========OFFER (Offered CPD)=========|
+                 |=============PROCESSING=============>|
+                 |=======ACCEPT (Accepted CPD)========>|
+                 |<=======ACK (Accepted CPD)===========|
+                 |                                     |
+
+               Figure 6: Connectivity Provisioning Documents
+
+   A CPD can include parameters with fixed values, loosely defined
+   values, or any combination thereof.  A CPD is said to be concrete if
+   all clauses have fixed values.
+
+   A typical evolution of a negotiation cycle would start with a
+   quotation order with loosely defined parameters, and then, as offers
+   are made, it would conclude with a concrete CPD for calling for the
+   agreement.
+
+8.8.  Child PQOs
+
+   If the server detects that network resources from another Network
+   Provider need to be allocated in order to accommodate the
+   requirements described in a PQO (e.g., in the context of an inter-
+   domain VPN service, additional Provider Edge (PE) router resources
+   need to be allocated), the server may generate child PQOs to request
+   the appropriate network provisioning operations (see Figure 7).  In
+   such a situation, the server also behaves as a CPNP client.  The
+   server associates the parent order with its child PQOs.  How this is
+   achieved is implementation specific (e.g., this can be typically
+   achieved by locally adding the reference of the child PQO to the
+   parent order).
+
+            +------+            +--------+          +--------+
+            |Client|            |Server A|          |Server B|
+            +------+            +--------+          +--------+
+               |                    |                    |
+               |=====QUOTATION=====>|                    |
+               |<====PROCESSING=====|                    |
+               |                    |=====QUOTATION=====>|
+               |                    |<====PROCESSING=====|
+               |                    |<=======OFFER=======|
+               |                    |=====PROCESSING====>|
+               |                    |=======ACCEPT======>|
+               |                    |<=======ACK=========|
+               |<=======OFFER=======|                    |
+               |=====PROCESSING====>|                    |
+               |=======ACCEPT======>|                    |
+               |<=======ACK=========|                    |
+               |                    |                    |
+
+                     Figure 7: Example of Child Orders
+
+   Note that the server must not activate recursion for an order if the
+   client includes a negotiation option to restrict the negotiation
+   scope to the resources of the server's domain (Section 9.1.10.3).
+
+   If recursion is not explicitly disabled, the server may notify the
+   client when appropriate (Section 9.2.2).  Such notification may
+   depend on the nature of the service and also regulatory
+   considerations.
+
+8.9.  Multi-Segment Service
+
+   A composite service (e.g., connectivity) requested by a Customer
+   could imply multi-segment services (e.g., multi-segment connectivity
+   spanning an end-to-end scope), in the sense that one single CPNP
+   request is decomposed into multiple connectivity requests on the
+   Provider's side (thereby leading to child orders).  The Provider is
+   in charge of handling the complexity of splitting the generic
+   provisioning order in a multi-segment context.  Such complexity is
+   local to the Provider.
+
+8.10.  Negotiating with Multiple CPNP Servers
+
+   A CPNP client may undertake multiple negotiations in parallel with
+   several servers for various reasons, such as cost optimization and
+   fail-safety.  These multiple negotiations may lead to one or many
+   agreements.
+
+   The salient point underlining the parallel negotiation scenarios is
+   that, although the negotiation protocol is strictly between two
+   parties, this may not be the case of the negotiation logic.  The CPNP
+   client negotiation logic may need to collectively drive parallel
+   negotiations, as the negotiation with one server may affect the
+   negotiation with other servers; for example, it may need to use the
+   responses from all servers as an input for determining the messages
+   (and their content) to subsequently send within the course of each
+   individual negotiation.  Therefore, timing is an important aspect on
+   the client's side.  The CPNP client needs to have the ability to
+   synchronize the receipt of the responses from the servers.  CPNP
+   takes into account this requirement by allowing clients to specify in
+   the QUOTATION message the time by which the server needs to respond
+   (see Section 9.1.6).
+
+8.11.  State Management
+
+   Both the client and the server maintain repositories to store ongoing
+   orders.  How these repositories are maintained is deployment
+   specific.  It is out of scope of this document to elaborate on such
+   considerations.  Timestamps are also logged to track state change.
+   Tracking may be needed for various reasons, including regulatory or
+   billing ones.
+
+   In order to accommodate failures that may lead to the reboot of the
+   client or the server, the use of permanent storage is recommended,
+   thereby facilitating state recovery.
+
+8.11.1.  On the Client Side
+
+   This is the list of the typical states that can be associated with a
+   given order on the client's side:
+
+   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.
+
+   Sub-states may be defined (e.g., to track failed vs. cancelled
+   orders), but those are not shown in Figure 8.
+
+                 +------------------+
+                 |     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------+
+                 +------------------+
+
+       Figure 8: Example of a CPNP Finite State Machine (Client Side)
+
+8.11.2.  On the Server Side
+
+   The following lists the states on the server's side that can be
+   associated with a given order and a corresponding offer:
+
+   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-----+          |
+   |                  +---------------------------+
+   +------------------+
+
+             Figure 9: CPNP Finite State Machine (Server Side)
+
+9.  CPNP Objects
+
+   This section defines CPNP objects using the Routing Backus-Naur Form
+   (RBNF) format defined in [RFC5511].  Please also note the following:
+
+      |  Note 1: The formats of CPNP messages are provided using a
+      |  generic format.  Implementors can adapt RBNF definitions to
+      |  their "favorite" message format.  For example, JSON [RFC8259]
+      |  or Concise Binary Object Representation (CBOR) [RFC7049] can be
+      |  used.
+
+      |  Note 2: CPNP messages cannot be blindly mapped to RESTCONF
+      |  messages with the target service being modelled as
+      |  configuration data because such data is supposed to be
+      |  manipulated by a RESTCONF client only.  In such a model, the
+      |  RESTCONF server cannot use a value other than the one set by
+      |  the client (e.g., Section 9.2.3) or remove offers from its own
+      |  initiative (e.g., Section 9.1.8).  An alternate approach might
+      |  be to map CPNP operations into RESTCONF actions (RPC).
+      |  Assessing the feasibility of such approach is out of scope.
+
+9.1.  Attributes
+
+9.1.1.  CUSTOMER_ORDER_IDENTIFIER
+
+   The CUSTOMER_ORDER_IDENTIFIER (Customer Order Identifier) is an
+   identifier that is assigned by a client to identify an agreement.
+   This identifier must be unique to the client.
+
+   Rules for assigning this identifier (including the structure and
+   semantics) are specific to the client (Customer).  The value of
+   CUSTOMER_ORDER_IDENTIFIER is included in all CPNP messages.
+
+   The client (Customer) assigns an identifier to an order under
+   negotiation before an agreement is reached.  This identifier will be
+   used to unambiguously identify the resulting agreement at the client
+   side (Customer).
+
+   The server handles the CUSTOMER_ORDER_IDENTIFIER as an opaque value.
+
+9.1.2.  PROVIDER_ORDER_IDENTIFIER
+
+   The PROVIDER_ORDER_IDENTIFIER (Provider Order Identifier) is an
+   identifier that is assigned by a server to identify an order.  This
+   identifier must be unique to the server.
+
+   Rules for assigning this identifier (including the structure and
+   semantics) are specific to the server (Provider).  The
+   PROVIDER_ORDER_IDENTIFIER is included in all CPNP messages except
+   QUOTATION messages (because the state is only present at the client
+   side).
+
+   The server (Provider) assigns an identifier to an order under
+   negotiation before an agreement is reached.  This identifier will be
+   used to unambiguously identify the resulting agreement at the server
+   side (Provider).
+
+   The client handles the PROVIDER_ORDER_IDENTIFIER as an opaque value.
+
+9.1.3.  TRANSACTION_ID
+
+   This object conveys the Transaction-ID introduced in Section 8.4.
+
+9.1.4.  SEQUENCE_NUMBER
+
+   The sequence number is a number that is monotonically incremented in
+   every new CPNP message pertaining to a given CPNP transaction.  This
+   number is used to avoid replay attacks.
+
+   Refer to Section 11.3.
+
+9.1.5.  NONCE
+
+   The NONCE is a random value assigned by the CPNP server.  Assigning a
+   unique NONCE value for each order is recommended.
+
+   It is mandatory to then include the NONCE in subsequent CPNP client
+   operations on the associated order (including the resulting
+   agreement) such as withdrawing the order or updating the order.
+
+   If the NONCE validation checks fail, the server rejects the request
+   with a FAIL message that includes the appropriate failure reason
+   code.
+
+9.1.6.  EXPECTED_RESPONSE_TIME
+
+   This attribute indicates the time by when the CPNP client is
+   expecting to receive a response from the CPNP server to a given PQO.
+   If no offer is received by then, the CPNP client will consider the
+   quotation order to be rejected.
+
+   The EXPECTED_RESPONSE_TIME follows the date format specified in
+   [RFC3339].
+
+9.1.7.  EXPECTED_OFFER_TIME
+
+   This attribute indicates the time by when the CPNP server is
+   expecting to make an offer to the CPNP client.  If no offer is
+   received by then, the CPNP client will consider the order rejected.
+
+   The CPNP server may propose an expected offer time that does not
+   match the expected response time indicated in the quotation order
+   message.  The CPNP client can accept or reject the proposed expected
+   time by when the CPNP server will make an offer.
+
+   The CPNP server can always request extra time for its processing, but
+   this may be accepted or rejected by the CPNP client.
+
+   The EXPECTED_OFFER_TIME follows the date format specified in
+   [RFC3339].
+
+9.1.8.  VALIDITY_OFFER_TIME
+
+   This attribute indicates the time of validity of an offer made by the
+   CPNP server.  If the offer is not accepted before this time expires,
+   the CPNP server will consider the CPNP client as having rejected the
+   offer; the CPNP server will silently remove this order from its base.
+
+   The VALIDITY_OFFER_TIME follows date format specified in [RFC3339].
+
+9.1.9.  SERVICE_DESCRIPTION
+
+   This document defines a machinery to negotiate any aspect subject to
+   negotiation.  Service clauses that are under negotiation are conveyed
+   using this attribute.
+
+   The structure of the connectivity provisioning clauses is provided in
+   the following subsection.
+
+9.1.9.1.  CPD
+
+   The RBNF format of the CPD is shown in Figure 10.
+
+   <CPD> ::=  <Connectivity Provisioning Component> ...
+   <Connectivity Provisioning Component> ::=
+                              <CONNECTIVITY_PROVISIONING_PROFILE> ...
+   <CONNECTIVITY_PROVISIONING_PROFILE> ::=
+                              <Customer Nodes Map>
+                              <SCOPE>
+                              <QoS Guarantees>
+                              <Availability>
+                              <CAPACITY>
+                              <Traffic Isolation>
+                              <Conformance Traffic>
+                              <Flow Identification>
+                              <Overall Traffic Guarantees>
+                              <Routing and Forwarding>
+                              <Activation Means>
+                              <Invocation Means>
+                              <Notifications>
+   <Customer Nodes Map> ::=  <Customer Node> ...
+   <Customer Node> ::=  <IDENTIFIER>
+                        <LINK_IDENTIFIER>
+                        <LOCALIZATION>
+
+                   Figure 10: The RBNF format of the CPD
+
+9.1.10.  CPNP Information Elements
+
+   An Information Element (IE) is an optional object that can be
+   included in a CPNP message.
+
+9.1.10.1.  Customer Description
+
+   The client may include administrative information such as the
+   following:
+
+   *  Name
+
+   *  Contact Information
+
+   The format of this Information Element is as follows:
+
+   <Customer Description> ::= [<NAME>] [<Contact Information>]
+   <Contact Information> ::=  [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
+                              [<TELEPHONE_NUMBER> ...]
+
+9.1.10.2.  Provider Description
+
+   The server may include administrative information in an offer such as
+   the following:
+
+   *  Name
+
+   *  AS Number [RFC6793]
+
+   *  Contact Information
+
+   The format of this Information Element is as follows:
+
+   <Provider Description> ::= [<NAME>][<Contact Information>]
+                              [<AS_NUMBER>]
+
+9.1.10.3.  Negotiation Options
+
+   The client may include some negotiation options such as the
+   following:
+
+   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.
+
+   The format of this Information Element is as follows:
+
+   <Negotiation Options> ::= [<PURPOSE>]
+
+9.2.  Operation Messages
+
+   This section defines the RBNF format of CPNP operation messages.  The
+   following operation codes are used:
+
+   +======+===================+================+
+   | Code | Operation Message | Reference      |
+   +======+===================+================+
+   | 1    | QUOTATION         | Section 9.2.1  |
+   +------+-------------------+----------------+
+   | 2    | PROCESSING        | Section 9.2.2  |
+   +------+-------------------+----------------+
+   | 3    | OFFER             | Section 9.2.3  |
+   +------+-------------------+----------------+
+   | 4    | ACCEPT            | Section 9.2.4  |
+   +------+-------------------+----------------+
+   | 5    | DECLINE           | Section 9.2.5  |
+   +------+-------------------+----------------+
+   | 6    | ACK               | Section 9.2.6  |
+   +------+-------------------+----------------+
+   | 7    | CANCEL            | Section 9.2.7  |
+   +------+-------------------+----------------+
+   | 8    | WITHDRAW          | Section 9.2.8  |
+   +------+-------------------+----------------+
+   | 9    | UPDATE            | Section 9.2.9  |
+   +------+-------------------+----------------+
+   | 10   | FAIL              | Section 9.2.10 |
+   +------+-------------------+----------------+
+   | 11   | ACTIVATE          | Section 9.2.11 |
+   +------+-------------------+----------------+
+
+       Table 1: CPNP Operation Message Codes
+
+   These codes are used to unambiguously identify a CPNP operation; the
+   operation code is conveyed in the METHOD_CODE attribute mentioned in
+   the following subsections.
+
+   In the following, VERSION refers to the CPNP version number.  This
+   attribute must be set to 1.
+
+9.2.1.  QUOTATION
+
+   The format of the QUOTATION message is shown below:
+
+   <QUOTATION Message> ::=  <VERSION>
+                            <METHOD_CODE>
+                            <SEQUENCE_NUMBER>
+                            <TRANSACTION_ID>
+                            <CUSTOMER_ORDER_IDENTIFIER>
+                            [<EXPECTED_RESPONSE_TIME>]
+                            <REQUESTED_CPD>
+                            [<INFORMATION_ELEMENT>...]
+
+   A QUOTATION message must include an order identifier that is
+   generated by the client (CUSTOMER_ORDER_IDENTIFIER).  Because several
+   orders can be issued to several servers, the QUOTATION message must
+   also include a Transaction-ID.
+
+   The message may include an EXPECTED_RESPONSE_TIME, which indicates by
+   when the client expects to receive an offer from the server.  The
+   QUOTATION message must also include a requested service description
+   (that is, a Requested CPD for connectivity services).
+
+   The message may include ACTIVATION_TYPE to request a permanent or
+   scheduled activation type (e.g., using the ACTIVATE method defined in
+   Section 9.2.11).  If no such clause is included, the default mode is
+   to assume that the order will be active once the accepted activation
+   means are successfully invoked (e.g., Section 3.11 of [RFC7297]).
+
+   When the client sends the QUOTATION message to the server, the state
+   of the order changes to "PQOSent" at the client side.
+
+9.2.2.  PROCESSING
+
+   The format of the PROCESSING message is shown below:
+
+   <PROCESSING Message> ::= <VERSION>
+                            <METHOD_CODE>
+                            <SEQUENCE_NUMBER>
+                            <TRANSACTION_ID>
+                            <CUSTOMER_ORDER_IDENTIFIER>
+                            <PROVIDER_ORDER_IDENTIFIER>
+                            [<EXPECTED_OFFER_TIME>]
+                            [<PROCESSING_SUBCODE>]
+
+   Upon receipt of a QUOTATION message, the server proceeds with the
+   parsing rules (see Section 10).  If no error is encountered, the
+   server generates a PROCESSING response to the client to indicate the
+   PQO has been received and it is being processed.  The server must
+   generate an order identifier that identifies the order in its local
+   order repository.  The server must copy the content of the
+   CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed in
+   the QUOTATION message.  The server may include an EXPECTED_OFFER_TIME
+   by when it expects to make an offer to the client.
+
+   Upon receipt of a PROCESSING message, the client verifies whether it
+   has issued a PQO that contains the CUSTOMER_ORDER_IDENTIFIER and
+   TRANSACTION_ID to that server.  If no such PQO is found, the
+   PROCESSING message must be silently ignored.  If a PQO is found, the
+   client may check whether it accepts the EXPECTED_OFFER_TIME, and then
+   it changes to state of the order to "ServerProcessing".
+
+   If the server requires more time to process the quotation order, it
+   may send a PROCESSING message that includes a new
+   EXPECTED_OFFER_TIME.  The client can answer with an ACK message if
+   more time is granted (Figure 11) or with a FAIL message if the time
+   extension request is rejected (Figure 12).
+
+   The server may provide more details in the PROCESSING_SUBCODE
+   attribute about the reason for requesting more time to process the
+   request.  The following codes are defined:
+
+   +=========+============================+
+   | Subcode | Description                |
+   +=========+============================+
+   | 1       | Upgrade of local resources |
+   +---------+----------------------------+
+   | 2       | Request external resources |
+   +---------+----------------------------+
+
+      Table 2: PROCESSING_SUBCODE Codes
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |=======QUOTATION(Requested CPD)=====>|
+                 |<========PROCESSING(time1)===========|
+                                   ...
+                 |<========PROCESSING(MoreTime)========|
+                 |============ACK(TimeGranted)========>|
+                                   ...
+                 |<=========OFFER(Offered CPD)=========|
+                 |=============PROCESSING=============>|
+                 |=========ACCEPT(Accepted CPD)=======>|
+                 |<=========ACK(Accepted CPD)==========|
+                 |                                     |
+
+             Figure 11: Request More Negotiation Time: Granted
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |=======QUOTATION(Requested CPD)=====>|
+                 |<========PROCESSING(time1)===========|
+                                   ...
+                 |<========PROCESSING(MoreTime)========|
+                 |=====FAIL(More Time Rejected)=======>|
+
+             Figure 12: Request More Negotiation Time: Rejected
+
+9.2.3.  OFFER
+
+   The format of the OFFER message is shown below:
+
+   <OFFER Message> ::= <VERSION>
+                       <METHOD_CODE>
+                       <SEQUENCE_NUMBER>
+                       <TRANSACTION_ID>
+                       <CUSTOMER_ORDER_IDENTIFIER>
+                       <PROVIDER_ORDER_IDENTIFIER>
+                       <NONCE>
+                       <VALIDITY_OFFER_TIME>
+                       <OFFERED_CPD>
+                       [<INFORMATION_ELEMENT>...]
+
+   The server answers a QUOTATION request received from the client with
+   an OFFER message.  The offer will be considered to be rejected by the
+   client if no confirmation (i.e., an ACCEPT message sent by the
+   client) is received by the server before the expiration of the
+   validity time.
+
+   The server may include ACTIVATION_TYPE to indicate whether the offer
+   is about a permanent or scheduled activation type.  The message may
+   include ACTIVATION_SCHEDULE to indicate when the order is to be
+   activated.  If no such clause is included, the default mode is to
+   assume that the order will be active once the accepted activation
+   means are successfully invoked (e.g., Section 3.11 of [RFC7297] or
+   Section 9.2.11).
+
+9.2.4.  ACCEPT
+
+   The format of the ACCEPT message is shown below:
+
+   <ACCEPT Message> ::= <VERSION>
+                        <METHOD_CODE>
+                        <SEQUENCE_NUMBER>
+                        <TRANSACTION_ID>
+                        <CUSTOMER_ORDER_IDENTIFIER>
+                        <PROVIDER_ORDER_IDENTIFIER>
+                        <NONCE>
+                        <ACCEPTED_CPD>
+                        [<INFORMATION_ELEMENT>...]
+
+   This message is used by a client to confirm the acceptance of an
+   offer received from a server.  The fields of this message must be
+   copied from the received OFFER message.  This message should not be
+   sent after the validity time of the offer expires, as indicated by
+   the server (Section 9.2.3).
+
+9.2.5.  DECLINE
+
+   The format of the DECLINE message is shown below:
+
+   <DECLINE Message> ::= <VERSION>
+                         <METHOD_CODE>
+                         <SEQUENCE_NUMBER>
+                         <TRANSACTION_ID>
+                         <CUSTOMER_ORDER_IDENTIFIER>
+                         <PROVIDER_ORDER_IDENTIFIER>
+                         <NONCE>
+                         [<REASON>...]
+
+   The client may issue a DECLINE message to reject an offer.
+   CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, TRANSACTION_ID,
+   and NONCE are used by the server as keys to find the corresponding
+   order.  If an order matches, the server changes the state of this
+   order to "Cancelled" and then returns an ACK with a copy of the
+   Requested CPD to the requesting client.
+
+   A DECLINE message may include an Information Element to indicate the
+   reason for declining an offer.  The following codes are defined:
+
+   +======+====================================================+
+   | Code | Description                                        |
+   +======+====================================================+
+   | 1    | Unacceptable gap between the request and the offer |
+   +------+----------------------------------------------------+
+   | 2    | Conflict with another offer from another server    |
+   +------+----------------------------------------------------+
+   | 3    | Activation type mismatch                           |
+   +------+----------------------------------------------------+
+
+                   Table 3: DECLINE Message Codes
+
+   If no order is found, the server returns a FAIL message to the
+   requesting client.  In order to prevent DDoS (Distributed Denial of
+   Service) attacks, the server should restrict the number of FAIL
+   messages sent to a requesting client.  It may also rate-limit FAIL
+   messages.
+
+   A flow example is shown in Figure 13.
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |=======QUOTATION(Requested CPD)=====>|
+                 |<============PROCESSING==============|
+                 |<=========OFFER(Offered CPD)=========|
+                 |=============PROCESSING=============>|
+                 |===============DECLINE==============>|
+                 |<================ACK=================|
+                 |                                     |
+
+                      Figure 13: DECLINE Flow Example
+
+9.2.6.  ACK
+
+   The format of the ACK message is shown below:
+
+   <ACK Message> ::= <VERSION>
+                     <METHOD_CODE>
+                     <SEQUENCE_NUMBER>
+                     <TRANSACTION_ID>
+                     <CUSTOMER_ORDER_IDENTIFIER>
+                     <PROVIDER_ORDER_IDENTIFIER>
+                     [<EXPECTED_RESPONSE_TIME>]
+                     [<CPD>]
+                     [<INFORMATION_ELEMENT>...]
+
+   This message is issued by the server to close a CPNP transaction or
+   by a client to grant more negotiation time to the server.
+
+   This message is sent by the server as a response to an ACCEPT,
+   WITHDRAW, DECLINE, or CANCEL message.  In this case, the ACK message
+   must include the copy of the service description (i.e., CPD for
+   connectivity services) as stored by the server.  In particular, the
+   following considerations are taken into account for connectivity
+   provisioning services:
+
+   *  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.
+
+   A client may issue an ACK message as a response to a time extension
+   request (conveyed in PROCESSING) received from the server.  In such
+   case, the ACK message must include an EXPECTED_RESPONSE_TIME that is
+   likely to be set to the time extension requested by the server.
+
+9.2.7.  CANCEL
+
+   The format of the CANCEL message is shown below:
+
+   <CANCEL Message> ::= <VERSION>
+                        <METHOD_CODE>
+                        <SEQUENCE_NUMBER>
+                        <TRANSACTION_ID>
+                        <CUSTOMER_ORDER_IDENTIFIER>
+                        [<CPD>]
+
+   The client can issue a CANCEL message at any stage during the CPNP
+   negotiation process before an agreement is reached.  The
+   CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID are used by the server
+   as keys to find the corresponding order.  If a quotation order
+   matches, the server changes the state of this quotation order to
+   "Cancelled" and then returns an ACK with a copy of the Requested CPD
+   to the requesting client.
+
+   If no quotation order is found, the server returns a FAIL message to
+   the requesting client.
+
+9.2.8.  WITHDRAW
+
+   The format of the WITHDRAW message is shown below:
+
+   <WITHDRAW Message> ::= <VERSION>
+                          <METHOD_CODE>
+                          <SEQUENCE_NUMBER>
+                          <TRANSACTION_ID>
+                          <CUSTOMER_ORDER_IDENTIFIER>
+                          <PROVIDER_ORDER_IDENTIFIER>
+                          <NONCE>
+                          [<ACCEPTED_CPD>]
+                          [<INFORMATION_ELEMENT>...]
+
+   This message is used to withdraw an offer already accepted by the
+   Customer.  Figure 14 shows a typical usage of this message.
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |============WITHDRAW(CPD)===========>|
+                 |<============PROCESSING==============|
+                 |<===========ACK(Empty CPD)===========|
+                 |                                     |
+
+                      Figure 14: WITHDRAW Flow Example
+
+   The WITHDRAW message must include the same CUSTOMER_ORDER_IDENTIFIER,
+   PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the
+   order.
+
+   Upon receipt of a WITHDRAW message, the server checks whether an
+   order matching the request is found.  If an order is found, the state
+   of the order is changed to "Cancelled", and an ACK message including
+   an Empty CPD is returned to the requesting client.  If no order is
+   found, the server returns a FAIL message to the requesting client.
+
+9.2.9.  UPDATE
+
+   The format of the UPDATE message is shown below:
+
+   <UPDATE Message> ::= <VERSION>
+                        <METHOD_CODE>
+                        <SEQUENCE_NUMBER>
+                        <TRANSACTION_ID>
+                        <CUSTOMER_ORDER_IDENTIFIER>
+                        <PROVIDER_ORDER_IDENTIFIER>
+                        <NONCE>
+                        <EXPECTED_RESPONSE_TIME>
+                        <REQUESTED_CPD>
+                        [<INFORMATION_ELEMENT>...]
+
+   This message is sent by the CPNP client to update an existing service
+   agreement (e.g., Accepted CPD).  The UPDATE message must include the
+   same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE
+   as those used when creating the order.  The CPNP client includes a
+   new service description (e.g., Updated CPD) that integrates the
+   requested modifications.  A new Transaction_ID must be assigned by
+   the client.
+
+   Upon receipt of an UPDATE message, the server checks whether an
+   order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER,
+   PROVIDER_ORDER_IDENTIFIER, and NONCE.
+
+   *  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.
+
+   A flow chart that illustrates the use of UPDATE operation is shown in
+   Figure 15.
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |=========UPDATE(Requested CPD)======>|
+                 |<============PROCESSING==============|
+                 |<=========OFFER(Updated CPD)=========|
+                 |=============PROCESSING=============>|
+                 |==========ACCEPT(Updated CPD)=======>|
+                 |<==========ACK(Updated CPD)==========|
+                 |                                     |
+
+                       Figure 15: UPDATE Flow Example
+
+9.2.10.  FAIL
+
+   The format of the FAIL message is shown below:
+
+   <FAIL Message> ::=  <VERSION>
+                       <METHOD_CODE>
+                       <SEQUENCE_NUMBER>
+                       <TRANSACTION_ID>
+                       <CUSTOMER_ORDER_IDENTIFIER>
+                       <PROVIDER_ORDER_IDENTIFIER>
+                       <STATUS_CODE>
+
+   This message is sent in the following cases:
+
+   *  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.
+
+   The status code indicates the error code.  The following codes are
+   supported:
+
+    +========+==================+=====================================+
+    | Status | Error Code       | Description                         |
+    | Code   |                  |                                     |
+    +========+==================+=====================================+
+    | 1      | Message          | The message cannot be validated     |
+    |        | Validation Error | (see Section 10).                   |
+    +--------+------------------+-------------------------------------+
+    | 2      | Authentication   | The request cannot be handled       |
+    |        | Required         | because authentication is required. |
+    +--------+------------------+-------------------------------------+
+    | 3      | Authorization    | The request cannot be handled       |
+    |        | Failed           | because authorization failed.       |
+    +--------+------------------+-------------------------------------+
+    | 4      | Administratively | The request cannot be handled       |
+    |        | prohibited       | because of administrative policies. |
+    +--------+------------------+-------------------------------------+
+    | 5      | Out of Resources | The request cannot be honored       |
+    |        |                  | because resources (e.g., capacity)  |
+    |        |                  | are insufficient.                   |
+    +--------+------------------+-------------------------------------+
+    | 6      | Network Presence | The request cannot be honored       |
+    |        | Error            | because there is no network         |
+    |        |                  | presence.                           |
+    +--------+------------------+-------------------------------------+
+    | 7      | More Time        | The request to extend the time for  |
+    |        | Rejected         | negotiation is rejected by the      |
+    |        |                  | client.                             |
+    +--------+------------------+-------------------------------------+
+    | 8      | Unsupported      | The request cannot be handled       |
+    |        | Activation Type  | because the requested activation    |
+    |        |                  | type is not supported.              |
+    +--------+------------------+-------------------------------------+
+
+                     Table 4: FAIL Message Error Codes
+
+9.2.11.  ACTIVATE
+
+   The format of the ACTIVATE message is shown below:
+
+   <ACTIVATE Message> ::= <VERSION>
+                          <METHOD_CODE>
+                          <SEQUENCE_NUMBER>
+                          <TRANSACTION_ID>
+                          <CUSTOMER_ORDER_IDENTIFIER>
+                          <PROVIDER_ORDER_IDENTIFIER>
+                          <NONCE>
+                          <ACTIVATION_SCHEDULE>
+                          [<INFORMATION_ELEMENT>...]
+
+   This message is sent by the CPNP client to request the activation of
+   an existing service agreement.  The message must include the same
+   CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE as
+   those used when creating the order.  The CPNP client may include a
+   schedule target for activating this order.  A new Transaction_ID must
+   be assigned by the client.
+
+   Upon receipt of an ACTIVATE message, the server checks whether an
+   order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER,
+   PROVIDER_ORDER_IDENTIFIER, and NONCE.
+
+   *  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.
+
+   Figure 16 illustrates the use of the ACTIVATE operation.
+
+              +------+                              +------+
+              |Client|                              |Server|
+              +------+                              +------+
+                 |================ACTIVATE()==========>|
+                 |<==============ACK()=================|
+                 |                                     |
+
+                      Figure 16: ACTIVATE Flow Example
+
+10.  CPNP Message Validation
+
+   Both the client and the server proceed with CPNP message validation.
+   The following tables summarize the validation checks to be followed.
+
+10.1.  On the Client Side
+
+   +==============+==================================================+
+   | Operation    | Validation Checks                                |
+   +==============+==================================================+
+   | PROCESSING   | {Source IP address, source port number,          |
+   |              | destination IP address, destination port number, |
+   |              | Transaction-ID, Customer Order Identifier} must  |
+   |              | match an existing PQO with a state set to        |
+   |              | "PQOSent".  The sequence number carried in the   |
+   |              | packet must be larger than the sequence number   |
+   |              | maintained by the client.                        |
+   +--------------+--------------------------------------------------+
+   | OFFER        | {Source IP address, source port number,          |
+   |              | destination IP address, destination port number, |
+   |              | Transaction-ID, Customer Order Identifier} must  |
+   |              | match an existing order with state set to        |
+   |              | "PQOSent", or {Source IP address, source port    |
+   |              | number, destination IP address, destination port |
+   |              | number, Transaction-ID, Customer Order           |
+   |              | Identifier, Provider Order Identifier} must      |
+   |              | match an existing order with a state set to      |
+   |              | "ServerProcessing".  The sequence number carried |
+   |              | in the packet must be larger than the sequence   |
+   |              | number maintained by the client.                 |
+   +--------------+--------------------------------------------------+
+   | ACK          | {Source IP address, source port number,          |
+   | (QUOTATION   | destination IP address, destination port number, |
+   | Transaction) | Transaction-ID, Customer Order Identifier,       |
+   |              | Provider Order Identifier, Offered Connectivity  |
+   |              | Provisioning Document} must match an order with  |
+   |              | a state set to "AcceptSent".  The sequence       |
+   |              | number carried in the packet must be larger than |
+   |              | the sequence number maintained by the client.    |
+   +--------------+--------------------------------------------------+
+   | ACK (UPDATE  | {Source IP address, source port number,          |
+   | Transaction) | destination IP address, destination port number, |
+   |              | Transaction-ID, Customer Order Identifier,       |
+   |              | Provider Order Identifier, Updated Connectivity  |
+   |              | Provisioning Document} must match an order with  |
+   |              | a state set to "AcceptSent".  The sequence       |
+   |              | number carried in the packet must be larger than |
+   |              | the sequence number maintained by the client.    |
+   +--------------+--------------------------------------------------+
+   | ACK          | {Source IP address, source port number,          |
+   | (WITHDRAW    | destination IP address, destination port number, |
+   | Transaction) | Transaction-ID, Customer Order Identifier,       |
+   |              | Provider Order Identifier, Empty Connectivity    |
+   |              | Provisioning Document} must match an order with  |
+   |              | a state set to "Cancelled".  The sequence number |
+   |              | carried in the packet must be larger than the    |
+   |              | sequence number maintained by the client.        |
+   +--------------+--------------------------------------------------+
+
+                  Table 5: Client Side Validation Checks
+
+10.2.  On the Server Side
+
+   +============+==================================================+
+   | Method     | Validation Checks                                |
+   +============+==================================================+
+   | QUOTATION  | The source IP address passes existing access     |
+   |            | filters (if any).  The sequence number carried   |
+   |            | in the packet must not be lower than the         |
+   |            | sequence number maintained by the server.        |
+   +------------+--------------------------------------------------+
+   | PROCESSING | The sequence number carried in the packet must   |
+   |            | be greater than the sequence number maintained   |
+   |            | by the server.                                   |
+   +------------+--------------------------------------------------+
+   | CANCEL     | {Source IP address, source port number,          |
+   |            | destination IP address, destination port number, |
+   |            | Transaction-ID, Customer Order Identifier} must  |
+   |            | match an order with state set to "PQOReceived"   |
+   |            | or "OfferProposed" or "ProcessingReceived" or    |
+   |            | "AcceptReceived".  The sequence number carried   |
+   |            | in the packet must be greater than the sequence  |
+   |            | number maintained by the server.                 |
+   +------------+--------------------------------------------------+
+   | ACCEPT     | {Source IP address, source port number,          |
+   |            | destination IP address, destination port number, |
+   |            | Transaction-ID, Customer Order Identifier,       |
+   |            | Provider Order Identifier, Nonce, Offered        |
+   |            | Connectivity Provisioning Document} must match   |
+   |            | an order with state set to "OfferProposed" or    |
+   |            | "ProcessingReceived".  The sequence number       |
+   |            | carried in the packet must be greater than the   |
+   |            | sequence number maintained by the server.        |
+   +------------+--------------------------------------------------+
+   | FAIL       | {Source IP address, source port number,          |
+   |            | destination IP address, destination port number, |
+   |            | Transaction-ID, Customer Order Identifier,       |
+   |            | Provider Order Identifier} must match an order   |
+   |            | with state set to "AwaitingProcessing" and for   |
+   |            | which a request to grant more time to process an |
+   |            | offer was requested.  The sequence number        |
+   |            | carried in the packet must be greater than the   |
+   |            | sequence number maintained by the server.        |
+   +------------+--------------------------------------------------+
+   | DECLINE    | {Source IP address, source port number,          |
+   |            | destination IP address, destination port number, |
+   |            | Transaction-ID, Customer Order Identifier,       |
+   |            | Provider Order Identifier, Nonce} must match an  |
+   |            | order with state set to "OfferProposed" or       |
+   |            | "ProcessingReceived".  The sequence number       |
+   |            | carried in the packet must be greater than the   |
+   |            | sequence number maintained by the server.        |
+   +------------+--------------------------------------------------+
+   | UPDATE     | The source IP address passes existing access     |
+   |            | filters (if any), and {Customer Order            |
+   |            | Identifier, Provider Order Identifier, Nonce}    |
+   |            | must match an existing order with state          |
+   |            | "Completed".                                     |
+   +------------+--------------------------------------------------+
+   | WITHDRAW   | The source IP address passes existing access     |
+   |            | filters (if any), and {Customer Order            |
+   |            | Identifier, Provider Order Identifier, Nonce}    |
+   |            | must match an existing order with state          |
+   |            | "Completed".                                     |
+   +------------+--------------------------------------------------+
+   | ACTIVATE   | The source IP address passes existing access     |
+   |            | filters (if any), and {Customer Order            |
+   |            | Identifier, Provider Order Identifier, Nonce}    |
+   |            | must match an existing order with a state of     |
+   |            | "Completed" and its activation procedure set to  |
+   |            | explicit.                                        |
+   +------------+--------------------------------------------------+
+
+                 Table 6: Server Side Validation Checks
+
+11.  Theory of Operation
+
+   Both the CPNP client and server proceed with message validation
+   checks as specified in Section 10.
+
+11.1.  Client Behavior
+
+11.1.1.  Order Negotiation Cycle
+
+   To place a PQO, the client first initiates a local quotation order
+   object identified by a unique identifier assigned by the client
+   (Client Order Identifier).  The state of the quotation order is set
+   to "Created".  The client then generates a QUOTATION request that
+   includes the assigned identifier, possibly an expected response time,
+   a Transaction-ID, and a requested service (e.g., Requested CPD).  The
+   client may include additional Information Elements such as Customer
+   Description or Negotiation Options.
+
+   The client may be configured to not enforce negotiation checks on
+   EXPECTED_OFFER_TIME; if so, the client should either not include the
+   EXPECTED_RESPONSE_TIME attribute in the PQO or it should set the
+   attribute to infinite.
+
+   Once the request is sent to the server, the state of the request is
+   set to "PQOSent", and if a response time is included in the quotation
+   order, a timer is set to the expiration time as included in the
+   QUOTATION request.  The client also maintains a copy of the CPNP
+   session entry details used to generate the QUOTATION request.  The
+   CPNP client must listen on the same port number that it used to send
+   the QUOTATION request.
+
+   If no answer is received from the server before the retransmission
+   timer expires (i.e., RETRANS_TIMER, Section 8.5), the client
+   retransmits the message until maximum retry is reached (e.g., three
+   times).  The same sequence number is used for retransmitted packets.
+
+   If a FAIL message is received, the client may decide to issue another
+   (corrected) request towards the same server, cancel the local order,
+   or contact another server.  The behavior of the client depends on the
+   error code returned by the server in the FAIL message.
+
+   If a PROCESSING message matching the CPNP session entry (Section 8.3)
+   is received, the client updates the CPNP session entry with the
+   PROVIDER_ORDER_IDENTIFIER information.  If the client does not accept
+   the expected offer time that may have been indicated in the
+   PROCESSING message, the client may decide to cancel the quotation
+   order.  If the client accepts the EXPECTED_OFFER_TIME, it changes the
+   state of the order to "ServerProcessing" and sets a timer to the
+   value of EXPECTED_OFFER_TIME.  If no offer is made before the timer
+   expires, the client changes the state of the order to "Cancelled".
+
+   As a response to a time extension request (conveyed in a PROCESSING
+   message that included a new EXPECTED_OFFER_TIME), the client may
+   either grant this extension by issuing an ACK message or reject the
+   time extension by issuing a FAIL message with a status code set to
+   "More Time Rejected".
+
+   If an OFFER message matching the CPNP session entry is received, the
+   client checks if a PROCESSING message having the same
+   PROVIDER_ORDER_IDENTIFIER has been received from the server.  If a
+   PROCESSING message was already received for the same order, but the
+   PROVIDER_ORDER_IDENTIFIER does not match the identifier included in
+   the OFFER message, the client silently ignores the message.  If a
+   PROCESSING message with the same PROVIDER_ORDER_IDENTIFIER was
+   already received and matches the CPNP transaction identifier, the
+   client changes the state of the order to "OfferReceived" and sets a
+   timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER
+   message.
+
+   If an offer is received from the server (i.e., as documented in an
+   OFFER message), the client may accept or reject the offer.  The
+   client accepts the offer by generating an ACCEPT message that
+   confirms that the client agrees to subscribe to the offer documented
+   in the OFFER message; the state of the order is passed to
+   "AcceptSent".  The transaction is terminated if an ACK message is
+   received from the server.  If no ACK is received from the server, the
+   client proceeds with the retransmission of the ACCEPT message until
+   the maximum retry is reached (Section 11.4).
+
+   The client may also decide to reject the offer by sending a DECLINE
+   message.  The state of the order is set by the client to "Cancelled".
+   If an offer is not acceptable to the client, the client may decide to
+   contact a new server or submit another order to the same server.
+   Guidelines to issue an updated order or terminate the negotiation are
+   specific to the client.
+
+   An order can be activated (or deactivated) using the ACTIVATE message
+   or other accepted activation means (Section 3.11 of [RFC7297]).
+
+11.1.2.  Order Withdrawal Cycle
+
+   A client may withdraw a completed order.  This is achieved by issuing
+   a WITHDRAW message.  This message must include the Customer Order
+   Identifier, Provider Order Identifier, and Nonce returned during the
+   order negotiation cycle, as specified in Section 11.1.1.
+
+   If no ACK is received from the server, the client proceeds with the
+   retransmission of the message.  If no ACK is received after the
+   maximum retry is exhausted, the client should log the information and
+   must send an alarm to the administrator.  If there is no specific
+   instruction from the administrator, the client should schedule
+   another Withdrawal cycle.  The client must not retry this Withdrawal
+   cycle more frequently than every 300 seconds and must not retry more
+   frequently than every 60 seconds.
+
+11.1.3.  Order Update Cycle
+
+   A client may update a completed order.  This is achieved by issuing
+   an UPDATE message.  This message must include the Customer Order
+   Identifier, Provider Order Identifier, and Nonce returned during the
+   order negotiation cycle specified in Section 11.1.1.  The client must
+   include in the UPDATE message an Updated CPD with the requested
+   changes.
+
+   The subsequent message exchange is similar to what is documented in
+   Section 11.1.1.
+
+11.2.  Server Behavior
+
+11.2.1.  Order Processing
+
+   Upon receipt of a QUOTATION message from a client, the server sets a
+   CPNP session, stores the Transaction-ID, and generates a Provider
+   Order Identifier.  Once preliminary validation checks are completed
+   (Section 10), the server may return a PROCESSING message to inform
+   the client that the quotation order is received and it is under
+   processing; the server may include an expected offer time to notify
+   the client by when an offer will be proposed.  An order with state
+   "AwaitingProcessing" is created by the server.  The server runs its
+   decision-making process to decide which offer it can make to honor
+   the received order.  The offer should be made before the expected
+   offer time expires.
+
+   If the server cannot make an offer, it sends backs a FAIL message
+   with the appropriate error code (Section 9.2.10).
+
+   If the server requires more negotiation time, it must send a
+   PROCESSING message with a new EXPECTED_OFFER_TIME.  The client may
+   grant this extension by issuing an ACK message or reject the time
+   extension by issuing a FAIL message with the status code set to "More
+   Time Rejected".  If the client doesn't grant more time, the server
+   must answer before the initial expected offer time; otherwise, the
+   client will decline the quotation order.
+
+   If the server can honor the request, or if it can make an offer that
+   meets only some of the requirements, it creates an OFFER message.
+   The server must indicate the Transaction-ID, the Customer Order
+   Identifier as indicated in the QUOTATION message, and the Provider
+   Order Identifier generated for this order.  The server must also
+   include the Nonce and the offered service document (e.g., Offered
+   CPD).  The server includes an offer validity time as well.  Once sent
+   to the client, the server changes the state of the order to
+   "OfferProposed", and a timer set to the validity time is initiated.
+
+   If the server determines that additional network resources from
+   another Network Provider are needed to accommodate a quotation order,
+   it will create child PQO(s) and will behave as a CPNP client to
+   negotiate child PQO(s) with possible partnering Providers (see
+   Figure 7).
+
+   If no PROCESSING, ACCEPT, or DECLINE message is received before the
+   expiry of the RETRANS_TIMER, the server resends the same offer to the
+   client.  This procedure is repeated until maximum retry is reached.
+
+   If an ACCEPT message is received before the offered validity time
+   expires, the server proceeds with validation checks as specified in
+   Section 10.  The state of the corresponding order is passed to
+   "AcceptReceived".  The server sends back an ACK message to terminate
+   the order processing cycle.
+
+   If a CANCEL or a DECLINE message is received, the server proceeds
+   with the cancellation of the order.  The state of the order is then
+   passed to "Cancelled".
+
+11.2.2.  Order Withdrawal
+
+   A client may withdraw a completed order by issuing a WITHDRAW
+   message.  Upon receipt of a WITHDRAW message, the server proceeds
+   with the validation checks, as specified in Section 10:
+
+   *  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.
+
+11.2.3.  Order Update
+
+   A client may update an order by issuing an UPDATE message.  Upon
+   receipt of an UPDATE message, the server proceeds with the validation
+   checks as specified in Section 10:
+
+   *  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.
+
+11.3.  Sequence Numbers
+
+   In each transaction, sequence numbers are used to protect the
+   transaction against replay attacks.  Each communicating partner of
+   the transaction maintains two sequence numbers, one for incoming
+   packets and one for outgoing packets.  When a partner receives a
+   message, it will check whether the sequence number in the message is
+   larger than the incoming sequence number maintained locally.  If not,
+   the message will be discarded.  If the message is proved to be
+   legitimate, the value of the incoming sequence number maintained
+   locally will be replaced by the value of the sequence number in the
+   message.  When a partner sends out a message, it will insert the
+   value of the outgoing sequence number into the message and increase
+   the outgoing sequence number maintained locally by 1.
+
+11.4.  Message Retransmission
+
+   If a transaction partner sends out a message and does not receive any
+   expected reply before the retransmission timer expires (i.e.,
+   RETRANS_TIMER), a transaction partner will try to retransmit the
+   message.  The procedure is reiterated until a maximum retry is
+   reached (e.g., three times).  An exception is the last message (e.g.,
+   ACK) sent from the server in a transaction.  After sending this
+   message, the retransmission timer will be disabled since no
+   additional feedback is expected.
+
+   In addition, if the partner receives a retransmission of the last
+   incoming packet it handled, the partner can resend the same answer to
+   the incoming packet with a limited frequency.  If an answer cannot be
+   generated right after the request is received, the partner needs to
+   generate a PROCESSING message as the answer.
+
+   To optimize message retransmission, a partner could also store the
+   last incoming packet and the associated answer.  Note that the times
+   of retransmission could be decided by the local policy, and
+   retransmission will not cause any change of sequence numbers.
+
+12.  Some Operational Guidelines
+
+12.1.  CPNP Server Logging
+
+   The CPNP server should be configurable to log various events and
+   associated information.  Such information may include the following:
+
+   *  Client's IP address
+
+   *  Any event change (e.g., new quotation order, offer sent, order
+      confirmation, order cancellation, order withdrawal, etc.)
+
+   *  Timestamp
+
+   The exact logging details are deployment specific.
+
+12.2.  Business Guidelines and Objectives
+
+   The CPNP server can operate in the following modes:
+
+   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.
+
+   Business guidelines are local to each administrative entity.  How
+   validation requests are presented to an administrator are out of
+   scope of this document; each administrative entity may decide the
+   appropriate mechanism to enable for that purpose.
+
+13.  Security Considerations
+
+   Means to defend the server against denial-of-service attacks must be
+   enabled.  For example, access control lists can be enforced on the
+   client, the server, or the network in between to allow a trusted
+   client to communicate with a trusted server.
+
+   The client and the server must be mutually authenticated.
+   Authenticated encryption must be used for data confidentiality and
+   message integrity.
+
+   The protocol does not provide security mechanisms to protect the
+   confidentiality and integrity of the packets transported between the
+   client and the server.  An underlying security protocol such as
+   (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport
+   Layer Security (TLS) [RFC8446]) must be used to protect the integrity
+   and confidentiality of protocol messages.  In this case, if it is
+   possible to provide automated key management (Section 2.1 of
+   [RFC4107]) and associate each transaction with a different key,
+   inter-transaction replay attacks can naturally be addressed.  If the
+   client and the server use a single key, an additional mechanism
+   should be provided to protect against inter-transaction replay
+   attacks between them.  Clients must implement DTLS record replay
+   detection (Section 3.3 of [RFC6347]) or an equivalent mechanism to
+   protect against replay attacks.
+
+   DTLS and TLS with a cipher suite offering confidentiality protection
+   and the guidance given in [RFC7525] must be followed to avoid attacks
+   on (D)TLS.
+
+   The client must silently discard CPNP responses received from unknown
+   CPNP servers.  The use of a randomly generated Transaction-ID makes
+   it hard to forge a response from a server with a spoofed IP address
+   belonging to a legitimate CPNP server.  Furthermore, CPNP demands
+   that messages from the server must include the correct identifiers of
+   the orders.  Two order identifiers are used: one generated by the
+   client and a second one generated by the server.  Both the CPNP
+   client and server maintain the local identifier they assigned and the
+   one assigned by the peer for a given order.  Means to detect swapping
+   of these identifiers (even when such swapping occurs inadvertently at
+   the client or the server) should be enabled by CPNP clients/servers.
+   For example, the CPNP server should not assign a Provider agreement
+   identifier that is equal to a Customer agreement identifier used by
+   the CPNP client.
+
+   The Provider must enforce the means to protect privacy-related
+   information included in the documents (see Section 8.7) exchanged in
+   CPNP messages [RFC6462].  In particular, this information must not be
+   revealed to external parties without the consent of Customers.
+   Providers should enforce policies to make Customer fingerprinting
+   difficult to achieve (e.g., in a recursion request).  For more
+   discussion about privacy, refer to [RFC6462] [RFC6973].
+
+   The Nonce and the Transaction-ID attributes provide sufficient
+   randomness and can effectively tolerate attacks raised by off-path
+   adversaries, who do not have the capability of eavesdropping and
+   intercepting the packets transported between the client and the
+   server.  Only authorized clients must be able to modify accepted CPNP
+   orders.  The use of a randomly generated Nonce by the server makes it
+   hard to modify an agreement on behalf of a malicious third party.
+
+14.  IANA Considerations
+
+   This document has no IANA actions.
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC3339]  Klyne, G. 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]  Eastlake 3rd, D., Schiller, J., 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]  Farrel, A., "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]  Rescorla, E. 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]  Boucadair, M., Jacquenet, C., and N. Wang, "IP
+              Connectivity Provisioning Profile (CPP)", RFC 7297,
+              DOI 10.17487/RFC7297, July 2014,
+              <https://www.rfc-editor.org/info/rfc7297>.
+
+   [RFC7525]  Sheffer, Y., Holz, R., 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]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+15.2.  Informative References
+
+   [AGAVE]    Boucadair, M., Georgatsos, P., Wang, N., Griffin, D.,
+              Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE
+              Approach for Network Virtualization: Differentiated
+              Services Delivery", Annals of Telecommunication, Volume
+              64, 277-288, DOI 10.1007/s12243-009-0103-4, April 2009,
+              <https://rd.springer.com/article/10.1007/
+              s12243-009-0103-4>.
+
+   [COPS-SLS] Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)",
+              Work in Progress, Internet-Draft, draft-nguyen-rap-cops-
+              sls-03, 5 July 2002, <https://tools.ietf.org/html/draft-
+              nguyen-rap-cops-sls-03>.
+
+   [DSNP]     Chen, J., "Dynamic Service Negotiation Protocol (DSNP)",
+              Work in Progress, Internet-Draft, draft-itsumo-dsnp-03, 2
+              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]
+              Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A.,
+              Jalil, L., and J. Ma, "A Layer 2 VPN Network YANG Model",
+              Work in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-
+              00, 2 July 2020,
+              <https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00>.
+
+   [L3VPN-NETWORK-YANG]
+              Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A.,
+              and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in
+              Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05,
+              16 October 2020, <https://tools.ietf.org/html/draft-ietf-
+              opsawg-l3sm-l3nm-05>.
+
+   [LISP-MS-DISCOVERY]
+              Boucadair, M. and C. Jacquenet, "LISP Mapping Service
+              Discovery at Large", Work in Progress, Internet-Draft,
+              draft-boucadair-lisp-idr-ms-discovery-01, 9 March 2016,
+              <https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms-
+              discovery-01>.
+
+   [NETSLICES-ARCH]
+              Geng, L., Dong, J., Bryant, S., Makhijani, K., Galis, A.,
+              Foy, X. D., and S. Kuklinski, "Network Slicing
+              Architecture", Work in Progress, Internet-Draft, draft-
+              geng-netslices-architecture-02, 3 July 2017,
+              <https://tools.ietf.org/html/draft-geng-netslices-
+              architecture-02>.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., 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]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
+              K., Herzog, S., Reichmeyer, F., Yavatkar, R., 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]  Andersson, L. 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]  Bellovin, S. 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]  El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
+              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]  Saint-Andre, P. 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]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6462]  Cooper, A., "Report from the Internet Privacy Workshop",
+              RFC 6462, DOI 10.17487/RFC6462, January 2012,
+              <https://www.rfc-editor.org/info/rfc6462>.
+
+   [RFC6574]  Tschofenig, H. 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]  Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
+              P., Ma, K., 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]  Vohra, Q. 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]  Farinacci, D., Fuller, V., Meyer, D., 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]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+              Morris, J., Hansen, M., and R. Smith, "Privacy
+              Considerations for Internet Protocols", RFC 6973,
+              DOI 10.17487/RFC6973, July 2013,
+              <https://www.rfc-editor.org/info/rfc6973>.
+
+   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
+              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
+              October 2013, <https://www.rfc-editor.org/info/rfc7049>.
+
+   [RFC7149]  Boucadair, M. 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]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
+              Pascual, J., 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]  King, D. 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]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8259]  Bray, T., Ed., "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]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., 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]  Wu, Q., Liu, W., and A. Farrel, "Service Models
+              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
+              <https://www.rfc-editor.org/info/rfc8309>.
+
+   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., 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]  Wen, B., Fioccola, G., Ed., Xie, C., 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]  Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M.,
+              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]     Wang, X., "A Resource Negotiation and Pricing Protocol
+              (RNAP)",
+              <http://www.cs.columbia.edu/~xinwang/public/projects/
+              protocol.html>.
+
+   [SNAP]     Czajkowski, K., Foster, I., Kesselman, C., Sander, V., and
+              S. Tuecke, "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]     Georgatsos, P. and G. Giannakopoulos, "Service Negotiation
+              Protocol (SrNP)", <https://www.ist-
+              tequila.org/presentations/srnp-pipcm.pdf>.
+
+   [TEAS-SLICE-NBI]
+              Contreras, L. M., Homma, S., and J. A. Ordonez-Lucena,
+              "Considerations for defining a Transport Slice NBI", Work
+              in Progress, Internet-Draft, draft-contreras-teas-slice-
+              nbi-02, 13 July 2020, <https://tools.ietf.org/html/draft-
+              contreras-teas-slice-nbi-02>.
+
+Acknowledgements
+
+   Thanks to Diego R. Lopez, Adrian Farrel, Éric Vyncke, Eric Kline, and
+   Benjamin Kaduk for the comments.
+
+   Thanks to those that reviewed this document for publication in the
+   Independent Stream.
+
+   Special thanks to Luis Miguel Contreras Murillo for the detailed
+   review.
+
+Authors' Addresses
+
+   Mohamed Boucadair (editor)
+   Orange
+   35000 Rennes
+   France
+
+   Email: mohamed.boucadair@orange.com
+
+
+   Christian Jacquenet
+   Orange
+   35000 Rennes
+   France
+
+   Email: christian.jacquenet@orange.com
+
+
+   Dacheng Zhang
+   Huawei Technologies
+
+   Email: dacheng.zhang@huawei.com
+
+
+   Panos Georgatsos
+   Centre for Research and Innovation Hellas
+   78, Filikis Etairias str.
+   38334 Volos
+   Greece
+
+   Phone: +302421306070
+   Email: pgeorgat@gmail.com