Orange

Rennes 35000 France mohamed.boucadair@orange.com

Orange

Rennes 35000 France christian.jacquenet@orange.com

Huawei Technologies

dacheng.zhang@huawei.com

Centre for Research and Innovation Hellas

78, Filikis Etairias str. Volos Hellas 38334 Greece +302421306070 pgeorgat@gmail.com

SDN Order Request Handling Automation Dynamic Provisioning CDN Interconnection Service Delivery Service Activation 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 .

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 () 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

• .  Introduction
• .  Terminology
• .  CPNP Functional Elements
• .  Order Processing Models
• .  Sample Use Cases
• .  CPNP Deployment Models
• .  CPNP Negotiation Model
• .  Protocol Overview
  • .  Client/Server Communication
  • .  Policy Configuration on the CPNP Server
  • .  CPNP Session Entries
  • .  CPNP Transactions
  • .  CPNP Timers
  • .  CPNP Operations
  • .  Connectivity Provisioning Documents
  • .  Child PQOs
  • .  Multi-Segment Service
  • . Negotiating with Multiple CPNP Servers
  • . State Management
    • .  On the Client Side
    • .  On the Server Side
• .  CPNP Objects
  • .  Attributes
    • .  CUSTOMER_ORDER_IDENTIFIER
    • .  PROVIDER_ORDER_IDENTIFIER
    • .  TRANSACTION_ID
    • .  SEQUENCE_NUMBER
    • .  NONCE
    • .  EXPECTED_RESPONSE_TIME
    • .  EXPECTED_OFFER_TIME
    • .  VALIDITY_OFFER_TIME
    • .  SERVICE_DESCRIPTION
    • . CPNP Information Elements
  • .  Operation Messages
    • .  QUOTATION
    • .  PROCESSING
    • .  OFFER
    • .  ACCEPT
    • .  DECLINE
    • .  ACK
    • .  CANCEL
    • .  WITHDRAW
    • .  UPDATE
    • . FAIL
    • . ACTIVATE
• . CPNP Message Validation
  • .  On the Client Side
  • .  On the Server Side
• . Theory of Operation
  • .  Client Behavior
    • .  Order Negotiation Cycle
    • .  Order Withdrawal Cycle
    • .  Order Update Cycle
  • .  Server Behavior
    • .  Order Processing
    • .  Order Withdrawal
    • .  Order Update
  • .  Sequence Numbers
  • .  Message Retransmission
• . Some Operational Guidelines
  • .  CPNP Server Logging
  • .  Business Guidelines and Objectives
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

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 . 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 . introduces several order processing models and defines those that are targeted by CPNP. The CPNP negotiation model is then detailed in . 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 . 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) or RESTCONF 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 , Service Negotiation Protocol , Dynamic Service Negotiation Protocol , Resource Negotiation and Pricing Protocol , Service Negotiation and Acquisition Protocol ). 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) , 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 . This specification builds on that effort.

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.

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 ().
2. Cancel an ongoing quotation order under negotiation ().
3. Accept an offer made by a server ().
4. Withdraw an agreement ().
5. Update an agreement ().

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 ().
2. Make an offer ().
3. Cancel an ongoing quotation order ().
4. Process an order withdrawal ().

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 .

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.

Sample Use Cases A non-exhaustive list of CPNP use cases is provided below:

1. 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 . A L3VPN Service YANG data model (L3SM) is defined in . Once an agreement is reached, the service can be provisioned using, e.g., the L3VPN Network YANG data model specified in . 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 . Once an agreement is reached, the L2VPN service can be provisioned using, e.g., the L2VPN Network YANG data model specified in .
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 .
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 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 .
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) 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) 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, ).
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 (see ).

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

