One document matched: draft-boucadair-connectivity-provisioning-protocol-10.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-10"
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>
<author fullname="Panos Georgatsos" initials="P." surname="Georgatsos">
<organization abbrev="CERTH">Centre for Research and Innovation
Hellas</organization>
<address>
<postal>
<street>78, Filikis Etairias str.</street>
<city>Volos</city>
<region>Hellas</region>
<code>38334</code>
<country>Greece</country>
</postal>
<phone>+302421306070</phone>
<email>pgeorgat@iti.gr</email>
</address>
</author>
<date day="" month="" year="2015" />
<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.</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, Content Delivery Networks
(CDN) 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
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 provisioning 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="RFC7297"></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 (VoIP), IPTV, and Virtual Private Network (VPN) services
<xref target="RFC4026"></xref>. The CPP document defines the set of IP
transfer parameters that reflect the guarantees that can be provided by
the underlying transport network together with reachability scope and
capacity needs. CPNP uses the CPP template to encode connectivity
provisioning clauses.</t>
<t>As a reminder, several proposals have been made in the past by the
(research) community (e.g., COPS-SLS, Service Negotiation Protocol
(SrNP), Dynamic Service Negotiation Protocol (DSNP), Resource
Negotiation and Pricing Protocol (RNAP), Service Negotiation and
Acquisition Protocol (SNAP), etc.). 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 the 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 could benefit from CPNP.</t>
<t><xref target="suc"></xref> discusses CPNP deployment models.</t>
<t><xref target="cnm"></xref> presents the CPNP negotiation
model.</t>
<t><xref target="po"></xref> provides an overview of the
protocol.</t>
<t><xref target="co"></xref> specifies the CPNP objects.</t>
<t><xref target="validation"></xref> describes the CPNP message
validation procedure.</t>
<t><xref target="behavior"></xref> specifies the behavior of the
involved CPNP functional elements.</t>
<t><xref target="og"></xref> discusses relevant operational
guidelines.</t>
<t><xref target="Security"></xref> discusses protocol security
aspects.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<list style="symbols">
<t>Customer: <vspace blankLines="1" />Is a business role which
denotes an entity that is involved in the definition and the
possible negotiation of a contract, including a Connectivity
Provisioning Agreement, with a Provider. A connectivity provisioning
contract is captured in a dedicated CPP template-based document,
which specifies (among other information): the sites to be
connected, border nodes, outsourced operations (e.g., routing, force
via points). <vspace blankLines="1" />The right to invoke the
subscribed service may be delegated by the Customer to third-party
End Users, or brokering services.<vspace blankLines="1" />A Customer
can be a Service Provider, an application owner, an enterprise, a
user, etc.</t>
<t>Network Provider (or Provider): <vspace blankLines="1" />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 at specific rates). Offered
connectivity services may not necessarily be restricted to IP.
<vspace blankLines="1" />The policies to be enforced by the
connectivity service delivery components can be derived from the
technology-specific clauses that might be included in contracts
agreed with the Customers. If no such clauses are included in the
agreement, the mapping between the connectivity requirements and the
underlying technology-specific policies to be enforced is
deployment-specific.</t>
<t>Quotation Order: <vspace blankLines="1" />Denotes a request made
by the Customer to the Provider that includes a set of requirements.
The Customer may express its service-specific requirements by
assigning (fixed or loosely defined) values to the information items
included in the commonly understood template (e.g., CPP template)
describing the offered service. These requirements constitute the
parameters to be mutually agreed upon.</t>
<t>Offer: <vspace blankLines="1" />Refers to a response made by the
Provider to a Customer 's quotation order as to the extent at which
the Provider may satisfy the order at the time of its receipt.
Offers reflect the capability of the Provider in accommodating
received Customer orders beyond monolithic ‘yes/no’
answers. <vspace blankLines="1" />An offer may fully or partially
meet the requirements of the corresponding order. In the latter
case, it may include alternative suggestions which the Customer may
take into account by issuing a new order.</t>
<t>Agreement: <vspace blankLines="1" />Refers to an order placed by
the Customer and accepted by the Provider. It signals the successful
conclusion of a negotiation cycle.</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): <vspace blankLines="1" />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>Accept an offer made by a server (<xref
target="creation"></xref>).</t>
<t>Withdraw an agreement (<xref target="corw"></xref>).</t>
<t>Update an agreement (<xref target="cordu"></xref>).</t>
</list></t>
<t>CPNP server (or server): <vspace blankLines="1" />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>Process a quotation order (<xref
target="handling"></xref>).</t>
<t>Make an offer (<xref target="handling"></xref>).</t>
<t>Cancel an ongoing quotation order (<xref
target="sordw"></xref>).</t>
<t>Process an order withdrawal (<xref
target="sordu"></xref>).</t>
</list></t>
</list></t>
</section>
<section anchor="opm" title="Order Processing Models">
<t>For preparing their service orders, the Customers may need to be
aware of the offered services. The Providers therefore should first
proceed with the announcement of the services that they can provide. The
service announcement process may take place at designated global or
Provider-specific service markets, or through explicit interactions with
the Providers. The details of this process are outside the scope of a
negotiation protocol.</t>
<t>With or without such service announcement mechanisms in place, the
following order processing models can be distinguished:</t>
<t>The following order processing models can be distinguished:<list
style="numbers">
<t>Frozen model: <vspace blankLines="1" />The Customer cannot
actually negotiate the parameters of the service(s) offered by a
Provider. After consulting the Provider's service portfolio, the
Customer selects the service offer 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 (i.e., these customers
share the same Customer Provisioning Profile).</t>
<t>Negotiation-based model: <vspace blankLines="1" />Unlike the
frozen model, the Customer documents his/her requirements in a
request for a quotation, which is then sent to one or several
Providers. Solicited Providers check whether they can address these
requirements or not, and get back to the Customer accordingly,
possibly with an offer that may not exactly match customer's
requirements (e.g., a 100 Mbps connection cannot be provisioned
given the amount of available resources, but an 80 Mbps connection
can be provided). A negotiation between the Customer and the
Provider(s) then follows to the end of reaching an agreement.</t>
</list></t>
<t>Both frozen and negotiation-based models require the existence of
appropriate service templates like a CPP template and their
instantiation for expressing specific offerings from Providers and
service requirements from Customers, respectively. CPNP can be used in
either model for automating the required Customer-Provider interactions.
Since the frozen model can be seen as a special case of the
negotiation-based model, not only ‘yes/no’ answers but also
counter offers may be issued by the Provider in response to Customer
orders, 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:<?rfc subcompact="yes"?><list
style="symbols">
<t>Network Provisioning (including Order Activation, Network
Planning, etc.)</t>
<t>Authentication, Authorization and Accounting (AAA)</t>
<t>Network and service management (performance verification,
complaint analysis, etc.)</t>
<t>Sales-related functional blocks (e.g., billing, invoice
validation, etc.)</t>
<t>Network Impact Analysis<?rfc subcompact="no"?></t>
</list></t>
<t>CPNP does not assume any specific knowledge about these functional
blocks, drawing an explicit line between protocol operation and the
logic for handling connectivity provisioning requests. Evidently order
handling logic is subject to the information manipulated by these
blocks. For example, the resources that can be allocated to accommodate
Customer's requirements may depend on network availability estimates as
calculated by the planning functions and related policies as well as on
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
subsequently managed by the Provider's Information System.</t>
</section>
<section anchor="suc" title="Sample Use Cases ">
<t>A non-exhaustive 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.
<vspace blankLines="1" />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
interconnection services (e.g., enable, update, disconnect). For
example, two Autonomous Systems (ASes) can be connected via several
interconnection points. CPNP can be used between these ASes to
upgrade existing links, request additional resources, provision a
new interconnection point, etc. <vspace blankLines="1" />See for
example the framework documented in <xref
target="ETICS"></xref>.</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 use CPNP to initiate connectivity
provisioning requests towards a number of Network Providers so that
to optimize the cost of delivering their services. Although multiple
CPNP ordering cycles can be initiated by a Service Provider towards
multiple Network Providers, a subset of these orders may actually be
put into effect.<vspace blankLines="1" />For example, a cloud
Service Provider can use CPNP to request more resources from Network
Providers.</t>
<t>CPNP can be used in Machine-to-Machine (M2M) environments to
dynamically subscribe to M2M services (e.g., access to data
retrieved by a set of sensors, extend sensor coverage, etc.).<vspace
blankLines="1" />Also, Internet of Things (IoT, <xref
target="RFC6574"></xref>) domains may rely on CPNP to enable dynamic
provisioning of data produced by involved objects, according to
their specific policies, to various external stakeholders such as
data analytics and business intelligence companies. Direct
CPNP-based interactions between IoT domains and interested parties
enable open access to diverse sets of data across the Internet,
e.g., from multiple types of sensors, user groups and/or
geographical areas.</t>
<t>A Provider offering cloud services can expose a CPNP interface to
allow Customers to dynamically negotiate related service features
such as additional storage, processing and networking resources,
enhanced security filters, etc.</t>
<t>In the inter-cloud context (also called cloud of clouds or cloud
federation), CPNP can be used to reserve external computing and
networking resources in other cloud environments.</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>).<vspace
blankLines="1" /><figure align="center" anchor="cdni"
title="CDN Interconnection">
<artwork align="center"><![CDATA[ ,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--']]></artwork>
</figure></t>
<t>LISP (<xref target="RFC6830"></xref>) Mapping Service Providers
can use CPNP to enrich their mapping database by interconnecting
their mapping system (see <xref target="map"></xref>). This
interconnection allows to relax the constraints on PxTR in favour of
native LISP forwarding. Also, it allows to prevent fragmented LISP
mapping database.<vspace blankLines="1" /><figure align="center"
anchor="map" title="LISP Mapping System Interconnect">
<artwork align="center"><![CDATA[ ,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
(Mapping System 'A')===(Mapping System 'B')
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
]]></artwork>
</figure></t>
</list></t>
</section>
<section anchor="dm" title="CPNP Deployment Models">
<t>Several CPNP deployment models can be envisaged. Two examples are
listed below:<?rfc subcompact="yes"?><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).<?rfc subcompact="no"?></t>
</list></t>
<t>Once the negotiation of connectivity provisioning parameters is
successfully concluded that is, an order has been placed by the
Customer, the actual network provisioning operations are initiated. The
specification of related dynamic resource allocation and policy
enforcement schemes, as well as how CPNP servers interact with the
network provisioning functional blocks at Provider sides 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 runs between a Customer and a Provider carrying service orders
from the Customer and respective responses from the Provider to the end
of reaching a connectivity service provisioning agreement. As the
services offered by the Provider are well-described, by means of the CPP
template, the negotiation process is essentially a value-settlement
process, where an agreement is pursued on the values of the commonly
understood information items (service parameters) included in the
service description template.</t>
<t>The protocol is transparent to the content that it carries and to the
negotiation logic, at Customer and Provider sides, that manipulates the
content.</t>
<t>The protocol aims at facilitating the execution of the negotiation
logic by providing the required generic communication primitives.</t>
<t>Since negotiations are initiated and primarily driven by the
Customer's negotiation logic, it is reasonable to assume that the
Customer can only call for an agreement. An implicit approach is adopted
for not overloading the protocol with additional messages. In
particular, the acceptance of an offer made by the Provider signals a
call for agreement from the Customer. Note that it is almost certain the
Provider to accept this call since it refers to an offer that itself
made. Of course, at any point the Provider or the Customer may quit the
negotiations, each on its own grounds.</t>
<t>Based on the above, CPNP adopts a Quotation Order/Offer/Answer model,
which proceeds through the following basic steps:</t>
<t><list style="numbers">
<t>The client specifies its service requirements via a Provision
Quotation Order (PQO). The order may include fixed or loosely
defined values in the clauses describing service provisioning
characteristics.</t>
<t>The server declines the PQO, or makes an offer to address the
requirements of the PQO, or which may suggests a counter-proposals
that partially addresses the requirements of the PQO for specific
requirements that cannot be accommodated.</t>
<t>The client either accepts or declines the offer. Accepting the
offer implies a call for agreement.</t>
</list></t>
<t>Multiple instances of CPNP may run at Customer or Provider domains. A
CPNP client may be engaged simultaneously in multiple negotiations with
the same or different CPNP servers (parallel negotiations, see <xref
target="mser"></xref>) and a CPNP server may need to negotiate with
other Provider(s) as part of negotiations with a CPNP client (cascaded
negotiations, see <xref target="cascaded"></xref>).</t>
<t>CPNP relies on various timers to achieve its operations. These timers
are used to guide the negotiation logic at both CPNP client and CPNP
server sides, particularly in cases where the CPNP client is involved in
parallel negotiations with several CPNP servers or in cases where the
CPNP server is, in its turn, involved in negotiations with other
Providers for processing a given quotation order. Related to the above,
CPNP allows the CPNP server to request for more time. This request may
be accepted or rejected by the CPNP client.</t>
<t>Providers may need to publish available services to the Customers
(see <xref target="opm"></xref>). CPNP may optionally support this
functionality. Dedicated templates can be defined for the purpose of
service announcements, which will be used by the CPNP clients to
initiate their CPNP negotiation cycles.</t>
<t>For simplicity, a single Offer/Answer stage is assumed within one a
CPNP negotiation cycle. Nevertheless, as stated before, multiple CPNP
negotiation cycles can be undertaken by a CPNP client (see <xref
target="examples"></xref>).</t>
<t>The model is flexible as it can accommodate changing conditions over
time (e.g., introduction of an additional VPN site).</t>
<t><figure align="center" anchor="examples"
title="Overall Negotiation Process">
<artwork align="center"><![CDATA[+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=====Quotation Order=====>| |=====Quotation Order=====>|
|<==========Offer==========| |<==========Offer==========|
|===========Accept========>| |==========Decline========>|
1-Step Successful Negotiation 1-Step Failed Negotiation
Cycle Cycle
+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|===Quotation Order(a)====>| |===Quotation Order(i)====>|
|<==========Offer==========| |<==========Offer==========|
|==========Decline========>| |==========Decline========>|
|===Quotation Order(b)====>| |===Quotation Order(j)====>|
|<==========Offer==========| |<==========Offer==========|
|===========Accept========>| |==========Decline========>|
|===Quotation Order(k)====>|
|<==========Offer==========|
|==========Decline========>|
|===Quotation Order(l)====>|
|<==Fail to make an offer==|
N-Step Negotiation Cycle: N-Step Negotiation Cycle:
Successful Negotiation Failed Negotiation
]]></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 is designed to run over any
transport protocol with UDP being the default transport mode. 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. The client sends CPNP messages to CPNP_PORT. The
same port used as the source port of the request sent to the server
must be used by the server to reply to that request.</t>
<t>CPNP is independent of the IP address family.</t>
<t>CPNP retransmission is discussed in <xref
target="retrans"></xref>.</t>
</section>
<section title="Server Discovery">
<t>The CPNP client can be configured with the CPNP server(s) using
manual or dynamic configuration means. For example, Providers may
configure dedicated SRV records (<xref target="RFC2782"></xref>) or
may use a well-known name/address.</t>
<t>Discussions about how the client can discovers its the server(s) of
its interest are out of the scope of this document. The document
assumes that a the required 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 its decision-making process, the CPNP server may be
connected to various external modules such as: Customer Profiles,
Network Topology, Network Resource Management, Orders Repository, AAA
and Network Provisioning Manager (an example is shown in <xref
target="fb"></xref>).</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 a provisioning
quotation request.</t>
<t>Check whether a customer is entitled to cancel an on-going
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.,
pricing, network usage levels, threshold on number of CPP
templates that can be processed over a given period of time as a
function of the nature of the service to be delivered, etc.).</t>
<t>Transfer completed orders to network provisioning blocks.<?rfc subcompact="no"?></t>
</list>The above list of CPNP server operations is not
exhaustive.</t>
<t><figure align="center" anchor="fb"
title="Order Handling Management Functional Block">
<artwork align="center"><![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><?rfc subcompact="yes"?></t>
<t>The following order handling modes can be also configured on the
server:<list style="numbers">
<t>Fully automated mode: <vspace blankLines="1" />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: <vspace
blankLines="1" />Some or all of the server's operations are
subject to administrative validation procedures. This mode
requires an action from the administrator for every request
received. The CPNP methods which can be automatically handled by
the server or they are subject to one or several validation
administrative checks can be configured on the server.</t>
</list></t>
</section>
<section anchor="session" 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:<?rfc subcompact="yes"?><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<?rfc subcompact="no"?></t>
</list></t>
</section>
<section title="Extended CPNP Session">
<t>An extended PQO session is denoted by a 5-uplet defined as
follows:<list style="symbols">
<t>CPNP session (<xref target="session"></xref>)</t>
<t>Incremented Sequence Number (<xref target="sq_nu"></xref>)</t>
<t>Customer Agreement Identifier: This is a unique identifier
assigned to the order under negotiation by the client (<xref
target="cu_id"></xref>). This identifier is also used to identify
the agreement that will result from a successful negotiation.</t>
<t>Provider Agreement Identifier: This is a unique identifier
assigned to the order under negotiation by the server (<xref
target="pr_id"></xref>). This identifier is also used to identify
the agreement that will result from a successful negotiation.</t>
<t>Transaction-ID (<xref target="trans_id"></xref>)</t>
</list></t>
</section>
<section anchor="trans" title="CPNP Transaction">
<t>A CPNP transaction occurs between a client and a server for
pursuing, modifying, withdrawing a service agreement and comprises all
CPNP messages exchanged between the client and the server, from the
first request sent by the client to the final response sent by the
server. A CPNP transaction is bound to a CPNP session.</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 by 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 for validating CPNP responses received by the
client.</t>
<t>In the context of a transaction, the client needs to randomly
select a sequence number and assign it in the first CPNP message to
send. This number is then incremented for each request message is
subsequently sent within the on-going CPNP transaction (see <xref
target="sq_nu"></xref>).</t>
</section>
<section anchor="timers" 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 a maximum retry threshold are
described in <xref target="behavior"></xref>.</t>
<t>The response timer (RESPONSE_TIMER) is set by the client to denote
the time, in seconds, the client will wait for receiving a response
from the server to a provisioning quotation order request (see <xref
target="extime"></xref>). If the timer expires, the respective
quotation order is cancelled by the client and a CANCEL message is
generated accordingly.</t>
<t>An offer expiration timer (EXPIRE_TIMER) is set by the server to
represent the time, in minutes, after which an offer made by the
server will be invalid (see <xref target="valtime"></xref>).</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 necessitate a distinct CPNP
client/server authentication phase before negotiation begins.<list
style="symbols">
<t>QUOTATION: <vspace blankLines="1" />This operation is used by
the client to initiate a provisioning quotation order. Upon
receipt of a QUOTATION request, the server may respond with a
PROCESSING, OFFER or a FAIL message. A QUOTATION-initiated
transaction can be terminated by a FAIL message.</t>
<t>PROCESSING: <vspace blankLines="1" />This operation is used to
inform the remote party that the message (the order quotation or
the offer) sent was received and it is processed. This message can
also be issued by the server to request more time, in which case
the client may reply with an ACK or FAIL message depending on
whether more time can or cannot be granted.</t>
<t>OFFER: <vspace blankLines="1" />This operation is used by the
server to inform the client about an offer that can best
accommodate the requirements indicated in the previously received
QUOTATION message.</t>
<t>ACCEPT: <vspace blankLines="1" />This operation is used by the
client to confirm the acceptance of an offer made by the server.
This message implies a call for agreement. An agreement is reached
when an ACK is subsequently received from the server, which is
likely to happen; it is rather unlikely the server to reject an
offer that it has already made.</t>
<t>ACK: <vspace blankLines="1" />This operation is used by the
server to acknowledge the receipt of an ACCEPT or WITHDRAW
message, or by the client to confirm the time extension requested
by the server for processing the last received quotation
order.</t>
<t>DECLINE: <vspace blankLines="1" />This operation is used by the
client to reject an offer made by the server. The on-going
transaction may not be terminated immediately, e.g., the
server/client may issue another offer/order.</t>
<t>CANCEL: <vspace blankLines="1" />This operation is used by the
client to cancel (quit) the on-going transaction.</t>
<t>WITHDRAW: <vspace blankLines="1" />This operation is used by
the client to withdraw an agreement.</t>
<t>UPDATE: <vspace blankLines="1" />This operation is used by the
client to update an existing agreement. For example, this method
can be invoked to add a new site. This method will trigger a new
negotiation cycle.</t>
<t>FAIL: <vspace blankLines="1" />This operation is used by the
server to indicate that it cannot accommodate the requirements
documented in the PQO conveyed in the QUOTATION message or to
inform the client about an error encountered when processing the
received message. In either case, the message implies that the
server is unable to make offers and as such it terminates the
on-going transaction. <vspace blankLines="1" />This message is
also used by the client to reject a time extension request
received from the server (in a PROCESSING message). The message
includes a status code for providing explanatory information.</t>
</list></t>
<t>Evidently, the above CPNP primitives are service-independent. CPNP
messages may transparently carry service-specific objects which are
handled by the negotiation logic at either side. The document
specifies the service objects that are required for connectivity
provisioning negotiation (see <xref target="cpd"></xref>). Additional
service-specific objects to be carried in the CPNP messages can be
defined in the future for accommodating alternative deployment or
other service provisioning 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="RFC7297"></xref>.<list style="symbols">
<t>Requested Connectivity Provisioning Document (Requested CPD):
<vspace blankLines="1" />refers to the CPD included by a CPNP
client in a QUOTATION request.</t>
<t>Offered Connectivity Provisioning Document (Offered CPD):
<vspace blankLines="1" />This document is included by a CPNP
server in an OFFER message. Its information reflects the proposal
of the server to accommodate all or a subset of the clauses
depicted in a Requested CPD. A validity time is associated with
the offer made.</t>
<t>Agreed Connectivity Provisioning Document (Agreed CPD): <vspace
blankLines="1" />If the client accepts an offer made by the
server, the Offered CPD is included in an ACCEPT message. This CPD
is also included in an ACK message. Thus, a 3-way hand-shaking
procedure is followed for successfully concluding the
negotiation.</t>
</list></t>
<t><xref target="example"></xref> shows a typical CPNP negotiation
cycle and the use of the different types of Connectivity Provisioning
Documents.</t>
<t><figure align="center" anchor="example"
title="Connectivity Provisioning Documents">
<artwork align="center"><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|======QUOTATION (Requested CPD)=====>|
|<============PROCESSING==============|
|<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>|
|=========ACCEPT (Agreed CPD)========>|
|<=========ACK (Agreed CPD)===========|
]]></artwork>
</figure></t>
<t>A provisioning document can include parameters with fixed values,
loosely defined values, or a combination thereof. A provisioning
document is said to be concrete if all clauses have fixed values.</t>
<t>A typical evolution of a negotiation cycle would start with a
quotation order with loosely defined parameters, and then, as offers
are made, it would conclude with concrete provisioning document for
calling for the agreement.</t>
</section>
<section anchor="cascaded" title="Child Provisioning Quotation Orders">
<t>If the server detects that network resources from another Network
Provider need to be allocated in order to accommodate the requirements
described in a PQO (e.g., in the context of an inter-domain VPN
service, additional 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 also 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 align="center"><![CDATA[+------+ +--------+ +--------+
|Client| |Server A| |Server B|
+------+ +--------+ +--------+
| | |
|=====QUOTATION=====>| |
|<====PROCESSING=====| |
| |=====QUOTATION=====>|
| |<====PROCESSING=====|
| |<=======OFFER=======|
| |=====PROCESSING====>|
| |=======ACCEPT======>|
| |<=======ACK=========|
|<=======OFFER=======| |
|=====PROCESSING====>| |
|=======ACCEPT======>| |
|<=======ACK=========| |
]]></artwork>
</figure></t>
</section>
<section anchor="mser" title="Negotiations with Multiple CPNP Servers">
<t>A CPNP client may undertake multiple negotiations in parallel with
several servers for practical reasons such as cost optimization and
fail-safety. The multiple negotiations may lead to one or many
agreements. Multiple negotiations with the same Provider are not
precluded.</t>
<t>The salient point underlining the parallel negotiations scenario is
that although the negotiation protocol is strictly between two
parties, the negotiation logic may not necessarily be. The CPNP client
negotiation logic may need to collectively drive parallel
negotiations, as the negotiation with one server may affect the
negotiation with other servers; e.g., it may need to use the responses
from all servers as input for determining the messages (and their
content) to subsequently send in each individual negotiation. Timing
is therefore an important aspect at the client's. The CPNP client
needs to have the ability to synchronize the receipt of the responses
from the servers. CPNP takes into account this requirement by allowing
clients to specify in the QUOTATION message the time by which the
server needs to respond (see <xref target="extime"></xref>).</t>
</section>
<section title="State Management">
<t>Both the client and the server maintain repositories to store
on-going orders. How these repositories are maintained is
deployment-specific. It is out of scope of this document to elaborate
on such considerations. Timestamps are also logged to track state
change. Tracking may be needed for various reasons,including
regulatory ones.</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:</t>
<t><list style="symbols">
<t>Created: <vspace blankLines="1" />when the order has been
created. It is not handled by the client until the administrator
allows to process it.</t>
<t>AwaitingProcessing: <vspace blankLines="1" />when the
administrator approved of processing a created order and the
order has not been handled yet.</t>
<t>PQOSent: <vspace blankLines="1" />when the order has been
sent to the server.</t>
<t>ServerProcessing: <vspace blankLines="1" />when the server
has confirmed the receipt of the order.</t>
<t>OfferReceived: <vspace blankLines="1" />when an offer has
been received from the server.</t>
<t>OfferProcessing: <vspace blankLines="1" />when a received
offer is currently processed by the client.</t>
<t>AcceptSent: <vspace blankLines="1" />when the client
confirmed the offer to the server.</t>
<t>AcceptAck: <vspace blankLines="1" />when the offer is
acknowledged by the server.</t>
<t>Cancelled: <vspace blankLines="1" />when the order has failed
or cancelled.</t>
</list></t>
<t><figure align="center" anchor="clientstate"
title="CPNP Finite State Machine (Client Side)">
<artwork align="center"><![CDATA[+------------------+
| Created |-----------------+
+------------------+ |
| |
v |
+------------------+ |
|AwaitingProcessing|----------------+|
+------------------+ ||
| ||
QUOTATION ||
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 and a corresponding offer on the server's side:</t>
<t><list style="symbols">
<t>PQOReceived: <vspace blankLines="1" />when the order has been
received from the client.</t>
<t>AwaitingProcessing: <vspace blankLines="1" />when the order
is being processed by the server. An action from the server
administrator may be needed.</t>
<t>OfferProposed: <vspace blankLines="1" />when the request has
been successfully handled and an offer has been sent to the
client.</t>
<t>ProcessingReceived: <vspace blankLines="1" />when the server
received a PROCESSING for an offer sent to the client.</t>
<t>AcceptReceived: <vspace blankLines="1" />when the server
received a confirmation for the offer from the client.</t>
<t>AcceptAck: <vspace blankLines="1" />when the server
acknowledged the offer (accepted by client) to the client.</t>
<t>Cancelled: <vspace blankLines="1" />when the order has failed
to be met or it has been cancelled by the client. Associate
resources must be released in the latter case, if prior
reserved.</t>
<t>ChildCreated: <vspace blankLines="1" />when a child order has
been created in cases where resources from another Network
Provider are needed.</t>
<t>ChildPQOSent: <vspace blankLines="1" />when a child order has
been sent to the remote server.</t>
<t>ChildServerProcessing: <vspace blankLines="1" />when a child
order is currently processed by the remote server.</t>
<t>ChildOfferReceived: <vspace blankLines="1" />when an offer
has been received to a child order from the remote server.</t>
<t>ChildOfferProcessing: <vspace blankLines="1" />when a
received offer to a child order is currently processed.</t>
<t>ChildAcceptSent: <vspace blankLines="1" />when the child
offer (offer received from the remote server in response to a
child order) is confirmed to the remote server.</t>
<t>ChildAcceptAck: <vspace blankLines="1" />when an accepted
child offer is acknowledged by the remote server.</t>
</list></t>
<t></t>
<t><figure align="center" anchor="serverstate"
title="CPNP Finite State Machine (Server Side)">
<artwork align="center"><![CDATA[ +------------------+
+---------------------| ChildCreated |
| +------------------+
v | ^
+------------------+ | |
| ChildPQOSent |----------------+| Q
+------------------+ || U
| || O
QUOTATION || T
v || A +--------------------+
+---------------------+ CANCEL || T | PQOReceived |
|ChildServerProcessing|------------+|| I +--------------------+
+---------------------+ FAIL vvv O | |
| +-----+ N CANCEL |
PROCESSING | |<---|-------+ PROCESSING
v | | | v
+------------------+ | | +------------------------+
|ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing |
+------------------+ | A | +------------------------+
| | N | ^ | OFFER
OFFER | C | | +------------------+
| | E |<DECLINE-| OfferProposed |
| | L | | +------------------+
v | L | | |
+------------------+ | E | | PROCESSING
|ChildOfferReceived|---CANCEL----| D | | v
+------------------+ | | | +------------------+
| | |<DECLINE-| Proc'ingReceived |
PROCESSING | | +------------------+
| +-----+ | | ACCEPT
v ^^^^^ | v
+------------------+ ||||| | +------------------+
|ChildOfferProc'ing|---DECLINE----+|||+-CANCEL-|-| AcceptReceived |
+------------------+ ||| | +------------------+
|ACCEPT ||| | |ACK
v ||| | v
+------------------+ ||| | +------------------+
| ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-| AcceptAck |
+------------------+ | | +------------------+
| ACK | |
v | |
+------------------+ | |
| ChildAcceptAck |---WITHDRAW-----+ |
+------------------+ |
| |
+--------------------------------------+
]]></artwork>
</figure></t>
<t></t>
</section>
</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><list style="empty">
<t>Note: The formats of CPNP messages are provided using a generic
format. Implementors can adapt RBNF definitions to their "favourite"
message format.</t>
</list></t>
<t>This document focuses on connectivity provisioning objects;
additional Information Elements (IEs) can be defined in the future.</t>
<t><?rfc subcompact="yes" ?></t>
<section title="Attributes">
<t></t>
<section anchor="cu_id" title="CUSTOMER_AGREEMENT_IDENTIFIER">
<t>CUSTOMER_AGREEMENT_IDENTIFIER is an identifier which is assigned
by a client to identify an agreement. This identifier must be unique
to the client.</t>
<t>Rules for assigning this identifier are specific to the client
(Customer). The value of CUSTOMER_AGREEMENT_IDENTIFIER is included
in all CPNP messages.</t>
<t>The client (Customer) assigns an identifier to an order under
negotiation before an agreement is reached. This identifier will be
used to unambiguously identify the resulting agreement at the client
side (Customer).</t>
<t>The server handles CUSTOMER_AGREEMENT_IDENTIFIER as an opaque
value.</t>
</section>
<section anchor="pr_id" title="PROVIDER_AGREEMENT_IDENTIFIER">
<t>PROVIDER_AGREEMENT_IDENTIFIER is an identifier which is assigned
by a server to identify an order. This identifier must be unique to
the server.</t>
<t>Rules for assigning this identifier are specific to the server
(Provider). The value of PROVIDER_AGREEMENT_IDENTIFIER is included
in all CPNP messages, except QUOTATION messages.</t>
<t>The server (Provider) assigns an identifier to an order under
negotiation before an agreement is reached. This identifier will be
used to unambiguously identify the resulting agreement at the server
side (Provider).</t>
<t>The client handles PROVIDER_AGREEMENT_IDENTIFIER as an opaque
value.</t>
</section>
<section anchor="trans_id" 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>
<t>Refer to <xref target="sq_nu"></xref>.</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 (including the resulting
agreement) 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 anchor="extime" title="EXPECTED_RESPONSE_TIME">
<t>This attribute indicates the time by when the CPNP client is
expecting to receive a response, for a PQO, from the CPNP server. If
no offer is received by then, the CPNP client will consider the
quotation order as rejected.</t>
<t>EXPECTED_RESPONSE_TIME follows the date format specified in <xref
target="RFC1123"></xref>.</t>
</section>
<section title="EXPECTED_OFFER_TIME">
<t>This attribute indicates the time by when the CPNP server is
expecting to make an offer to the CPNP client. If no offer is
received by then, the CPNP client will consider the order as
rejected.</t>
<t>The CPNP server may propose an expected offer time that does not
match the expected response time indicated in the quotation order
message. The CPNP client can accept or rejects the proposed expected
time by when the CPNP server will make an offer.</t>
<t>The CPNP server can always request extra time for its processing,
but this may be accepted or rejected by the CPNP client.</t>
<t>EXPECTED_OFFER_TIME follows the date format specified in <xref
target="RFC1123"></xref>.</t>
</section>
<section anchor="valtime" title="VALIDITY_OFFER_TIME">
<t>This attribute indicates the time of validity of an offer made by
the CPNP server. If the offer is not accepted before this date
expires, the CPNP server will consider the CPNP client has rejected
the offer; the CPNP server will silently clear this order.</t>
<t>VALIDITY_OFFER_TIME 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 (IE) 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:<?rfc subcompact="yes"?><list style="symbols">
<t>Name</t>
<t>Contact Information<?rfc subcompact="no"?></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:<?rfc subcompact="yes"?><list style="symbols">
<t>Name</t>
<t>AS Number (<xref target="RFC6793"></xref>)</t>
<t>Contact Information<?rfc subcompact="no"?></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:<?rfc subcompact="yes"?><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.<?rfc subcompact="no"?></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="QUOTATION">
<t>The format of the QUOTATION message is shown below:<?rfc subcompact="yes" ?></t>
<t><list hangIndent="23" style="hanging">
<t hangText="<QUOTATION Message> ::="><VERSION></t>
<t><METHOD_CODE></t>
<t><SEQUENCE_NUMBER></t>
<t><TRANSACTION_ID></t>
<t><CUSTOMER_AGREEMENT_IDENTIFIER></t>
<t>[<EXPECTED_RESPONSE_TIME>]</t>
<t><REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t><?rfc subcompact="no" ?>A QUOTATION message must include an order
identifier which is generated by the client. Because several orders
can be issued to several servers, the QUOTATION message must also
include a Transaction-ID.</t>
<t>The message may include an EXPECTED_RESPONSE_TIME which indicates
by when the client is expecting to receive an offer from the server.
QUOTATION message must also include a requested connectivity
provisioning document.</t>
<t>When the client sends the QUOTATION message to the server, the
state of the order changes to "PQOSent".</t>
</section>
<section anchor="proc" title="PROCESSING">
<t>The format of the PROCESSING message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t>[<EXPECTED_OFFER_TIME>]</t>
</list></t>
<t><?rfc subcompact="no" ?>Upon receipt of a QUOTATION 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_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed
in the QUOTATION message. The server may include an
EXPECTED_OFFER_TIME by when it expects to make an offer to the
client.</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_AGREEMENT_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_TIME
and then, it changes to state of the order to
"ServerProcessing".</t>
<t>If more time is required by the server to process the quotation
order, it may send a PROCESSING message that includes a new
EXPECTED_OFFER_TIME. The client can answer with an ACK message if
more time is granted (<xref target="timegranted"></xref>) or with a
FAIL message if the time extension is rejected (<xref
target="timerejected"></xref>).</t>
<t><figure align="center" anchor="timegranted"
title="Request more negotiation time: Granted">
<artwork align="center"><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|============ACK(TimeGranted)========>|
...
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|==========ACCEPT(Agreed CPD)========>|
|<==========ACK(Agreed CPD)===========|
]]></artwork>
</figure></t>
<t><figure align="center" anchor="timerejected"
title="Request more negotiation time: Rejected">
<artwork align="center"><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|===========FAIL(TimeRejected)=======>|
]]></artwork>
</figure></t>
</section>
<section anchor="offer" title="OFFER">
<t>The format of the OFFER message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t><NONCE></t>
<t><VALIDITY_OFFER_TIME></t>
<t><OFFERED_CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t><?rfc subcompact="no" ?>The server answers with an OFFER message
to a QUOTATION 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 time.</t>
</section>
<section anchor="accept" title="ACCEPT">
<t>The format of the ACCEPT message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t><NONCE></t>
<t><AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t><?rfc subcompact="no" ?>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 the ACK message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t>[<EXPECTED_RESPONSE_TIME>]</t>
<t>[<CONNECTIVITY_PROVISIONING_DOCUMENT>]</t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t><?rfc subcompact="no" ?>This message is issued by the server to
close a CPNP transaction or by a client to grant more negotiation
time to the server.</t>
<t>This message is sent by the server as a response to an ACCEPT,
WITHDRAW, DECLINE, or CANCEL message. In such case, the ACK message
must include the copy of the Connectivity Provisioning Document as
stored by the server, in particular:<?rfc subcompact="yes"?><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
QUOTATION transaction.</t>
<t>An empty CPD is included by the server if it successfully
handled a DECLINE message.<?rfc subcompact="no"?></t>
</list></t>
<t>A client may issue an ACK message as a response to a more time
request (conveyed in PROCESSING) received from the server. In such
case, the ACK message must include an EXPECTED_RESPONSE_TIME that is
likely to be set to the time extension requested by the server.</t>
</section>
<section anchor="dec" title="DECLINE">
<t>The format of the DECLINE message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t><NONCE></t>
</list><?rfc subcompact="no" ?>The client can issue a DECLINE
message to reject an offer. CUSTOMER_AGREEMENT_IDENTIFIER,
PROVIDER_AGREEMENT_IDENTIFIER, TRANSACTION_ID, and NONCE are used by
the server as keys to find the corresponding order. If an order
matches, the server changes the state of this order to "Cancelled"
and then returns an ACK with a copy of the requested CPD to the
requesting client.</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 align="center"><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<============PROCESSING==============|
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|===============DECLINE==============>|
|<================ACK=================|
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="cancel" title="CANCEL">
<t>The format of the CANCEL message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t>[<CONNECTIVITY_PROVISIONING_DOCUMENT>]</t>
</list><?rfc subcompact="no" ?>The client can issue a CANCEL
message at any stage during the CPNP negotiation process before an
agreement is reached. CUSTOMER_AGREEMENT_IDENTIFIER and
TRANSACTION_ID are used by the server as keys to find the
corresponding order. If a quotation order matches, the server
changes the state of this quotation order to "Cancelled" and then
returns an ACK with a copy of the requested CPD to the requesting
client.</t>
<t>If no quotation order is found, the server returns a FAIL message
to the requesting client.</t>
</section>
<section anchor="with" title="WITHDRAW">
<t>The format of the WITHDRAW message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t><NONCE></t>
<t>[<AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT>]</t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t><?rfc subcompact="no" ?>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 align="center"><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|============WITHDRAW(CPD)===========>|
|<============PROCESSING==============|
|<===========ACK(Empty CPD)===========|
]]></artwork>
</figure></t>
<t>The CPNP must include the same CUSTOMER_AGREEMENT_IDENTIFIER,
PROVIDER_AGREEMENT_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 the UPDATE message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t><NONCE></t>
<t><EXPECTED_RESPONSE_TIME></t>
<t><REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT></t>
<t>[<INFORMATION_ELEMENT>...]</t>
</list></t>
<t><?rfc subcompact="no" ?>This message is sent by the CPNP client
to update an existing connectivity provisioning agreement. The CPNP
must include the same CUSTOMER_AGREEMENT_IDENTIFIER,
PROVIDER_AGREEMENT_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_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE. <?rfc subcompact="yes"?><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.<?rfc subcompact="no"?></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 align="center"><![CDATA[+------+ +------+
|Client| |Server|
+------+ +------+
|=========UPDATE(Requested 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 the FAIL message is shown below:<?rfc subcompact="yes" ?></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_AGREEMENT_IDENTIFIER></t>
<t><PROVIDER_AGREEMENT_IDENTIFIER></t>
<t><STATUS_CODE></t>
</list></t>
<t><?rfc subcompact="no" ?>This message is sent in the following
cases:<?rfc subcompact="yes"?><list style="symbols">
<t>The server can not honor an order received from the client
(i.e., received in a QUOTATION or UPDATE request).</t>
<t>The server encounters an error when processing a CPNP request
received from the client.</t>
<t>The client can not grant more time to a the server. This is a
response to a more time request conveyed in a PROCESSING
message.</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="format %d">
<t>(Validation Error): The message can not be validated (see
<xref target="validation"></xref>).</t>
<t>(Authentication Required): the request cannot be handled
because authentication is required.</t>
<t>(Authorization Required): the request cannot be handled
because authorization failed.</t>
<t>(Administratively prohibited): the request can not be handled
because of administrative policies.</t>
<t>(Out of Resources): the request can not be honored because
there is not enough capacity.</t>
<t>(Network Presence): the request can not be honored because
there is no network presence.</t>
<t>(More Time Rejected): the request to extend the time
negotiation is rejected by the client.</t>
</list></t>
<t><?rfc subcompact="no"?></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 (QUOTATION 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>QUOTATION</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 provisioning quotation order, the client initiates
first a local quotation order object identified by a unique
identifier assigned by the client. The state of the quotation order
is set to "Created". The client then generates a QUOTATION request
which includes the assigned identifier, possibly an expected
response time, a Transaction-ID and a Requested Connectivity
Provisioning Document. The client may include additional Information
Elements such as Negotiation Options.</t>
<t>The client may be configured to not enforce negotiation checks on
EXPECTED_OFFER_TIME; if so no EXPECTED_RESPONSE_TIME attribute (or
EXPECTED_RESPONSE_TIME set to infinite) should be included in the
quotation order.</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 time as included in
the QUOTATION request. The client also maintains a copy of the
extended transport session details used to generate the QUOTATION
request. The CPNP client must listen on the same port number that it
used to send the QUOTATION request.</t>
<t>If no answer is received from the server before the
retransmission timer expires (i.e., RETRANS_TIMER, <xref
target="timers"></xref>), 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_AGREEMENT_IDENTIFIER information. If the client does not
accept the expected offer time that may have been indicated in the
PROCESSING message, the client may decide to cancel the quotation
order. If the client accepts the EXPECTED_OFFER_TIME, it changes the
state of the order to "ServerProcessing" and sets a timer to the
value of EXPECTED_OFFER_TIME. If no offer is made before the timer
expires, the client changes the state of the order to
"Cancelled".</t>
<t>As a response to a more time request (conveyed in a PROCESSING
message that included a new EXPECTED_OFFER_TIME), the client may
grant this extension by issuing an ACK message or reject the time
extension with a FAIL message having a status code set to "More Time
Rejected".</t>
<t>If an OFFER message matching the extended CPNP session is
received, the client checks if a PROCESSING message having the same
PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If
a PROCESSING message was already received for the same order but the
PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included
in the OFFER message, the client ignores silently the message. If a
PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was
already received and matches the CPNP transaction identifier, the
client changes the state of the order to "OfferReceived" and sets a
timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER
message.</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. 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.</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.</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 QUOTATION message from a client, the server
sets a CPNP session, stores Transaction-ID and generates a Provider
Order Identifier. Once preliminary validation checks are completed (
<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 time to notify the client by when an offer will be
proposed. An order with state "AwaitingProcessing" is created by the
server. The server runs its decision-making process to decide which
offer it can make to honor the received order. The offer should be
made before the expected offer time expires.</t>
<t>If the server cannot make an offer, it sends backs a FAIL message
with the appropriate error code.</t>
<t>If the server requires more negotiation time, it must send a
PROCESSING message with a new EXPECTED_OFFER_TIME. The client may
grant this extension by issuing an ACK message or reject the time
extension with a FAIL message having a status code set to "More Time
Rejected". If the client doesn't grant more time, the server must
answer before the initial expected offer time; otherwise the client
will ignore the quotation order.</t>
<t>If the server can honor the request or it can make an offer that
meet some of the requirements, it creates an OFFER message. The
server must indicate the Transaction-ID, Customer Order Identifier
as indicated in the QUOTATION message, and the Provider Order
Identifier generated for this order. The server must also include
Nonce and the offered Connectivity Provisioning Document. The server
includes an offer validity time as well. Once sent to the client,
the server changes the state of the order to "OfferSent" and a timer
set to the validity time is initiated.</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>).</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 time
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>.<?rfc subcompact="yes"?><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.<?rfc subcompact="no"?></t>
</list></t>
</section>
</section>
<section anchor="sq_nu" 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 anchor="retrans" title="Message Re-Transmission">
<t>If a transaction partner sends out a message and does not receive
any expected reply before the retransmission timer expires (i.e.,
RETRANS_TIMER), a transaction partner will try to re-transit the
messages. An exception is the last message (e.g., ACK) sent from the
server in a transaction. After sending this message, the
retransmission timer will be disabled since no additional feedback is
expected.</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:<?rfc subcompact="yes"?></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<?rfc subcompact="no"?></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 to a legitimate CPNP server. Furthermore, CPNP demands that
messages from the server must include correct identifiers of the orders.
Two order identifiers are used: one generated by the client and a second
one generated by the server.</t>
<t>The Provider must enforce means to protect privacy-related
information included the documents (see <xref target="cpd"></xref>)
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 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 ID attributes provide sufficient
randomness and can effectively tolerate attacks raised by off-line
adversaries, who do not have the capability of eavesdropping and
intercepting the packets transported between the client and the server.
Only authorized clients must be able to modify agreed CPNP orders. The
use of a randomly generated NONCE by the server makes it hard to modify
an agreement on behalf of a malicious third-party.</t>
<t>The sequence numbers included in the CPNP messages can be used to
detect replay attacks and antique packets intercepted from on-going
transactions may be re-sent. However, the protocol in its current
version may be vulnerable to replay attacks where the replayed messages
are intercepted from antique transactions. Although the Transaction ID
provided by the client could protect inter-transaction replay attacks,
no protection is provided for the server to deal with this type of
attack.</t>
<t>The protocol does not provide security mechanisms to protect the
confidentiality and integrity of the packets transported between the
client and the server. An underlying security protocol such as (e.g.,
DTLS <xref target="RFC6347"></xref>, IPsec) could be used to protect the
integrity and confidentiality for the protocol. In this case, if it is
possible to provide an Automated Key Management (AKM) and associate each
transaction with a different key, inter- transaction replay attacks can
naturally be addressed. If the client and the server use a single key,
an additional mechanism should be provided to protect inter-transaction
replay attacks between them.</t>
<t>The deployment option of a Customer Order Management portal operated
by a trusted third-party (see <xref target="dm"></xref>) may facilitate
the efficient resolution of the aforementioned security concerns.</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:<?rfc subcompact="yes"?><list style="format %d:">
<t>QUOTATION</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<?rfc subcompact="no"?></t>
</list></t>
<t>A registry for CPNP errors should be created. The following codes are
reserved:<?rfc subcompact="yes"?><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>
<t>More Time Rejected<?rfc subcompact="no"?></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.RFC.7297'?>
<?rfc include='reference.RFC.7149'?>
<?rfc include='reference.RFC.4026'?>
<?rfc include='reference.RFC.6973'?>
<?rfc include='reference.RFC.6462'?>
<?rfc include='reference.RFC.6770'?>
<?rfc include='reference.RFC.2782'?>
<?rfc include='reference.RFC.6574'?>
<?rfc include='reference.RFC.6793'?>
<?rfc include='reference.RFC.6347'?>
<?rfc include='reference.RFC.6830'?>
<reference anchor="ETICS"
target="https://www.ict-etics.eu/fileadmin/documents/news/ETICS_white_paper_final.pdf">
<front>
<title>Economics and Technologies of Inter-Carrier Services</title>
<author fullname="" surname="">
<organization>EU FP7 ETICS Project</organization>
</author>
<date day="0" month="January" year="2014" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:39:19 |