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

9.2.10. FAIL

The format of 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 can not honor an order received from the client (i.e., received in a PROVISION or UPDATE request).
• The server encounters an error when processing a CPNP request received from the client.

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.

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

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

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

As mentioned above, if a transaction partner sends out a message and does not receives 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 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.

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

The nonce and the transaction IDs provide sufficient randomness and can effectively tolerate the 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 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.

In the base CPNP protocol, sequence numbers can be used to detect the replay attacks by re-sending the antique packets intercepted from the current transaction. However, the based protocol may be vulnerable to the replay attacks where the replayed packets are intercepted from antique transactions. Although the transaction ID provided by the client could protect it from inter-transaction replay attacks, no protection is provided for the server to deal with this type of attack.

The based protocol does not provide any security mechanism 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 or confidentiality for the protocol. In this case, if it is possible to provide an AKM and associate each transaction a different key, inter-transaction replay attacks can be naturally addressed. If the client and the server use a single key to secure multiple transactions, the additional mechanism should be provided against inter-transaction replay attacks. However, how to address this issue is out of scope of this document.

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 codes are reserved:

1:

PROVISION

2:

PROCESSING

3:

OFFER

4:

ACCEPT

5:

DECLINE

6:

ACK

7:

CANCEL

8:

WITHDRAW

9:

UPDATE

10:

FAIL

A registry for CPNP errors should be created. The following codes are reserved:

1:

Message Validation Error

2:

Authentication Required

3:

Authorization Failed

4:

Administratively prohibited

5:

Out of Resources

6:

Network Presence Error

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, October 1989.
[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.

16.2. Informative References

[I-D.boucadair-connectivity-provisioning-profile]	Boucadair, M., Jacquenet, C. and N. Wang, "IP Connectivity Provisioning Profile (CPP)", Internet-Draft draft-boucadair-connectivity-provisioning-profile-05, April 2014.
[RFC2782]	Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[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, October 2005.
[RFC6347]	Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6462]	Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
[RFC6770]	Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K. and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012.
[RFC6973]	Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.
[RFC7149]	Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014.

Authors' Addresses