11. Mapping Service Providers (MSPs) can use CPNP to enrich their mapping database by interconnecting their mapping system (see ). 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 . Also, it prevents the fragmentation of the LISP mapping database. A framework is described in .

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

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 .

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.

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 (). 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 ():

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.

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

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 ), 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 ). 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 ). 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 ). The model is flexible enough to accommodate changing conditions during the lifetime of a service (e.g., the introduction of an additional VPN site).

Overall Negotiation Process +------+ +------+ +------+ +------+ |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

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. 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 ().

Protocol Overview

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) . 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 . 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 (). 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 . Considerations related to mutual authentication are discussed in .

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 ). 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 ). For example, the outcome of CPNP may be passed to modules such as Application-Based Network Operations (ABNO) or network controllers. These controllers will use protocols such as NETCONF 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.

Order Handling Management Functional Block (Focus on Internal Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .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 | +-------------------------------------------------------+

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.

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 ().
• Customer agreement identifier: This is a unique identifier assigned to the order under negotiation by the CPNP client (). 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 (). This identifier is also used by the server to identify the agreement that will result from a successful negotiation.
• Transaction-ID ().

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 (). 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 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 ).

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 . 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 ). 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 ). 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 ).

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 ():

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 ():

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 ():

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 ():

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 ():

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 ():

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 ():

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

WITHDRAW ():

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

UPDATE ():

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 ():

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 ). Additional service-specific objects for CPNP messages to accommodate alternative deployment schemes or other service provisioning needs can be defined in the future.

Connectivity Provisioning Documents CPNP makes use of several flavors of Connectivity Provisioning Documents (CPD). These documents follow the same CPP template described in .

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.

shows a typical CPNP negotiation cycle and the use of the different types of CPDs.

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

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.

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 ). 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).

Example of Child Orders +------+ +--------+ +--------+ |Client| |Server A| |Server B| +------+ +--------+ +--------+ | | | |=====QUOTATION=====>| | |<====PROCESSING=====| | | |=====QUOTATION=====>| | |<====PROCESSING=====| | |<=======OFFER=======| | |=====PROCESSING====>| | |=======ACCEPT======>| | |<=======ACK=========| |<=======OFFER=======| | |=====PROCESSING====>| | |=======ACCEPT======>| | |<=======ACK=========| | | | |

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 (). If recursion is not explicitly disabled, the server may notify the client when appropriate (). Such notification may depend on the nature of the service and also regulatory considerations.

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.

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 ).

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.

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 .

Example of a CPNP Finite State Machine (Client Side) +------------------+ | 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------+ +------------------+

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.

CPNP Finite State Machine (Server Side) +------------------+ +------------------+ |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-----+ | | +---------------------------+ +------------------+

CPNP Objects This section defines CPNP objects using the Routing Backus-Naur Form (RBNF) format defined in . Please also note the following:

Attributes

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.

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.

TRANSACTION_ID This object conveys the Transaction-ID introduced in .

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 .

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.

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 .

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 .

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 .

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.

CPD The RBNF format of the CPD is shown in .

The RBNF format of the CPD <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>

CPNP Information Elements An Information Element (IE) is an optional object that can be included in a CPNP message.

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> ...]

Provider Description The server may include administrative information in an offer such as the following:

• Name
• AS Number
• Contact Information

The format of this Information Element is as follows: <Provider Description> ::= [<NAME>][<Contact Information>] [<AS_NUMBER>]

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>]

Operation Messages This section defines the RBNF format of CPNP operation messages. The following operation codes are used: CPNP Operation Message Codes

Code	Operation Message	Reference
1	QUOTATION
2	PROCESSING
3	OFFER
4	ACCEPT
5	DECLINE
6	ACK
7	CANCEL
8	WITHDRAW
9	UPDATE
10	FAIL
11	ACTIVATE

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.

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 ). 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., ). When the client sends the QUOTATION message to the server, the state of the order changes to "PQOSent" at the client side.

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 ). 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 () or with a FAIL message if the time extension request is rejected (). 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: PROCESSING_SUBCODE Codes

