rfc8921xml2.original.xml   rfc8921.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!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="info"
docName="draft-boucadair-connectivity-provisioning-protocol-22"
ipr="trust200902" updates="">
<front>
<title abbrev="CPNP">Dynamic Service Negotiation</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor" <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
surname="Boucadair">
<organization>Orange</organization>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-boucadair-connectivity-provisioning-protocol-22"
number="8921"
ipr="trust200902"
updates=""
obsoletes=""
submissionType="independent"
category="info"
xml:lang="en"
tocInclude="true"
tocDepth="3"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<front>
<title abbrev="CPNP">Dynamic Service Negotiation: The Connectivity Provision
ing Negotiation Protocol (CPNP)</title>
<seriesInfo name="RFC" value="8921"/>
<author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
ucadair">
<organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Rennes</city> <city>Rennes</city>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet"> <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Rennes</city> <city>Rennes</city>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>christian.jacquenet@orange.com</email> <email>christian.jacquenet@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang"> <author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>dacheng.zhang@huawei.com</email> <email>dacheng.zhang@huawei.com</email>
<uri></uri>
</address> </address>
</author> </author>
<author fullname="Panos Georgatsos" initials="P." surname="Georgatsos"> <author fullname="Panos Georgatsos" initials="P." surname="Georgatsos">
<organization abbrev="CERTH">Centre for Research and Innovation <organization abbrev="CERTH">Centre for Research and Innovation
Hellas</organization> Hellas</organization>
<address> <address>
<postal> <postal>
<street>78, Filikis Etairias str.</street> <street>78, Filikis Etairias str.</street>
<city>Volos</city> <city>Volos</city>
<region>Hellas</region> <region>Hellas</region>
<code>38334</code> <code>38334</code>
<country>Greece</country> <country>Greece</country>
</postal> </postal>
<phone>+302421306070</phone> <phone>+302421306070</phone>
<email>pgeorgat@gmail.com</email> <email>pgeorgat@gmail.com</email>
</address> </address>
</author> </author>
<date month="October" year="2020" />
<date /> <keyword>SDN</keyword>
<keyword>Order Request Handling</keyword>
<keyword>SDN, Order Request Handling, Automation, Dynamic Provisioning, <keyword>Automation</keyword>
CDN, Interconnection, Service Delivery, Service Activation</keyword> <keyword>Dynamic Provisioning</keyword>
<keyword>CDN</keyword>
<keyword>Interconnection</keyword>
<keyword>Service Delivery</keyword>
<keyword>Service Activation</keyword>
<abstract> <abstract>
<t>This document defines the Connectivity Provisioning Negotiation <t>This document defines the Connectivity Provisioning Negotiation
Protocol (CPNP) which is designed to facilitate the dynamic negotiation Protocol (CPNP), which is designed to facilitate the dynamic negotiation
of service parameters.</t> of service parameters.</t>
<t>CPNP is a generic protocol that can be used for various negotiation <t>CPNP is a generic protocol that can be used for various negotiation
purposes that include (but are not necessarily limited to) connectivity purposes that include (but are not necessarily limited to) connectivity
provisioning services, storage facilities, Content Delivery Networks, provisioning services, storage facilities, Content Delivery Networks,
etc.</t> etc.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>This document defines the Connectivity Provisioning Negotiation <t>This document defines the Connectivity Provisioning Negotiation
Protocol (CPNP) that is meant to dynamically exchange and negotiate Protocol (CPNP) that is meant to dynamically exchange and negotiate
connectivity provisioning parameters and other service-specific connectivity provisioning parameters and other service-specific
parameters between a Customer and a Provider. CPNP is a tool that parameters between a Customer and a Provider. CPNP is a tool that
introduces automation in the service negotiation and activation introduces automation to the service negotiation and activation
procedures, thus fostering the overall service provisioning process. procedures, thus fostering the overall service provisioning process.
CPNP can be seen as a component of the dynamic negotiation meta-domain CPNP can be seen as a component of the dynamic negotiation metadomain
described in Section 3.4 of <xref target="RFC7149"></xref>.</t> described in <xref target="RFC7149" sectionFormat="of" section="2.4"/>.</t
>
<t>CPNP is a generic protocol that can be used for other negotiation <t>CPNP is a generic protocol that can be used for negotiation
purposes than connectivity provisioning. For example, CPNP can be used purposes other than connectivity provisioning. For example, CPNP can be us
to request extra storage resources, to extend the footprint of a CDN ed
(Content Delivery Networks), to enable additional features from a cloud to request extra storage resources, to extend the footprint of a
Content Delivery Network (CDN), to enable additional features from a cloud
Provider, etc. CPNP can be extended with new Information Elements (IEs). Provider, etc. CPNP can be extended with new Information Elements (IEs).
Sample negotiation use cases are described in <xref Sample negotiation use cases are described in
target="suc"></xref>. <xref target="opm"></xref> introduces several <xref target="suc" format="default"/>. <xref target="opm" format="default"/> int
order processing models and precises those that are targeted by CPNP. roduces several
The CPNP negotiation model is then detailed in <xref order processing models and defines those that are targeted by CPNP.
target="cnm"></xref>.</t> The CPNP negotiation model is then detailed in <xref target="cnm" format="
default"/>.</t>
<t><xref target="RFC7297"></xref> describes a Connectivity Provisioning <t><xref target="RFC7297" format="default"/> describes a Connectivity Prov
isioning
Profile (CPP) template to capture connectivity requirements to be met by Profile (CPP) template to capture connectivity requirements to be met by
a transport infrastructure for the delivery of various services such as a transport infrastructure for the delivery of various services such as
Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) services Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) services
<xref target="RFC4026"></xref>. The CPP document defines the set of IP <xref target="RFC4026" format="default"/>. The CPP document defines the se t of IP
transfer parameters that reflect the guarantees that can be provided by transfer parameters that reflect the guarantees that can be provided by
the underlying transport network together with reachability scope and the underlying transport network together with reachability scope and
capacity needs. CPNP uses the CPP template to encode connectivity capacity needs. CPNP uses the CPP template to encode connectivity
provisioning clauses that are subject to negotiation. The agreed CPP provisioning clauses that are subject to negotiation. The accepted CPP
will be then passed to other functional elements that are responsible will then be passed to other functional elements that are responsible
for the actual service activation and provisioning. For example, NETCONF for the actual service activation and provisioning. For example,
<xref target="RFC6241"></xref> or RESTCONF <xref Network Configuration Protocol (NETCONF)
target="RFC8040"></xref> can be used to activate adequate network <xref target="RFC6241" format="default"/> or RESTCONF
features that are required to deliver the agreed service. How the <xref target="RFC8040" format="default"/> can be used to activate adequate
network
features that are required to deliver the accepted service. How the
outcome of CPNP negotiation is translated into service and network outcome of CPNP negotiation is translated into service and network
provisioning actions is out of scope of this document.</t> provisioning actions is out of scope of this document.</t>
<t>As a reminder, several proposals have been made in the past by the <t>As a reminder, several proposals have been made in the past by the
(research) community (e.g., COPS-SLS <xref (research) community (e.g., Common Open Policy Service protocol for
target="I-D.nguyen-rap-cops-sls"></xref>, Service Negotiation Protocol supporting Service Level Specification <xref target="I-D.nguyen-rap-cops-s
(SrNP) <xref target="TEQUILA"></xref>, Dynamic Service Negotiation ls" format="default"/>, Service Negotiation Protocol
Protocol (DSNP) <xref target="I-D.itsumo-dsnp"></xref>, Resource <xref target="SrNP" format="default"/>, Dynamic Service Negotiation
Negotiation and Pricing Protocol (RNAP) <xref target="Xin"></xref>, Protocol <xref target="I-D.itsumo-dsnp" format="default"/>, Resource
Service Negotiation and Acquisition Protocol (SNAP) <xref Negotiation and Pricing Protocol <xref target="RNAP" format="default"/>,
target="Karl"></xref>). CPNP leverages the experience of the authors Service Negotiation and Acquisition Protocol <xref target="SNAP" format="d
efault"/>).
CPNP leverages the authors' experience
with SrNP by separating the negotiation primitives from the service with SrNP by separating the negotiation primitives from the service
under negotiation. Moreover, careful examination of the other proposals under negotiation. Moreover, careful examination of the other proposals
revealed certain deficiencies that were easier to address through the revealed certain deficiencies that were easier to address through the
creation of a new protocol rather than modifying existing protocols. For creation of a new protocol rather than the modification of existing protoc
example:<list style="symbols"> ols. For
<t>COPS-SLS relies upon COPS-PR <xref target="RFC3084"></xref>, example:</t>
which is an Historic RFC.</t> <ul spacing="normal">
<li>COPS-SLS relies upon the COPS usage for policy provisioning (COPS-PR
<t>DSNP is tightly designed with one specific service in mind (QoS) ) <xref target="RFC3084" format="default"/>,
which is a Historic RFC.</li>
<li>DSNP is tightly designed with one specific service in mind (QoS)
and does not make any distinction between a quotation phase and the and does not make any distinction between a quotation phase and the
actual service ordering phase.</t> actual service-ordering phase.</li>
</list></t> </ul>
<t>One of the primary motivations of this document is to provide a <t>One of the primary motivations of this document is to provide a
permanent reference to exemplify how service negotiation can be permanent reference to exemplify how service negotiation can be
automated.</t> automated.</t>
<t>Implementation details are out of scope. An example of required <t>Implementation details are out of scope. An example of required
modules and interfaces to implement this specification is sketched in modules and interfaces to implement this specification is sketched in
Section 4 of <xref target="AGAVE"></xref>. This specification builds on Section 4 of <xref target="AGAVE" format="default"/>. This specification b uilds on
that effort.</t> that effort.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>This document makes use of the following terms:<list style="hanging"> <t>This document makes use of the following terms:</t>
<t hangText="Customer:">Is a business role which denotes an entity <dl newline="false" spacing="normal">
<dt>Customer:</dt>
<dd>
<t>Is a business role that denotes an entity
that is involved in the definition and the possible negotiation of that is involved in the definition and the possible negotiation of
an order, including a Connectivity Provisioning Agreement, with a an order, including a Connectivity Provisioning Agreement, with a
Provider. A connectivity provisioning order is captured in a Provider. A connectivity provisioning document is captured in a
dedicated CPP template-based document, which may specify (among dedicated CPP template-based document, which may specify (among
other information): the sites to be connected, border nodes, other information) the sites to be connected, border nodes,
outsourced operations (e.g., routing, force via points). <vspace outsourced operations (e.g., routing, traffic steering). </t>
blankLines="1" />The right to invoke the subscribed service may be <t>The right to invoke the subscribed service may be
delegated by the Customer to third-party End Users, or brokering delegated by the Customer to third-party end users or brokering
services.<vspace blankLines="1" />A Customer can be a Service services.</t>
<t>A Customer can be a Service
Provider, an application owner, an enterprise, a user, etc.</t> Provider, an application owner, an enterprise, a user, etc.</t>
</dd>
<t hangText="Network Provider (or Provider):">Owns and administers <dt>Network Provider (or Provider):</dt>
one or many transport domain(s) (typically Autonomous System (AS)) <dd>
<t>Owns and administers
one or many transport domain(s) (typically Autonomous Systems (ASes))
composed of (IP) switching and transmission resources (e.g., composed of (IP) switching and transmission resources (e.g.,
routing, switching, forwarding, etc.). Network Providers are routing, switching, forwarding, etc.). Network Providers are
responsible for delivering and operating connectivity services responsible for delivering and operating connectivity services
(e.g., offering global or restricted reachability at specific (e.g., offering global or restricted reachability at specific
rates). Offered connectivity services may not necessarily be rates). Offered connectivity services may not necessarily be
restricted to IP. <vspace blankLines="1" />The policies to be restricted to IP. </t>
<t>The policies to be
enforced by the connectivity service delivery components can be enforced by the connectivity service delivery components can be
derived from the technology-specific clauses that might be included derived from the technology-specific clauses that might be included
in agreements with the Customers. If no such clauses are included in in agreements with the Customers. If no such clauses are included in
the agreement, the mapping between the connectivity requirements and the agreement, the mapping between the connectivity requirements and
the underlying technology-specific policies to be enforced is the underlying technology-specific policies to be enforced is
deployment-specific.</t> deployment specific.</t>
</dd>
<t hangText="Quotation Order:">Denotes a request made by the <dt>Quotation Order:</dt>
<dd>Denotes a request made by the
Customer to the Provider that includes a set of requirements. The Customer to the Provider that includes a set of requirements. The
Customer may express its service-specific requirements by assigning Customer may express its service-specific requirements by assigning
(strictly or loosely defined) values to the information items (strictly or loosely defined) values to the information items
included in the commonly understood template (e.g., CPP template) included in the commonly understood template (e.g., CPP template)
describing the offered service. These requirements constitute the describing the offered service. These requirements constitute the
parameters to be mutually agreed upon.</t> parameters to be mutually agreed upon.</dd>
<dt>Offer:</dt>
<t hangText="Offer:">Refers to a response made by the Provider to a <dd>
<t>Refers to a response made by the Provider to a
Customer's quotation order that describes the ability of the Customer's quotation order that describes the ability of the
Provider to satisfy the order at the time of its receipt. Offers Provider to satisfy the order at the time of its receipt. Offers
reflect the capability of the Provider in accommodating received reflect the capability of the Provider in accommodating received
Customer orders beyond monolithic &lsquo;yes/no&rsquo; answers. Customer orders beyond monolithic 'yes/no' answers.
<vspace blankLines="1" />An offer may fully or partially meet the </t>
<t>An offer may fully or partially meet the
requirements of the corresponding order. In the latter case, it may requirements of the corresponding order. In the latter case, it may
include alternative suggestions which the Customer may take into include alternative suggestions that the Customer may take into
account by issuing a new order.</t> account by issuing a new order.</t>
</dd>
<t hangText="Agreement:">Refers to an order placed by the Customer <dt>Agreement:</dt>
<dd>Refers to an order placed by the Customer
and accepted by the Provider. It signals the successful conclusion and accepted by the Provider. It signals the successful conclusion
of a negotiation cycle.</t> of a negotiation cycle.</dd>
</list></t> </dl>
</section> </section>
<section anchor="fe" numbered="true" toc="default">
<section anchor="fe" title="CPNP Functional Elements"> <name>CPNP Functional Elements</name>
<t>The following functional elements are defined:<list style="hanging"> <t>The following functional elements are defined:</t>
<t hangText="CPNP client (or client): ">Denotes a software instance <dl newline="false" spacing="normal">
<dt>CPNP client (or client): </dt>
<dd>
<t>Denotes a software instance
that sends CPNP requests and receives CPNP responses. The current that sends CPNP requests and receives CPNP responses. The current
operations that can be performed by a CPNP client are listed operations that can be performed by a CPNP client are listed
below:<list style="numbers"> below:</t>
<t>Create a quotation order (<xref <ol spacing="normal" type="1">
target="provision"></xref>).</t> <li>Create a quotation order (<xref target="provision" format="defau
lt"/>).</li>
<t>Cancel an ongoing quotation order under negotiation (<xref <li>Cancel an ongoing quotation order under negotiation (<xref targe
target="cancel"></xref>).</t> t="cancel" format="default"/>).</li>
<li>Accept an offer made by a server (<xref target="accept" format="
<t>Accept an offer made by a server (<xref default"/>).</li>
target="accept"></xref>).</t> <li>Withdraw an agreement (<xref target="with" format="default"/>).<
/li>
<t>Withdraw an agreement (<xref target="with"></xref>).</t> <li>Update an agreement (<xref target="upd" format="default"/>).</li
>
<t>Update an agreement (<xref target="upd"></xref>).</t> </ol>
</list></t> </dd>
<dt>CPNP server (or server):</dt>
<t hangText="CPNP server (or server):">Denotes a software instance <dd>
<t>Denotes a software instance
that receives CPNP requests and sends back CPNP responses that receives CPNP requests and sends back CPNP responses
accordingly. The CPNP server is responsible for the following accordingly. The CPNP server is responsible for the following
operations:<list style="numbers"> operations:</t>
<t>Process a quotation order (<xref target="proc"></xref>).</t> <ol spacing="normal" type="1">
<li>Process a quotation order (<xref target="proc" format="default"/
<t>Make an offer (<xref target="offer"></xref>).</t> >).</li>
<li>Make an offer (<xref target="offer" format="default"/>).</li>
<t>Cancel an ongoing quotation order (<xref <li>Cancel an ongoing quotation order (<xref target="sordu" format="
target="sordu"></xref>).</t> default"/>).</li>
<li>Process an order withdrawal (<xref target="sordu" format="defaul
<t>Process an order withdrawal (<xref t"/>).</li>
target="sordu"></xref>).</t> </ol>
</list></t> </dd>
</list></t> </dl>
</section> </section>
<section anchor="opm" numbered="true" toc="default">
<section anchor="opm" title="Order Processing Models"> <name>Order Processing Models</name>
<t>For preparing their service orders, Customers may need to be aware of <t>For preparing their service orders, Customers may need to be aware of
the offered services. Therefore, Providers should first proceed with the the offered services. Therefore, Providers should first proceed with the
announcement (or the exposure) of the services they can provide. The announcement (or the exposure) of the services they can provide. The
service announcement process may take place at designated global or service announcement process may take place at designated global or
Provider-specific service markets, or through explicit interactions with Provider-specific service markets or through explicit interactions with
the Providers. The details of this process are outside the scope of this the Providers. The details of this process are outside the scope of this
document.</t> document.</t>
<t>With or without such service announcement/exposure mechanisms in <t>With or without such service announcement/exposure mechanisms in
place, the following order processing models can be distinguished:</t> place, the following order processing models can be distinguished:</t>
<dl newline="true" spacing="normal">
<t><list style="hanging"> <dt>Frozen model:</dt>
<t hangText="Frozen model:"><vspace blankLines="1" />The Customer <dd>The Customer
cannot actually negotiate the parameters of the service(s) offered cannot actually negotiate the parameters of the service(s) offered
by a Provider. After consulting the Provider's service portfolio, by a Provider. After consulting the Provider's service portfolio,
the Customer selects the service offer he/she wants to subscribe and the Customer selects the service offer to which he or she wants to sub scribe and
places an order to the Provider. Order handling is quite simple on places an order to the Provider. Order handling is quite simple on
the Provider side because the service is not customized as per the Provider side because the service is not customized per
Customer's requirements, but rather pre-designed to address a Customer's requirements, but rather designed to address a
Customer base that shares the same requirements (i.e., these Customer base that shares the same requirements (i.e., these
customers share the same Customer Provisioning Profile). This mode Customers share the same Connectivity Provisioning Profile). This mode
can be implemented using existing tools such as <xref can be implemented using existing tools such as <xref target="RFC8309"
target="RFC8309"></xref>.</t> format="default"/>.</dd>
<dt>Negotiation-based model:</dt>
<t hangText="Negotiation-based model:"><vspace <dd>Unlike the frozen model, the Customer documents
blankLines="1" />Unlike the frozen model, the Customer documents
his/her requirements in a request for a quotation, which is then his/her requirements in a request for a quotation, which is then
sent to one or several Providers. Solicited Providers check whether sent to one or several Providers. Solicited Providers check whether
they can address these requirements or not, and get back to the they can address these requirements or not, and get back to the
Customer accordingly, possibly with an offer that may not exactly Customer accordingly, possibly with an offer that may not exactly
match customer's requirements (e.g., a 100 Mbps connection cannot be match the Customer's requirements (e.g., a 100 Mbps connection cannot be
provisioned given the amount of available resources, but an 80 Mbps provisioned given the amount of available resources, but an 80 Mbps
connection can be provided). A negotiation between the Customer and connection can be provided). A negotiation between the Customer and
the Provider(s) then follows until both parties reach an agreement the Provider(s) then follows until both parties reach an agreement
(or do not).</t> (or do not).</dd>
</list></t> </dl>
<t>Both frozen and negotiation-based models require the existence of <t>Both frozen and negotiation-based models require the existence of
appropriate service templates like a CPP template and their appropriate service templates like a CPP template and their
instantiation for expressing specific offerings from Providers and instantiation for expressing specific offerings from Providers and
service requirements from Customers, respectively. CPNP can be used in service requirements from Customers, respectively. CPNP can be used in
either model for automating the required Customer-Provider interactions. either model for automating the required Customer-Provider interactions.
The frozen model can be seen as a special case of the negotiation-based The frozen model can be seen as a special case of the negotiation-based
model. This document focuses on the negotiation-based model. Not only model. This document focuses on the negotiation-based model. Not only
&lsquo;yes/no&rsquo; answers but also counter-proposals may be offered 'yes/no' answers but also counterproposals may be offered
by the Provider in response to Customer orders.</t> by the Provider in response to Customer orders.</t>
<t>Order processing management on the Network Provider's side usually <t>Order processing management on the Network Provider's side usually
solicits features supported by the following functional blocks: <?rfc subc solicits features supported by the following functional blocks: </t>
ompact="yes"?><list <ul spacing="normal">
style="symbols"> <li>Network provisioning (including order activation, Network
<t>Network Provisioning (including Order Activation, Network Planning, etc.)</li>
Planning, etc.)</t> <li>Authentication, authorization, and accounting (AAA)</li>
<li>Network and service management (performance measurement and
<t>Authentication, Authorization and Accounting (AAA)</t> assessment, fault detection, etc.)</li>
<li>Sales-related functional blocks (e.g., billing, invoice
<t>Network and service management (performance measurement and validation)</li>
assessment, fault detection, etc.)</t> <li>Network impact analysis</li>
</ul>
<t>Sales-related functional blocks (e.g., billing, invoice
validation)</t>
<t>Network Impact Analysis<?rfc subcompact="no"?></t>
</list></t>
<t>CPNP does not assume any specific knowledge about these functional <t>CPNP does not assume any specific knowledge about these functional
blocks, drawing an explicit line between protocol operation and the blocks, drawing an explicit line between protocol operation and the
logic for handling connectivity provisioning requests. An order logic for handling connectivity provisioning requests. An order
processing logic is typically fed with the information manipulated by processing logic is typically fed with the information manipulated by
the aforementioned functional blocks. For example, the resources that the aforementioned functional blocks. For example, the resources that
can be allocated to accommodate Customer's requirements may depend on can be allocated to accommodate the Customer's requirements may depend on
network availability estimates as calculated by the planning functions network availability estimates as calculated by the planning functions
and related policies, as well as the number of orders to be processed and related policies, as well as the number of orders to be processed
simultaneously over a given period of time.</t> simultaneously over a given period of time.</t>
<t>This document does not elaborate on how Customers are identified and <t>This document does not elaborate on how Customers are identified and
subsequently managed by the Provider's Information System.</t> subsequently managed by the Provider's information system.</t>
</section> </section>
<section anchor="suc" numbered="true" toc="default">
<section anchor="suc" title="Sample Use Cases "> <name>Sample Use Cases</name>
<t>A non-exhaustive list of CPNP use cases is provided below:<list <t>A non-exhaustive list of CPNP use cases is provided below:</t>
style="numbers"> <ol spacing="normal" type="1">
<t><xref target="RFC4176"></xref> introduces the Layer 3 VPN (L3VPN) <li>
Service Order Management functional block which is responsible for <t><xref target="RFC4176" format="default"/> introduces the Layer 3 VP
N (L3VPN)
Service Order Management functional block, which is responsible for
managing the requests initiated by the Customers and tracks the managing the requests initiated by the Customers and tracks the
status of the completion of the related operations. CPNP can be used status of the completion of the related operations. CPNP can be used
between the Customer and the Provider to negotiate L3VPN service between the Customer and the Provider to negotiate L3VPN service
parameters. <vspace blankLines="1" />A CPNP server could therefore parameters. </t>
<t>A CPNP server could therefore
be part of the L3VPN Service Order Management functional block be part of the L3VPN Service Order Management functional block
discussed in <xref target="RFC4176"></xref>. A L3VPN Service YANG discussed in <xref target="RFC4176" format="default"/>. A L3VPN Servic
data Model (L3SM) is defined in <xref target="RFC8299"></xref>. Once e YANG
data model (L3SM) is defined in <xref target="RFC8299" format="default
"/>. Once
an agreement is reached, the service can be provisioned using, e.g., an agreement is reached, the service can be provisioned using, e.g.,
the L3VPN Network YANG Model specified in <xref the L3VPN Network YANG data model specified in <xref target="I-D.ietf-
target="I-D.ietf-opsawg-l3sm-l3nm"></xref>.<vspace opsawg-l3sm-l3nm" format="default"/>.</t>
blankLines="1" />Likewise, A CPNP server could be part of the Layer <t>Likewise, a CPNP server could be part of the Layer
2 VPN (L2VPN) Service Order Management functional block. A YANG data 2 VPN (L2VPN) Service Order Management functional block. A YANG data
model for L2VPN service delivery is defined in <xref model for L2VPN service delivery is defined in <xref target="RFC8466"
target="RFC8466"></xref>. Once an agreement is reached, the L2VPN format="default"/>. Once an agreement is reached, the L2VPN
service can be provisioned using, e.g., the L2VPN Network YANG Model service can be provisioned using, e.g., the L2VPN Network YANG data mo
specified in <xref del
target="I-D.barguil-opsawg-l2sm-l2nm"></xref>.</t> specified in <xref target="I-D.ietf-opsawg-l2nm" format="default"/>.</
t>
</li>
<li>
<t>CPNP can be used between two adjacent domains to deliver IP <t>CPNP can be used between two adjacent domains to deliver IP
interconnection services (e.g., enable, update, disconnect). For interconnection services (e.g., enable, update, disconnect). For
example, two Autonomous Systems (ASes) can be connected via several example, two Autonomous Systems (ASes) can be connected via several
interconnection points. CPNP can be used between these ASes to interconnection points. CPNP can be used between these ASes to
upgrade existing links, request additional resources, provision a upgrade existing links, request additional resources, provision a
new interconnection point, etc. <vspace blankLines="1" />See, for new interconnection point, etc. </t>
example, the framework documented in <xref <t>See, for
target="ETICS"></xref>.</t> example, the framework documented in <xref target="ETICS" format="defa
ult"/>.</t>
<t>An integrated Provider can use CPNP to rationalize connectivity </li>
<li>An integrated Provider can use CPNP to rationalize connectivity
provisioning needs related to its service portfolio. A CPNP server provisioning needs related to its service portfolio. A CPNP server
function is used by network operations teams. A CPNP interface to function is used by network operations teams. A CPNP interface to
trigger CPNP negotiation cycles is exposed to service management trigger CPNP negotiation cycles is exposed to service management
teams.</t> teams.</li>
<li>
<t>Service Providers can use CPNP to initiate connectivity <t>Service Providers can use CPNP to initiate connectivity
provisioning requests towards a number of Network Providers so as to provisioning requests towards a number of Network Providers so as to
optimize the cost of delivering their services. Although multiple optimize the cost of delivering their services. Although multiple
CPNP ordering cycles can be initiated by a Service Provider towards CPNP ordering cycles can be initiated by a Service Provider towards
multiple Network Providers, a subset of these orders may actually be multiple Network Providers, a subset of these orders may actually be
put into effect.<vspace blankLines="1" />For example, a cloud put into effect.</t>
<t>For example, a cloud
Service Provider can use CPNP to request more resources from Network Service Provider can use CPNP to request more resources from Network
Providers.</t> Providers.</t>
</li>
<t>CPNP can also be used in the context of network slicing (<xref <li>CPNP can also be used in the context of network slicing
target="I-D.geng-netslices-architecture"></xref>) to request network <xref target="I-D.geng-netslices-architecture" format="default"/> to r
equest network
resources together with a set of requirements that need to be resources together with a set of requirements that need to be
satisfied by the Provider. Such requirements are not restricted to satisfied by the Provider. Such requirements are not restricted to
basic IP forwarding capabilities, but may also include a basic IP forwarding capabilities, but may also include a
characterization of a set of service functions that may be invoked. characterization of a set of service functions that may be invoked.
For the network slicing case, the instances of a CPP template could For the network slicing case, the instances of a CPP template could
be derived from the network slice templates inputs as documented in be derived from the network slice template documented in
<xref target="I-D.contreras-teas-slice-nbi"></xref>.</t> <xref target="I-D.contreras-teas-slice-nbi" format="default"/>.</li>
<li>
<t>CPNP can be used in Machine-to-Machine (M2M) environments to <t>CPNP can be used in Machine-to-Machine (M2M) environments to
dynamically subscribe to M2M services (e.g., access to data dynamically subscribe to M2M services (e.g., access data
retrieved by a set of sensors, extend sensor coverage, etc.).<vspace retrieved by a set of sensors, extend sensor coverage, etc.).</t>
blankLines="1" />Also, Internet of Things (IoT, <xref <t>Also, Internet of Things (IoT) <xref target="RFC6574" format="defau
target="RFC6574"></xref>) domains may rely on CPNP to enable dynamic lt"/>
domains may rely on CPNP to enable dynamic
access to data produced by involved objects, according to their access to data produced by involved objects, according to their
specific policies, to various external stakeholders such as data specific policies, to various external stakeholders such as data
analytics and business intelligence companies. Direct CPNP-based analytics and business intelligence companies. Direct CPNP-based
interactions between IoT domains and interested parties enable open interactions between IoT domains and interested parties enable open
access to diverse sets of data across the Internet, e.g., from access to diverse sets of data across the Internet, e.g., from
multiple types of sensors, user groups and/or geographical multiple types of sensors, user groups, and/or geographical
areas.</t> areas.</t>
</li>
<t>CPNP can be used in the context of I2NSF (<xref <li>CPNP can be used in the context of Interface to Network Security Func
target="RFC8329"></xref>) to capture the customer-driven policies to tions
be enforced by a set of Network Security Functions.</t> (I2NSF) <xref target="RFC8329" format="default"/>
to capture the Customer-driven policies to
be enforced by a set of Network Security Functions.</li>
<li>
<t>A Provider offering cloud services can expose a CPNP interface to <t>A Provider offering cloud services can expose a CPNP interface to
allow Customers to dynamically negotiate typical data center allow Customers to dynamically negotiate typical data center
resources, such as additional storage, processing and networking resources, such as additional storage, processing and networking
resources, enhanced security filters, etc.<vspace resources, enhanced security filters, etc.</t>
blankLines="1" />Cloud computing providers typically structure their <t>Cloud computing Providers typically structure their
computation service offerings by bundling CPU, RAM, and storage computation service offerings by bundling CPU, RAM, and storage
units as quotas, instances, or flavors that can be consumed in an units as quotas, instances, or flavors that can be consumed in an
ephemeral or temporal fashion during the lifetime of the required ephemeral or temporal fashion during the lifetime of the required
function. A similar approach is followed by CPNP (see for example, function. A similar approach is followed by CPNP (see for example,
<xref target="activate"></xref>).</t> <xref target="activate" format="default"/>).</t>
</li>
<t>In the inter-cloud context (also called cloud of clouds or cloud <li>In the inter-cloud context (also called cloud of clouds or cloud
federation), CPNP can be used to reserve computing and networking federation), CPNP can be used to reserve computing and networking
resources hosted by various cloud infrastructures.</t> resources hosted by various cloud infrastructures.</li>
<li>
<t>CDN Providers can use CPNP to extend their footprint by <t>CDN Providers can use CPNP to extend their footprint by
interconnecting their respective CDN infrastructures <xref interconnecting their respective CDN infrastructures <xref target="RFC
target="RFC6770"></xref> (see <xref target="cdni"></xref>).<vspace 6770" format="default"/> (see <xref target="cdni" format="default"/>).</t>
blankLines="1" /><figure align="center" anchor="cdni" <figure anchor="cdni">
title="CDN Interconnection"> <name>CDN Interconnection</name>
<artwork align="center"><![CDATA[ ,--,--,--. ,-- <artwork align="center" name="" type="" alt=""><![CDATA[
,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B') (CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-' `-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--']]></artwork> `--'--'--' `--'--'--'
</figure></t> ]]></artwork>
</figure>
<t>Mapping Service Providers (MSPs, <xref target="RFC7215"></xref>) </li>
<li>
<t>Mapping Service Providers (MSPs) <xref target="RFC7215" format="def
ault"/>
can use CPNP to enrich their mapping database by interconnecting can use CPNP to enrich their mapping database by interconnecting
their mapping system (see <xref target="map"></xref>). This their mapping system (see <xref target="map" format="default"/>). This
interconnection allows to relax the constraints on PxTR (Proxy interconnection allows the relaxation of the constraints on PxTR (Prox
y
Ingress/Egress Tunnel Router) in favour of native LISP (Locator/ID Ingress/Egress Tunnel Router) in favour of native LISP (Locator/ID
Separation Protocol) forwarding <xref target="RFC6830"></xref>. Separation Protocol) forwarding <xref target="RFC6830" format="default "/>.
Also, it prevents the fragmentation of the LISP mapping database. A Also, it prevents the fragmentation of the LISP mapping database. A
framework is described in <xref framework is described in <xref target="I-D.boucadair-lisp-idr-ms-disc
target="I-D.boucadair-lisp-idr-ms-discovery"></xref>.<vspace overy" format="default"/>.</t>
blankLines="1" /><figure align="center" anchor="map" <figure anchor="map">
title="LISP Mapping System Interconnect"> <name>LISP Mapping System Interconnect</name>
<artwork align="center"><![CDATA[ ,--,--,--. ,-- <artwork align="center" name="" type="" alt=""><![CDATA[
,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
(Mapping System 'A')===(Mapping System 'B') (Mapping System 'A')===(Mapping System 'B')
`-. ,-' `-. ,-' `-. ,-' `-. ,-'
`--'--'--' `--'--'--']]></artwork> `--'--'--' `--'--'--'
</figure></t> ]]></artwork>
</figure>
<t>CPNP may also be used between SDN (Software-Defined Networking) </li>
<li>CPNP may also be used between SDN (Software-Defined Networking)
controllers in contexts where Cooperating Layered Architecture for controllers in contexts where Cooperating Layered Architecture for
Software-Defined Networking (CLAS) is enabled <xref Software-Defined Networking (CLAS) is enabled <xref target="RFC8597" f
target="RFC8597"></xref>.</t> ormat="default"/>.</li>
</list></t> </ol>
</section> </section>
<section anchor="dm" numbered="true" toc="default">
<section anchor="dm" title="CPNP Deployment Models"> <name>CPNP Deployment Models</name>
<t>Several CPNP deployment models can be envisaged. Two examples are <t>Several CPNP deployment models can be envisaged. Two examples are
listed below:<?rfc subcompact="yes"?><list style="symbols"> listed below:</t>
<t>The Customer deploys a CPNP client while one or several CPNP <ul spacing="normal">
<li>The Customer deploys a CPNP client while one or several CPNP
servers are deployed by the Provider. A CPNP client can discover its servers are deployed by the Provider. A CPNP client can discover its
CPNP servers using a variety of means (static, dynamic, etc.).</t> CPNP servers using a variety of means (static, dynamic, etc.).</li>
<li>The Customer does not enable any CPNP client. The Provider
<t>The Customer does not enable any CPNP client. The Provider
maintains a Customer Order Management portal. The Customer can maintains a Customer Order Management portal. The Customer can
initiate connectivity provisioning quotation orders via the portal; initiate connectivity provisioning quotation orders via the portal;
appropriate CPNP messages are then generated and sent to the appropriate CPNP messages are then generated and sent to the
relevant CPNP server. In this model, both the CPNP client and CPNP relevant CPNP server. In this model, both the CPNP client and CPNP
server are under the responsibility of the same administrative server are under the responsibility of the same administrative
entity (i.e., Network Provider).<?rfc subcompact="no"?></t> entity (i.e., Network Provider).</li>
</list></t> </ul>
<t>Once the negotiation of connectivity provisioning parameters is <t>Once the negotiation of connectivity provisioning parameters is
successfully concluded, that is, an order has been placed by the successfully concluded, that is, an order has been placed by the
Customer, the actual network provisioning operations are initiated. The Customer, the actual network provisioning operations are initiated. The
specification of related dynamic resource allocation and policy specification of related dynamic resource allocation and policy
enforcement schemes, as well as how CPNP servers interact with the enforcement schemes, as well as how CPNP servers interact with the
network provisioning functional blocks at Provider sides are out of the network provisioning functional blocks on the Provider side, are out of th e
scope of this document.</t> scope of this document.</t>
<t>This document does not make any assumptions about the CPNP deployment
<t>This document does not make any assumption about the CPNP deployment
model either.</t> model either.</t>
</section> </section>
<section anchor="cnm" numbered="true" toc="default">
<section anchor="cnm" title="CPNP Negotiation Model"> <name>CPNP Negotiation Model</name>
<t>CPNP runs between a Customer and a Provider carrying service orders <t>CPNP runs between a Customer and a Provider, carrying service orders
from the Customer and corresponding responses from the Provider to the from the Customer and corresponding responses from the Provider in
end of reaching a service provisioning agreement. As the services order to reach a service provisioning agreement. As the services
offered by the Provider are well-described, by means of the CPP template offered by the Provider are well described, by means of the CPP template
for connectivity matters, the negotiation process is essentially a for connectivity matters, the negotiation process is essentially a
value-settlement process, where an agreement is pursued on the values of value-settlement process, where an agreement is pursued on the values of
the commonly understood information items (service parameters) included the commonly understood information items (service parameters) included
in the service description template (<xref in the service description template (<xref target="service_template" forma
target="service_template"></xref>).</t> t="default"/>).</t>
<t>The content that CPNP carries and the negotiation logic invoked
<t>The protocol is transparent to the content that it carries and to the at Customer and Provider sides to manipulate the content (i.e.,
negotiation logic invoked at Customer and Provider sides, and which the information carried in CPNP messages to proceed with the
manipulates the content (i.e., the information carried in CPNP messages negotiation) is transparent to the protocol. </t>
to proceed with the negotiation).</t> <t>The protocol aims to facilitate the execution of the negotiation
<t>The protocol aims at facilitating the execution of the negotiation
logic by providing the required generic communication primitives.</t> logic by providing the required generic communication primitives.</t>
<t>Since negotiations are initiated and primarily driven by the <t>Since negotiations are initiated and primarily driven by the
Customer's negotiation logic, it is reasonable to assume that the Customer's negotiation logic, it is reasonable to assume that the
Customer is the only party that can call for an agreement. An implicit Customer is the only party that can call for an agreement. An implicit
approach is adopted for not overloading the protocol with additional approach is adopted for not overloading the protocol with additional
messages. In particular, the acceptance of an offer made by the Provider 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 signals a call for agreement from the Customer. Note that it is almost
certain the Provider will accept this call since it refers to an offer certain the Provider will accept this call since it refers to an offer
that itself made. Of course, at any point the Provider or the Customer that the Provider made. Of course, at any point the Provider or the Custom er
may quit the negotiations, each on its own grounds.</t> may quit the negotiations, each on its own grounds.</t>
<t>Based on the above, CPNP adopts a quotation order/offer/answer model,
<t>Based on the above, CPNP adopts a Quotation Order/Offer/Answer model, which proceeds through the following basic steps (<xref target="service_va
which proceeds through the following basic steps (<xref riants" format="default"/>):</t>
target="service_variants"></xref>):</t> <ol spacing="normal" type="1">
<li>The CPNP client specifies its service requirements in a
<t><list style="numbers"> Provisioning Quotation Order (PQO). The order may include strictly or
<t>The CPNP client specifies its service requirements via a
Provision Quotation Order (PQO). The order may include strictly or
loosely defined values in the clauses describing service loosely defined values in the clauses describing service
provisioning characteristics.</t> provisioning characteristics.</li>
<li>The CPNP server declines the PQO, or makes an offer to address
<t>The CPNP server declines the PQO, or makes an offer to address the requirements of the PQO, or suggests a counterproposal that
the requirements of the PQO, or suggests a counter-proposal that
partially addresses the requirements of the PQO in case specific partially addresses the requirements of the PQO in case specific
requirements cannot be accommodated.</t> requirements cannot be accommodated.</li>
<li>The CPNP client either accepts or declines the offer. The acceptance
<t>The CPNP client either accepts or declines the offer. Accepting of the offer by the CPNP client implies a call for
the offer by the CPNP client implies a call for agreement; thus the agreement and, thus, the
agreement between both parties and the conclusion of the agreement between both parties and the conclusion of the
negotiation.</t> negotiation.</li>
</list></t> </ol>
<figure anchor="service_variants">
<t><figure align="center" anchor="service_variants" <name>Simplified Service Negotiation</name>
title="Simplified Service Negotiation"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------+ +------+ +------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=====Requested Service=====>| |=====Requested Service=====>|
|<=====Offered Service=======| |<=====Offered Service=======|
|======Agreed Service=======>| |=====Accepted Service======>|
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Multiple instances of CPNP may run at a Customer's or a Provider's
<t>Multiple instances of CPNP may run at Customer's or Provider's
domains. A CPNP client may be engaged in multiple, simultaneous domains. A CPNP client may be engaged in multiple, simultaneous
negotiations with the same or different CPNP servers (parallel negotiations with the same or different CPNP servers (parallel
negotiations, see <xref target="mser"></xref>) and a CPNP server may negotiations, see <xref target="mser" format="default"/>), and a CPNP serv er may
need to negotiate with other Provider(s) as part of negotiations that need to negotiate with other Provider(s) as part of negotiations that
are ongoing with a CPNP client (cascaded negotiations, see <xref are ongoing with a CPNP client (cascaded negotiations, see <xref target="c
target="cascaded"></xref>).</t> ascaded" format="default"/>).</t>
<t>CPNP relies on various timers to run its operations. Two types of <t>CPNP relies on various timers to run its operations. Two types of
timers are defined: those that are specific to CPNP message transmission timers are defined: those that are specific to CPNP message transmission
and those that are specific to the negotiation logic. The latter are and those that are specific to the negotiation logic. The latter are
used to guide the negotiation logic at both CPNP client and CPNP server used to guide the negotiation logic at both CPNP client and CPNP server
sides, particularly in cases where the CPNP client is involved in sides, particularly in cases where the CPNP client is involved in
parallel negotiations with several CPNP servers or in cases where the parallel negotiations with several CPNP servers or in cases where the
CPNP server is in turn involved in negotiations with other Providers for CPNP server is, in turn, involved in negotiations with other Providers for
processing a given customer-originated quotation order. CPNP allows a processing a given Customer-originated quotation order. CPNP allows a
CPNP server to request an extra time to proceed with the negotiation. CPNP server to request extra time to proceed with the negotiation.
This request may be accepted or rejected by the CPNP client.</t> This request may be accepted or rejected by the CPNP client.</t>
<t>Providers may need to publish available services to the Customers <t>Providers may need to publish available services to the Customers
(see <xref target="opm"></xref>). CPNP may optionally support this (see <xref target="opm" format="default"/>). CPNP may optionally support t his
functionality. Dedicated templates can be defined for the purpose of functionality. Dedicated templates can be defined for the purpose of
service announcement, which will be used by the CPNP clients to initiate service announcement, which will be used by the CPNP clients to initiate
their CPNP negotiation cycles.</t> their CPNP negotiation cycles.</t>
<t>For the sake of simplicity, a single offer/answer stage is assumed
<t>For the sake of simplicity, a single Offer/Answer stage is assumed
within one CPNP negotiation cycle. Nevertheless, as already stated, within one CPNP negotiation cycle. Nevertheless, as already stated,
multiple CPNP negotiation cycles can be undertaken by a CPNP client (see multiple CPNP negotiation cycles can be undertaken by a CPNP client (see
<xref target="examples"></xref>).</t> <xref target="examples" format="default"/>).</t>
<t>The model is flexible enough to accommodate changing conditions <t>The model is flexible enough to accommodate changing conditions
during the lifetime of a service (e.g., introduction of an additional during the lifetime of a service (e.g., the introduction of an additional
VPN site).</t> VPN site).</t>
<figure anchor="examples">
<t><figure align="center" anchor="examples" <name>Overall Negotiation Process</name>
title="Overall Negotiation Process"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------+ +------+ +- +------+ +------+ +------+ +------+
-----+ +------+
|Client| |Server| |Client| |Server| |Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|=====Quotation Order=====>| |=====Quotation Order=====>| |=====Quotation Order=====>| |=====Quotation Order=====>|
|<==========Offer==========| |<==========Offer==========| |<==========Offer==========| |<==========Offer==========|
|===========Accept========>| |==========Decline========>| |===========Accept========>| |==========Decline========>|
1-Step Successful Negotiation 1-Step Failed Negotiation 1-Step Successful Negotiation 1-Step Failed Negotiation
Cycle Cycle Cycle Cycle
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
skipping to change at line 644 skipping to change at line 585
|===========Accept========>| |==========Decline========>| |===========Accept========>| |==========Decline========>|
|===Quotation Order(k)====>| |===Quotation Order(k)====>|
|<==========Offer==========| |<==========Offer==========|
|==========Decline========>| |==========Decline========>|
|===Quotation Order(l)====>| |===Quotation Order(l)====>|
|<==Fail to make an offer==| |<==Fail to make an offer==|
N-Step Negotiation Cycle: N-Step Negotiation Cycle: N-Step Negotiation Cycle: N-Step Negotiation Cycle:
Successful Negotiation Failed Negotiation Successful Negotiation Failed Negotiation
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The means used by a CPNP client to retrieve a list of active/accepted
<t>Means used by a CPNP client to retrieve a list of active/agreed
offers are not defined in this document.</t> offers are not defined in this document.</t>
<t>An order can be implicitly or explicitly activated.
<t>An order can be implicitly or explicitly activated. Section 3.11 of <xref target="RFC7297" sectionFormat="of" section="3.11"/> specifies a ded
<xref target="RFC7297"></xref> specifies a dedicated clause called icated clause called
Activation Means. Such clause indicates the required action(s) to be Activation Means. Such a clause indicates the required action(s) to be
undertaken to activate access to the (IP connectivity) service. This undertaken to activate access to the (IP connectivity) service. This
document defines a dedicated CPNP message that can be used for explicit document defines a dedicated CPNP message that can be used for explicit
activation (<xref target="activate"></xref>)).</t> activation (<xref target="activate" format="default"/>).</t>
</section> </section>
<section anchor="po" numbered="true" toc="default">
<section anchor="po" title="Protocol Overview"> <name>Protocol Overview</name>
<t></t> <section numbered="true" toc="default">
<name>Client/Server Communication</name>
<section title="Client/Server Communication">
<t>CPNP is a client/server protocol that can run over any transport <t>CPNP is a client/server protocol that can run over any transport
protocol. Yet, UDP is the default transport mode secured with Datagram protocol. The default transport mode is UDP secured with Datagram
Transport Layer Security (DTLS) <xref target="RFC6347"></xref>. No Transport Layer Security (DTLS) <xref target="RFC6347" format="default"/
>. No
permanent CPNP transport session needs to be maintained between the permanent CPNP transport session needs to be maintained between the
client and the server.</t> client and the server.</t>
<t>The CPNP client can be configured with the CPNP server(s). <t>The CPNP client can be configured with the CPNP server(s).
Typically, an IP address together with a port number are configured to Typically, the CPNP client is configured with an IP address together
the CPNP client, based upon manual or dynamic configuration means with a port number using manual or dynamic configuration means
(e.g., DHCP). Alternatively, a Provider may advertise the port number (e.g., DHCP). Alternatively, a Provider may advertise the port number
(CPNP_PORT) it uses to bind the CPNP service using SRV <xref (CPNP_PORT) it uses to bind the CPNP service using SRV <xref target="RFC
target="RFC2782"></xref>.</t> 2782" format="default"/>.</t>
<t>The CPNP client may be provided with a domain name of the CPNP <t>The CPNP client may be provided with a domain name of the CPNP
server for PKIX-based authentication purposes. CPNP servers should server for PKIX-based authentication purposes. CPNP servers should
prefer the use of DNS-ID and SRV-ID over CN-ID identifier types in prefer the use of DNS-ID and SRV-ID over CN-ID identifier types in
certificate requests (Section 2.3 of <xref target="RFC6125"></xref>). certificate requests (<xref target="RFC6125"
sectionFormat="of" section="2.3"/>).
URI-IDs should not be used for CPNP server identity verification.</t> URI-IDs should not be used for CPNP server identity verification.</t>
<t>The client sends CPNP requests using CPNP_PORT as the destination <t>The client sends CPNP requests using CPNP_PORT as the destination
port number. The same port number used as the source port number of a port number. The same port number used as the source port number of a
CPNP request sent to a CPNP server is used by the server to reply to CPNP request sent to a CPNP server is used by the server to reply to
that request.</t> that request.</t>
<t>CPNP is independent of the IP address family.</t> <t>CPNP is independent of the IP address family.</t>
<t>CPNP retransmission for unreliable transports is discussed in
<t>CPNP retransmission is discussed in <xref target="retrans"></xref> <xref target="retrans" format="default"/>.</t>
for unreliable transports.</t>
<t>Considerations related to mutual authentication are discussed in <t>Considerations related to mutual authentication are discussed in
<xref target="Security"></xref>.</t> <xref target="Security" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Policy Configuration on the CPNP Server"> <name>Policy Configuration on the CPNP Server</name>
<t>As an input to its decision-making process, the CPNP server may be <t>As an input to its decision-making process, the CPNP server may be
connected to various external modules such as: Customer Profiles, connected to various external modules such as Customer Profiles,
Network Topology, Network Resource Management, Order Repositories, Network Topology, Network Resource Management, Order Repositories,
AAA, and Network Provisioning Manager (an example is shown in <xref AAA, and Network Provisioning Manager (an example is shown in <xref targ
target="fb"></xref>).</t> et="fb" format="default"/>).</t>
<t>These external modules provide inputs to the CPNP server so that
<t>These external modules provide inputs to the CPNP server, so that it can do the following:</t>
it can:<list style="symbols"> <ul spacing="normal">
<t>Check whether a customer is entitled to initiate a provisioning <li>Check whether a Customer is entitled to initiate a provisioning
quotation request.</t> quotation request.</li>
<li>Check whether a Customer is entitled to cancel an ongoing
<t>Check whether a customer is entitled to cancel an ongoing order.</li>
order.</t> <li>Check whether administrative data (e.g., billing-related
<t>Check whether administrative data (e.g., billing-related
information) have been verified before the processing of the information) have been verified before the processing of the
request starts.</t> request starts.</li>
<li>Check whether network capacity is available or additional
<t>Check whether network capacity is available or additional capacity is required.</li>
capacity is required.</t> <li>Receive guidelines from network design and sales blocks (e.g.,
<t>Receive guidelines from network design and sales blocks (e.g.,
pricing, network usage levels, thresholds associated with the pricing, network usage levels, thresholds associated with the
number of CPP templates that can be processed over a given period 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 of time as a function of the nature of the service to be
delivered, etc.).</t> delivered, etc.).</li>
<li>Transfer completed orders to network provisioning blocks
<t>Transfer completed orders to network provisioning blocks (referred to as "Network Provisioning Manager" in <xref target="fb"
(referred to as "Network Provisioning Manager" in <xref format="default"/>). For example, the outcome of CPNP may be
target="fb"></xref>). For example, the outcome of CPNP may be
passed to modules such as Application-Based Network Operations passed to modules such as Application-Based Network Operations
(ABNO) <xref target="RFC7491"></xref> or network controllers. (ABNO) <xref target="RFC7491" format="default"/> or network controll
These controllers will use protocols such as NETCONF <xref ers.
target="RFC6241"></xref> to interact with the appropriate network These controllers will use protocols such as NETCONF <xref target="R
FC6241" format="default"/> to interact with the appropriate network
nodes and functions for the sake of proper service activation and nodes and functions for the sake of proper service activation and
delivery. <?rfc subcompact="no"?></t> delivery. </li>
</list>The above list of CPNP server operations is not </ul>
<t>The above list of CPNP server operations is not
exhaustive.</t> exhaustive.</t>
<figure anchor="fb">
<t><figure align="center" anchor="fb" <name>Order Handling Management Functional Block (Focus on Internal In
title="Order Handling Management Functional Block (Focus on Internal terfaces)</name>
Interfaces)"> <artwork align="center" name="" type="" alt=""><![CDATA[ . . . .
<artwork align="center"><![CDATA[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
.Business & Administrative Management . .Business & Administrative Management .
.+------------------------++---------------------------+. .+------------------------++---------------------------+.
.| Business Guidelines || Billing & Charging |. .| Business Guidelines || Billing & Charging |.
.+-----------+------------++-----------+---------------+. .+-----------+------------++-----------+---------------+.
. | | . . | | .
. +-------------------+ | . . +-------------------+ | .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . . . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
.Order Handling Management | | . .Order Handling Management | | .
. +-------------------+ +-------+-----+--------------+ . . +-------------------+ +-------+-----+--------------+ .
skipping to change at line 766 skipping to change at line 690
. | Network +------------+ | | | +--------+ . . | Network +------------+ | | | +--------+ .
. | Resource | +------------+-+ | +-+----------+ . . | Resource | +------------+-+ | +-+----------+ .
. | Management | | Customer | | | Orders | . . | Management | | Customer | | | Orders | .
. | | | Profiles | | | Repository | . . | | | Profiles | | | Repository | .
. +-----------------+ +--------------+ | +------------+ . . +-----------------+ +--------------+ | +------------+ .
. . . . . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . . . . . . . . . . . . . . . . .|. . . . . . . . .
+--------------------------------------+----------------+ +--------------------------------------+----------------+
| Network Provisioning Manager | | Network Provisioning Manager |
+-------------------------------------------------------+ +-------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The following order-handling modes can also be configured on the
<t><?rfc subcompact="no"?></t> server:</t>
<dl spacing="normal">
<t>The following order handling modes can also be configured on the <dt>Fully automated mode:</dt><dd>This mode does not require any actio
server:<list style="numbers"> n
<t>Fully automated mode: This mode does not require any action
from the administrator when receiving a request for a service. The from the administrator when receiving a request for a service. The
server can execute its decision-making process related to the server can execute its decision-making process related to the
orders received and generate corresponding offers.</t> orders received and can generate corresponding offers.</dd>
<dt>Administrative validation checking:</dt><dd>Some or all of the ser
<t>Administrative validation checking: Some or all of the server's ver's
operations are subject to administrative validation procedures. operations are subject to administrative validation procedures.
This mode requires an action from the administrator for every This mode requires an action from the administrator for every
request received. To that aim, the CPNP methods which can be request received. To that aim, the CPNP methods that can be
automatically handled by the server (or are subject to one or automatically handled by the server (or are subject to one or
several validation administrative checks) can be configured on the several validation administrative checks) can be configured on the
server.</t> server.</dd>
</list></t> </dl>
</section> </section>
<section anchor="session" numbered="true" toc="default">
<section anchor="session" title="CPNP Session Entries"> <name>CPNP Session Entries</name>
<t>A CPNP session entry is denoted by a tuple defined as follows:<list <t>A CPNP session entry is represented by a tuple defined as follows:</t
style="symbols"> >
<t>Transport session (typically, IP address of the CPNP client, <ul spacing="normal">
client's port number, IP address of the CPNP server, and CPNP <li>Transport session (typically, the IP address of the CPNP client,
server's port number).</t> the client's port number, the IP address of the CPNP server, and the
CPNP
<t>Incremented Sequence Number (<xref target="sq_nu"></xref>)</t> server's port number).</li>
<li>Incremented sequence number (<xref target="sq_nu" format="default"
<t>Customer Agreement Identifier: This is a unique identifier />).</li>
assigned to the order under negotiation by the CPNP client (<xref <li>Customer agreement identifier: This is a unique identifier
target="cu_id"></xref>). This identifier is also used by the assigned to the order under negotiation by the CPNP client (<xref ta
rget="cu_id" format="default"/>). This identifier is also used by the
client to identify the agreement that will result from a client to identify the agreement that will result from a
successful negotiation.</t> successful negotiation.</li>
<li>Provider agreement identifier: This is a unique identifier
<t>Provider Agreement Identifier: This is a unique identifier assigned to the order under negotiation by the CPNP server (<xref ta
assigned to the order under negotiation by the CPNP server (<xref rget="pr_id" format="default"/>). This identifier is also used by the
target="pr_id"></xref>). This identifier is also used by the
server to identify the agreement that will result from a server to identify the agreement that will result from a
successful negotiation.</t> successful negotiation.</li>
<li>Transaction-ID (<xref target="trans" format="default"/>).</li>
<t>Transaction-ID (<xref target="trans"></xref>).</t> </ul>
</list></t>
</section> </section>
<section anchor="trans" numbered="true" toc="default">
<section anchor="trans" title="CPNP Transaction"> <name>CPNP Transactions</name>
<t>A CPNP transaction occurs between a client and a server for <t>A CPNP transaction occurs between a client and a server for
completing, modifying, withdrawing a service agreement, and comprises completing, modifying, or withdrawing a service agreement, and comprises
all CPNP messages exchanged between the client and the server, from 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 the first request sent by the client to the final response sent by the
server. A CPNP transaction is bound to a CPNP session (<xref server. A CPNP transaction is bound to a CPNP session (<xref target="ses
target="session"></xref>).</t> sion" format="default"/>).</t>
<t>Because multiple CPNP transactions can be maintained by the CPNP <t>Because multiple CPNP transactions can be maintained by the CPNP
client, the client must assign an identifier to uniquely identify a client, the client must assign an identifier to uniquely identify a
given transaction. This identifier is denoted as Transaction-ID.</t> given transaction. This identifier is the Transaction-ID.</t>
<t>The Transaction-ID must be randomly assigned by the CPNP client, <t>The Transaction-ID must be randomly assigned by the CPNP client,
according to the best current practice for generating random numbers according to the best current practice for generating random numbers
<xref target="RFC4086"></xref> that cannot be guessed easily. <xref target="RFC4086" format="default"/> that cannot be guessed easily.
Transaction-ID is used for validating CPNP responses received by the The Transaction-ID is used for validating CPNP responses received by the
client.</t> client.</t>
<t>In the context of a transaction, the client needs to
<t>In the context of a transaction, the client needs to randomly select a sequence number randomly and then needs to assign it to the fir
select a sequence number and assign it to the first CPNP message to st CPNP message to
send. This number is then incremented for each request message that is send. This number is then incremented for each request message that is
subsequently sent within the ongoing CPNP transaction (see <xref subsequently sent within the ongoing CPNP transaction (see <xref target=
target="sq_nu"></xref>).</t> "sq_nu" format="default"/>).</t>
</section> </section>
<section anchor="timers" numbered="true" toc="default">
<section anchor="timers" title="CPNP Timers"> <name>CPNP Timers</name>
<t>CPNP adopts a simple retransmission procedure which relies on a <t>CPNP adopts a simple retransmission procedure that relies on a
retransmission timer denoted as RETRANS_TIMER and a maximum retry retransmission timer represented by RETRANS_TIMER and a maximum retry
threshold. The use of RETRANS_TIMER and a maximum retry threshold are threshold. The use of RETRANS_TIMER and a maximum retry threshold are
described in <xref target="behavior"></xref>.</t> described in <xref target="behavior" format="default"/>.</t>
<t>The response timer (EXPECTED_RESPONSE_TIME) is set by the client to <t>The response timer (EXPECTED_RESPONSE_TIME) is set by the client to
denote the time, in seconds, the client will wait for receiving a denote the time, in seconds, the client will wait to receive a
response from the server to a provisioning quotation order request response from the server to a PQO request
(see <xref target="extime"></xref>). If the timer expires, the (see <xref target="extime" format="default"/>). If the timer expires, th
respective quotation order is cancelled by the client and a CANCEL e
respective PQO is cancelled by the client, and a CANCEL
message is generated accordingly.</t> message is generated accordingly.</t>
<t>The expected offer timer (EXPECTED_OFFER_TIME) is set by the server <t>The expected offer timer (EXPECTED_OFFER_TIME) is set by the server
to indicate the time by when the CPNP server is expecting to make an to indicate the time by when the CPNP server is expected to make an
offer to the CPNP client (see <xref offer to the CPNP client (see <xref target="EXPECTED_OFFER_TIME" format=
target="EXPECTED_OFFER_TIME"></xref>). If no offer is received by "default"/>). If no offer is received by
then, the CPNP client will consider the order as rejected.</t> then, the CPNP client will consider the order as rejected.</t>
<t>An offer expiration timer (VALIDITY_OFFER_TIME) is set by the <t>An offer expiration timer (VALIDITY_OFFER_TIME) is set by the
server to represent the time, in minutes, after which an offer made by server to represent the time, in minutes, after which an offer made by
the server becomes invalid (see <xref target="valtime"></xref>).</t> the server becomes invalid (see <xref target="valtime" format="default"/ >).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="CPNP Operations"> <name>CPNP Operations</name>
<t>CPNP operations are listed below. They may be augmented, depending <t>CPNP operations are listed below. They may be augmented depending
on the nature of some transactions or because of security on the nature of some transactions or because of security
considerations that may necessitate a distinct CPNP client/server considerations that may necessitate a distinct CPNP client/server
authentication phase before negotiation begins. <list style="symbols"> authentication phase before negotiation begins. </t>
<t>QUOTATION (<xref target="provision"></xref>): <vspace <dl spacing="normal" newline="true">
blankLines="1" />This operation is used by the client to initiate <dt>QUOTATION (<xref target="provision" format="default"/>): </dt>
a provisioning quotation order. Upon receipt of a QUOTATION <dd>This operation is used by the client to initiate
request, the server may respond with a PROCESSING, OFFER or a FAIL a PQO. 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 message. A QUOTATION-initiated transaction can be terminated by a
FAIL message.</t> FAIL message.</dd>
<dt>PROCESSING (<xref target="proc" format="default"/>): </dt>
<t>PROCESSING (<xref target="proc"></xref>): <vspace <dd>This operation is used to inform the remote party
blankLines="1" />This operation is used to inform the remote party that its message (the order quotation or the offer) was
that the message (the order quotation or the offer) sent was received and it is being processed. This message can also be issued
received and it is processed. This message can also be issued by by
the server to request more time, in which case the client may the server to request more time, in which case, the client may
reply with an ACK or FAIL message depending on whether extra time reply with an ACK or FAIL message depending on whether extra time
can or cannot be granted.</t> can or cannot be granted.</dd>
<dt>OFFER (<xref target="offer" format="default"/>): </dt>
<t>OFFER (<xref target="offer"></xref>): <vspace <dd>This operation is used by the server to inform
blankLines="1" />This operation is used by the server to inform
the client about an offer that can best accommodate the the client about an offer that can best accommodate the
requirements indicated in the previously received QUOTATION requirements indicated in the previously received QUOTATION
message.</t> message.</dd>
<dt>ACCEPT (<xref target="accept" format="default"/>): </dt>
<t>ACCEPT (<xref target="accept"></xref>): <vspace <dd>This operation is used by the client to confirm
blankLines="1" />This operation is used by the client to confirm
the acceptance of an offer made by the server. This message the acceptance of an offer made by the server. This message
implies a call for agreement. An agreement is reached when an ACK implies a call for agreement. An agreement is reached when an ACK
is subsequently received from the server, which is likely to is subsequently received from the server, which is likely to
happen if the message is sent before the offer validity time happen if the message is sent before the offer validity time
expires; the server is unlikely to reject an offer that it has expires; the server is unlikely to reject an offer that it has
already made.</t> already made.</dd>
<dt>DECLINE (<xref target="dec" format="default"/>): </dt>
<t>DECLINE (<xref target="dec"></xref>): <vspace <dd>This operation is used by the client to reject an
blankLines="1" />This operation is used by the client to reject an
offer made by the server. The ongoing transaction may not be offer made by the server. The ongoing transaction may not be
terminated immediately, e.g., the server/client may issue another terminated immediately, e.g., the client may issue another order
offer/order.</t> or the server may issue another offer.</dd>
<dt>ACK (<xref target="ack" format="default"/>): </dt>
<t>ACK (<xref target="ack"></xref>): <vspace blankLines="1" />This <dd>This
operation is used by the server to acknowledge the receipt of an operation is used by the server to acknowledge the receipt of an
ACCEPT or WITHDRAW message, or by the client to confirm the time ACCEPT or WITHDRAW message or by the client to confirm the server's
extension requested (conveyed in a PROCESSING message) by the request for a time extension (conveyed in a PROCESSING message)
server for processing the last received quotation order.</t> in order to process the last received quotation order.</dd>
<dt>CANCEL (<xref target="cancel" format="default"/>): </dt>
<t>CANCEL (<xref target="cancel"></xref>): <vspace <dd>This operation is used by the client to cancel
blankLines="1" />This operation is used by the client to cancel (quit) the ongoing transaction.</dd>
(quit) the ongoing transaction.</t> <dt>WITHDRAW (<xref target="with" format="default"/>): </dt>
<dd>This operation is used by the client to withdraw
<t>WITHDRAW (<xref target="with"></xref>): <vspace a completed order (i.e., an agreement).</dd>
blankLines="1" />This operation is used by the client to withdraw <dt>UPDATE (<xref target="upd" format="default"/>): </dt>
a completed order (i.e., an agreement).</t> <dd>This operation is used by the client to update an
<t>UPDATE (<xref target="upd"></xref>): <vspace
blankLines="1" />This operation is used by the client to update an
existing agreement. For example, this method can be invoked to add existing agreement. For example, this method can be invoked to add
a new VPN site. This method will trigger a new negotiation a new VPN site. This method will trigger a new negotiation
cycle.</t> cycle.</dd>
<dt>FAIL (<xref target="fail" format="default"/>): </dt>
<t>FAIL (<xref target="fail"></xref>): <vspace <dd>
blankLines="1" />This operation is used by the server to indicate <t>This operation is used by the server to indicate
that it cannot accommodate the requirements documented in the PQO that it cannot accommodate the requirements documented in the PQO
conveyed in the QUOTATION message or to inform the client about an conveyed in the QUOTATION message or to inform the client about an
error encountered when processing the received message. In either error encountered when processing the received message. In either
case, the message implies that the server is unable to make offers case, the message implies that the server is unable to make offers,
and as a consequence, it terminates the ongoing transaction. and, as a consequence, it terminates the ongoing transaction.
<vspace blankLines="1" />This message is also used by the client </t>
to reject a time extension request received from the server (in a <t>This message is also used by the client
PROCESSING message). The message includes a status code for to reject a time extension request in a PROCESSING message received
providing explanatory information.</t> from the server. The message includes a status code that
</list></t> provides explanatory information.</t>
</dd>
<t>The above CPNP primitives are service-independent. CPNP messages </dl>
may transparently carry service-specific objects which are handled by <t>The above CPNP primitives are service independent. CPNP messages
may transparently carry service-specific objects that are handled by
the negotiation logic at either side.</t> the negotiation logic at either side.</t>
<t>The document defines the service objects that are required for <t>The document defines the service objects that are required for
connectivity provisioning negotiation (see <xref target="cpd"></xref>) connectivity provisioning negotiation purposes
purposes. Additional service-specific objects to be carried in CPNP (see <xref target="cpd" format="default"/>).
messages can be defined in the future for accommodating alternative Additional service-specific objects for CPNP messages to accommodate alt
deployment schemes or other service provisioning needs.</t> ernative
deployment schemes or other service provisioning needs can be
defined in the future.</t>
</section> </section>
<section anchor="cpd" numbered="true" toc="default">
<section anchor="cpd" title="Connectivity Provisioning Documents"> <name>Connectivity Provisioning Documents</name>
<t>CPNP makes use of several flavors of Connectivity Provisioning <t>CPNP makes use of several flavors of Connectivity Provisioning
Documents (CPD). These documents follow the same CPP template Documents (CPD). These documents follow the same CPP template
described in <xref target="RFC7297"></xref>.<list style="hanging"> described in <xref target="RFC7297" format="default"/>.</t>
<t <dl newline="true" spacing="normal">
hangText="Requested Connectivity Provisioning Document (Requested CP <dt>Requested CPD: </dt>
D): ">Refers <dd>Refers
to the CPD included by a CPNP client in a QUOTATION request.</t> to the CPD included by a CPNP client in a QUOTATION request.</dd>
<dt>Offered CPD: </dt>
<t <dd>This
hangText="Offered Connectivity Provisioning Document (Offered CPD):
">This
document is included by a CPNP server in an OFFER message. Its document is included by a CPNP server in an OFFER message. Its
information reflects the proposal of the server to accommodate all information reflects the proposal of the server to accommodate all
or a subset of the clauses depicted in a Requested CPD. A validity or a subset of the clauses depicted in a Requested CPD. A validity
time is associated with the offer made.</t> time is associated with the offer made.</dd>
<dt>Accepted CPD: </dt>
<t <dd>If
hangText="Agreed Connectivity Provisioning Document (Agreed CPD): ">
If
the client accepts an offer made by the server, the Offered CPD is 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 included in an ACCEPT message. This CPD is also included in an ACK
message. Thus, a 3-way handshake procedure is followed for message. Thus, a three-way handshake procedure is followed for
successfully completing the negotiation.</t> successfully completing the negotiation.</dd>
</list></t> </dl>
<t><xref target="example" format="default"/> shows a typical CPNP negoti
<t><xref target="example"></xref> shows a typical CPNP negotiation ation
cycle and the use of the different types of Connectivity Provisioning cycle and the use of the different types of CPDs.</t>
Documents.</t> <figure anchor="example">
<name>Connectivity Provisioning Documents</name>
<t><figure align="center" anchor="example" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Connectivity Provisioning Documents"> +------+ +------+
<artwork align="center"><![CDATA[+------+
+------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|======QUOTATION (Requested CPD)=====>| |======QUOTATION (Requested CPD)=====>|
|<============PROCESSING==============| |<============PROCESSING==============|
|<========OFFER (Offered CPD)=========| |<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>| |=============PROCESSING=============>|
|=========ACCEPT (Agreed CPD)========>| |=======ACCEPT (Accepted CPD)========>|
|<=========ACK (Agreed CPD)===========| |<=======ACK (Accepted CPD)===========|
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>A CPD can include parameters with fixed values,
<t>A provisioning document can include parameters with fixed values, loosely defined values, or any combination thereof. A CPD
loosely-defined values, or any combination thereof. A provisioning is said to be concrete if all clauses have fixed values.</t>
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 <t>A typical evolution of a negotiation cycle would start with a
quotation order with loosely-defined parameters, and then, as offers quotation order with loosely defined parameters, and then, as offers
are made, it would conclude with concrete provisioning document for are made, it would conclude with a concrete CPD for
calling for the agreement.</t> calling for the agreement.</t>
</section> </section>
<section anchor="cascaded" numbered="true" toc="default">
<section anchor="cascaded" title="Child Provisioning Quotation Orders"> <name>Child PQOs</name>
<t>If the server detects that network resources from another Network <t>If the server detects that network resources from another Network
Provider need to be allocated in order to accommodate the requirements 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 described in a PQO (e.g., in the context of an inter-domain VPN
service, additional PE router resources need to be allocated), the service, additional Provider Edge (PE) router resources need to be alloc ated), the
server may generate child PQOs to request the appropriate network server may generate child PQOs to request the appropriate network
provisioning operations (see <xref target="child"></xref>). In such provisioning operations (see <xref target="child"
situation, the server behaves also as a CPNP client. The server format="default"/>). In such a
situation, the server also behaves as a CPNP client. The server
associates the parent order with its child PQOs. How this is achieved associates the parent order with its child PQOs. How this is achieved
is implementation-specific (e.g., this can be typically achieved by is implementation specific (e.g., this can be typically achieved by
locally adding the reference of the child PQO to the parent locally adding the reference of the child PQO to the parent
order).</t> order).</t>
<figure anchor="child">
<t><figure align="center" anchor="child" <name>Example of Child Orders</name>
title="Example of Child Orders"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------+ +--------+ +------+ +--------+ +--------+
+--------+
|Client| |Server A| |Server B| |Client| |Server A| |Server B|
+------+ +--------+ +--------+ +------+ +--------+ +--------+
| | | | | |
|=====QUOTATION=====>| | |=====QUOTATION=====>| |
|<====PROCESSING=====| | |<====PROCESSING=====| |
| |=====QUOTATION=====>| | |=====QUOTATION=====>|
| |<====PROCESSING=====| | |<====PROCESSING=====|
| |<=======OFFER=======| | |<=======OFFER=======|
| |=====PROCESSING====>| | |=====PROCESSING====>|
| |=======ACCEPT======>| | |=======ACCEPT======>|
| |<=======ACK=========| | |<=======ACK=========|
|<=======OFFER=======| | |<=======OFFER=======| |
|=====PROCESSING====>| | |=====PROCESSING====>| |
|=======ACCEPT======>| | |=======ACCEPT======>| |
|<=======ACK=========| | |<=======ACK=========| |
| | | | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Note that the server must not activate recursion for an
<t>Note that recursion must not be activated by the server for an
order if the client includes a negotiation option to restrict the order if the client includes a negotiation option to restrict the
negotiation scope to the resources of the server's domain (<xref negotiation scope to the resources of the server's domain (<xref target=
target="nego"></xref>).</t> "nego" format="default"/>).</t>
<t>If recursion is not explicitly disabled, the server may notify the <t>If recursion is not explicitly disabled, the server may notify the
client when appropriate (<xref target="proc"></xref>). Such client when appropriate (<xref target="proc" format="default"/>). Such
notification may also depend on the nature of the service but also notification may depend on the nature of the service and also
regulatory considerations.</t> regulatory considerations.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Multi-Segment Service"> <name>Multi-Segment Service</name>
<t>A composite service (e.g., connectivity) requested by a customer <t>A composite service (e.g., connectivity) requested by a Customer
could imply multi-segment services (e.g., multi-segment connectivity could imply multi-segment services (e.g., multi-segment connectivity
spanning an end-to-end scope), in the sense that one single CPNP spanning an end-to-end scope), in the sense that one single CPNP
request is decomposed into N connectivity requests at the provider's request is decomposed into multiple connectivity requests on the Provide r's
side (thereby leading to child orders). The Provider is in charge of side (thereby leading to child orders). The Provider is in charge of
handling the complexity of splitting the generic provisioning order in handling the complexity of splitting the generic provisioning order in
a multi-segment context. Such complexity is local to the Provider.</t> a multi-segment context. Such complexity is local to the Provider.</t>
</section> </section>
<section anchor="mser" numbered="true" toc="default">
<section anchor="mser" title="Negotiating with Multiple CPNP Servers"> <name>Negotiating with Multiple CPNP Servers</name>
<t>A CPNP client may undertake multiple negotiations in parallel with <t>A CPNP client may undertake multiple negotiations in parallel with
several servers for various reasons, such as cost optimization and several servers for various reasons, such as cost optimization and
fail-safety. These multiple negotiations may lead to one or many fail-safety. These multiple negotiations may lead to one or many
agreements.</t> agreements.</t>
<t>The salient point underlining the parallel negotiation scenarios is <t>The salient point underlining the parallel negotiation scenarios is
that, although the negotiation protocol is strictly between two that, although the negotiation protocol is strictly between two
parties, this may not be the case of the negotiation logic. The CPNP parties, this may not be the case of the negotiation logic. The CPNP
client negotiation logic may need to collectively drive parallel client negotiation logic may need to collectively drive parallel
negotiations, as the negotiation with one server may affect the negotiations, as the negotiation with one server may affect the
negotiation with other servers; for example, it may need to use the negotiation with other servers; for example, it may need to use the
responses from all servers as an input for determining the messages responses from all servers as an input for determining the messages
(and their content) to subsequently send within the course of each (and their content) to subsequently send within the course of each
individual negotiation. Timing is therefore an important aspect at the individual negotiation. Therefore, timing is an important aspect on the
client's side. The CPNP client needs to have the ability to client's side. The CPNP client needs to have the ability to
synchronize the receipt of the responses from the servers. CPNP takes synchronize the receipt of the responses from the servers. CPNP takes
into account this requirement by allowing clients to specify in the into account this requirement by allowing clients to specify in the
QUOTATION message the time by which the server needs to respond (see QUOTATION message the time by which the server needs to respond (see
<xref target="extime"></xref>).</t> <xref target="extime" format="default"/>).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="State Management"> <name>State Management</name>
<t>Both the client and the server maintain repositories to store <t>Both the client and the server maintain repositories to store
ongoing orders. How these repositories are maintained is ongoing orders. How these repositories are maintained is
deployment-specific. It is out of scope of this document to elaborate deployment specific. It is out of scope of this document to elaborate
on such considerations. Timestamps are also logged to track state on such considerations. Timestamps are also logged to track state
change. Tracking may be needed for various reasons, including change. Tracking may be needed for various reasons, including
regulatory or billing ones.</t> regulatory or billing ones.</t>
<t>In order to accommodate failures that may lead to the reboot of the <t>In order to accommodate failures that may lead to the reboot of the
client or the server, the use of permanent storage is recommended, client or the server, the use of permanent storage is recommended,
thereby facilitating state recovery. <!-- thereby facilitating state recovery.
</t>
<section title="On the Client Side"> <section numbered="true" toc="default">
<name>On the Client Side</name>
<t>This is the list of the typical states that can be associated <t>This is the list of the typical states that can be associated
with a given order on the client's side:</t> with a given order on the client's side:</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>Created:</dt><dd>The order has been created. It is not handled
<t>Created: when the order has been created. It is not handled by the client until the administrator allows it to be processed.</
by the client until the administrator allows to process it.</t> dd>
<dt>AwaitingProcessing:</dt><dd>The administrator has approved the
<t>AwaitingProcessing: when the administrator approved the processing of a created order, but the order has not been handled
processing of a created order and the order has not been handled yet.</dd>
yet.</t> <dt>PQOSent:</dt><dd> The order has been sent to the server.</dd>
<dt>ServerProcessing:</dt><dd>The server has confirmed the receipt
<t>PQOSent: when the order has been sent to the server.</t> of the order.</dd>
<dt>OfferReceived:</dt><dd>An offer has been received from the
<t>ServerProcessing: when the server has confirmed the receipt server.</dd>
of the order.</t> <dt>OfferProcessing:</dt><dd>A received offer is being processed
by the client.</dd>
<t>OfferReceived: when an offer has been received from the <dt>AcceptSent:</dt><dd>The client has confirmed the offer to the
server.</t> server.</dd>
<dt>Completed:</dt><dd>The offer has been acknowledged by the server
<t>OfferProcessing: when a received offer is currently processed .</dd>
by the client.</t> <dt>Cancelled:</dt><dd>The order has failed or was cancelled.</dd>
</dl>
<t>AcceptSent: when the client confirmed the offer to the
server.</t>
<t>Completed: when the offer is acknowledged by the server.</t>
<t>Cancelled: when the order has failed or cancelled.</t>
</list></t>
<t>Sub-states may be defined (e.g., to track failed vs. cancelled <t>Sub-states may be defined (e.g., to track failed vs. cancelled
orders) but those are not shown in <xref orders), but those are not shown in <xref target="clientstate" format=
target="clientstate"></xref>.</t> "default"/>.</t>
<figure anchor="clientstate">
<t><figure align="center" anchor="clientstate" <name>Example of a CPNP Finite State Machine (Client Side)</name>
title="Example of a CPNP Finite State Machine (Client Side)"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------------------+ +------------------+
| Created |-----------------+ | Created |-----------------+
+------------------+ | +------------------+ |
| | | |
v | v |
+------------------+ | +------------------+ |
|AwaitingProcessing|----------------+| |AwaitingProcessing|----------------+|
+------------------+ || +------------------+ ||
| || | ||
QUOTATION/UPDATE || QUOTATION/UPDATE ||
v || v ||
skipping to change at line 1170 skipping to change at line 1052
v || v ||
+------------------+ || +------------------+ ||
| AcceptSent |---CANCEL-------+| | AcceptSent |---CANCEL-------+|
+------------------+ | +------------------+ |
| ACK | | ACK |
v | v |
+------------------+ | +------------------+ |
| Completed |---WITHDRAW------+ | Completed |---WITHDRAW------+
+------------------+ +------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t></t>
</section> </section>
<section numbered="true" toc="default">
<section title="On the Server Side"> <name>On the Server Side</name>
<t>The following lists the states which can be associated with a <t>The following lists the states on the server's side that can be ass
given order and a corresponding offer on the server's side:</t> ociated with a
given order and a corresponding offer:</t>
<t><list style="symbols"> <dl spacing="normal">
<t>PQOReceived: when the order has been received from the <dt>PQOReceived:</dt><dd>The order has been received from the
client.</t> client.</dd>
<dt>AwaitingProcessing: </dt><dd>The order is being processed by the
<t>AwaitingProcessing: when the order is being processed by the
server. An action from the server administrator may be server. An action from the server administrator may be
needed.</t> needed.</dd>
<dt>OfferProposed:</dt><dd>The request has been successfully handled
<t>OfferProposed: when the request has been successfully handled ,
and an offer has been sent to the client.</t> and an offer has been sent to the client.</dd>
<dt>ProcessingReceived:</dt><dd>The server has received a PROCESSING
<t>ProcessingReceived: when the server received a PROCESSING for message for
an offer sent to the client.</t> an offer sent to the client.</dd>
<dt>AcceptReceived:</dt><dd>The server has received a confirmation f
<t>AcceptReceived: when the server received a confirmation for or
the offer from the client.</t> the offer from the client.</dd>
<dt>Completed:</dt><dd>The server has acknowledged the offer (accept
<t>Completed: when the server acknowledged the offer (accepted ed
by client) to the client. Transitioning to this state assumes by client) to the client. Transitioning to this state assumes
that the ACK was received by the client (this can be detected by that the ACK was received by the client (this can be detected by
the server if it receives retransmitted ACCEPT from the the server if it receives a retransmitted ACCEPT message from the
client).</t> client).</dd>
<dt>Cancelled:</dt><dd>The order cannot be accommodated, or it has
<t>Cancelled: when the order cannot be accommodated or it has been cancelled by the client. Associated resources must be
been cancelled by the client. Associate resources must be released in the latter case, if previously reserved.</dd>
released in the latter case, if previously reserved.</t> <dt>ChildCreated:</dt><dd>A child order has been created in cases
where resources from another Network Provider are needed.</dd>
<t>ChildCreated: when a child order has been created in cases <dt>ChildPQOSent:</dt><dd>A child order has been sent to the remote
where resources from another Network Provider are needed.</t> server.</dd>
<dt>ChildServerProcessing:</dt><dd>A child order is being
<t>ChildPQOSent: when a child order has been sent to the remote processed by the remote server.</dd>
server.</t> <dt>ChildOfferReceived:</dt><dd> The remote server has received an o
ffer to a
<t>ChildServerProcessing: when a child order is currently child order.</dd>
processed by the remote server.</t> <dt>ChildOfferProcessing:</dt><dd> A received offer to a child order
is being processed.</dd>
<t>ChildOfferReceived: when an offer has been received to a <dt>ChildAcceptSent: </dt><dd>The child offer (the offer received fr
child order from the remote server.</t> om
<t>ChildOfferProcessing: when a received offer to a child order
is currently processed.</t>
<t>ChildAcceptSent: when the child offer (offer received from
the remote server in response to a child order) is confirmed to the remote server in response to a child order) is confirmed to
the remote server.</t> the remote server.</dd>
<dt>ChildCompleted:</dt><dd> The accepted child offer has been ackno
<t>ChildCompleted: when an accepted child offer is acknowledged wledged
by the remote server.</t> by the remote server.</dd>
</list></t> </dl>
<figure anchor="serverstate">
<t><figure align="center" anchor="serverstate" <name>CPNP Finite State Machine (Server Side)</name>
title="CPNP Finite State Machine (Server Side)"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------------------+ +- +------------------+ +------------------+
-----------------+
|AwaitingProcessing|<----------| ChildCreated | |AwaitingProcessing|<----------| ChildCreated |
+------------------+ +------------------+ +------------------+ +------------------+
| | ^ | | ^
v | | v | |
+------------------+ | | +------------------+ | |
| ChildPQOSent |----------------+| Q | ChildPQOSent |----------------+| Q
+------------------+ || U +------------------+ || U
| || O | || O
QUOTATION/UPDATE || T QUOTATION/UPDATE || T
v || A +--------------------+ v || A +--------------------+
skipping to change at line 1278 skipping to change at line 1144
+------------------+ ||| | +------------------+ +------------------+ ||| | +------------------+
| ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-| Completed | | ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-| Completed |
+------------------+ | | +------------------+ +------------------+ | | +------------------+
| ACK | | | ACK | |
v | | v | |
+------------------+ | | +------------------+ | |
| ChildCompleted |---WITHDRAW-----+ | | ChildCompleted |---WITHDRAW-----+ |
| +---------------------------+ | +---------------------------+
+------------------+ +------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t></t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="co" numbered="true" toc="default">
<section anchor="co" title="CPNP Objects"> <name>CPNP Objects</name>
<t>This section defines CPNP objects using the RBNF format defined at <t>This section defines CPNP objects using the Routing Backus-Naur Form (R
<xref target="RFC5511"></xref>.</t> BNF) format defined in
<xref target="RFC5511" format="default"/>. Please also note the
<t><list style="empty"> following:</t>
<t>Note 1: The formats of CPNP messages are provided using a generic <aside><t>Note 1: The formats of CPNP messages are provided using a gene
ric
format. Implementors can adapt RBNF definitions to their "favorite" format. Implementors can adapt RBNF definitions to their "favorite"
message format. For example, JSON <xref target="RFC8259"></xref> or message format. For example, JSON <xref target="RFC8259" format="defau
CBOR <xref target="RFC7049"></xref> can be used.</t> lt"/> or
Concise Binary Object Representation (CBOR) <xref target="RFC7049" for
<t>Note 2: CPNP messages cannot be blindly mapped to RESTCONF mat="default"/> can be used.</t></aside>
<aside><t>Note 2: CPNP messages cannot be blindly mapped to RESTCONF
messages with the target service being modelled as configuration messages with the target service being modelled as configuration
data because such data is supposed to be manipulated by a RESTCONF data because such data is supposed to be manipulated by a RESTCONF
client only. In such model, the RESTCONF server cannot use a value client only. In such a model, the RESTCONF server cannot use a value
other than the one set by the client (e.g., <xref other than the one set by the client (e.g., <xref target="offer" forma
target="offer"></xref>) or remove offers from its own initiative t="default"/>)
(e.g., <xref target="valtime"></xref>). An alternate approach might or remove offers from its own initiative
be to map CPNP operations into RESTCONF actions (rpc). Assessing the (e.g., <xref target="valtime" format="default"/>). An alternate approa
feasibility of such approach is out of scope.</t> ch might
</list></t> be to map CPNP operations into RESTCONF actions (RPC). Assessing the
feasibility of such approach is out of scope.</t></aside>
<t><?rfc subcompact="yes" ?></t>
<section title="Attributes">
<t></t>
<section anchor="cu_id" title="CUSTOMER_AGREEMENT_IDENTIFIER"> <section numbered="true" toc="default">
<t>CUSTOMER_AGREEMENT_IDENTIFIER is an identifier which is assigned <name>Attributes</name>
<section anchor="cu_id" numbered="true" toc="default">
<name>CUSTOMER_ORDER_IDENTIFIER</name>
<t>The CUSTOMER_ORDER_IDENTIFIER (Customer Order Identifier) is an ide
ntifier that is assigned
by a client to identify an agreement. This identifier must be unique by a client to identify an agreement. This identifier must be unique
to the client.</t> to the client.</t>
<t>Rules for assigning this identifier (including the structure and
<t>Rules for assigning this identifier (including structure and semantics) are specific to the client (Customer). The value of
semantic) are specific to the client (Customer). The value of CUSTOMER_ORDER_IDENTIFIER is included in all CPNP messages.</t>
CUSTOMER_AGREEMENT_IDENTIFIER is included in all CPNP messages.</t>
<t>The client (Customer) assigns an identifier to an order under <t>The client (Customer) assigns an identifier to an order under
negotiation before an agreement is reached. This identifier will be negotiation before an agreement is reached. This identifier will be
used to unambiguously identify the resulting agreement at the client used to unambiguously identify the resulting agreement at the client
side (Customer).</t> side (Customer).</t>
<t>The server handles the CUSTOMER_ORDER_IDENTIFIER as an opaque
<t>The server handles CUSTOMER_AGREEMENT_IDENTIFIER as an opaque
value.</t> value.</t>
</section> </section>
<section anchor="pr_id" numbered="true" toc="default">
<section anchor="pr_id" title="PROVIDER_AGREEMENT_IDENTIFIER"> <name>PROVIDER_ORDER_IDENTIFIER</name>
<t>PROVIDER_AGREEMENT_IDENTIFIER is an identifier which is assigned <t>The PROVIDER_ORDER_IDENTIFIER (Provider Order Identifier) is an ide
ntifier that is assigned
by a server to identify an order. This identifier must be unique to by a server to identify an order. This identifier must be unique to
the server.</t> the server.</t>
<t>Rules for assigning this identifier (including the structure and
<t>Rules for assigning this identifier (including structure and semantics) are specific to the server (Provider).
semantic) are specific to the server (Provider). The PROVIDER_ORDER_IDENTIFIER is included in all CPNP messages
PROVIDER_AGREEMENT_IDENTIFIER is included in all CPNP messages,
except QUOTATION messages (because the state is only present at the except QUOTATION messages (because the state is only present at the
client side).</t> client side).</t>
<t>The server (Provider) assigns an identifier to an order under <t>The server (Provider) assigns an identifier to an order under
negotiation before an agreement is reached. This identifier will be negotiation before an agreement is reached. This identifier will be
used to unambiguously identify the resulting agreement at the server used to unambiguously identify the resulting agreement at the server
side (Provider).</t> side (Provider).</t>
<t>The client handles the PROVIDER_ORDER_IDENTIFIER as an opaque
<t>The client handles PROVIDER_AGREEMENT_IDENTIFIER as an opaque
value.</t> value.</t>
</section> </section>
<section anchor="trans_id" numbered="true" toc="default">
<section anchor="trans_id" title="TRANSACTION_ID"> <name>TRANSACTION_ID</name>
<t>This object conveys the Transaction-ID introduced in <xref <t>This object conveys the Transaction-ID introduced in <xref target="
target="trans"></xref>.</t> trans" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="SEQUENCE_NUMBER"> <name>SEQUENCE_NUMBER</name>
<t>Sequence Number is a number that is monotonically incremented in <t>The sequence number is a number that is monotonically incremented i
n
every new CPNP message pertaining to a given CPNP transaction. This every new CPNP message pertaining to a given CPNP transaction. This
number is used to avoid reply attacks.</t> number is used to avoid replay attacks.</t>
<t>Refer to <xref target="sq_nu" format="default"/>.</t>
<t>Refer to <xref target="sq_nu"></xref>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="NONCE"> <name>NONCE</name>
<t>NONCE is a random value assigned by the CPNP server. It is <t>The NONCE is a random value assigned by the CPNP server.
recommended to assign unique NONCE values for each order.</t> Assigning a unique NONCE value for each order is recommended.</t>
<t>It is mandatory to then include the NONCE in subsequent CPNP client
<t>NONCE is then mandatory to be included in subsequent CPNP client
operations on the associated order (including the resulting operations on the associated order (including the resulting
agreement) such as: withdraw the order or update the order.</t> agreement) such as withdrawing the order or updating the order.</t>
<t>If the NONCE validation checks fail, the server rejects the <t>If the NONCE validation checks fail, the server rejects the
request with a FAIL message including the appropriate failure reason request with a FAIL message that includes the appropriate failure reas on
code.</t> code.</t>
</section> </section>
<section anchor="extime" numbered="true" toc="default">
<section anchor="extime" title="EXPECTED_RESPONSE_TIME"> <name>EXPECTED_RESPONSE_TIME</name>
<t>This attribute indicates the time by when the CPNP client is <t>This attribute indicates the time by when the CPNP client is
expecting to receive a response from the CPNP server to a given PQO. expecting to receive a response from the CPNP server to a given PQO.
If no offer is received by then, the CPNP client will consider the If no offer is received by then, the CPNP client will consider the
quotation order as rejected.</t> quotation order to be rejected.</t>
<t>The EXPECTED_RESPONSE_TIME follows the date format specified in <xr
<t>EXPECTED_RESPONSE_TIME follows the date format specified in <xref ef target="RFC3339" format="default"/>.</t>
target="RFC3339"></xref>.</t>
</section> </section>
<section anchor="EXPECTED_OFFER_TIME" numbered="true" toc="default">
<section anchor="EXPECTED_OFFER_TIME" title="EXPECTED_OFFER_TIME"> <name>EXPECTED_OFFER_TIME</name>
<t>This attribute indicates the time by when the CPNP server is <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 expecting to make an offer to the CPNP client. If no offer is
received by then, the CPNP client will consider the order as received by then, the CPNP client will consider the order
rejected.</t> rejected.</t>
<t>The CPNP server may propose an expected offer time that does not <t>The CPNP server may propose an expected offer time that does not
match the expected response time indicated in the quotation order match the expected response time indicated in the quotation order
message. The CPNP client can accept or reject the proposed expected message. The CPNP client can accept or reject the proposed expected
time by when the CPNP server will make an offer.</t> time by when the CPNP server will make an offer.</t>
<t>The CPNP server can always request extra time for its processing, <t>The CPNP server can always request extra time for its processing,
but this may be accepted or rejected by the CPNP client.</t> but this may be accepted or rejected by the CPNP client.</t>
<t>The EXPECTED_OFFER_TIME follows the date format specified in <xref
<t>EXPECTED_OFFER_TIME follows the date format specified in <xref target="RFC3339" format="default"/>.</t>
target="RFC3339"></xref>.</t>
</section> </section>
<section anchor="valtime" numbered="true" toc="default">
<section anchor="valtime" title="VALIDITY_OFFER_TIME"> <name>VALIDITY_OFFER_TIME</name>
<t>This attribute indicates the time of validity of an offer made by <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 the CPNP server. If the offer is not accepted before this time
expires, the CPNP server will consider the CPNP client has rejected expires, the CPNP server will consider the CPNP client as having rejec
ted
the offer; the CPNP server will silently remove this order from its the offer; the CPNP server will silently remove this order from its
base.</t> base.</t>
<t>The VALIDITY_OFFER_TIME follows date format specified in <xref targ
<t>VALIDITY_OFFER_TIME follows date format specified in <xref et="RFC3339" format="default"/>.</t>
target="RFC3339"></xref>.</t>
</section> </section>
<section anchor="service_template" numbered="true" toc="default">
<section anchor="service_template" title="SERVICE_DESCRIPTION"> <name>SERVICE_DESCRIPTION</name>
<t>This document defines a machinery to negotiate any aspect subject <t>This document defines a machinery to negotiate any aspect subject
to negotiation. Service clauses that are under negotiation are to negotiation. Service clauses that are under negotiation are
conveyed using this attribute.</t> conveyed using this attribute.</t>
<t>The structure of the connectivity provisioning clauses is <t>The structure of the connectivity provisioning clauses is
provided in the following sub-section.</t> provided in the following subsection.</t>
<section anchor="cpd_template" numbered="true" toc="default">
<section anchor="cpd_template" <name>CPD</name>
title="CONNECTIVITY_PROVISIONING_DOCUMENT"> <t>The RBNF format of the CPD
<t>The RBNF format of the Connectivity Provisioning Document (CPD) is shown in <xref target="rbnf_cpd" format="default"/>.</t>
is shown in <xref target="rbnf_cpd"></xref>:</t> <figure anchor="rbnf_cpd">
<name>The RBNF format of the CPD</name>
<t><figure anchor="rbnf_cpd" <sourcecode type="rbnf"><![CDATA[
title="The RBNF format of the Connectivity Provisioning Document <CPD> ::= <Connectivity Provisioning Component> ...
(CPD)">
<artwork><![CDATA[<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=
<Connectivity Provisioning Component> ...
<Connectivity Provisioning Component> ::= <Connectivity Provisioning Component> ::=
<CONNECTIVITY_PROVISIONING_PROFILE> ... <CONNECTIVITY_PROVISIONING_PROFILE> ...
<CONNECTIVITY_PROVISIONING_PROFILE> ::= <CONNECTIVITY_PROVISIONING_PROFILE> ::=
<Customer Nodes Map> <Customer Nodes Map>
<SCOPE> <SCOPE>
<QoS Guarantees> <QoS Guarantees>
<Availability> <Availability>
<CAPACITY> <CAPACITY>
<Traffic Isolation> <Traffic Isolation>
<Conformance Traffic> <Conformance Traffic>
<Flow Identification> <Flow Identification>
<Overall Traffic Guarantees> <Overall Traffic Guarantees>
<Routing and Forwarding> <Routing and Forwarding>
<Activation Means> <Activation Means>
<Invocation Means> <Invocation Means>
<Notifications> <Notifications>
<Customer Nodes Map> ::= <Customer Node> ... <Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER> <Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER> <LINK_IDENTIFIER>
<LOCALISATION>]]></artwork> <LOCALISATION>
</figure></t> ]]></sourcecode>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="CPNP Information Elements"> <name>CPNP Information Elements</name>
<t>An Information Element (IE) is an optional object which can be <t>An Information Element (IE) is an optional object that can be
included in a CPNP message.</t> included in a CPNP message.</t>
<section numbered="true" toc="default">
<section title="Customer Description"> <name>Customer Description</name>
<t>The client may include administrative information such <t>The client may include administrative information such
as:<?rfc subcompact="yes"?><list style="symbols"> as the following:</t>
<t>Name</t> <ul spacing="normal">
<li>Name</li>
<t>Contact Information<?rfc subcompact="no"?></t> <li>Contact Information</li>
</list>The format of this Information Element is as follows:</t> </ul>
<t>The format of this Information Element is as follows:</t>
<t><figure> <sourcecode type="rbnf"><![CDATA[
<artwork><![CDATA[<Customer Description> ::= [<NAME>] [<Contact <Customer Description> ::= [<NAME>] [<Contact Information>]
Information>]
<Contact Information> ::= [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>] <Contact Information> ::= [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...] [<TELEPHONE_NUMBER> ...]
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Provider Description"> <name>Provider Description</name>
<t>The server may include administrative information in an offer <t>The server may include administrative information in an offer
such as:<?rfc subcompact="yes"?><list style="symbols"> such as the following:</t>
<t>Name</t> <ul spacing="normal">
<li>Name</li>
<t>AS Number (<xref target="RFC6793"></xref>)</t> <li>AS Number <xref target="RFC6793" format="default"/></li>
<li>Contact Information</li>
<t>Contact Information<?rfc subcompact="no"?></t> </ul>
</list>The format of this Information Element is as follows:</t> <t>The format of this Information Element is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<t><figure> <Provider Description> ::= [<NAME>][<Contact Information>]
<artwork><![CDATA[<Provider Description> ::= [<NAME>][<Contact I [<AS_NUMBER>]
nformation>][<AS_NUMBER>] ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="nego" numbered="true" toc="default">
<section anchor="nego" title="Negotiation Options"> <name>Negotiation Options</name>
<t>The client may include some negotiation options such as:<?rfc sub <t>The client may include some negotiation options such as the follo
compact="yes"?><list wing:</t>
style="symbols"> <dl spacing="normal">
<t>Setup purpose: A client may request the setup of a service <dt>Setup purpose:</dt><dd>A client may request the setup of a ser
vice
(e.g., connectivity) only for testing purposes during a (e.g., connectivity) only for testing purposes during a
limited period. The order can be extended to become permanent limited period. The order can be extended to become permanent
if the client was satisfied during the test period. This if the client was satisfied during the test period. This
operation is achieved using the UPDATE method.</t> operation is achieved using the UPDATE method.</dd>
<dt>Activation type:</dt><dd> A client may request a permanent or
<t>Activation type: A client may request a permanent or
scheduled activation type. If no activation type clause is scheduled activation type. If no activation type clause is
included during the negotiation, this means that the order included during the negotiation, this means that the order
will be immediately activated right after the negotiation will be immediately activated right after the negotiation
ends.<?rfc subcompact="no"?></t> ends.</dd>
</list></t> </dl>
<t>The format of this Information Element is as follows:</t> <t>The format of this Information Element is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<t><figure> <Negotiation Options> ::= [<PURPOSE>]
<artwork><![CDATA[<Negotiation Options> ::= [<PURPOSE>] ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Operation Messages"> <name>Operation Messages</name>
<t>This section defines the RBNF format of CPNP operation messages. <t>This section defines the RBNF format of CPNP operation messages.
The following operation codes are used: <?rfc subcompact="yes" ?></t> The following operation codes are used: </t>
<table align="left">
<t><list style="format %d:"> <name>CPNP Operation Message Codes</name>
<t>QUOTATION (<xref target="provision"></xref>)</t> <thead>
<tr>
<t>PROCESSING (<xref target="proc"></xref>)</t> <th>Code</th>
<th>Operation Message</th>
<t>OFFER (<xref target="offer"></xref>)</t> <th>Reference</th>
</tr>
<t>ACCEPT (<xref target="accept"></xref>)</t> </thead>
<tbody>
<t>DECLINE (<xref target="dec"></xref>)</t> <tr>
<td>1</td>
<t>ACK (<xref target="ack"></xref>)</t> <td>QUOTATION</td>
<td><xref target="provision" format="default"/></td>
<t>CANCEL (<xref target="cancel"></xref>)</t> </tr>
<tr>
<t>WITHDRAW (<xref target="with"></xref>)</t> <td>2</td>
<td>PROCESSING</td>
<t>UPDATE (<xref target="upd"></xref>)</t> <td><xref target="proc" format="default"/></td>
</tr>
<t>FAIL (<xref target="fail"></xref>)</t> <tr>
<td>3</td>
<t>ACTIVATE (<xref target="activate"></xref>)<?rfc subcompact="no"?> <td>OFFER</td>
</t> <td><xref target="offer" format="default"/></td>
</list></t> </tr>
<tr>
<td>4</td>
<td>ACCEPT</td>
<td><xref target="accept" format="default"/></td>
</tr>
<tr>
<td>5</td>
<td>DECLINE</td>
<td><xref target="dec" format="default"/></td>
</tr>
<tr>
<td>6</td>
<td>ACK</td>
<td><xref target="ack" format="default"/></td>
</tr>
<tr>
<td>7</td>
<td>CANCEL</td>
<td><xref target="cancel" format="default"/></td>
</tr>
<tr>
<td>8</td>
<td>WITHDRAW</td>
<td><xref target="with" format="default"/></td>
</tr>
<tr>
<td>9</td>
<td>UPDATE</td>
<td><xref target="upd" format="default"/></td>
</tr>
<tr>
<td>10</td>
<td>FAIL</td>
<td><xref target="fail" format="default"/></td>
</tr>
<tr>
<td>11</td>
<td>ACTIVATE</td>
<td><xref target="activate" format="default"/></td>
</tr>
</tbody>
</table>
<t>These codes are used to unambiguously identify a CPNP operation; <t>These codes are used to unambiguously identify a CPNP operation;
the operation code is conveyed in the "METHOD_CODE" attribute the operation code is conveyed in the METHOD_CODE attribute
mentioned in the following sub-sections.</t> mentioned in the following subsections.</t>
<t>In the following, VERSION refers to the CPNP version number. This
<t>In the following, "VERSION" refers to the CPNP version number. This
attribute must be set to 1.</t> attribute must be set to 1.</t>
<section anchor="provision" numbered="true" toc="default">
<section anchor="provision" title="QUOTATION"> <name>QUOTATION</name>
<t>The format of the QUOTATION message is shown below:<?rfc subcompact <t>The format of the QUOTATION message is shown below:</t>
="yes" ?></t> <sourcecode type="rbnf"><![CDATA[
<QUOTATION Message> ::= <VERSION>
<t><list hangIndent="23" style="hanging"> <METHOD_CODE>
<t hangText="&lt;QUOTATION Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
<t>&lt;SEQUENCE_NUMBER&gt;</t> <REQUESTED_CPD>
[<INFORMATION_ELEMENT>...]
<t>&lt;TRANSACTION_ID&gt;</t> ]]></sourcecode>
<t>A QUOTATION message must include an order
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> identifier that is generated by the client
(CUSTOMER_ORDER_IDENTIFIER). Because several orders can be
<t>[&lt;EXPECTED_RESPONSE_TIME&gt;]</t>
<t>&lt;REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT&gt;</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</t>
</list></t>
<t><?rfc subcompact="no" ?>A QUOTATION message must include an order
identifier which is generated by the client
(CUSTOMER_AGREEMENT_IDENTIFIER). Because several orders can be
issued to several servers, the QUOTATION message must also include a issued to several servers, the QUOTATION message must also include a
Transaction-ID.</t> Transaction-ID.</t>
<t>The message may include an EXPECTED_RESPONSE_TIME, which indicates
<t>The message may include an EXPECTED_RESPONSE_TIME which indicates by when the client expects to receive an offer from the server.
by when the client is expecting to receive an offer from the server. The QUOTATION message must also include a requested service descriptio
QUOTATION message must also include a requested service description n
(that is, requested connectivity provisioning document for (that is, a Requested CPD for
connectivity services).</t> connectivity services).</t>
<t>The message may include ACTIVATION_TYPE to request a permanent or <t>The message may include ACTIVATION_TYPE to request a permanent or
scheduled activation type (e.g., using the ACTIVATE method defined scheduled activation type (e.g., using the ACTIVATE method defined
in <xref target="activate"></xref>). If no such clause is included, in <xref target="activate" format="default"/>). If no such clause is i ncluded,
the default mode is to assume that the order will be active once the the default mode is to assume that the order will be active once the
agreed activation means are successfully invoked (e.g., Section 3.11 accepted activation means are successfully invoked (e.g., <xref target
of <xref target="RFC7297"></xref>).</t> ="RFC7297" sectionFormat="of" section="3.11"/>).</t>
<t>When the client sends the QUOTATION message to the server, the <t>When the client sends the QUOTATION message to the server, the
state of the order changes to "PQOSent" at the client side.</t> state of the order changes to "PQOSent" at the client side.</t>
</section> </section>
<section anchor="proc" numbered="true" toc="default">
<section anchor="proc" title="PROCESSING"> <name>PROCESSING</name>
<t>The format of the PROCESSING message is shown below:<?rfc subcompac <t>The format of the PROCESSING message is shown below:</t>
t="yes" ?></t> <sourcecode type="rbnf"><![CDATA[
<PROCESSING Message> ::= <VERSION>
<t><list hangIndent="25" style="hanging"> <METHOD_CODE>
<t hangText="&lt;PROCESSING Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> [<EXPECTED_OFFER_TIME>]
[<PROCESSING_SUBCODE>]
<t>&lt;TRANSACTION_ID&gt;</t> ]]></sourcecode>
<t>Upon receipt of a QUOTATION message, the
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> server proceeds with the parsing rules (see <xref target="validation"
format="default"/>).
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t> If no error is encountered, the server
<t>[&lt;EXPECTED_OFFER_TIME&gt;]</t>
<t>[&lt;PROCESSING_SUBCODE&gt;]</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 generates a PROCESSING response to the client to indicate the PQO
has been received and it is being processed. The server must has been received and it is being processed. The server must
generate an order identifier which identifies the order in its local generate an order identifier that identifies the order in its local
order repository. The server must copy the content of order repository. The server must copy the content of the
CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed
in the QUOTATION message. The server may include an in the QUOTATION message. The server may include an
EXPECTED_OFFER_TIME by when it expects to make an offer to the EXPECTED_OFFER_TIME by when it expects to make an offer to the
client.</t> client.</t>
<t>Upon receipt of a PROCESSING message, the client verifies whether <t>Upon receipt of a PROCESSING message, the client verifies whether
it has issued a PQO to that server and which contains the it has issued a PQO that contains the
CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID to that server. If no suc
h PQO is
found, the PROCESSING message must be silently ignored. If a PQO is found, the PROCESSING message must be silently ignored. If a PQO is
found, the client may check whether it accepts the found, the client may check whether it accepts the
EXPECTED_OFFER_TIME and then, it changes to state of the order to EXPECTED_OFFER_TIME, and then it changes to state of the order to
"ServerProcessing".</t> "ServerProcessing".</t>
<t>If the server requires more time to process the quotation
<t>If more time is required by the server to process the quotation
order, it may send a PROCESSING message that includes a new order, it may send a PROCESSING message that includes a new
EXPECTED_OFFER_TIME. The client can answer with an ACK message if EXPECTED_OFFER_TIME. The client can answer with an ACK message if
more time is granted (<xref target="timegranted"></xref>) or with a more time is granted (<xref target="timegranted" format="default"/>) o
FAIL message if the time extension request is rejected (<xref r with a
target="timerejected"></xref>).</t> FAIL message if the time extension request is rejected (<xref target="
timerejected" format="default"/>).</t>
<t>The server may provide more details in the PROCESSING_SUBCODE <t>The server may provide more details in the PROCESSING_SUBCODE
attribute about the reason for requesting more time to process the attribute about the reason for requesting more time to process the
request. The following codes are defined:</t> request. The following codes are defined:</t>
<table align="left">
<name>PROCESSING_SUBCODE Codes</name>
<thead>
<tr>
<th>Subcode</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>Upgrade of local resources</td>
</tr>
<tr>
<td>2</td>
<td>Request external resources</td>
</tr>
</tbody>
</table>
<t><list style="empty"> <figure anchor="timegranted">
<t>(1) Upgrade of local resources</t> <name>Request More Negotiation Time: Granted</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<t>(2) Request external resources</t> +------+ +------+
</list></t>
<t><figure align="center" anchor="timegranted"
title="Request More Negotiation Time: Granted">
<artwork align="center"><![CDATA[+------+
+------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=======QUOTATION(Requested CPD)=====>| |=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========| |<========PROCESSING(time1)===========|
... ...
|<========PROCESSING(MoreTime)========| |<========PROCESSING(MoreTime)========|
|============ACK(TimeGranted)========>| |============ACK(TimeGranted)========>|
... ...
|<=========OFFER(Offered CPD)=========| |<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>| |=============PROCESSING=============>|
|==========ACCEPT(Agreed CPD)========>| |=========ACCEPT(Accepted CPD)=======>|
|<==========ACK(Agreed CPD)===========| |<=========ACK(Accepted CPD)==========|
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="timerejected">
<t><figure align="center" anchor="timerejected" <name>Request More Negotiation Time: Rejected</name>
title="Request More Negotiation Time: Rejected"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------+ +------+ +------+
+------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=======QUOTATION(Requested CPD)=====>| |=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========| |<========PROCESSING(time1)===========|
... ...
|<========PROCESSING(MoreTime)========| |<========PROCESSING(MoreTime)========|
|=====FAIL(More Time Rejected)=======>| |=====FAIL(More Time Rejected)=======>|
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="offer" numbered="true" toc="default">
<section anchor="offer" title="OFFER"> <name>OFFER</name>
<t>The format of the OFFER message is shown below:<?rfc subcompact="ye <t>The format of the OFFER message is shown below:</t>
s" ?></t> <sourcecode type="rbnf"><![CDATA[
<OFFER Message> ::= <VERSION>
<t><list hangIndent="20" style="hanging"> <METHOD_CODE>
<t hangText="&lt;OFFER Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <NONCE>
<VALIDITY_OFFER_TIME>
<t>&lt;TRANSACTION_ID&gt;</t> <OFFERED_CPD>
[<INFORMATION_ELEMENT>...]
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> ]]></sourcecode>
<t>The server answers
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t> a QUOTATION request received from the client with an OFFER message. Th
e offer will be
<t>&lt;NONCE&gt;</t> considered to be rejected by the client if no confirmation (i.e., an A
CCEPT
<t>&lt;VALIDITY_OFFER_TIME&gt;</t>
<t>&lt;OFFERED_CONNECTIVITY_PROVISIONING_DOCUMENT&gt;</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</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 message sent by the client) is received by the server before the
expiration of the validity time.</t> expiration of the validity time.</t>
<t>The server may include ACTIVATION_TYPE to indicate whether the <t>The server may include ACTIVATION_TYPE to indicate whether the
offer is about a permanent or scheduled activation type. The message offer is about a permanent or scheduled activation type. The message
may include ACTIVATION_SCHEDULE to indicate when the order is to be may include ACTIVATION_SCHEDULE to indicate when the order is to be
activated. If no such clause is included, the default mode is to activated. If no such clause is included, the default mode is to
assume that the order will be active once the agreed activation assume that the order will be active once the accepted activation
means are successfully invoked (e.g., Section 3.11 of <xref means are successfully invoked (e.g., <xref target="RFC7297" sectionFo
target="RFC7297"></xref> or <xref target="activate"></xref>).</t> rmat="of" section="3.11"/> or <xref target="activate" format="default"/>).</t>
</section> </section>
<section anchor="accept" numbered="true" toc="default">
<section anchor="accept" title="ACCEPT"> <name>ACCEPT</name>
<t>The format of the ACCEPT message is shown below:<?rfc subcompact="y <t>The format of the ACCEPT message is shown below:</t>
es" ?></t> <sourcecode type="rbnf"><![CDATA[
<ACCEPT Message> ::= <VERSION>
<t><list hangIndent="22" style="hanging"> <METHOD_CODE>
<t hangText="&lt;ACCEPT Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <NONCE>
<ACCEPTED_CPD>
<t>&lt;TRANSACTION_ID&gt;</t> [<INFORMATION_ELEMENT>...]
]]></sourcecode>
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> <t>This message is used by a client to
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t>
<t>&lt;NONCE&gt;</t>
<t>&lt;AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT&gt;</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</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 confirm the acceptance of an offer received from a server. The
fields of this message must be copied from the received OFFER fields of this message must be copied from the received OFFER
message. This message should not be sent after the validity time of message. This message should not be sent after the validity time of
the offer expires, as indicated by the server (<xref the offer expires, as indicated by the server (<xref target="offer" fo
target="offer"></xref>).</t> rmat="default"/>).</t>
</section> </section>
<section anchor="dec" numbered="true" toc="default">
<section anchor="dec" title="DECLINE"> <name>DECLINE</name>
<t>The format of the DECLINE message is shown below:<?rfc subcompact=" <t>The format of the DECLINE message is shown below:</t>
yes" ?></t> <sourcecode type="rbnf"><![CDATA[
<DECLINE Message> ::= <VERSION>
<t><list hangIndent="21" style="hanging"> <METHOD_CODE>
<t hangText="&lt;DECLINE Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <NONCE>
[<REASON>...]
<t>&lt;TRANSACTION_ID&gt;</t> ]]></sourcecode>
<t>The client may issue a DECLINE
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> message to reject an offer. CUSTOMER_ORDER_IDENTIFIER,
PROVIDER_ORDER_IDENTIFIER, TRANSACTION_ID, and NONCE are used by
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t>
<t>&lt;NONCE&gt;</t>
<t>[&lt;REASON&gt;...]</t>
</list><?rfc subcompact="no" ?>The client may 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 the server as keys to find the corresponding order. If an order
matches, the server changes the state of this order to "Cancelled" 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 and then returns an ACK with a copy of the Requested CPD to the
requesting client.</t> requesting client.</t>
<t>A DECLINE message may include an Information Element to indicate
<t>A DECLINE message may include an information element to indicate
the reason for declining an offer. The following codes are defined: the reason for declining an offer. The following codes are defined:
<list style="empty"> </t>
<t>1 (Unacceptable gap between the request and the offer)</t>
<t>2 (Conflict with another offer from another server)</t>
<t>3 (Activation type mismatch)</t>
</list></t>
<table align="left">
<name>DECLINE Message Codes</name>
<thead>
<tr>
<th>Code</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>Unacceptable gap between the request and the offer</td>
</tr>
<tr>
<td>2</td>
<td>Conflict with another offer from another server</td>
</tr>
<tr>
<td>3</td>
<td>Activation type mismatch</td>
</tr>
</tbody>
</table>
<t>If no order is found, the server returns a FAIL message to the <t>If no order is found, the server returns a FAIL message to the
requesting client. In order to prevent DDoS (Distributed Denial of requesting client. In order to prevent DDoS (Distributed Denial of
Service) attacks, the server should restrict the number of FAIL Service) attacks, the server should restrict the number of FAIL
messages sent to a requesting client. It may also rate-limit FAIL messages sent to a requesting client. It may also rate-limit FAIL
messages.</t> messages.</t>
<t>A flow example is shown in <xref target="decline" format="default"/
<t>A flow example is shown in <xref target="decline"></xref>.</t> >.</t>
<figure anchor="decline">
<t><figure align="center" anchor="decline" <name>DECLINE Flow Example</name>
title="DECLINE Flow Example"> <artwork align="center" name="" type="" alt=""><![CDATA[+------+
<artwork align="center"><![CDATA[+------+ +------+
+------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=======QUOTATION(Requested CPD)=====>| |=======QUOTATION(Requested CPD)=====>|
|<============PROCESSING==============| |<============PROCESSING==============|
|<=========OFFER(Offered CPD)=========| |<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>| |=============PROCESSING=============>|
|===============DECLINE==============>| |===============DECLINE==============>|
|<================ACK=================| |<================ACK=================|
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t></t>
</section> </section>
<section anchor="ack" numbered="true" toc="default">
<section anchor="ack" title="ACK"> <name>ACK</name>
<t>The format of the ACK message is shown below:<?rfc subcompact="yes" <t>The format of the ACK message is shown below:</t>
?></t> <sourcecode type="rbnf"><![CDATA[
<ACK Message> ::= <VERSION>
<t><list hangIndent="17" style="hanging"> <METHOD_CODE>
<t hangText="&lt;ACK Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> [<EXPECTED_RESPONSE_TIME>]
[<CPD>]
<t>&lt;TRANSACTION_ID&gt;</t> [<INFORMATION_ELEMENT>...]
]]></sourcecode>
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> <t>This message is issued by the server to
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t>
<t>[&lt;EXPECTED_RESPONSE_TIME&gt;]</t>
<t>[&lt;CONNECTIVITY_PROVISIONING_DOCUMENT&gt;]</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</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 close a CPNP transaction or by a client to grant more negotiation
time to the server.</t> time to the server.</t>
<t>This message is sent by the server as a response to an ACCEPT, <t>This message is sent by the server as a response to an ACCEPT,
WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message
must include the copy of the service description document as stored must include the copy of the service description (i.e., CPD for connec tivity services) as stored
by the server. In particular, the following considerations are taken by the server. In particular, the following considerations are taken
into account for connectivity provisioning services:<?rfc subcompact=" into account for connectivity provisioning services:</t>
yes"?><list <ul spacing="normal">
style="symbols"> <li>A copy of the Requested/Offered CPD is included by the server
<t>A copy of the requested/offered CPD is included by the server if it successfully handled a CANCEL message.</li>
if it successfully handled a CANCEL message.</t> <li>A copy of the Updated CPD is included by the server if it
successfully handled an UPDATE message.</li>
<t>A copy of the updated CPD is included by the server if it <li>A copy of the Offered 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 successfully handled an ACCEPT message in the context of a
QUOTATION transaction (refer to "Agreed CPD" in <xref QUOTATION transaction (refer to "Accepted CPD" in <xref target="cp
target="cpd"></xref>).</t> d" format="default"/>).</li>
<li>An Empty CPD is included by the server if it successfully
<t>An empty CPD is included by the server if it successfully handled a DECLINE or WITHDRAW message.</li>
handled a DECLINE or WITHDRAW message.<?rfc subcompact="no"?></t> </ul>
</list></t>
<t>A client may issue an ACK message as a response to a time <t>A client may issue an ACK message as a response to a time
extension request (conveyed in PROCESSING) received from the server. extension request (conveyed in PROCESSING) received from the server.
In such case, the ACK message must include an EXPECTED_RESPONSE_TIME 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 that is likely to be set to the time extension requested by the
server.</t> server.</t>
</section> </section>
<section anchor="cancel" numbered="true" toc="default">
<section anchor="cancel" title="CANCEL"> <name>CANCEL</name>
<t>The format of the CANCEL message is shown below:<?rfc subcompact="y <t>The format of the CANCEL message is shown below:</t>
es" ?></t> <sourcecode type="rbnf"><![CDATA[
<CANCEL Message> ::= <VERSION>
<t><list hangIndent="21" style="hanging"> <METHOD_CODE>
<t hangText="&lt;CANCEL Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
[<CPD>]
<t>&lt;SEQUENCE_NUMBER&gt;</t> ]]></sourcecode>
<t>The client can issue a CANCEL
<t>&lt;TRANSACTION_ID&gt;</t>
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t>
<t>[&lt;CONNECTIVITY_PROVISIONING_DOCUMENT&gt;]</t>
</list><?rfc subcompact="no" ?>The client can issue a CANCEL
message at any stage during the CPNP negotiation process before an message at any stage during the CPNP negotiation process before an
agreement is reached. CUSTOMER_AGREEMENT_IDENTIFIER and agreement is reached. The CUSTOMER_ORDER_IDENTIFIER and
TRANSACTION_ID are used by the server as keys to find the TRANSACTION_ID are used by the server as keys to find the
corresponding order. If a quotation order matches, the server corresponding order. If a quotation order matches, the server
changes the state of this quotation order to "Cancelled" and then changes the state of this quotation order to "Cancelled" and then
returns an ACK with a copy of the requested CPD to the requesting returns an ACK with a copy of the Requested CPD to the requesting
client.</t> client.</t>
<t>If no quotation order is found, the server returns a FAIL message <t>If no quotation order is found, the server returns a FAIL message
to the requesting client.</t> to the requesting client.</t>
</section> </section>
<section anchor="with" numbered="true" toc="default">
<section anchor="with" title="WITHDRAW"> <name>WITHDRAW</name>
<t>The format of the WITHDRAW message is shown below:<?rfc subcompact= <t>The format of the WITHDRAW message is shown below:</t>
"yes" ?></t> <sourcecode type="rbnf"><![CDATA[
<WITHDRAW Message> ::= <VERSION>
<t><list hangIndent="23" style="hanging"> <METHOD_CODE>
<t hangText="&lt;WITHDRAW Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <NONCE>
[<ACCEPTED_CPD>]
<t>&lt;TRANSACTION_ID&gt;</t> [<INFORMATION_ELEMENT>...]
]]></sourcecode>
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> <t>This message is used to withdraw an offer
already accepted by the Customer. <xref target="withdraw" format="defa
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t> ult"/>
<t>&lt;NONCE&gt;</t>
<t>[&lt;AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT&gt;]</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</t>
</list></t>
<t><?rfc subcompact="no" ?>This message is used to withdraw an offer
already accepted by the Customer. <xref target="withdraw"></xref>
shows a typical usage of this message.</t> shows a typical usage of this message.</t>
<figure anchor="withdraw">
<t><figure align="center" anchor="withdraw" <name>WITHDRAW Flow Example</name>
title="WITHDRAW Flow Example"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+------+ +------+ +------+
+------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|============WITHDRAW(CPD)===========>| |============WITHDRAW(CPD)===========>|
|<============PROCESSING==============| |<============PROCESSING==============|
|<===========ACK(Empty CPD)===========| |<===========ACK(Empty CPD)===========|
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The WITHDRAW message must include the same <t>The WITHDRAW message must include the same
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
NONCE as those used when creating the order.</t> NONCE as those used when creating the order.</t>
<t>Upon receipt of a WITHDRAW message, the server checks whether an <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 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 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 an Empty CPD is returned to the requesting client. If no order is
found, the server returns a FAIL message to the requesting found, the server returns a FAIL message to the requesting
client.</t> client.</t>
</section> </section>
<section anchor="upd" numbered="true" toc="default">
<section anchor="upd" title="UPDATE"> <name>UPDATE</name>
<t>The format of the UPDATE message is shown below:<?rfc subcompact="y <t>The format of the UPDATE message is shown below:</t>
es" ?></t> <sourcecode type="rbnf"><![CDATA[
<UPDATE Message> ::= <VERSION>
<t><list hangIndent="21" style="hanging"> <METHOD_CODE>
<t hangText="&lt;UPDATE Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <NONCE>
<EXPECTED_RESPONSE_TIME>
<t>&lt;TRANSACTION_ID&gt;</t> <REQUESTED_CPD>
[<INFORMATION_ELEMENT>...]
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> ]]></sourcecode>
<t>This message is sent by the CPNP client
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t> to update an existing service agreement (e.g., Accepted
CPD). The UPDATE message must include the same
<t>&lt;NONCE&gt;</t> CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
<t>&lt;EXPECTED_RESPONSE_TIME&gt;</t>
<t>&lt;REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT&gt;</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</t>
</list></t>
<t><?rfc subcompact="no" ?>This message is sent by the CPNP client
to update an existing service agreement (e.g., connectivity
provisioning agreement). The UPDATE message must include the same
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE as those used when creating the order. The CPNP client NONCE as those used when creating the order. The CPNP client
includes a new service description (e.g., updated CPD) which includes a new service description (e.g., Updated CPD) that
integrates the requested modifications. A new Transaction_ID must be integrates the requested modifications. A new Transaction_ID must be
assigned by the client.</t> assigned by the client.</t>
<t>Upon receipt of an UPDATE message, the server checks whether an <t>Upon receipt of an UPDATE message, the server checks whether an
order, having state "Completed", matches order, having state "Completed", matches
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
NONCE. <?rfc subcompact="yes"?><list style="symbols"> NONCE. </t>
<t>If no order is found, the CPNP server generates a FAIL error <ul spacing="normal">
with the appropriate error code (<xref <li>If no order is found, the CPNP server generates a FAIL error
target="fail"></xref>).</t> with the appropriate error code (<xref target="fail" format="defau
lt"/>).</li>
<li>
<t>If an order is found, the server checks whether it can honor <t>If an order is found, the server checks whether it can honor
the request:<list style="symbols"> the request:</t>
<t>A FAIL message is sent to the client if the server cannot <ul spacing="normal">
<li>A FAIL message is sent to the client if the server cannot
honor the request. The client may initiate a new PQO honor the request. The client may initiate a new PQO
negotiation cycle (that is, a new UPDATE).</t> negotiation cycle (that is, send a new UPDATE message).</li>
<li>
<t>An OFFER message including the updated clauses (e.g., <t>An OFFER message including the updated clauses (e.g.,
updated connectivity provisioning document) is sent to the Updated CPD) is sent to the
client. For example, the server maintains an order for client. For example, the server maintains an order for
provisioning a VPN service that connects sites A, B, and C. provisioning a VPN service that connects sites A, B, and C.
If the client sends an UPDATE message to remove site C, only 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 sites A and B will be included in the OFFER sent by the
server to the requesting client.<vspace server to the requesting client.</t>
blankLines="1" />Note that the cycle that is triggered by an <t>Note that the cycle that is triggered by an
UPDATE message is also considered as a negotiation UPDATE message is also considered to be a negotiation
cycle.<?rfc subcompact="no"?></t> cycle.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ul>
<t>A flow chart that illustrates the use of UPDATE operation is <t>A flow chart that illustrates the use of UPDATE operation is
shown in <xref target="update"></xref>.<figure align="center" shown in <xref target="update" format="default"/>.</t>
anchor="update" title="UPDATE Flow Example"> <figure anchor="update">
<artwork align="center"><![CDATA[+------+ <name>UPDATE Flow Example</name>
+------+ <artwork align="center" name="" type="" alt=""><![CDATA[
+------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|=========UPDATE(Requested CPD)======>| |=========UPDATE(Requested CPD)======>|
|<============PROCESSING==============| |<============PROCESSING==============|
|<=========OFFER(Updated CPD)=========| |<=========OFFER(Updated CPD)=========|
|=============PROCESSING=============>| |=============PROCESSING=============>|
|==========ACCEPT(Updated CPD)=======>| |==========ACCEPT(Updated CPD)=======>|
|<==========ACK(Updated CPD)==========| |<==========ACK(Updated CPD)==========|
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t></t>
</section> </section>
<section anchor="fail" numbered="true" toc="default">
<section anchor="fail" title="FAIL"> <name>FAIL</name>
<t>The format of the FAIL message is shown below:<?rfc subcompact="yes <t>The format of the FAIL message is shown below:</t>
" ?></t> <sourcecode type="rbnf"><![CDATA[
<FAIL Message> ::= <VERSION>
<t><list hangIndent="19" style="hanging"> <METHOD_CODE>
<t hangText="&lt;FAIL Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <STATUS_CODE>
]]></sourcecode>
<t>&lt;TRANSACTION_ID&gt;</t> <t>This message is sent in the following
cases:</t>
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> <ul spacing="normal">
<li>The server cannot honor an order received from the client
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t> (i.e., received in a QUOTATION or UPDATE request).</li>
<li>The server encounters an error when processing a CPNP request
<t>&lt;STATUS_CODE&gt;</t> received from the client.</li>
</list></t> <li>The client cannot grant more time to the server. This is a
<t><?rfc subcompact="no" ?>This message is sent in the following
cases:<?rfc subcompact="yes"?><list style="symbols">
<t>The server cannot 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 cannot grant more time to the server. This is a
response to a time extension request carried in a PROCESSING response to a time extension request carried in a PROCESSING
message.</t> message.</li>
</list></t> </ul>
<t>The status code indicates the error code. The following codes are <t>The status code indicates the error code. The following codes are
supported:<list hangIndent="5" style="hanging"> supported:</t>
<t hangText="1 (Message Validation Error): "><vspace <table>
blankLines="0" />The message cannot be validated (see <xref <name>FAIL Message Error Codes</name>
target="validation"></xref>).</t> <thead>
<tr>
<t hangText="2 (Authentication Required):"><vspace <th>Status Code</th>
blankLines="0" />The request cannot be handled because <th>Error Code</th>
authentication is required.</t> <th>Description</th>
</tr>
<t hangText="3 (Authorization Failed): "><vspace </thead>
blankLines="0" />The request cannot be handled because <tbody>
authorization failed.</t> <tr>
<td>1</td>
<t hangText="4 (Administratively prohibited): "><vspace <td>Message Validation Error</td>
blankLines="0" />The request cannot be handled because of <td>The message cannot be validated (see <xref target="validation"
administrative policies.</t> format="default"/>).</td>
</tr>
<t hangText="5 (Out of Resources): "><vspace <tr>
blankLines="0" />The request cannot be honored because resources <td>2</td>
(e.g., capacity) are insufficient.</t> <td>Authentication Required</td>
<td>The request cannot be handled because authentication is required.</td>
<t hangText="6 (Network Presence Error): "><vspace </tr>
blankLines="0" />The request cannot be honored because there is <tr>
no network presence.</t> <td>3</td>
<td>Authorization Failed</td>
<t hangText="7 (More Time Rejected):"><vspace <td>The request cannot be handled because authorization failed.</td>
blankLines="0" />The request to extend the time for negotiation </tr>
is rejected by the client.</t> <tr>
<td>4</td>
<t hangText="8 (Unsupported Activation Type):"><vspace <td>Administratively prohibited</td>
blankLines="0" />The request cannot be handled because the <td>The request cannot be handled because of administrative policies.</td>
requested activation type is not supported.</t> </tr>
</list></t> <tr>
<td>5</td>
<t><?rfc subcompact="no"?></t> <td>Out of Resources</td>
<td>The request cannot be honored because resources (e.g., capacity) are insuffi
cient.</td>
</tr>
<tr>
<td>6</td>
<td>Network Presence Error</td>
<td>The request cannot be honored because there is no network presence.</td>
</tr>
<tr>
<td>7</td>
<td>More Time Rejected</td>
<td>The request to extend the time for negotiation is rejected by the client.</t
d>
</tr>
<tr>
<td>8</td>
<td>Unsupported Activation Type</td>
<td>The request cannot be handled because the requested activation type is not
supported.</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="activate" numbered="true" toc="default">
<section anchor="activate" title="ACTIVATE"> <name>ACTIVATE</name>
<t>The format of the ACTIVATE message is shown below:<?rfc subcompact= <t>The format of the ACTIVATE message is shown below:</t>
"yes" ?></t> <sourcecode type="rbnf"><![CDATA[
<ACTIVATE Message> ::= <VERSION>
<t><list hangIndent="21" style="hanging"> <METHOD_CODE>
<t hangText="&lt;ACTIVATE Message&gt; ::=">&lt;VERSION&gt;</t> <SEQUENCE_NUMBER>
<TRANSACTION_ID>
<t>&lt;METHOD_CODE&gt;</t> <CUSTOMER_ORDER_IDENTIFIER>
<PROVIDER_ORDER_IDENTIFIER>
<t>&lt;SEQUENCE_NUMBER&gt;</t> <NONCE>
<ACTIVATION_SCHEDULE>
<t>&lt;TRANSACTION_ID&gt;</t> [<INFORMATION_ELEMENT>...]
]]></sourcecode>
<t>&lt;CUSTOMER_AGREEMENT_IDENTIFIER&gt;</t> <t>This message is sent by the CPNP client
<t>&lt;PROVIDER_AGREEMENT_IDENTIFIER&gt;</t>
<t>&lt;NONCE&gt;</t>
<t>&lt;ACTIVATION_SCHEDULE&gt;</t>
<t>[&lt;INFORMATION_ELEMENT&gt;...]</t>
</list></t>
<t><?rfc subcompact="no" ?>This message is sent by the CPNP client
to request the activation of an existing service agreement. The to request the activation of an existing service agreement. The
message must include the same CUSTOMER_AGREEMENT_IDENTIFIER, message must include the same CUSTOMER_ORDER_IDENTIFIER,
PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating
the order. The CPNP client may includes a schedule target for the order. The CPNP client may include a schedule target for
activating this order. A new Transaction_ID must be assigned by the activating this order. A new Transaction_ID must be assigned by the
client.</t> client.</t>
<t>Upon receipt of an ACTIVATE message, the server checks whether an <t>Upon receipt of an ACTIVATE message, the server checks whether an
order, having state "Completed", matches order, having state "Completed", matches
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
NONCE. <?rfc subcompact="yes"?><list style="symbols"> NONCE. </t>
<t>If no completed order is found, the CPNP server generates a <ul spacing="normal">
FAIL error with the appropriate error code (<xref <li>If no completed order is found, the CPNP server generates a
target="fail"></xref>).</t> FAIL error with the appropriate error code (<xref target="fail" fo
rmat="default"/>).</li>
<li>
<t>If an order is found, the server checks whether it can honor <t>If an order is found, the server checks whether it can honor
the request:<list style="symbols"> the request:</t>
<t>A FAIL message is sent to the client if the server cannot <ul spacing="normal">
<li>A FAIL message is sent to the client if the server cannot
honor the request (e.g., out of resources or explicit honor the request (e.g., out of resources or explicit
activation wasn't negotiated with this client).</t> activation wasn't negotiated with this client).</li>
<li>An ACK is sent to the client to confirm that the
<t>An ACK is sent to the client to confirm that the immediate activation (or deactivation) of the order or its
immediate activation (or de-activation) of the order or its
successful scheduling if a non-null ACTIVATION_SCHEDULE was successful scheduling if a non-null ACTIVATION_SCHEDULE was
included in the request. Note that setting included in the request. Note that setting
ACTIVATION_SCHEDULE to 0 in an ACTIVATE request has a ACTIVATION_SCHEDULE to 0 in an ACTIVATE request has a
special meaning: it is used to request a de-activation of an special meaning: it is used to request a deactivation of an
agreed order. <?rfc subcompact="no"?></t> accepted order. </li>
</list></t> </ul>
</list></t> </li>
</ul>
<t><xref target="activateex"></xref> illustrates the use of ACTIVATE <t><xref target="activateex" format="default"/> illustrates the use of
operation.<figure align="center" anchor="activateex" the ACTIVATE
title="ACTIVATE Flow Example"> operation.</t>
<artwork align="center"><![CDATA[+------+ <figure anchor="activateex">
+------+ <name>ACTIVATE Flow Example</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+------+ +------+
|Client| |Server| |Client| |Server|
+------+ +------+ +------+ +------+
|================ACTIVATE()==========>| |================ACTIVATE()==========>|
|<==============ACK()=================| |<==============ACK()=================|
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t></t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="validation" numbered="true" toc="default">
<section anchor="validation" title="CPNP Message Validation"> <name>CPNP Message Validation</name>
<t>Both client and server proceed with CPNP message validation. The <t>Both the client and the server proceed with CPNP message validation. Th
e
following tables summarize the validation checks to be followed.</t> following tables summarize the validation checks to be followed.</t>
<section numbered="true" toc="default">
<section title="On the Client Side"> <name>On the Client Side</name>
<t></t> <table align="left">
<name>Client Side Validation Checks</name>
<texttable align="left" style="headers"> <thead>
<ttcol align="left">Operation</ttcol> <tr>
<th align="left">Operation</th>
<ttcol align="left">Validation Checks</ttcol> <th align="left">Validation Checks</th>
</tr>
<c>PROCESSING</c> </thead>
<tbody>
<c>{Source IP address, source port number, destination IP address, <tr>
<td align="left">PROCESSING</td>
<td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier} destination port number, Transaction-ID, Customer Order Identifier}
must match an existing PQO with a state set to "PQOSent". The 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 carried in the packet must be larger than the
sequence number maintained by the client.</c> sequence number maintained by the client.</td>
</tr>
<c>OFFER</c> <tr>
<td align="left">OFFER</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier} destination port number, Transaction-ID, Customer Order Identifier}
must match an existing order with state set to "PQOSent" or {Source must match an existing order with state set to "PQOSent", or {Source
IP address, source port number, destination IP address, destination IP address, source port number, destination IP address, destination
port number, Transaction-ID, Customer Order Identifier, Provider port number, Transaction-ID, Customer Order Identifier, Provider
Order Identifier} must match an existing order with a state set to Order Identifier} must match an existing order with a state set to
"ServerProcessing". The sequence number carried in the packet must "ServerProcessing". The sequence number carried in the packet must
be larger than the sequence number maintained by the client.</c> be larger than the sequence number maintained by the client.</td>
</tr>
<c>ACK (QUOTATION Transaction)</c> <tr>
<td align="left">ACK (QUOTATION Transaction)</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier, destination port number, Transaction-ID, Customer Order Identifier,
Provider Order Identifier, Offered Connectivity Provisioning Order} Provider Order Identifier, Offered Connectivity Provisioning Document}
must match an order with a state set to "AcceptSent". The sequence must match an order with a state set to "AcceptSent". The sequence
number carried in the packet must be larger than the sequence number number carried in the packet must be larger than the sequence number
maintained by the client.</c> maintained by the client.</td>
</tr>
<c>ACK (UPDATE Transaction)</c> <tr>
<td align="left">ACK (UPDATE Transaction)</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier, destination port number, Transaction-ID, Customer Order Identifier,
Provider Order Identifier, Updated Connectivity Provisioning Order} Provider Order Identifier, Updated Connectivity Provisioning Document}
must match an order with a state set to "AcceptSent". The sequence must match an order with a state set to "AcceptSent". The sequence
number carried in the packet must be larger than the sequence number number carried in the packet must be larger than the sequence number
maintained by the client.</c> maintained by the client.</td>
</tr>
<c>ACK (WITHDRAW Transaction)</c> <tr>
<td align="left">ACK (WITHDRAW Transaction)</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier, destination port number, Transaction-ID, Customer Order Identifier,
Provider Order Identifier, Empty Connectivity Provisioning Order} Provider Order Identifier, Empty Connectivity Provisioning Document}
must match an order with a state set to "Cancelled". The sequence must match an order with a state set to "Cancelled". The sequence
number carried in the packet must be larger than the sequence number number carried in the packet must be larger than the sequence number
maintained by the client.</c> maintained by the client.</td>
</texttable> </tr>
</tbody>
<t></t> </table>
</section> </section>
<section numbered="true" toc="default">
<section title="On the Server Side"> <name>On the Server Side</name>
<t></t> <table align="left">
<name>Server Side Validation Checks</name>
<texttable align="left" style="headers"> <thead>
<ttcol>Method</ttcol> <tr>
<th align="left">Method</th>
<ttcol align="left">Validation Checks</ttcol> <th align="left">Validation Checks</th>
</tr>
<c>QUOTATION</c> </thead>
<tbody>
<c>The source IP address passes existing access filters (if any). <tr>
<td align="left">QUOTATION</td>
<td align="left">The source IP address passes existing access filt
ers (if any).
The sequence number carried in the packet must not be lower than the The sequence number carried in the packet must not be lower than the
sequence number maintained by the server.</c> sequence number maintained by the server.</td>
</tr>
<c>PROCESSING</c> <tr>
<td align="left">PROCESSING</td>
<c>The sequence number carried in the packet must be greater than <td align="left">The sequence number carried in the packet must be
the sequence number maintained by the server.</c> greater than
the sequence number maintained by the server.</td>
<c>CANCEL</c> </tr>
<tr>
<c>{Source IP address, source port number, destination IP address, <td align="left">CANCEL</td>
<td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier} destination port number, Transaction-ID, Customer Order Identifier}
must match an order with state set to "PQOReceived" or must match an order with state set to "PQOReceived" or
"OfferProposed" or "ProcessingReceived" or "AcceptReceived ". The "OfferProposed" or "ProcessingReceived" or "AcceptReceived". The
sequence number carried in the packet must be greater than the sequence number carried in the packet must be greater than the
sequence number maintained by the server.</c> sequence number maintained by the server.</td>
</tr>
<c>ACCEPT</c> <tr>
<td align="left">ACCEPT</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier, destination port number, Transaction-ID, Customer Order Identifier,
Provider Order Identifier, Nonce, Offered Connectivity Provisioning Provider Order Identifier, Nonce, Offered Connectivity Provisioning
Order} must match an order with state set to "OfferProposed" or Document} must match an order with state set to "OfferProposed" or
"ProcessingReceived". The sequence number carried in the packet must "ProcessingReceived". The sequence number carried in the packet must
be greater than the sequence number maintained by the server.</c> be greater than the sequence number maintained by the server.</td>
</tr>
<c>FAIL</c> <tr>
<td align="left">FAIL</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier, destination port number, Transaction-ID, Customer Order Identifier,
Provider Order Identifier} must match an order with state set to Provider Order Identifier} must match an order with state set to
"AwaitingProcessing" and for which a request to grant more time to "AwaitingProcessing" and for which a request to grant more time to
process an offer was requested. The sequence number carried in the process an offer was requested. The sequence number carried in the
packet must be greater than the sequence number maintained by the packet must be greater than the sequence number maintained by the
server.</c> server.</td>
</tr>
<c>DECLINE</c> <tr>
<td align="left">DECLINE</td>
<c>{Source IP address, source port number, destination IP address, <td align="left">{Source IP address, source port number, destinati
on IP address,
destination port number, Transaction-ID, Customer Order Identifier, destination port number, Transaction-ID, Customer Order Identifier,
Provider Order Identifier, Nonce} must match an order with state set Provider Order Identifier, Nonce} must match an order with state set
to "OfferProposed" or "ProcessingReceived". The sequence number to "OfferProposed" or "ProcessingReceived". The sequence number
carried in the packet must be greater than the sequence number carried in the packet must be greater than the sequence number
maintained by the server.</c> maintained by the server.</td>
</tr>
<c>UPDATE</c> <tr>
<td align="left">UPDATE</td>
<c>The source IP address passes existing access filters (if any) and <td align="left">The source IP address passes existing access filt
ers (if any), and
{Customer Order Identifier, Provider Order Identifier, Nonce} must {Customer Order Identifier, Provider Order Identifier, Nonce} must
match an existing order with state "Completed".</c> match an existing order with state "Completed".</td>
</tr>
<c>WITHDRAW</c> <tr>
<td align="left">WITHDRAW</td>
<c>The source IP address passes existing access filters (if any) and <td align="left">The source IP address passes existing access filt
ers (if any), and
{Customer Order Identifier, Provider Order Identifier, Nonce} must {Customer Order Identifier, Provider Order Identifier, Nonce} must
match an existing order with state "Completed".</c> match an existing order with state "Completed".</td>
</tr>
<c>ACTIVATE</c> <tr>
<td align="left">ACTIVATE</td>
<c>The source IP address passes existing access filters (if any) and <td align="left">The source IP address passes existing access filt
ers (if any), and
{Customer Order Identifier, Provider Order Identifier, Nonce} must {Customer Order Identifier, Provider Order Identifier, Nonce} must
match an existing order with state "Completed" for which the match an existing order with a state of "Completed" and its
activation procedure is tagged to be explicit.</c> activation procedure set to explicit.</td>
</texttable> </tr>
</tbody>
<t></t> </table>
</section> </section>
</section> </section>
<section anchor="behavior" numbered="true" toc="default">
<section anchor="behavior" title="Theory of Operation"> <name>Theory of Operation</name>
<t>Both CPNP client and server proceed with message validation checks as <t>Both the CPNP client and server proceed with message validation checks
specified in <xref target="validation"></xref>.</t> as
specified in <xref target="validation" format="default"/>.</t>
<section title="Client Behavior"> <section numbered="true" toc="default">
<t></t> <name>Client Behavior</name>
<section anchor="creation" numbered="true" toc="default">
<section anchor="creation" title="Order Negotiation Cycle"> <name>Order Negotiation Cycle</name>
<t>To place a provisioning quotation order, the client first <t>To place a PQO, the client first
initiates a local quotation order object identified by a unique initiates a local quotation order object identified by a unique
identifier assigned by the client (Client Order Identifier). The identifier assigned by the client (Client Order Identifier). The
state of the quotation order is set to "Created". The client then state of the quotation order is set to "Created". The client then
generates a QUOTATION request which includes the assigned generates a QUOTATION request that includes the assigned
identifier, possibly an expected response time, a Transaction-ID, identifier, possibly an expected response time, a Transaction-ID,
and a Requested Service (e.g., Requested Connectivity Provisioning and a requested service (e.g., Requested CPD). The client may include
Document). The client may include additional Information Elements additional Information Elements
such as Negotiation Options or Activation Type.</t> such as Customer Description or Negotiation Options.</t>
<t>The client may be configured to not enforce negotiation checks on <t>The client may be configured to not enforce negotiation checks on
EXPECTED_OFFER_TIME; if so, no EXPECTED_RESPONSE_TIME attribute (or EXPECTED_OFFER_TIME; if so, the client should either not include
EXPECTED_RESPONSE_TIME set to infinite) should be included in the the EXPECTED_RESPONSE_TIME attribute in the PQO or it should set
quotation order.</t> the attribute to infinite. </t>
<t>Once the request is sent to the server, the state of the request <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 is set to "PQOSent", and if a response time is included in
the quotation order, is set to the expiration time as included in the quotation order, a timer is set to the expiration time as included
in
the QUOTATION request. The client also maintains a copy of the CPNP the QUOTATION request. The client also maintains a copy of the CPNP
session entry details used to generate the QUOTATION request. The session entry details used to generate the QUOTATION request. The
CPNP client must listen on the same port number that it used to send CPNP client must listen on the same port number that it used to send
the QUOTATION request.</t> the QUOTATION request.</t>
<t>If no answer is received from the server before the <t>If no answer is received from the server before the
retransmission timer expires (i.e., RETRANS_TIMER, <xref retransmission timer expires (i.e., RETRANS_TIMER, <xref target="timer
target="timers"></xref>), the client retransmits the message until s" format="default"/>), the client retransmits the message until
maximum retry is reached (e.g., 3 times). The same sequence number maximum retry is reached (e.g., three times). The same sequence number
is used for retransmitted packets.</t> is used for retransmitted packets.</t>
<t>If a FAIL message is received, the client may decide to issue <t>If a FAIL message is received, the client may decide to issue
another (corrected) request towards the same server, cancel the another (corrected) request towards the same server, cancel the
local order, or contact another server. The behavior of the client local order, or contact another server. The behavior of the client
depends on the error code returned by the server in the FAIL depends on the error code returned by the server in the FAIL
message.</t> message.</t>
<t>If a PROCESSING message matching the CPNP session entry (<xref targ
<t>If a PROCESSING message matching the CPNP session entry (<xref et="session" format="default"/>) is received, the client updates the CPNP
target="session"></xref>) is received, the client updates the CPNP session entry with the PROVIDER_ORDER_IDENTIFIER information. If
session entry with the PROVIDER_AGREEMENT_IDENTIFIER information. If
the client does not accept the expected offer time that may have the client does not accept the expected offer time that may have
been indicated in the PROCESSING message, the client may decide to been indicated in the PROCESSING message, the client may decide to
cancel the quotation order. If the client accepts the cancel the quotation order. If the client accepts the
EXPECTED_OFFER_TIME, it changes the state of the order to EXPECTED_OFFER_TIME, it changes the state of the order to
"ServerProcessing" and sets a timer to the value of "ServerProcessing" and sets a timer to the value of
EXPECTED_OFFER_TIME. If no offer is made before the timer expires, EXPECTED_OFFER_TIME. If no offer is made before the timer expires,
the client changes the state of the order to "Cancelled".</t> the client changes the state of the order to "Cancelled".</t>
<t>As a response to a time extension request (conveyed in a <t>As a response to a time extension request (conveyed in a
PROCESSING message that included a new EXPECTED_OFFER_TIME), the PROCESSING message that included a new EXPECTED_OFFER_TIME), the
client may grant this extension by issuing an ACK message or reject client may either grant this extension by issuing an ACK message or re
the time extension with a FAIL message having a status code set to ject
the time extension by issuing a FAIL message with a status code set to
"More Time Rejected".</t> "More Time Rejected".</t>
<t>If an OFFER message matching the CPNP session entry is received, <t>If an OFFER message matching the CPNP session entry is received,
the client checks if a PROCESSING message having the same the client checks if a PROCESSING message having the same
PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If PROVIDER_ORDER_IDENTIFIER has been received from the server. If
a PROCESSING message was already received for the same order but the a PROCESSING message was already received for the same order, but the
PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included PROVIDER_ORDER_IDENTIFIER does not match the identifier included
in the OFFER message, the client silently ignores the message. If a in the OFFER message, the client silently ignores the message. If a
PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was PROCESSING message with the same PROVIDER_ORDER_IDENTIFIER was
already received and matches the CPNP transaction identifier, the already received and matches the CPNP transaction identifier, the
client changes the state of the order to "OfferReceived" and sets a client changes the state of the order to "OfferReceived" and sets a
timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER
message.</t> message.</t>
<t>If an offer is received from the server (i.e., as documented in <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 an OFFER message), the client may accept or reject the offer. The
client accepts the offer by generating an ACCEPT message which client accepts the offer by generating an ACCEPT message that
confirms that the client agrees to subscribe to the offer documented confirms that the client agrees to subscribe to the offer documented
in the OFFER message; the state of the order is passed to in the OFFER message; the state of the order is passed to
"AcceptSent". The transaction is terminated if an ACK message is "AcceptSent". The transaction is terminated if an ACK message is
received from the server. If no ACK is received from the server, the received from the server. If no ACK is received from the server, the
client proceeds with the retransmission of the ACCEPT message until client proceeds with the retransmission of the ACCEPT message until
the maximum retry is reached (<xref target="retrans"></xref>).</t> the maximum retry is reached (<xref target="retrans" format="default"/
>).</t>
<t>The client may also decide to reject the offer by sending a <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 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 "Cancelled". If an offer is not acceptable to the client, the client
may decide to contact a new server or submit another order to the may decide to contact a new server or submit another order to the
same server. Guidelines to issue an updated order or terminate the same server. Guidelines to issue an updated order or terminate the
negotiation are specific to the client.</t> negotiation are specific to the client.</t>
<t>An order can be activated (or deactivated) using the ACTIVATE
<t>An order can be activated (or de-activated) using the ACTIVATE message or other accepted activation means (<xref
message or other agreed activation means (Section 3.11 of <xref target="RFC7297" sectionFormat="of" section="3.11"/>).</t>
target="RFC7297"></xref>).</t>
</section> </section>
<section anchor="corw" numbered="true" toc="default">
<section anchor="corw" title="Order Withdrawal Cycle"> <name>Order Withdrawal Cycle</name>
<t>A client may withdraw a completed order. This is achieved by <t>A client may withdraw a completed order. This is achieved by
issuing a WITHDRAW message. This message must include Customer Order issuing a WITHDRAW message. This message must include the Customer Ord
Identifier, Provider Identifier, and Nonce returned during the order er
negotiation cycle, as specified in <xref Identifier, Provider Order Identifier, and Nonce returned during the o
target="creation"></xref>.</t> rder
negotiation cycle, as specified in <xref target="creation" format="def
ault"/>.</t>
<t>If no ACK is received from the server, the client proceeds with <t>If no ACK is received from the server, the client proceeds with
the retransmission of the message. If no ACK is received after the the retransmission of the message. If no ACK is received after the
maximum retry is exhausted, the client should log the information maximum retry is exhausted, the client should log the information
and must send an alarm to the administrator. If there is no specific and must send an alarm to the administrator. If there is no specific
instruction from the administrator, the client should schedule instruction from the administrator, the client should schedule
another Withdrawal cycle. The client must not retry this Withdrawal another Withdrawal cycle. The client must not retry this Withdrawal
cycle more frequently than every 300 seconds and must not retry more cycle more frequently than every 300 seconds and must not retry more
frequently than every 60 seconds.</t> frequently than every 60 seconds.</t>
</section> </section>
<section anchor="cordu" numbered="true" toc="default">
<section anchor="cordu" title="Order Update Cycle"> <name>Order Update Cycle</name>
<t>A client may update a completed order. This is achieved by <t>A client may update a completed order. This is achieved by
issuing an UPDATE message. This message must include Customer Order issuing an UPDATE message. This message must include the Customer Orde
Identifier, Provider Order Identifier and Nonce returned during the r
order negotiation cycle specified in <xref Identifier, Provider Order Identifier, and Nonce returned during the
target="creation"></xref>. The client must include in the UPDATE order negotiation cycle specified in <xref target="creation" format="d
message an updated CPD with the requested changes.</t> efault"/>. 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 <t>The subsequent message exchange is similar to what is documented in
<xref target="creation"></xref>.</t> <xref target="creation" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Server Behavior"> <name>Server Behavior</name>
<t></t> <section anchor="handling" numbered="true" toc="default">
<name>Order Processing</name>
<section anchor="handling" title="Order Processing">
<t>Upon receipt of a QUOTATION message from a client, the server <t>Upon receipt of a QUOTATION message from a client, the server
sets a CPNP session, stores Transaction-ID and generates a Provider sets a CPNP session, stores the Transaction-ID, and generates a Provid
Order Identifier. Once preliminary validation checks are completed ( er
<xref target="validation"></xref>), the server may return a Order Identifier. Once preliminary validation checks are completed
(<xref target="validation" format="default"/>), the server may return
a
PROCESSING message to inform the client that the quotation order is PROCESSING message to inform the client that the quotation order is
received and it is under processing; the server may include an received and it is under processing; the server may include an
expected offer time to notify the client by when an offer will be expected offer time to notify the client by when an offer will be
proposed. An order with state "AwaitingProcessing" is created by the proposed. An order with state "AwaitingProcessing" is created by the
server. The server runs its decision-making process to decide which server. The server runs its decision-making process to decide which
offer it can make to honor the received order. The offer should be offer it can make to honor the received order. The offer should be
made before the expected offer time expires.</t> made before the expected offer time expires.</t>
<t>If the server cannot make an offer, it sends backs a FAIL message <t>If the server cannot make an offer, it sends backs a FAIL message
with the appropriate error code.</t> with the appropriate error code (<xref target="fail" format="default"/
>).</t>
<t>If the server requires more negotiation time, it must send a <t>If the server requires more negotiation time, it must send a
PROCESSING message with a new EXPECTED_OFFER_TIME. The client may PROCESSING message with a new EXPECTED_OFFER_TIME. The client may
grant this extension by issuing an ACK message or reject the time 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 extension by issuing a FAIL message with the status code set to "More Time
Rejected". If the client doesn't grant more time, the server must Rejected". If the client doesn't grant more time, the server must
answer before the initial expected offer time; otherwise the client answer before the initial expected offer time; otherwise, the client
will decline the quotation order.</t> will decline the quotation order.</t>
<t>If the server can honor the request, or if it can make an offer tha
<t>If the server can honor the request or it can make an offer that t
meets only some of the requirements, it creates an OFFER message. meets only some of the requirements, it creates an OFFER message.
The server must indicate the Transaction-ID, Customer Order The server must indicate the Transaction-ID, the Customer Order
Identifier as indicated in the QUOTATION message, and the Provider Identifier as indicated in the QUOTATION message, and the Provider
Order Identifier generated for this order. The server must also Order Identifier generated for this order. The server must also
include Nonce and the offered service document (e.g., offered include the Nonce and the offered service document (e.g., Offered
Connectivity Provisioning Document). The server includes an offer CPD). The server includes an offer
validity time as well. Once sent to the client, the server changes validity time as well. Once sent to the client, the server changes
the state of the order to "OfferProposed" and a timer set to the the state of the order to "OfferProposed", and a timer set to the
validity time is initiated.</t> validity time is initiated.</t>
<t>If the server determines that additional network resources from <t>If the server determines that additional network resources from
another network provider are needed to accommodate a quotation another Network Provider are needed to accommodate a quotation
order, it will create child PQO(s) and will behave as a CPNP client order, it will create child PQO(s) and will behave as a CPNP client
to negotiate child PQO(s) with possible partnering providers (see to negotiate child PQO(s) with possible partnering Providers (see
<xref target="child"></xref>).</t> <xref target="child" format="default"/>).</t>
<t>If no PROCESSING, ACCEPT, or DECLINE message is received before <t>If no PROCESSING, ACCEPT, or DECLINE message is received before
the expiry of the RETRANS_TIMER, the server re-sends the same offer the expiry of the RETRANS_TIMER, the server resends the same offer
to the client. This procedure is repeated until maximum retry is to the client. This procedure is repeated until maximum retry is
reached.</t> reached.</t>
<t>If an ACCEPT message is received before the offered validity time <t>If an ACCEPT message is received before the offered validity time
expires, the server proceeds with validation checks as specified in expires, the server proceeds with validation checks as specified in
<xref target="validation"></xref>. The state of the corresponding <xref target="validation" format="default"/>. The state of the corresp onding
order is passed to "AcceptReceived". The server sends back an ACK order is passed to "AcceptReceived". The server sends back an ACK
message to terminate the order processing cycle.</t> message to terminate the order processing cycle.</t>
<t>If a CANCEL or a DECLINE message is received, the server proceeds w
<t>If a CANCEL/DECLINE message is received, the server proceeds with ith
the cancellation of the order. The state of the order is then passed the cancellation of the order. The state of the order is then passed
to "Cancelled".</t> to "Cancelled".</t>
</section> </section>
<section anchor="sordw" numbered="true" toc="default">
<section anchor="sordw" title="Order Withdrawal"> <name>Order Withdrawal</name>
<t>A client may withdraw a completed order by issuing a WITHDRAW <t>A client may withdraw a completed order by issuing a WITHDRAW
message. Upon receipt of a WITHDRAW message, the server proceeds message. Upon receipt of a WITHDRAW message, the server proceeds
with the validation checks, as specified in <xref with the validation checks, as specified in <xref target="validation"
target="validation"></xref>:<list style="symbols"> format="default"/>:</t>
<t>If the checks fail, a FAIL message is sent back to the client <ul spacing="normal">
<li>If the checks fail, a FAIL message is sent back to the client
with the appropriate error code (e.g., 1 (Message Validation with the appropriate error code (e.g., 1 (Message Validation
Error), 2 (Authentication Required), or 3 (Authorization Error), 2 (Authentication Required), or 3 (Authorization
Failed)).</t> Failed)).</li>
<li>If the checks succeed, the server clears the clauses of the
<t>If the checks succeed, the server clears the clauses of the CPD, changes the state of the
Connectivity Provisioning Document, changes the state of the
order to "Cancelled", and sends back an ACK message with an order to "Cancelled", and sends back an ACK message with an
Empty Connectivity Provisioning Document.</t> Empty CPD.</li>
</list></t> </ul>
</section> </section>
<section anchor="sordu" numbered="true" toc="default">
<section anchor="sordu" title="Order Update"> <name>Order Update</name>
<t>A client may update an order by issuing an UPDATE message. Upon <t>A client may update an order by issuing an UPDATE message. Upon
receipt of an UPDATE message, the server proceeds with the receipt of an UPDATE message, the server proceeds with the
validation checks as specified in <xref validation checks as specified in <xref target="validation" format="de
target="validation"></xref>:<?rfc subcompact="yes"?><list fault"/>:</t>
style="symbols"> <ul spacing="normal">
<t>If the checks fail, a FAIL message is sent back to the client <li>If the checks fail, a FAIL message is sent back to the client
with the appropriate error code (e.g., 1 (Message Validation with the appropriate error code (e.g., 1 (Message Validation
Error), 2 (Authentication Required), 3 (Authorization Failed), Error), 2 (Authentication Required), 3 (Authorization Failed),
or 6 (Network Presence Error)).</t> or 6 (Network Presence Error)).</li>
<li>The exchange of subsequent messages is similar to what is
<t>The exchange of subsequent messages is similar to what is specified in <xref target="creation" format="default"/>. The serve
specified in <xref target="creation"></xref>. The server should r should
generate a new Nonce value to be included in the offer made to generate a new Nonce value to be included in the offer made to
the client.<?rfc subcompact="no"?></t> the client.</li>
</list></t> </ul>
</section> </section>
</section> </section>
<section anchor="sq_nu" numbered="true" toc="default">
<section anchor="sq_nu" title="Sequence Numbers"> <name>Sequence Numbers</name>
<t>In each transaction, sequence numbers are used to protect the <t>In each transaction, sequence numbers are used to protect the
transaction against replay attacks. Each communicating partner of the transaction against replay attacks. Each communicating partner of the
transaction maintains two sequence numbers, one for incoming packets transaction maintains two sequence numbers, one for incoming packets
and one for outgoing packets. When a partner receives a message, it and one for outgoing packets. When a partner receives a message, it
will check whether the sequence number in the message is larger than will check whether the sequence number in the message is larger than
the incoming sequence number maintained locally. If not, the message the incoming sequence number maintained locally. If not, the message
will be discarded. If the message is proved to be legitimate, the will be discarded. If the message is proved to be legitimate, the
value of the incoming sequence number maintained locally will be value of the incoming sequence number maintained locally will be
replaced by the value of the sequence number in the message. When a replaced by the value of the sequence number in the message. When a
partner sends out a message, it will insert the value of the outgoing partner sends out a message, it will insert the value of the outgoing
sequence number into the message and increase the outgoing sequence sequence number into the message and increase the outgoing sequence
number maintained locally by 1.</t> number maintained locally by 1.</t>
</section> </section>
<section anchor="retrans" numbered="true" toc="default">
<section anchor="retrans" title="Message Re-Transmission"> <name>Message Retransmission</name>
<t>If a transaction partner sends out a message and does not receive <t>If a transaction partner sends out a message and does not receive
any expected reply before the retransmission timer expires (i.e., any expected reply before the retransmission timer expires (i.e.,
RETRANS_TIMER), a transaction partner will try to re-transmit the RETRANS_TIMER), a transaction partner will try to retransmit the
message. The procedure is reiterated until a maximum retry is reached message. The procedure is reiterated until a maximum retry is reached
(e.g., 3 times). An exception is the last message (e.g., ACK) sent (e.g., three times). An exception is the last message (e.g., ACK) sent
from the server in a transaction. After sending this message, the from the server in a transaction. After sending this message, the
retransmission timer will be disabled since no additional feedback is retransmission timer will be disabled since no additional feedback is
expected.</t> expected.</t>
<t>In addition, if the partner receives a retransmission of the last
<t>In addition, if the partner receives a retransmission of a last incoming packet it handled, the partner can resend the same answer to
incoming packet it handled, the partner can re-send the same answer to the incoming packet with a limited frequency. If an answer cannot be
the incoming packet with a limited frequency. If no answer was generated right after the request is received, the partner needs to
generated at the moment, the partner needs to generate a PROCESSING generate a PROCESSING message as the answer.</t>
message as the answer.</t>
<t>To optimize message retransmission, a partner could also store the <t>To optimize message retransmission, a partner could also store the
last incoming packet and the associated answer. Note that the times of last incoming packet and the associated answer. Note that the times of
retransmission could be decided by the local policy and retransmission retransmission could be decided by the local policy, and retransmission
will not cause any change of sequence numbers.</t> will not cause any change of sequence numbers.</t>
</section> </section>
</section> </section>
<section anchor="og" numbered="true" toc="default">
<section anchor="og" title="Some Operational Guidelines"> <name>Some Operational Guidelines</name>
<t></t> <section numbered="true" toc="default">
<name>CPNP Server Logging</name>
<section title="Logging on the CPNP Server ">
<t>The CPNP server should be configurable to log various events and <t>The CPNP server should be configurable to log various events and
associated information. Such information may include:<?rfc subcompact="y associated information. Such information may include the following:</t>
es"?></t> <ul spacing="normal">
<li>Client's IP address</li>
<t><list style="symbols"> <li>Any event change (e.g., new quotation order, offer sent, order
<t>Client's IP address</t> confirmation, order cancellation, order withdrawal, etc.)</li>
<li>Timestamp</li>
<t>Any event change (e.g., new quotation order, offer sent, order </ul>
confirm, order cancellation, order withdraw, etc.)</t> <t>The exact logging details are deployment specific.</t>
<t>Timestamp<?rfc subcompact="no"?></t>
</list>The exact logging details are deployment-specific.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Business Guidelines and Objectives"> <name>Business Guidelines and Objectives</name>
<t>The CPNP server can operate in the following modes: <list <t>The CPNP server can operate in the following modes: </t>
style="numbers"> <dl spacing="normal" newline="true">
<t>Fully automated mode: <vspace blankLines="1" />The CPNP server <dt>Fully automated mode: </dt>
<dd>The CPNP server
is provisioned with a set of business guidelines and objectives is provisioned with a set of business guidelines and objectives
that will be used as an input to the decision-making process. The that will be used as an input to the decision-making process. The
CPNP server will service received orders that fall into these CPNP server will service received orders that fall into these
business guidelines; otherwise, requests will be escalated to an business guidelines; otherwise, requests will be escalated to an
administrator that will formally validate/invalidate an order administrator that will formally validate or invalidate an order
request. The set of policies to be configured to the CPNP server request. The set of policies to be configured to the CPNP server
are specific to each administrative entity managing a CPNP are specific to each administrative entity managing a CPNP
server.</t> server.</dd>
<dt>Administrative-based mode: </dt>
<t>Administrative-based mode: <vspace blankLines="1" />This mode <dd>This mode
assumes some or all CPNP server' operations are subject to a assumes some or all of the CPNP server's operations are subject to a
formal administrative validation. CPNP events will trigger formal administrative validation. CPNP events will trigger
appropriate validation requests that will be forwarded to the appropriate validation requests that will be forwarded to the
contact person(s) or department which is responsible for contact person(s) or department that is responsible for
validating the orders. Administrative validation messages are validating the orders. Administrative validation messages are
relayed using another protocol (e.g., SMTP) or a dedicated relayed using another protocol (e.g., SMTP) or a dedicated
tool.</t> tool.</dd>
</list>Business guidelines are local to each administrative entity. </dl>
<t>Business guidelines are local to each administrative entity.
How validation requests are presented to an administrator are out of How validation requests are presented to an administrator are out of
scope of this document; each administrative entity may decide the scope of this document; each administrative entity may decide the
appropriate mechanism to enable for that purpose.</t> appropriate mechanism to enable for that purpose.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Means to defend the server against denial-of-service attacks must be <t>Means to defend the server against denial-of-service attacks must be
enabled. For example, access control lists can be enforced on the enabled. For example, access control lists can be enforced on the
client, the server or the network in between, to allow a trusted client client, the server, or the network in between to allow a trusted client
to communicate with a trusted server.</t> to communicate with a trusted server.</t>
<t>The client and the server must be mutually authenticated. <t>The client and the server must be mutually authenticated.
Authenticated encryption must be used for data confidentiality and Authenticated encryption must be used for data confidentiality and
message integrity.</t> message integrity.</t>
<t>The protocol does not provide security mechanisms to protect the <t>The protocol does not provide security mechanisms to protect the
confidentiality and integrity of the packets transported between the confidentiality and integrity of the packets transported between the
client and the server. An underlying security protocol such as (e.g., client and the server. An underlying security protocol such as (e.g.,
Datagram Transport Layer Security (DTLS) <xref target="RFC6347"></xref>, Datagram Transport Layer Security (DTLS) <xref target="RFC6347" format="de
Transport Layer Security (TLS) <xref target="RFC8446"></xref>) must be fault"/>,
Transport Layer Security (TLS) <xref target="RFC8446" format="default"/>)
must be
used to protect the integrity and confidentiality of protocol messages. used to protect the integrity and confidentiality of protocol messages.
In this case, if it is possible to provide an Automated Key Management In this case, if it is possible to provide automated key management
(<xref target="RFC4107" section="2.1" sectionFormat="of" format="default"/
>)
and associate each transaction with a different key, inter-transaction and associate each transaction with a different key, inter-transaction
replay attacks can naturally be addressed. If the client and the server replay attacks can naturally be addressed. If the client and the server
use a single key, an additional mechanism should be provided to protect use a single key, an additional mechanism should be provided to protect ag ainst
inter-transaction replay attacks between them. Clients must implement inter-transaction replay attacks between them. Clients must implement
DTLS record replay detection (Section 3.3 of <xref DTLS record replay detection (<xref target="RFC6347"
target="RFC6347"></xref>) or an equivalent mechanism to protect against sectionFormat="of" section="3.3" />) or an equivalent mechanism to protect
against
replay attacks.</t> replay attacks.</t>
<t>DTLS and TLS with a cipher suite offering confidentiality protection <t>DTLS and TLS with a cipher suite offering confidentiality protection
and the guidance given in <xref target="RFC7525"></xref> must be and the guidance given in <xref target="RFC7525" format="default"/> must b e
followed to avoid attacks on (D)TLS.</t> followed to avoid attacks on (D)TLS.</t>
<t>The client must silently discard CPNP responses received from unknown <t>The client must silently discard CPNP responses received from unknown
CPNP servers. The use of a randomly generated Transaction-ID makes it 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 hard to forge a response from a server with a spoofed IP address
belonging to a legitimate CPNP server. Furthermore, CPNP demands that belonging to a legitimate CPNP server. Furthermore, CPNP demands that
messages from the server must include the correct identifiers of the messages from the server must include the correct identifiers of the
orders. Two order identifiers are used: one generated by the client and orders. Two order identifiers are used: one generated by the client and
a second one generated by the server. Both the CPNP client and server a second one generated by the server. Both the CPNP client and server
maintain the local identifier they assigned and the one assigned by the maintain the local identifier they assigned and the one assigned by the
peer for a given order. Means to detect swapping of these identifiers peer for a given order. Means to detect swapping of these identifiers
(even when such swapping occurs by inadvertence at the client or the (even when such swapping occurs inadvertently at the client or the
server) should be enabled by CPNP clients/servers. For example, the CPNP server) should be enabled by CPNP clients/servers. For example, the CPNP
server should not assign a provider agreement identifier that is equal server should not assign a Provider agreement identifier that is equal
to a customer agreement identifier used by the CPNP client. </t> to a Customer agreement identifier used by the CPNP client. </t>
<t>The Provider must enforce the means to protect privacy-related
<t>The Provider must enforce means to protect privacy-related information included in the documents (see <xref target="cpd" format="defa
information included the documents (see <xref target="cpd"></xref>) ult"/>)
exchanged in CPNP messages <xref target="RFC6462"></xref>. In exchanged in CPNP messages <xref target="RFC6462" format="default"/>. In
particular, this information must not be revealed to external parties particular, this information must not be revealed to external parties
without the consent of Customers. Providers should enforce policies to without the consent of Customers. Providers should enforce policies to
make Customer fingerprinting difficult to achieve (e.g., in a recursion make Customer fingerprinting difficult to achieve (e.g., in a recursion
request). For more discussion about privacy, refer to <xref request). For more discussion about privacy, refer to <xref target="RFC646
target="RFC6462"></xref><xref target="RFC6973"></xref>.</t> 2" format="default"/>
<xref target="RFC6973" format="default"/>.</t>
<t>The Nonce and the Transaction ID attributes provide sufficient <t>The Nonce and the Transaction-ID attributes provide sufficient
randomness and can effectively tolerate attacks raised by off-path randomness and can effectively tolerate attacks raised by off-path
adversaries, who do not have the capability of eavesdropping and adversaries, who do not have the capability of eavesdropping and
intercepting the packets transported between the client and the server. intercepting the packets transported between the client and the server.
Only authorized clients must be able to modify agreed CPNP orders. The Only authorized clients must be able to modify accepted CPNP orders. The
use of a randomly generated Nonce by the server makes it hard to modify use of a randomly generated Nonce by the server makes it hard to modify
an agreement on behalf of a malicious third-party.</t> an agreement on behalf of a malicious third party.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not request any IANA action.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section title="Acknowledgements"> <name>IANA Considerations</name>
<t>Thanks to Diego R. Lopez, Adrian Farrel, Eric Vyncke, Eric Kline, and <t>This document has no IANA actions.</t>
Benjamin Kaduk for the comments.</t>
<t>Thanks to the ISE reviewers.</t>
<t>Special thanks to Luis Miguel Contreras Murillo for the detailed
review.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc ?>
<?rfc include='reference.RFC.4086'?>
<?rfc include='reference.RFC.5511'?>
<?rfc include='reference.RFC.7525'?>
<?rfc include='reference.RFC.8446'?>
<?rfc include='reference.RFC.6347'?>
<?rfc include='reference.RFC.7297'?>
<?rfc include='reference.RFC.3339'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4176'?>
<?rfc include='reference.RFC.6125'?>
<?rfc include='reference.RFC.8309'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.RFC.8259'?>
<?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'?> <displayreference target="I-D.boucadair-lisp-idr-ms-discovery" to="LISP-MS-DISCO
VERY"/>
<?rfc include='reference.RFC.2782'?> <displayreference target="I-D.geng-netslices-architecture" to="NETSLICES-ARCH"/>
<displayreference target="I-D.contreras-teas-slice-nbi" to="TEAS-SLICE-NBI"/>
<?rfc include='reference.RFC.6574'?> <displayreference target="I-D.ietf-opsawg-l3sm-l3nm" to="L3VPN-NETWORK-YANG"/>
<displayreference target="I-D.itsumo-dsnp" to="DSNP"/>
<?rfc include='reference.RFC.6793'?> <displayreference target="I-D.nguyen-rap-cops-sls" to="COPS-SLS"/>
<displayreference target="I-D.ietf-opsawg-l2nm" to="L2VPN-NETWORK-YANG"/>
<?rfc include='reference.RFC.6830'?>
<?rfc include='reference.RFC.3084'?>
<?rfc include='reference.RFC.7049'?>
<?rfc include='reference.RFC.8299'?>
<?rfc include='reference.RFC.8466'?>
<?rfc include='reference.I-D.boucadair-lisp-idr-ms-discovery'?>
<?rfc include='reference.I-D.geng-netslices-architecture'?>
<?rfc include='reference.I-D.contreras-teas-slice-nbi'?>
<?rfc include='reference.RFC.8329'?>
<?rfc include='reference.RFC.7215'?>
<?rfc include='reference.RFC.7491'?>
<?rfc include='reference.RFC.8040'?>
<?rfc include='reference.RFC.8597'?>
<?rfc include='reference.I-D.ietf-opsawg-l3sm-l3nm'?>
<?rfc include='reference.I-D.itsumo-dsnp'?>
<?rfc include='reference.I-D.nguyen-rap-cops-sls'?>
<?rfc include='reference.I-D.barguil-opsawg-l2sm-l2nm'?>
<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=""> <references>
<organization>EU FP7 ETICS Project</organization> <name>References</name>
</author> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5511.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7297.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3339.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4176.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6125.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8309.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6241.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7149.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4026.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6973.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6462.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6770.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2782.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6574.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6793.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6830.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3084.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7049.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8299.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8466.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4107.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.boucadair-lisp-idr-ms-discovery.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.geng-netslices-architecture.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.contreras-teas-slice-nbi.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8329.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7215.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7491.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8040.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8597.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-opsawg-l3sm-l3nm.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.itsumo-dsnp.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
nguyen-rap-cops-sls.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-opsawg-l2nm.xml"/>
<date day="0" month="January" year="2014" /> <reference anchor="ETICS" target="https://cordis.europa.eu/project/id/24
</front> 8567">
</reference> <front>
<title>Economics and Technologies of Inter-Carrier Services</title>
<author fullname="" surname="">
<organization>EU FP7 ETICS Project</organization>
</author>
<date month="January" year="2014"/>
</front>
</reference>
<reference anchor="AGAVE" <reference anchor="AGAVE" target="https://rd.springer.com/article/10.100
target="https://rd.springer.com/article/10.1007/s12243-009-0103 7/s12243-009-0103-4">
-4"> <front>
<front> <title>The AGAVE Approach for Network Virtualization: Differentiated
<title>The AGAVE Approach for Network Virtualization: Differentiated
Services Delivery</title> Services Delivery</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>EU FP7 ETICS Project</organization>
</author>
<author fullname="Panos Georgatsos" initials="P." surname="Georgatso
s"/>
<author fullname="N. Wang" initials="N." surname="Wang"/>
<author fullname="D. Griffin" initials="D." surname="Griffin"/>
<author fullname="G. Pavlou" initials="G." surname="Pavlou"/>
<author fullname="M. Howarth" initials="M." surname="Howarth"/>
<author fullname="A. Elizondo" initials="A." surname="Elizondo"/>
<date month="April" year="2009"/>
</front>
<refcontent>Annals of Telecommunication, Volume 64, 277-288</refcontent
>
<seriesInfo name="DOI" value="10.1007/s12243-009-0103-4"/>
</reference>
<author fullname="Mohamed Boucadair" initials="M." <reference anchor="SrNP" target="https://www.ist-tequila.org/presentatio
surname="Boucadair"> ns/srnp-pipcm.pdf">
<organization>EU FP7 ETICS Project</organization> <front>
</author> <title>Service Negotiation Protocol (SrNP)</title>
<author fullname="Panos Georgatsos" initials="P." surname="Georgatso
<author fullname="Panos Georgatsos" initials="P." s"/>
surname="Georgatsos"> <author fullname="Dimitris Giannakopoulos" initials="G." surname="Gi
<organization></organization> annakopoulos"/>
<date/>
<address> </front>
<postal> </reference>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="N. Wang" initials="N." surname="Wang">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="D. Griffin" initials="D." surname="Griffin">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="G. Pavlou" initials="G." surname="Pavlou">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="M. Howarth" initials="M." surname="Howarth">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="A. Elizondo" initials="A." surname="Elizondo">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="10" month="April" year="2009" />
</front>
</reference>
<reference anchor="TEQUILA"
target="https://www.ist-tequila.org/presentations/srnp-pipcm.pd
f">
<front>
<title>Service Negotiation Protocol (SrNP)</title>
<author fullname="Panos Georgatsos" initials="P."
surname="Georgatsos">
<organization></organization>
</author>
<author fullname="Dimitris Giannakopoulos" initials="G."
surname="Giannakopoulos">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date />
</front>
</reference>
<reference anchor="Xin"
target="http://www.cs.columbia.edu/~xinwang/public/projects/pro
tocol.html">
<front>
<title>Resource Negotiation and Pricing Protocol (RNAP)</title>
<author fullname="Xin Wang" initials="X." surname="Wang">
<organization></organization>
</author>
<date /> <reference anchor="RNAP" target="http://www.cs.columbia.edu/~xinwang/pub
</front> lic/projects/protocol.html">
</reference> <front>
<title>A Resource Negotiation and Pricing Protocol (RNAP)</title>
<author fullname="Xin Wang" initials="X." surname="Wang">
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="Karl" <reference anchor="SNAP" target="http://citeseerx.ist.psu.edu/viewdoc/su
target="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1 mmary?doi=10.1.1.19.5907">
.19.5907"> <front>
<front> <title>SNAP: A Protocol for Negotiating Service Level Agreements and
<title>SNAP: A Protocol for Negotiating Service Level Agreements and
Coordinating Resource Management in Distributed Systems</title> Coordinating Resource Management in Distributed Systems</title>
<author fullname="Karl Czajkowski"/>
<author fullname="Ian Foster"/>
<author fullname="Carl Kesselman"/>
<author fullname="Volker Sander"/>
<author fullname="Steven Tuecke"/>
<date year="2002"/>
</front>
<seriesInfo name="DOI" value="10.1.1.19.5907"/>
</reference>
</references>
</references>
<author fullname="Karl Czajkowski"> <section numbered="false" toc="default">
<organization></organization> <name>Acknowledgements</name>
</author> <t>Thanks to <contact fullname="Diego R. Lopez"/>,
<contact fullname="Adrian Farrel"/>, <contact fullname="√Čric Vyncke"/>,
<author fullname="Ian Foster"> <contact fullname="Eric Kline"/>, and <contact fullname="Benjamin Kaduk"/>
<organization></organization> for the comments.</t>
<t>Thanks to those that reviewed this document for publication
<address> in the Independent Stream.</t>
<postal> <t>Special thanks to <contact fullname="Luis Miguel Contreras Murillo"/> f
<street></street> or the detailed
review.</t>
<city></city> </section>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Carl Kesselman ">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Volker Sander">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Steven Tuecke">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date />
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 426 change blocks. 
2124 lines changed or deleted 1734 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/