One document matched: draft-boucadair-connectivity-provisioning-protocol-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp"
docName="draft-boucadair-connectivity-provisioning-protocol-04"
ipr="trust200902" updates="">
<front>
<title abbrev="CPNP">Connectivity Provisioning Negotiation Protocol
(CPNP)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>zhangdacheng@huawei.com</email>
<uri></uri>
</address>
</author>
<date day="27" month="June" year="2014" />
<keyword>SDN, Order Request Handling, Automation, Dynamic
Provisioning</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="RFC7149"></xref>.</t>
<t>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).</t>
<t><xref
target="I-D.boucadair-connectivity-provisioning-profile"></xref>
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.</t>
<t>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.). <!--I would quote references accordingly.-->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.</t>
<t>This document is organized as follows:<?rfc subcompact="yes" ?><list
style="symbols">
<t><xref target="fe"></xref> defines functional elements involved in
CPNP exchanges.</t>
<t><xref target="opm"></xref> introduces several order processing
models and precises those that are targeted by CPNP.</t>
<t><xref target="suc"></xref> enumerates a non-exhaustive list of
use cases that would benefit from CPNP.</t>
<t><xref target="suc"></xref> discusses some CPNP deployment
models.</t>
<t><xref target="cnm"></xref> presents CPNP negotiation model.</t>
<t><xref target="po"></xref> provides an overview of the
protocol.</t>
<t><xref target="co"></xref> specifies CPNP objects.</t>
<t><xref target="validation"></xref> describes CPNP message
validation procedure.</t>
<t><xref target="behavior"></xref> specifies the behavior of
involved CPNP functional elements.</t>
<t><xref target="og"></xref> discusses some operational
guidelines.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<list style="symbols">
<t>Customer: is a business role which denotes an entity that is
involved in the definition and the possible negotiation of a
contract, including Connectivity Provisioning Agreement, with a
Provider. A connectivity provisioning contract is captured in a
dedicated CPP template, which specifies (among other information):
the sites to be connected, border nodes, outsourced operations
(e.g., routing, force via points). The right to invoke the
subscribed service may be delegated by the Customer to third-party
End Users, or brokering services.</t>
<t>Network Provider (or Provider): owns and administers one or many
transport domain(s) (typically Autonomous System (AS)) composed of
IP switching and transmission resources (e.g., routing, switching,
forwarding, etc.). Network Providers are responsible for ensuring
connectivity services (e.g., offering global or restricted
reachability). Connectivity services offered to Customers are
captured in contracts from which are derived the technology-specific
clauses and policies to be enforced by the components involved in
the connectivity service delivery. Offered connectivity services are
not restricted to IP.</t>
</list></t>
</section>
<section anchor="fe" title="CPNP Functional Elements">
<t>The following functional elements are defined:<list style="symbols">
<t>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:<list
style="numbers">
<t>Create a quotation order (<xref
target="creation"></xref>).</t>
<t>Cancel an ongoing quotation order under negotiation (<xref
target="creation"></xref>).</t>
<t>Withdraw a pre-negotiated order (<xref
target="corw"></xref>).</t>
<t>Update a pre-negotiated order (<xref
target="cordu"></xref>).</t>
</list></t>
<t>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:<list
style="numbers">
<t>Quotation order handling (<xref
target="handling"></xref>).</t>
<t>Cancel an ongoing quotation order (<xref
target="sordw"></xref>).</t>
<t>Handling of an order withdrawal (<xref
target="sordu"></xref>).</t>
</list></t>
</list></t>
</section>
<section anchor="opm" title="Order Processing Models">
<t>There are basically three models for customer's order processing
purposes:<list style="numbers">
<t>Frozen model: The Customer cannot negotiate the parameters of the
service delivered by a Provider. After consulting a service
portfolio, the Customer selects the offer he/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 as per
Customer's requirements, but rather pre-designed to target a group
of customers having similar requirements (and who therefore share
the same Customer Provisioning Profile).</t>
<t>Announcement model: The Provider proceeds to the announcement of
a set of services templates. The Customer can then initiate a
negotiation cycle using these templates to prepare its request
order.</t>
<t>Negotiation-based model: Unlike the frozen model, the Customer
documents his/her requirements in some kind of request for quotation
which is then sent to one or several Providers. Solicited Providers
then 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 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 then follows, and an order is
placed by the Customer eventually, upon completion of the
negotiation phase.</t>
</list></t>
<t>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.</t>
<t>Order processing management on the Network Provider's side is usually
connected with the following functional blocks:<list style="symbols">
<t>Network Provisioning (including Order Activation, Network
Planning, etc.)</t>
<t>AAA</t>
<t>Sales-related functional blocks (e.g., billing, Customers credit
checks validation, etc.)</t>
<t>Network Impact Analysis</t>
</list></t>
<t>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.</t>
<t>This document does not elaborate on how Customers are identified and
managed by the Provider's Information System.</t>
</section>
<section anchor="suc" title="Sample Use Cases ">
<t>A list of CPNP use cases is provided below:<list style="numbers">
<t><xref target="RFC4176"></xref> introduces the 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 <xref
target="RFC4176"></xref>.</t>
<t>CPNP can be used between two adjacent domains to deliver IP
interconnect services (e.g., enable, update, disconnect). For
example, two 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.</t>
<t>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
invoke CPNP negotiation cycles is exposed to service management
teams.</t>
<t>Service Providers can initiate connectivity provisioning requests
towards Network Providers using CPNP. Multiple CPNP ordering cycles
can be initiated by a Service Provider towards multiple Network
Providers. Only a subset of these orders may be put into effect.</t>
<t>CPNP can be used in M2M environments to dynamically subscribe to
M2M services (e.g., access to data retrieved by a set of sensors,
extend sensor coverage, etc.).</t>
<t>A Provider offering cloud services can expose a CPNP interface to
allow Customers to dynamically negotiate the features they want to
subscribe to. These features can be for instance: request additional
storage resources, enable security filters, etc.</t>
<t>CDN Providers can use CPNP to extend their footprint by
interconnecting their CDN infrastructure <xref
target="RFC6770"></xref> (see <xref target="cdni"></xref>).</t>
</list><figure align="center" anchor="cdni"
title="CDN Interconnection">
<artwork><![CDATA[ ,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--']]></artwork>
</figure></t>
</section>
<section anchor="dm" title="Deployment Models">
<t>Several CPNP deployment models can be envisaged. Two examples are
listed below:<list style="symbols">
<t>The Customer deploys a CPNP client while one or several CPNP
servers are deployed by the Provider.</t>
<t>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).</t>
</list></t>
<t>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.</t>
<t>This document does not make any assumption about the CPNP deployment
model either.</t>
</section>
<section anchor="cnm" title="CPNP Negotiation Model">
<t>CPNP adopts a Quotation Order/Offer/Answer model where:<list
style="numbers">
<t>The client specifies its requirements via a Provision Quotation
Order (PQO).</t>
<t>The server makes an offer to either address the requirements of
the PQO or suggests a counter-proposal that partially addresses the
requirements of the PQO or declines the PQO.</t>
<t>The client either accepts or declines the offer.</t>
</list></t>
<t>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.</t>
<t>Only one Offer/Answer stage is assumed within one single CPNP
negotiation cycle. Nevertheless, multiple CPNP negotiation cycles can be
undertaken by the CPNP client (see <xref target="examples"></xref>).</t>
<t>The model is flexible as it accommodates changes such as conditions
that may evolve over time (e.g., introduction of an additional VPN
site).</t>
<t><figure align="center" anchor="examples"
title="Overall Negotiation Process">
<artwork><![CDATA[+------+ +------+ +------+ +------+
|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
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="po" title="Protocol Overview">
<t></t>
<section title="Client/Server Communication">
<t>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.</t>
<t>The server uses CPNP_PORT (see <xref target="IANA"></xref>) 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.</t>
<t>CPNP is independent of the IP address family.</t>
</section>
<section title="Server Discovery">
<t>The CPNP client can be configured with the CPNP server using manual
or dynamic configuration means. For example, Providers may configure
dedicated SRV records (<xref target="RFC2782"></xref>).</t>
<t>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.</t>
</section>
<section title="Policy Configuration on the CPNP Server">
<t>As an input to the CPNP server's decision-making process<!--I would elaborate on what such a decision-making process is, e.g., provide an offer that (1) Fully (2) Partly accommodates customer's requirements or (3) Declines because resources are not available for example. The service is structured according to the input provided by other components, such as dynamic resource management block, custoemr database, etc.-->,
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 <xref target="fb"></xref>).</t>
<t><figure align="center" anchor="fb"
title="Order Handling Management Functional Block">
<artwork><![CDATA[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.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 |
+-------------------------------------------------------+
]]></artwork>
</figure></t>
<t>These external modules provide inputs to the CPNP server, so that
it can:<list style="symbols">
<t>Check whether a customer is entitled to initiate the
connectivity provisioning quotation request.</t>
<t>Check whether a customer is entitled to cancel the order</t>
<t>Check whether administrative data (e.g., billing-related
information) have been verified before starting handling the
request</t>
<t>Check whether network capacity is available or additional
capacity is required</t>
<t>Receive guidelines from network design and sales blocks (e.g.,
cost, increase network usage, threshold of how many CPP templates
can be processed over a given period of time as a function of the
nature of the service to be delivered, etc.)</t>
<t>Transfer completed orders to network provisioning blocks</t>
<t>Etc.</t>
</list></t>
<t>The above list of CPNP server operations is not exhaustive.</t>
<t>The following order handling modes can be also configured on the
server:<list style="numbers">
<t>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 generate corresponding offers.</t>
<t>Administrative validation checking: Some or all server's
operations are subject to administrative validation procedures.
This mode requires an action from the administrator for every
request received by the CPNP server. CPNP methods which can be
automatically handled or subject to one or several validation
administrative checks can be configured on the server.</t>
</list></t>
</section>
<section title="CPNP Session">
<t>Both the client and server maintain the following CPNP transport
session information:</t>
<t>A CPNP session is identified by the following items:<list
style="symbols">
<t>IP address of the client</t>
<t>Client's port number</t>
<t>IP address of the server</t>
<t>Server's port number</t>
</list></t>
</section>
<section title="Extended CPNP Session">
<t>An extended PQO session denotes a 4-uplet defined as follows:<list
style="symbols">
<t>CPNP session</t>
<t>Incremented Sequence Number</t>
<t>Customer Order Identifier</t>
<t>Provider Order Identifier</t>
<t>Transaction-ID</t>
</list></t>
</section>
<section anchor="trans" title="CPNP Transaction">
<t>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. </t>
<t>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.</t>
<t>The Transaction-ID must be randomly assigned be the CPNP client,
according to the best current practice for generating random numbers
<xref target="RFC4086"></xref> that cannot be guessed easily.
Transaction-ID is used as part of the validation of CPNP responses
received by the client.</t>
<t>The client needs to randomly select a sequence number and set it in
the first CPNP message and in the outgoing sequence number maintained
locally. This number is then incremented fro each request within the
same CPNP transaction.</t>
</section>
<section title="CPNP Operations">
<t>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.<list style="symbols">
<t>PROVISION: This operation is used to initiate a connectivity
provisioning quotation order. Upon receipt of a PROVISION request,
the server may response with a PROCESSING, OFFER or a FAIL
message. A PROVISION-initiated transaction can be terminated by an
OFFER or FAIL message.</t>
<t>PROCESSING: This operation is used to inform the remote party
the message was received and that the order quotation or the offer
is being processed.</t>
<t>OFFER: This operation is used by the server to inform the
client about an Offer that is supposed to best accommodate the
requirements indicated in the PROVISION message.</t>
<t>ACCEPT: This operation is used to confirm the acceptance of an
offer made by the server.</t>
<t>ACK: This operation is used by the server to acknowledge the
receipt of an ACCEPT or WITHDRAW message.</t>
<t>DECLINE: This operation is used by a client to reject an offer
made by the server.</t>
<t>CANCEL: This operation is used by the client to cancel an
ongoing connectivity provisioning quotation order.</t>
<t>WITHDRAW: This operation is used by the client to withdraw a
pre-negotiated connectivity provisioning order.</t>
<t>UPDATE: This operation is used by the client to update an
existing connectivity provisioning order. For example, this method
can be invoked to add a new site. This method will trigger a new
negotiation cycle.</t>
<t>FAIL: This operation is used by the server when it cannot
accommodate the requirements documented in the PQO conveyed in the
PROVISION message. This operation can also be used by a server to
inform the client about an error encountered when processing the
received message.<!--I would then distinguish between a FAIL and an ERROR, for the sake of processing optimization.-->
The message includes the status code which provides more
information about the error.</t>
</list></t>
<t>CPNP primitives are service-independent. This document specifies
objects that are required for connectivity provisioning negotiation
(see <xref target="cpd"></xref>). Additional service-specific objects
to be carried in CPNP messages can be defined in the future to
accommodate other deployment needs.</t>
</section>
<section anchor="cpd" title="Connectivity Provisioning Documents">
<t>CPNP makes use of several flavors of Connectivity Provisioning
Documents (CPD). These documents follow the CPP template described in
<xref
target="I-D.boucadair-connectivity-provisioning-profile"></xref>.<list
style="symbols">
<t>Requested Connectivity Provisioning Document: refers to the CPD
included by a CPNP client in a PROVISION request.</t>
<t>Offered Connectivity Provisioning Document: This document is
included by a CPNP server in an OFFER message. This information
reflects the proposal of the server to accommodate all or a subset
of the clauses depicted in a CPD. A validity date is associated
with the offer.</t>
<t>Agreed Connectivity Provisioning Document: If the client
accepts the offer, the offered CPD is included in an ACCEPT
message. This CPD is also included in an ACK message.</t>
</list></t>
<t><xref target="example"></xref> shows a typical CPNP negotiation
cycle and the use of Connectivity Provisioning Documents. There are
two CPNP transactions (<xref target="trans"></xref>) in this
negotiation cycle: the one from PROVISION to its final response which
is OFFER, and the second one starting with an ACCEPT message while its
final response ACK. </t>
<t><figure align="center" anchor="example"
title="Connectivity Provisioning Documents">
<artwork><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|======PROVISION (Requested CPD)=====>|
|<============PROCESSING==============|
|<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>|
|=========ACCEPT (Agreed CPD)========>|
|<=========ACK (Agreed CPD)===========|
]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Child Connectivity Provisioning Quotation Orders">
<t>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 <xref target="child"></xref>). 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.<!--I think we should refer to some of the IPSF stuff for that matter, especially by introducing this notion of Adminsitrative Owner, which is the provider solicited by the client and which will act on behalf of partnering providers. Note that this sibling relationship may be worth a separate document, because of the security and negotiation implications that may go beyond the scope of this draft.--></t>
<t><figure align="center" anchor="child"
title="Example of Child Orders">
<artwork><![CDATA[+------+ +--------+ +--------+
|Client| |Server A| |Server B|
+------+ +--------+ +--------+
| | |
|=====PROVISION=====>| |
|<====PROCESSING=====| |
| |=====PROVISION=====>|
| |<====PROCESSING=====|
| |<=======OFFER=======|
| |=====PROCESSING====>|
| |=======ACCEPT======>|
| |<=======ACK=========|
|<=======OFFER=======| |
|=====PROCESSING====>| |
|=======ACCEPT======>| |
|<=======ACK=========| |
]]></artwork>
</figure></t>
</section>
<section title="State Management">
<t>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.<!--Not sure I understand the purpose of the sentence. This is a matter of implementation anyway. I would delete it.-->Timestamps
are also logged to track state change. Tracking may be needed for
various reasons (including regulatory ones).</t>
<section title="On the Client Side">
<t>The following lists the states which can be associated with a
given order on the client's side:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>Created: when the order has been created. It is not handled
by the client until the administrator allows to process it.</t>
<t>AwaitingProcessing: when the administrator ordered to process
an order and this order is not handled yet.</t>
<t>PQOSent: when the PQO has been sent to the server.</t>
<t>ServerProcessing: when the server has confirmed the receipt
of the order.</t>
<t>OfferReceived: when an offer has been received from the
server.</t>
<t>OfferProcessing: when a received offer is currently processed
by the client.</t>
<t>AcceptSent: when the client confirmed the offer to the
server.</t>
<t>AcceptAck: when the offer is acknowledged by the server.</t>
<t>Cancelled: when the order has failed or has been
cancelled.<?rfc subcompact="no" ?></t>
</list></t>
<t><figure align="center" anchor="clientstate"
title="CPNP Finite State Machine (Client Side)">
<artwork><![CDATA[+------------------+
| 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------+
+------------------+
]]></artwork>
</figure></t>
</section>
<section title="On the Server Side">
<t>The following lists the states which can be associated with a
given order on the server's side:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>PQOReceived: when the connectivity provisioning quotation
order request has been received from the client.</t>
<t>AwaitingProcessing: when the order request is being processed
by the server. An action from the server administrator may be
needed.</t>
<t>OfferProposed: when the request has been successfully handled
and an offer has been sent to the requesting client.</t>
<t>ProcessingReceived: when the server received a PROCESSING for
an offer sent to the client.</t>
<t>AcceptReceived: when the server received a confirm for the
offer from the client.</t>
<t>AcceptAck: when the server acknowledged the offer to the
client.</t>
<t>Cancelled: when the order request has failed or has been
cancelled. Associate resources must be released in the latter
case.</t>
<t>ChildCreated: when a child PQO has been created because
resources from another network provider are needed.</t>
<t>ChildPQOSent: when a child PQO has been sent to another
server.</t>
<t>ChildServerProcessing: when a child PQO is currently
processed by another server.</t>
<t>ChildOfferReceived: when an offer has been received to a
child PQO.</t>
<t>ChildOfferProcessing: when a received offer is currently
processed.</t>
<t>ChildAcceptSent: when the child offer is confirmed to another
server.</t>
<t>ChildAcceptAck: when the child offer is acknowledged by
another server.<?rfc subcompact="no" ?><!--See previous comment. I would probably separate states that relate to a single client/server peering relationship from states that assume clustering and sibling relationships.--></t>
</list></t>
<t></t>
<t><figure align="center" anchor="serverstate"
title="CPNP Finite State Machine (Server Side)">
<artwork><![CDATA[ +------------------+
+---------------------| 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-----+ |
+------------------+ |
| |
+--------------------------------------+
]]></artwork>
</figure></t>
<t></t>
</section>
</section>
<section title="CPNP Timers">
<t>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 <xref target="behavior"></xref>.</t>
<t>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.</t>
<t>An offer expiration timer (EXPIRE_TIMER) represents the maximum
time, defined in minutes, after which an offer made by the server will
be invalid.</t>
</section>
</section>
<section anchor="co" title="CPNP Objects">
<t>This section defines CPNP objects using the RBNF format defined at
<xref target="RFC5511"></xref>.</t>
<t>This document focuses on connectivity provisioning objects;
additional Information Elements can be defined in the future.</t>
<t><?rfc subcompact="yes" ?></t>
<section title="Attributes">
<t></t>
<section title="CUSTOMER_ORDER_IDENTIFIER">
<t>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.</t>
<t>The server handles CUSTOMER_ORDER_IDENTIFIER as an opaque
value.</t>
</section>
<section title="PROVIDER_ORDER_IDENTIFIER">
<t>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.</t>
<t>The client handles PROVIDER_ORDER_IDENTIFIER as an opaque
value.</t>
</section>
<section title="TRANSACTION_ID">
<t>This object conveys the Transaction-ID introduced in <xref
target="trans"></xref>.</t>
</section>
<section title="SEQUENCE_NUMBER">
<t>Sequence Number is a number that is monotonically incremented on
every new CPNP message within a CPNP transaction. This number is
used to avoid reply attacks.</t>
</section>
<section title="NONCE">
<t>NONCE is a random value assigned by the CPNP server. It is
RECOMMENDED to assign unique NONCE values for each order.</t>
<t>NONCE is then mandatory to be included in subsequent CPNP client
operations on the associated order such as: withdraw the order or
update the order.</t>
<t>If the NONCE validation checks fail, the server rejects the
request with a FAIL message including the appropriate failure reason
code.</t>
</section>
<section title="EXPECTED_RESPONSE_DATE">
<t>This attribute indicates the date by when the client is expecting
to receive a response, for a PQO, from the server. If no offer is
received by then, the client will consider the quotation order as
rejected.</t>
<t>EXPECTED_RESPONSE_DATE follows date format specified in <xref
target="RFC1123"></xref>.</t>
</section>
<section title="EXPECTED_OFFER_DATE">
<t>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.</t>
<t>EXPECTED_OFFER_DATE follows date format specified in <xref
target="RFC1123"></xref>.</t>
</section>
<section title="VALIDITY_DATE">
<t>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.</t>
<t>VALIDITY_DATE follows date format specified in <xref
target="RFC1123"></xref>.</t>
</section>
<section title="CONNECTIVITY_PROVISIONING_DOCUMENT">
<t>The RBNF format of the Connectivity Provisioning Document is
shown below:</t>
<t><figure>
<artwork><![CDATA[<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>]]></artwork>
</figure></t>
</section>
<section title="Information Elements">
<t>An Information Element is an optional object which can be
included in a CPNP message.</t>
<section title="Customer Description">
<t>The client may include administrative information such as:<list
style="symbols">
<t>Name</t>
<t>Contact Information</t>
</list>The format of this Information Element is as follows:</t>
<t><figure>
<artwork><![CDATA[<Customer Description> ::= <NAME> <Contact Information>
<Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
]]></artwork>
</figure></t>
</section>
<section title="Provider Description">
<t>The server may include administrative information in an offer
such as:<list style="symbols">
<t>Name</t>
<t>AS Number</t>
<t>Contact Information</t>
</list>The format of this Information Element is as follows:</t>
<t><figure>
<artwork><![CDATA[<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
]]></artwork>
</figure></t>
</section>
<section title="Negotiation Options">
<t>The client may include some negotiation options such as:<list
style="symbols">
<t>Cost: the client may include an empty or a preferred COST
attribute to request the cost from the server. The server will
provide the cost information in the response.</t>
<t>Setup purpose: A client may request to setup a 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 UPDATE method.</t>
</list>Other negotiation options may be defined in the
future.</t>
<t>The format of this Information Element is as follows:</t>
<t><figure>
<artwork><![CDATA[<Negotiation Options> ::= [<COST>][<PURPOSE>]
]]></artwork>
</figure></t>
</section>
</section>
</section>
<section title="Operation Messages">
<t>This section specifies the RBNF format of CPNP operation
messages.</t>
<section anchor="provision" title="PROVISION">
<t>The format of PROVISION message is shown below:</t>
<t><list hangIndent="24" style="hanging">
<t hangText="<PROVISION Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t>[<EXPECTED_RESPONSE_DATE>]</t>
<t><CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t>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. </t>
<t>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.</t>
<t>When the client sends the PROVISION message to the server, the
state of the order changes to "PQOSent".</t>
</section>
<section anchor="proc" title="PROCESSING">
<t>The format of PROCESSING Message is shown below:</t>
<t><list hangIndent="25" style="hanging">
<t hangText="<PROCESSING Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t>[<EXPECTED_OFFER_DATE>]</t>
</list></t>
<t>Upon receipt of a PROVISION message, the server proceeds with
parsing rules (see <xref target="validation"></xref>). 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.</t>
<t>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".</t>
</section>
<section anchor="offer" title="OFFER">
<t>The format of OFFER message is shown below:</t>
<t><list hangIndent="20" style="hanging">
<t hangText="<OFFER Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t><NONCE></t>
<t><VALIDITY_DATE></t>
<t><CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t>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.</t>
</section>
<section anchor="accept" title="ACCEPT">
<t>The format of ACCEPT message is shown below:</t>
<t><list hangIndent="22" style="hanging">
<t hangText="<ACCEPT Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t><NONCE></t>
<t><CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t>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.</t>
</section>
<section anchor="ack" title="ACK">
<t>The format of ACK message is shown below:</t>
<t><list hangIndent="17" style="hanging">
<t hangText="<ACK Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t><CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t>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:<list style="symbols">
<t>A copy of the requested/offered CPD is included by the server
if it successfully handled a CANCEL message.</t>
<t>A copy of the updated CPD is included by the server if it
successfully handled an UPDATE message.</t>
<t>A copy of the offered CPD is included by the server if it
successfully handled an ACCEPT message in the context of a
PROVISION transaction.</t>
<t>An empty CPD is included by the server if it successfully
handled a DECLINE message.</t>
</list></t>
<t></t>
</section>
<section anchor="dec" title="DECLINE">
<t>The format of DECLINE message is shown below:</t>
<t><list hangIndent="21" style="hanging">
<t hangText="<DECLINE Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
</list>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.</t>
<t>If no order is found, the server returns a FAIL message to the
requesting client.</t>
<t>A flow example is shown in <xref target="decline"></xref>.</t>
<t><figure align="center" anchor="decline"
title="DECLINE Flow Example">
<artwork><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|======PROVISION (Requested CPD)=====>|
|<============PROCESSING==============|
|<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>|
|===============DECLINE==============>|
|<================ACK=================|
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="cancel" title="CANCEL">
<t>The format of CANCEL message is shown below:</t>
<t><list hangIndent="21" style="hanging">
<t hangText="<CANCEL Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t>[<CONNECTIVITY_PROVISIONING_DOCUMENT>]</t>
</list>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.</t>
<t>If no order is found, the server returns a FAIL message to the
requesting client.</t>
</section>
<section anchor="with" title="WITHDRAW">
<t>The format of WITHDRAW message is shown below:</t>
<t><list hangIndent="23" style="hanging">
<t hangText="<WITHDRAW Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t><NONCE></t>
<t>[<CONNECTIVITY_PROVISIONING_DOCUMENT>]</t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t>This message is used to withdraw an offer already subscribed by
the Customer. <xref target="withdraw"></xref> shows a typical usage
of this message.</t>
<t><figure align="center" anchor="withdraw"
title="WITHDRAW Flow Example">
<artwork><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|===========WITHDRAW (CPD)===========>|
|<============PROCESSING==============|
|<==========ACK (Empty CPD)===========|
]]></artwork>
</figure></t>
<t>The CPNP must include the same CUSTOMER_ORDER_IDENTIFIER,
PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating the
order.</t>
<t>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.</t>
</section>
<section anchor="upd" title="UPDATE">
<t>The format of UPDATE message is shown below:</t>
<t><list hangIndent="21" style="hanging">
<t hangText="<UPDATE Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t><NONCE></t>
<t><EXPECTED_RESPONSE_DATE></t>
<t><CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t>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.</t>
<t>Upon receipt of an UPDATE message, the server checks whether an
order, having state "Completed", matches CUSTOMER_ORDER_IDENTIFIER,
PROVIDER_ORDER_IDENTIFIER, and NONCE. <list style="symbols">
<t>If no order is found, the CPNP server generates a FAIL error
with the appropriate error code.</t>
<t>If an order is found, the server checks whether it can honor
the request:<list style="symbols">
<t>A FAIL message is sent to the client if the server cannot
honor the request. The client may initiate a new PQO
negotiation cycle.</t>
<t>An OFFER message including the updated connectivity
provisioning document 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.</t>
</list></t>
</list></t>
<t>A flow chart that illustrates the use of UPDATE operation is
shown in <xref target="update"></xref>.<figure align="center"
anchor="update" title="UPDATE Flow Example">
<artwork><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|=========UPDATE (Diff CPD)==========>|
|<============PROCESSING==============|
|<========OFFER (Updated CPD)=========|
|=============PROCESSING=============>|
|=========ACCEPT (Updated CPD)=======>|
|<=========ACK (Updated CPD)==========|
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="fail" title="FAIL">
<t>The format of FAIL message is shown below:</t>
<t><list hangIndent="19" style="hanging">
<t hangText="<FAIL Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_ORDER_IDENTIFIER></t>
<t><PROVIDER_ORDER_IDENTIFIER></t>
<t><STATUS_CODE></t>
</list></t>
<t>This message is sent in the following cases:<list style="symbols">
<t>The server can not honor an order received from the client
(i.e., received in a PROVISION or UPDATE request).</t>
<t>The server encounters an error when processing a CPNP request
received from the client.</t>
</list></t>
<t>The status code indicates the error code. The following codes are
currently supported; other codes will be defined in future versions
of the document:<list style="empty">
<t>1 (Validation Error): The message can not be validated (see
<xref target="validation"></xref>).</t>
<t>2 (Authentication Required): the request cannot be handled
because authentication is required.</t>
<t>3 (Authorization Required): : the request cannot be handled
because authorization failed.</t>
<t>4 (Administratively prohibited): the request can not be
handled because of administrative policies.</t>
<t>5 (Out of Resources): the request can not be honored because
there is not enough capacity.</t>
<t>6 (Network Presence): the request can not be honored because
there is no network presence.</t>
</list></t>
<t></t>
</section>
</section>
</section>
<section anchor="validation" title="Message Validation">
<t>Both client and server proceed with CPNP message validation. The
following tables summarize the validation checks to be followed.</t>
<section title="On the Client Side">
<t></t>
<texttable style="headers">
<ttcol>Operation</ttcol>
<ttcol>Validation Checks</ttcol>
<c>PROCESSING</c>
<c>{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.</c>
<c>OFFER</c>
<c>{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.</c>
<c>ACK (PROVISION Transaction)</c>
<c>{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.</c>
<c>ACK (UPDATE Transaction)</c>
<c>{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.</c>
<c>ACK (WITHDRAW Transaction)</c>
<c>{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.</c>
</texttable>
<t></t>
</section>
<section title="On the Server Side">
<t></t>
<texttable style="headers">
<ttcol>Method</ttcol>
<ttcol>Validation Checks</ttcol>
<c>PROVISION</c>
<c>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.</c>
<c>PROCESSING</c>
<c>The sequence number carried in the packet must be larger than the
sequence number maintained by the server.</c>
<c>ACCEPT</c>
<c>{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.</c>
<c>DECLINE</c>
<c>{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.</c>
<c>UPDATE</c>
<c>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".</c>
<c>WITHDRAW</c>
<c>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".</c>
</texttable>
<t></t>
</section>
</section>
<section anchor="behavior" title="Theory of Operation">
<t>Both CPNP client and server proceeds to message validation checks as
specified in <xref target="validation"></xref>.</t>
<section title="Client Behavior">
<t></t>
<section anchor="creation" title="Order Negotiation Cycle">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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".</t>
<t>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.</t>
<t>If an offer is received from the server (i.e., as documented in
an OFFER message), the client may accept or reject the offer. <!--Or renegotiate.-->
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.<!--This suggests another timer that, when expired, triggers re-transmission. This may also raises additional complexity, depending on the time it takes for the server to ACK. This suggests additionalm server behavior, like "The client considers the OFFER is not valid anymore after x re-transmission attempts." --></t>
<t>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.<!--Looks like a re-negotiation capability to me. I'm not sure I would be that radical, i.e., cancel an existing offer and then re-submit a different SSR. For the sake of consistency, I would keep the same TRANSACTION_ID and offer the re-negotiation capability.--></t>
</section>
<section anchor="corw" title="Order Withdrawal Cycle">
<t>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 <xref target="creation"></xref>.</t>
<t>If no ACK is received from the server, the client proceeds with
the re-transmission of the message.</t>
</section>
<section anchor="cordu" title="Order Update Cycle">
<t>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 <xref
target="creation"></xref>. The client must include in the UPDATE
message an updated CPD with the requested changes.</t>
<t>Subsequent messages exchange is similar to what is documented in
<xref target="creation"></xref>.</t>
</section>
</section>
<section title="Server Behavior">
<t></t>
<section anchor="handling" title="Order Processing">
<t>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 (
<xref target="validation"></xref>), 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.</t>
<t>If the server cannot honor the request, it sends backs a FAIL
message with the appropriate error code.</t>
<t>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.</t>
<t>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
<xref target="child"></xref>).<!--Not necessarily. As an AO, it can also rely upon an existing service portfolio that has been exchanged between partnering providers by some other means.--></t>
<t>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.</t>
<t>If an ACCEPT message is received before the offered validity date
expires, the server proceeds with validation checks as specified in
<xref target="validation"></xref>. The state of the corresponding
order is passed to "AcceptReceived". The server sends back an ACK
message to terminate the order processing cycle.</t>
<t>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".</t>
</section>
<section anchor="sordw" title="Order Withdrawal">
<t>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 <xref
target="validation"></xref>.<list style="symbols">
<t>If the checks fail, a FAIL message is sent back to the client
with the appropriate error code.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="sordu" title="Order Update">
<t>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 <xref
target="validation"></xref>.<list style="symbols">
<t>If the checks fail, a FAIL message is sent back to the client
with the appropriate error code.</t>
<t>Subsequent messages exchange is similar to what is specified
in <xref target="creation"></xref>. The server should generate a
new Nonce value to be included in the offer made to the
client.</t>
</list></t>
</section>
</section>
<section title="Sequence Numbers">
<t>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.</t>
</section>
<section title="Message Re-Transmission">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="og" title="Operational Guidelines">
<t></t>
<section title="Logging on the CPNP Server ">
<t>The CPNP server SHOULD be configurable to log various events and
associated information. Such information includes:</t>
<t><list style="symbols">
<t>Client's IP Address</t>
<t>Any event change (e.g., new quotation order, offer sent, order
confirm, order cancellation, order withdraw, etc.)</t>
<t>Timestamp</t>
</list></t>
</section>
<section title="Business Guidelines & Objectives">
<t>The CPNP server can operate in the following modes: <list
style="numbers">
<t>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.</t>
<t>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.</t>
</list>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.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>The client and the server should be mutually authenticated. Out of
band mechanisms can be used instead of integrating them into CPNP.</t>
<t>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.</t>
<t>The Provider must enforce means to protect privacy-related
information captured in a CPP documents exchanged using CPNP messages
<xref target="RFC6462"></xref>. 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 <xref
target="RFC6462"></xref><xref target="RFC6973"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>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
<xref target="RFC6347"></xref>, 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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>Authors of the document request IANA to assign a UDP port for
CPNP.</t>
<t>A registry for CPNP methods should be created. The following codes
are reserved:<list style="format %d:">
<t>PROVISION</t>
<t>PROCESSING</t>
<t>OFFER</t>
<t>ACCEPT</t>
<t>DECLINE</t>
<t>ACK</t>
<t>CANCEL</t>
<t>WITHDRAW</t>
<t>UPDATE</t>
<t>FAIL</t>
</list></t>
<t>A registry for CPNP errors should be created. The following codes are
reserved:<list style="format %d:">
<t>Message Validation Error</t>
<t>Authentication Required</t>
<t>Authorization Failed</t>
<t>Administratively prohibited</t>
<t>Out of Resources</t>
<t>Network Presence Error</t>
</list></t>
<t></t>
<t><?rfc subcompact="no" ?></t>
</section>
<section title="Acknowledgements">
<t>Thanks to Diego R. Lopez for his comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.RFC.4086'?>
<?rfc include='reference.RFC.5511'?>
<?rfc include='reference.RFC.1123'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4176'?>
<?rfc include='reference.I-D.boucadair-connectivity-provisioning-profile'?>
<?rfc include='reference.RFC.7149'?>
<?rfc include='reference.RFC.6973'?>
<?rfc include='reference.RFC.6462'?>
<?rfc include='reference.RFC.6770'?>
<?rfc include='reference.RFC.2782'?>
<?rfc include='reference.RFC.6347'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:39:21 |