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

Figure 14: UPDATE Flow Example

A flow chart that illustrates the use of UPDATE operation is shown in Figure 14.

9.2.10. FAIL

The format of the FAIL message is shown below:

<FAIL Message> ::=

<VERSION>

<METHOD_CODE>

<SEQUENCE_NUMBER>

<TRANSACTION_ID>

<CUSTOMER_AGREEMENT_IDENTIFIER>

<PROVIDER_AGREEMENT_IDENTIFIER>

<STATUS_CODE>

• The server can not 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 can not grant more time to a the server. This is a response to a more time request conveyed in a PROCESSING message.

The status code indicates the error code. The following codes are currently supported; other codes will be defined in future versions of the document:

1

(Validation Error): The message can not be validated (see Section 10).

2

(Authentication Required): the request cannot be handled because authentication is required.

3

(Authorization Required): the request cannot be handled because authorization failed.

4

(Administratively prohibited): the request can not be handled because of administrative policies.

5

(Out of Resources): the request can not be honored because there is not enough capacity.

6

(Network Presence): the request can not be honored because there is no network presence.

7

(More Time Rejected): the request to extend the time negotiation is rejected by the client.

10. Message Validation

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

10.1. On the Client Side

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 be larger than 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 be larger than the sequence number maintained by the client.
ACK (QUOTATION 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 be larger than 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 be larger than 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 be larger than the sequence number maintained by the client.

10.2. On the Server Side

Method	Validation Checks
QUOTATION	The source IP address passes existing access filters (if any). The sequence number carried in the packet must not be less than the sequence number maintained by the server.
PROCESSING	The sequence number carried in the packet must be larger than the sequence number maintained by the server.
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 be larger than 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 be larger 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".

11. Theory of Operation

Both CPNP client and server proceeds to message validation checks as specified in Section 10.

11.1. Client Behavior

11.1.1. Order Negotiation Cycle

To place a provisioning quotation order, the client initiates first a local quotation 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 QUOTATION request which includes the assigned identifier, possibly an expected response time, 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_TIME; if so no EXPECTED_RESPONSE_TIME attribute (or EXPECTED_RESPONSE_TIME set to infinite) should be included in the quotation order.

Once the request is sent to the server, the state of the request is set to "PQOSent" and a timer, if a response time is included in the quotation order, is set to the expiration time as included in the QUOTATION request. The client also maintains a copy of the extended transport session details used to generate the QUOTATION request. The CPNP client must listen on the same port number that it used to send the QUOTATION request.

If no answer is received from the server before the retransmission timer expires (i.e., RETRANS_TIMER, Section 8.7), 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_AGREEMENT_IDENTIFIER information. If the client does not accept the expected offer time that may have been indicated in the PROCESSING message, the client may decide to cancel the quotation order. If the client accepts the EXPECTED_OFFER_TIME, it changes the state of the order to "ServerProcessing" and sets a timer to the value of EXPECTED_OFFER_TIME. If no offer is made before the timer expires, the client changes the state of the order to "Cancelled".

As a response to a more time request (conveyed in a PROCESSING message that included a new EXPECTED_OFFER_TIME), the client may grant this extension by issuing an ACK message or reject the time extension with a FAIL message having a status code set to "More Time Rejected".

If an OFFER message matching the extended CPNP session is received, the client checks if a PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If a PROCESSING message was already received for the same order but the PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included in the OFFER message, the client ignores silently the message. If a PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was already received and matches the CPNP transaction identifier, the client changes the state of the order to "OfferReceived" and sets a timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER message.

If an offer is received from the server (i.e., as documented in an OFFER message), the client may accept or reject the offer. The client accepts the offer by generating an ACCEPT message which confirms that the client agrees to subscribe to the offer documented in the OFFER message; the state of the order is passed to "AcceptSent". The transaction is terminated if an ACK message is received from the server. If no ACK is received from the server, the client proceeds with the 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.

11.1.2. Order Withdrawal Cycle

A client may withdraw a completed order. This is achieved by issuing a WITHDRAW message. This message must include Customer Order Identifier, Provider Identifier and Nonce returned during the order negotiation cycle specified in Section 11.1.1.

If no ACK is received from the server, the client proceeds with the re-transmission of the message.

11.1.3. Order Update Cycle

A client may update a completed order. This is achieved by issuing an UPDATE message. This message must include Customer Order Identifier, Provider Order Identifier and Nonce returned during the order negotiation cycle specified in Section 11.1.1. The client must include in the UPDATE message an updated CPD with the requested changes.

Subsequent messages exchange is similar to what is documented in Section 11.1.1.

11.2. Server Behavior

11.2.1. Order Processing

Upon receipt of a QUOTATION message from a client, the server sets a CPNP session, stores Transaction-ID and generates a Provider Order Identifier. Once preliminary validation checks are completed ( Section 10), the server may return a PROCESSING message to notify the client 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 with a FAIL message having a status code set to "More Time Rejected". If the client doesn't grant more time, the server must answer before the initial expected offer time; otherwise the client will ignore the quotation order.

If the server can honor the request or it can make an offer that meet some of the requirements, it creates an OFFER message. The server must indicate the Transaction-ID, Customer Order Identifier as indicated in the QUOTATION message, and the Provider Order Identifier generated for this order. The server must also include Nonce and the offered Connectivity Provisioning Document. The server includes an offer validity time as well. Once sent to the client, the server changes the state of the order to "OfferSent" and a timer set to the validity time is initiated.

If the server determines that additional network resources from another network provider are needed to accommodate a quotation order, it will create child PQO(s) and will behave as a CPNP client to negotiate child PQO(s) with possible partnering providers (see Figure 6).

If no PROCESSING, ACCEPT or DECLINE message is received before the expiry of the RETRANS_TIMER, the server re-sends the same offer to the client. This procedure is repeated until maximum retry is reached.

If an ACCEPT message is received before the offered validity time expires, the server proceeds with validation checks as specified in Section 10. The state of the corresponding order is passed to "AcceptReceived". The server sends back an ACK message to terminate the order processing cycle.

If a CANCEL/DECLINE message is received, the server proceeds with the cancellation of the order. The state of the order is then passed to "Cancelled".

11.2.2. Order Withdrawal

A client may withdraw a completed order by issuing a WITHDRAW message. Upon receipt of a WITHDRAW message, the server proceeds with the validation checks, as specified in Section 10.

• If the checks fail, a FAIL message is sent back to the client with the appropriate error code.
• If the checks succeed, the server clears the clauses of the Connectivity Provisioning Document, changes the state of the order to "Cancelled", and sends back an ACK message with an Empty Connectivity Provisioning Document.

11.2.3. Order Update

A client may update an order by issuing an UPDATE message. Upon receipt of an UPDATE message, the server proceeds with the validation checks as specified in Section 10.

• If the checks fail, a FAIL message is sent back to the client with the appropriate error code.
• Subsequent messages exchange is similar to what is specified in Section 11.1.1. The server should generate a new Nonce value to be included in the offer made to the client.

11.3. Sequence Numbers

In each transaction, sequence numbers are used to protect the transaction against replay attacks. Each communicating partner of the transaction maintains two sequence numbers, one for incoming packets and one for outgoing packets. When a partner receives a message, it will check whether the sequence number in the message is larger than the incoming sequence number maintained locally. If not, the messages will be discarded. If the message is proved to be legal, the value of the incoming sequence number 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 outgoing sequence number into the message and increase the outgoing sequence number maintained locally by 1.

11.4. Message Re-Transmission

If a transaction partner sends out a message and does not receive any expected reply before the retransmission timer expires (i.e., RETRANS_TIMER), a transaction partner will try to re-transit the messages. 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 re-sent last incoming packet, the partner can also send out the answer to the incoming packet with a limited frequency. If no answer was generated at the moment, the partner needs to generate a PROCESSING message as the answer.

To benefit message re-transmission, a partner could also store the last incoming packet and the associated answer. Note that the times of re-transmission could be decided by the local policy and re-transmission will not cause any change of sequence numbers.

12. Operational Guidelines

12.1. Logging on the CPNP Server

The CPNP server SHOULD be configurable to log various events and associated information. Such information includes:

• Client's IP address
• Any event change (e.g., new quotation order, offer sent, order confirm, order cancellation, order withdraw, etc.)
• Timestamp

12.2. Business Guidelines & Objectives

The CPNP server can operate in the following modes:

1. Fully automated mode: The CPNP server is provisioned with a set of business guidelines and objectives that will be used as an input to the decision-making process. The CPNP server will service received orders that falls into these business guidelines; otherwise requests will be escalated to an administrator that will formally validate/invalidate an order request. The set of policies to be configured to the CPNP server are specific to each administrative entity managing a CPNP server.
2. Administrative-based mode: This mode assumes some or all CPNP server' operations are subject to a formal administrative validation. CPNP events will trigger appropriate validation requests that will be forwarded to the contact person(s) or department which is responsible for validating the orders. Administrative validation messages are relayed using another protocol (e.g., SMTP) or a dedicated tool.

Business guidelines are local to each administrative entity. How validation requests are presented to an administrator are out of scope of this document; each administrative entity may decide the appropriate mechanism to enable for that purpose.

13. Security Considerations

Means to defend the server against denial-of-service attacks must be enabled. For example, access control lists (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 to a legitimate CPNP server. Furthermore, CPNP demands that messages from the server must include correct identifiers of the orders. Two order identifiers are used: one generated by the client and a second one generated by the server.

The Provider must enforce means to protect privacy-related information included the documents (see Section 8.9) 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 difficult to achieve. For more discussion about privacy, refer to [RFC6462][RFC6973].

The NONCE and the Transaction ID attributes provide sufficient randomness and can effectively tolerate attacks raised by off-line adversaries, who do not have the capability of eavesdropping and intercepting the packets transported between the client and the server. Only authorized clients must be able to modify agreed CPNP orders. The use of a randomly generated NONCE by the server makes it hard to modify an agreement on behalf of a malicious third-party.

The sequence numbers included in the CPNP messages can be used to detect replay attacks and antique packets intercepted from on-going transactions may be re-sent. However, the protocol in its current version may be vulnerable to replay attacks where the replayed messages are intercepted from antique transactions. Although the Transaction ID provided by the client could protect inter-transaction replay attacks, no protection is provided for the server to deal with this type of attack.

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., DTLS [RFC6347], IPsec) could be used to protect the integrity and confidentiality for the protocol. In this case, if it is possible to provide an Automated Key Management (AKM) and associate each transaction with a different key, inter- transaction replay attacks can naturally be addressed. If the client and the server use a single key, an additional mechanism should be provided to protect inter-transaction replay attacks between them.

The deployment option of a Customer Order Management portal operated by a trusted third-party (see Section 6) may facilitate the efficient resolution of the aforementioned security concerns.

14. IANA Considerations

Authors of the document request IANA to assign a UDP port for CPNP.

A registry for CPNP methods should be created. The following initial codes should be reserved:

1:

QUOTATION

2:

PROCESSING

3:

OFFER

4:

ACCEPT

5:

DECLINE

6:

ACK

7:

CANCEL

8:

WITHDRAW

9:

UPDATE

10:

FAIL

A registry for CPNP error codes should be created. The following initial error codes should be reserved:

1:

Message Validation Error

2:

Authentication Required

3:

Authorization Failed

4:

Administratively prohibited

5:

Out of Resources

6:

Network Presence Error

7:

More Time Rejected

15. Acknowledgements

Thanks to Diego R. Lopez for his comments.

16. References

16.1. Normative References

[RFC1123]	Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4086]	Eastlake 3rd, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005.
[RFC5511]	Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009.

16.2. Informative References

[ETICS]	, , "Economics and Technologies of Inter-Carrier Services", January 2014.
[I-D.boucadair-lisp-idr-ms-discovery]	Boucadair, M. and C. Jacquenet, "LISP Mapping Service Discovery at Large", Internet-Draft draft-boucadair-lisp-idr-ms-discovery-01, March 2016.
[RFC2782]	Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000.
[RFC4026]	Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005.
[RFC4176]	El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K. and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005.
[RFC6347]	Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012.
[RFC6462]	Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, DOI 10.17487/RFC6462, January 2012.
[RFC6574]	Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012.
[RFC6770]	Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K. and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012.
[RFC6793]	Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012.
[RFC6830]	Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013.
[RFC6973]	Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013.
[RFC7149]	Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014.
[RFC7297]	Boucadair, M., Jacquenet, C. and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014.

Authors' Addresses