Subcode	Description
1	Upgrade of local resources
2	Request external resources

Request More Negotiation Time: Granted +------+ +------+ |Client| |Server| +------+ +------+ |=======QUOTATION(Requested CPD)=====>| |<========PROCESSING(time1)===========| ... |<========PROCESSING(MoreTime)========| |============ACK(TimeGranted)========>| ... |<=========OFFER(Offered CPD)=========| |=============PROCESSING=============>| |=========ACCEPT(Accepted CPD)=======>| |<=========ACK(Accepted CPD)==========| | |

Request More Negotiation Time: Rejected +------+ +------+ |Client| |Server| +------+ +------+ |=======QUOTATION(Requested CPD)=====>| |<========PROCESSING(time1)===========| ... |<========PROCESSING(MoreTime)========| |=====FAIL(More Time Rejected)=======>|

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., or ).

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 ().

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: DECLINE Message Codes

Code	Description
1	Unacceptable gap between the request and the offer
2	Conflict with another offer from another server
3	Activation type mismatch

If no order is found, the server returns a FAIL message to the requesting client. In order to prevent DDoS (Distributed Denial of Service) attacks, the server should restrict the number of FAIL messages sent to a requesting client. It may also rate-limit FAIL messages. A flow example is shown in .

DECLINE Flow Example +------+ +------+ |Client| |Server| +------+ +------+ |=======QUOTATION(Requested CPD)=====>| |<============PROCESSING==============| |<=========OFFER(Offered CPD)=========| |=============PROCESSING=============>| |===============DECLINE==============>| |<================ACK=================| | |

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 ).
• 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.

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.

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. shows a typical usage of this message.

WITHDRAW Flow Example +------+ +------+ |Client| |Server| +------+ +------+ |============WITHDRAW(CPD)===========>| |<============PROCESSING==============| |<===========ACK(Empty CPD)===========| | |

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.

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 ().
• 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 .

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

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: FAIL Message Error Codes

Status Code	Error Code	Description
1	Message Validation Error	The message cannot be validated (see ).
2	Authentication Required	The request cannot be handled because authentication is required.
3	Authorization Failed	The request cannot be handled because authorization failed.
4	Administratively prohibited	The request cannot be handled because of administrative policies.
5	Out of Resources	The request cannot be honored because resources (e.g., capacity) are insufficient.
6	Network Presence Error	The request cannot be honored because there is no network presence.
7	More Time Rejected	The request to extend the time for negotiation is rejected by the client.
8	Unsupported Activation Type	The request cannot be handled because the requested activation type is not supported.

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 ().
• 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.

illustrates the use of the ACTIVATE operation.

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

CPNP Message Validation Both the client and the server proceed with CPNP message validation. The following tables summarize the validation checks to be followed.

On the Client Side Client Side Validation Checks

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 (QUOTATION Transaction)	{Source IP address, source port number, destination IP address, destination port number, 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 Transaction)	{Source IP address, source port number, 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 (WITHDRAW Transaction)	{Source IP address, source port number, destination IP address, destination port number, 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.

On the Server Side Server Side Validation Checks

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.

Theory of Operation Both the CPNP client and server proceed with message validation checks as specified in .

Client Behavior

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, ), 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 () 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 (). 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 ().

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 . 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.

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 . 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 .

Server Behavior

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 (), 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 (). 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 ). 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 . 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".

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 :

• 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.

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 :

• 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 . The server should generate a new Nonce value to be included in the offer made to the client.

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.

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.

Some Operational Guidelines

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.

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.

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) , Transport Layer Security (TLS) ) must be used to protect the integrity and confidentiality of protocol messages. In this case, if it is possible to provide automated key management () and associate each transaction with a different key, inter-transaction replay attacks can naturally be addressed. If the client and the server use a single key, an additional mechanism should be provided to protect against inter-transaction replay attacks between them. Clients must implement DTLS record replay detection () or an equivalent mechanism to protect against replay attacks. DTLS and TLS with a cipher suite offering confidentiality protection and the guidance given in 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 ) exchanged in CPNP messages . 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 . 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.

