diff options
Diffstat (limited to 'doc/rfc/rfc8921.txt')
| -rw-r--r-- | doc/rfc/rfc8921.txt | 2733 |
1 files changed, 2733 insertions, 0 deletions
diff --git a/doc/rfc/rfc8921.txt b/doc/rfc/rfc8921.txt new file mode 100644 index 0000000..e4b1e76 --- /dev/null +++ b/doc/rfc/rfc8921.txt @@ -0,0 +1,2733 @@ + + + + +Independent Submission M. Boucadair, Ed. +Request for Comments: 8921 C. Jacquenet +Category: Informational Orange +ISSN: 2070-1721 D. Zhang + Huawei Technologies + P. Georgatsos + CERTH + October 2020 + + + Dynamic Service Negotiation: The Connectivity Provisioning Negotiation + Protocol (CPNP) + +Abstract + + This document defines the Connectivity Provisioning Negotiation + Protocol (CPNP), which is designed to facilitate the dynamic + negotiation of service parameters. + + CPNP is a generic protocol that can be used for various negotiation + purposes that include (but are not necessarily limited to) + connectivity provisioning services, storage facilities, Content + Delivery Networks, etc. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8921. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. CPNP Functional Elements + 4. Order Processing Models + 5. Sample Use Cases + 6. CPNP Deployment Models + 7. CPNP Negotiation Model + 8. Protocol Overview + 8.1. Client/Server Communication + 8.2. Policy Configuration on the CPNP Server + 8.3. CPNP Session Entries + 8.4. CPNP Transactions + 8.5. CPNP Timers + 8.6. CPNP Operations + 8.7. Connectivity Provisioning Documents + 8.8. Child PQOs + 8.9. Multi-Segment Service + 8.10. Negotiating with Multiple CPNP Servers + 8.11. State Management + 8.11.1. On the Client Side + 8.11.2. On the Server Side + 9. CPNP Objects + 9.1. Attributes + 9.1.1. CUSTOMER_ORDER_IDENTIFIER + 9.1.2. PROVIDER_ORDER_IDENTIFIER + 9.1.3. TRANSACTION_ID + 9.1.4. SEQUENCE_NUMBER + 9.1.5. NONCE + 9.1.6. EXPECTED_RESPONSE_TIME + 9.1.7. EXPECTED_OFFER_TIME + 9.1.8. VALIDITY_OFFER_TIME + 9.1.9. SERVICE_DESCRIPTION + 9.1.10. CPNP Information Elements + 9.2. Operation Messages + 9.2.1. QUOTATION + 9.2.2. PROCESSING + 9.2.3. OFFER + 9.2.4. ACCEPT + 9.2.5. DECLINE + 9.2.6. ACK + 9.2.7. CANCEL + 9.2.8. WITHDRAW + 9.2.9. UPDATE + 9.2.10. FAIL + 9.2.11. ACTIVATE + 10. CPNP Message Validation + 10.1. On the Client Side + 10.2. On the Server Side + 11. Theory of Operation + 11.1. Client Behavior + 11.1.1. Order Negotiation Cycle + 11.1.2. Order Withdrawal Cycle + 11.1.3. Order Update Cycle + 11.2. Server Behavior + 11.2.1. Order Processing + 11.2.2. Order Withdrawal + 11.2.3. Order Update + 11.3. Sequence Numbers + 11.4. Message Retransmission + 12. Some Operational Guidelines + 12.1. CPNP Server Logging + 12.2. Business Guidelines and Objectives + 13. Security Considerations + 14. IANA Considerations + 15. References + 15.1. Normative References + 15.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + This document defines the Connectivity Provisioning Negotiation + Protocol (CPNP) that is meant to dynamically exchange and negotiate + connectivity provisioning parameters and other service-specific + parameters between a Customer and a Provider. CPNP is a tool that + introduces automation to the service negotiation and activation + procedures, thus fostering the overall service provisioning process. + CPNP can be seen as a component of the dynamic negotiation metadomain + described in Section 2.4 of [RFC7149]. + + CPNP is a generic protocol that can be used for negotiation purposes + other than connectivity provisioning. For example, CPNP can be used + to request extra storage resources, to extend the footprint of a + Content Delivery Network (CDN), to enable additional features from a + cloud Provider, etc. CPNP can be extended with new Information + Elements (IEs). Sample negotiation use cases are described in + Section 5. Section 4 introduces several order processing models and + defines those that are targeted by CPNP. The CPNP negotiation model + is then detailed in Section 7. + + [RFC7297] describes a Connectivity Provisioning Profile (CPP) + template to capture connectivity requirements to be met by a + transport infrastructure for the delivery of various services such as + Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) + services [RFC4026]. The CPP document defines the set of IP transfer + parameters that reflect the guarantees that can be provided by the + underlying transport network together with reachability scope and + capacity needs. CPNP uses the CPP template to encode connectivity + provisioning clauses that are subject to negotiation. The accepted + CPP will then be passed to other functional elements that are + responsible for the actual service activation and provisioning. For + example, Network Configuration Protocol (NETCONF) [RFC6241] or + RESTCONF [RFC8040] can be used to activate adequate network features + that are required to deliver the accepted service. How the outcome + of CPNP negotiation is translated into service and network + provisioning actions is out of scope of this document. + + As a reminder, several proposals have been made in the past by the + (research) community (e.g., Common Open Policy Service protocol for + supporting Service Level Specification [COPS-SLS], Service + Negotiation Protocol [SrNP], Dynamic Service Negotiation Protocol + [DSNP], Resource Negotiation and Pricing Protocol [RNAP], Service + Negotiation and Acquisition Protocol [SNAP]). CPNP leverages the + authors' experience with SrNP by separating the negotiation + primitives from the service under negotiation. Moreover, careful + examination of the other proposals revealed certain deficiencies that + were easier to address through the creation of a new protocol rather + than the modification of existing protocols. For example: + + * COPS-SLS relies upon the COPS usage for policy provisioning (COPS- + PR) [RFC3084], which is a Historic RFC. + + * DSNP is tightly designed with one specific service in mind (QoS) + and does not make any distinction between a quotation phase and + the actual service-ordering phase. + + One of the primary motivations of this document is to provide a + permanent reference to exemplify how service negotiation can be + automated. + + Implementation details are out of scope. An example of required + modules and interfaces to implement this specification is sketched in + Section 4 of [AGAVE]. This specification builds on that effort. + +2. Terminology + + This document makes use of the following terms: + + Customer: Is a business role that denotes an entity that is involved + in the definition and the possible negotiation of an order, + including a Connectivity Provisioning Agreement, with a Provider. + A connectivity provisioning document is captured in a dedicated + CPP template-based document, which may specify (among other + information) the sites to be connected, border nodes, outsourced + operations (e.g., routing, traffic steering). + + The right to invoke the subscribed service may be delegated by the + Customer to third-party end users or brokering services. + + A Customer can be a Service Provider, an application owner, an + enterprise, a user, etc. + + Network Provider (or Provider): Owns and administers one or many + transport domain(s) (typically Autonomous Systems (ASes)) composed + of (IP) switching and transmission resources (e.g., routing, + switching, forwarding, etc.). Network Providers are responsible + for delivering and operating connectivity services (e.g., offering + global or restricted reachability at specific rates). Offered + connectivity services may not necessarily be restricted to IP. + + The policies to be enforced by the connectivity service delivery + components can be derived from the technology-specific clauses + that might be included in agreements with the Customers. If no + such clauses are included in the agreement, the mapping between + the connectivity requirements and the underlying technology- + specific policies to be enforced is deployment specific. + + Quotation Order: Denotes a request made by the Customer to the + Provider that includes a set of requirements. The Customer may + express its service-specific requirements by assigning (strictly + or loosely defined) values to the information items included in + the commonly understood template (e.g., CPP template) describing + the offered service. These requirements constitute the parameters + to be mutually agreed upon. + + Offer: Refers to a response made by the Provider to a Customer's + quotation order that describes the ability of the Provider to + satisfy the order at the time of its receipt. Offers reflect the + capability of the Provider in accommodating received Customer + orders beyond monolithic 'yes/no' answers. + + An offer may fully or partially meet the requirements of the + corresponding order. In the latter case, it may include + alternative suggestions that the Customer may take into account by + issuing a new order. + + Agreement: Refers to an order placed by the Customer and accepted by + the Provider. It signals the successful conclusion of a + negotiation cycle. + +3. CPNP Functional Elements + + The following functional elements are defined: + + CPNP client (or client): Denotes a software instance that sends CPNP + requests and receives CPNP responses. The current operations that + can be performed by a CPNP client are listed below: + + 1. Create a quotation order (Section 9.2.1). + + 2. Cancel an ongoing quotation order under negotiation + (Section 9.2.7). + + 3. Accept an offer made by a server (Section 9.2.4). + + 4. Withdraw an agreement (Section 9.2.8). + + 5. Update an agreement (Section 9.2.9). + + CPNP server (or server): Denotes a software instance that receives + CPNP requests and sends back CPNP responses accordingly. The CPNP + server is responsible for the following operations: + + 1. Process a quotation order (Section 9.2.2). + + 2. Make an offer (Section 9.2.3). + + 3. Cancel an ongoing quotation order (Section 11.2.3). + + 4. Process an order withdrawal (Section 11.2.3). + +4. Order Processing Models + + For preparing their service orders, Customers may need to be aware of + the offered services. Therefore, Providers should first proceed with + the announcement (or the exposure) of the services they can provide. + The service announcement process may take place at designated global + or Provider-specific service markets or through explicit interactions + with the Providers. The details of this process are outside the + scope of this document. + + With or without such service announcement/exposure mechanisms in + place, the following order processing models can be distinguished: + + Frozen model: + The Customer cannot actually negotiate the parameters of the + service(s) offered by a Provider. After consulting the Provider's + service portfolio, the Customer selects the service offer to which + he or she wants to subscribe and places an order to the Provider. + Order handling is quite simple on the Provider side because the + service is not customized per Customer's requirements, but rather + designed to address a Customer base that shares the same + requirements (i.e., these Customers share the same Connectivity + Provisioning Profile). This mode can be implemented using + existing tools such as [RFC8309]. + + Negotiation-based model: + Unlike the frozen model, the Customer documents his/her + requirements in a request for a quotation, which is then sent to + one or several Providers. Solicited Providers check whether they + can address these requirements or not, and get back to the + Customer accordingly, possibly with an offer that may not exactly + match the Customer's requirements (e.g., a 100 Mbps connection + cannot be provisioned given the amount of available resources, but + an 80 Mbps connection can be provided). A negotiation between the + Customer and the Provider(s) then follows until both parties reach + an agreement (or do not). + + Both frozen and negotiation-based models require the existence of + appropriate service templates like a CPP template and their + instantiation for expressing specific offerings from Providers and + service requirements from Customers, respectively. CPNP can be used + in either model for automating the required Customer-Provider + interactions. The frozen model can be seen as a special case of the + negotiation-based model. This document focuses on the negotiation- + based model. Not only 'yes/no' answers but also counterproposals may + be offered by the Provider in response to Customer orders. + + Order processing management on the Network Provider's side usually + solicits features supported by the following functional blocks: + + * Network provisioning (including order activation, Network + Planning, etc.) + + * Authentication, authorization, and accounting (AAA) + + * Network and service management (performance measurement and + assessment, fault detection, etc.) + + * Sales-related functional blocks (e.g., billing, invoice + validation) + + * Network impact analysis + + CPNP does not assume any specific knowledge about these functional + blocks, drawing an explicit line between protocol operation and the + logic for handling connectivity provisioning requests. An order + processing logic is typically fed with the information manipulated by + the aforementioned functional blocks. For example, the resources + that can be allocated to accommodate the Customer's requirements may + depend on network availability estimates as calculated by the + planning functions and related policies, as well as the number of + orders to be processed simultaneously over a given period of time. + + This document does not elaborate on how Customers are identified and + subsequently managed by the Provider's information system. + +5. Sample Use Cases + + A non-exhaustive list of CPNP use cases is provided below: + + 1. [RFC4176] introduces the Layer 3 VPN (L3VPN) Service Order + Management functional block, which is responsible for managing + the requests initiated by the Customers and tracks the status of + the completion of the related operations. CPNP can be used + between the Customer and the Provider to negotiate L3VPN service + parameters. + + A CPNP server could therefore be part of the L3VPN Service Order + Management functional block discussed in [RFC4176]. A L3VPN + Service YANG data model (L3SM) is defined in [RFC8299]. Once an + agreement is reached, the service can be provisioned using, + e.g., the L3VPN Network YANG data model specified in + [L3VPN-NETWORK-YANG]. + + Likewise, a CPNP server could be part of the Layer 2 VPN (L2VPN) + Service Order Management functional block. A YANG data model + for L2VPN service delivery is defined in [RFC8466]. Once an + agreement is reached, the L2VPN service can be provisioned + using, e.g., the L2VPN Network YANG data model specified in + [L2VPN-NETWORK-YANG]. + + 2. CPNP can be used between two adjacent domains to deliver IP + interconnection services (e.g., enable, update, disconnect). + For example, two Autonomous Systems (ASes) can be connected via + several interconnection points. CPNP can be used between these + ASes to upgrade existing links, request additional resources, + provision a new interconnection point, etc. + + See, for example, the framework documented in [ETICS]. + + 3. An integrated Provider can use CPNP to rationalize connectivity + provisioning needs related to its service portfolio. A CPNP + server function is used by network operations teams. A CPNP + interface to trigger CPNP negotiation cycles is exposed to + service management teams. + + 4. Service Providers can use CPNP to initiate connectivity + provisioning requests towards a number of Network Providers so + as to optimize the cost of delivering their services. Although + multiple CPNP ordering cycles can be initiated by a Service + Provider towards multiple Network Providers, a subset of these + orders may actually be put into effect. + + For example, a cloud Service Provider can use CPNP to request + more resources from Network Providers. + + 5. CPNP can also be used in the context of network slicing + [NETSLICES-ARCH] to request network resources together with a + set of requirements that need to be satisfied by the Provider. + Such requirements are not restricted to basic IP forwarding + capabilities, but may also include a characterization of a set + of service functions that may be invoked. For the network + slicing case, the instances of a CPP template could be derived + from the network slice template documented in [TEAS-SLICE-NBI]. + + 6. CPNP can be used in Machine-to-Machine (M2M) environments to + dynamically subscribe to M2M services (e.g., access data + retrieved by a set of sensors, extend sensor coverage, etc.). + + Also, Internet of Things (IoT) [RFC6574] domains may rely on + CPNP to enable dynamic access to data produced by involved + objects, according to their specific policies, to various + external stakeholders such as data analytics and business + intelligence companies. Direct CPNP-based interactions between + IoT domains and interested parties enable open access to diverse + sets of data across the Internet, e.g., from multiple types of + sensors, user groups, and/or geographical areas. + + 7. CPNP can be used in the context of Interface to Network Security + Functions (I2NSF) [RFC8329] to capture the Customer-driven + policies to be enforced by a set of Network Security Functions. + + 8. A Provider offering cloud services can expose a CPNP interface + to allow Customers to dynamically negotiate typical data center + resources, such as additional storage, processing and networking + resources, enhanced security filters, etc. + + Cloud computing Providers typically structure their computation + service offerings by bundling CPU, RAM, and storage units as + quotas, instances, or flavors that can be consumed in an + ephemeral or temporal fashion during the lifetime of the + required function. A similar approach is followed by CPNP (see + for example, Section 9.2.11). + + 9. In the inter-cloud context (also called cloud of clouds or cloud + federation), CPNP can be used to reserve computing and + networking resources hosted by various cloud infrastructures. + + 10. CDN Providers can use CPNP to extend their footprint by + interconnecting their respective CDN infrastructures [RFC6770] + (see Figure 1). + + ,--,--,--. ,--,--,--. + ,-' `-. ,-' `-. + (CDN Provider 'A')=====(CDN Provider 'B') + `-. (CDN-A) ,-' `-. (CDN-B) ,-' + `--'--'--' `--'--'--' + + Figure 1: CDN Interconnection + + 11. Mapping Service Providers (MSPs) [RFC7215] can use CPNP to + enrich their mapping database by interconnecting their mapping + system (see Figure 2). This interconnection allows the + relaxation of the constraints on PxTR (Proxy Ingress/Egress + Tunnel Router) in favour of native LISP (Locator/ID Separation + Protocol) forwarding [RFC6830]. Also, it prevents the + fragmentation of the LISP mapping database. A framework is + described in [LISP-MS-DISCOVERY]. + + ,--,--,--. ,--,--,--. + ,-' `-. ,-' `-. + (Mapping System 'A')===(Mapping System 'B') + `-. ,-' `-. ,-' + `--'--'--' `--'--'--' + + Figure 2: LISP Mapping System Interconnect + + 12. CPNP may also be used between SDN (Software-Defined Networking) + controllers in contexts where Cooperating Layered Architecture + for Software-Defined Networking (CLAS) is enabled [RFC8597]. + +6. CPNP Deployment Models + + Several CPNP deployment models can be envisaged. Two examples are + listed below: + + * The Customer deploys a CPNP client while one or several CPNP + servers are deployed by the Provider. A CPNP client can discover + its CPNP servers using a variety of means (static, dynamic, etc.). + + * The Customer does not enable any CPNP client. The Provider + maintains a Customer Order Management portal. The Customer can + initiate connectivity provisioning quotation orders via the + portal; appropriate CPNP messages are then generated and sent to + the relevant CPNP server. In this model, both the CPNP client and + CPNP server are under the responsibility of the same + administrative entity (i.e., Network Provider). + + Once the negotiation of connectivity provisioning parameters is + successfully concluded, that is, an order has been placed by the + Customer, the actual network provisioning operations are initiated. + The specification of related dynamic resource allocation and policy + enforcement schemes, as well as how CPNP servers interact with the + network provisioning functional blocks on the Provider side, are out + of the scope of this document. + + This document does not make any assumptions about the CPNP deployment + model either. + +7. CPNP Negotiation Model + + CPNP runs between a Customer and a Provider, carrying service orders + from the Customer and corresponding responses from the Provider in + order to reach a service provisioning agreement. As the services + offered by the Provider are well described, by means of the CPP + template for connectivity matters, the negotiation process is + essentially a value-settlement process, where an agreement is pursued + on the values of the commonly understood information items (service + parameters) included in the service description template + (Section 9.1.9). + + The content that CPNP carries and the negotiation logic invoked at + Customer and Provider sides to manipulate the content (i.e., the + information carried in CPNP messages to proceed with the negotiation) + is transparent to the protocol. + + The protocol aims to facilitate the execution of the negotiation + logic by providing the required generic communication primitives. + + Since negotiations are initiated and primarily driven by the + Customer's negotiation logic, it is reasonable to assume that the + Customer is the only party that can call for an agreement. An + implicit approach is adopted for not overloading the protocol with + additional messages. In particular, the acceptance of an offer made + by the Provider signals a call for agreement from the Customer. Note + that it is almost certain the Provider will accept this call since it + refers to an offer that the Provider made. Of course, at any point + the Provider or the Customer may quit the negotiations, each on its + own grounds. + + Based on the above, CPNP adopts a quotation order/offer/answer model, + which proceeds through the following basic steps (Figure 3): + + 1. The CPNP client specifies its service requirements in a + Provisioning Quotation Order (PQO). The order may include + strictly or loosely defined values in the clauses describing + service provisioning characteristics. + + 2. The CPNP server declines the PQO, or makes an offer to address + the requirements of the PQO, or suggests a counterproposal that + partially addresses the requirements of the PQO in case specific + requirements cannot be accommodated. + + 3. The CPNP client either accepts or declines the offer. The + acceptance of the offer by the CPNP client implies a call for + agreement and, thus, the agreement between both parties and the + conclusion of the negotiation. + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |=====Requested Service=====>| + |<=====Offered Service=======| + |=====Accepted Service======>| + + Figure 3: Simplified Service Negotiation + + Multiple instances of CPNP may run at a Customer's or a Provider's + domains. A CPNP client may be engaged in multiple, simultaneous + negotiations with the same or different CPNP servers (parallel + negotiations, see Section 8.10), and a CPNP server may need to + negotiate with other Provider(s) as part of negotiations that are + ongoing with a CPNP client (cascaded negotiations, see Section 8.8). + + CPNP relies on various timers to run its operations. Two types of + timers are defined: those that are specific to CPNP message + transmission and those that are specific to the negotiation logic. + The latter are used to guide the negotiation logic at both CPNP + client and CPNP server sides, particularly in cases where the CPNP + client is involved in parallel negotiations with several CPNP servers + or in cases where the CPNP server is, in turn, involved in + negotiations with other Providers for processing a given Customer- + originated quotation order. CPNP allows a CPNP server to request + extra time to proceed with the negotiation. This request may be + accepted or rejected by the CPNP client. + + Providers may need to publish available services to the Customers + (see Section 4). CPNP may optionally support this functionality. + Dedicated templates can be defined for the purpose of service + announcement, which will be used by the CPNP clients to initiate + their CPNP negotiation cycles. + + For the sake of simplicity, a single offer/answer stage is assumed + within one CPNP negotiation cycle. Nevertheless, as already stated, + multiple CPNP negotiation cycles can be undertaken by a CPNP client + (see Figure 4). + + The model is flexible enough to accommodate changing conditions + during the lifetime of a service (e.g., the introduction of an + additional VPN site). + + +------+ +------+ +------+ +------+ + |Client| |Server| |Client| |Server| + +------+ +------+ +------+ +------+ + |=====Quotation Order=====>| |=====Quotation Order=====>| + |<==========Offer==========| |<==========Offer==========| + |===========Accept========>| |==========Decline========>| + + 1-Step Successful Negotiation 1-Step Failed Negotiation + Cycle Cycle + + +------+ +------+ +------+ +------+ + |Client| |Server| |Client| |Server| + +------+ +------+ +------+ +------+ + |===Quotation Order(a)====>| |===Quotation Order(i)====>| + |<==========Offer==========| |<==========Offer==========| + |==========Decline========>| |==========Decline========>| + |===Quotation Order(b)====>| |===Quotation Order(j)====>| + |<==========Offer==========| |<==========Offer==========| + |===========Accept========>| |==========Decline========>| + |===Quotation Order(k)====>| + |<==========Offer==========| + |==========Decline========>| + |===Quotation Order(l)====>| + |<==Fail to make an offer==| + + N-Step Negotiation Cycle: N-Step Negotiation Cycle: + Successful Negotiation Failed Negotiation + + Figure 4: Overall Negotiation Process + + The means used by a CPNP client to retrieve a list of active/accepted + offers are not defined in this document. + + An order can be implicitly or explicitly activated. Section 3.11 of + [RFC7297] specifies a dedicated clause called Activation Means. Such + a clause indicates the required action(s) to be undertaken to + activate access to the (IP connectivity) service. This document + defines a dedicated CPNP message that can be used for explicit + activation (Section 9.2.11). + +8. Protocol Overview + +8.1. Client/Server Communication + + CPNP is a client/server protocol that can run over any transport + protocol. The default transport mode is UDP secured with Datagram + Transport Layer Security (DTLS) [RFC6347]. No permanent CPNP + transport session needs to be maintained between the client and the + server. + + The CPNP client can be configured with the CPNP server(s). + Typically, the CPNP client is configured with an IP address together + with a port number using manual or dynamic configuration means (e.g., + DHCP). Alternatively, a Provider may advertise the port number + (CPNP_PORT) it uses to bind the CPNP service using SRV [RFC2782]. + + The CPNP client may be provided with a domain name of the CPNP server + for PKIX-based authentication purposes. CPNP servers should prefer + the use of DNS-ID and SRV-ID over CN-ID identifier types in + certificate requests (Section 2.3 of [RFC6125]). URI-IDs should not + be used for CPNP server identity verification. + + The client sends CPNP requests using CPNP_PORT as the destination + port number. The same port number used as the source port number of + a CPNP request sent to a CPNP server is used by the server to reply + to that request. + + CPNP is independent of the IP address family. + + CPNP retransmission for unreliable transports is discussed in + Section 11.4. + + Considerations related to mutual authentication are discussed in + Section 13. + +8.2. Policy Configuration on the CPNP Server + + As an input to its decision-making process, the CPNP server may be + connected to various external modules such as Customer Profiles, + Network Topology, Network Resource Management, Order Repositories, + AAA, and Network Provisioning Manager (an example is shown in + Figure 5). + + These external modules provide inputs to the CPNP server so that it + can do the following: + + * Check whether a Customer is entitled to initiate a provisioning + quotation request. + + * Check whether a Customer is entitled to cancel an ongoing order. + + * Check whether administrative data (e.g., billing-related + information) have been verified before the processing of the + request starts. + + * Check whether network capacity is available or additional capacity + is required. + + * Receive guidelines from network design and sales blocks (e.g., + pricing, network usage levels, thresholds associated with the + number of CPP templates that can be processed over a given period + of time as a function of the nature of the service to be + delivered, etc.). + + * Transfer completed orders to network provisioning blocks (referred + to as "Network Provisioning Manager" in Figure 5). For example, + the outcome of CPNP may be passed to modules such as Application- + Based Network Operations (ABNO) [RFC7491] or network controllers. + These controllers will use protocols such as NETCONF [RFC6241] to + interact with the appropriate network nodes and functions for the + sake of proper service activation and delivery. + + The above list of CPNP server operations is not exhaustive. + + . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + .Business & Administrative Management . + .+------------------------++---------------------------+. + .| Business Guidelines || Billing & Charging |. + .+-----------+------------++-----------+---------------+. + . | | . + . +-------------------+ | . + . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . + . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . + .Order Handling Management | | . + . +-------------------+ +-------+-----+--------------+ . + . |Network Topology DB+--+ CPNP Server | . + . +-------------------+ +-+---+---+---+---+-----+----+ . + . | | | | | | . + . +------------------------+-+ | | | | | . + . | Network Dimensioning | | | | | | . + . | & Planning | | | | | | . + . +--------------------------+ | | | | | . + . +----------------------------+-+ | | | +---+----+ . + . | | | | | | AAA | . + . | Network +------------+ | | | +--------+ . + . | Resource | +------------+-+ | +-+----------+ . + . | Management | | Customer | | | Orders | . + . | | | Profiles | | | Repository | . + . +-----------------+ +--------------+ | +------------+ . + . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . + +--------------------------------------+----------------+ + | Network Provisioning Manager | + +-------------------------------------------------------+ + + Figure 5: Order Handling Management Functional Block (Focus on + Internal Interfaces) + + The following order-handling modes can also be configured on the + server: + + Fully automated mode: This mode does not require any action from the + administrator when receiving a request for a service. The server + can execute its decision-making process related to the orders + received and can generate corresponding offers. + + Administrative validation checking: Some or all of the server's + operations are subject to administrative validation procedures. + This mode requires an action from the administrator for every + request received. To that aim, the CPNP methods that can be + automatically handled by the server (or are subject to one or + several validation administrative checks) can be configured on the + server. + +8.3. CPNP Session Entries + + A CPNP session entry is represented by a tuple defined as follows: + + * Transport session (typically, the IP address of the CPNP client, + the client's port number, the IP address of the CPNP server, and + the CPNP server's port number). + + * Incremented sequence number (Section 11.3). + + * Customer agreement identifier: This is a unique identifier + assigned to the order under negotiation by the CPNP client + (Section 9.1.1). This identifier is also used by the client to + identify the agreement that will result from a successful + negotiation. + + * Provider agreement identifier: This is a unique identifier + assigned to the order under negotiation by the CPNP server + (Section 9.1.2). This identifier is also used by the server to + identify the agreement that will result from a successful + negotiation. + + * Transaction-ID (Section 8.4). + +8.4. CPNP Transactions + + A CPNP transaction occurs between a client and a server for + completing, modifying, or withdrawing a service agreement, and + comprises all CPNP messages exchanged between the client and the + server, from the first request sent by the client to the final + response sent by the server. A CPNP transaction is bound to a CPNP + session (Section 8.3). + + Because multiple CPNP transactions can be maintained by the CPNP + client, the client must assign an identifier to uniquely identify a + given transaction. This identifier is the Transaction-ID. + + The Transaction-ID must be randomly assigned by the CPNP client, + according to the best current practice for generating random numbers + [RFC4086] that cannot be guessed easily. The Transaction-ID is used + for validating CPNP responses received by the client. + + In the context of a transaction, the client needs to select a + sequence number randomly and then needs to assign it to the first + CPNP message to send. This number is then incremented for each + request message that is subsequently sent within the ongoing CPNP + transaction (see Section 11.3). + +8.5. CPNP Timers + + CPNP adopts a simple retransmission procedure that relies on a + retransmission timer represented by RETRANS_TIMER and a maximum retry + threshold. The use of RETRANS_TIMER and a maximum retry threshold + are described in Section 11. + + The response timer (EXPECTED_RESPONSE_TIME) is set by the client to + denote the time, in seconds, the client will wait to receive a + response from the server to a PQO request (see Section 9.1.6). If + the timer expires, the respective PQO is cancelled by the client, and + a CANCEL message is generated accordingly. + + The expected offer timer (EXPECTED_OFFER_TIME) is set by the server + to indicate the time by when the CPNP server is expected to make an + offer to the CPNP client (see Section 9.1.7). If no offer is + received by then, the CPNP client will consider the order as + rejected. + + An offer expiration timer (VALIDITY_OFFER_TIME) is set by the server + to represent the time, in minutes, after which an offer made by the + server becomes invalid (see Section 9.1.8). + +8.6. CPNP Operations + + CPNP operations are listed below. They may be augmented depending on + the nature of some transactions or because of security considerations + that may necessitate a distinct CPNP client/server authentication + phase before negotiation begins. + + QUOTATION (Section 9.2.1): + This operation is used by the client to initiate a PQO. Upon + receipt of a QUOTATION request, the server may respond with a + PROCESSING, OFFER, or a FAIL message. A QUOTATION-initiated + transaction can be terminated by a FAIL message. + + PROCESSING (Section 9.2.2): + This operation is used to inform the remote party that its message + (the order quotation or the offer) was received and it is being + processed. This message can also be issued by the server to + request more time, in which case, the client may reply with an ACK + or FAIL message depending on whether extra time can or cannot be + granted. + + OFFER (Section 9.2.3): + This operation is used by the server to inform the client about an + offer that can best accommodate the requirements indicated in the + previously received QUOTATION message. + + ACCEPT (Section 9.2.4): + This operation is used by the client to confirm the acceptance of + an offer made by the server. This message implies a call for + agreement. An agreement is reached when an ACK is subsequently + received from the server, which is likely to happen if the message + is sent before the offer validity time expires; the server is + unlikely to reject an offer that it has already made. + + DECLINE (Section 9.2.5): + This operation is used by the client to reject an offer made by + the server. The ongoing transaction may not be terminated + immediately, e.g., the client may issue another order or the + server may issue another offer. + + ACK (Section 9.2.6): + This operation is used by the server to acknowledge the receipt of + an ACCEPT or WITHDRAW message or by the client to confirm the + server's request for a time extension (conveyed in a PROCESSING + message) in order to process the last received quotation order. + + CANCEL (Section 9.2.7): + This operation is used by the client to cancel (quit) the ongoing + transaction. + + WITHDRAW (Section 9.2.8): + This operation is used by the client to withdraw a completed order + (i.e., an agreement). + + UPDATE (Section 9.2.9): + This operation is used by the client to update an existing + agreement. For example, this method can be invoked to add a new + VPN site. This method will trigger a new negotiation cycle. + + FAIL (Section 9.2.10): + This operation is used by the server to indicate that it cannot + accommodate the requirements documented in the PQO conveyed in the + QUOTATION message or to inform the client about an error + encountered when processing the received message. In either case, + the message implies that the server is unable to make offers, and, + as a consequence, it terminates the ongoing transaction. + + This message is also used by the client to reject a time extension + request in a PROCESSING message received from the server. The + message includes a status code that provides explanatory + information. + + The above CPNP primitives are service independent. CPNP messages may + transparently carry service-specific objects that are handled by the + negotiation logic at either side. + + The document defines the service objects that are required for + connectivity provisioning negotiation purposes (see Section 8.7). + Additional service-specific objects for CPNP messages to accommodate + alternative deployment schemes or other service provisioning needs + can be defined in the future. + +8.7. Connectivity Provisioning Documents + + CPNP makes use of several flavors of Connectivity Provisioning + Documents (CPD). These documents follow the same CPP template + described in [RFC7297]. + + Requested CPD: + Refers to the CPD included by a CPNP client in a QUOTATION + request. + + Offered CPD: + This document is included by a CPNP server in an OFFER message. + Its information reflects the proposal of the server to accommodate + all or a subset of the clauses depicted in a Requested CPD. A + validity time is associated with the offer made. + + Accepted CPD: + If the client accepts an offer made by the server, the Offered CPD + is included in an ACCEPT message. This CPD is also included in an + ACK message. Thus, a three-way handshake procedure is followed + for successfully completing the negotiation. + + Figure 6 shows a typical CPNP negotiation cycle and the use of the + different types of CPDs. + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |======QUOTATION (Requested CPD)=====>| + |<============PROCESSING==============| + |<========OFFER (Offered CPD)=========| + |=============PROCESSING=============>| + |=======ACCEPT (Accepted CPD)========>| + |<=======ACK (Accepted CPD)===========| + | | + + Figure 6: Connectivity Provisioning Documents + + A CPD can include parameters with fixed values, loosely defined + values, or any combination thereof. A CPD is said to be concrete if + all clauses have fixed values. + + A typical evolution of a negotiation cycle would start with a + quotation order with loosely defined parameters, and then, as offers + are made, it would conclude with a concrete CPD for calling for the + agreement. + +8.8. Child PQOs + + If the server detects that network resources from another Network + Provider need to be allocated in order to accommodate the + requirements described in a PQO (e.g., in the context of an inter- + domain VPN service, additional Provider Edge (PE) router resources + need to be allocated), the server may generate child PQOs to request + the appropriate network provisioning operations (see Figure 7). In + such a situation, the server also behaves as a CPNP client. The + server associates the parent order with its child PQOs. How this is + achieved is implementation specific (e.g., this can be typically + achieved by locally adding the reference of the child PQO to the + parent order). + + +------+ +--------+ +--------+ + |Client| |Server A| |Server B| + +------+ +--------+ +--------+ + | | | + |=====QUOTATION=====>| | + |<====PROCESSING=====| | + | |=====QUOTATION=====>| + | |<====PROCESSING=====| + | |<=======OFFER=======| + | |=====PROCESSING====>| + | |=======ACCEPT======>| + | |<=======ACK=========| + |<=======OFFER=======| | + |=====PROCESSING====>| | + |=======ACCEPT======>| | + |<=======ACK=========| | + | | | + + Figure 7: Example of Child Orders + + Note that the server must not activate recursion for an order if the + client includes a negotiation option to restrict the negotiation + scope to the resources of the server's domain (Section 9.1.10.3). + + If recursion is not explicitly disabled, the server may notify the + client when appropriate (Section 9.2.2). Such notification may + depend on the nature of the service and also regulatory + considerations. + +8.9. Multi-Segment Service + + A composite service (e.g., connectivity) requested by a Customer + could imply multi-segment services (e.g., multi-segment connectivity + spanning an end-to-end scope), in the sense that one single CPNP + request is decomposed into multiple connectivity requests on the + Provider's side (thereby leading to child orders). The Provider is + in charge of handling the complexity of splitting the generic + provisioning order in a multi-segment context. Such complexity is + local to the Provider. + +8.10. Negotiating with Multiple CPNP Servers + + A CPNP client may undertake multiple negotiations in parallel with + several servers for various reasons, such as cost optimization and + fail-safety. These multiple negotiations may lead to one or many + agreements. + + The salient point underlining the parallel negotiation scenarios is + that, although the negotiation protocol is strictly between two + parties, this may not be the case of the negotiation logic. The CPNP + client negotiation logic may need to collectively drive parallel + negotiations, as the negotiation with one server may affect the + negotiation with other servers; for example, it may need to use the + responses from all servers as an input for determining the messages + (and their content) to subsequently send within the course of each + individual negotiation. Therefore, timing is an important aspect on + the client's side. The CPNP client needs to have the ability to + synchronize the receipt of the responses from the servers. CPNP + takes into account this requirement by allowing clients to specify in + the QUOTATION message the time by which the server needs to respond + (see Section 9.1.6). + +8.11. State Management + + Both the client and the server maintain repositories to store ongoing + orders. How these repositories are maintained is deployment + specific. It is out of scope of this document to elaborate on such + considerations. Timestamps are also logged to track state change. + Tracking may be needed for various reasons, including regulatory or + billing ones. + + In order to accommodate failures that may lead to the reboot of the + client or the server, the use of permanent storage is recommended, + thereby facilitating state recovery. + +8.11.1. On the Client Side + + This is the list of the typical states that can be associated with a + given order on the client's side: + + Created: The order has been created. It is not handled by the + client until the administrator allows it to be processed. + + AwaitingProcessing: The administrator has approved the processing of + a created order, but the order has not been handled yet. + + PQOSent: The order has been sent to the server. + + ServerProcessing: The server has confirmed the receipt of the order. + + OfferReceived: An offer has been received from the server. + + OfferProcessing: A received offer is being processed by the client. + + AcceptSent: The client has confirmed the offer to the server. + + Completed: The offer has been acknowledged by the server. + + Cancelled: The order has failed or was cancelled. + + Sub-states may be defined (e.g., to track failed vs. cancelled + orders), but those are not shown in Figure 8. + + +------------------+ + | Created |-----------------+ + +------------------+ | + | | + v | + +------------------+ | + |AwaitingProcessing|----------------+| + +------------------+ || + | || + QUOTATION/UPDATE || + v || + +------------------+ || + | PQOSent |---CANCEL------+|| + +------------------+ vvv + | +-----+ + PROCESSING | | + v | | + +------------------+ CANCEL | C | + | ServerProcessing |------------>| A | + +------------------+ FAIL | N | + | | C | + | | E | + OFFER | L | + | | L | + v | E | + +------------------+ | D | + | OfferReceived |---CANCEL--->| | + +------------------+ | | + | PROCESSING +-----+ + v ^^^ + +------------------+ ||| + | OfferProcessing |---DECLINE-----+|| + +------------------+ || + | ACCEPT || + v || + +------------------+ || + | AcceptSent |---CANCEL-------+| + +------------------+ | + | ACK | + v | + +------------------+ | + | Completed |---WITHDRAW------+ + +------------------+ + + Figure 8: Example of a CPNP Finite State Machine (Client Side) + +8.11.2. On the Server Side + + The following lists the states on the server's side that can be + associated with a given order and a corresponding offer: + + PQOReceived: The order has been received from the client. + + AwaitingProcessing: The order is being processed by the server. An + action from the server administrator may be needed. + + OfferProposed: The request has been successfully handled, and an + offer has been sent to the client. + + ProcessingReceived: The server has received a PROCESSING message for + an offer sent to the client. + + AcceptReceived: The server has received a confirmation for the offer + from the client. + + Completed: The server has acknowledged the offer (accepted by + client) to the client. Transitioning to this state assumes that + the ACK was received by the client (this can be detected by the + server if it receives a retransmitted ACCEPT message from the + client). + + Cancelled: The order cannot be accommodated, or it has been + cancelled by the client. Associated resources must be released in + the latter case, if previously reserved. + + ChildCreated: A child order has been created in cases where + resources from another Network Provider are needed. + + ChildPQOSent: A child order has been sent to the remote server. + + ChildServerProcessing: A child order is being processed by the + remote server. + + ChildOfferReceived: The remote server has received an offer to a + child order. + + ChildOfferProcessing: A received offer to a child order is being + processed. + + ChildAcceptSent: The child offer (the offer received from the remote + server in response to a child order) is confirmed to the remote + server. + + ChildCompleted: The accepted child offer has been acknowledged by + the remote server. + + +------------------+ +------------------+ + |AwaitingProcessing|<----------| ChildCreated | + +------------------+ +------------------+ + | | ^ + v | | + +------------------+ | | + | ChildPQOSent |----------------+| Q + +------------------+ || U + | || O + QUOTATION/UPDATE || T + v || A +--------------------+ + +---------------------+ CANCEL || T | PQOReceived | + |ChildServerProcessing|------------+|| I +--------------------+ + +---------------------+ FAIL vvv O | | + | +-----+ N CANCEL | + PROCESSING | |<---|-------+ PROCESSING + v | | | v + +------------------+ | | +------------------------+ + |ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing | + +------------------+ | A | +------------------------+ + | | N | ^ | OFFER + OFFER | C | | +------------------+ + | | E |<DECLINE-| OfferProposed | + | | L | | +------------------+ + v | L | | | + +------------------+ | E | | PROCESSING + |ChildOfferReceived|---CANCEL----| D | | v + +------------------+ | | | +------------------+ + | | |<DECLINE-| Proc'ingReceived | + PROCESSING | | |+------------------+ + | +-----+ | | ACCEPT + v ^^^^^ | v + +------------------+ ||||| | +------------------+ + |ChildOfferProc'ing|---DECLINE----+|||+-CANCEL-|-| AcceptReceived | + +------------------+ ||| | +------------------+ + |ACCEPT ||| | |ACK + v ||| | v + +------------------+ ||| | +------------------+ + | ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-| Completed | + +------------------+ | | +------------------+ + | ACK | | + v | | + +------------------+ | | + | ChildCompleted |---WITHDRAW-----+ | + | +---------------------------+ + +------------------+ + + Figure 9: CPNP Finite State Machine (Server Side) + +9. CPNP Objects + + This section defines CPNP objects using the Routing Backus-Naur Form + (RBNF) format defined in [RFC5511]. Please also note the following: + + | Note 1: The formats of CPNP messages are provided using a + | generic format. Implementors can adapt RBNF definitions to + | their "favorite" message format. For example, JSON [RFC8259] + | or Concise Binary Object Representation (CBOR) [RFC7049] can be + | used. + + | Note 2: CPNP messages cannot be blindly mapped to RESTCONF + | messages with the target service being modelled as + | configuration data because such data is supposed to be + | manipulated by a RESTCONF client only. In such a model, the + | RESTCONF server cannot use a value other than the one set by + | the client (e.g., Section 9.2.3) or remove offers from its own + | initiative (e.g., Section 9.1.8). An alternate approach might + | be to map CPNP operations into RESTCONF actions (RPC). + | Assessing the feasibility of such approach is out of scope. + +9.1. Attributes + +9.1.1. CUSTOMER_ORDER_IDENTIFIER + + The CUSTOMER_ORDER_IDENTIFIER (Customer Order Identifier) is an + identifier that is assigned by a client to identify an agreement. + This identifier must be unique to the client. + + Rules for assigning this identifier (including the structure and + semantics) are specific to the client (Customer). The value of + CUSTOMER_ORDER_IDENTIFIER is included in all CPNP messages. + + The client (Customer) assigns an identifier to an order under + negotiation before an agreement is reached. This identifier will be + used to unambiguously identify the resulting agreement at the client + side (Customer). + + The server handles the CUSTOMER_ORDER_IDENTIFIER as an opaque value. + +9.1.2. PROVIDER_ORDER_IDENTIFIER + + The PROVIDER_ORDER_IDENTIFIER (Provider Order Identifier) is an + identifier that is assigned by a server to identify an order. This + identifier must be unique to the server. + + Rules for assigning this identifier (including the structure and + semantics) are specific to the server (Provider). The + PROVIDER_ORDER_IDENTIFIER is included in all CPNP messages except + QUOTATION messages (because the state is only present at the client + side). + + The server (Provider) assigns an identifier to an order under + negotiation before an agreement is reached. This identifier will be + used to unambiguously identify the resulting agreement at the server + side (Provider). + + The client handles the PROVIDER_ORDER_IDENTIFIER as an opaque value. + +9.1.3. TRANSACTION_ID + + This object conveys the Transaction-ID introduced in Section 8.4. + +9.1.4. SEQUENCE_NUMBER + + The sequence number is a number that is monotonically incremented in + every new CPNP message pertaining to a given CPNP transaction. This + number is used to avoid replay attacks. + + Refer to Section 11.3. + +9.1.5. NONCE + + The NONCE is a random value assigned by the CPNP server. Assigning a + unique NONCE value for each order is recommended. + + It is mandatory to then include the NONCE in subsequent CPNP client + operations on the associated order (including the resulting + agreement) such as withdrawing the order or updating the order. + + If the NONCE validation checks fail, the server rejects the request + with a FAIL message that includes the appropriate failure reason + code. + +9.1.6. EXPECTED_RESPONSE_TIME + + This attribute indicates the time by when the CPNP client is + expecting to receive a response from the CPNP server to a given PQO. + If no offer is received by then, the CPNP client will consider the + quotation order to be rejected. + + The EXPECTED_RESPONSE_TIME follows the date format specified in + [RFC3339]. + +9.1.7. EXPECTED_OFFER_TIME + + This attribute indicates the time by when the CPNP server is + expecting to make an offer to the CPNP client. If no offer is + received by then, the CPNP client will consider the order rejected. + + The CPNP server may propose an expected offer time that does not + match the expected response time indicated in the quotation order + message. The CPNP client can accept or reject the proposed expected + time by when the CPNP server will make an offer. + + The CPNP server can always request extra time for its processing, but + this may be accepted or rejected by the CPNP client. + + The EXPECTED_OFFER_TIME follows the date format specified in + [RFC3339]. + +9.1.8. VALIDITY_OFFER_TIME + + This attribute indicates the time of validity of an offer made by the + CPNP server. If the offer is not accepted before this time expires, + the CPNP server will consider the CPNP client as having rejected the + offer; the CPNP server will silently remove this order from its base. + + The VALIDITY_OFFER_TIME follows date format specified in [RFC3339]. + +9.1.9. SERVICE_DESCRIPTION + + This document defines a machinery to negotiate any aspect subject to + negotiation. Service clauses that are under negotiation are conveyed + using this attribute. + + The structure of the connectivity provisioning clauses is provided in + the following subsection. + +9.1.9.1. CPD + + The RBNF format of the CPD is shown in Figure 10. + + <CPD> ::= <Connectivity Provisioning Component> ... + <Connectivity Provisioning Component> ::= + <CONNECTIVITY_PROVISIONING_PROFILE> ... + <CONNECTIVITY_PROVISIONING_PROFILE> ::= + <Customer Nodes Map> + <SCOPE> + <QoS Guarantees> + <Availability> + <CAPACITY> + <Traffic Isolation> + <Conformance Traffic> + <Flow Identification> + <Overall Traffic Guarantees> + <Routing and Forwarding> + <Activation Means> + <Invocation Means> + <Notifications> + <Customer Nodes Map> ::= <Customer Node> ... + <Customer Node> ::= <IDENTIFIER> + <LINK_IDENTIFIER> + <LOCALIZATION> + + Figure 10: The RBNF format of the CPD + +9.1.10. CPNP Information Elements + + An Information Element (IE) is an optional object that can be + included in a CPNP message. + +9.1.10.1. Customer Description + + The client may include administrative information such as the + following: + + * Name + + * Contact Information + + The format of this Information Element is as follows: + + <Customer Description> ::= [<NAME>] [<Contact Information>] + <Contact Information> ::= [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>] + [<TELEPHONE_NUMBER> ...] + +9.1.10.2. Provider Description + + The server may include administrative information in an offer such as + the following: + + * Name + + * AS Number [RFC6793] + + * Contact Information + + The format of this Information Element is as follows: + + <Provider Description> ::= [<NAME>][<Contact Information>] + [<AS_NUMBER>] + +9.1.10.3. Negotiation Options + + The client may include some negotiation options such as the + following: + + Setup purpose: A client may request the setup of a service (e.g., + connectivity) only for testing purposes during a limited period. + The order can be extended to become permanent if the client was + satisfied during the test period. This operation is achieved + using the UPDATE method. + + Activation type: A client may request a permanent or scheduled + activation type. If no activation type clause is included during + the negotiation, this means that the order will be immediately + activated right after the negotiation ends. + + The format of this Information Element is as follows: + + <Negotiation Options> ::= [<PURPOSE>] + +9.2. Operation Messages + + This section defines the RBNF format of CPNP operation messages. The + following operation codes are used: + + +======+===================+================+ + | Code | Operation Message | Reference | + +======+===================+================+ + | 1 | QUOTATION | Section 9.2.1 | + +------+-------------------+----------------+ + | 2 | PROCESSING | Section 9.2.2 | + +------+-------------------+----------------+ + | 3 | OFFER | Section 9.2.3 | + +------+-------------------+----------------+ + | 4 | ACCEPT | Section 9.2.4 | + +------+-------------------+----------------+ + | 5 | DECLINE | Section 9.2.5 | + +------+-------------------+----------------+ + | 6 | ACK | Section 9.2.6 | + +------+-------------------+----------------+ + | 7 | CANCEL | Section 9.2.7 | + +------+-------------------+----------------+ + | 8 | WITHDRAW | Section 9.2.8 | + +------+-------------------+----------------+ + | 9 | UPDATE | Section 9.2.9 | + +------+-------------------+----------------+ + | 10 | FAIL | Section 9.2.10 | + +------+-------------------+----------------+ + | 11 | ACTIVATE | Section 9.2.11 | + +------+-------------------+----------------+ + + Table 1: CPNP Operation Message Codes + + These codes are used to unambiguously identify a CPNP operation; the + operation code is conveyed in the METHOD_CODE attribute mentioned in + the following subsections. + + In the following, VERSION refers to the CPNP version number. This + attribute must be set to 1. + +9.2.1. QUOTATION + + The format of the QUOTATION message is shown below: + + <QUOTATION Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + [<EXPECTED_RESPONSE_TIME>] + <REQUESTED_CPD> + [<INFORMATION_ELEMENT>...] + + A QUOTATION message must include an order identifier that is + generated by the client (CUSTOMER_ORDER_IDENTIFIER). Because several + orders can be issued to several servers, the QUOTATION message must + also include a Transaction-ID. + + The message may include an EXPECTED_RESPONSE_TIME, which indicates by + when the client expects to receive an offer from the server. The + QUOTATION message must also include a requested service description + (that is, a Requested CPD for connectivity services). + + The message may include ACTIVATION_TYPE to request a permanent or + scheduled activation type (e.g., using the ACTIVATE method defined in + Section 9.2.11). If no such clause is included, the default mode is + to assume that the order will be active once the accepted activation + means are successfully invoked (e.g., Section 3.11 of [RFC7297]). + + When the client sends the QUOTATION message to the server, the state + of the order changes to "PQOSent" at the client side. + +9.2.2. PROCESSING + + The format of the PROCESSING message is shown below: + + <PROCESSING Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + [<EXPECTED_OFFER_TIME>] + [<PROCESSING_SUBCODE>] + + Upon receipt of a QUOTATION message, the server proceeds with the + parsing rules (see Section 10). If no error is encountered, the + server generates a PROCESSING response to the client to indicate the + PQO has been received and it is being processed. The server must + generate an order identifier that identifies the order in its local + order repository. The server must copy the content of the + CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed in + the QUOTATION message. The server may include an EXPECTED_OFFER_TIME + by when it expects to make an offer to the client. + + Upon receipt of a PROCESSING message, the client verifies whether it + has issued a PQO that contains the CUSTOMER_ORDER_IDENTIFIER and + TRANSACTION_ID to that server. If no such PQO is found, the + PROCESSING message must be silently ignored. If a PQO is found, the + client may check whether it accepts the EXPECTED_OFFER_TIME, and then + it changes to state of the order to "ServerProcessing". + + If the server requires more time to process the quotation order, it + may send a PROCESSING message that includes a new + EXPECTED_OFFER_TIME. The client can answer with an ACK message if + more time is granted (Figure 11) or with a FAIL message if the time + extension request is rejected (Figure 12). + + The server may provide more details in the PROCESSING_SUBCODE + attribute about the reason for requesting more time to process the + request. The following codes are defined: + + +=========+============================+ + | Subcode | Description | + +=========+============================+ + | 1 | Upgrade of local resources | + +---------+----------------------------+ + | 2 | Request external resources | + +---------+----------------------------+ + + Table 2: PROCESSING_SUBCODE Codes + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |=======QUOTATION(Requested CPD)=====>| + |<========PROCESSING(time1)===========| + ... + |<========PROCESSING(MoreTime)========| + |============ACK(TimeGranted)========>| + ... + |<=========OFFER(Offered CPD)=========| + |=============PROCESSING=============>| + |=========ACCEPT(Accepted CPD)=======>| + |<=========ACK(Accepted CPD)==========| + | | + + Figure 11: Request More Negotiation Time: Granted + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |=======QUOTATION(Requested CPD)=====>| + |<========PROCESSING(time1)===========| + ... + |<========PROCESSING(MoreTime)========| + |=====FAIL(More Time Rejected)=======>| + + Figure 12: Request More Negotiation Time: Rejected + +9.2.3. OFFER + + The format of the OFFER message is shown below: + + <OFFER Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <NONCE> + <VALIDITY_OFFER_TIME> + <OFFERED_CPD> + [<INFORMATION_ELEMENT>...] + + The server answers a QUOTATION request received from the client with + an OFFER message. The offer will be considered to be rejected by the + client if no confirmation (i.e., an ACCEPT message sent by the + client) is received by the server before the expiration of the + validity time. + + The server may include ACTIVATION_TYPE to indicate whether the offer + is about a permanent or scheduled activation type. The message may + include ACTIVATION_SCHEDULE to indicate when the order is to be + activated. If no such clause is included, the default mode is to + assume that the order will be active once the accepted activation + means are successfully invoked (e.g., Section 3.11 of [RFC7297] or + Section 9.2.11). + +9.2.4. ACCEPT + + The format of the ACCEPT message is shown below: + + <ACCEPT Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <NONCE> + <ACCEPTED_CPD> + [<INFORMATION_ELEMENT>...] + + This message is used by a client to confirm the acceptance of an + offer received from a server. The fields of this message must be + copied from the received OFFER message. This message should not be + sent after the validity time of the offer expires, as indicated by + the server (Section 9.2.3). + +9.2.5. DECLINE + + The format of the DECLINE message is shown below: + + <DECLINE Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <NONCE> + [<REASON>...] + + The client may issue a DECLINE message to reject an offer. + CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, TRANSACTION_ID, + and NONCE are used by the server as keys to find the corresponding + order. If an order matches, the server changes the state of this + order to "Cancelled" and then returns an ACK with a copy of the + Requested CPD to the requesting client. + + A DECLINE message may include an Information Element to indicate the + reason for declining an offer. The following codes are defined: + + +======+====================================================+ + | Code | Description | + +======+====================================================+ + | 1 | Unacceptable gap between the request and the offer | + +------+----------------------------------------------------+ + | 2 | Conflict with another offer from another server | + +------+----------------------------------------------------+ + | 3 | Activation type mismatch | + +------+----------------------------------------------------+ + + Table 3: DECLINE Message Codes + + If no order is found, the server returns a FAIL message to the + requesting client. In order to prevent DDoS (Distributed Denial of + Service) attacks, the server should restrict the number of FAIL + messages sent to a requesting client. It may also rate-limit FAIL + messages. + + A flow example is shown in Figure 13. + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |=======QUOTATION(Requested CPD)=====>| + |<============PROCESSING==============| + |<=========OFFER(Offered CPD)=========| + |=============PROCESSING=============>| + |===============DECLINE==============>| + |<================ACK=================| + | | + + Figure 13: DECLINE Flow Example + +9.2.6. ACK + + The format of the ACK message is shown below: + + <ACK Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + [<EXPECTED_RESPONSE_TIME>] + [<CPD>] + [<INFORMATION_ELEMENT>...] + + This message is issued by the server to close a CPNP transaction or + by a client to grant more negotiation time to the server. + + This message is sent by the server as a response to an ACCEPT, + WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message + must include the copy of the service description (i.e., CPD for + connectivity services) as stored by the server. In particular, the + following considerations are taken into account for connectivity + provisioning services: + + * A copy of the Requested/Offered CPD is included by the server if + it successfully handled a CANCEL message. + + * A copy of the Updated CPD is included by the server if it + successfully handled an UPDATE message. + + * A copy of the Offered CPD is included by the server if it + successfully handled an ACCEPT message in the context of a + QUOTATION transaction (refer to "Accepted CPD" in Section 8.7). + + * An Empty CPD is included by the server if it successfully handled + a DECLINE or WITHDRAW message. + + A client may issue an ACK message as a response to a time extension + request (conveyed in PROCESSING) received from the server. In such + case, the ACK message must include an EXPECTED_RESPONSE_TIME that is + likely to be set to the time extension requested by the server. + +9.2.7. CANCEL + + The format of the CANCEL message is shown below: + + <CANCEL Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + [<CPD>] + + The client can issue a CANCEL message at any stage during the CPNP + negotiation process before an agreement is reached. The + CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID are used by the server + as keys to find the corresponding order. If a quotation order + matches, the server changes the state of this quotation order to + "Cancelled" and then returns an ACK with a copy of the Requested CPD + to the requesting client. + + If no quotation order is found, the server returns a FAIL message to + the requesting client. + +9.2.8. WITHDRAW + + The format of the WITHDRAW message is shown below: + + <WITHDRAW Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <NONCE> + [<ACCEPTED_CPD>] + [<INFORMATION_ELEMENT>...] + + This message is used to withdraw an offer already accepted by the + Customer. Figure 14 shows a typical usage of this message. + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |============WITHDRAW(CPD)===========>| + |<============PROCESSING==============| + |<===========ACK(Empty CPD)===========| + | | + + Figure 14: WITHDRAW Flow Example + + The WITHDRAW message must include the same CUSTOMER_ORDER_IDENTIFIER, + PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the + order. + + Upon receipt of a WITHDRAW message, the server checks whether an + order matching the request is found. If an order is found, the state + of the order is changed to "Cancelled", and an ACK message including + an Empty CPD is returned to the requesting client. If no order is + found, the server returns a FAIL message to the requesting client. + +9.2.9. UPDATE + + The format of the UPDATE message is shown below: + + <UPDATE Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <NONCE> + <EXPECTED_RESPONSE_TIME> + <REQUESTED_CPD> + [<INFORMATION_ELEMENT>...] + + This message is sent by the CPNP client to update an existing service + agreement (e.g., Accepted CPD). The UPDATE message must include the + same CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE + as those used when creating the order. The CPNP client includes a + new service description (e.g., Updated CPD) that integrates the + requested modifications. A new Transaction_ID must be assigned by + the client. + + Upon receipt of an UPDATE message, the server checks whether an + order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER, + PROVIDER_ORDER_IDENTIFIER, and NONCE. + + * If no order is found, the CPNP server generates a FAIL error with + the appropriate error code (Section 9.2.10). + + * If an order is found, the server checks whether it can honor the + request: + + - A FAIL message is sent to the client if the server cannot honor + the request. The client may initiate a new PQO negotiation + cycle (that is, send a new UPDATE message). + + - An OFFER message including the updated clauses (e.g., Updated + CPD) is sent to the client. For example, the server maintains + an order for provisioning a VPN service that connects sites A, + B, and C. If the client sends an UPDATE message to remove site + C, only sites A and B will be included in the OFFER sent by the + server to the requesting client. + + Note that the cycle that is triggered by an UPDATE message is + also considered to be a negotiation cycle. + + A flow chart that illustrates the use of UPDATE operation is shown in + Figure 15. + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |=========UPDATE(Requested CPD)======>| + |<============PROCESSING==============| + |<=========OFFER(Updated CPD)=========| + |=============PROCESSING=============>| + |==========ACCEPT(Updated CPD)=======>| + |<==========ACK(Updated CPD)==========| + | | + + Figure 15: UPDATE Flow Example + +9.2.10. FAIL + + The format of the FAIL message is shown below: + + <FAIL Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <STATUS_CODE> + + This message is sent in the following cases: + + * The server cannot honor an order received from the client (i.e., + received in a QUOTATION or UPDATE request). + + * The server encounters an error when processing a CPNP request + received from the client. + + * The client cannot grant more time to the server. This is a + response to a time extension request carried in a PROCESSING + message. + + The status code indicates the error code. The following codes are + supported: + + +========+==================+=====================================+ + | Status | Error Code | Description | + | Code | | | + +========+==================+=====================================+ + | 1 | Message | The message cannot be validated | + | | Validation Error | (see Section 10). | + +--------+------------------+-------------------------------------+ + | 2 | Authentication | The request cannot be handled | + | | Required | because authentication is required. | + +--------+------------------+-------------------------------------+ + | 3 | Authorization | The request cannot be handled | + | | Failed | because authorization failed. | + +--------+------------------+-------------------------------------+ + | 4 | Administratively | The request cannot be handled | + | | prohibited | because of administrative policies. | + +--------+------------------+-------------------------------------+ + | 5 | Out of Resources | The request cannot be honored | + | | | because resources (e.g., capacity) | + | | | are insufficient. | + +--------+------------------+-------------------------------------+ + | 6 | Network Presence | The request cannot be honored | + | | Error | because there is no network | + | | | presence. | + +--------+------------------+-------------------------------------+ + | 7 | More Time | The request to extend the time for | + | | Rejected | negotiation is rejected by the | + | | | client. | + +--------+------------------+-------------------------------------+ + | 8 | Unsupported | The request cannot be handled | + | | Activation Type | because the requested activation | + | | | type is not supported. | + +--------+------------------+-------------------------------------+ + + Table 4: FAIL Message Error Codes + +9.2.11. ACTIVATE + + The format of the ACTIVATE message is shown below: + + <ACTIVATE Message> ::= <VERSION> + <METHOD_CODE> + <SEQUENCE_NUMBER> + <TRANSACTION_ID> + <CUSTOMER_ORDER_IDENTIFIER> + <PROVIDER_ORDER_IDENTIFIER> + <NONCE> + <ACTIVATION_SCHEDULE> + [<INFORMATION_ELEMENT>...] + + This message is sent by the CPNP client to request the activation of + an existing service agreement. The message must include the same + CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE as + those used when creating the order. The CPNP client may include a + schedule target for activating this order. A new Transaction_ID must + be assigned by the client. + + Upon receipt of an ACTIVATE message, the server checks whether an + order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER, + PROVIDER_ORDER_IDENTIFIER, and NONCE. + + * If no completed order is found, the CPNP server generates a FAIL + error with the appropriate error code (Section 9.2.10). + + * If an order is found, the server checks whether it can honor the + request: + + - A FAIL message is sent to the client if the server cannot honor + the request (e.g., out of resources or explicit activation + wasn't negotiated with this client). + + - An ACK is sent to the client to confirm that the immediate + activation (or deactivation) of the order or its successful + scheduling if a non-null ACTIVATION_SCHEDULE was included in + the request. Note that setting ACTIVATION_SCHEDULE to 0 in an + ACTIVATE request has a special meaning: it is used to request a + deactivation of an accepted order. + + Figure 16 illustrates the use of the ACTIVATE operation. + + +------+ +------+ + |Client| |Server| + +------+ +------+ + |================ACTIVATE()==========>| + |<==============ACK()=================| + | | + + Figure 16: ACTIVATE Flow Example + +10. CPNP Message Validation + + Both the client and the server proceed with CPNP message validation. + The following tables summarize the validation checks to be followed. + +10.1. On the Client Side + + +==============+==================================================+ + | Operation | Validation Checks | + +==============+==================================================+ + | PROCESSING | {Source IP address, source port number, | + | | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier} must | + | | match an existing PQO with a state set to | + | | "PQOSent". The sequence number carried in the | + | | packet must be larger than the sequence number | + | | maintained by the client. | + +--------------+--------------------------------------------------+ + | OFFER | {Source IP address, source port number, | + | | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier} must | + | | match an existing order with state set to | + | | "PQOSent", or {Source IP address, source port | + | | number, destination IP address, destination port | + | | number, Transaction-ID, Customer Order | + | | Identifier, Provider Order Identifier} must | + | | match an existing order with a state set to | + | | "ServerProcessing". The sequence number carried | + | | in the packet must be larger than the sequence | + | | number maintained by the client. | + +--------------+--------------------------------------------------+ + | ACK | {Source IP address, source port number, | + | (QUOTATION | destination IP address, destination port number, | + | Transaction) | Transaction-ID, Customer Order Identifier, | + | | Provider Order Identifier, Offered Connectivity | + | | Provisioning Document} must match an order with | + | | a state set to "AcceptSent". The sequence | + | | number carried in the packet must be larger than | + | | the sequence number maintained by the client. | + +--------------+--------------------------------------------------+ + | ACK (UPDATE | {Source IP address, source port number, | + | Transaction) | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier, | + | | Provider Order Identifier, Updated Connectivity | + | | Provisioning Document} must match an order with | + | | a state set to "AcceptSent". The sequence | + | | number carried in the packet must be larger than | + | | the sequence number maintained by the client. | + +--------------+--------------------------------------------------+ + | ACK | {Source IP address, source port number, | + | (WITHDRAW | destination IP address, destination port number, | + | Transaction) | Transaction-ID, Customer Order Identifier, | + | | Provider Order Identifier, Empty Connectivity | + | | Provisioning Document} must match an order with | + | | a state set to "Cancelled". The sequence number | + | | carried in the packet must be larger than the | + | | sequence number maintained by the client. | + +--------------+--------------------------------------------------+ + + Table 5: Client Side Validation Checks + +10.2. On the Server Side + + +============+==================================================+ + | Method | Validation Checks | + +============+==================================================+ + | QUOTATION | The source IP address passes existing access | + | | filters (if any). The sequence number carried | + | | in the packet must not be lower than the | + | | sequence number maintained by the server. | + +------------+--------------------------------------------------+ + | PROCESSING | The sequence number carried in the packet must | + | | be greater than the sequence number maintained | + | | by the server. | + +------------+--------------------------------------------------+ + | CANCEL | {Source IP address, source port number, | + | | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier} must | + | | match an order with state set to "PQOReceived" | + | | or "OfferProposed" or "ProcessingReceived" or | + | | "AcceptReceived". The sequence number carried | + | | in the packet must be greater than the sequence | + | | number maintained by the server. | + +------------+--------------------------------------------------+ + | ACCEPT | {Source IP address, source port number, | + | | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier, | + | | Provider Order Identifier, Nonce, Offered | + | | Connectivity Provisioning Document} must match | + | | an order with state set to "OfferProposed" or | + | | "ProcessingReceived". The sequence number | + | | carried in the packet must be greater than the | + | | sequence number maintained by the server. | + +------------+--------------------------------------------------+ + | FAIL | {Source IP address, source port number, | + | | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier, | + | | Provider Order Identifier} must match an order | + | | with state set to "AwaitingProcessing" and for | + | | which a request to grant more time to process an | + | | offer was requested. The sequence number | + | | carried in the packet must be greater than the | + | | sequence number maintained by the server. | + +------------+--------------------------------------------------+ + | DECLINE | {Source IP address, source port number, | + | | destination IP address, destination port number, | + | | Transaction-ID, Customer Order Identifier, | + | | Provider Order Identifier, Nonce} must match an | + | | order with state set to "OfferProposed" or | + | | "ProcessingReceived". The sequence number | + | | carried in the packet must be greater than the | + | | sequence number maintained by the server. | + +------------+--------------------------------------------------+ + | UPDATE | The source IP address passes existing access | + | | filters (if any), and {Customer Order | + | | Identifier, Provider Order Identifier, Nonce} | + | | must match an existing order with state | + | | "Completed". | + +------------+--------------------------------------------------+ + | WITHDRAW | The source IP address passes existing access | + | | filters (if any), and {Customer Order | + | | Identifier, Provider Order Identifier, Nonce} | + | | must match an existing order with state | + | | "Completed". | + +------------+--------------------------------------------------+ + | ACTIVATE | The source IP address passes existing access | + | | filters (if any), and {Customer Order | + | | Identifier, Provider Order Identifier, Nonce} | + | | must match an existing order with a state of | + | | "Completed" and its activation procedure set to | + | | explicit. | + +------------+--------------------------------------------------+ + + Table 6: Server Side Validation Checks + +11. Theory of Operation + + Both the CPNP client and server proceed with message validation + checks as specified in Section 10. + +11.1. Client Behavior + +11.1.1. Order Negotiation Cycle + + To place a PQO, the client first initiates a local quotation order + object identified by a unique identifier assigned by the client + (Client Order Identifier). The state of the quotation order is set + to "Created". The client then generates a QUOTATION request that + includes the assigned identifier, possibly an expected response time, + a Transaction-ID, and a requested service (e.g., Requested CPD). The + client may include additional Information Elements such as Customer + Description or Negotiation Options. + + The client may be configured to not enforce negotiation checks on + EXPECTED_OFFER_TIME; if so, the client should either not include the + EXPECTED_RESPONSE_TIME attribute in the PQO or it should set the + attribute to infinite. + + Once the request is sent to the server, the state of the request is + set to "PQOSent", and if a response time is included in the quotation + order, a timer is set to the expiration time as included in the + QUOTATION request. The client also maintains a copy of the CPNP + session entry details used to generate the QUOTATION request. The + CPNP client must listen on the same port number that it used to send + the QUOTATION request. + + If no answer is received from the server before the retransmission + timer expires (i.e., RETRANS_TIMER, Section 8.5), the client + retransmits the message until maximum retry is reached (e.g., three + times). The same sequence number is used for retransmitted packets. + + If a FAIL message is received, the client may decide to issue another + (corrected) request towards the same server, cancel the local order, + or contact another server. The behavior of the client depends on the + error code returned by the server in the FAIL message. + + If a PROCESSING message matching the CPNP session entry (Section 8.3) + is received, the client updates the CPNP session entry with the + PROVIDER_ORDER_IDENTIFIER information. If the client does not accept + the expected offer time that may have been indicated in the + PROCESSING message, the client may decide to cancel the quotation + order. If the client accepts the EXPECTED_OFFER_TIME, it changes the + state of the order to "ServerProcessing" and sets a timer to the + value of EXPECTED_OFFER_TIME. If no offer is made before the timer + expires, the client changes the state of the order to "Cancelled". + + As a response to a time extension request (conveyed in a PROCESSING + message that included a new EXPECTED_OFFER_TIME), the client may + either grant this extension by issuing an ACK message or reject the + time extension by issuing a FAIL message with a status code set to + "More Time Rejected". + + If an OFFER message matching the CPNP session entry is received, the + client checks if a PROCESSING message having the same + PROVIDER_ORDER_IDENTIFIER has been received from the server. If a + PROCESSING message was already received for the same order, but the + PROVIDER_ORDER_IDENTIFIER does not match the identifier included in + the OFFER message, the client silently ignores the message. If a + PROCESSING message with the same PROVIDER_ORDER_IDENTIFIER was + already received and matches the CPNP transaction identifier, the + client changes the state of the order to "OfferReceived" and sets a + timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER + message. + + If an offer is received from the server (i.e., as documented in an + OFFER message), the client may accept or reject the offer. The + client accepts the offer by generating an ACCEPT message that + confirms that the client agrees to subscribe to the offer documented + in the OFFER message; the state of the order is passed to + "AcceptSent". The transaction is terminated if an ACK message is + received from the server. If no ACK is received from the server, the + client proceeds with the retransmission of the ACCEPT message until + the maximum retry is reached (Section 11.4). + + The client may also decide to reject the offer by sending a DECLINE + message. The state of the order is set by the client to "Cancelled". + If an offer is not acceptable to the client, the client may decide to + contact a new server or submit another order to the same server. + Guidelines to issue an updated order or terminate the negotiation are + specific to the client. + + An order can be activated (or deactivated) using the ACTIVATE message + or other accepted activation means (Section 3.11 of [RFC7297]). + +11.1.2. Order Withdrawal Cycle + + A client may withdraw a completed order. This is achieved by issuing + a WITHDRAW message. This message must include the Customer Order + Identifier, Provider Order Identifier, and Nonce returned during the + order negotiation cycle, as specified in Section 11.1.1. + + If no ACK is received from the server, the client proceeds with the + retransmission of the message. If no ACK is received after the + maximum retry is exhausted, the client should log the information and + must send an alarm to the administrator. If there is no specific + instruction from the administrator, the client should schedule + another Withdrawal cycle. The client must not retry this Withdrawal + cycle more frequently than every 300 seconds and must not retry more + frequently than every 60 seconds. + +11.1.3. Order Update Cycle + + A client may update a completed order. This is achieved by issuing + an UPDATE message. This message must include the Customer Order + Identifier, Provider Order Identifier, and Nonce returned during the + order negotiation cycle specified in Section 11.1.1. The client must + include in the UPDATE message an Updated CPD with the requested + changes. + + The subsequent message exchange is similar to what is documented in + Section 11.1.1. + +11.2. Server Behavior + +11.2.1. Order Processing + + Upon receipt of a QUOTATION message from a client, the server sets a + CPNP session, stores the Transaction-ID, and generates a Provider + Order Identifier. Once preliminary validation checks are completed + (Section 10), the server may return a PROCESSING message to inform + the client that the quotation order is received and it is under + processing; the server may include an expected offer time to notify + the client by when an offer will be proposed. An order with state + "AwaitingProcessing" is created by the server. The server runs its + decision-making process to decide which offer it can make to honor + the received order. The offer should be made before the expected + offer time expires. + + If the server cannot make an offer, it sends backs a FAIL message + with the appropriate error code (Section 9.2.10). + + If the server requires more negotiation time, it must send a + PROCESSING message with a new EXPECTED_OFFER_TIME. The client may + grant this extension by issuing an ACK message or reject the time + extension by issuing a FAIL message with the status code set to "More + Time Rejected". If the client doesn't grant more time, the server + must answer before the initial expected offer time; otherwise, the + client will decline the quotation order. + + If the server can honor the request, or if it can make an offer that + meets only some of the requirements, it creates an OFFER message. + The server must indicate the Transaction-ID, the Customer Order + Identifier as indicated in the QUOTATION message, and the Provider + Order Identifier generated for this order. The server must also + include the Nonce and the offered service document (e.g., Offered + CPD). The server includes an offer validity time as well. Once sent + to the client, the server changes the state of the order to + "OfferProposed", and a timer set to the validity time is initiated. + + If the server determines that additional network resources from + another Network Provider are needed to accommodate a quotation order, + it will create child PQO(s) and will behave as a CPNP client to + negotiate child PQO(s) with possible partnering Providers (see + Figure 7). + + If no PROCESSING, ACCEPT, or DECLINE message is received before the + expiry of the RETRANS_TIMER, the server resends the same offer to the + client. This procedure is repeated until maximum retry is reached. + + If an ACCEPT message is received before the offered validity time + expires, the server proceeds with validation checks as specified in + Section 10. The state of the corresponding order is passed to + "AcceptReceived". The server sends back an ACK message to terminate + the order processing cycle. + + If a CANCEL or a DECLINE message is received, the server proceeds + with the cancellation of the order. The state of the order is then + passed to "Cancelled". + +11.2.2. Order Withdrawal + + A client may withdraw a completed order by issuing a WITHDRAW + message. Upon receipt of a WITHDRAW message, the server proceeds + with the validation checks, as specified in Section 10: + + * If the checks fail, a FAIL message is sent back to the client with + the appropriate error code (e.g., 1 (Message Validation Error), 2 + (Authentication Required), or 3 (Authorization Failed)). + + * If the checks succeed, the server clears the clauses of the CPD, + changes the state of the order to "Cancelled", and sends back an + ACK message with an Empty CPD. + +11.2.3. Order Update + + A client may update an order by issuing an UPDATE message. Upon + receipt of an UPDATE message, the server proceeds with the validation + checks as specified in Section 10: + + * If the checks fail, a FAIL message is sent back to the client with + the appropriate error code (e.g., 1 (Message Validation Error), 2 + (Authentication Required), 3 (Authorization Failed), or 6 (Network + Presence Error)). + + * The exchange of subsequent messages is similar to what is + specified in Section 11.1.1. The server should generate a new + Nonce value to be included in the offer made to the client. + +11.3. Sequence Numbers + + In each transaction, sequence numbers are used to protect the + transaction against replay attacks. Each communicating partner of + the transaction maintains two sequence numbers, one for incoming + packets and one for outgoing packets. When a partner receives a + message, it will check whether the sequence number in the message is + larger than the incoming sequence number maintained locally. If not, + the message will be discarded. If the message is proved to be + legitimate, the value of the incoming sequence number maintained + locally will be replaced by the value of the sequence number in the + message. When a partner sends out a message, it will insert the + value of the outgoing sequence number into the message and increase + the outgoing sequence number maintained locally by 1. + +11.4. Message Retransmission + + If a transaction partner sends out a message and does not receive any + expected reply before the retransmission timer expires (i.e., + RETRANS_TIMER), a transaction partner will try to retransmit the + message. The procedure is reiterated until a maximum retry is + reached (e.g., three times). An exception is the last message (e.g., + ACK) sent from the server in a transaction. After sending this + message, the retransmission timer will be disabled since no + additional feedback is expected. + + In addition, if the partner receives a retransmission of the last + incoming packet it handled, the partner can resend the same answer to + the incoming packet with a limited frequency. If an answer cannot be + generated right after the request is received, the partner needs to + generate a PROCESSING message as the answer. + + To optimize message retransmission, a partner could also store the + last incoming packet and the associated answer. Note that the times + of retransmission could be decided by the local policy, and + retransmission will not cause any change of sequence numbers. + +12. Some Operational Guidelines + +12.1. CPNP Server Logging + + The CPNP server should be configurable to log various events and + associated information. Such information may include the following: + + * Client's IP address + + * Any event change (e.g., new quotation order, offer sent, order + confirmation, order cancellation, order withdrawal, etc.) + + * Timestamp + + The exact logging details are deployment specific. + +12.2. Business Guidelines and Objectives + + The CPNP server can operate in the following modes: + + Fully automated mode: + The CPNP server is provisioned with a set of business guidelines + and objectives that will be used as an input to the decision- + making process. The CPNP server will service received orders that + fall into these business guidelines; otherwise, requests will be + escalated to an administrator that will formally validate or + invalidate an order request. The set of policies to be configured + to the CPNP server are specific to each administrative entity + managing a CPNP server. + + Administrative-based mode: + This mode assumes some or all of the CPNP server's operations are + subject to a formal administrative validation. CPNP events will + trigger appropriate validation requests that will be forwarded to + the contact person(s) or department that is responsible for + validating the orders. Administrative validation messages are + relayed using another protocol (e.g., SMTP) or a dedicated tool. + + Business guidelines are local to each administrative entity. How + validation requests are presented to an administrator are out of + scope of this document; each administrative entity may decide the + appropriate mechanism to enable for that purpose. + +13. Security Considerations + + Means to defend the server against denial-of-service attacks must be + enabled. For example, access control lists can be enforced on the + client, the server, or the network in between to allow a trusted + client to communicate with a trusted server. + + The client and the server must be mutually authenticated. + Authenticated encryption must be used for data confidentiality and + message integrity. + + The protocol does not provide security mechanisms to protect the + confidentiality and integrity of the packets transported between the + client and the server. An underlying security protocol such as + (e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport + Layer Security (TLS) [RFC8446]) must be used to protect the integrity + and confidentiality of protocol messages. In this case, if it is + possible to provide automated key management (Section 2.1 of + [RFC4107]) and associate each transaction with a different key, + inter-transaction replay attacks can naturally be addressed. If the + client and the server use a single key, an additional mechanism + should be provided to protect against inter-transaction replay + attacks between them. Clients must implement DTLS record replay + detection (Section 3.3 of [RFC6347]) or an equivalent mechanism to + protect against replay attacks. + + DTLS and TLS with a cipher suite offering confidentiality protection + and the guidance given in [RFC7525] must be followed to avoid attacks + on (D)TLS. + + The client must silently discard CPNP responses received from unknown + CPNP servers. The use of a randomly generated Transaction-ID makes + it hard to forge a response from a server with a spoofed IP address + belonging to a legitimate CPNP server. Furthermore, CPNP demands + that messages from the server must include the correct identifiers of + the orders. Two order identifiers are used: one generated by the + client and a second one generated by the server. Both the CPNP + client and server maintain the local identifier they assigned and the + one assigned by the peer for a given order. Means to detect swapping + of these identifiers (even when such swapping occurs inadvertently at + the client or the server) should be enabled by CPNP clients/servers. + For example, the CPNP server should not assign a Provider agreement + identifier that is equal to a Customer agreement identifier used by + the CPNP client. + + The Provider must enforce the means to protect privacy-related + information included in the documents (see Section 8.7) exchanged in + CPNP messages [RFC6462]. In particular, this information must not be + revealed to external parties without the consent of Customers. + Providers should enforce policies to make Customer fingerprinting + difficult to achieve (e.g., in a recursion request). For more + discussion about privacy, refer to [RFC6462] [RFC6973]. + + The Nonce and the Transaction-ID attributes provide sufficient + randomness and can effectively tolerate attacks raised by off-path + adversaries, who do not have the capability of eavesdropping and + intercepting the packets transported between the client and the + server. Only authorized clients must be able to modify accepted CPNP + orders. The use of a randomly generated Nonce by the server makes it + hard to modify an agreement on behalf of a malicious third party. + +14. IANA Considerations + + This document has no IANA actions. + +15. References + +15.1. Normative References + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + <https://www.rfc-editor.org/info/rfc3339>. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <https://www.rfc-editor.org/info/rfc4086>. + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, DOI 10.17487/RFC5511, April + 2009, <https://www.rfc-editor.org/info/rfc5511>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <https://www.rfc-editor.org/info/rfc6347>. + + [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP + Connectivity Provisioning Profile (CPP)", RFC 7297, + DOI 10.17487/RFC7297, July 2014, + <https://www.rfc-editor.org/info/rfc7297>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <https://www.rfc-editor.org/info/rfc7525>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + +15.2. Informative References + + [AGAVE] Boucadair, M., Georgatsos, P., Wang, N., Griffin, D., + Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE + Approach for Network Virtualization: Differentiated + Services Delivery", Annals of Telecommunication, Volume + 64, 277-288, DOI 10.1007/s12243-009-0103-4, April 2009, + <https://rd.springer.com/article/10.1007/ + s12243-009-0103-4>. + + [COPS-SLS] Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)", + Work in Progress, Internet-Draft, draft-nguyen-rap-cops- + sls-03, 5 July 2002, <https://tools.ietf.org/html/draft- + nguyen-rap-cops-sls-03>. + + [DSNP] Chen, J., "Dynamic Service Negotiation Protocol (DSNP)", + Work in Progress, Internet-Draft, draft-itsumo-dsnp-03, 2 + March 2006, + <https://tools.ietf.org/html/draft-itsumo-dsnp-03>. + + [ETICS] EU FP7 ETICS Project, "Economics and Technologies of + Inter-Carrier Services", January 2014, + <https://cordis.europa.eu/project/id/248567>. + + [L2VPN-NETWORK-YANG] + Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., + Jalil, L., and J. Ma, "A Layer 2 VPN Network YANG Model", + Work in Progress, Internet-Draft, draft-ietf-opsawg-l2nm- + 00, 2 July 2020, + <https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00>. + + [L3VPN-NETWORK-YANG] + Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., + and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in + Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05, + 16 October 2020, <https://tools.ietf.org/html/draft-ietf- + opsawg-l3sm-l3nm-05>. + + [LISP-MS-DISCOVERY] + Boucadair, M. and C. Jacquenet, "LISP Mapping Service + Discovery at Large", Work in Progress, Internet-Draft, + draft-boucadair-lisp-idr-ms-discovery-01, 9 March 2016, + <https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms- + discovery-01>. + + [NETSLICES-ARCH] + Geng, L., Dong, J., Bryant, S., Makhijani, K., Galis, A., + Foy, X. D., and S. Kuklinski, "Network Slicing + Architecture", Work in Progress, Internet-Draft, draft- + geng-netslices-architecture-02, 3 July 2017, + <https://tools.ietf.org/html/draft-geng-netslices- + architecture-02>. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + DOI 10.17487/RFC2782, February 2000, + <https://www.rfc-editor.org/info/rfc2782>. + + [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, + K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. + Smith, "COPS Usage for Policy Provisioning (COPS-PR)", + RFC 3084, DOI 10.17487/RFC3084, March 2001, + <https://www.rfc-editor.org/info/rfc3084>. + + [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual + Private Network (VPN) Terminology", RFC 4026, + DOI 10.17487/RFC4026, March 2005, + <https://www.rfc-editor.org/info/rfc4026>. + + [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic + Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, + June 2005, <https://www.rfc-editor.org/info/rfc4107>. + + [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., + and A. Gonguet, "Framework for Layer 3 Virtual Private + Networks (L3VPN) Operations and Management", RFC 4176, + DOI 10.17487/RFC4176, October 2005, + <https://www.rfc-editor.org/info/rfc4176>. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, <https://www.rfc-editor.org/info/rfc6125>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", + RFC 6462, DOI 10.17487/RFC6462, January 2012, + <https://www.rfc-editor.org/info/rfc6462>. + + [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object + Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, + <https://www.rfc-editor.org/info/rfc6574>. + + [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, + P., Ma, K., and G. Watson, "Use Cases for Content Delivery + Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, + November 2012, <https://www.rfc-editor.org/info/rfc6770>. + + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + <https://www.rfc-editor.org/info/rfc6793>. + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + DOI 10.17487/RFC6830, January 2013, + <https://www.rfc-editor.org/info/rfc6830>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <https://www.rfc-editor.org/info/rfc6973>. + + [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, + October 2013, <https://www.rfc-editor.org/info/rfc7049>. + + [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined + Networking: A Perspective from within a Service Provider + Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, + <https://www.rfc-editor.org/info/rfc7149>. + + [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- + Pascual, J., and D. Lewis, "Locator/Identifier Separation + Protocol (LISP) Network Element Deployment + Considerations", RFC 7215, DOI 10.17487/RFC7215, April + 2014, <https://www.rfc-editor.org/info/rfc7215>. + + [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for + Application-Based Network Operations", RFC 7491, + DOI 10.17487/RFC7491, March 2015, + <https://www.rfc-editor.org/info/rfc7491>. + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + <https://www.rfc-editor.org/info/rfc8040>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, + "YANG Data Model for L3VPN Service Delivery", RFC 8299, + DOI 10.17487/RFC8299, January 2018, + <https://www.rfc-editor.org/info/rfc8299>. + + [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models + Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, + <https://www.rfc-editor.org/info/rfc8309>. + + [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. + Kumar, "Framework for Interface to Network Security + Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, + <https://www.rfc-editor.org/info/rfc8329>. + + [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG + Data Model for Layer 2 Virtual Private Network (L2VPN) + Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October + 2018, <https://www.rfc-editor.org/info/rfc8466>. + + [RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., + and P. Iovanna, "Cooperating Layered Architecture for + Software-Defined Networking (CLAS)", RFC 8597, + DOI 10.17487/RFC8597, May 2019, + <https://www.rfc-editor.org/info/rfc8597>. + + [RNAP] Wang, X., "A Resource Negotiation and Pricing Protocol + (RNAP)", + <http://www.cs.columbia.edu/~xinwang/public/projects/ + protocol.html>. + + [SNAP] Czajkowski, K., Foster, I., Kesselman, C., Sander, V., and + S. Tuecke, "SNAP: A Protocol for Negotiating Service Level + Agreements and Coordinating Resource Management in + Distributed Systems", DOI 10.1.1.19.5907, 2002, + <http://citeseerx.ist.psu.edu/viewdoc/ + summary?doi=10.1.1.19.5907>. + + [SrNP] Georgatsos, P. and G. Giannakopoulos, "Service Negotiation + Protocol (SrNP)", <https://www.ist- + tequila.org/presentations/srnp-pipcm.pdf>. + + [TEAS-SLICE-NBI] + Contreras, L. M., Homma, S., and J. A. Ordonez-Lucena, + "Considerations for defining a Transport Slice NBI", Work + in Progress, Internet-Draft, draft-contreras-teas-slice- + nbi-02, 13 July 2020, <https://tools.ietf.org/html/draft- + contreras-teas-slice-nbi-02>. + +Acknowledgements + + Thanks to Diego R. Lopez, Adrian Farrel, Éric Vyncke, Eric Kline, and + Benjamin Kaduk for the comments. + + Thanks to those that reviewed this document for publication in the + Independent Stream. + + Special thanks to Luis Miguel Contreras Murillo for the detailed + review. + +Authors' Addresses + + Mohamed Boucadair (editor) + Orange + 35000 Rennes + France + + Email: mohamed.boucadair@orange.com + + + Christian Jacquenet + Orange + 35000 Rennes + France + + Email: christian.jacquenet@orange.com + + + Dacheng Zhang + Huawei Technologies + + Email: dacheng.zhang@huawei.com + + + Panos Georgatsos + Centre for Research and Innovation Hellas + 78, Filikis Etairias str. + 38334 Volos + Greece + + Phone: +302421306070 + Email: pgeorgat@gmail.com |