Internet DRAFT - draft-boucadair-connectivity-provisioning-protocol
draft-boucadair-connectivity-provisioning-protocol
Network Working Group M. Boucadair, Ed.
Internet-Draft C. Jacquenet
Intended status: Informational Orange
Expires: December 27, 2020 D. Zhang
Huawei Technologies
P. Georgatsos
CERTH
June 25, 2020
Dynamic Service Negotiation
draft-boucadair-connectivity-provisioning-protocol-22
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2020.
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
Boucadair, et al. Expires December 27, 2020 [Page 1]
Internet-Draft CPNP June 2020
(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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. CPNP Functional Elements . . . . . . . . . . . . . . . . . . 6
4. Order Processing Models . . . . . . . . . . . . . . . . . . . 6
5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
6. CPNP Deployment Models . . . . . . . . . . . . . . . . . . . 11
7. CPNP Negotiation Model . . . . . . . . . . . . . . . . . . . 11
8. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Client/Server Communication . . . . . . . . . . . . . . . 14
8.2. Policy Configuration on the CPNP Server . . . . . . . . . 15
8.3. CPNP Session Entries . . . . . . . . . . . . . . . . . . 18
8.4. CPNP Transaction . . . . . . . . . . . . . . . . . . . . 18
8.5. CPNP Timers . . . . . . . . . . . . . . . . . . . . . . . 19
8.6. CPNP Operations . . . . . . . . . . . . . . . . . . . . . 19
8.7. Connectivity Provisioning Documents . . . . . . . . . . . 21
8.8. Child Provisioning Quotation Orders . . . . . . . . . . . 22
8.9. Multi-Segment Service . . . . . . . . . . . . . . . . . . 23
8.10. Negotiating with Multiple CPNP Servers . . . . . . . . . 23
8.11. State Management . . . . . . . . . . . . . . . . . . . . 24
8.11.1. On the Client Side . . . . . . . . . . . . . . . . . 24
8.11.2. On the Server Side . . . . . . . . . . . . . . . . . 27
9. CPNP Objects . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 30
9.1.1. CUSTOMER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 30
9.1.2. PROVIDER_AGREEMENT_IDENTIFIER . . . . . . . . . . . . 30
9.1.3. TRANSACTION_ID . . . . . . . . . . . . . . . . . . . 31
9.1.4. SEQUENCE_NUMBER . . . . . . . . . . . . . . . . . . . 31
9.1.5. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1.6. EXPECTED_RESPONSE_TIME . . . . . . . . . . . . . . . 31
9.1.7. EXPECTED_OFFER_TIME . . . . . . . . . . . . . . . . . 32
9.1.8. VALIDITY_OFFER_TIME . . . . . . . . . . . . . . . . . 32
9.1.9. SERVICE_DESCRIPTION . . . . . . . . . . . . . . . . . 32
9.1.10. CPNP Information Elements . . . . . . . . . . . . . . 33
9.2. Operation Messages . . . . . . . . . . . . . . . . . . . 34
9.2.1. QUOTATION . . . . . . . . . . . . . . . . . . . . . . 35
9.2.2. PROCESSING . . . . . . . . . . . . . . . . . . . . . 35
9.2.3. OFFER . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2.4. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . 38
Boucadair, et al. Expires December 27, 2020 [Page 2]
Internet-Draft CPNP June 2020
9.2.5. DECLINE . . . . . . . . . . . . . . . . . . . . . . . 38
9.2.6. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.2.7. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 40
9.2.8. WITHDRAW . . . . . . . . . . . . . . . . . . . . . . 40
9.2.9. UPDATE . . . . . . . . . . . . . . . . . . . . . . . 41
9.2.10. FAIL . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2.11. ACTIVATE . . . . . . . . . . . . . . . . . . . . . . 44
10. CPNP Message Validation . . . . . . . . . . . . . . . . . . . 45
10.1. On the Client Side . . . . . . . . . . . . . . . . . . . 45
10.2. On the Server Side . . . . . . . . . . . . . . . . . . . 47
11. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 48
11.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 48
11.1.1. Order Negotiation Cycle . . . . . . . . . . . . . . 48
11.1.2. Order Withdrawal Cycle . . . . . . . . . . . . . . . 50
11.1.3. Order Update Cycle . . . . . . . . . . . . . . . . . 50
11.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 50
11.2.1. Order Processing . . . . . . . . . . . . . . . . . . 50
11.2.2. Order Withdrawal . . . . . . . . . . . . . . . . . . 52
11.2.3. Order Update . . . . . . . . . . . . . . . . . . . . 52
11.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 52
11.4. Message Re-Transmission . . . . . . . . . . . . . . . . 53
12. Some Operational Guidelines . . . . . . . . . . . . . . . . . 53
12.1. Logging on the CPNP Server . . . . . . . . . . . . . . . 53
12.2. Business Guidelines and Objectives . . . . . . . . . . . 53
13. Security Considerations . . . . . . . . . . . . . . . . . . . 54
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. Normative References . . . . . . . . . . . . . . . . . . 56
16.2. Informative References . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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 in the service negotiation and activation
procedures, thus fostering the overall service provisioning process.
CPNP can be seen as a component of the dynamic negotiation meta-
domain described in Section 3.4 of [RFC7149].
CPNP is a generic protocol that can be used for other negotiation
purposes than connectivity provisioning. For example, CPNP can be
used to request extra storage resources, to extend the footprint of a
CDN (Content Delivery Networks), to enable additional features from a
cloud Provider, etc. CPNP can be extended with new Information
Boucadair, et al. Expires December 27, 2020 [Page 3]
Internet-Draft CPNP June 2020
Elements (IEs). Sample negotiation use cases are described in
Section 5. Section 4 introduces several order processing models and
precises 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 agreed CPP
will be then passed to other functional elements that are responsible
for the actual service activation and provisioning. For example,
NETCONF [RFC6241] or RESTCONF [RFC8040] can be used to activate
adequate network features that are required to deliver the agreed
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., COPS-SLS [I-D.nguyen-rap-cops-sls],
Service Negotiation Protocol (SrNP) [TEQUILA], Dynamic Service
Negotiation Protocol (DSNP) [I-D.itsumo-dsnp], Resource Negotiation
and Pricing Protocol (RNAP) [Xin], Service Negotiation and
Acquisition Protocol (SNAP) [Karl]). CPNP leverages the experience
of the authors 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 modifying
existing protocols. For example:
o COPS-SLS relies upon COPS-PR [RFC3084], which is an Historic RFC.
o 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.
Boucadair, et al. Expires December 27, 2020 [Page 4]
Internet-Draft CPNP June 2020
2. Terminology
This document makes use of the following terms:
Customer: Is a business role which 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 order 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, force via points).
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 System (AS)) 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.
Boucadair, et al. Expires December 27, 2020 [Page 5]
Internet-Draft CPNP June 2020
An offer may fully or partially meet the requirements of the
corresponding order. In the latter case, it may include
alternative suggestions which 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
Boucadair, et al. Expires December 27, 2020 [Page 6]
Internet-Draft CPNP June 2020
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 he/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 as per Customer's requirements, but rather pre-
designed to address a Customer base that shares the same
requirements (i.e., these customers share the same Customer
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 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 counter-proposals
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:
o Network Provisioning (including Order Activation, Network
Planning, etc.)
o Authentication, Authorization and Accounting (AAA)
Boucadair, et al. Expires December 27, 2020 [Page 7]
Internet-Draft CPNP June 2020
o Network and service management (performance measurement and
assessment, fault detection, etc.)
o Sales-related functional blocks (e.g., billing, invoice
validation)
o 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 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 Model specified in
[I-D.ietf-opsawg-l3sm-l3nm].
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 Model specified in
[I-D.barguil-opsawg-l2sm-l2nm].
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
Boucadair, et al. Expires December 27, 2020 [Page 8]
Internet-Draft CPNP June 2020
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
([I-D.geng-netslices-architecture]) 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 templates inputs as documented in
[I-D.contreras-teas-slice-nbi].
6. CPNP can be used in Machine-to-Machine (M2M) environments to
dynamically subscribe to M2M services (e.g., access to 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 I2NSF ([RFC8329]) to capture
the customer-driven policies to be enforced by a set of Network
Security Functions.
Boucadair, et al. Expires December 27, 2020 [Page 9]
Internet-Draft CPNP June 2020
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 to relax 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
[I-D.boucadair-lisp-idr-ms-discovery].
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
(Mapping System 'A')===(Mapping System 'B')
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
Figure 2: LISP Mapping System Interconnect
Boucadair, et al. Expires December 27, 2020 [Page 10]
Internet-Draft CPNP June 2020
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:
o 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.).
o 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 at Provider sides are out of
the scope of this document.
This document does not make any assumption 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 to
the end of reaching 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 protocol is transparent to the content that it carries and to the
negotiation logic invoked at Customer and Provider sides, and which
manipulates the content (i.e., the information carried in CPNP
messages to proceed with the negotiation).
Boucadair, et al. Expires December 27, 2020 [Page 11]
Internet-Draft CPNP June 2020
The protocol aims at facilitating 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 itself 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 via a
Provision 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 counter-proposal 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. Accepting
the offer by the CPNP client implies a call for agreement; thus
the agreement between both parties and the conclusion of the
negotiation.
+------+ +------+
|Client| |Server|
+------+ +------+
|=====Requested Service=====>|
|<=====Offered Service=======|
|======Agreed Service=======>|
Figure 3: Simplified Service Negotiation
Multiple instances of CPNP may run at Customer's or 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).
Boucadair, et al. Expires December 27, 2020 [Page 12]
Internet-Draft CPNP June 2020
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 an 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., introduction of an additional
VPN site).
Boucadair, et al. Expires December 27, 2020 [Page 13]
Internet-Draft CPNP June 2020
+------+ +------+ +------+ +------+
|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
Means used by a CPNP client to retrieve a list of active/agreed
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
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. Yet, UDP is the default transport mode secured with
Datagram Transport Layer Security (DTLS) [RFC6347]. No permanent
Boucadair, et al. Expires December 27, 2020 [Page 14]
Internet-Draft CPNP June 2020
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, an IP address together with a port number are configured
to the CPNP client, based upon 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 is discussed in Section 11.4 for unreliable
transports.
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:
o Check whether a customer is entitled to initiate a provisioning
quotation request.
o Check whether a customer is entitled to cancel an ongoing order.
o Check whether administrative data (e.g., billing-related
information) have been verified before the processing of the
request starts.
Boucadair, et al. Expires December 27, 2020 [Page 15]
Internet-Draft CPNP June 2020
o Check whether network capacity is available or additional capacity
is required.
o 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.).
o 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.
Boucadair, et al. Expires December 27, 2020 [Page 16]
Internet-Draft CPNP June 2020
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.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:
1. 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 generate corresponding offers.
2. 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 which can be
automatically handled by the server (or are subject to one or
several validation administrative checks) can be configured on
the server.
Boucadair, et al. Expires December 27, 2020 [Page 17]
Internet-Draft CPNP June 2020
8.3. CPNP Session Entries
A CPNP session entry is denoted by a tuple defined as follows:
o Transport session (typically, IP address of the CPNP client,
client's port number, IP address of the CPNP server, and CPNP
server's port number).
o Incremented Sequence Number (Section 11.3)
o 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.
o 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.
o Transaction-ID (Section 8.4).
8.4. CPNP Transaction
A CPNP transaction occurs between a client and a server for
completing, modifying, 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 denoted as 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. Transaction-ID is used for
validating CPNP responses received by the client.
In the context of a transaction, the client needs to randomly select
a sequence number and 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).
Boucadair, et al. Expires December 27, 2020 [Page 18]
Internet-Draft CPNP June 2020
8.5. CPNP Timers
CPNP adopts a simple retransmission procedure which relies on a
retransmission timer denoted as 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 for receiving a
response from the server to a provisioning quotation order request
(see Section 9.1.6). If the timer expires, the respective quotation
order 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 expecting 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.
o QUOTATION (Section 9.2.1):
This operation is used by the client to initiate a provisioning
quotation order. 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.
o PROCESSING (Section 9.2.2):
This operation is used to inform the remote party that the message
(the order quotation or the offer) sent was received and it is
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.
Boucadair, et al. Expires December 27, 2020 [Page 19]
Internet-Draft CPNP June 2020
o 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.
o 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.
o 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 server/client may issue another offer/
order.
o 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
time extension requested (conveyed in a PROCESSING message) by the
server for processing the last received quotation order.
o CANCEL (Section 9.2.7):
This operation is used by the client to cancel (quit) the ongoing
transaction.
o WITHDRAW (Section 9.2.8):
This operation is used by the client to withdraw a completed order
(i.e., an agreement).
o 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.
o FAIL (Section 9.2.10):
Boucadair, et al. Expires December 27, 2020 [Page 20]
Internet-Draft CPNP June 2020
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 received from the server (in a PROCESSING message). The
message includes a status code for providing explanatory
information.
The above CPNP primitives are service-independent. CPNP messages may
transparently carry service-specific objects which are handled by the
negotiation logic at either side.
The document defines the service objects that are required for
connectivity provisioning negotiation (see Section 8.7) purposes.
Additional service-specific objects to be carried in CPNP messages
can be defined in the future for accommodating alternative deployment
schemes or other service provisioning needs.
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 Connectivity Provisioning Document (Requested CPD):
Refers to the CPD included by a CPNP client in a QUOTATION
request.
Offered Connectivity Provisioning Document (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.
Agreed Connectivity Provisioning Document (Agreed 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 3-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 Connectivity Provisioning Documents.
Boucadair, et al. Expires December 27, 2020 [Page 21]
Internet-Draft CPNP June 2020
+------+ +------+
|Client| |Server|
+------+ +------+
|======QUOTATION (Requested CPD)=====>|
|<============PROCESSING==============|
|<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>|
|=========ACCEPT (Agreed CPD)========>|
|<=========ACK (Agreed CPD)===========|
| |
Figure 6: Connectivity Provisioning Documents
A provisioning document can include parameters with fixed values,
loosely-defined values, or any combination thereof. A provisioning
document 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 concrete provisioning document for
calling for the agreement.
8.8. Child Provisioning Quotation Orders
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 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
situation, the server behaves also 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).
Boucadair, et al. Expires December 27, 2020 [Page 22]
Internet-Draft CPNP June 2020
+------+ +--------+ +--------+
|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 recursion must not be activated by the server 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 also
depend on the nature of the service but 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 N connectivity requests at 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.
Boucadair, et al. Expires December 27, 2020 [Page 23]
Internet-Draft CPNP June 2020
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. Timing is therefore an important aspect at
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:
o Created: when the order has been created. It is not handled by
the client until the administrator allows to process it.
o AwaitingProcessing: when the administrator approved the processing
of a created order and the order has not been handled yet.
o PQOSent: when the order has been sent to the server.
o ServerProcessing: when the server has confirmed the receipt of the
order.
o OfferReceived: when an offer has been received from the server.
o OfferProcessing: when a received offer is currently processed by
the client.
Boucadair, et al. Expires December 27, 2020 [Page 24]
Internet-Draft CPNP June 2020
o AcceptSent: when the client confirmed the offer to the server.
o Completed: when the offer is acknowledged by the server.
o Cancelled: when the order has failed or cancelled.
Sub-states may be defined (e.g., to track failed vs. cancelled
orders) but those are not shown in Figure 8.
Boucadair, et al. Expires December 27, 2020 [Page 25]
Internet-Draft CPNP June 2020
+------------------+
| 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)
Boucadair, et al. Expires December 27, 2020 [Page 26]
Internet-Draft CPNP June 2020
8.11.2. On the Server Side
The following lists the states which can be associated with a given
order and a corresponding offer on the server's side:
o PQOReceived: when the order has been received from the client.
o AwaitingProcessing: when the order is being processed by the
server. An action from the server administrator may be needed.
o OfferProposed: when the request has been successfully handled and
an offer has been sent to the client.
o ProcessingReceived: when the server received a PROCESSING for an
offer sent to the client.
o AcceptReceived: when the server received a confirmation for the
offer from the client.
o Completed: when the server 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 retransmitted ACCEPT from the client).
o Cancelled: when the order cannot be accommodated or it has been
cancelled by the client. Associate resources must be released in
the latter case, if previously reserved.
o ChildCreated: when a child order has been created in cases where
resources from another Network Provider are needed.
o ChildPQOSent: when a child order has been sent to the remote
server.
o ChildServerProcessing: when a child order is currently processed
by the remote server.
o ChildOfferReceived: when an offer has been received to a child
order from the remote server.
o ChildOfferProcessing: when a received offer to a child order is
currently processed.
o ChildAcceptSent: when the child offer (offer received from the
remote server in response to a child order) is confirmed to the
remote server.
Boucadair, et al. Expires December 27, 2020 [Page 27]
Internet-Draft CPNP June 2020
o ChildCompleted: when an accepted child offer is acknowledged by
the remote server.
Boucadair, et al. Expires December 27, 2020 [Page 28]
Internet-Draft CPNP June 2020
+------------------+ +------------------+
|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)
Boucadair, et al. Expires December 27, 2020 [Page 29]
Internet-Draft CPNP June 2020
9. CPNP Objects
This section defines CPNP objects using the RBNF format defined at
[RFC5511].
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 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 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_AGREEMENT_IDENTIFIER
CUSTOMER_AGREEMENT_IDENTIFIER is an identifier which is assigned by a
client to identify an agreement. This identifier must be unique to
the client.
Rules for assigning this identifier (including structure and
semantic) are specific to the client (Customer). The value of
CUSTOMER_AGREEMENT_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 CUSTOMER_AGREEMENT_IDENTIFIER as an opaque value.
9.1.2. PROVIDER_AGREEMENT_IDENTIFIER
PROVIDER_AGREEMENT_IDENTIFIER is an identifier which is assigned by a
server to identify an order. This identifier must be unique to the
server.
Rules for assigning this identifier (including structure and
semantic) are specific to the server (Provider).
PROVIDER_AGREEMENT_IDENTIFIER is included in all CPNP messages,
Boucadair, et al. Expires December 27, 2020 [Page 30]
Internet-Draft CPNP June 2020
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 PROVIDER_AGREEMENT_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
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 reply attacks.
Refer to Section 11.3.
9.1.5. NONCE
NONCE is a random value assigned by the CPNP server. It is
recommended to assign unique NONCE values for each order.
NONCE is then mandatory to be included in subsequent CPNP client
operations on the associated order (including the resulting
agreement) such as: withdraw the order or update the order.
If the NONCE validation checks fail, the server rejects the request
with a FAIL message including 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 as rejected.
EXPECTED_RESPONSE_TIME follows the date format specified in
[RFC3339].
Boucadair, et al. Expires December 27, 2020 [Page 31]
Internet-Draft CPNP June 2020
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 as
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.
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 date expires,
the CPNP server will consider the CPNP client has rejected the offer;
the CPNP server will silently remove this order from its base.
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 sub-section.
9.1.9.1. CONNECTIVITY_PROVISIONING_DOCUMENT
The RBNF format of the Connectivity Provisioning Document (CPD) is
shown in Figure 10:
Boucadair, et al. Expires December 27, 2020 [Page 32]
Internet-Draft CPNP June 2020
<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=
<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>
<LOCALISATION>
Figure 10: The RBNF format of the Connectivity Provisioning Document
(CPD)
9.1.10. CPNP Information Elements
An Information Element (IE) is an optional object which can be
included in a CPNP message.
9.1.10.1. Customer Description
The client may include administrative information such as:
o Name
o Contact Information
The format of this Information Element is as follows:
<Customer Description> ::= [<NAME>] [<Contact Information>]
<Contact Information> ::= [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Boucadair, et al. Expires December 27, 2020 [Page 33]
Internet-Draft CPNP June 2020
9.1.10.2. Provider Description
The server may include administrative information in an offer such
as:
o Name
o AS Number ([RFC6793])
o 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:
o 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.
o 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:
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)
Boucadair, et al. Expires December 27, 2020 [Page 34]
Internet-Draft CPNP June 2020
These codes are used to unambiguously identify a CPNP operation; the
operation code is conveyed in the "METHOD_CODE" attribute mentioned
in the following sub-sections.
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_AGREEMENT_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
<REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
A QUOTATION message must include an order identifier which is
generated by the client (CUSTOMER_AGREEMENT_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 is expecting to receive an offer from the server.
QUOTATION message must also include a requested service description
(that is, requested connectivity provisioning document 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 agreed 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>
Boucadair, et al. Expires December 27, 2020 [Page 35]
Internet-Draft CPNP June 2020
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
[<EXPECTED_OFFER_TIME>]
[<PROCESSING_SUBCODE>]
Upon receipt of a QUOTATION message, the server proceeds with 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 which identifies the order in its local order
repository. The server must copy the content of
CUSTOMER_AGREEMENT_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 to that server and which contains the
CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. 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 more time is required by the server 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:
(1) Upgrade of local resources
(2) Request external resources
Boucadair, et al. Expires December 27, 2020 [Page 36]
Internet-Draft CPNP June 2020
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|============ACK(TimeGranted)========>|
...
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|==========ACCEPT(Agreed CPD)========>|
|<==========ACK(Agreed 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_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<VALIDITY_OFFER_TIME>
<OFFERED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
The server answers with an OFFER message to a QUOTATION request
received from the client. The offer will be considered as rejected
by the client if no confirmation (ACCEPT message sent by the client)
is received by the server before the expiration of the validity time.
Boucadair, et al. Expires December 27, 2020 [Page 37]
Internet-Draft CPNP June 2020
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 agreed 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_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<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_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
[<REASON>...]
The client may issue a DECLINE message to reject an offer.
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_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.
Boucadair, et al. Expires December 27, 2020 [Page 38]
Internet-Draft CPNP June 2020
A DECLINE message may include an information element to indicate the
reason for declining an offer. The following codes are defined:
1 (Unacceptable gap between the request and the offer)
2 (Conflict with another offer from another server)
3 (Activation type mismatch)
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_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
[<CONNECTIVITY_PROVISIONING_DOCUMENT>]
[<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.
Boucadair, et al. Expires December 27, 2020 [Page 39]
Internet-Draft CPNP June 2020
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 document as stored
by the server. In particular, the following considerations are taken
into account for connectivity provisioning services:
o A copy of the requested/offered CPD is included by the server if
it successfully handled a CANCEL message.
o A copy of the updated CPD is included by the server if it
successfully handled an UPDATE message.
o 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 "Agreed CPD" in Section 8.7).
o 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_AGREEMENT_IDENTIFIER>
[<CONNECTIVITY_PROVISIONING_DOCUMENT>]
The client can issue a CANCEL message at any stage during the CPNP
negotiation process before an agreement is reached.
CUSTOMER_AGREEMENT_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>
Boucadair, et al. Expires December 27, 2020 [Page 40]
Internet-Draft CPNP June 2020
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
[<AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT>]
[<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_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_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_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<EXPECTED_RESPONSE_TIME>
<REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
Boucadair, et al. Expires December 27, 2020 [Page 41]
Internet-Draft CPNP June 2020
This message is sent by the CPNP client to update an existing service
agreement (e.g., connectivity provisioning agreement). The UPDATE
message must include the same CUSTOMER_AGREEMENT_IDENTIFIER,
PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating
the order. The CPNP client includes a new service description (e.g.,
updated CPD) which 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_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE.
o If no order is found, the CPNP server generates a FAIL error with
the appropriate error code (Section 9.2.10).
o 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, a new UPDATE).
* An OFFER message including the updated clauses (e.g., updated
connectivity provisioning document) 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 as 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
Boucadair, et al. Expires December 27, 2020 [Page 42]
Internet-Draft CPNP June 2020
9.2.10. FAIL
The format of the FAIL message is shown below:
<FAIL Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<STATUS_CODE>
This message is sent in the following cases:
o The server cannot honor an order received from the client (i.e.,
received in a QUOTATION or UPDATE request).
o The server encounters an error when processing a CPNP request
received from the client.
o 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:
1 (Message Validation Error):
The message cannot be validated (see Section 10).
2 (Authentication Required):
The request cannot be handled because authentication is
required.
3 (Authorization Failed):
The request cannot be handled because authorization failed.
4 (Administratively prohibited):
The request cannot be handled because of administrative
policies.
5 (Out of Resources):
The request cannot be honored because resources (e.g., capacity)
are insufficient.
6 (Network Presence Error):
The request cannot be honored because there is no network
presence.
7 (More Time Rejected):
The request to extend the time for negotiation is rejected by
the client.
8 (Unsupported Activation Type):
The request cannot be handled because the requested activation
type is not supported.
Boucadair, et al. Expires December 27, 2020 [Page 43]
Internet-Draft CPNP June 2020
9.2.11. ACTIVATE
The format of the ACTIVATE message is shown below:
<ACTIVATE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_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_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE as those used when creating the order. The CPNP client may
includes 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_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE.
o If no completed order is found, the CPNP server generates a FAIL
error with the appropriate error code (Section 9.2.10).
o 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 de-activation) 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
de-activation of an agreed order.
Figure 16 illustrates the use of ACTIVATE operation.
Boucadair, et al. Expires December 27, 2020 [Page 44]
Internet-Draft CPNP June 2020
+------+ +------+
|Client| |Server|
+------+ +------+
|================ACTIVATE()==========>|
|<==============ACK()=================|
| |
Figure 16: ACTIVATE Flow Example
10. CPNP Message Validation
Both client and server proceed with CPNP message validation. The
following tables summarize the validation checks to be followed.
10.1. On the Client Side
Boucadair, et al. Expires December 27, 2020 [Page 45]
Internet-Draft CPNP June 2020
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, destination IP
(QUOTATION address, destination port number, Transaction-
Transaction) ID, Customer Order Identifier, Provider Order
Identifier, Offered Connectivity Provisioning Order}
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, destination IP
Transaction) address, destination port number, Transaction-
ID, Customer Order Identifier, Provider Order
Identifier, Updated Connectivity Provisioning Order}
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, destination IP
(WITHDRAW address, destination port number, Transaction-
Transaction) ID, Customer Order Identifier, Provider Order
Identifier, Empty Connectivity Provisioning Order}
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.
Boucadair, et al. Expires December 27, 2020 [Page 46]
Internet-Draft CPNP June 2020
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
Order} 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".
Boucadair, et al. Expires December 27, 2020 [Page 47]
Internet-Draft CPNP June 2020
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 state "Completed" for which the
activation procedure is tagged to be explicit.
11. Theory of Operation
Both 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 provisioning quotation order, 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 which includes the assigned identifier, possibly an
expected response time, a Transaction-ID, and a Requested Service
(e.g., Requested Connectivity Provisioning Document). The client may
include additional Information Elements such as Negotiation Options
or Activation Type.
The client may be configured to not enforce negotiation checks on
EXPECTED_OFFER_TIME; if so, no EXPECTED_RESPONSE_TIME attribute (or
EXPECTED_RESPONSE_TIME set to infinite) should be included in the
quotation order.
Once the request is sent to the server, the state of the request is
set to "PQOSent" and a timer, if a response time is included in the
quotation order, 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., 3
times). The same sequence number is used for retransmitted packets.
Boucadair, et al. Expires December 27, 2020 [Page 48]
Internet-Draft CPNP June 2020
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_AGREEMENT_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
grant this extension by issuing an ACK message or reject the time
extension with a FAIL message having 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_AGREEMENT_IDENTIFIER has been received from the server. If
a PROCESSING message was already received for the same order but the
PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included
in the OFFER message, the client silently ignores the message. If a
PROCESSING message having the same PROVIDER_AGREEMENT_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 which
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 by the client, the client may decide to
contact a new server or submit another order to the same server.
Boucadair, et al. Expires December 27, 2020 [Page 49]
Internet-Draft CPNP June 2020
Guidelines to issue an updated order or terminate the negotiation are
specific to the client.
An order can be activated (or de-activated) using the ACTIVATE
message or other agreed 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 Customer Order
Identifier, Provider 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 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.
Subsequent messages 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 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
Boucadair, et al. Expires December 27, 2020 [Page 50]
Internet-Draft CPNP June 2020
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.
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 with a FAIL message having a 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 it can make an offer that
meets only some of the requirements, it creates an OFFER message.
The server must indicate the Transaction-ID, Customer Order
Identifier as indicated in the QUOTATION message, and the Provider
Order Identifier generated for this order. The server must also
include Nonce and the offered service document (e.g., offered
Connectivity Provisioning Document). 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 re-sends 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/DECLINE message is received, the server proceeds with the
cancellation of the order. The state of the order is then passed to
"Cancelled".
Boucadair, et al. Expires December 27, 2020 [Page 51]
Internet-Draft CPNP June 2020
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:
o 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)).
o If the checks succeed, the server clears the clauses of the
Connectivity Provisioning Document, changes the state of the order
to "Cancelled", and sends back an ACK message with an Empty
Connectivity Provisioning Document.
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:
o 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)).
o 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.
Boucadair, et al. Expires December 27, 2020 [Page 52]
Internet-Draft CPNP June 2020
11.4. Message Re-Transmission
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 re-transmit the
message. The procedure is reiterated until a maximum retry is
reached (e.g., 3 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 a last
incoming packet it handled, the partner can re-send the same answer
to the incoming packet with a limited frequency. If no answer was
generated at the moment, 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. Logging on the CPNP Server
The CPNP server should be configurable to log various events and
associated information. Such information may include:
o Client's IP address
o Any event change (e.g., new quotation order, offer sent, order
confirm, order cancellation, order withdraw, etc.)
o Timestamp
The exact logging details are deployment-specific.
12.2. Business Guidelines and Objectives
The CPNP server can operate in the following modes:
1. 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/invalidate an order request. The set of policies to be
Boucadair, et al. Expires December 27, 2020 [Page 53]
Internet-Draft CPNP June 2020
configured to the CPNP server are specific to each administrative
entity managing a CPNP server.
2. Administrative-based mode:
This mode assumes some or all CPNP server' 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 which 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 an Automated Key Management 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
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
Boucadair, et al. Expires December 27, 2020 [Page 54]
Internet-Draft CPNP June 2020
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 by inadvertence
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 means to protect privacy-related
information included 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 agreed 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 does not request any IANA action.
15. Acknowledgements
Thanks to Diego R. Lopez, Adrian Farrel, Eric Vyncke, Eric Kline,
and Benjamin Kaduk for the comments.
Thanks to the ISE reviewers.
Special thanks to Luis Miguel Contreras Murillo for the detailed
review.
16. References
Boucadair, et al. Expires December 27, 2020 [Page 55]
Internet-Draft CPNP June 2020
16.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>.
16.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", April 2009,
<https://rd.springer.com/article/10.1007/
s12243-009-0103-4>.
[ETICS] EU FP7 ETICS Project, "Economics and Technologies of
Inter-Carrier Services", January 2014, <https://www.ict-
etics.eu/fileadmin/documents/news/
ETICS_white_paper_final.pdf>.
Boucadair, et al. Expires December 27, 2020 [Page 56]
Internet-Draft CPNP June 2020
[I-D.barguil-opsawg-l2sm-l2nm]
Barguil, S., Dios, O., Boucadair, M., Munoz, L., Jalil,
L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-
barguil-opsawg-l2sm-l2nm-02 (work in progress), May 2020.
[I-D.boucadair-lisp-idr-ms-discovery]
Boucadair, M. and C. Jacquenet, "LISP Mapping Service
Discovery at Large", draft-boucadair-lisp-idr-ms-
discovery-01 (work in progress), March 2016.
[I-D.contreras-teas-slice-nbi]
Contreras, L., Homma, S., and J. Ordonez-Lucena,
"Considerations for defining a Transport Slice NBI",
draft-contreras-teas-slice-nbi-01 (work in progress),
March 2020.
[I-D.geng-netslices-architecture]
67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com,
k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing
Architecture", draft-geng-netslices-architecture-02 (work
in progress), July 2017.
[I-D.ietf-opsawg-l3sm-l3nm]
Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A.
Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
opsawg-l3sm-l3nm-03 (work in progress), April 2020.
[I-D.itsumo-dsnp]
Chen, J., "Dynamic Service Negotiation Protocol (DSNP)",
draft-itsumo-dsnp-03 (work in progress), March 2006.
[I-D.nguyen-rap-cops-sls]
Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)",
draft-nguyen-rap-cops-sls-03 (work in progress), July
2002.
[Karl] 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",
<http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.19.5907>.
[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>.
Boucadair, et al. Expires December 27, 2020 [Page 57]
Internet-Draft CPNP June 2020
[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>.
[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>.
Boucadair, et al. Expires December 27, 2020 [Page 58]
Internet-Draft CPNP June 2020
[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>.
Boucadair, et al. Expires December 27, 2020 [Page 59]
Internet-Draft CPNP June 2020
[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>.
[TEQUILA] Georgatsos, P. and G. Giannakopoulos, "Service Negotiation
Protocol (SrNP)", <https://www.ist-
tequila.org/presentations/srnp-pipcm.pdf>.
[Xin] Wang, X., "Resource Negotiation and Pricing Protocol
(RNAP)",
<http://www.cs.columbia.edu/~xinwang/public/projects/
protocol.html>.
Authors' Addresses
Mohamed Boucadair (editor)
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Dacheng Zhang
Huawei Technologies
Email: dacheng.zhang@huawei.com
Boucadair, et al. Expires December 27, 2020 [Page 60]
Internet-Draft CPNP June 2020
Panos Georgatsos
Centre for Research and Innovation
Hellas
78, Filikis Etairias str.
Volos, Hellas 38334
Greece
Phone: +302421306070
Email: pgeorgat@gmail.com
Boucadair, et al. Expires December 27, 2020 [Page 61]
