| Network Working Group | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Intended status: Experimental | France Telecom |
| Expires: October 25, 2014 | April 23, 2014 |
Connectivity Provisioning Negotiation Protocol (CPNP)
draft-boucadair-connectivity-provisioning-protocol-03
This document specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is used to facilitate the dynamic negotiation of service parameters between a Customer and a Provider.
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, CDN (Content Delivery Networks) footprint, etc. CPNP can be extended with new Information Elements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2014.
Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document defines the Connectivity Provisioning Negotiation Protocol (CPNP) that is meant to dynamically exchange and negotiate the connectivity provisioning parameters, and other service-specific parameters, between a Customer and a Provider. CPNP is a tool that introduces automation in the service negotiation and activation procedures, thus fostering the overall service delivery process. CPNP can be seen as a component of the dynamic negotiation meta-domain described in Section 3.4 of [RFC7149].
CPNP is a generic protocol that can be used for other negotiation purposes than connectivity provisioning. For example, CPNP can be used to request extra storage resources, to extend the footprint of a CDN (Content Delivery Networks), to enable additional features from a cloud Provider, etc. CPNP can be extended with new Information Elements (IEs).
[I-D.boucadair-connectivity-provisioning-profile] 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, IPTV, and 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 a reachability scope and capacity needs. CPNP uses the CPP template to encode connectivity provisioning clauses.
As a reminder, several proposals have been made in the past by the community (e.g., COPS-SLS, SrNP (Service Negotiation Protocol), DSNP (Dynamic Service Negotiation Protocol, RNAP (Resource Negotiation and Pricing Protocol), SNAP (Service Negotiation and Acquisition Protocol), etc.). None of these proposals has been standardized by IETF. It is out of the scope of this document to elaborate on the differences between CPNP and the aforementioned proposals.
This document is organized as follows:
This document makes use of the following terms:
The following functional elements are defined:
There are basically three models for customer's order processing purposes:
Even if the frozen model could also yield the instantiation of a CPP template and CPNP could be used to display the said CPP to the Customer and confirm the order is being processed/delivered, etc., this document focuses on the negotiation-based model.
Order processing management on the Network Provider's side is usually connected with the following functional blocks:
CPNP does not assume any specific knowledge about these functional blocks, but the instantiation of the connectivity provisioning requests may be conditioned by the information manipulated by some of these blocks. For example, the resources that can be allocated to accommodate the Customer's requirements may depend on the network planning policy 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 managed by the Provider's Information System.
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
Figure 1: CDN Interconnection
A list of CPNP use cases is provided below:
Several CPNP deployment models can be envisaged. Two examples are listed below:
Once the negotiation of connectivity provisioning parameters is completed and an order has been placed by the Customer accordingly, the actual network provisioning operations are initiated. The specification of corresponding dynamic resource allocation and policy enforcement schemes, as well as how CPNP servers interact with network provisioning functional blocks are out of the scope of this document.
This document does not make any assumption about the CPNP deployment model either.
CPNP adopts a Quotation Order/Offer/Answer model where:
The server may support the optional functionality to publish available services to the clients. Dedicated templates can be defined for the purpose of service announcements. The client will use these templates to initiate its CPNP negotiation cycle.
Only one Offer/Answer stage is assumed within one single CPNP transaction (Section 8.6). Nevertheless, multiple CPNP transactions can be undertaken by the CPNP client (see Figure 2).
+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|==== Quotation Order=====>| |==== Quotation Order======>|
|<====Make an offer========| |<=====Make an offer========|
|=========Accept==========>| |=========Decline==========>|
1-Step Successful Negotiation 1-Step Failed Negotiation
Cycle Cycle
+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|===Quotation Order(a)====>| |===Quotation Order(i)====>|
|<====Make an offer========| |<=====Make an offer=======|
|========Decline==========>| |=========Decline=========>|
|===Quotation Order(b)====>| |===Quotation Order(j)====>|
|<====Make an offer========| |<=====Make an offer=======|
|=========Accept==========>| |=========Decline=========>|
|===Quotation Order(k)====>|
|<=====Make an offer=======|
|=========Decline=========>|
|===Quotation Order(l)====>|
|<==Fail to make an offer==|
N-Step Negotiation Cycle: N-Step Negotiation Cycle:
Successful Negotiation Failed Negotiation
Figure 2: Overall Negotiation Process
CPNP is a client/server protocol which runs over UDP. No permanent CPNP session needs to be maintained between the client and the server. There is no need to run CPNP over a reliable transport mode because CPNP messages are acknowledged.
The server uses CPNP_PORT (see Section 14) to bind the CPNP service. CPNP client sends messages to CPNP_PORT. The same port is used as the source port of the request sent to the server to document service requirements, and must be used by the client to listen to messages sent by the server.
CPNP messages can also be transported over DTLS [RFC6347].
CPNP is independent of the IP address family.
The CPNP client can be configured with the CPNP server using manual or dynamic configuration means. For example, Providers may configure dedicated SRV records ([RFC2782]).
Discussions about how the client discovers its server(s) are out of the scope of this document. The document assumes a CPNP server can be reached by the CPNP client, thanks to some configuration means.
As an input to the CPNP server's decision-making process, the CPNP server may be connected to various external modules such as: Customer Profiles, Network Topology, Network Resource Management, Orders Repository, AAA or Network Provisioning Manager (an example is shown in Figure 3).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.Business & Administrative Management .
.+------------------------++---------------------------+.
.| Business Guidelines || Billing & Charging |.
.+-----------+------------++-----------+---------------+.
. | | .
. +-------------------+ | .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
.Order Handling Management | | .
. +-------------------+ +-------+-----+--------------+ .
. |Network Topology DB+--+ CPNP Server | .
. +-------------------+ +-+---+---+---+---+-----+----+ .
. | | | | | | .
. +------------------------+-+ | | | | | .
. | Network Dimensioning | | | | | | .
. | & Planning | | | | | | .
. +--------------------------+ | | | | | .
. +----------------------------+-+ | | | +---+----+ .
. | | | | | | AAA | .
. | Network +------------+ | | | +--------+ .
. | Resource | +------------+-+ | +-+----------+ .
. | Management | | Customer | | | Orders | .
. | | | Profiles | | | Repository | .
. +-----------------+ +--------------+ | +------------+ .
. . . . . . . . . . . . . . . . . . . .|. . . . . . . . .
+--------------------------------------+----------------+
| Network Provisioning Manager |
+-------------------------------------------------------+
Figure 3: Order Handling Management Functional Block
These external modules provide inputs to the CPNP server, so that it can:
The above list of CPNP server operations is not exhaustive.
The following order handling modes can be also configured on the server:
Both the client and server maintain the following CPNP transport session information:
A CPNP session is identified by the following items:
An extended PQO session denotes a 4-uplet defined as follows:
A CPNP transaction occurs between a client and a server and comprises all CPNP messages, from the first request sent by the client to the server until a final response sent by the server to the client and which completes the transaction. The 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 denoted as Transaction-ID.
The Transaction-ID must be randomly assigned be the CPNP client, according to the best current practice for generating random numbers [RFC4086] that cannot be guessed easily. Transaction-ID is used as part of the validation of CPNP responses received by the client.
Using cryptographically random Transaction-IDs provides some protection against session hijacking.
Sequence Number is set in the first CPNP message by the client. This number is then incremented fro each request within the same CPNP transaction.
The current CPNP operations are listed below. They may be augmented, depending on the nature of some transactions or because of security considerations that may suggest a CPNP client/server authentication phase before negotiation begins.
CPNP primitives are service-independent. This document specifies objects that are required for connectivity provisioning negotiation (see Section 8.8). Additional service-specific objects to be carried in CPNP messages can be defined in the future to accommodate other deployment needs.
CPNP makes use of several flavors of Connectivity Provisioning Documents (CPD). These documents follow the CPP template described in [I-D.boucadair-connectivity-provisioning-profile].
Figure 4 shows a typical CPNP transaction and the use of Connectivity Provisioning Documents:
+------+ +------+ |Client| |Server| +------+ +------+ |======PROVISION (Requested CPD)=====>| |<============PROCESSING==============| |<========OFFER (Offered CPD)=========| |=============PROCESSING=============>| |=========ACCEPT (Agreed CPD)========>| |<=========ACK (Agreed CPD)===========|
Figure 4: Connectivity Provisioning Documents
If the server detects network resources from another Network Provider need to be allocated in order to accommodate the requirements described in a PQO (e.g., context of an inter-domain VPN service where additional PE router resources need to be allocated), the server may generate child PQOs to request the appropriate network provisioning operations (see Figure 5). In such situation, the server behaves as a CPNP client. The server associates the parent order with its child PQOs. This is typically achieved by locally adding the reference of the child PQO to the parent order.
+------+ +--------+ +--------+ |Client| |Server A| |Server B| +------+ +--------+ +--------+ | | | |=====PROVISION=====>| | |<====PROCESSING=====| | | |=====PROVISION=====>| | |<====PROCESSING=====| | |<=======OFFER=======| | |=====PROCESSING====>| | |=======ACCEPT======>| | |<=======ACK=========| |<=======OFFER=======| | |=====PROCESSING====>| | |=======ACCEPT======>| | |<=======ACK=========| |
Figure 5: Example of Child Orders
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 ones).
The following lists the states which can be associated with a given order on the client's side:
+------------------+
| Created |-----------------+
+------------------+ |
| |
v |
+------------------+ |
|AwaitingProcessing|----------------+|
+------------------+ ||
| ||
PROVISION ||
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 |
+------------------+ |
| AcceptAck |---WITHDRAW------+
+------------------+
Figure 6: CPNP Finite State Machine (Client Side)
The following lists the states which can be associated with a given order on the server's side:
+------------------+
+---------------------| ChildCreated |
| +------------------+
v | ^
+------------------+ | |
| ChildPQOSent |----------------+| P
+------------------+ || R
| || O
PROVISION || V
v || I +--------------------+
+---------------------+ CANCEL || S | 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|-| AcceptAck |
+------------------+ | | +------------------+
| ACK | |
v | |
+------------------+ | |
| ChildAcceptAck |---WITHDRAW-----+ |
+------------------+ |
| |
+--------------------------------------+
Figure 7: CPNP Finite State Machine (Server Side)
CPNP adopts a simple retransmission procedure which relies on a retransmission timer denoted as RETRANS_TIMER and maximum retry threshold. The use of RETRANS_TIMER and maximum retry threshold are described in Section 11.
The response timer (RESPONSE_TIMER) is the maximum time, defined in seconds, between a connectivity provisioning quotation order request sent to the server and the corresponding response. If this timer is exceeded, the corresponding quotation order is cancelled by the client. Relevant CANCEL messages are generated accordingly.
An offer expiration timer (EXPIRE_TIMER) represents the maximum time, defined in minutes, after which an offer made by the server will be invalid.
This section defines CPNP objects using the RBNF format defined at [RFC5511].
This document focuses on connectivity provisioning objects; additional Information Elements can be defined in the future.
CUSTOMER_ORDER_IDENTIFIER is an identifier which is assigned by a client to identify an order. This identifier must be unique. Rules for assigning this identifier are specific to the client. The value of CUSTOMER_ORDER_IDENTIFIER is included in all CPNP messages.
The server handles CUSTOMER_ORDER_IDENTIFIER as an opaque value.
PROVIDER_ORDER_IDENTIFIER is an identifier which is assigned by a server to identify an order. This identifier must be unique to the server. Rules for assigning this identifier are specific to the server. The value of PROVIDER_ORDER_IDENTIFIER is included in all CPNP message, except PROVISION messages.
The client handles PROVIDER_ORDER_IDENTIFIER as an opaque value.
This object conveys the Transaction-ID introduced in Section 8.6.
Sequence Number is a number that is incremented on every new CPNP message within a CPNP transaction. This number is used to avoid reply attacks.
NONCE is a random value assigned by the CPNP server. It is RECOMMENDED to assign unique NONCE values for each order.
NONCE is mandatory to be included in subsequent CPNP client operations such as: withdraw an existing order or update an order.
If the NONCE validation checks fail, the server rejects the request with a FAIL message including the appropriate failure reason code.
This attribute indicates the date by when the client is expecting to receive a response from the server. If no offer is received by then, the client will consider the quotation order as rejected.
EXPECTED_RESPONSE_DATE follows date format specified in [RFC1123].
This attribute indicates the date by when the server is expecting to make an offer to the client. If no offer is received by then, the client will consider the order as rejected.
EXPECTED_OFFER_DATE follows date format specified in [RFC1123].
This attribute indicates the date of a validity of an offer made by the server. If the offer is not accepted before this date expires, the server will consider the client has rejected the offer; the server will silently clear this order.
VALIDITY_DATE follows date format specified in [RFC1123].
The RBNF format of the Connectivity Provisioning Document is shown below:
<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=
<Connectivity Provisioning Component> ...
<Connectivity Provisioning Component> ::=
<CONNECTIVITY_PROVISIONING_PROFILE> ...
<CONNECTIVITY_PROVISIONING_PROFILE> ::=
<Customer Nodes Map>
<SCOPE>
<QoS Guarantees>
<Availability>
<CAPACITY>
<Traffic Isolation>
<Conformance Traffic>
<Flow Identification>
<Overall Traffic Guarantees>
<Routing and Forwarding>
<Activation Means>
<Invocation Means>
<Notifications>
<Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER>
<LOCALISATION>
An Information Element is an optional object which can be included in a CPNP message.
The client may include administrative information such as:
The format of this Information Element is as follows:
<Customer Description> ::= <NAME> <Contact Information>
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
The server may include administrative information in an offer such as:
The format of this Information Element is as follows:
<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
The client may include some negotiation options such as:
Other negotiation options may be defined in the future.
The format of this Information Element is as follows:
<Negotiation Options> ::= [<COST>][<PURPOSE>]
This section specifies the RBNF format of CPNP operation messages.
The format of PROVISION message is shown below:
A PROVISION message must include an order identifier which is generated by the client. Because several orders can be issued to several servers, the PROVISION message must also include a Transaction-ID. The message may include an EXPECTED_RESPONSE_DATE which indicates by when the client is expecting to receive an offer from the server. PROVISION message must also include a requested connectivity provisioning document.
When the client sends the PROVISION message to the server, the state of the order changes to "PQOSent".
The format of PROCESSING Message is shown below:
Upon receipt of a PROVISION message, the server proceeds with parsing rules (see Section 10). If no error is encountered, the server generates a PROCESSING response to the client to indicate the PQO has been received and it is being processed. The server must generate an order identifier which identifies the order in its local order repository. The server MUST copy the content of CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed in the PROVISION message. The server may include an EXPECTED_OFFER_DATE by when it expects to make an offer to the client.
Upon receipt of a PROCESSING message, the client verifies whether it has issued a PQO to that server and which contains the CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID. If no such PQO is found, the PROCESSING message is silently ignored. If a PQO is found, the client may check if it accepts the EXPECTED_OFFER_DATE and then, it changes to state of the order to "ServerProcessing".
The format of OFFER message is shown below:
The server answers with an OFFER message to a PROVISION request received from the client. The offer will be considered as rejected by the client if no confirmation (ACCEPT message sent by the client) is received by the server before the expiration of the validity date.
The format of ACCEPT message is shown below:
This message is used by a client to confirm the acceptance of an offer received from a server. The fields of this message are copied from the received OFFER message.
The format of ACK message is shown below:
This message is issued by the server to close a CPNP transaction. In particular, this message is sent as a response to an ACCEPT, WITHDRAW, DECLINE, or CANCEL message. The ACK message must include the copy of the Connectivity Provisioning Document as stored by the server, in particular:
The format of DECLINE message is shown below:
The client can issue a DECLINE message to reject an offer. CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER and TRANSACTION_ID 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.
If no order is found, the server returns a FAIL message to the requesting client.
A flow example is shown in Figure 8.
+------+ +------+ |Client| |Server| +------+ +------+ |======PROVISION (Requested CPD)=====>| |<============PROCESSING==============| |<========OFFER (Offered CPD)=========| |=============PROCESSING=============>| |===============DECLINE==============>| |<================ACK=================|
Figure 8: DECLINE Flow Example
The format of CANCEL message is shown below:
The client can issue a CANCEL message at any stage during the CPNP negotiation process. CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID 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.
If no order is found, the server returns a FAIL message to the requesting client.
The format of WITHDRAW message is shown below:
This message is used to withdraw an offer already subscribed by the Customer. Figure 9 shows a typical usage of this message.
+------+ +------+ |Client| |Server| +------+ +------+ |===========WITHDRAW (CPD)===========>| |<============PROCESSING==============| |<==========ACK (Empty CPD)===========|
Figure 9: WITHDRAW Flow Example
The CPNP 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.
The format of UPDATE message is shown below:
This message is sent by the CPNP client to update an existing connectivity provisioning agreement. The CPNP 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 CPD which integrates the requested modifications. A new Transaction_ID must be assigned by the client.
Upon receipt of an UPDATE message, the server checks whether an order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and NONCE.
+------+ +------+ |Client| |Server| +------+ +------+ |=========UPDATE (Diff CPD)==========>| |<============PROCESSING==============| |<========OFFER (Updated CPD)=========| |=============PROCESSING=============>| |=========ACCEPT (Updated CPD)=======>| |<=========ACK (Updated CPD)==========|
Figure 10: UPDATE Flow Example
A flow chart that illustrates the use of UPDATE operation is shown in Figure 10.
The format of FAIL message is shown below:
This message is sent in the following cases:
The status code indicates the error code. The following codes are currently supported; other codes will be defined in future versions of the document:
Both client and server proceed with CPNP message validation. The following tables summarize the validation checks to be followed.
| Operation | Validation Checks |
|---|---|
| PROCESSING | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier} must match an existing PQO with a state set to "PQOSent". The sequence number carried in the packet must match the sequence number maintained by the client. |
| OFFER | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier} must match an existing order with state set to "PQOSent" or {Source IP address, source port, destination IP address, destination port, 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 match the sequence number maintained by the client. |
| ACK (PROVISION Transaction) | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier, Provider Order Identifier, Offered Connectivity Provisioning Order} must match an order with a state set to "AcceptSent". The sequence number carried in the packet must match the sequence number maintained by the client. |
| ACK (UPDATE Transaction) | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier, Provider Order Identifier, Updated Connectivity Provisioning Order} must match an order with a state set to "AcceptSent". The sequence number carried in the packet must match the sequence number maintained by the client. |
| ACK (WITHDRAW Transaction) | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier, Provider Order Identifier, Empty Connectivity Provisioning Order} must match an order with a state set to "Cancelled". The sequence number carried in the packet must match the sequence number maintained by the client. |
| Method | Validation Checks |
|---|---|
| PROVISION | The source IP address passes existing access filters (if any). |
| ACCEPT | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier, Provider Order Identifier, Nonce, Offered Connectivity Provisioning Order} must match an order with state set to "OfferProposed" or "ProcessngReceived". The sequence number carried in the packet must match the sequence number maintained by the server. |
| DECLINE | {Source IP address, source port, destination IP address, destination port, Transaction-ID, Customer Order Identifier, Provider Order Identifier, Nonce} must match an order with state set to "OfferProposed" or "ProcessngReceived". The sequence number carried in the packet must match 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". |
Both CPNP client and server proceeds to message validation checks as specified in Section 10.
To place a connectivity provisioning quotation order, the client initiates first a local order object identified by a unique identifier assigned by the client. The state of the quotation order is set to "Created". The client then generates a PROVISION request which includes the assigned identifier, possibly an Expected Response Date, a Transaction-ID and a Requested Connectivity Provisioning Document. The client may include additional Information Elements such as Negotiation Options.
The client may be configured to not enforce negotiation checks on EXPECTED_OFFER_DATE; if so no EXPECTED_RESP_TIMER attribute (or EXPECTED_RESP_TIMER set to infinite) should be included in the quotation order.
Once the request is sent to the server, the state of the request is set to "PQOSent" and a timer, if a response time is included in the quotation order, is set to the expiration date as included in the PROVISION request. The client also maintains a copy of the extended transport session details used to generate the PROVISION request. The CPNP client must listen on the same port number that it used to send the PROVISION request.
If no answer is received from the server before the retransmission timer expires (i.e., RETRANS_TIMER), the client proceeds to retransmission until maximum retry is reached (i.e., 3 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 transport session is received, the client updates the CPNP session with the PROVIDER_ORDER_IDENTIFIER information. If the client does not accept the expected offer date 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_DATE, it changes the state of the order to "ServerProcessing" and sets a timer to the value of EXPECTED_OFFER_DATE. If no offer is made before the timer expires, the client changes the state of the order to "Cancelled".
If an OFFER message matching the extended CPNP session 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 ignores silently the message. If a PROCESSING message having 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_DATE indicated in the OFFER message.
If an offer is received from the server (i.e., as documented in an OFFER message), the client may accept or reject the offer. The client accepts the offer by generating an ACCEPT message which confirms that the client agrees to subscribe to the offer documented in the OFFER message; the state of the order is passed to "AcceptSent". The transaction is terminated if an ACK message is received from the server. If no ACK is received from the server, the client proceeds with the re-transmission of the ACCEPT message.
The client may also decide to reject the offer by sending a DECLINE message. The state of the order is set by the client to "Cancelled". If an offer is not acceptable by the client, the client may decide to contact a new server or submit another order to the same server. Guidelines to issue an updated order or terminate the negotiation are specific to the client.
A client may withdraw a completed order. This is achieved by issuing a WITHDRAW message. This message must include Customer Order Identifier, Provider Identifier and Nonce returned during the order negotiation cycle specified in Section 11.1.1.
If no ACK is received from the server, the client proceeds with the re-transmission of the message.
A client may update a completed order. This is achieved by issuing an UPDATE message. This message must include Customer Order Identifier, Provider Order Identifier and Nonce returned during the order negotiation cycle specified in Section 11.1.1. The client must include in the UPDATE message an updated CPD with the requested changes.
Subsequent messages exchange is similar to what is documented in Section 11.1.1.
Upon receipt of a PROVISION message from a client, the server sets a CPNP session, stores Transaction-ID and generates a Provider Order Identifier. Once preliminary validation checks are completed ( Section 10), the server may return a PROCESSING message to notify the client the quotation order is received and it is under processing; the server may include an expected offer date 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 date expires.
If the server cannot honor the request, it sends backs a FAIL message with the appropriate error code.
If the server can honor the request, it creates an OFFER message. The server must indicate the Transaction-ID, Customer Order Identifier as indicated in the PROVISION message, and the Provider Order Identifier generated for this order. The server must also include Nonce and the offered Connectivity Provisioning Document. The server includes an offer validity date as well. Once sent to the client, the server changes the state of the order to "OfferSent" and a timer set to the validity date is initiated.
If the server determines that additional network resources from another network provider are needed to accommodate a quotation order, it will create child PQO(s) and will behave as a CPNP client to negotiate child PQO(s) with possible partnering providers (see Figure 5).
If no PROCESSING, ACCEPT or DECLINE message is received before the expiry of the RETRANS_TIMER, the server re-sends the same offer to the client. This procedure is repeated until maximum retry is reached.
If an ACCEPT message is received before the offered validity date expires, the server proceeds with validation checks as specified in Section 10. The state of the corresponding order is passed to "AcceptReceived". The server sends back an ACK message to terminate the order processing cycle.
If a CANCEL/DECLINE message is received, the server proceeds with the cancellation of the order. The state of the order is then passed to "Cancelled".
A client may withdraw a completed order by issuing a WITHDRAW message. Upon receipt of a WITHDRAW message, the server proceeds with the validation checks, as specified in Section 10.
A client may update an order by issuing an UPDATE message. Upon receipt of an UPDATE message, the server proceeds with the validation checks as specified in Section 10.
The CPNP server SHOULD be configurable to log various events and associated information. Such information includes:
The CPNP server can operate in the following modes:
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.
Means to defend the server against denial-of-service attacks must be enabled. For example, access control lists (ACLs) 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 should be mutually authenticated. Out of band mechanisms can be used instead of integrating them into CPNP.
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 the legitimate CPNP server. Furthermore, CPNP messages from the server must also include correct identifiers of the orders. Two order identifiers are used: one generated by the client and the second one is generated by the server.
Only authorized clients must be able to modify existing CPNP orders. The use of a randomly generated Nonce by the server makes it hard to modify an order on behalf of a third-party.
The use of sequence numbers protects the CPNP server from replay attacks.
The Provider must enforce means to protect privacy-related information captured in a CPP documents exchanged using CPNP messages [RFC6462]. In particular, this information must not be revealed to external parties without the consent of Customers. Providers should enforce policies to make Customer fingerprinting more difficult to achieve. For more discussion about privacy, refer to [RFC6462][RFC6973].
Authors of the document request IANA to assign a UDP port for CPNP.
A registry for CPNP methods should be created. The following codes are reserved:
A registry for CPNP errors should be created. The following codes are reserved:
Thanks to Diego R. Lopez for his comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4086] | Eastlake, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. |
| [RFC5511] | Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. |
| [RFC1123] | Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. |