IANA Considerations This document has no IANA actions.

References Normative References This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK] This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References EU FP7 ETICS Project Annals of Telecommunication, Volume 64, 277-288 Work in Progress National Tsing Hua University This memo presents the specification of Dynamic Service Negotiation Protocol (DSNP). DSNP is a protocol to negotiate the SLS (Service Level Specification) in IP layer. It can be used for service negotiation from host to network, network to host, and network to network. The automated negotiation makes service negotiation efficient in terms of time, cost, and correctness, etc. The dynamic negotiation not only allows users to adapt their needs dynamically, but also let providers better utilize the network. The DSNP messages and packet formats are detailed. DSNP can be used in both wireline and wireless networks. It is, however, particularly useful in mobile environment. To demonstrate the usefulness of DSNP, a reference wireless QoS architecture is presented. Exemplary applications are illustrated. Work in Progress EU FP7 ETICS Project Telefonica Telefonica Orange Vodafone Verizon China Unicom This document defines a YANG Data model (called, L2NM) that can be used to manage the provisioning of Layer 2 VPN services within a Service Provider Network. This YANG module provides representation of the Layer 2 VPN Service from a network standpoint. The module is meant to be used by a Network Controller to derive the configuration information that will be sent to relevant network devices. The L2NM YANG Data model complements the Layer 2 Service Model (RFC8466) by providing a network-centric view of the service that is internal to a Service Provider. Work in Progress Telefonica Telefonica Orange Vodafone Nokia This document defines a L3VPN Network YANG Model (L3NM) that can be used to manage the provisioning of Layer 3 Virtual Private Network (VPN) services within a Service Provider's network. The model provides a network-centric view of L3VPN services. L3NM is meant to be used by a Network Controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate the communication between a service orchestrator and a network controller/orchestrator. Work in Progress Locator/ID Separation Protocol (LISP) operation relies upon a mapping mechanism that is used by ingress/egress Tunnel Routers (xTR) to forward traffic over the LISP network. The ability of dynamically discovering the Map-Resolver and Map-Server entities that provide such mapping services is meant to facilitate global LISP operation (automatic discovery of Map-Resolvers and Map-Servers). This document specifies a BGP Extended Communities attribute that can be used to dynamically discover LISP Mapping Systems of different domains. Work in Progress China Mobile Huawei Technologies Huawei Technologies Huawei Technologies University College London InterDigital Inc. Orange This document defines the overall architecture of network slicing. Based on the general architecture, basic concepts of network slicing and examples of network slicing instances are introduced for clarification purposes. Some architectural considerations about the data plane, control plane, management and orchestration of network slicing are described to give a general view of network slicing implementation principles. Work in Progress This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK] The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community. The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community. Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes. Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes. The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK] This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment. It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding. Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text. The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated. This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities. This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path. Telefonica NTT Telefonica The transport network is an essential component in the end-to-end delivery of services and, consequently, with the advent of network slicing it is necessary to understand what could be the way in which the transport network is consumed as a slice. This document analyses the needs of potential transport slice customers (i.e., use cases) in order to identify the functionality required on the North Bound Interface (NBI) of a transport slice controller for satisfying such transport slice requests. Work in Progress

Acknowledgements Thanks to , , , , and for the comments. Thanks to those that reviewed this document for publication in the Independent Stream. Special thanks to for the detailed review.

Authors' Addresses Orange

Rennes 35000 France mohamed.boucadair@orange.com

Orange

Rennes 35000 France christian.jacquenet@orange.com

Huawei Technologies

dacheng.zhang@huawei.com

Centre for Research and Innovation Hellas

78, Filikis Etairias str. Volos Hellas 38334 Greece +302421306070 pgeorgat@gmail.com